PCF-PDSN Ios Standard

A.S0017-0v1.
3GPP2 A.S0017-0
Version 1.0
Date: November 16, 2001
2
3
4
5
6
7
8
9
10
11
12
13 Interoperability Specification (IOS) for CDMA 2000

14 Access Network Interfaces — Part 7 (A10 and A11
15 Interfaces)
16
17 Revision 0 (3G IOSv4.2)

18
19 (SDO Ballot Version)

20
21
22
23
24
25
26
27 © 3GPP2 2001
28 3GPP2 and its Organizational Partners claim copyright in this document and individual
29 Organizational Partners may copyright and issue documents or standards publications in
30 individual Organizational Partner's name based on this document. Requests for reproduction of
31 this document should be directed to the 3GPP2 Secretariat at secretariat@3gpp2.org. Requests
32 to reproduce individual Organizational Partner's documents should be directed to that
33 Organizational Partner. See www.3gpp2.org for more information.
34
A.S0017-0v1.0
1 Table of Contents
2
3 1.0 Introduction......................................................................................................................................... 5
4 1.1 Overview......................................................................................................................................... 5
5 1.1.1 Purpose.................................................................................................................................... 5
6 1.1.2 Scope....................................................................................................................................... 5
7 1.2 References....................................................................................................................................... 5
8 1.2.1 Telecommunications Industry Association (TIA) / Electronics Industry Association (EIA).. 6
9 1.2.2 3GPP2 ..................................................................................................................................... 6
10 1.2.3 Other ....................................................................................................................................... 6
11 1.3 Terminology.................................................................................................................................... 6
12 1.3.1 Acronyms................................................................................................................................ 6
13 1.3.2 Definitions............................................................................................................................... 7
14 1.4 Message Body, Coding, and Ordering of Elements ........................................................................ 7
15 1.5 Forward Compatibility Guidelines.................................................................................................. 9
16 1.6 Message Definition Guidelines ....................................................................................................... 9
17 1.7 IOS Upgrade Guidelines ............................................................................................................... 10
18 2.0 Message Procedures.......................................................................................................................... 11
19 2.1 A10 Connection Establishment Procedures .................................................................................. 11
20 2.1.1 A11-Registration Request ..................................................................................................... 11
21 2.1.1.1 Successful Operation............................................................................................................ 11
22 2.1.1.2 Failure Operation ................................................................................................................. 11
23 2.1.2 A11-Registation Reply.......................................................................................................... 12
26 2.2 A10 Connection Operational Procedures...................................................................................... 13
33 2.3 A10 Connection Release Procedures ............................................................................................ 14
40 2.3.3. A11-Registation Update........................................................................................................ 15
43 2.3. A11-Registration Acknowledge................................................................................................ 15
46 2.4 A10 Packet Accounting Procedures.............................................................................................. 16
47 2.4.1 A10 Connection Setup Airlink Record ................................................................................. 16
48 2.4.2 Active-Start Airlink Record .................................................................................................. 16
49 2.4.3 Active-Stop Airlink Record .................................................................................................. 17
50 2.4.4 SDB Airlink Record.............................................................................................................. 17
51 2.4.5 Accounting at Re-registration ............................................................................................... 17
52 2.4.6 Sequence Numbers................................................................................................................ 17
53 2.4.7 Accounting update due to parameter changes....................................................................... 17
54 2.5 Mobile IP Based Tunneling Protocol............................................................................................ 18
55 2.5.1 Mobile IP Extensions ............................................................................................................ 18
i
A.S0017-0v1.0
1 2.5.1.1 Registration Request ............................................................................................................ 18

2 2.5.1.2 Registration Reply................................................................................................................ 18
3 2.5.1.3 Registration Update/Acknowledge ...................................................................................... 18
4 2.5.1.4 Registration Update Authentication Extension .................................................................... 18
5 3.0 Message Formats .............................................................................................................................. 19
6 3.1 A11-Registration Request ............................................................................................................. 19
7 3.2 A11-Registration Reply ................................................................................................................ 23
8 3.3 A11-Registration Update .............................................................................................................. 26
9 3.4 A11-Registration Acknowledge.................................................................................................... 29
10 4.0 Information Element Definitions ...................................................................................................... 33
11 4.1 Generic Information Element Encoding ....................................................................................... 33
12 4.1.1 Conventions .......................................................................................................................... 33
13 4.1.2 Information Element Identifiers............................................................................................ 33
14 4.1.3 Additional Coding and Interpretation Rules for Information Elements ................................ 35
15 4.1.4 Cross Reference of Information Elements With Messages ................................................... 35
16 4.2 Information Elements.................................................................................................................... 36
17 4.2.1 A11 Message Type................................................................................................................ 36
18 4.2.2 Flags...................................................................................................................................... 37
19 4.2.3 Lifetime................................................................................................................................. 37
20 4.2.4 Home Address....................................................................................................................... 37
21 4.2.5 Home Agent .......................................................................................................................... 38
22 4.2.6 Care-of-Address .................................................................................................................... 38
23 4.2.7 Identification ......................................................................................................................... 39
24 4.2.8 Code ...................................................................................................................................... 39
25 4.2.9 Status..................................................................................................................................... 40
26 4.2.10 Mobile-Home Authentication Extension .............................................................................. 40
27 4.2.11 Registration Update Authentication Extension ..................................................................... 41
28 4.2.12 Session Specific Extension ................................................................................................... 41
29 4.2.13 Critical Vendor/Organization Specific Extension (CVSE) ................................................... 43
30 4.2.14 Normal Vendor/Organization Specific Extension (NVSE)................................................... 50
31 5.0 Timer Definitions.............................................................................................................................. 55
32 5.1 Timer Values................................................................................................................................. 55
33 5.2 Timer Definitions.......................................................................................................................... 55
34 5.2.1 Tregreq ..................................................................................................................................... 55
35 5.2.2 Tregupd ..................................................................................................................................... 55
36 5.2.3 Trp .......................................................................................................................................... 55
37 5.2.4 Tpresetup ................................................................................................................................... 55
38
39
ii
A.S0017-0v1.0
1 List of Tables
2
3 Table 1.4-1 Element Flow DIRECTION Indication ....................................................................................... 8

4 Table 2.4-1 - Accounting Records Generated By The PCF ......................................................................... 16
5 Table 4.1.2-1 A11 Information Element Identifiers Sorted by Name ........................................................... 34
6 Table 4.1.2-2 A11 Information Element Identifiers Sorted by Value........................................................... 34
7 Table 4.1.4-1 Cross Reference of Information Elements With Messages .................................................... 35
8 Table 4.2.1-1 A11 Interface Message Types ................................................................................................ 37
9 Table 4.2.2-1 Setting of A11-Registration Request Message Flags.............................................................. 37
10 Table 4.2.4-1 Setting of Home Address Field............................................................................................... 38
11 Table 4.2.8-1 A11 Code Values.................................................................................................................... 39
12 Table 4.2.9-1 A11 Status Values .................................................................................................................. 40
13 Table 4.2.12-1 A11 Protocol Type Values.................................................................................................... 42
14 Table 4.2.13-1 Vendor/Organization Specific Extension - Application Type .............................................. 44
15 Table 4.2.13-2 Application Sub Type ........................................................................................................... 45
16 Table 4.2.14-1 Vendor/Organization Specific Extension - Application Type .............................................. 51
17 Table 4.2.14-2 Application Sub Type ........................................................................................................... 52
18 Table 5.1-1 Timer Values and Ranges Sorted by Name ............................................................................... 55
19
iii
A.S0017-0v1.0
1 1.0 Introduction
2 1.1 Overview
3 This document contains the message procedures, bitmaps, information elements, and timers used
4 to define the interfaces for the Aquater Reference Point.
5 1.1.1 Purpose
6 TBD
7 1.1.2 Scope
8 TBD
9 1.2 References
10 [1] TIA/EIA/IS-2000.1-A, Introduction to CDMA 2000 Standards for Spread Spectrum
11 Systems, March 2000. Refer also to 3GPP2 C.S0001-0.
12 [2] TIA/EIA/IS-2000.2-A, Physical Layer Standard for CDMA 2000 Spread Spectrum
14 [3] TIA/EIA/IS-2000.3-A, Medium Access Control (MAC) Standard for CDMA 2000 Spread
15 Spectrum Systems, March 2000. Refer also to 3GPP2 C.S0003-0.
16 [4] TIA/EIA/IS-2000.4-A, Signaling Link Access Control (LAC) Standard for CDMA 2000
17 Spread Spectrum Systems, March 2000. Refer also to 3GPP2 C.S0004-0.
18 [5] TIA/EIA/IS-2000.5-A, Upper Layer (Layer 3) Signaling Standard for CDMA 2000
19 Spread Spectrum Systems, March 2000. Refer also to 3GPP2 C.S0005-0.
20 [6] TIA/EIA/IS-2000.6-A, Analog Signaling Standard for CDMA 2000 Spread Spectrum
22 [11] A.S0011-0, Interoperability Specification (IOS) for CDMA 2000 Access Network
23 Interfaces – Part 1 Overview, October 2001. Refer also to TIA/EIA-2001.1-B.
25 Interfaces – Part 2 Transport, October 2001. Refer also to TIA/EIA-2001.2-B.
27 Interfaces – Part 3 Features, October 2001. Refer also to TIA/EIA-2001.3-B.
29 Interfaces – Part 4 (A1, A2, and A5 Interfaces), October 2001. Refer also to TIA/EIA-
30 2001.4-B.
32 Interfaces – Part 5 (A3 and A7 Interfaces), October 2001. Refer also to TIA/EIA-2001.5-
33 B.
35 Interfaces – Part 6 (A8 and A9 Interfaces), October 2001. Refer also to TIA/EIA-2001.6-
36 B.
38 Interfaces – Part 7 (A10 and A11 Interfaces), October 2001. Refer also to TIA/EIA-
39 2001.7-B.
Section 1 5
A.S0017-0v1.0
1 1.2.1 Telecommunications Industry Association (TIA) / Electronics

