pcf-pdsn ios standard
TRANSCRIPT
A.S0017-0v1.0
3GPP2 A.S0017-0
Version 1.0
Date: November 16, 2001
1
2
3
4
5
6
7
8
9
10
11
12
Interoperability Specification (IOS) for CDMA 2000 13
Access Network Interfaces — Part 7 (A10 and A11 14
Interfaces) 15
16
Revision 0 (3G IOSv4.2) 17
18
(SDO Ballot Version) 19
20
21
22
23
24
25
26
© 3GPP2 2001 27
3GPP2 and its Organizational Partners claim copyright in this document and individual 28
Organizational Partners may copyright and issue documents or standards publications in 29
individual Organizational Partner's name based on this document. Requests for reproduction of 30
this document should be directed to the 3GPP2 Secretariat at [email protected]. Requests 31
to reproduce individual Organizational Partner's documents should be directed to that 32
Organizational Partner. See www.3gpp2.org for more information. 33
34
A.S0017-0v1.0
i
Table of Contents 1
2
1.0 Introduction......................................................................................................................................... 5 3
1.1 Overview......................................................................................................................................... 5 4
1.1.1 Purpose.................................................................................................................................... 5 5
1.1.2 Scope....................................................................................................................................... 5 6
1.2 References....................................................................................................................................... 5 7
1.2.1 Telecommunications Industry Association (TIA) / Electronics Industry Association (EIA).. 6 8
1.2.2 3GPP2 ..................................................................................................................................... 6 9
1.2.3 Other ....................................................................................................................................... 6 10
1.3 Terminology.................................................................................................................................... 6 11
1.3.1 Acronyms................................................................................................................................ 6 12
1.3.2 Definitions............................................................................................................................... 7 13
1.4 Message Body, Coding, and Ordering of Elements ........................................................................ 7 14
1.5 Forward Compatibility Guidelines.................................................................................................. 9 15
1.6 Message Definition Guidelines ....................................................................................................... 9 16
1.7 IOS Upgrade Guidelines ............................................................................................................... 10 17
2.0 Message Procedures.......................................................................................................................... 11 18
2.1 A10 Connection Establishment Procedures .................................................................................. 11 19
2.1.1 A11-Registration Request ..................................................................................................... 11 20
2.1.1.1 Successful Operation............................................................................................................ 11 21
2.1.1.2 Failure Operation ................................................................................................................. 11 22
2.1.2 A11-Registation Reply.......................................................................................................... 12 23
2.1.2.1 Successful Operation............................................................................................................ 12 24
2.1.2.2 Failure Operation ................................................................................................................. 12 25
2.2 A10 Connection Operational Procedures...................................................................................... 13 26
2.2.1 A11-Registration Request ..................................................................................................... 13 27
2.2.1.1 Successful Operation............................................................................................................ 13 28
2.2.1.2 Failure Operation ................................................................................................................. 13 29
2.2.2 A11-Registation Reply.......................................................................................................... 13 30
2.2.2.1 Successful Operation............................................................................................................ 13 31
2.2.2.2 Failure Operation ................................................................................................................. 14 32
2.3 A10 Connection Release Procedures ............................................................................................ 14 33
2.3.1 A11-Registration Request ..................................................................................................... 14 34
2.3.1.1 Successful Operation............................................................................................................ 14 35
2.3.1.2 Failure Operation ................................................................................................................. 14 36
2.3.2 A11-Registation Reply.......................................................................................................... 14 37
2.3.2.1 Successful Operation............................................................................................................ 14 38
2.3.2.2 Failure Operation ................................................................................................................. 15 39
2.3.3. A11-Registation Update........................................................................................................ 15 40
2.3.3.1 Successful Operation............................................................................................................ 15 41
2.3.3.2 Failure Operation ................................................................................................................. 15 42
2.3. A11-Registration Acknowledge................................................................................................ 15 43
2.3.4.1 Successful Operation............................................................................................................ 15 44
2.3.4.2 Failure Operation ................................................................................................................. 15 45
2.4 A10 Packet Accounting Procedures.............................................................................................. 16 46
2.4.1 A10 Connection Setup Airlink Record ................................................................................. 16 47
2.4.2 Active-Start Airlink Record .................................................................................................. 16 48
2.4.3 Active-Stop Airlink Record .................................................................................................. 17 49
2.4.4 SDB Airlink Record.............................................................................................................. 17 50
2.4.5 Accounting at Re-registration ............................................................................................... 17 51
2.4.6 Sequence Numbers................................................................................................................ 17 52
2.4.7 Accounting update due to parameter changes....................................................................... 17 53
2.5 Mobile IP Based Tunneling Protocol............................................................................................ 18 54
2.5.1 Mobile IP Extensions ............................................................................................................ 18 55
A.S0017-0v1.0
ii
2.5.1.1 Registration Request ............................................................................................................ 18 1
2.5.1.2 Registration Reply................................................................................................................ 18 2
2.5.1.3 Registration Update/Acknowledge ...................................................................................... 18 3
2.5.1.4 Registration Update Authentication Extension .................................................................... 18 4
3.0 Message Formats .............................................................................................................................. 19 5
3.1 A11-Registration Request ............................................................................................................. 19 6
3.2 A11-Registration Reply ................................................................................................................ 23 7
3.3 A11-Registration Update .............................................................................................................. 26 8
3.4 A11-Registration Acknowledge.................................................................................................... 29 9
4.0 Information Element Definitions ...................................................................................................... 33 10
4.1 Generic Information Element Encoding ....................................................................................... 33 11
4.1.1 Conventions .......................................................................................................................... 33 12
4.1.2 Information Element Identifiers............................................................................................ 33 13
4.1.3 Additional Coding and Interpretation Rules for Information Elements ................................ 35 14
4.1.4 Cross Reference of Information Elements With Messages ................................................... 35 15
4.2 Information Elements.................................................................................................................... 36 16
4.2.1 A11 Message Type................................................................................................................ 36 17
4.2.2 Flags...................................................................................................................................... 37 18
4.2.3 Lifetime................................................................................................................................. 37 19
4.2.4 Home Address....................................................................................................................... 37 20
4.2.5 Home Agent .......................................................................................................................... 38 21
4.2.6 Care-of-Address .................................................................................................................... 38 22
4.2.7 Identification ......................................................................................................................... 39 23
4.2.8 Code ...................................................................................................................................... 39 24
4.2.9 Status..................................................................................................................................... 40 25
4.2.10 Mobile-Home Authentication Extension .............................................................................. 40 26
4.2.11 Registration Update Authentication Extension ..................................................................... 41 27
4.2.12 Session Specific Extension ................................................................................................... 41 28
4.2.13 Critical Vendor/Organization Specific Extension (CVSE) ................................................... 43 29
4.2.14 Normal Vendor/Organization Specific Extension (NVSE)................................................... 50 30
5.0 Timer Definitions.............................................................................................................................. 55 31
5.1 Timer Values................................................................................................................................. 55 32
5.2 Timer Definitions.......................................................................................................................... 55 33
5.2.1 Tregreq ..................................................................................................................................... 55 34
5.2.2 Tregupd..................................................................................................................................... 55 35
5.2.3 Trp.......................................................................................................................................... 55 36
5.2.4 Tpresetup ................................................................................................................................... 55 37
38
39
A.S0017-0v1.0
iii
List of Tables 1
2
Table 1.4-1 Element Flow DIRECTION Indication ....................................................................................... 8 3
Table 2.4-1 - Accounting Records Generated By The PCF......................................................................... 16 4
Table 4.1.2-1 A11 Information Element Identifiers Sorted by Name........................................................... 34 5
Table 4.1.2-2 A11 Information Element Identifiers Sorted by Value........................................................... 34 6
Table 4.1.4-1 Cross Reference of Information Elements With Messages .................................................... 35 7
Table 4.2.1-1 A11 Interface Message Types ................................................................................................ 37 8
Table 4.2.2-1 Setting of A11-Registration Request Message Flags.............................................................. 37 9
Table 4.2.4-1 Setting of Home Address Field............................................................................................... 38 10
Table 4.2.8-1 A11 Code Values.................................................................................................................... 39 11
Table 4.2.9-1 A11 Status Values .................................................................................................................. 40 12
Table 4.2.12-1 A11 Protocol Type Values.................................................................................................... 42 13
Table 4.2.13-1 Vendor/Organization Specific Extension - Application Type .............................................. 44 14
Table 4.2.13-2 Application Sub Type ........................................................................................................... 45 15
Table 4.2.14-1 Vendor/Organization Specific Extension - Application Type .............................................. 51 16
Table 4.2.14-2 Application Sub Type ........................................................................................................... 52 17
Table 5.1-1 Timer Values and Ranges Sorted by Name ............................................................................... 55 18
19
A.S0017-0v1.0
Section 1 5
1.0 Introduction 1
1.1 Overview 2
This document contains the message procedures, bitmaps, information elements, and timers used 3
to define the interfaces for the Aquater Reference Point. 4
1.1.1 Purpose 5
TBD 6
1.1.2 Scope 7
TBD 8
1.2 References 9
[1] TIA/EIA/IS-2000.1-A, Introduction to CDMA 2000 Standards for Spread Spectrum 10
Systems, March 2000. Refer also to 3GPP2 C.S0001-0. 11
[2] TIA/EIA/IS-2000.2-A, Physical Layer Standard for CDMA 2000 Spread Spectrum 12
Systems, March 2000. Refer also to 3GPP2 C.S0002-0. 13
[3] TIA/EIA/IS-2000.3-A, Medium Access Control (MAC) Standard for CDMA 2000 Spread 14
Spectrum Systems, March 2000. Refer also to 3GPP2 C.S0003-0. 15
[4] TIA/EIA/IS-2000.4-A, Signaling Link Access Control (LAC) Standard for CDMA 2000 16
Spread Spectrum Systems, March 2000. Refer also to 3GPP2 C.S0004-0. 17
[5] TIA/EIA/IS-2000.5-A, Upper Layer (Layer 3) Signaling Standard for CDMA 2000 18
Spread Spectrum Systems, March 2000. Refer also to 3GPP2 C.S0005-0. 19
[6] TIA/EIA/IS-2000.6-A, Analog Signaling Standard for CDMA 2000 Spread Spectrum 20
Systems, March 2000. Refer also to 3GPP2 C.S0006-0. 21
[11] A.S0011-0, Interoperability Specification (IOS) for CDMA 2000 Access Network 22
Interfaces – Part 1 Overview, October 2001. Refer also to TIA/EIA-2001.1-B. 23
[12] A.S0012-0, Interoperability Specification (IOS) for CDMA 2000 Access Network 24
Interfaces – Part 2 Transport, October 2001. Refer also to TIA/EIA-2001.2-B. 25
[13] A.S0013-0, Interoperability Specification (IOS) for CDMA 2000 Access Network 26
Interfaces – Part 3 Features, October 2001. Refer also to TIA/EIA-2001.3-B. 27
[14] A.S0014-0, Interoperability Specification (IOS) for CDMA 2000 Access Network 28
Interfaces – Part 4 (A1, A2, and A5 Interfaces), October 2001. Refer also to TIA/EIA-29
2001.4-B. 30
[15] A.S0015-0, Interoperability Specification (IOS) for CDMA 2000 Access Network 31
Interfaces – Part 5 (A3 and A7 Interfaces), October 2001. Refer also to TIA/EIA-2001.5-32
B. 33
[16] A.S0016-0, Interoperability Specification (IOS) for CDMA 2000 Access Network 34
Interfaces – Part 6 (A8 and A9 Interfaces), October 2001. Refer also to TIA/EIA-2001.6-35
B. 36
[17] A.S0017-0, Interoperability Specification (IOS) for CDMA 2000 Access Network 37
Interfaces – Part 7 (A10 and A11 Interfaces), October 2001. Refer also to TIA/EIA-38
2001.7-B. 39
A.S0017-0v1.0
Section 1 6
1.2.1 Telecommunications Industry Association (TIA) / Electronics 1
Industry Association (EIA) 2
[18] TIA/EIA-2001.1-B, Interoperability Specification (IOS) for CDMA 2000 Access Network 3
Interfaces – Part 1 Overview, October 2001. Refer also to A.S0011-0. 4
[19] TIA/EIA-2001.2-B, Interoperability Specification (IOS) for CDMA 2000 Access Network 5
Interfaces – Part 2 Transport, October 2001. Refer also to A.S0012-0. 6
[20] TIA/EIA-2001.3-B, Interoperability Specification (IOS) for CDMA 2000 Access Network 7
Interfaces – Part 3 Features, October 2001. Refer also to A.S0013-0. 8
[21] TIA/EIA-2001.4-B, Interoperability Specification (IOS) for CDMA 2000 Access Network 9
Interfaces – Part 4 (A1, A2, and A5 Interfaces), October 2001. Refer also to A.S0014-0. 10
[22] TIA/EIA-2001.5-B, Interoperability Specification (IOS) for CDMA 2000 Access Network 11
Interfaces – Part 5 (A3 and A7 Interfaces), October 2001. Refer also to A.S0015-0. 12
[23] TIA/EIA-2001.6-B, Interoperability Specification (IOS) for CDMA 2000 Access Network 13
Interfaces – Part 6 (A8 and A9 Interfaces), October 2001. Refer also to A.S0016-0. 14
[24] TIA/EIA-2001.7-B, Interoperability Specification (IOS) for CDMA 2000 Access Network 15
Interfaces – Part 7 (A10 and A11 Interfaces), October 2001. Refer also to A.S0017-0. 16
[25] TIA/EIA/IS-637-A, Short Message Service for Spread Spectrum Systems, September, 17
1999. 18
[26] TIA/EIA/IS-835, cdma2000 Wireless IP Network Standard, December 2000. 19
1.2.2 3GPP2 20
[27] 3GPP2 C.S0001-0, Introduction to CDMA 2000 Standards for Spread Spectrum Systems, 21
June 2000. Refer also to TIA/EIA/IS-2000.1-A. 22
[28] 3GPP2 C.S0002-0, Physical Layer Standard for CDMA 2000 Spread Spectrum Systems, 23
June 2000. Refer also to TIA/EIA/IS-2000.2-A. 24
[29] 3GPP2 C.S0003-0, Medium Access Control (MAC) Standard for CDMA 2000 Spread 25
Spectrum Systems, June 2000. Refer also to TIA/EIA/IS-2000.3-A. 26
[30] 3GPP2 C.S0004-0, Signaling Link Access Control (LAC) Standard for CDMA 2000 27
Spread Spectrum Systems, June 2000. Refer also to TIA/EIA/IS-2000.4-A. 28
[31] 3GPP2 C.S0005-0, Upper Layer (Layer 3) Signaling Standard for CDMA 2000 Spread 29
Spectrum Systems, June 2000. Refer also to TIA/EIA/IS-2000.5-A. 30
[32] 3GPP2 C.S0006-0, Analog Signaling Standard for CDMA 2000 Spread Spectrum 31
Systems, June 2000. Refer also to TIA/EIA/IS-2000.6-A. 32
1.2.3 Other 33
[33] Internet Engineering Task Force, RFC 2002 – IP Mobility Support Specification, 1996. 34
[34] Internet Engineering Task Force, RFC 2138 – Remote Authentication Dial In User 35
Services (RADIUS), 1997. 36
[35] Internet Engineering Task Force, RFC 2139 – RADIUS Accounting, 1997. 37
1.3 Terminology 38
1.3.1 Acronyms 39
40
Acronym Meaning 3GPP2 ANID Access Network Identifiers BCD Binary Coded Decimal BS Base Station
A.S0017-0v1.0
Section 1 7
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.3.2 Definitions 1
TBD 2
1.4 Message Body, Coding, and Ordering of Elements 3
For each A11 Interface message there are a number of information elements that are individually 4
defined in section 4.2. Each information element in a given message is tagged with a reference in 5
section 4.2, a direction indication (i.e., some elements within a message are bi-directional and 6
others are not), and a mandatory/optional type (M/O) indicator. Information elements that are 7
marked as optional carry an additional indication of being either required (R) or conditional (C). 8
(See below.) Some information elements are reused in multiple messages. 9
A.S0017-0v1.0
Section 1 8
The DIRECTION indication associated with each message element pertains to the use of that 1
particular message element when used with the particular message (i.e., use of the message 2
element may be different in other messages). The format of the DIRECTION indication is as 3
follows: 4
Table 1.4-1 Element Flow DIRECTION Indication 5
PCF -> PDSN Element flows from the PCF to the PDSN PDSN -> PCF Element flows from the PDSN to the PCF
The inclusion of information elements in each message is specified as follows: 6
M Information elements which are mandatory for the message. 7
O Information elements which are optional for the message. 8
R Required in the message whenever the message is sent. 9
C Conditionally required. The conditions for inclusion of this element is 10
defined in the operation(s) where the message is used (see [13]) and in 11
footnotes associated with the table defining the order of information 12
elements in the message. 13
Information elements which are mandatory for a given message shall be present, and appear in the 14
order shown in the message definitions in this chapter. 15
Information elements which are optional for a given message are included as needed for specific 16
conditions. When included, they shall appear in the order shown in the message definition given in 17
this chapter. 18
An information element can very well be mandatory for some messages and optional for other 19
messages. 20
The bitmap tables in the message subsections of 3.0 are patterned after the format for 21
the information elements of section 4.2 and use the following conventions: 22
⇒ Element Name{<# instances>: 23
= Name of information element. 24
Different elements within a message are separated by 25
double lines. 26
Fields within elements are separated by single lines. 27
Octets are renumbered at the beginning of every 28
element. 29
[<values>] = Set of allowed values. 30
} Element Name The number of instances of an element is 1 by default. 31
If the Element Name{<# instances … }Element 32
Name notation is used, the <# instances> notation 33
indicates: 34
n = exactly n occurrences of the element 35
n+ = n or more occurrences of the element 36
1..n = 1 to n inclusive occurrences of the element 37
label {<# instances>: 38
<octet 1> 39
A.S0017-0v1.0
Section 1 9
<octet m> 1
} label = Number of instances of the bracketed set of fields 2
where <# instances> notation indicates: 3
n = exactly n occurrences of the field 4
n+ = n or more occurrences of the field 5
1..n = 1 to n inclusive occurrences of the field 6
ssss ssss 7
• • • = Variable length field. 8
ssss ssss 9
1.5 Forward Compatibility Guidelines 10
This standard will evolve to accommodate new features and capabilities. To ensure that equipment 11
implemented to one revision level will interoperate with equipment implemented to later revision 12
levels the following guidelines are defined for the processing of messages and for the development 13
of messages in future revisions of this standard. 14
Unexpected signaling information may be received at an entity due to differing revision levels of 15
signaling protocol at different entities within a network: an entity using a more enhanced version 16
of the protocol may send (unless overridden by section 1.8) information to an entity implemented 17
at a lower level of the protocol which is outside the protocol definition supported at that receiving 18
entity. 19
It may happen that an entity receives unrecognized signaling information, i.e., messages, element 20
types or element values. This can typically be caused by the upgrading of the protocol version 21
used by other entities in the network. In these cases the following message processing guidelines 22
are invoked (unless overridden by section 1.8) to ensure predictable network behavior. 23
If the receiving entity is implemented to version 4.0 of the IOS or greater, then the sending entity 24
shall send messages that are correctly formatted for the version of the IOS declared to be 25
implemented by the sending entity, (unless overridden by section 1.8). 26
If the receiving entity is implemented to a CDG IOS version less than 3.1.0, then if the sending 27
entity is at an equal or greater version than the receiver, the sending entity shall format messages 28
according to the version of the protocol implemented at the receiving entity. 29
For example, a CDG IOS version 3.1.0 entity by using the following guidelines (unless overridden 30
by section 1.8) may be capable of ignoring additional new elements or fields within elements sent 31
by an entity implemented to an IOS version higher than 3.1.0. 32
1.6 Message Definition Guidelines 33
1. New messages shall have a Message Type that was never previously used. 34
2. Information Element Identifiers may be reused in future revisions only when: 35
♦ The old use of the element identifier is not used in the new revision, and 36
♦ The new use of the element identifier is used only in new messages which 37
were not defined in previous revisions. 38
A.S0017-0v1.0
Section 1 10
♦ The old use of the element identifier shall be supported within the context 1
of the old messages in which it was used. 2
3. Defined valid values of Information Elements may be changed in future revisions. 3
The new version shall define the error handling when previously valid values are 4
received. 5
4. Octets and bits which are undefined or which are defined as reserved may be used 6
in future revisions. 7
5. The Mandatory/Optional designation of Information Elements within a message 8
shall not change. 9
6. Mandatory Information elements shall be sent in the order specified in section 3.0. 10
7. New optional Information Elements in a message shall be defined after all 11
previously defined optional Information Elements. 12
8. All new Information Elements shall be defined with a length field. 13
9. New information may be added to the end of an existing Information Element, 14
provided that the Information Element is defined with a length field. 15
1.7 IOS Upgrade Guidelines 16
For supporting backward compatibility on the A11 interface: 17
When two nodes communicate on the A1 interface no element shall be sent which is larger or 18
smaller in length, or have values other than expected as per the protocol version of the node 19
running on the lower protocol version. If an information element is sent in a manner that violates 20
the above principle, or if an unexpected or unknown element is sent in the middle of a message, or 21
if an element that was required to be sent for successful message processing as per the protocol 22
revision of the node running at the lower version is not sent, then failure handling may be invoked 23
by the receiving node. If the receiving node determines that failure handling does not need to be 24
applied, then processing may continue with the receiving entity generating any OA&M logs as 25
required. 26
Any new elements may be sent to the node running the lower protocol version if the position of 27
those elements is beyond the end of the elements expected by the lower protocol revision. 28
Elements that were defined at the lower protocol revision but marked as not required and that 29
become used at the higher protocol revision and appear before the end of the elements expected by 30
the lower protocol revision shall not be sent to the node running the lower protocol revision. 31
If both the nodes are running the same protocol version then the above rules still apply. 32
33
A.S0017-0v1.0
Section 2 11
2.0 Message Procedures 1
This section describes message procedures for the A10/A11 interface. 2
2.1 A10 Connection Establishment Procedures 3
2.1.1 A11-Registration Request 4
This message is sent from the PCF to the PDSN to initiate establishment of an A10 connection. 5
2.1.1.1 Successful Operation 6
The PCF initiates setup of an A10 connection by sending an A11-Registration Request message to 7
the PDSN and starts timer Tregreq. The A11-Registration Request message is structured as 8
specified in [33] and contains the extensions specified in this standard. The A11-Registration 9
Request message may be retransmitted a configurable number of times as specified in [33]. 10
If the connection setup request is acceptable, the PDSN updates its binding record for the A10 11
connection by creating an association between the PDSN Session Identifier (PDSN SID) and the 12
IMSI address, PCF-Address and PDSN-Address information. The PSDN SID shall be identical to 13
the PCF Session Identifier (PCF SID), If the either the PCF or the PDSN does not support a 14
Session Identifier Version higher than ‘0’, the PDSN may choose any PDSN SID. 15
The PCF and the PDSN use the PCF-IP-Address and the PDSN-IP-Address returned in the A11-16
Registration Reply message as the A10 connection for the transport of user traffic. The PCF-IP-17
Address and the PDSN-IP-Address form the unique link layer ID for each A10 connection. The 18
PCF and the PDSN maintain an association of the mobile’s IMSI address with the A10 19
connection. 20
If the PCF initiates the setup of the A10 connection due to dormant handoff the PCF shall include 21
a Mobility Event Indicator as CVSE and the CANID and PANID as a NVSE in the A11-22
Registartion Request 23
If the PCF initiates the setup of the A10 connection due to hard handoff with support of Fast 24
handoff, The PCF shall set the flag bit S to ‘1’, include the anchor PDSN IP address in a NVSE 25
and set the ‘lifetime’ to Tpresetup in the A11-Registartion Request 26
2.1.1.2 Failure Operation 27
If the PCF does not receive an A11-Registration Reply message from the PDSN before timer 28
Tregreq expires, the PCF may retransmit the A11-Registration Request message. A connection 29
establishment is considered to have failed if no A11-Registration Reply is received after a 30
configurable number of A11-Registration Request retransmissions. 31
Reliable message delivery mechanisms are used for setting up the A10 connection between the 32
PCF and the PDSN. 33
When the PDSN receives an A11-Registration Request message with a NVSE element that 34
contains unrecognizable information in an element field (Vendor ID, Application Type, 35
Application Sub Type or Application Data), the PDSN shall reject the NVSE element that contains 36
the unrecognizable field and process the rest of the A11-Registration Request message. 37
A.S0017-0v1.0
Section 2 12
When PDSN receives an A11-Registration Request message with a CVSE element that contains 1
unrecognizable information in an element field (Vendor ID, Application Type, Application Sub 2
Type or Application Data), the PDSN shall reject the A11-Registartion Request message with the 3
reject error code 8DH (Registration Denied – unsupported Vendor ID or unable to interpret the 4
information). 5
2.1.2 A11-Registation Reply 6
The PDSN sends this message to the PCF to either establish or refuse establishment of an A10 7
connection. 8
2.1.2.1 Successful Operation 9
Upon receipt of an A11-Registration Request message with a nonzero ‘lifetime’, the PDSN shall 10
respond with an A11-Registration Reply message. If the PDSN accepts the A10 connection, it 11
shall send an ‘accept’ indication in the message. PCF stops timer Tregreq when it receives the A11-12
Registartion Relay. 13
In the case of PDSN has data to send to PCF when it receives an A11-Registartion Request, The 14
PDSN shall include a Data Available Indication as a CVSE in the A11-Registartion Reply. 15
In the case of PDSN supports fast handoff the PDSN shall include the anchor PDSN IP address in 16
a NVSE in the A11-Registration Reply. 17
If the PCF initiates the setup of the A10 connection due to hard handoff and the PDSN supports 18
Fast handoff, The PCF shall include the anchor PDSN IP address in a NVSE in the A11-19
Registartion Request. 20
If the selected PDSN does not accept the A10 connection, it shall return an A11-Registration 21
Reply with a reject result code. Upon receipt of this message, the PCF stops timer Tregreq. 22
The PDSN may return an A11-Registration Reply message with result code ‘88H’ (Registration 23
Denied – unknown PDSN address). When code ‘88H’ is used, an alternate PDSN address is 24
included in the A11-Registration Reply message. The address of the alternate proposed PDSN 25
shall be returned in the Home Agent field of the A11-Registration Reply message. Upon receipt of 26
this message, the PCF stops timer Tregreq. 27
On receipt of an A11-Registration Reply with code ‘88H’, the PCF shall either initiate 28
establishment of the A10 connection with the proposed PDSN by sending a new A11-Registration 29
Request message as indicated in this section, or it shall use internal algorithms to select a new 30
PDSN. 31
On receipt of an A11-Registration Reply with another result code, depending on the result code, 32
the PCF may attempt to re-try setting up the A10 connection. If the A10 connection cannot be 33
established, the PCF shall indicate this to the BSC, which shall return a failure indication to the 34
MSC. The MSC shall then release the call. 35
2.1.2.2 Failure Operation 36
None. 37
A.S0017-0v1.0
Section 2 13
2.2 A10 Connection Operational Procedures 1
2.2.1 A11-Registration Request 2
This message is sent from the PCF to the PDSN to refresh an A10 connection. 3
2.2.1.1 Successful Operation 4
The PCF periodically refreshes the A10 connection with the PDSN by sending an A11-5
Registration Request message before the A10 connection registration Lifetime (Trp) expires, as per 6
procedures specified in [33]. After sending this message, the PCF starts timer Tregreq. 7
2.2.1.2 Failure Operation 8
If the PCF does not receive an A11-Registration Reply message from the PDSN before timer 9
Tregreq expires, the PCF may retransmit the A11-Registration Request message. Refreshment of 10
the connection is considered to have failed if no A11-Registration Reply is received after a 11
configurable number of A11-Registration Request retransmissions. 12
Reliable message delivery mechanisms are used for setting up the A10 connection between the 13
PCF and the PDSN. 14
When the PDSN receives an A11-Registration Request message with a NVSE element type that 15
contains unrecognizable information in an element field (Vendor ID, Application Type, 16
Application Sub Type or Application Data), the PDSN shall reject the NVSE element that contains 17
the unrecognizable field and process the rest of the A11-Registration Request message. 18
When the PDSN receives an A11-Registration Request message with a CVSE element type that 19
contains unrecognizable information in an element field (Vendor ID, Application Type, 20
Application Sub Type or Application Data), the PDSN shall reject the A11-Registartion Request 21
message with the reject error code 8DH (Registration Denied – unsupported Vendor ID or unable 22
to interpret the information). 23
2.2.2 A11-Registation Reply 24
The PDSN sends this message to the PCF to acknowledge a refreshment of an A10 connection. 25
2.2.2.1 Successful Operation 26
Upon receipt of an A11-Registration Request message with a nonzero ‘lifetime’, the PDSN shall 27
respond with an A11-Registration Reply message with an accept indication, including the 28
refreshed Lifetime timer value (Trp) for the A10 connection. Upon receipt of this message, the 29
PCF stops timer Tregreq. 30
If authentication failed during re-registration, the A10 connection is released at the expiration of 31
the Lifetime timer. 32
If an identification mismatch is detected in the A11-Registration Reply at re-registration, the A10 33
connection is released upon expiration of the Lifetime timer. 34
A.S0017-0v1.0
Section 2 14
2.2.2.2 Failure Operation 1
None 2
2.3 A10 Connection Release Procedures 3
The release of an A10 connection is controlled by the PCF. For PDSN initiated A10 connection 4
release, the PDSN requests that the PCF release the connection. 5
2.3.1 A11-Registration Request 6
The PCF may initiate release of the A10 connection by sending an A11-Registration Request 7
message to the PDSN with Lifetime field set to zero. 8
2.3.1.1 Successful Operation 9
The PCF may initiate release of the A10 connection by sending an A11-Registration Request 10
message to the PDSN with Lifetime field set to zero. The PCF includes accounting related and 11
other information in the A11-Registration Request. For successful operation, the PDSN removes 12
the binding information for the A10 connection and saves the accounting related and other 13
information for further processing. 14
2.3.1.2 Failure Operation 15
If the PCF does not receive an A11-Registration Reply message from the PDSN before timer 16
Tregreq expires, the PCF may retransmit the A11-Registration Request message. On failure to 17
receive A11-Registration Reply in response to a configurable number of A11-Registration Request 18
retransmissions, the PCF removes the binding information for the A10 connection. 19
Reliable message delivery mechanisms are used for setting up the A10 connection between the 20
PCF and the PDSN. 21
When the PDSN receives an A11-Registration Request with a NVSE element type that contains 22
unrecognizable information in an element field (Vendor ID, Application Type, Application Sub 23
Type or Application Data), the PDSN shall reject the NVSE element that contains the 24
unrecognizable field and process the rest of the A11-Registration Request message. 25
When the PDSN receives an A11-Registration Request with a CVSE element type that contains 26
unrecognizable information in an element field (Vendor ID, Application Type, Application Sub 27
Type or Application Data), the PDSN shall reject the A11-Registration Request message with the 28
reject error code 8DH (Registration Denied – unsupported Vendor ID or unable to interpret the 29
information). 30
2.3.2 A11-Registation Reply 31
The PDSN sends this message to the PCF to acknowledge the teardown of an A10 connection. 32
2.3.2.1 Successful Operation 33
Upon receipt of an A11-Registration Request message with Lifetime field set to zero, the PDSN 34
shall respond with an A11-Registration Reply message with an accept indication. Upon receipt of 35
A.S0017-0v1.0
Section 2 15
this message, the PCF removes binding information for the A10 connection and stops timer 1
Tregreq. 2
2.3.2.2 Failure Operation 3
None 4
2.3.3. A11-Registation Update 5
The PDSN sends this message to the PCF to initiate release of an A10 connection. 6
2.3.3.1 Successful Operation 7
The PDSN may initiate release of an A10 connection by sending an A11-Registration Update 8
message to the PCF. The Home Agent field in the A11-Registration Update is the PDSN-Address 9
and the Home Address is set to zero. The PCF Session Identifier and other session specific 10
information are sent within the Session Specific extension. After sending this message, the PDSN 11
starts timer Tregupd. 12
2.3.3.2 Failure Operation 13
If the PDSN does not receive an A11-Registration Acknowledge message or an A11-Registration 14
Request message (with lifetime equal to ‘0’ and accounting related information included) after a 15
configurable number of retransmissions, or upon receipt of an A11-Registration Acknowledge 16
message with an ‘update denied’ status, the PDSN shall remove all binding information for the 17
A10 connection. 18
2.3. A11-Registration Acknowledge 19
The PCF sends this message to the PDSN to acknowledge receipt of an A11-Registration Update 20
message. 21
2.3.4.1 Successful Operation 22
Upon receipt of an A11-Registration Update message, the PCF shall send an A11-Registration 23
Acknowledge message. If the PCF accepts the update, it shall send an ‘accept’ indication in the 24
message. Otherwise, the PCF shall indicate an ‘update denied’ status. Upon receipt of this 25
message, the PDSN stops timer Tregupd. 26
For successful operation, the PCF includes accounting related and other information in the 27
Vendor/Organization Specific Extension in the A11-Registration Request message with Lifetime 28
set to zero (0). The PDSN responds with an A11-Registration Reply message with an ‘accept’ 29
indication and saves the accounting related information and other information for further 30
processing. At this time, both the PCF and the PDSN remove the binding information for the A10 31
connection. 32
2.3.4.2 Failure Operation 33
If the PCF sends an A11-Registration Replay indicating ‘registration denied’, the PDSN may send 34
a new A11-Registration Update message a configurable number of times. 35
A.S0017-0v1.0
Section 2 16
2.4 A10 Packet Accounting Procedures 1
The PCF uses the A11-Registration Request message to send accounting related and other 2
information to the PDSN. The accounting related information is accumulated at the PCF and sent 3
to the PDSN on occurrence of pre-defined triggers, which are listed in Table 2.4-1 below. The 4
occurrence of these predefined triggers is fully specified in [26]. The A10 connection binding 5
information at the PDSN and the PCF may also be updated appropriately depending on the setting 6
of the Lifetime field. 7
Table 2.4-1 - Accounting Records Generated By The PCF 8
Airlink Record Type
(Y1)
Accounting Records Generated By The PCF
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
If any airlink parameters for an active session change, the PCF generates an “Active Stop (Y1=3)” 9
accounting record followed by an “Active Start (Y1=2)” accounting record. For successful 10
operation, the PDSN saves the accounting related and other information for further processing, 11
and responds with an A11-Registration Reply message with an accept indication. 12
The Airlink Record information is transferred from the PCF to the PDSN, as RADUIS protocol 13
encoded attributes, in the Application Data field of the CVSE element. If the PDSN does not 14
receive a RADIUS attribute that is expected, the PDSN shall reject the A11-Registration Request 15
message and the associated A11-Registration Reply shall contain the Code ‘8DH’ (Registration 16
Denied – unsupported Vendor ID or unable to interpret data in a CVSE.) 17
2.4.1 A10 Connection Setup Airlink Record 18
The A10 Connection Setup Airlink record shall be included in the A11-Registration Request 19
message at the time of establishment of a new A10 connection. It is also included in this message 20
thief an A10 connection is pre-setup during fast handoff operation. 21
2.4.2 Active-Start Airlink Record 22
The Active-Start Airlink record shall be included in the A11-Registration Request message under 23
the following circumstances: 24
1. When a traffic channel is assigned to a packet data session: during initial call setup, on 25
transition from dormant to active state or during handoff. The Active-Start Airlink record may 26
follow the connection Setup Airlink record in the same A11-Registration Request message 27
(assuming that all the parameters required in the Active-Start Airlink record are made 28
available at the PCF at the time the message is sent). 29
2. Following an Active-Stop Airlink record when any of the parameters (QoS, User Zone, 30
Forward/Reverse Mux Option) currently defined in the Active Start Airlink Record are 31
changed. The Active Start Airlink Record shall contain the new set of parameters. 32
A.S0017-0v1.0
Section 2 17
2.4.3 Active-Stop Airlink Record 1
The Active Stop Airlink Record shall be included in A11-Registration Request message under the 2
following circumstances: 3
1. When the traffic channel assigned to the packet data session is released. 4
2. When any of the parameters (QoS, User Zone, Forward/Reverse Mux Option) currently 5
defined in the Active Start Airlink Record are changed. The Active Stop Airlink Record shall 6
be sent and followed by an Active Start Airlink Record that shall contain the new set of 7
parameters. 8
2.4.4 SDB Airlink Record 9
The SDB Airlink Record is used by the PCF to report to the PDSN the transfer of Short Data Burst 10
information from and to the user. 11
The PCF should be notified when a successful SDB is delivered to the MS or successfully 12
received by the BSC. 13
2.4.5 Accounting at Re-registration 14
Reception by the PCF of new accounting information shall trigger an A11-Registration Request 15
message to transfer this accounting information to the PDSN. 16
2.4.6 Sequence Numbers 17
All the airlink records include a sequence number initialized to i=zero at A10 connection setup for 18
each identification triplet (PCF session ID, MSID, PCF ID). The PCF shall increment the 19
sequence number (modulo 256) and insert it in the subsequent airlink record transmitted during 20
the lifetime of the PCF session ID. If the sequence number is equal to 255, and the PCF needs to 21
send a subsequent airlink record on the same PCF session, the PCF should set the sequence 22
number to i+1 modulo 256 in the next airlink record. 23
In the event of retransmission of the Air Link Record, the PCF shall retransmit with the same 24
sequence number. 25
2.4.7 Accounting update due to parameter changes 26
During an active connection, if any of the following parameters are changed: 27
• User Zone 28
• Quality of Service 29
• Forward/Reverse Mux Option 30
The PCF shall notify the PSDN using the A11-Registartion Request message containing an 31
“Active Stop” and an “Active Start” Airlink Record with the new set of parameters. 32
A.S0017-0v1.0
Section 2 18
2.5 Mobile IP Based Tunneling Protocol 1
2.5.1 Mobile IP Extensions 2
This section describes extensions to the Mobile IP protocol for the Aquater interface within the 3
TIA/EIA/IS-2000 network. 4
2.5.1.1 Registration Request 5
In a cdma2000 network, the Mobile Station initiates a connection by sending a call setup 6
indication to the BS/PCF across the radio network. When this indication is received by a BS/PCF, 7
a Registration Request will be sent from the BS/PCF to the PDSN to setup a new A10 connection. 8
The BS/PCF sends a Registration Request with the GRE encapsulation and the reverse tunneling 9
bit set. The Home Address field is set to zero. The Home Agent field will be assigned to the IP 10
address of the PDSN and the Care-of Address field will be assigned to the IP address of the 11
BS/PCF. 12
When a Registration Request is received by a PDSN, the information from the Session Specific 13
Extension will be used to identify a packet data session. When a registration is accepted, a GRE 14
tunnel will be created for this Mobile Station. 15
2.5.1.2 Registration Reply 16
The Registration Reply is sent by a PDSN following the procedure as described in [33]. The Home 17
Address field is the same value as the Home Address field from the corresponding Registration 18
Request message received by the PDSN. The Session Specific Extension shall be included in the 19
message. 20
2.5.1.3 Registration Update/Acknowledge 21
Two new messages are defined to support PDSN initiated A10/A11 connection tear down and to 22
speed up resource reclamation on the BS/PCF. 23
The Registration Update message is used for notification of the change of the registration 24
associated with a call. It shall be sent by the PDSN to the previous BS/PCF when a BS/PCF to 25
BS/PCF handoff occurs. 26
The Registration Update message uses the Mobile IP well-known port number 699. The 27
Registration Acknowledge message is sent to the source port received from the corresponding 28
Registration Update message. Each control message is transmitted within a UDP datagram. 29
2.5.1.4 Registration Update Authentication Extension 30
The Registration Update Authentication extension is used to authenticate the Registration Update 31
and Registration Acknowledge messages. It has the same format and default algorithm support 32
requirements as the authentication extension defined for the Mobile IP protocol [33], but with a 33
different type (40). The authenticator value is computed from the stream of bytes including the 34
shared secret, the UDP payload, all prior extensions in their entirety, and the type and length of 35
this extension, but not including the authenticator field itself nor the UDP header. The secret used 36
for computing the authenticator field is shared between the BS/PCF and PDSN. This extension is 37
required in both Registration Update and Registration Acknowledge messages. 38
39
A.S0017-0v1.0
Section 3 19
3.0 Message Formats 1
3.1 A11-Registration Request 2
This A11 interface message is sent from the PCF to the PDSN for: 3
♦ establishing an A10 connection; 4
♦ periodic re-registration of an A10 connection; 5
♦ clearing an A10 connection; 6
♦ passing accounting related information. 7
Information Element Section Reference
Element Direction Type
A11 Message Type 4.2.1 PCF -> PDSN M Flags 4.2.2 PCF -> PDSN O R Lifetime 4.2.3 PCF -> PDSN 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 Critical Vendor/Organization Specific Extension(s)
4.2.13 PCF -> PDSN Oa C
Mobile-Home Authentication Extension 4.2.10 PCF -> PDSN O R Normal Vendor/Organization Specific Extension
4.2.14 PCF -> PDSN Oa C
a. One or more instances of this element may be included in the A11-8
Registration Request message. 9
10
A.S0017-0v1.0
Section 3 20
The following table shows the bitmap layout for the A11-Registration Request message. 1
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
A.S0017-0v1.0
Section 3 21
1
-- 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 = [ ‘00’ (Version 0),
‘01’ (Version 1)]
10
(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+1 = [FH] (BCD)} Else If (Odd/Even Indicator = 0001 (odd)) {Identity Digit N+1 = [0H, 9H] (BCD)}
Identity Digit N = [0H, 9H] (BCD) 21-23
-- Continued on next page -- 2
A.S0017-0v1.0
Section 3 22
1
-- Continued from previous page --
⇒⇒⇒⇒ 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
-- Continued on next page -- 2
A.S0017-0v1.0
Section 3 23
1
-- Continued from previous page --
⇒⇒⇒⇒ Normal Vendor/Organization Specific Extension: Type = [ 86H] 1
Length - <variable> 2 (MSB) Reserved = [00 00H] 3
(LSB) 4 (MSB) 5
3GPP2 Vendor ID = 00 00 15 9FH 6 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.2 A11-Registration Reply 3
This A11 interface message is sent from the PDSN to the PCF in response to an A11-Registration 4
Request message. 5
Information Element Section Reference
Element Direction Type
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 Extension
4.2.13 PDSN -> PCF Od C
Mobile-Home Authentication Extension 4.2.10 PDSN -> PCF O R Normal Vendor/Organization Specific Extension
4.2.14 PDSN -> PCF Ob,c C
a. This element can also be used to identify the IPv4 address of an alternative 6
PDSN. 7
b. One or more instances of this element may be included in the A11-8
Registration Reply message. 9
c. This element is used to provide “Anchor PDSN IP Address” when PDSN 10
supports fast handoff. 11
d. This element is included of the PDSN has data available 12
13
A.S0017-0v1.0
Section 3 24
The following table shows the bitmap layout for the A11-Registration Reply message. 1
0 1 2 3 4 5 6 7 Octet ⇒⇒⇒⇒ A11 Message Type = [03H] 1
⇒⇒⇒⇒ Code = [ 00H (Registration Accepted),
80H (Registration Denied – reason unspecified) 81H (Registration Denied – administratively prohibited) 82H (Registration Denied – insufficient resources) 83H (Registration Denied – mobile node failed authentication) 85H (Registration Denied – identification mismatch) 86H (Registration Denied – poorly formed request) 88H (Registration Denied – unknown PDSN address) 89H (Registration Denied – requested reverse tunnel unavailable) 8AH (Registration Denied – reverse tunnel is mandatory and ‘T’ bit not set) 8DH (Registration Denied – unsupported vendor ID or unable to interpret data in the
CVSE ]
1
(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
⇒⇒⇒⇒ Home Agent = <any value> 2
3
(LSB) 4
(MSB) 1
2 3
⇒⇒⇒⇒ Identification = <any value> 4
5 6 7
(LSB) 8
-- Continued on next page -- 2
A.S0017-0v1.0
Section 3 25
1
-- Continued from previous page --
⇒⇒⇒⇒ 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
Reserved = [0000 00] Session ID Ver = [ ‘00’ (Version 0),
‘01’ (Version 1)]
10
(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+1 = [FH] (BCD)} Else If (Odd/Even Indicator = 0001 (odd)) {Identity Digit N+1 = [0H, 9H] (BCD)}
Identity Digit N = [0H, 9H] (BCD) 21-23
⇒⇒⇒⇒ Critical Vendor/Organization Specific Extension: Type = [ 26H] 1
Reserved = [0000 0000] 2 (MSB) 3
Length = 00 06H (LSB) 4 (MSB) 5
3GPP2 Vendor ID = 00 00 15 9FH 6 7
(LSB) 8 Application Type = [03H] 9
Application Sub Type = [01 H] 10 -- Continued on next page --
2
A.S0017-0v1.0
Section 3 26
1
-- Continued from previous page --
⇒⇒⇒⇒ Mobile-Home Authentication Extension: Type = [20H] 1
Length = [ 14H ] 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
⇒⇒⇒⇒ Normal Vendor/Organization Specific Extension: Type = [ 86H] 1
Length - <variable> 2 (MSB) Reserved = [0000 0000] 3
Reserved = [0000 0000] (LSB) 4 (MSB) 5
3GPP2 Vendor ID = 00 00 15 9FH 6 7
(LSB) 8
9 Application data = <any value> …
k
2
3.3 A11-Registration Update 3
This A11 interface message is sent from the PDSN to the PCF to update the status of an A10 4
connection. 5
Information Element Section Reference
Element Direction Type
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 Extension
4.2.11 PDSN -> PCF M
a. This field is set to zero by the PDSN and ignored by the PCF. 6
A.S0017-0v1.0
Section 3 27
The following table shows the bitmap layout for the A11-Registration Update message. 1
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
⇒⇒⇒⇒ Home Agent = <any value> 2
3
(LSB) 4
(MSB) 1
2 3
⇒⇒⇒⇒ Identification = <any value> 4
5 6 7
(LSB) 8
-- Continued on next page -- 2
A.S0017-0v1.0
Section 3 28
1
-- Continued from previous page --
⇒⇒⇒⇒ 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
Reserved = [0000 00] Session ID Ver = [ ‘00’ (Version 0), ‘01’ (Version 1)]
10
(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+1 = [FH] (BCD)} ELSE (If Odd/Even Indicator = 0001 (odd)) {Identity Digit N+1 = [0H, 9H] (BCD)}
Identity Digit N = [0H, 9H] (BCD) 21-23
⇒⇒⇒⇒ Registration Update Authentication Extension: Type = [28H] 1
Length = [14H ] 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
A.S0017-0v1.0
Section 3 29
3.4 A11-Registration Acknowledge 1
This A11 interface message is sent from the PCF to the PDSN in response to an A11-Registration 2
Update message. 3
Information Element Section Reference
Element Direction Type
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 Extension
4.2.11 PCF -> PDSN M
a. This field is set to zero by the PCF and ignored by the PDSN. 4
The following table shows the bitmap layout for the A11-Registration Acknowledge message. 5
0 1 2 3 4 5 6 7 Octet ⇒⇒⇒⇒ Message Type = [15H] 1
⇒⇒⇒⇒ Reserved = [00 00 H] 1
2
⇒⇒⇒⇒ Status = [00H (Update Accepted)
80H (Update Denied – reason unspecified) 83H (Update Denied – sending node failed authentication) 85H (Update Denied – identification mismatch) 86H (Update Denied – poorly formed registration update) ]
1
(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
-- Continued on next page -- 6
A.S0017-0v1.0
Section 3 30
1
-- Continued from previous page --
⇒⇒⇒⇒ Identification = <any value> 4
5 6 7
(LSB) 8
⇒⇒⇒⇒ 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
Reserved = [0000 00] Session ID Ver = [ ‘00’ (Version 0), ‘01’ (Version 1)]
10
(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+1 = [FH] (BCD)} Else If (Odd/Even Indicator = 0001 (odd)) {Identity Digit N+1 = [0H, 9H] (BCD)}
Identity Digit N = [0H, 9H] (BCD) 21-23
-- Continued on next page -- 2
A.S0017-0v1.0
Section 3 31
1
-- Continued from previous page --
⇒⇒⇒⇒ Registration Update Authentication Extension: Type = [28H] 1
Length = [14H ] 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
3
A.S0017-0v1.0
Section 4 33
4.0 Information Element Definitions 1
This section contains the coding of the signaling elements used in the messages defined in Section 2
3.0. 3
The definitions in the following subsections are for informational purposes only. Parameter usage 4
may vary per message in that only a subset of the defined values may be applicable in a particular 5
message. Therefore, the allowed values are specified per message in the subsections of section 3.0. 6
4.1 Generic Information Element Encoding 7
4.1.1 Conventions 8
The following conventions are assumed for the sequence of transmission of bits and bytes: 9
♦ Each bit position is marked as 0 to 7. Note that for the A10/A11 interface, bit 0 is the 10
most significant bit and is transmitted first. 11
♦ In a message, octets are identified by number. Octet 1 is transmitted first, then octet 2, 12
etc. 13
For variable length elements, a length indicator is included. This indicates the number of octets 14
following in the element. 15
The definition of whether an information element is mandatory or optional is specified in Section 16
3.0. 17
In all cases of signaling messages on the A11 Interface the Information Element Identifier is 18
included. 19
All spare and reserved bits are set to 0, unless otherwise indicated. 20
For future expansion purposes, some of these information elements have fields within them that 21
have been reserved. 22
The extensions for the A11 interface messages are defined in the TLV (Type-Length-Value) 23
format. The Type field indicates the type of the extension. Length field indicates the length (in 24
octets) of the extension, not including the Type and Length fields. The value field contains the 25
information specific to the Type of the extension. 26
4.1.2 Information Element Identifiers 27
The following tables contain lists of all elements that make up the messages defined in Section 28
3.0. The tables include the Information Element Identifier (IEI) coding which distinguishes one 29
element from another. The tables also include a section and page reference where the element 30
coding can be found. 31
A11 interface information elements, other than the extensions, are position specific, hence do not 32
include the Information Element Identifier (IEI). The A11 interface extensions are, however, 33
identified by a Type field, which distinguishes one extension from the others. 34
A.S0017-0v1.0
Section 4 34
Table 4.1.2-1 A11 Information Element Identifiers Sorted by Name 1
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 Extension
86H 4.2.14
Critical Vendor/Organization Specific Extension
26H 4.2.13
All other values are reserved.
Table 4.1.2-2 A11 Information Element Identifiers Sorted by Value 2
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 Extension
86H 4.2.14
Critical Vendor/Organization Specific Extension
26H 4.2.13
Session Specific Extension 27H 4.2.12 Registration Update Authentication Extension 28 H 4.2.11
All other values are reserved.
3
A.S0017-0v1.0
Section 4 35
4.1.3 Additional Coding and Interpretation Rules for Information Elements 1
Information elements shall always use the same Information Element Identifier for all occurrences 2
on a specific A11 Interface. Insofar as possible, the same Information Element Identifier shall be 3
used for a given information element when it is used on more than one of the A11 Interface. 4
The order of appearance for each information element which is mandatory or optional in a 5
message is laid down in the definition of the message. 6
Where the description of the information element in this standard contains spare bits, these bits are 7
indicated as being set to ‘0’. In order to allow compatibility with future implementation, messages 8
shall not be rejected simply because a spare bit is set to ‘1’. 9
An optional variable length information element may be present, but empty. For example, a 10
message may contain an information element, the content of which is zero length. This shall be 11
interpreted by the receiver as equivalent to that information element being absent. 12
Some existing elements make use of an extension bit mechanism that allows the size of the 13
information element to be increased. This mechanism consists of the use of the high order bit (bit 14
7) of an octet as an “extension bit.” When an octet within an information element has bit 7 defined 15
as an extension bit, then the value ‘0’ in that bit position indicates that the following octet is an 16
extension of the current octet. When the value is ‘1’, there is no extension. 17
4.1.4 Cross Reference of Information Elements With Messages 18
The following table provides a cross reference between the elements defined in this specification 19
and the messages defined herein. 20
Table 4.1.4-1 Cross Reference of Information Elements With Messages 21
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 A11-Registration Acknowledge 3.4 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 A11-Registration Reply 3.2 A11-Registration Update 3.3 A11-Registration Acknowledge 3.4
Home Agent 4.2.5 A11-Registration Request 3.1 A11-Registration Reply 3.2 A11-Registration Update 3.3
22
A.S0017-0v1.0
Section 4 36
Table 4.1.4-1 (cont.) Cross Reference of Information Elements With Messages 1
Identification 4.2.7 A11-Registration Request 3.1 A11-Registration Reply 3.2 A11-Registration Update 3.3 A11-Registration Acknowledge 3.4 Lifetime 4.2.3 A11-Registration Request 3.1 A11-Registration Reply 3.2 Mobile-Home Authentication Extension 4.2.10 A11-Registration Request 3.1 A11-Registration Reply 3.2 Registration Update Authentication Extension
4.2.11 A11-Registration Update 3.3
A11-Registration Acknowledge 3.4 Session Specific Extension 4.2.12 A11-Registration Request 3.1 A11-Registration Reply 3.2 A11-Registration Update 3.3 A11-Registration Acknowledge 3.4 Status 4.2.9 A11-Registration Acknowledge 3.4 Critical Vendor/Organization Specific Extension
4.2.13 A11-Registration Request 3.1
A11-Registration Reply 3.2 Normal Vendor/Organization Specific Extension
4.2.14 A11-Registration Request 3.1
A11-Registration Reply 3.2
4.2 Information Elements 2
4.2.1 A11 Message Type 3
This one octet element identifies the type of the A11 interface message. The structure of the 4
element conforms to as specified in [33], and is shown below. 5
0 1 2 3 4 5 6 7 Octet
A11 Message Type 1
The A11 interface message types are listed in Table 4.2.1-1. These values shall remain 6
coordinated with the values assigned by the IETF for the Mobile IP protocol. 7
8
A.S0017-0v1.0
Section 4 37
Table 4.2.1-1 A11 Interface Message Types 1
A11 Interface Message Name
A11 Message Type Value
Section 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
4.2.2 Flags 2
The structure of this element is as specified in [33], and is shown below. The setting of the Flags 3
bits determines how an A11 interface message is interpreted by the receiving entity, and the 4
characteristics of the A10 connection also. 5
0 1 2 3 4 5 6 7 Octet
S B D M G V T Reserved 1
For the A11-Registration Request message, the Flag bits are set as specified in Table 4.2.2-1. 6
Table 4.2.2-1 Setting of A11-Registration Request Message Flags 7
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
4.2.3 Lifetime 8
This two octet element indicates the number of seconds remaining before registration for an A10 9
connection is considered expired. The structure of the element conforms to [33] and is shown 10
below. 11
0 1 2 3 4 5 6 7 Octet
(MSB) Lifetime 1
(LSB) 2
4.2.4 Home Address 12
This four octet element identifies the IPv4 address of the entity for which the A10 connection is 13
established. The structure of the element conforms to as specified in [33], and is shown below. 14
A.S0017-0v1.0
Section 4 38
0 1 2 3 4 5 6 7 Octet
(MSB) 1 Home Address 2
3 (LSB) 4
Table 4.2.4-1 shows the setting of the Home Address field for various A11 interface messages. 1
Table 4.2.4-1 Setting of Home Address Field 2
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
4.2.5 Home Agent 3
This element identifies the IPv4 address of the PDSN that terminates the A10 connection. The 4
structure of the element conforms to [33] and is shown below. 5
0 1 2 3 4 5 6 7 Octet
(MSB) 1 Home Agent 2
3 (LSB) 4
4.2.6 Care-of-Address 6
This element identifies the IPv4 address of the PCF that terminates the A10 connection. The 7
structure of the element conforms to [33] and is shown below. 8
0 1 2 3 4 5 6 7 Octet
(MSB) 1 Care-of-Address 2
3 (LSB) 4
9
A.S0017-0v1.0
Section 4 39
4.2.7 Identification 1
This element is used by the PCF and the PDSN for matching the A11-Registration Requests with 2
A11-Registration Replies, and A11-Registration Updates with A11-Registration Acknowledge 3
messages. It also protects against replay attacks (section 5.6, [33]). The structure of the element 4
conforms to [33] and is shown below. 5
0 1 2 3 4 5 6 7 Octet
(MSB) 1 2
Identification 3 4 5 6 7
(LSB) 8
4.2.8 Code 6
This element identifies the result of processing an A11-Registration Request message. The 7
structure of the element conforms to [33] and is shown below. 8
0 1 2 3 4 5 6 7 Octet
Code 1
The supported Code values are listed in Table 4.2.8-1. 9
Table 4.2.8-1 A11 Code Values 10
Hex Value
Decimal Value
Code
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
A.S0017-0v1.0
Section 4 40
4.2.9 Status 1
This element identifies the result of processing an A11-Registration Update message. 2
0 1 2 3 4 5 6 7 Octet
Status 1
The supported Status values are listed in Table 4.2.9-1. 3
Table 4.2.9-1 A11 Status Values 4
Hex Value
Decimal Value
A11 Status
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
4.2.10 Mobile-Home Authentication Extension 5
This element is present in all A11-Registration Request and A11-Registration Reply messages. 6
This element marks the end of the authenticated data in these messages. The structure of the 7
extension conforms to [33] and is shown below. 8
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
Type: 9
20H. (Section 3.5.2, [33]) 10
Length: 11
This field is set to 4 plus the number of bytes in the authenticator. 12
SPI: 13
This four octet field is set to the Security Parameter Index, as described 14
in section 1.6, [33]. 15
Authenticator: 16
For keyed-MD-5 authentication, the Authenticator field is set to the 17
128-bit “message digest” value obtained by applying the keyed-MD-5 18
algorithm in the “prefix+suffix” mode on the protected fields. See 19
section 3.5.1, [33] for details. 20
A.S0017-0v1.0
Section 4 41
4.2.11 Registration Update Authentication Extension 1
This element is present in all A11-Registration Update and A11-Registration Acknowledge 2
messages. This element marks the end of the authenticated data in these messages. 3
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
Type: 4
28H 5
Length: 6
This field is set to 4 plus the number of bytes in the authenticator. 7
SPI: 8
This four octet field is set to the Security Parameter Index, as described 9
in section 1.6, [33]. 10
Authenticator: 11
For keyed-MD-5 authentication, the Authenticator field is set to the 12
128-bit “message digest” value obtained by applying the keyed-MD-5 13
algorithm in the “prefix+suffix” mode on the protected fields. See 14
section 3.5.1, [33] for details. 15
4.2.12 Session Specific Extension 16
This element is present in all A11-Registration Request, A11-Registration Reply, A11-17
Registration Update and A11-Registration Acknowledge messages. This element includes the 18
mobile identity and session specific information. 19
0 1 2 3 4 5 6 7 Octet A11 Element Identifier (Type) 1
Length 2 (MSB) 3
Protocol Type (LSB) 4 (MSB) 5
Key 6 7
(LSB) 8
-- Continued on next page -- 20
A.S0017-0v1.0
Section 4 42
1
-- Continued from previous page -- 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
Type: 2
27H 3
Length: 4
This one octet field indicates the length (in bytes) of the extension, 5
NOT including the Type and Length fields. 6
Protocol Type: 7
This two octet field identifies the type of the link layer protocol 8
/network layer protocol in use at the mobile node. The supported 9
‘Protocol Type’ values are listed below: 10
Table 4.2.12-1 A11 Protocol Type Values 11
Protocol Type Value PPP 88 0BH
Unstructured Byte Stream 88 81H Key: 12
This field indicates to the receiver the value to use in the GRE header 13
Key field when sending traffic frames on the A10 connection. 14
Reserved: 15
This field is not used at present. It is set to zero by the sending entity 16
and ignored by the receiving entity. 17
Session ID Ver: 18
This field is used to negotiate the Session Identifier Version to be used. 19
A one step negotiation is used where the initiating entity (the PCF) 20
indicates the highest version it supports, and the replying entity (the 21
PDSN) indicates the highest version it supports that is less than or 22
equal to the version received from the initiating entity. 23
If the negotiated Session Identifier Version is 0, the replying entity 24
shall send the same Key value received by the initiating entity. 25
If the negotiated Session Identifier Version is 1, the replying entity may 26
select a Key value different from the one received from the initiating 27
entity. 28
Values greater than 1 are reserved. 29
A.S0017-0v1.0
Section 4 43
MN Session ReferenceID: 1
This field is used to differentiate multiple packet data service sessions 2
in the mobile. In the future releases, the MN Session Reference ID shall 3
be passed to the PCF from the mobile on each origination. Note that for 4
this release, only a single session is supported and therefore the MN 5
Session Reference ID is not passed to the PCF, and the PCF should set 6
the value of this element to 1 (one). 7
MSID Type: 8
This field indicates the type of the address used by the mobile node. 9
Note only the least significant bits are shown, all other bits are set to 10
zero. 11
MSID Length: 12
This one octet field identifies the number of octets following the MSID 13
Length field. 14
Odd/Even Indicator: 15
This field is set to ‘0000’ for an even number of identity digits and to 16
‘0001’ for an odd number of identity digits. 17
Identity Digits: 18
The identity digits are coded as follows: 19
The International Mobile Subscriber Identifier fields are coded using 20
BCD coding format. If the number of identity digits is even then bits 0 21
to 3 of the last octet shall be filled with an end mark coded as ‘1111’. 22
The Broadcast Address is encoded as specified in [25]. 23
4.2.13 Critical Vendor/Organization Specific Extension (CVSE) 24
This element may be present in the A11-Registration Request message to convey the accounting 25
information from the PCF to the PDSN. This element may also be present in the A11-Registration 26
Request message to convey the Mobility Event Indicator from the PCF to the PDSN during 27
dormant handoffs and active/hard handoffs. For alternative coding formats see [34]. 28
This element may be present in the A11-Registration Reply message to convey the Data Available 29
Indicator (DAI) from the PDSN to the PCF during handoff. 30
This element reflects Application Type and Application Sub-Types supported in IOS v4.0. New 31
Application Type or Application Sub-Types shall be added to the Normal Vendor/Organization 32
Specific Extension (see section 4.2.14). No new functionality shall be added to the CVSE. 33
When used to convey the accounting information, the accounting records are contained within the 34
Application Data field of this element. The accounting records conveyed from the PCF to the 35
PDSN conform to the specifications in [26]. Each application type 01H (Accounting) VSE 36
contains one and only one airlink record. For transmission of multiple airlink records in the same 37
A11-Registration Request message, multiple instances of accounting type VSEs are used. 38
0 1 2 3 4 5 6 7 Octet A11 Element Identifier (Type) 1
Reserved 2 (MSB) 3
-- Continued on next page -- 39
A.S0017-0v1.0
Section 4 44
1
-- Continued from previous page -- 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 Type: 2
26H 3
Length: 4
This field indicates the number of octets in this element following this 5
field. 6
3GPP2 Vendor ID: 7
00 00 15 9FH 8
Application Type: 9
This field indicates the type of the application, that the extension relates 10
to. The supported values are: 11
Table 4.2.13-1 Vendor/Organization Specific Extension - Application Type 12
Hex Value Description 01H Accounting 02H Mobility Event Indicator 03H Data Available Indicator
All other values reserved. Application Sub Type: 13
This one octet field indicates the Application sub-type within the 14
Application Type. The supported values are listed in Table 4.2.13-2. 15
A.S0017-0v1.0
Section 4 45
Table 4.2.13-2 Application Sub Type 1
Application Type Application Sub Type Application Type
Name HEX Value Application Sub
Type Name HEX Value
Accounting 01 H RADIUS 01H DIAMETER 02H All other values are reserved
Mobility Event Indicator
02H Mobility 01H
All other values are reserved Data Available
Indicator 03H Data Ready to Send 01H
All other values are reserved All other values are reserved
Application Data: 2
For Application Type 01H (Accounting), this field contains the 3
accounting parameters conveyed from the PCF to the PDSN as 4
specified in [26]. Each of the accounting parameters are structured in 5
the format of RADIUS attributes specified in [34] and [35]. This field 6
is used in messages sent from the PCF to the PDSN. 7
For Application Type 02H (Mobility Event Indicator), this field is zero 8
bytes in length. This field is used in messages sent from the PCF to the 9
PDSN. 10
For Application Type 03H (Data Available Indicator), this field is zero 11
bytes in length. This field is used in messages sent from the PDSN to 12
the PCF. 13
For Application Type 01H (Accounting) all 3GPP2 specific Airlink 14
Record Parameters are coded as follows: 15
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 -- Continued on next page --
16
A.S0017-0v1.0
Section 4 46
1
-- Continued from previous page -- Vendor-Length 8
MSB 9 10
Vendor-Value (variable number of octets) ... (LSB) k
2
Type: 3
26 H 4
Length: 5
Type (1 octet) + Length (1 octet) + 3GPP2 Vendor Id (4 octets) + { 6
Vendor-Type (1 octet), Vendor-Length (1 octet), Vendor-Value 7
(variable octets) of the 3GPP2 specific parameter comprising the airlink 8
record being coded.} 9
Vendor ID: 10
00 00 15 9F H 11
Vendor Type: 12
Sub-Type value from the Airlink Record table below. 13
Vendor-Length: 14
Vendor-Type (1 octet) + Vendor-Length (1 octet) + Payload Length (in 15
octets) from the Airlink Record table below. 16
For Application Type 01 H (Accounting) all RADIUS specific Airlink Record Parameters are 17
coded as follows: 18
1 2 3 4 5 6 7 8 Octet Type 1
Length 2 MSB 3
4 Value (variable number of octets) …
(LSB) k Length: 19
Type (1 octet) + Length (1 octet) + Payload Length (in octets) from the 20
Airlink Record table below. 21
Airlink Record Fields Tables: 22
23
A.S0017-0v1.0
Section 4 47
1. R-P Session Setup Airlink Record (Connection Setup). 1
Parameter Type Sub-Type
Max. Payload Length (octet)
Format
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
Active Start Airlink Record. 2
Parameter Type Sub-Type
Max. Payload Length (octet)
Format
Airlink record type = 2 (START) 26 40 4 Integer R-P Session ID 26 41 4 Integer
Airlink Sequence number 26 42 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).
A.S0017-0v1.0
Section 4 48
Active Stop Airlink Record. 1
Parameter Type Sub-Type
Max. Payload Length (octet)
Format
Airlink record type = 3 (STOP) 26 40 4 Integer R-P Session ID 26 41 4 Integer
Airlink Sequence number 26 42 4 Integer Active Connection Time in Seconds 46 N/A 4 Integer
2
4. SDB Airlink Record. 3
Parameter Type Sub-Type
Max. Payload Length (octet)
Format
Airlink record type = 4 (SDB) 26 40 4 Integer R-P Session ID 26 41 4 Integer
Airlink Sequence number 26 42 4 Integer Mobile Orig./Term. Indicator 26 45 4 Integer
SDB Octet Count 26 31/323 4 Integer
An example coding of the Active Stop Airlink Record within the critical Vendor/Organization 4
Specific Extension element is illustrated below: 5
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 -- Continued on next page --
6
3 Subtype 31 is for terminating SDB octet count, subtype 32 is for originating SDB octet count.
A.S0017-0v1.0
Section 4 49
1
-- Continued from previous page -- 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 Vendor-Length = 06 H 30
(MSB) 31 32
Vendor-Value = PCF Session Identifier 33 (LSB) 34
-- Continued on next page -- 2
A.S0017-0v1.0
Section 4 50
1
-- Continued from previous page -- 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 Vendor-Length = 06 H 42
(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
4.2.14 Normal Vendor/Organization Specific Extension (NVSE) 3
This element may be present in the A11-Registration Request or A11-Registration Reply message 4
to convey information between the PCF and the PDSN. Any new Application Types, Application 5
Sub-Types, and Application Data supported after IOS v4.0 shall be added to this element. 6
This element is used the A11-Registration Request message to convey the Access Network 7
Identifiers (PANID, CANID) to the PDSN. 8
9
A.S0017-0v1.0
Section 4 51
This element may be present in RRP and RRQ message when the PCF establishes the A10 1
connection with the selected PDSN. This information element is vendor specific and if the PCF or 2
the PDSN is not able to interpret it the information element shall be discarded without notification. 3
When used to convey the accounting information, the accounting records are contained within the 4
Application Data field of this element. The accounting records conveyed from the PCF to the 5
PDSN conform to the specifications in [26] (Wireless IP Network Standard). Each application 6
type 01H (Accounting) VSE contains one and only one airlink record. For transmission of 7
multiple airlink records in the same A11-Registration Request message, multiple instances of 8
accounting type VSEs are used. 9
0 1 2 3 4 5 6 7 Octet A11 Element Identifier (Type) 1
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
Type: 10
86H 11
Length: 12
This field indicates the number of octets in this element following this 13
field. 14
3GPP2 Vendor ID: 15
00 00 15 9FH. 16
Application Type: 17
This field indicates the type of the application, that the extension relates 18
to. The supported values are: 19
Table 4.2.14-1 Vendor/Organization Specific Extension - Application Type 20
Hex Value Description 01H Accounting 04H Access Network Identifiers 05H PDSN Identifier
All other values reserved.
A.S0017-0v1.0
Section 4 52
Application Sub Type: 1
This one octet field indicates the Application sub-type within the 2
Application Type. The supported values are listed in Table 4.2.14-2. 3
Table 4.2.14-2 Application Sub Type 4
Application Type Application Sub Type Application Type
Name HEX Value Application Sub
Type Name HEX Value
RADIUS 01H Accounting 01 H
DIAMETER 02H
All other values are reserved
Access Network Identifiers
04 H ANID 01H
All other values are reserved Anchor PDSN IP
Address 01H PDSN Identifier 05H
All other values are reserved All other values are reserved
Application Data: 5
For Application Type 01H (Accounting), this field contains 6
the accounting parameter DCCH Frame Size conveyed from the PCF to 7
the PDSN as specified in [26] (Wireless IP Network Standard). The 8
accounting parameter is structured in the format of RADIUS attributes 9
specified in [34] and [35]. This field is used in messages sent from the 10
PCF to the PDSN. 11
The Airlink Record Parameter is coded as follows: 12
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
Type: 1A H 13
A.S0017-0v1.0
Section 4 53
Length: Type (1 octet ) + Length (1 octet ) + 3GPP2 Vendor Id (4 octets) + { 1
Vendor-Type (1 octet), Vendor-Length (1 octet), Vendor-Value 2
(variable octets) of the 3GPP2 specific parameter comprising the airlink 3
record being coded.} 4
Vendor ID: 00 00 15 9F H 5
Vendor Type: Sub-Type value from the Airlink Record table below. 6
Vendor-Length: Vendor-Type (1 octet) + Vendor-Length (1 octet) + Payload Length (in 7
octets) from the Airlink Record table below. 8
Airlink Record Fields Tables: 9
Active Start Airlink Record. 10
11
Parameter Type Sub-Type
Max. Payload Length (octet)
Format
Airlink record type = 2 (START) 26 40 4 Integer
DCCH Frame Size (0/5/20ms) 4 26 50 4 Integer
For Application Type 04H (Access Network Identifiers), this field 12
contains the PANID of the source PCF in octets 11-15 and CANID of 13
the target PCF in octets 16-20. The PANID and CANID are formatted 14
as specified for the Access Network Identifiers element (see [16]) from 15
octet 3-7. If PANID or CANID information is not available, it shall be 16
coded as all zeros. The PANID and CANID information is included 17
only in the first A11-Registration Request message following a 18
handoff. 19
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.
A.S0017-0v1.0
Section 5 55
5.0 Timer Definitions 1
5.1 Timer Values 2
The following table is in units of seconds unless otherwise noted. 3
Table 5.1-1 Timer Values and Ranges Sorted by Name 4
Timer Name
Default Value
(seconds)
Range of Values
(seconds)
Granularity
(seconds)
Section Reference
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.2 Timer Definitions 5
5.2.1 Tregreq 6
The PCF timer Tregreq is started when the Registration Request message is sent, and stopped when 7
the Registration Reply message is received. 8
5.2.2 Tregupd 9
The PDSN timer Tregupd is started when the Registration Update message is sent, and stopped 10
when the Registration Acknowledge message is received. 11
5.2.3 Trp 12
This is the A10 connection registration Lifetime timer. This timer is started at the time of 13
establishment of an A10 connection and updated during periodic re-registrations of the A10 14
connection. The A10 connection is cleared on expiration of this timer. A Trp value of “FF FF H” 15
(two octets, all bits set to ‘1’) indicates infinite Lifetime. A value of “00 00 H” (two octets, all bits 16
set to ‘0’) indicates that the A10 connection is to be released. 17
5.2.4 Tpresetup 18
The Tpresetup is a pre-registration Lifetime timer. It has a configurable value such as that it allows 19
sufficient time for air-interface traffic channel handoff to occur between the source and target 20
radio network. 21