Pcf-pdsn Ios Standard

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.2 A10 Connection Operational Procedures...................................................................................... 13 26







2.3 A10 Connection Release Procedures ............................................................................................ 14 33







2.3.3. A11-Registation Update........................................................................................................ 15 40



2.3. A11-Registration Acknowledge................................................................................................ 15 43



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


[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


[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


Interfaces – Part 2 Transport, October 2001. Refer also to TIA/EIA-2001.2-B. 25


Interfaces – Part 3 Features, October 2001. Refer also to TIA/EIA-2001.3-B. 27


Interfaces – Part 4 (A1, A2, and A5 Interfaces), October 2001. Refer also to TIA/EIA-29

2001.4-B. 30


Interfaces – Part 5 (A3 and A7 Interfaces), October 2001. Refer also to TIA/EIA-2001.5-32

B. 33


Interfaces – Part 6 (A8 and A9 Interfaces), October 2001. Refer also to TIA/EIA-2001.6-35

B. 36


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


Interfaces – Part 2 Transport, October 2001. Refer also to A.S0012-0. 6


Interfaces – Part 3 Features, October 2001. Refer also to A.S0013-0. 8


Interfaces – Part 4 (A1, A2, and A5 Interfaces), October 2001. Refer also to A.S0014-0. 10


Interfaces – Part 5 (A3 and A7 Interfaces), October 2001. Refer also to A.S0015-0. 12





[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


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


None. 37

A.S0017-0v1.0

Section 2 13

2.2 A10 Connection Operational Procedures 1


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


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



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



When the PDSN receives an A11-Registration Request message with a NVSE element type that 15


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


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


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


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


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


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


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



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



When the PDSN receives an A11-Registration Request with a NVSE element type that contains 22


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


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


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


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


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


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


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


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


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


A.S0017-0v1.0

Section 3 22

1


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


A.S0017-0v1.0

Section 3 23

1


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



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


3

(LSB) 4

(MSB) 1

2 3


5 6 7

(LSB) 8


A.S0017-0v1.0

Section 3 25

1


⇒⇒⇒⇒ Session Specific Extension: Type = [27H] 1

Length = [13H – 15H] 2 (MSB) Protocol Type = [ 88 0BH, 88 81H ] 3

(LSB) 4 (MSB) 5


(LSB) 8 Reserved = [00 H] 9

Reserved = [0000 00] Session ID Ver = [ ‘00’ (Version 0),

‘01’ (Version 1)]

10







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


⇒⇒⇒⇒ Mobile-Home Authentication Extension: Type = [20H] 1

Length = [ 14H ] 2 (MSB) 3


(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



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


3

(LSB) 4

(MSB) 1

2 3


5 6 7

(LSB) 8


A.S0017-0v1.0

Section 3 28

1



Length = [13H – 15H] 2 (MSB) Protocol Type = [ 88 0BH, 88 81H] 3

(LSB) 4 (MSB) 5



Reserved = [0000 00] Session ID Ver = [ ‘00’ (Version 0), ‘01’ (Version 1)]

10





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


⇒⇒⇒⇒ Registration Update Authentication Extension: Type = [28H] 1

Length = [14H ] 2 (MSB) 3


(LSB) 6 (MSB) 7


… …

(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



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


A.S0017-0v1.0

Section 3 30

1



5 6 7

(LSB) 8


Length = [13H – 15H] 2 (MSB) Protocol Type = [ 88 0BH, 88 81H] 3

(LSB) 4 (MSB) 5



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




A.S0017-0v1.0

Section 3 31

1


⇒⇒⇒⇒ Registration Update Authentication Extension: Type = [28H] 1

Length = [14H ] 2 (MSB) 3


(LSB) 6 (MSB) 7


… …

(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


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


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


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


Length 2 (MSB) 3

Protocol Type (LSB) 4 (MSB) 5

Key 6 7

(LSB) 8


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


Reserved 2 (MSB) 3


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



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



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



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


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


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



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

Documents

Pcf-pdsn Ios Standard