2 Industry Association (EIA)
3 [18] TIA/EIA-2001.1-B, Interoperability Specification (IOS) for CDMA 2000 Access Network
4 Interfaces – Part 1 Overview, October 2001. Refer also to A.S0011-0.
6 Interfaces – Part 2 Transport, October 2001. Refer also to A.S0012-0.
8 Interfaces – Part 3 Features, October 2001. Refer also to A.S0013-0.
10 Interfaces – Part 4 (A1, A2, and A5 Interfaces), October 2001. Refer also to A.S0014-0.
12 Interfaces – Part 5 (A3 and A7 Interfaces), October 2001. Refer also to A.S0015-0.
17 [25] TIA/EIA/IS-637-A, Short Message Service for Spread Spectrum Systems, September,
18 1999.
19 [26] TIA/EIA/IS-835, cdma2000 Wireless IP Network Standard, December 2000.
20 1.2.2 3GPP2
21 [27] 3GPP2 C.S0001-0, Introduction to CDMA 2000 Standards for Spread Spectrum Systems,
22 June 2000. Refer also to TIA/EIA/IS-2000.1-A.
23 [28] 3GPP2 C.S0002-0, Physical Layer Standard for CDMA 2000 Spread Spectrum Systems,
24 June 2000. Refer also to TIA/EIA/IS-2000.2-A.
25 [29] 3GPP2 C.S0003-0, Medium Access Control (MAC) Standard for CDMA 2000 Spread
26 Spectrum Systems, June 2000. Refer also to TIA/EIA/IS-2000.3-A.
27 [30] 3GPP2 C.S0004-0, Signaling Link Access Control (LAC) Standard for CDMA 2000
28 Spread Spectrum Systems, June 2000. Refer also to TIA/EIA/IS-2000.4-A.
29 [31] 3GPP2 C.S0005-0, Upper Layer (Layer 3) Signaling Standard for CDMA 2000 Spread
30 Spectrum Systems, June 2000. Refer also to TIA/EIA/IS-2000.5-A.
31 [32] 3GPP2 C.S0006-0, Analog Signaling Standard for CDMA 2000 Spread Spectrum
32 Systems, June 2000. Refer also to TIA/EIA/IS-2000.6-A.
33 1.2.3 Other
34 [33] Internet Engineering Task Force, RFC 2002 – IP Mobility Support Specification, 1996.
35 [34] Internet Engineering Task Force, RFC 2138 – Remote Authentication Dial In User
36 Services (RADIUS), 1997.
37 [35] Internet Engineering Task Force, RFC 2139 – RADIUS Accounting, 1997.
38 1.3 Terminology
39 1.3.1 Acronyms
40
Acronym Meaning
3GPP2
ANID Access Network Identifiers
BCD Binary Coded Decimal
BS Base Station
Section 1 6
A.S0017-0v1.0
Acronym Meaning
BSID Base Station ID
CANID Current Access Network Identifiers
CDG CDMA Development Group
CVSE Critical Vendor/Organization Specific Extension
DAI Data Available Indicator
EIA Electronics Industry Association
ESN Electronic Serial Number
GRE Generic Routing Encapsulation
IEI Information Element Identifier
IETF Internet Engineering Task Force
IOS Interoperability Specification
IP Internet Protocol
IS Interim Standard
LSB Least Significant Bit
MSB Most Significant Bit
MSID Mobile Station ID
OA&M Operations, Administration, and Maintenance
PANID Previous Access Network Identifiers
PCF Packet Control Function
PDSN Packet Data Serving Node
QOS Quality of Service
RADIUS Remote Authentication Dial In User Service
RC Radio Configuration, Radio Class
RRP Registration RePly
RRQ Registration ReQuest
SDB Short Data Burst
SPI Security Parameter Index
TIA Telecommunications Industry Association
TLV Type Length Value
VSE Vendor Specific Extension
1 1.3.2 Definitions
2 TBD
3 1.4 Message Body, Coding, and Ordering of Elements

4 For each A11 Interface message there are a number of information elements that are individually
5 defined in section 4.2. Each information element in a given message is tagged with a reference in
6 section 4.2, a direction indication (i.e., some elements within a message are bi-directional and
7 others are not), and a mandatory/optional type (M/O) indicator. Information elements that are
8 marked as optional carry an additional indication of being either required (R) or conditional (C).
9 (See below.) Some information elements are reused in multiple messages.
Section 1 7
A.S0017-0v1.0
1 The DIRECTION indication associated with each message element pertains to the use of that
2 particular message element when used with the particular message (i.e., use of the message
3 element may be different in other messages). The format of the DIRECTION indication is as
4 follows:
5 Table 1.4-1 Element Flow DIRECTION Indication

PCF -> PDSN Element flows from the PCF to the PDSN
PDSN -> PCF Element flows from the PDSN to the PCF
6 The inclusion of information elements in each message is specified as follows:
7 M Information elements which are mandatory for the message.
8 O Information elements which are optional for the message.
9 R Required in the message whenever the message is sent.
10 C Conditionally required. The conditions for inclusion of this element is
11 defined in the operation(s) where the message is used (see [13]) and in
12 footnotes associated with the table defining the order of information
13 elements in the message.
14 Information elements which are mandatory for a given message shall be present, and appear in the
15 order shown in the message definitions in this chapter.
16 Information elements which are optional for a given message are included as needed for specific
17 conditions. When included, they shall appear in the order shown in the message definition given in
18 this chapter.
19 An information element can very well be mandatory for some messages and optional for other
20 messages.
21 The bitmap tables in the message subsections of 3.0 are patterned after the format for
22 the information elements of section 4.2 and use the following conventions:
23 ⇒ Element Name{<# instances>:
24 = Name of information element.
25 Different elements within a message are separated by
26 double lines.
27 Fields within elements are separated by single lines.
28 Octets are renumbered at the beginning of every
29 element.
30 [<values>] = Set of allowed values.
31 } Element Name The number of instances of an element is 1 by default.
32 If the Element Name{<# instances … }Element
33 Name notation is used, the <# instances> notation
34 indicates:
35 n = exactly n occurrences of the element
36 n+ = n or more occurrences of the element
37 1..n = 1 to n inclusive occurrences of the element
38 label {<# instances>:
39 <octet 1>
Section 1 8
A.S0017-0v1.0
1 <octet m>
2 } label = Number of instances of the bracketed set of fields

3 where <# instances> notation indicates:
4 n = exactly n occurrences of the field
5 n+ = n or more occurrences of the field
6 1..n = 1 to n inclusive occurrences of the field
7 ssss ssss
8 ••• = Variable length field.
9 ssss ssss
10 1.5 Forward Compatibility Guidelines

11 This standard will evolve to accommodate new features and capabilities. To ensure that equipment
12 implemented to one revision level will interoperate with equipment implemented to later revision
13 levels the following guidelines are defined for the processing of messages and for the development
14 of messages in future revisions of this standard.
15 Unexpected signaling information may be received at an entity due to differing revision levels of
16 signaling protocol at different entities within a network: an entity using a more enhanced version
17 of the protocol may send (unless overridden by section 1.8) information to an entity implemented
18 at a lower level of the protocol which is outside the protocol definition supported at that receiving
19 entity.
20 It may happen that an entity receives unrecognized signaling information, i.e., messages, element
21 types or element values. This can typically be caused by the upgrading of the protocol version
22 used by other entities in the network. In these cases the following message processing guidelines
23 are invoked (unless overridden by section 1.8) to ensure predictable network behavior.
24 If the receiving entity is implemented to version 4.0 of the IOS or greater, then the sending entity
25 shall send messages that are correctly formatted for the version of the IOS declared to be
26 implemented by the sending entity, (unless overridden by section 1.8).
27 If the receiving entity is implemented to a CDG IOS version less than 3.1.0, then if the sending
28 entity is at an equal or greater version than the receiver, the sending entity shall format messages
29 according to the version of the protocol implemented at the receiving entity.
30 For example, a CDG IOS version 3.1.0 entity by using the following guidelines (unless overridden
31 by section 1.8) may be capable of ignoring additional new elements or fields within elements sent
32 by an entity implemented to an IOS version higher than 3.1.0.
33 1.6 Message Definition Guidelines

34 1. New messages shall have a Message Type that was never previously used.
35 2. Information Element Identifiers may be reused in future revisions only when:
36 ♦ The old use of the element identifier is not used in the new revision, and
37 ♦ The new use of the element identifier is used only in new messages which
38 were not defined in previous revisions.
Section 1 9
A.S0017-0v1.0
1 ♦ The old use of the element identifier shall be supported within the context
2 of the old messages in which it was used.
3 3. Defined valid values of Information Elements may be changed in future revisions.
4 The new version shall define the error handling when previously valid values are
5 received.
6 4. Octets and bits which are undefined or which are defined as reserved may be used
7 in future revisions.
8 5. The Mandatory/Optional designation of Information Elements within a message
9 shall not change.
10 6. Mandatory Information elements shall be sent in the order specified in section 3.0.
11 7. New optional Information Elements in a message shall be defined after all
12 previously defined optional Information Elements.
13 8. All new Information Elements shall be defined with a length field.
14 9. New information may be added to the end of an existing Information Element,
15 provided that the Information Element is defined with a length field.
16 1.7 IOS Upgrade Guidelines

17 For supporting backward compatibility on the A11 interface:
18 When two nodes communicate on the A1 interface no element shall be sent which is larger or
19 smaller in length, or have values other than expected as per the protocol version of the node
20 running on the lower protocol version. If an information element is sent in a manner that violates
21 the above principle, or if an unexpected or unknown element is sent in the middle of a message, or
22 if an element that was required to be sent for successful message processing as per the protocol
23 revision of the node running at the lower version is not sent, then failure handling may be invoked
24 by the receiving node. If the receiving node determines that failure handling does not need to be
25 applied, then processing may continue with the receiving entity generating any OA&M logs as
26 required.
27 Any new elements may be sent to the node running the lower protocol version if the position of
28 those elements is beyond the end of the elements expected by the lower protocol revision.
29 Elements that were defined at the lower protocol revision but marked as not required and that
30 become used at the higher protocol revision and appear before the end of the elements expected by
31 the lower protocol revision shall not be sent to the node running the lower protocol revision.
32 If both the nodes are running the same protocol version then the above rules still apply.
33
Section 1 10
A.S0017-0v1.0
1 2.0 Message Procedures

2 This section describes message procedures for the A10/A11 interface.
3 2.1 A10 Connection Establishment Procedures
4 2.1.1 A11-Registration Request

5 This message is sent from the PCF to the PDSN to initiate establishment of an A10 connection.
6 2.1.1.1 Successful Operation

7 The PCF initiates setup of an A10 connection by sending an A11-Registration Request message to
8 the PDSN and starts timer Tregreq. The A11-Registration Request message is structured as
9 specified in [33] and contains the extensions specified in this standard. The A11-Registration
10 Request message may be retransmitted a configurable number of times as specified in [33].
11 If the connection setup request is acceptable, the PDSN updates its binding record for the A10
12 connection by creating an association between the PDSN Session Identifier (PDSN SID) and the
13 IMSI address, PCF-Address and PDSN-Address information. The PSDN SID shall be identical to
14 the PCF Session Identifier (PCF SID), If the either the PCF or the PDSN does not support a
15 Session Identifier Version higher than ‘0’, the PDSN may choose any PDSN SID.
16 The PCF and the PDSN use the PCF-IP-Address and the PDSN-IP-Address returned in the A11-
17 Registration Reply message as the A10 connection for the transport of user traffic. The PCF-IP-
18 Address and the PDSN-IP-Address form the unique link layer ID for each A10 connection. The
19 PCF and the PDSN maintain an association of the mobile’s IMSI address with the A10
20 connection.
21 If the PCF initiates the setup of the A10 connection due to dormant handoff the PCF shall include
22 a Mobility Event Indicator as CVSE and the CANID and PANID as a NVSE in the A11-
23 Registartion Request
24 If the PCF initiates the setup of the A10 connection due to hard handoff with support of Fast
25 handoff, The PCF shall set the flag bit S to ‘1’, include the anchor PDSN IP address in a NVSE
26 and set the ‘lifetime’ to Tpresetup in the A11-Registartion Request
27 2.1.1.2 Failure Operation

28 If the PCF does not receive an A11-Registration Reply message from the PDSN before timer
29 Tregreq expires, the PCF may retransmit the A11-Registration Request message. A connection
30 establishment is considered to have failed if no A11-Registration Reply is received after a
31 configurable number of A11-Registration Request retransmissions.
32 Reliable message delivery mechanisms are used for setting up the A10 connection between the
33 PCF and the PDSN.
34 When the PDSN receives an A11-Registration Request message with a NVSE element that
35 contains unrecognizable information in an element field (Vendor ID, Application Type,
36 Application Sub Type or Application Data), the PDSN shall reject the NVSE element that contains
37 the unrecognizable field and process the rest of the A11-Registration Request message.
Section 2 11
A.S0017-0v1.0
1 When PDSN receives an A11-Registration Request message with a CVSE element that contains
2 unrecognizable information in an element field (Vendor ID, Application Type, Application Sub
3 Type or Application Data), the PDSN shall reject the A11-Registartion Request message with the
4 reject error code 8DH (Registration Denied – unsupported Vendor ID or unable to interpret the
5 information).
6 2.1.2 A11-Registation Reply

7 The PDSN sends this message to the PCF to either establish or refuse establishment of an A10
8 connection.

10 Upon receipt of an A11-Registration Request message with a nonzero ‘lifetime’, the PDSN shall
11 respond with an A11-Registration Reply message. If the PDSN accepts the A10 connection, it
12 shall send an ‘accept’ indication in the message. PCF stops timer Tregreq when it receives the A11-
13 Registartion Relay.
14 In the case of PDSN has data to send to PCF when it receives an A11-Registartion Request, The
15 PDSN shall include a Data Available Indication as a CVSE in the A11-Registartion Reply.
16 In the case of PDSN supports fast handoff the PDSN shall include the anchor PDSN IP address in
17 a NVSE in the A11-Registration Reply.
18 If the PCF initiates the setup of the A10 connection due to hard handoff and the PDSN supports
19 Fast handoff, The PCF shall include the anchor PDSN IP address in a NVSE in the A11-
20 Registartion Request.
21 If the selected PDSN does not accept the A10 connection, it shall return an A11-Registration
22 Reply with a reject result code. Upon receipt of this message, the PCF stops timer Tregreq.
23 The PDSN may return an A11-Registration Reply message with result code ‘88H’ (Registration
24 Denied – unknown PDSN address). When code ‘88H’ is used, an alternate PDSN address is
25 included in the A11-Registration Reply message. The address of the alternate proposed PDSN
26 shall be returned in the Home Agent field of the A11-Registration Reply message. Upon receipt of
27 this message, the PCF stops timer Tregreq.
28 On receipt of an A11-Registration Reply with code ‘88H’, the PCF shall either initiate
29 establishment of the A10 connection with the proposed PDSN by sending a new A11-Registration
30 Request message as indicated in this section, or it shall use internal algorithms to select a new
31 PDSN.
32 On receipt of an A11-Registration Reply with another result code, depending on the result code,
33 the PCF may attempt to re-try setting up the A10 connection. If the A10 connection cannot be
34 established, the PCF shall indicate this to the BSC, which shall return a failure indication to the
35 MSC. The MSC shall then release the call.

37 None.
Section 2 12
A.S0017-0v1.0
1 2.2 A10 Connection Operational Procedures

3 This message is sent from the PCF to the PDSN to refresh an A10 connection.

5 The PCF periodically refreshes the A10 connection with the PDSN by sending an A11-
6 Registration Request message before the A10 connection registration Lifetime (Trp) expires, as per
7 procedures specified in [33]. After sending this message, the PCF starts timer Tregreq.

10 Tregreq expires, the PCF may retransmit the A11-Registration Request message. Refreshment of
11 the connection is considered to have failed if no A11-Registration Reply is received after a
12 configurable number of A11-Registration Request retransmissions.
15 When the PDSN receives an A11-Registration Request message with a NVSE element type that
17 Application Sub Type or Application Data), the PDSN shall reject the NVSE element that contains
18 the unrecognizable field and process the rest of the A11-Registration Request message.
19 When the PDSN receives an A11-Registration Request message with a CVSE element type that
21 Application Sub Type or Application Data), the PDSN shall reject the A11-Registartion Request
22 message with the reject error code 8DH (Registration Denied – unsupported Vendor ID or unable
23 to interpret the information).

25 The PDSN sends this message to the PCF to acknowledge a refreshment of an A10 connection.

27 Upon receipt of an A11-Registration Request message with a nonzero ‘lifetime’, the PDSN shall
28 respond with an A11-Registration Reply message with an accept indication, including the
29 refreshed Lifetime timer value (Trp) for the A10 connection. Upon receipt of this message, the
30 PCF stops timer Tregreq.
31 If authentication failed during re-registration, the A10 connection is released at the expiration of
32 the Lifetime timer.
33 If an identification mismatch is detected in the A11-Registration Reply at re-registration, the A10

34 connection is released upon expiration of the Lifetime timer.
Section 2 13
A.S0017-0v1.0
2 None
3 2.3 A10 Connection Release Procedures

4 The release of an A10 connection is controlled by the PCF. For PDSN initiated A10 connection
5 release, the PDSN requests that the PCF release the connection.

7 The PCF may initiate release of the A10 connection by sending an A11-Registration Request
8 message to the PDSN with Lifetime field set to zero.

10 The PCF may initiate release of the A10 connection by sending an A11-Registration Request
11 message to the PDSN with Lifetime field set to zero. The PCF includes accounting related and
12 other information in the A11-Registration Request. For successful operation, the PDSN removes
13 the binding information for the A10 connection and saves the accounting related and other
14 information for further processing.
17 Tregreq expires, the PCF may retransmit the A11-Registration Request message. On failure to
18 receive A11-Registration Reply in response to a configurable number of A11-Registration Request
19 retransmissions, the PCF removes the binding information for the A10 connection.
22 When the PDSN receives an A11-Registration Request with a NVSE element type that contains
24 Type or Application Data), the PDSN shall reject the NVSE element that contains the
25 unrecognizable field and process the rest of the A11-Registration Request message.
26 When the PDSN receives an A11-Registration Request with a CVSE element type that contains
28 Type or Application Data), the PDSN shall reject the A11-Registration Request message with the
29 reject error code 8DH (Registration Denied – unsupported Vendor ID or unable to interpret the
30 information).

32 The PDSN sends this message to the PCF to acknowledge the teardown of an A10 connection.

34 Upon receipt of an A11-Registration Request message with Lifetime field set to zero, the PDSN
35 shall respond with an A11-Registration Reply message with an accept indication. Upon receipt of
Section 2 14
A.S0017-0v1.0
1 this message, the PCF removes binding information for the A10 connection and stops timer
2 Tregreq.
4 None
5 2.3.3. A11-Registation Update

6 The PDSN sends this message to the PCF to initiate release of an A10 connection.

8 The PDSN may initiate release of an A10 connection by sending an A11-Registration Update
9 message to the PCF. The Home Agent field in the A11-Registration Update is the PDSN-Address
10 and the Home Address is set to zero. The PCF Session Identifier and other session specific
11 information are sent within the Session Specific extension. After sending this message, the PDSN
12 starts timer Tregupd.

14 If the PDSN does not receive an A11-Registration Acknowledge message or an A11-Registration
15 Request message (with lifetime equal to ‘0’ and accounting related information included) after a
16 configurable number of retransmissions, or upon receipt of an A11-Registration Acknowledge
17 message with an ‘update denied’ status, the PDSN shall remove all binding information for the
18 A10 connection.
19 2.3. A11-Registration Acknowledge

20 The PCF sends this message to the PDSN to acknowledge receipt of an A11-Registration Update
21 message.

23 Upon receipt of an A11-Registration Update message, the PCF shall send an A11-Registration
24 Acknowledge message. If the PCF accepts the update, it shall send an ‘accept’ indication in the
25 message. Otherwise, the PCF shall indicate an ‘update denied’ status. Upon receipt of this
26 message, the PDSN stops timer Tregupd.
27 For successful operation, the PCF includes accounting related and other information in the
28 Vendor/Organization Specific Extension in the A11-Registration Request message with Lifetime
29 set to zero (0). The PDSN responds with an A11-Registration Reply message with an ‘accept’
30 indication and saves the accounting related information and other information for further
31 processing. At this time, both the PCF and the PDSN remove the binding information for the A10
32 connection.
34 If the PCF sends an A11-Registration Replay indicating ‘registration denied’, the PDSN may send
35 a new A11-Registration Update message a configurable number of times.
Section 2 15
A.S0017-0v1.0
1 2.4 A10 Packet Accounting Procedures

2 The PCF uses the A11-Registration Request message to send accounting related and other
3 information to the PDSN. The accounting related information is accumulated at the PCF and sent
4 to the PDSN on occurrence of pre-defined triggers, which are listed in Table 2.4-1 below. The
5 occurrence of these predefined triggers is fully specified in [26]. The A10 connection binding
6 information at the PDSN and the PCF may also be updated appropriately depending on the setting
7 of the Lifetime field.
8 Table 2.4-1 - Accounting Records Generated By The PCF
Airlink Accounting Records Generated By The PCF

Record Type
(Y1)
Y1=1 Connection Setup: Setup of A10 connection initiated
Y1=2 Active Start: Mobile comes on the traffic channel(s).
Y1=3 Active Stop: Mobile has stopped use of traffic channel(s).
Y1=4 A forward or reverse short data burst (SDB) was exchanged
with the mobile
9 If any airlink parameters for an active session change, the PCF generates an “Active Stop (Y1=3)”
10 accounting record followed by an “Active Start (Y1=2)” accounting record. For successful
11 operation, the PDSN saves the accounting related and other information for further processing,
12 and responds with an A11-Registration Reply message with an accept indication.
13 The Airlink Record information is transferred from the PCF to the PDSN, as RADUIS protocol
14 encoded attributes, in the Application Data field of the CVSE element. If the PDSN does not
15 receive a RADIUS attribute that is expected, the PDSN shall reject the A11-Registration Request
16 message and the associated A11-Registration Reply shall contain the Code ‘8DH’ (Registration
17 Denied – unsupported Vendor ID or unable to interpret data in a CVSE.)
18 2.4.1 A10 Connection Setup Airlink Record

19 The A10 Connection Setup Airlink record shall be included in the A11-Registration Request
20 message at the time of establishment of a new A10 connection. It is also included in this message
21 thief an A10 connection is pre-setup during fast handoff operation.
22 2.4.2 Active-Start Airlink Record

23 The Active-Start Airlink record shall be included in the A11-Registration Request message under
24 the following circumstances:
25 1. When a traffic channel is assigned to a packet data session: during initial call setup, on
26 transition from dormant to active state or during handoff. The Active-Start Airlink record may
27 follow the connection Setup Airlink record in the same A11-Registration Request message
28 (assuming that all the parameters required in the Active-Start Airlink record are made
29 available at the PCF at the time the message is sent).
30 2. Following an Active-Stop Airlink record when any of the parameters (QoS, User Zone,
31 Forward/Reverse Mux Option) currently defined in the Active Start Airlink Record are
32 changed. The Active Start Airlink Record shall contain the new set of parameters.
Section 2 16
A.S0017-0v1.0
1 2.4.3 Active-Stop Airlink Record

2 The Active Stop Airlink Record shall be included in A11-Registration Request message under the
3 following circumstances:
4 1. When the traffic channel assigned to the packet data session is released.
5 2. When any of the parameters (QoS, User Zone, Forward/Reverse Mux Option) currently
6 defined in the Active Start Airlink Record are changed. The Active Stop Airlink Record shall
7 be sent and followed by an Active Start Airlink Record that shall contain the new set of
8 parameters.
9 2.4.4 SDB Airlink Record

10 The SDB Airlink Record is used by the PCF to report to the PDSN the transfer of Short Data Burst
11 information from and to the user.
12 The PCF should be notified when a successful SDB is delivered to the MS or successfully
13 received by the BSC.
14 2.4.5 Accounting at Re-registration

15 Reception by the PCF of new accounting information shall trigger an A11-Registration Request
16 message to transfer this accounting information to the PDSN.
17 2.4.6 Sequence Numbers

18 All the airlink records include a sequence number initialized to i=zero at A10 connection setup for
19 each identification triplet (PCF session ID, MSID, PCF ID). The PCF shall increment the
20 sequence number (modulo 256) and insert it in the subsequent airlink record transmitted during
21 the lifetime of the PCF session ID. If the sequence number is equal to 255, and the PCF needs to
22 send a subsequent airlink record on the same PCF session, the PCF should set the sequence
23 number to i+1 modulo 256 in the next airlink record.
24 In the event of retransmission of the Air Link Record, the PCF shall retransmit with the same
25 sequence number.
26 2.4.7 Accounting update due to parameter changes

27 During an active connection, if any of the following parameters are changed:
28 • User Zone
29 • Quality of Service
30 • Forward/Reverse Mux Option
31 The PCF shall notify the PSDN using the A11-Registartion Request message containing an
32 “Active Stop” and an “Active Start” Airlink Record with the new set of parameters.
Section 2 17
A.S0017-0v1.0
1 2.5 Mobile IP Based Tunneling Protocol
2 2.5.1 Mobile IP Extensions

3 This section describes extensions to the Mobile IP protocol for the Aquater interface within the
4 TIA/EIA/IS-2000 network.
5 2.5.1.1 Registration Request

6 In a cdma2000 network, the Mobile Station initiates a connection by sending a call setup
7 indication to the BS/PCF across the radio network. When this indication is received by a BS/PCF,
8 a Registration Request will be sent from the BS/PCF to the PDSN to setup a new A10 connection.
9 The BS/PCF sends a Registration Request with the GRE encapsulation and the reverse tunneling
10 bit set. The Home Address field is set to zero. The Home Agent field will be assigned to the IP
11 address of the PDSN and the Care-of Address field will be assigned to the IP address of the
12 BS/PCF.
13 When a Registration Request is received by a PDSN, the information from the Session Specific
14 Extension will be used to identify a packet data session. When a registration is accepted, a GRE
15 tunnel will be created for this Mobile Station.
16 2.5.1.2 Registration Reply

17 The Registration Reply is sent by a PDSN following the procedure as described in [33]. The Home
18 Address field is the same value as the Home Address field from the corresponding Registration
19 Request message received by the PDSN. The Session Specific Extension shall be included in the
20 message.
21 2.5.1.3 Registration Update/Acknowledge
22 Two new messages are defined to support PDSN initiated A10/A11 connection tear down and to
23 speed up resource reclamation on the BS/PCF.
24 The Registration Update message is used for notification of the change of the registration
25 associated with a call. It shall be sent by the PDSN to the previous BS/PCF when a BS/PCF to
26 BS/PCF handoff occurs.
27 The Registration Update message uses the Mobile IP well-known port number 699. The
28 Registration Acknowledge message is sent to the source port received from the corresponding
29 Registration Update message. Each control message is transmitted within a UDP datagram.
30 2.5.1.4 Registration Update Authentication Extension

31 The Registration Update Authentication extension is used to authenticate the Registration Update
32 and Registration Acknowledge messages. It has the same format and default algorithm support
33 requirements as the authentication extension defined for the Mobile IP protocol [33], but with a
34 different type (40). The authenticator value is computed from the stream of bytes including the
35 shared secret, the UDP payload, all prior extensions in their entirety, and the type and length of
36 this extension, but not including the authenticator field itself nor the UDP header. The secret used
37 for computing the authenticator field is shared between the BS/PCF and PDSN. This extension is
38 required in both Registration Update and Registration Acknowledge messages.
39
Section 2 18
A.S0017-0v1.0
1 3.0 Message Formats
2 3.1 A11-Registration Request

3 This A11 interface message is sent from the PCF to the PDSN for:
4 ♦ establishing an A10 connection;

5 ♦ periodic re-registration of an A10 connection;
6 ♦ clearing an A10 connection;
7 ♦ passing accounting related information.
Information Element Section Element Direction Type

Reference
A11 Message Type 4.2.1 PCF -> PDSN M
Flags 4.2.2 PCF -> PDSN O R
Lifetime 4.2.3 PCF -> PDSN O 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 O R
Identification 4.2.7 PCF -> PDSN O R
Session Specific Extension 4.2.12 PCF -> PDSN O R
a
Critical Vendor/Organization Specific 4.2.13 PCF -> PDSN O C
Extension(s)
Mobile-Home Authentication Extension 4.2.10 PCF -> PDSN O R
a
Normal Vendor/Organization Specific 4.2.14 PCF -> PDSN O C
Extension
8 a. One or more instances of this element may be included in the A11-
9 Registration Request message.
10
Section 3 19
A.S0017-0v1.0
1 The following table shows the bitmap layout for the A11-Registration Request message.
0 1 2 3 4 5 6 7 Octet
⇒ A11 Message Type = [01H] 1
⇒ Flags = [0AH] 1
(MSB) ⇒ Lifetime = [00 00H to FF FFH] 1
(LSB) 2
(MSB) 1
⇒ Home Address = [00 00 00 00 H] 2
3
(LSB) 4
(MSB) 1
⇒ Home Agent = <any value> 2
3
(LSB) 4
(MSB) 1
⇒ Care-of-Address = <any value> 2
3
(LSB) 4
(MSB) 1
2
3
⇒ Identification = <any value> 4
5
6
7
(LSB) 8
-- Continued on next page --
2
Section 3 20
A.S0017-0v1.0
-- Continued from previous page --

⇒ Session Specific Extension: = [27H] 1
Length = [13H–15H] 2
(MSB) Protocol Type = [ 88 0BH, 88 81H ] 3
(LSB) 4
(MSB) 5
Key = <any value> 6
7
(LSB) 8
Reserved = [00H] 9
Reserved = [0000 00] Session ID Ver = 10
[ ‘00’ (Version 0),
‘01’ (Version 1)]
(MSB) MN Session Reference Id = <any value> 11
(LSB) 12
(MSB) MSID Type = [00 06 H] (IMSI) 13
(LSB) 14
MSID Length = [06-08H] (10-15 digits) 15
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 = [0H, 9H] (BCD) 21-23
{Identity Digit N+1 = [FH] (BCD)}
Else If (Odd/Even Indicator = 0001 (odd))
{Identity Digit N+1 = [0H, 9H] (BCD)}
2
Section 3 21
A.S0017-0v1.0

⇒ Critical Vendor/Organization Specific Extension: Type = [ 26H] 1
Reserved = [0000 0000] 2
(MSB) 3
Length = <variable> (LSB) 4
(MSB) 5
3GPP2 Vendor ID = 00 00 15 9FH 6
7
(LSB) 8
Application Type = [01H, 02H] 9
IF (Application Type = 01H (Accounting) {1:
Application Sub Type = [01 H] 10
(MSB) 11
Application Data (contains accounting information) …
(LSB) k
} Application Type = 01H; ELSE IF (Application Type = 02H (Mobility Event Indicator)) {1:
Application Sub Type = [01H] m
} Application Type = 02H
⇒ Mobile-Home Authentication Extension: Type = [20H] 1

Length = [14 H ] 2
(MSB) 3
SPI = [00 00 01 00H to FF FF FF FF H] 4
5
(LSB) 6
(MSB) 7
8
Authenticator = <any value > (keyed-MD-5 authentication) 9
… …
(LSB) 22
2
Section 3 22
A.S0017-0v1.0

⇒ Normal Vendor/Organization Specific Extension: Type = [ 86H] 1
Length - <variable> 2
(MSB) Reserved = [00 00H] 3
(LSB) 4
(MSB) 5
7
(LSB) 8
Application Type = [04H] n+1
Application Sub Type = [01H] n+2
(MSB) n+3
Application Data (contains PANID and CANID) …
(LSB) q
2
3 3.2 A11-Registration Reply

4 This A11 interface message is sent from the PDSN to the PCF in response to an A11-Registration
5 Request message.

Reference
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 M
Critical Vendor/Organization Specific 4.2.13 PDSN -> PCF Od C
Extension
Mobile-Home Authentication Extension 4.2.10 PDSN -> PCF O R
b,c
Normal Vendor/Organization Specific 4.2.14 PDSN -> PCF O C
Extension
6 a. This element can also be used to identify the IPv4 address of an alternative
7 PDSN.
8 b. One or more instances of this element may be included in the A11-
9 Registration Reply message.
10 c. This element is used to provide “Anchor PDSN IP Address” when PDSN
11 supports fast handoff.
12 d. This element is included of the PDSN has data available
13
Section 3 23
A.S0017-0v1.0
1 The following table shows the bitmap layout for the A11-Registration Reply message.
0 1 2 3 4 5 6 7 Octet
⇒ A11 Message Type = [03H] 1
⇒ Code = 1
[ 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 ]
(MSB) ⇒ Lifetime = [00 00 H to FF FF H] 1
(LSB) 2
(MSB) 1
⇒ Home Address = [00 00 00 00 H] 2
3
(LSB) 4
(MSB) 1
3
(LSB) 4
(MSB) 1
2
3
5
6
7
(LSB) 8
2
Section 3 24
A.S0017-0v1.0

⇒ Session Specific Extension: Type = [27H] 1
Length = [13H – 15H] 2
(MSB) Protocol Type = [ 88 0BH, 88 81H ] 3
(LSB) 4
(MSB) 5
Key = <any value> 6
7
(LSB) 8
Reserved = [00 H] 9
[ ‘00’ (Version 0),
(LSB) 12
(LSB) 14
… … …
⇒ Critical Vendor/Organization Specific Extension: Type = [ 26H] 1
Reserved = [0000 0000] 2
(MSB) 3
Length = 00 06H (LSB) 4
(MSB) 5
7
(LSB) 8
Application Type = [03H] 9
Application Sub Type = [01 H] 10
2
Section 3 25
A.S0017-0v1.0

⇒ Mobile-Home Authentication Extension: Type = [20H] 1
Length = [ 14H ] 2
(MSB) 3
5
(LSB) 6
(MSB) 7
8
… …
(LSB) 22
⇒ Normal Vendor/Organization Specific Extension: Type = [ 86H] 1
Length - <variable> 2
(MSB) Reserved = [0000 0000] 3
Reserved = [0000 0000] (LSB) 4
(MSB) 5
7
(LSB) 8
9
Application data = <any value> …
k
3 3.3 A11-Registration Update

4 This A11 interface message is sent from the PDSN to the PCF to update the status of an A10
5 connection.

Reference
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 M
Registration Update Authentication 4.2.11 PDSN -> PCF M
Extension
6 a. This field is set to zero by the PDSN and ignored by the PCF.
Section 3 26
A.S0017-0v1.0
1 The following table shows the bitmap layout for the A11-Registration Update message.
0 1 2 3 4 5 6 7 Octet
⇒ Message Type = [14H] 1
1
⇒ Reserved = [00 00 00 H] 2
3
(MSB) 1
⇒ Home Address = [00 00 00 00 H] 2
3
(LSB) 4
(MSB) 1
3
(LSB) 4
(MSB) 1
2
3
5
6
7
(LSB) 8
2
Section 3 27
A.S0017-0v1.0

Length = [13H – 15H] 2
(MSB) Protocol Type = [ 88 0BH, 88 81H] 3
(LSB) 4
(MSB) 5
Key = <any value> 6
7
(LSB) 8
Reserved = [00 H] 9
[ ‘00’ (Version 0),
(LSB) 12
(LSB) 14
… … …
ELSE (If Odd/Even Indicator = 0001 (odd))
⇒ Registration Update Authentication Extension: Type = [28H] 1
Length = [14H ] 2
(MSB) 3
5
(LSB) 6
(MSB) 7
8
… …
(LSB) 22
2
Section 3 28
A.S0017-0v1.0
1 3.4 A11-Registration Acknowledge

2 This A11 interface message is sent from the PCF to the PDSN in response to an A11-Registration
3 Update message.

Reference
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 M
Registration Update Authentication 4.2.11 PCF -> PDSN M
Extension
4 a. This field is set to zero by the PCF and ignored by the PDSN.
5 The following table shows the bitmap layout for the A11-Registration Acknowledge message.
0 1 2 3 4 5 6 7 Octet
⇒ Message Type = [15H] 1
⇒ Reserved = [00 00 H] 1
2
⇒ Status = 1
[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) ]
(MSB) 1
⇒ Home Address = [00 00 00 00 H] 2
3
(LSB) 4
(MSB) 1
⇒ Care-of-Address = <any value> 2
3
(LSB) 4
(MSB) 1
2
3
6
Section 3 29
A.S0017-0v1.0

5
6
7
(LSB) 8
Length = [13H – 15H] 2
(MSB) Protocol Type = [ 88 0BH, 88 81H] 3
(LSB) 4
(MSB) 5
Key = <any value> 6
7
(LSB) 8
Reserved = [00 H] 9
[ ‘00’ (Version 0),
(LSB) 12
(LSB) 14
… … …
2
Section 3 30
A.S0017-0v1.0

⇒ Registration Update Authentication Extension: Type = [28H] 1
Length = [14H ] 2
(MSB) 3
5
(LSB) 6
(MSB) 7
8
… …
(LSB) 22
2
3
Section 3 31
A.S0017-0v1.0
1 4.0 Information Element Definitions

2 This section contains the coding of the signaling elements used in the messages defined in Section
3 3.0.
4 The definitions in the following subsections are for informational purposes only. Parameter usage
5 may vary per message in that only a subset of the defined values may be applicable in a particular
6 message. Therefore, the allowed values are specified per message in the subsections of section 3.0.
7 4.1 Generic Information Element Encoding
8 4.1.1 Conventions
9 The following conventions are assumed for the sequence of transmission of bits and bytes:
10 ♦ Each bit position is marked as 0 to 7. Note that for the A10/A11 interface, bit 0 is the
11 most significant bit and is transmitted first.
12 ♦ In a message, octets are identified by number. Octet 1 is transmitted first, then octet 2,
13 etc.
14 For variable length elements, a length indicator is included. This indicates the number of octets
15 following in the element.
16 The definition of whether an information element is mandatory or optional is specified in Section

17 3.0.
18 In all cases of signaling messages on the A11 Interface the Information Element Identifier is
19 included.
20 All spare and reserved bits are set to 0, unless otherwise indicated.
21 For future expansion purposes, some of these information elements have fields within them that
22 have been reserved.
23 The extensions for the A11 interface messages are defined in the TLV (Type-Length-Value)
24 format. The Type field indicates the type of the extension. Length field indicates the length (in
25 octets) of the extension, not including the Type and Length fields. The value field contains the
26 information specific to the Type of the extension.
27 4.1.2 Information Element Identifiers

28 The following tables contain lists of all elements that make up the messages defined in Section
29 3.0. The tables include the Information Element Identifier (IEI) coding which distinguishes one
30 element from another. The tables also include a section and page reference where the element
31 coding can be found.
32 A11 interface information elements, other than the extensions, are position specific, hence do not
33 include the Information Element Identifier (IEI). The A11 interface extensions are, however,
34 identified by a Type field, which distinguishes one extension from the others.
Section 4 33
A.S0017-0v1.0
1 Table 4.1.2-1 A11 Information Element Identifiers Sorted by Name
Element Name Identifier Reference

A11 Message Type None 4.2.1
Care-of-Address None 4.2.6
Code None 4.2.8
Flags None 4.2.2
Home Address None 4.2.4
Home Agent None 4.2.5
Identification None 4.2.7
Lifetime None 4.2.3
Mobile-Home Authentication Extension 20H 4.2.10
Registration Update Authentication Extension 28H 4.2.11
Session Specific Extension 27H 4.2.12
Status None 4.2.9
Normal Vendor/Organization Specific 86H 4.2.14
Extension
Critical Vendor/Organization Specific 26H 4.2.13
Extension
All other values are reserved.
2 Table 4.1.2-2 A11 Information Element Identifiers Sorted by Value
Element Name Identifier Reference

A11 Message Type None 4.2.1
Care-of-Address None 4.2.6
Code None 4.2.8
Flags None 4.2.2
Home Address None 4.2.4
Home Agent None 4.2.5
Identification None 4.2.7
Lifetime None 4.2.3
Status None 4.2.9
Mobile-Home Authentication Extension 20H 4.2.10
Normal Vendor/Organization Specific 86H 4.2.14
Extension
Critical Vendor/Organization Specific 26H 4.2.13
Extension
Session Specific Extension 27H 4.2.12
Registration Update Authentication Extension 28 H 4.2.11
All other values are reserved.
Section 4 34
A.S0017-0v1.0
1 4.1.3 Additional Coding and Interpretation Rules for Information Elements

2 Information elements shall always use the same Information Element Identifier for all occurrences
3 on a specific A11 Interface. Insofar as possible, the same Information Element Identifier shall be
4 used for a given information element when it is used on more than one of the A11 Interface.
5 The order of appearance for each information element which is mandatory or optional in a
6 message is laid down in the definition of the message.
7 Where the description of the information element in this standard contains spare bits, these bits are
8 indicated as being set to ‘0’. In order to allow compatibility with future implementation, messages
9 shall not be rejected simply because a spare bit is set to ‘1’.
10 An optional variable length information element may be present, but empty. For example, a
11 message may contain an information element, the content of which is zero length. This shall be
12 interpreted by the receiver as equivalent to that information element being absent.
13 Some existing elements make use of an extension bit mechanism that allows the size of the
14 information element to be increased. This mechanism consists of the use of the high order bit (bit
15 7) of an octet as an “extension bit.” When an octet within an information element has bit 7 defined
16 as an extension bit, then the value ‘0’ in that bit position indicates that the following octet is an
17 extension of the current octet. When the value is ‘1’, there is no extension.
18 4.1.4 Cross Reference of Information Elements With Messages

19 The following table provides a cross reference between the elements defined in this specification
20 and the messages defined herein.
21 Table 4.1.4-1 Cross Reference of Information Elements With Messages
Information Element Used in These Messages

A11 Message Type 4.2.1 A11-Registration Request 3.1
A11-Registration Reply 3.2
A11-Registration Update 3.3
A11-Registration Acknowledge 3.4
Care-of-Address 4.2.6 A11-Registration Request 3.1
Code 4.2.8 A11-Registration Reply 3.2
Flags 4.2.2 A11-Registration Request 3.1
Home Address 4.2.4 A11-Registration Request 3.1
Home Agent 4.2.5 A11-Registration Request 3.1

22
Section 4 35
A.S0017-0v1.0
1 Table 4.1.4-1 (cont.) Cross Reference of Information Elements With Messages
Identification 4.2.7 A11-Registration Request 3.1

Lifetime 4.2.3 A11-Registration Request 3.1
Mobile-Home Authentication Extension 4.2.10 A11-Registration Request 3.1
Registration Update Authentication 4.2.11 A11-Registration Update 3.3
Extension
Session Specific Extension 4.2.12 A11-Registration Request 3.1
Status 4.2.9 A11-Registration Acknowledge 3.4
Critical Vendor/Organization Specific 4.2.13 A11-Registration Request 3.1
Extension
Normal Vendor/Organization Specific 4.2.14 A11-Registration Request 3.1
Extension
2 4.2 Information Elements
3 4.2.1 A11 Message Type

4 This one octet element identifies the type of the A11 interface message. The structure of the
5 element conforms to as specified in [33], and is shown below.
0 1 2 3 4 5 6 7 Octet
A11 Message Type 1
6 The A11 interface message types are listed in Table 4.2.1-1. These values shall remain
7 coordinated with the values assigned by the IETF for the Mobile IP protocol.
8
Section 4 36
A.S0017-0v1.0
1 Table 4.2.1-1 A11 Interface Message Types

A11 Message Section
A11 Interface Message Name Type Value Reference
A11-Registration Request 01H 3.1
A11-Registration Reply 03H 3.2
A11-Registration Update 14H 3.3
A11-Registration Acknowledge 15H 3.4
2 4.2.2 Flags
3 The structure of this element is as specified in [33], and is shown below. The setting of the Flags
4 bits determines how an A11 interface message is interpreted by the receiving entity, and the
5 characteristics of the A10 connection also.
0 1 2 3 4 5 6 7 Octet
S B D M G V T Reserved 1
6 For the A11-Registration Request message, the Flag bits are set as specified in Table 4.2.2-1.
7 Table 4.2.2-1 Setting of A11-Registration Request Message Flags
7 6 5 4 3 2 1 0 Bit Position
S B D M G V T RES Bit Identifier
0/1 Simultaneous Bindings
0 Broadcast Datagrams
0 Decapsulation by mobile node
0 Minimal Encapsulation
1 GRE Encapsulation
0 V.J. Compression
1 Reverse Tunneling
0 Reserved Bit
8 4.2.3 Lifetime
9 This two octet element indicates the number of seconds remaining before registration for an A10
10 connection is considered expired. The structure of the element conforms to [33] and is shown
11 below.
0 1 2 3 4 5 6 7 Octet
(MSB) Lifetime 1
(LSB) 2
12 4.2.4 Home Address

13 This four octet element identifies the IPv4 address of the entity for which the A10 connection is
14 established. The structure of the element conforms to as specified in [33], and is shown below.
Section 4 37
A.S0017-0v1.0
0 1 2 3 4 5 6 7 Octet
(MSB) 1
Home Address 2
3
(LSB) 4
1 Table 4.2.4-1 shows the setting of the Home Address field for various A11 interface messages.
2 Table 4.2.4-1 Setting of Home Address Field
A11 Interface Message Home Address

A11-Registration Request 00 00 00 00 H
A11-Registration Reply 00 00 00 00 H
A11-Registration Update 00 00 00 00 H
A11-Registration Acknowledge 00 00 00 00 H
3 4.2.5 Home Agent

4 This element identifies the IPv4 address of the PDSN that terminates the A10 connection. The
5 structure of the element conforms to [33] and is shown below.
0 1 2 3 4 5 6 7 Octet
(MSB) 1
Home Agent 2
3
(LSB) 4
6 4.2.6 Care-of-Address
7 This element identifies the IPv4 address of the PCF that terminates the A10 connection. The
0 1 2 3 4 5 6 7 Octet
(MSB) 1
Care-of-Address 2
3
(LSB) 4
9
Section 4 38
A.S0017-0v1.0
1 4.2.7 Identification
2 This element is used by the PCF and the PDSN for matching the A11-Registration Requests with
3 A11-Registration Replies, and A11-Registration Updates with A11-Registration Acknowledge
4 messages. It also protects against replay attacks (section 5.6, [33]). The structure of the element
5 conforms to [33] and is shown below.
0 1 2 3 4 5 6 7 Octet
(MSB) 1
2
Identification 3
4
5
6
7
(LSB) 8
6 4.2.8 Code
7 This element identifies the result of processing an A11-Registration Request message. The
0 1 2 3 4 5 6 7 Octet
Code 1
9 The supported Code values are listed in Table 4.2.8-1.
10 Table 4.2.8-1 A11 Code Values
Hex Decimal Code

Value Value
00H 0 Registration Accepted
80H 128 Registration Denied – reason unspecified
81H 129 Registration Denied – administratively prohibited
82H 130 Registration Denied – insufficient resources
83H 131 Registration Denied – mobile node failed authentication
85H 133 Registration Denied – identification mismatch
86H 134 Registration Denied – poorly formed request
88H 136 Registration Denied – unknown PDSN address
89H 137 Registration Denied – requested reverse tunnel unavailable
8AH 138 Registration Denied – reverse tunnel is mandatory and ‘T’ bit not set
8DH 141 Registration Denied – unsupported Vendor ID or unable to interpret data
in the CVSE
All other values reserved
11
Section 4 39
A.S0017-0v1.0
1 4.2.9 Status
2 This element identifies the result of processing an A11-Registration Update message.
0 1 2 3 4 5 6 7 Octet
Status 1
3 The supported Status values are listed in Table 4.2.9-1.
4 Table 4.2.9-1 A11 Status Values
Hex Decimal A11 Status

Value Value
0 0 Update Accepted
80H 128 Update Denied – reason unspecified
83H 131 Update Denied – sending node failed authentication
85H 133 Update Denied – identification mismatch
86H 134 Update Denied – poorly formed Registration Update
All other values reserved
5 4.2.10 Mobile-Home Authentication Extension

6 This element is present in all A11-Registration Request and A11-Registration Reply messages.
7 This element marks the end of the authenticated data in these messages. The structure of the
8 extension conforms to [33] and is shown below.
0 1 2 3 4 5 6 7 Octet
A11 Element Identifier (Type) 1
Length 2
(MSB) 3
SPI 4
5
(LSB) 6
(MSB) 7
Authenticator …
(LSB) 22
9 Type:
10 20H. (Section 3.5.2, [33])
11 Length:
12 This field is set to 4 plus the number of bytes in the authenticator.
13 SPI:
14 This four octet field is set to the Security Parameter Index, as described
15 in section 1.6, [33].
16 Authenticator:
17 For keyed-MD-5 authentication, the Authenticator field is set to the
18 128-bit “message digest” value obtained by applying the keyed-MD-5
19 algorithm in the “prefix+suffix” mode on the protected fields. See
20 section 3.5.1, [33] for details.
Section 4 40
A.S0017-0v1.0
1 4.2.11 Registration Update Authentication Extension

2 This element is present in all A11-Registration Update and A11-Registration Acknowledge
3 messages. This element marks the end of the authenticated data in these messages.
0 1 2 3 4 5 6 7 Octet
Length 2
(MSB) 3
SPI 4
5
(LSB) 6
(MSB) 7
Authenticator …
(LSB) 22
4 Type:
5 28H
6 Length:
7 This field is set to 4 plus the number of bytes in the authenticator.
8 SPI:
9 This four octet field is set to the Security Parameter Index, as described
10 in section 1.6, [33].
11 Authenticator:
12 For keyed-MD-5 authentication, the Authenticator field is set to the
13 128-bit “message digest” value obtained by applying the keyed-MD-5
14 algorithm in the “prefix+suffix” mode on the protected fields. See
15 section 3.5.1, [33] for details.
16 4.2.12 Session Specific Extension

17 This element is present in all A11-Registration Request, A11-Registration Reply, A11-
18 Registration Update and A11-Registration Acknowledge messages. This element includes the
19 mobile identity and session specific information.
0 1 2 3 4 5 6 7 Octet
Length 2
(MSB) 3
Protocol Type (LSB) 4
(MSB) 5
Key 6
7
(LSB) 8
20
Section 4 41
A.S0017-0v1.0

Reserved 9
Reserved Session ID Ver 10
(MSB) 11
MN Session Reference Id (LSB) 12
(MSB) 13
MSID Type (LSB) 14
MSID Length 15
Identity Digit 1 Odd/Even Indicator 16
Identity Digit 3 Identity Digit 2 17
… … …
Identity Digit N+1 Identity Digit N Variable
2 Type:
3 27H
4 Length:
5 This one octet field indicates the length (in bytes) of the extension,
6 NOT including the Type and Length fields.
7 Protocol Type:
8 This two octet field identifies the type of the link layer protocol
9 /network layer protocol in use at the mobile node. The supported
10 ‘Protocol Type’ values are listed below:
11 Table 4.2.12-1 A11 Protocol Type Values
Protocol Type Value
PPP 88 0BH
Unstructured Byte Stream 88 81H
12 Key:
13 This field indicates to the receiver the value to use in the GRE header
14 Key field when sending traffic frames on the A10 connection.
15 Reserved:
16 This field is not used at present. It is set to zero by the sending entity
17 and ignored by the receiving entity.
18 Session ID Ver:
19 This field is used to negotiate the Session Identifier Version to be used.
20 A one step negotiation is used where the initiating entity (the PCF)
21 indicates the highest version it supports, and the replying entity (the
22 PDSN) indicates the highest version it supports that is less than or
23 equal to the version received from the initiating entity.
24 If the negotiated Session Identifier Version is 0, the replying entity
25 shall send the same Key value received by the initiating entity.
26 If the negotiated Session Identifier Version is 1, the replying entity may
27 select a Key value different from the one received from the initiating
28 entity.
29 Values greater than 1 are reserved.
Section 4 42
A.S0017-0v1.0
1 MN Session ReferenceID:
2 This field is used to differentiate multiple packet data service sessions
3 in the mobile. In the future releases, the MN Session Reference ID shall
4 be passed to the PCF from the mobile on each origination. Note that for
5 this release, only a single session is supported and therefore the MN
6 Session Reference ID is not passed to the PCF, and the PCF should set
7 the value of this element to 1 (one).
8 MSID Type:
9 This field indicates the type of the address used by the mobile node.
10 Note only the least significant bits are shown, all other bits are set to
11 zero.
12 MSID Length:
13 This one octet field identifies the number of octets following the MSID
14 Length field.
15 Odd/Even Indicator:
16 This field is set to ‘0000’ for an even number of identity digits and to
17 ‘0001’ for an odd number of identity digits.
18 Identity Digits:
19 The identity digits are coded as follows:
20 The International Mobile Subscriber Identifier fields are coded using
21 BCD coding format. If the number of identity digits is even then bits 0
22 to 3 of the last octet shall be filled with an end mark coded as ‘1111’.
23 The Broadcast Address is encoded as specified in [25].
24 4.2.13 Critical Vendor/Organization Specific Extension (CVSE)

25 This element may be present in the A11-Registration Request message to convey the accounting
26 information from the PCF to the PDSN. This element may also be present in the A11-Registration
27 Request message to convey the Mobility Event Indicator from the PCF to the PDSN during
28 dormant handoffs and active/hard handoffs. For alternative coding formats see [34].
29 This element may be present in the A11-Registration Reply message to convey the Data Available
30 Indicator (DAI) from the PDSN to the PCF during handoff.
31 This element reflects Application Type and Application Sub-Types supported in IOS v4.0. New
32 Application Type or Application Sub-Types shall be added to the Normal Vendor/Organization
33 Specific Extension (see section 4.2.14). No new functionality shall be added to the CVSE.
34 When used to convey the accounting information, the accounting records are contained within the
35 Application Data field of this element. The accounting records conveyed from the PCF to the
36 PDSN conform to the specifications in [26]. Each application type 01H (Accounting) VSE
37 contains one and only one airlink record. For transmission of multiple airlink records in the same
38 A11-Registration Request message, multiple instances of accounting type VSEs are used.
0 1 2 3 4 5 6 7 Octet
Reserved 2
(MSB) 3
39
Section 4 43
A.S0017-0v1.0

Length (LSB) 4
(MSB) 5
3GPP2 Vendor ID 6
7
(LSB) 8
Application Type 9
Application Sub Type 10
(MSB) 11
12
Application Data …
…
(LSB) k
2 Type:
3 26H
4 Length:
5 This field indicates the number of octets in this element following this
6 field.
7 3GPP2 Vendor ID:
8 00 00 15 9FH
9 Application Type:
10 This field indicates the type of the application, that the extension relates
11 to. The supported values are:
12 Table 4.2.13-1 Vendor/Organization Specific Extension - Application Type
Hex Value Description

01H Accounting
02H Mobility Event Indicator
03H Data Available Indicator
All other values reserved.
13 Application Sub Type:
14 This one octet field indicates the Application sub-type within the
15 Application Type. The supported values are listed in Table 4.2.13-2.
Section 4 44
A.S0017-0v1.0
1 Table 4.2.13-2 Application Sub Type
Application Type Application Sub Type

Application Type HEX Value Application Sub HEX Value
Name Type Name
Accounting 01 H RADIUS 01H
DIAMETER 02H
All other values are reserved
Mobility Event 02H Mobility 01H
Indicator
Data Available 03H Data Ready to Send 01H
Indicator
2 Application Data:
3 For Application Type 01H (Accounting), this field contains the
4 accounting parameters conveyed from the PCF to the PDSN as
5 specified in [26]. Each of the accounting parameters are structured in
6 the format of RADIUS attributes specified in [34] and [35]. This field
7 is used in messages sent from the PCF to the PDSN.
8 For Application Type 02H (Mobility Event Indicator), this field is zero
9 bytes in length. This field is used in messages sent from the PCF to the
10 PDSN.
11 For Application Type 03H (Data Available Indicator), this field is zero
12 bytes in length. This field is used in messages sent from the PDSN to
13 the PCF.
14 For Application Type 01H (Accounting) all 3GPP2 specific Airlink
15 Record Parameters are coded as follows:
1 2 3 4 5 6 7 8 Octet
Type 1
Length 2
(MSB) 3
4
3GPP2 Vendor-Id 5
(LSB) 6
Vendor-Type 7
16
Section 4 45
A.S0017-0v1.0

Vendor-Length 8
MSB 9
10
Vendor-Value (variable number of octets) ...
(LSB) k
2
3 Type:
4 26 H
5 Length:
6 Type (1 octet) + Length (1 octet) + 3GPP2 Vendor Id (4 octets) + {
7 Vendor-Type (1 octet), Vendor-Length (1 octet), Vendor-Value
8 (variable octets) of the 3GPP2 specific parameter comprising the airlink
9 record being coded.}
10 Vendor ID:
11 00 00 15 9F H
12 Vendor Type:
13 Sub-Type value from the Airlink Record table below.
14 Vendor-Length:
15 Vendor-Type (1 octet) + Vendor-Length (1 octet) + Payload Length (in
16 octets) from the Airlink Record table below.
17 For Application Type 01 H (Accounting) all RADIUS specific Airlink Record Parameters are
18 coded as follows:
1 2 3 4 5 6 7 8 Octet
Type 1
Length 2
MSB 3
4
Value (variable number of octets) …
(LSB) k
19 Length:
20 Type (1 octet) + Length (1 octet) + Payload Length (in octets) from the
21 Airlink Record table below.
22 Airlink Record Fields Tables:
23
Section 4 46
A.S0017-0v1.0
1 1. R-P Session Setup Airlink Record (Connection Setup).
Parameter Type Sub- Max. Payload Format

Type Length (octet)
Airlink Record Type = 1 (Setup) 26 40 4 Integer
R-P Session ID 26 41 4 Integer
Airlink Sequence number 26 42 4 Integer
MSID 31 N/A 15 String
Serving PCF 26 9 4 Ip-addr
BSID 26 10 12 String1
ESN 26 48 15 String
2 Active Start Airlink Record.

Type Length (octet)
Airlink record type = 2 (START) 26 40 4 Integer
User Zone 26 11 4 Integer
Forward Mux Option 26 12 4 Integer
Reverse Mux Option 26 13 4 Integer
Forward Fundamental Rate 26 14 4 Integer
Reverse Fundamental Rate 26 15 4 Integer
Service Option 26 16 4 Integer
Forward Traffic Type 26 17 4 Integer
Reverse Traffic Type 26 18 4 Integer
Fundamental Frame Size 26 19 4 Integer
Forward Fundamental RC 26 20 4 Integer
Reverse Fundamental RC 26 21 4 Integer
DCCH Frame Size (0/5/20ms)2 26 50 4 Integer
Airlink Quality of Service (QOS) 26 39 4 Integer
3
1
A number formed from the concatenation of SID+NID+BSC ID, where each item is
encoded using four hexadecimal upper case ASCII characters.
2 DCCH Frame Size was not present in IOS V4.0 and therefore shall be sent in Normal
Vendor/Organization Specific Extension (NVSE).
Section 4 47
A.S0017-0v1.0
1 Active Stop Airlink Record.

Type Length (octet)
Airlink record type = 3 (STOP) 26 40 4 Integer
Active Connection Time in Seconds 46 N/A 4 Integer
3 4. SDB Airlink Record.

Type Length (octet)
Airlink record type = 4 (SDB) 26 40 4 Integer
Mobile Orig./Term. Indicator 26 45 4 Integer
3
SDB Octet Count 26 31/32 4 Integer
4 An example coding of the Active Stop Airlink Record within the critical Vendor/Organization
5 Specific Extension element is illustrated below:
0 1 2 3 4 5 6 7 Octet
A11 Element Identifier = 26H 1
Reserved 2
(MSB) 3
Length = 30 H (LSB) 4
(MSB) 5
3GPP2 Vendor ID = 00 00 15 9F H 6
7
(LSB) 8
Application Type = 01 H 9
Application Sub Type = 01 H 10
6
3
Subtype 31 is for terminating SDB octet count, subtype 32 is for originating SDB
octet count.
Section 4 48
A.S0017-0v1.0

Parameter Name: Airlink Record Type = 3 (Active Stop)
Type = 1A H 11
Length = 0C H 12
(MSB) 13
14
3GPP2 Vendor-Id = 00 00 15 9F H 15
(LSB) 16
Vendor-Type = 28 H 17
Vendor-Length = 06 H 18
MSB 19
20
Vendor-Value = 3 (Active Stop) 21
(LSB) 22
Parameter Name: R-P-Session ID
Type = 1A H 23
Length = 0C H 24
(MSB) 25
26
3GPP2 Vendor-Id = 00 00 15 9F H 27
(LSB) 28
Vendor-Type = 29 H 29
(MSB) 31
32
Vendor-Value = PCF Session Identifier 33
(LSB) 34
2
Section 4 49
A.S0017-0v1.0

Parameter Name: Airlink Sequence Number
Type = 1A H 35
Length = 0C H 36
(MSB) 37
38
3GPP2 Vendor-Id = 00 00 15 9F H 39
(LSB) 40
Vendor-Type = 2A H 41
(MSB) 43
44
Vendor-Value = Sequence Number 45
(LSB) 46
Parameter Name: Active Connection Time
Type = 3A H 47
Length = 06 H 48
(MSB) 49
50
Value = Active Connection Time (in seconds) 51
(LSB) 52
2
3 4.2.14 Normal Vendor/Organization Specific Extension (NVSE)

4 This element may be present in the A11-Registration Request or A11-Registration Reply message
5 to convey information between the PCF and the PDSN. Any new Application Types, Application
6 Sub-Types, and Application Data supported after IOS v4.0 shall be added to this element.
7 This element is used the A11-Registration Request message to convey the Access Network
8 Identifiers (PANID, CANID) to the PDSN.
9
Section 4 50
A.S0017-0v1.0
1 This element may be present in RRP and RRQ message when the PCF establishes the A10
2 connection with the selected PDSN. This information element is vendor specific and if the PCF or
3 the PDSN is not able to interpret it the information element shall be discarded without notification.
4 When used to convey the accounting information, the accounting records are contained within the
5 Application Data field of this element. The accounting records conveyed from the PCF to the
6 PDSN conform to the specifications in [26] (Wireless IP Network Standard). Each application
7 type 01H (Accounting) VSE contains one and only one airlink record. For transmission of
8 multiple airlink records in the same A11-Registration Request message, multiple instances of
9 accounting type VSEs are used.
0 1 2 3 4 5 6 7 Octet
Length 2
(MSB) Reserved 3
(LSB) 4
(MSB) 5
3GPP2 Vendor ID 6
7
(LSB) 8
Application Type 9
Application Sub Type 10
(MSB) 11
12
Application Data …
…
(LSB) k
10 Type:
11 86H
12 Length:
13 This field indicates the number of octets in this element following this
14 field.
15 3GPP2 Vendor ID:
16 00 00 15 9FH.
17 Application Type:
18 This field indicates the type of the application, that the extension relates
19 to. The supported values are:
20 Table 4.2.14-1 Vendor/Organization Specific Extension - Application Type
Hex Value Description

01H Accounting
04H Access Network Identifiers
05H PDSN Identifier
All other values reserved.
Section 4 51
A.S0017-0v1.0
1 Application Sub Type:

2 This one octet field indicates the Application sub-type within the
3 Application Type. The supported values are listed in Table 4.2.14-2.
4 Table 4.2.14-2 Application Sub Type
Application Type Application Sub Type

Application Type HEX Value Application Sub HEX Value
Name Type Name
Accounting 01 H RADIUS 01H
DIAMETER 02H
Access Network 04 H ANID 01H
Identifiers
PDSN Identifier 05H Anchor PDSN IP 01H
Address
5 Application Data:
6 For Application Type 01H (Accounting), this field contains
7 the accounting parameter DCCH Frame Size conveyed from the PCF to
8 the PDSN as specified in [26] (Wireless IP Network Standard). The
9 accounting parameter is structured in the format of RADIUS attributes
10 specified in [34] and [35]. This field is used in messages sent from the
11 PCF to the PDSN.
12 The Airlink Record Parameter is coded as follows:
1 2 3 4 5 6 7 8 Octet
Type 1
Length 2
(MSB) 3
4
3GPP2 Vendor-Id 5
(LSB) 6
Vendor-Type 7
Vendor-Length 8
MSB 9
10
Vendor-Value (variable number of octets) ...

(LSB) k
13 Type: 1A H
Section 4 52
A.S0017-0v1.0
1 Length: Type (1 octet ) + Length (1 octet ) + 3GPP2 Vendor Id (4 octets) + {

2 Vendor-Type (1 octet), Vendor-Length (1 octet), Vendor-Value
3 (variable octets) of the 3GPP2 specific parameter comprising the airlink
4 record being coded.}
5 Vendor ID: 00 00 15 9F H
6 Vendor Type: Sub-Type value from the Airlink Record table below.
7 Vendor-Length: Vendor-Type (1 octet) + Vendor-Length (1 octet) + Payload Length (in
8 octets) from the Airlink Record table below.
9 Airlink Record Fields Tables:
10 Active Start Airlink Record.

11

Type Length (octet)
Airlink record type = 2 (START) 26 40 4 Integer
DCCH Frame Size (0/5/20ms) 4 26 50 4 Integer
12 For Application Type 04H (Access Network Identifiers), this field
13 contains the PANID of the source PCF in octets 11-15 and CANID of
14 the target PCF in octets 16-20. The PANID and CANID are formatted
15 as specified for the Access Network Identifiers element (see [16]) from
16 octet 3-7. If PANID or CANID information is not available, it shall be
17 coded as all zeros. The PANID and CANID information is included
18 only in the first A11-Registration Request message following a
19 handoff.
4 DCCH Frame Size was not present in IOS V4.0 and therefore shall be sent in Normal
Vendor/Organization Specific Extension (NVSE), not in Critical Vendor/Organization
Specific Extension.
Section 4 53
A.S0017-0v1.0
1 5.0 Timer Definitions
2 5.1 Timer Values

3 The following table is in units of seconds unless otherwise noted.
4 Table 5.1-1 Timer Values and Ranges Sorted by Name

Timer Default Range of Section
Name Value Values Granularity Reference
(seconds) (seconds) (seconds)
Tpresetup 10 0-255 1 5.2.4
Tregreq 1 1–5 1 5.2.1
Tregupd 1 1–5 1 5.2.2
Trp 1800 60 – 65,535 60 5.2.3
5 5.2 Timer Definitions
6 5.2.1 Tregreq
7 The PCF timer Tregreq is started when the Registration Request message is sent, and stopped when
8 the Registration Reply message is received.
9 5.2.2 Tregupd
10 The PDSN timer Tregupd is started when the Registration Update message is sent, and stopped
11 when the Registration Acknowledge message is received.
12 5.2.3 Trp
13 This is the A10 connection registration Lifetime timer. This timer is started at the time of
14 establishment of an A10 connection and updated during periodic re-registrations of the A10
15 connection. The A10 connection is cleared on expiration of this timer. A Trp value of “FF FF H”
16 (two octets, all bits set to ‘1’) indicates infinite Lifetime. A value of “00 00 H” (two octets, all bits
17 set to ‘0’) indicates that the A10 connection is to be released.
18 5.2.4 Tpresetup
19 The Tpresetup is a pre-registration Lifetime timer. It has a configurable value such as that it allows
20 sufficient time for air-interface traffic channel handoff to occur between the source and target
21 radio network.
Section 5 55

PCF-PDSN Ios Standard

Uploaded by

Copyright:

Available Formats

You might also like

PCF-PDSN Ios Standard

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PCF-PDSN Ios Standard

Uploaded by

Copyright:

Available Formats

A.S0017-0v1.

Date: November 16, 2001

13 Interoperability Specification (IOS) for CDMA 2000

17 Revision 0 (3G IOSv4.2)

19 (SDO Ballot Version)

1 2.5.1.1 Registration Request ............................................................................................................ 18

3 Table 1.4-1 Element Flow DIRECTION Indication ....................................................................................... 8

1 1.2.1 Telecommunications Industry Association (TIA) / Electronics

3 1.4 Message Body, Coding, and Ordering of Elements

5 Table 1.4-1 Element Flow DIRECTION Indication

2 } label = Number of instances of the bracketed set of fields

8 ••• = Variable length field.

10 1.5 Forward Compatibility Guidelines

33 1.6 Message Definition Guidelines

16 1.7 IOS Upgrade Guidelines

1 2.0 Message Procedures

3 2.1 A10 Connection Establishment Procedures

4 2.1.1 A11-Registration Request

6 2.1.1.1 Successful Operation

27 2.1.1.2 Failure Operation

6 2.1.2 A11-Registation Reply

9 2.1.2.1 Successful Operation

36 2.1.2.2 Failure Operation

1 2.2 A10 Connection Operational Procedures

2 2.2.1 A11-Registration Request

4 2.2.1.1 Successful Operation

8 2.2.1.2 Failure Operation

24 2.2.2 A11-Registation Reply

26 2.2.2.1 Successful Operation

33 If an identification mismatch is detected in the A11-Registration Reply at re-registration, the A10

1 2.2.2.2 Failure Operation

3 2.3 A10 Connection Release Procedures

6 2.3.1 A11-Registration Request

9 2.3.1.1 Successful Operation

15 2.3.1.2 Failure Operation

31 2.3.2 A11-Registation Reply

33 2.3.2.1 Successful Operation

3 2.3.2.2 Failure Operation

5 2.3.3. A11-Registation Update

7 2.3.3.1 Successful Operation

13 2.3.3.2 Failure Operation

19 2.3. A11-Registration Acknowledge

22 2.3.4.1 Successful Operation

33 2.3.4.2 Failure Operation

1 2.4 A10 Packet Accounting Procedures

8 Table 2.4-1 - Accounting Records Generated By The PCF

Airlink Accounting Records Generated By The PCF

18 2.4.1 A10 Connection Setup Airlink Record

22 2.4.2 Active-Start Airlink Record

1 2.4.3 Active-Stop Airlink Record

9 2.4.4 SDB Airlink Record

14 2.4.5 Accounting at Re-registration

17 2.4.6 Sequence Numbers

26 2.4.7 Accounting update due to parameter changes

30 • Forward/Reverse Mux Option

1 2.5 Mobile IP Based Tunneling Protocol

2 2.5.1 Mobile IP Extensions