P.S0001-B v2.0 041004

1 3GPP2 P.
S0001-B
2 Version 2.0
3 Version Date: September, 2004
5 cdma2000 Wireless IP
6 Network Standard
10
11
12
13
14
COPYRIGHT
3GPP2 and its Organizational Partners claim copyright in this document and individual Organizational
Partners may copyright and issue documents or standards publications in individual Organizational
Partner's name based on this document. Requests for reproduction of this document should be
directed to the 3GPP2 Secretariat at secretariat@3gpp2.org.Requests to reproduce individual
Organizational Partner's documents should be directed to that Organizational Partner. See
www.3gpp2.org for more information.
15
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 Revision History
2
3 Revision Date
4 Rev. 0 Initial Publication November 2002
5 Rev. A Revision A of P.S0001 May 2001
6 Rev. B Version 1 of P.S0001 Revision B September 2002
7 Rev. B v2.0 Version 2 of P.S0001 Revision B September 2004
- ii - 3GPP2
1 CONTENTS
2
3 1 INTRODUCTION...................................................................................................................... 1
4 2 GLOSSARY AND DEFINITION............................................................................................... 2

5 2.1 ACRONYMS ......................................................................................................................... 2
6 2.2 DEFINITIONS........................................................................................................................ 3
7 3 REFERENCES......................................................................................................................... 8
8 3.1 NORMATIVE REFERENCES.................................................................................................... 8
9 3.1.1 IETF ........................................................................................................................... 8
10 3.1.2 3GPP2 ..................................................................................................................... 10
11 3.1.3 TIA............................................................................................................................ 11
12 3.2 ITU-T ............................................................................................................................... 11
13 3.3 INFORMATIVE .................................................................................................................... 11
14 3.3.1 3GPP2 ..................................................................................................................... 11
15 4 PROTOCOL REFERENCE MODELS ................................................................................... 12
16 4.1 NETWORK REFERENCE MODELS ........................................................................................ 12
17 4.2 SIMPLE IP ......................................................................................................................... 13
18 4.3 MOBILE IP......................................................................................................................... 14
19 4.4 RADIUS........................................................................................................................... 18
20 5 SIMPLE IP OPERATION ....................................................................................................... 19
21 5.1 COMMON SERVICE SPECIFICATION ..................................................................................... 19
22 5.1.1 PPP Session ............................................................................................................ 19
23 5.2 PDSN REQUIREMENTS ..................................................................................................... 19
24 5.2.1 PPP Session ............................................................................................................ 19
25 5.2.2 RADIUS Support...................................................................................................... 23
26 5.2.3 Ingress Address Filtering ......................................................................................... 25
27 5.3 RADIUS SERVER REQUIREMENTS ..................................................................................... 25
28 5.4 MS REQUIREMENTS .......................................................................................................... 26
29 5.4.1 PPP Session ............................................................................................................ 26
30 6 MOBILE IPV4 OPERATION .................................................................................................. 30
31 6.1 COMMON SERVICE SPECIFICATION ..................................................................................... 30
32 6.1.1 PPP Session ............................................................................................................ 30
33 6.1.2 Mobile IP .................................................................................................................. 30
34 6.1.3 Dynamic Home Agent and Home Address Assignment.......................................... 30
35 6.2 PDSN REQUIREMENTS ..................................................................................................... 31
36 6.2.1 PPP Session ............................................................................................................ 31
37 6.2.2 MIP Registration ...................................................................................................... 32
38 6.2.3 RADIUS Support...................................................................................................... 34
39 6.2.4 IP Security Support .................................................................................................. 34
40 6.2.5 Ingress Address Filtering ......................................................................................... 36
41 6.3 HOME AGENT REQUIREMENTS ........................................................................................... 37
42 6.3.1 Multiple Registrations .............................................................................................. 37
43 6.3.2 MIP Authentication Support ..................................................................................... 37
44 6.3.3 IPSec Support.......................................................................................................... 38
45 6.3.4 Dynamic Home Agent Assignment .......................................................................... 39
46 6.3.5 DNS Address Assignment ....................................................................................... 39
47 6.4 RADIUS SERVER REQUIREMENTS ..................................................................................... 39
48 6.4.1 Dynamic Home Agent Assignment .......................................................................... 41
49 6.4.2 MN-HA Shared Key Distribution .............................................................................. 41
50 6.4.3 Dynamic Key Distribution Procedure....................................................................... 41
1 6.4.4 DNS Address Assignment ....................................................................................... 41

2 6.5 MOBILE STATION REQUIREMENTS ...................................................................................... 41
3 6.5.1 PPP Session ............................................................................................................ 41
4 6.5.2 MIP Registration ...................................................................................................... 43
5 6.6 DNS SERVER IP ADDRESS NVSE ..................................................................................... 44
6 7 SIMULTANEOUS SERVICE.................................................................................................. 46
7 8 IP REACHABILITY SERVICE ............................................................................................... 47

8 8.1 SIMPLE IP OPERATION ...................................................................................................... 47
9 8.2 MOBILE IP OPERATION ...................................................................................................... 47
10 8.2.1 DNS Update by the Home RADIUS Server............................................................. 47
11 8.2.2 DNS Update by the HA............................................................................................ 48
12 8.3 IPV6 IRS .......................................................................................................................... 48
13 9 MOBILITY MANAGEMENT ................................................................................................... 49
14 9.1 MOBILITY WITHIN RADIO NETWORK .................................................................................... 49
15 9.2 PCF TO PCF HANDOFF..................................................................................................... 49
16 9.3 PDSN TO PDSN HANDOFF ............................................................................................... 49
17 10 QUALITY OF SERVICE ..................................................................................................... 51
18 10.1 MULTIPLE SERVICE INSTANCES ...................................................................................... 52
19 10.1.1 MS Requirements .................................................................................................... 52
20 10.1.2 PDSN Requirements ............................................................................................... 53
21 10.2 QOS FLOW MAPPING AND TREATMENTS ......................................................................... 53
22 10.3 SUBSCRIBER QOS PROFILE ........................................................................................... 53
23 10.3.1 Allowed Differentiated Services Marking ................................................................. 53
24 10.3.2 PDSN-Based R-P Admission Control...................................................................... 54
25 11 ACCOUNTING ................................................................................................................... 55
26 11.1 GENERAL ...................................................................................................................... 55
27 11.1.1 Usage Data Records ............................................................................................... 55
28 11.1.2 Remote Address Accounting ................................................................................... 55
29 11.1.3 Accounting and Fast Handoff .................................................................................. 56
30 11.1.4 Accounting Attribute Notation .................................................................................. 57
31 11.2 AIRLINK RECORDS ......................................................................................................... 57
32 11.2.1 R-P Connection Setup Airlink Record ..................................................................... 58
33 11.2.2 Active Start Airlink Record ....................................................................................... 59
34 11.2.3 Active Stop Airlink Record ....................................................................................... 59
35 11.2.4 SDB Airlink Record .................................................................................................. 59
36 11.3 PDSN USAGE DATA RECORD (UDR) ............................................................................. 60
37 11.4 ACCOUNTING FORMATS.................................................................................................. 62
38 11.5 PDSN PROCEDURES ..................................................................................................... 66
39 11.5.1 R-P Connection Setup Airlink Record Arrives ......................................................... 67
40 11.5.2 Packet Data Service Establishment ........................................................................ 68
41 11.5.3 Packet Data Service Termination ............................................................................ 68
42 11.5.4 User Data Through PDSN ....................................................................................... 69
43 11.5.5 Active Start Airlink Record Arrives........................................................................... 69
44 11.5.6 Active Stop Airlink Record Arrives........................................................................... 70
45 11.5.7 SDB Airlink Record Arrives...................................................................................... 70
46 11.5.8 Interim Record Trigger............................................................................................. 70
47 11.5.9 Stop Record Trigger ................................................................................................ 70
48 11.5.10 Time of Day Timer Expires................................................................................... 71
49 12 P-P INTERFACE ................................................................................................................ 72
50 12.1 ARCHITECTURE .............................................................................................................. 72
- iv - 3GPP2
1 12.2 THE P-P INTERFACE PROTOCOL ..................................................................................... 72

2 12.2.1 Signaling .................................................................................................................. 73
3 12.2.2 Bearer Transport...................................................................................................... 73
4 12.3 P-P HANDOFF ............................................................................................................... 73
5 12.3.1 Active Service Instances.......................................................................................... 74
6 12.3.2 Dormant Service Instances...................................................................................... 75
7 12.4 DETAILED P–P INTERFACE PROCEDURES ....................................................................... 75
8 12.4.1 P-P Connection Establishment ................................................................................ 75
9 12.4.2 P-P Establishment Connection Failure.................................................................... 77
10 12.4.3 P-P Connection – Periodic Re-registration.............................................................. 78
11 12.4.4 P-P Interface Release Procedures .......................................................................... 78
12 12.4.5 P-P Fast Handoff Completion .................................................................................. 79
13 12.5 BICASTING SCENARIOS .................................................................................................. 79
14 12.6 PPP LINK INDICATOR EXTENSION ................................................................................... 82
15 13 RADIO NETWORK REQUIREMENTS .............................................................................. 83
16 13.1 GENERAL ...................................................................................................................... 83
17 13.2 R-P INTERFACE REQUIREMENTS .................................................................................... 83
18 13.3 R-P GENERAL HANDOFF CAPABILITIES ........................................................................... 83
19 ANNEX A: IKE/ISAKMP PAYLOADS .......................................................................................... 85
20 ANNEX B: CERTIFICATES .......................................................................................................... 88
21 ANNEX C: RADIUS ATTRIBUTES .............................................................................................. 90
22 ANNEX D: 3GPP2 VSAS TABLE............................................................................................... 100
23 ANNEX E: INTERIM RADIUS ACCOUNTING ........................................................................... 103

24
25
-v- 3GPP2
1 Figures
2
3 Figure 1 - Reference Model for Simple IP Access ........................................................................ 12
4 Figure 2 - Reference Model for Mobile IP Access......................................................................... 13
5 Figure 3 - Protocol Reference Model for Simple IP Access .......................................................... 14
6 Figure 4 - Protocol Reference Model for Simple IP Access During Fast Handoff ........................ 14
7 Figure 5 - Protocol Reference Model for Mobile IP Control and IKE ............................................ 15
8 Figure 6 - Protocol Reference Model for Mobile IP Bearer Data .................................................. 16
9 Figure 7 - Protocol Reference Model for MIP Control and IKE During Fast Handoff.................... 16
10 Figure 8 - Protocol Reference Model for MIP Bearer Data During Fast Handoff.......................... 17
11 Figure 9 - Protocol Reference Model for Signaling for Fast Handoff ............................................ 17
12 Figure 10 - Protocol Reference Model for User Data for Fast Handoff......................................... 18
13 Figure 11 - RADIUS Protocol Reference Model............................................................................ 18
14 Figure 12- NVSE for DNS server IP address ................................................................................ 45
15 Figure 13 - Graphical Illustration of Multiple Connection Relationships ....................................... 52
16 Figure 14 - Accounting Architecture .............................................................................................. 55
17 Figure 15 - Accounting Architecture With Fast Handoff ................................................................ 57
18 Figure 16 - Intra PDSN Handoff .................................................................................................... 80
19 Figure 17 - Inter PDSN, Beginning of Fast Handoff ...................................................................... 80
20 Figure 18 - Intra PDSN, Continuation of Fast Handoff on Target PDSN ...................................... 81
21 Figure 19 - Inter PDSN Handoff, Continuation of Fast Handoff Between Target PDSNs............. 81
22 Figure 20 - 3GPP2 RADIUS Attribute Format ............................................................................... 90
23
24
- vi - 3GPP2
1 Tables
2
3 Table 1 - Occurrence of RADIUS Attributes for Simple IP ............................................................ 24
4 Table 2 – Home Agent and Home Address Scenarios ................................................................. 30
5 Table 3 – Description of Scenarios ............................................................................................... 31
6 Table 4 – Occurrence of RADIUS Attributes for Mobile IP............................................................ 40
7 Table 5 – MS Registration Scenarios............................................................................................ 43
8 Table 6 – R-P Connection Setup Airlink Fields ............................................................................. 58
9 Table 7 – Active Start Airlink Fields............................................................................................... 59
10 Table 8 – Active Stop Airlink Fields............................................................................................... 59
11 Table 9 – SDB Airlink Fields.......................................................................................................... 59
12 Table 10 – Complete UDR ............................................................................................................ 61
13 Table 11 – Accounting Parameter Attribute RADIUS Definitions.................................................. 65
14
- vii - 3GPP2
1 P.S0001 Revision History

2
Revision Date Comments
0 December Initial Publication
2000
A May 2001 Added specification or clarification for the following items:
• New mechanism for PDSN/HA pre-shared secret distribution for
IKE
• Security status is replaced by IKE Pre-shared Secret Request
attribute
• New counters G15 and G16 for Mobile IP signaling
• Clarifications with respect to counters G1 and G2
• A new indicator in RADIUS stop message to indicate session
still in progress (to avoid release of the IP address)
• Removal of RADIUS accounting fields H1, I2, and I3
• New accounting session to be created when F1, F2 accounting
fields vary
• Non-zero and zero IP address in IP Configuration option in IPCP
is treated as Simple IP by PDSN. Mobile IP is supported with
null IP address configuration option (i.e., not included).
• The Active Time attribute format changed from standard
RADIUS encoding to 3GPP2 specific encoding.
B September This specification has been revised to support the following features:
2002 • Simultaneous multiple service instances concept
introduced.Simultaneous multiple over-the-air service instances,
includes support of PPP in the multiple service instance
environment
• RTP/UDP/IP Header Reduction Schemes
• Differentiated Services QoS Policy
• Fast handoff for data call (i.e., tunneled PPP between PDSNs)
• Dynamic Home Agent allocation with RADIUS
• Optional support for DNS server address auto configuration in
MS
• Always On support
• IP Reachability Service with dynamic DNS update
• Simple IPv6
• Remote address based accounting
B v2.0 September This addendum is provided to correct errors and omissions in the
2004 previously published version of this specification.
Revisions are indicated by change bars located in the left or right
hand margins, and also by specific markings applied to the text.
New text is underlined, as shown below.
This is how new text is identified.
Deleted text is crossed out, as shown below.
This is how deleted text is identified.
A modified figure is marked similarly to modified text. A new figure is
underlined; a deleted figure is crossed out through the middle of the
figure.
The table of contents does not identify revisions to any section
heading, table, or figure.
3
4
- viii - 3GPP2
1 1 Introduction
2 This specification defines requirements for support of wireless packet data networking capability
3 on a third generation wireless system based on cdma2000®1. This specification supports the
4 services and architecture in [1].
5
6 This specification defines the two methods for accessing public networks (Internet) and private
7 networks (intranets): Simple IP and Mobile IP. It describes the required Quality of Service,
8 Security, Mobility Management, and Accounting capabilities needed to support both methods.
9 IETF protocols are widely employed whenever possible to minimize the number of new protocols
10 required and to maximize the utilization of well accepted standards.
11
12 This specification is organized in the following structure:
13
14 • Sections 2 and 3 are the Glossary and Definitions, and References, respectively.
15 • Section 4 describes the protocol reference models for Simple IP, Mobile IP, RADIUS, and
16 the overall wireless packet data network.
17 • Sections 5 and 6 describe Simple IP operation and Mobile IP operation, respectively.
18 • Section 7 describes simultaneous Mobile IP and Simple IP services.
19 • Section 8 describes IP Reachability Service.
20 • Section 9 describes Mobility Management for PCF-PCF handoff, PDSN-PDSN handoff,
21 and PDSN-PDSN Fast Handoff.
22 • Section 10 describes Quality of Service requirements and operation.
23 • Section 11 describes Accounting architecture and parameters.
24 • Sections 12 and 13 describe the P-P Interface, and Radio Network Requirements,
25 respectively.
26
27 In this document, several key words are used to signify the requirements. The key words "shall",
28 "shall not", "should", "should not", and "may" are to be interpreted as described in RFC 2119 and
29 the TIA Engineering Style Manual.
30
1
cdma2000® is the trademark for the technical nomenclature for certain specifications and
standards of the Organizational Partners (OPs) of 3GPP2. Geographically (and as of the date of
publication), cdma2000® is a registered trademark of the Telecommunications Industry
Association (TIA-USA) in the United States.
-1- 3GPP2
1 2 Glossary and Definition
2 2.1 Acronyms
3 AAA Authentication, Authorization, and Accounting
4 ACCM Asynchronous Control Character Map
5 AH Authentication Header
6 AVP Attribute Value Pair
7 BS Base Station
8 CA Certificate Authority
9 CCP Compression Control Protocol
10 CHAP Challenge Handshake Authentication Protocol
11 CoA Care-of address
12 CRL Certificate Revocation List
13 CSRC Contributing Source
14 D-H Diffie-Hellman
15 DN Distinguished Name
16 DNS Domain Name System
17 DSA Digital Signature Algorithm
18 DOI Domain Of Interpretation
19 ESP Encapsulating Security Payload
20 FA Foreign Agent
21 FAC Foreign Agent Challenge
22 GRE Generic Routing Encapsulation
23 HA Home Agent
24 HAAA Home AAA
25 HDLC High-level Data Link Control
26 HLR Home Location Register
27 HRPD High Rate Packet Data
28 IANA Internet Assigned Numbering Authority
29 IETF Internet Engineering Task Force
30 IKE Internet Key Exchange
31 IMSI International Mobile Subscriber Identity
32 IMT-2000 International Mobile Telecommunications - 2000
33 IP Internet Protocol
34 IPv4 Internet Protocol version 4
35 IPv6 Internet Protocol version 6
36 IPCP IP Control Protocol
37 ICMP Internet Control Message Protocol
38 IPv6CP IPv6 Control Protocol
39 IPSec IP Security
40 IRM International Roaming MIN
41 IRS IP Reachability Service
42 ISAKMP Internet Security Association and Key Management Protocol
43 ISP Internet Service Provider
44 LAC Link Access Control
45 LCP Link Control Protocol
46 MAC Medium Access Control
47 MEID Mobile Equipment Identifier
48 MIN Mobile Identification Number
49 MIP Mobile IP
50 MS Mobile Station
51 MSID Mobile Station ID
52 NAI Network Access Identifier
-2- 3GPP2
1 NAS Network Access System

2 NCP Network Control Protocol
3 NID Network ID
4 NVSE Normal Vendor Specific Extension
5 PAP Password Authentication Protocol
6 PCF Packet Control Function
7 PDSN Packet Data Serving Node
8 PHB Per Hop Behavior
9 Pi PDSN – Internet (Interface)
10 PL Physical Layer
11 P-P PDSN-PDSN (Interface)
12 PPP Point-to-Point Protocol
13 PSI PCF Session ID
14 PZID Packet Zone ID
15 QoS Quality of Service
16 RADIUS Remote Authentication Dial In User Service
17 RLP Radio Link Protocol
18 RN Radio Network
19 R-P RN-PDSN Interface
20 RRP Mobile IP Registration Reply
21 RRQ Mobile IP Registration Request
22 RSA Rivest-Shamir-Adleman public key algorithm
23 RTP Real-time Transport Protocol
24 SA Security Association
25 SDB Short Data Burst
26 SHA Secure Hash Algorithm
27 SID System Identification
28 SPI Security Parameter Index
29 SR_ID Service Reference Identifier
30 SSRC Synchronization Source
31 SS7 Signaling System 7
32 TCP Transmission Control Protocol
33 TFT Traffic Flow Template
34 TSIG Transaction Signature
35 TTL Time To Live
36 UDP User Datagram Protocol
37 UDR Usage Data Record
38 VAAA Visited AAA
39 VLR Visitor Location Register
40 VSA Vendor Specific Attribute
41 VSE Vendor Specific Extension
42 2.2 Definitions
43
44 A Resource Record:
45 The A resource record type is a record specific to the Internet class that stores a single
46 IPv4 address.
47
48 AAAA Resource Record:
49 The AAAA resource record type is a record specific to the Internet class that stores a
50 single IPv6 address.
51 Access Provider Network:

52 A cdma2000 wireless network that provides access to cdma2000 users.
-3- 3GPP2
1 Always On:
2 The Always On Service maintains the subscriber's packet data session in the local
3 network (i.e., for Always On service, the PDSN shall not initiate release of the
4 subscriber's packet data session, unless the PDSN determines the user is no longer
5 reachable).
6 Auxiliary Service Instance:

7 Auxiliary service instance refers to an additional service instance that is initiated on a per
8 need basis, e.g., when a service such as VoIP is invoked. The QoS characteristics of a
9 auxiliary service instance are based on the needs of the application using it, e.g., low
10 delay, maximum bit rate, guaranteed bit rate, etc. The auxiliary service instances only
11 exist for the time that they are needed by the requesting application. An auxiliary service
12 instance begins after the PPP session is established, and ends no later than when the
13 PPP session ends.
14 Broker RADIUS Server:

15 An intermediate RADIUS server that has security relationships with the Visited RADIUS
16 server and the Home RADIUS server and is used to securely transfer RADIUS
17 messages between the Visited Access Provider Network and the Home IP Network. In
18 some situations, there may be more than one broker RADIUS server in the path between
19 the Visited RADIUS server and the Home RADIUS server.
20 Broker RADIUS Network:

21 A collection of administrative domains that contain Broker RADIUS servers.
22 Default Treatment:
23 The default treatment is the header and payload compressions that are applied to a
24 packet by PPP. The particular compression technique for a given packet is chosen from
25 the set of techniques negotiated during IPCP and CCP.
26 Fast Handoff:
27 An inter PDSN based low latency hard handoff between PCFs. Fast handoff between
28 two PDSNs allows a mobile’s PPP session to be maintained via a layer two tunnel
29 passing through a Target PDSN to the Serving PDSN. Note: There is also an intra
30 PDSN fast handoff that is described in [4] that is outside the scope of this specification.
31 Handoff:
32 In this specification the term "handoff" is defined to mean continuity of IP bindings or PPP
33 link layer state during an interface change from one entity to another. In the absence of
34 any continuity of state whatsoever, this specification does not refer to such interface
35 changes as "handoffs".
36 Home RADIUS:
37 The RADIUS server that resides in the Home IP Network.
38 HAAA:
39 The AAA server that resides in the Home IP Network.
40 Home Access Provider Network:

41 A cdma2000 wireless network that is the home for the mobile subscriber unit. The user
42 may have a different home network for data services.
43 Home Address:
44 An MS IP address that remains unchanged regardless of the MS's point of attachment to
45 the network.
-4- 3GPP2
1 Home IP Network:
2 The home network that provides IP based data services to the user. This network is
3 where the user's NAI is homed. This network may be a private network, publicly
4 accessible ISP network, or a cdma2000 wireless network.
5 Link Local Address:

6 An IPv6 address whose scope is local to a link.
7
8 Main Service Instance:
9 The service instance initiated by an MS that is used for PPP negotiation. This
10 specification allows an MS exactly one main service instance. For any PPP session, the
11 main service instance is established first, before any auxiliary service instances are
12 established.
13
14 SR_ID:
15 The SR_ID is the service instance identifier used to identify a given service instance.
16 Packet Data Service:

17 A general term used for any packet switched data service offered by an access provider
18 network to a user through the user’s MS.
19 Packet Data Service Option:

20 A number specified in [13] that is used to identify a packet switched data service.
21 Packet Data Session:

22 Describes continuous use of packet data service by the user. A packet data session
23 begins when the user invokes packet data service. A packet data session ends when the
24 user or the network terminates packet data service. During a particular Mobile IP packet
25 data session, the user may change its point of attachment while maintaining the same
26 home address.
27
28 For Simple IP service, changing points of attachments constitutes a change in packet
29 data session because a new IP address is assigned by the new point of attachment. For
30 Simple IP service, a packet data session and a PPP session are concurrent, where as for
31 Mobile IP service, the packet data session can exist through several changes of the PPP
32 session.
33 Point of Attachment:
34 Point of attachment refers to the node where the MS is connected to access the IP
35 network. In the context of this specification, it refers to the PDSN entity.
36 Pi:
37 Pi is the interface between the PDSN and the public Internet.
38 P-P Connection:
39 A connection between a Serving and Target PDSN that uses a GRE tunnel to transport
40 user data for a single service instance during fast handoff.
41
42 P-P Interface:
43 The interface between the Target PDSN and the Serving PDSN that is used to support
44 fast handoff.
45 P-P Session:
46 The set of all P-P connections for a single MS.
-5- 3GPP2
1 PPP Session:
2 A PPP session describes the time during which the main service instance is maintained
3 between the MS and the Serving PDSN. The PPP session is maintained while the MS is
4 dormant. If a user hands off from one RN to another RN but is still connected to the
5 same PDSN, the PPP session remains.
6 Private Address:
7 An IP address conforming to RFC 1918.
8 Private Network:
9 An IP Network that resides behind a firewall and that may use private IP addresses.
10 RADIUS:
11 The specific AAA server implementation used in cdma2000 networks for AAA
12 functionality. The RADIUS servers may be located in the Home IP Network, the Broker
13 Network, or the Visited Access Provider Network.
14 Radio Network:
15 The RN is equivalent to the BS and the PCF as defined in the Network Reference Model
16 [14]. In this specification, the terms PCF and RN are used interchangeably when
17 describing handoffs across the R-P interface. The RN is equivalent to the Radio Access
18 Network (RAN) specified in [4].
19 R-P Connection:
20 A connection between a PCF and a PDSN that uses a GRE tunnel to transport user data
21 for a single packet data service instance. This is equivalent to the A10 connection
22 specified in [4].
23 R-P Interface:
24 The interface between the PCF and PDSN that transports user packet data and signaling
25 messages, as specified in [4].
26 R-P Network:
27 An IP network as defined in [4] connecting the RNs with the PDSNs.
28
29 R-P Session:
30 The R-P session is a collection of R-P connections for a single MS and is equivalent to a
31 Packet Data Session as specified in [4].
32 Service Instance:
33 A connection between an MS and PDSN used to transport user data for a packet data
34 service. Associated with each service instance is a packet data service option, a service
35 reference identifier (SR_ID), and an R-P connection. This specification defines two
36 categories of service instances, a main service instance and an auxiliary service
37 instance.
38 Serving PDSN:
39 A PDSN that supports the PPP session to an MS.
40 Serving R-P Address:

41 The R-P network interface IP address of the Serving PDSN.
42 Serving P-P Address:

43 The P-P network interface IP address of the Serving PDSN.
-6- 3GPP2
1 Target PDSN:
2 A PDSN that co-operates with a Target RN over the R-P interface, and co-operates with
3 the Serving PDSN over the P-P interface to provide link layer tunneling between the
4 Serving PDSN and the Target RN in the context of a fast handoff.
5 Target P-P Address:

6 The P-P network interface IP address of the Target PDSN.
7
8 User Profile:
9 The User Profile is an abstraction for the collection of all the parameters applied to the
10 user. The User Profile includes the Subscriber QoS profile (which itself includes the
11 Allowed Differentiated Services Marking and Service Option profile).
12
13 Visited Access Provider Network:
14 The visited service provider provides access services through the establishment of a
15 service agreement with a home service provider.
16 Visited RADIUS:
17 The RADIUS server that resides in the Visited Access Provider Network.
18
-7- 3GPP2
1 3 References
2 3.1 Normative References
3 3.13.1.1 IETF
4 RFC 768, Postel, User Datagram Protocol, August 1980.
5
6 RFC 791, Internet Protocol, Sept. 1981.
7
8 RFC 792, Postel, Internet Control Message Protocol, September 1981.
9
10 RFC 793, Transmission Control Protocol, September 1981.
11
12 RFC1034, Mockapetris, Domain Names - Concepts and Facilities, November 1987.
13
14 RFC 1035, Mockapetris, Domain Names - Implementation and Specification, November 1987.
15
16 RFC 1122, Braden, Requirements for Internet Hosts - Communication Layers, October 1989.
17
18 RFC 1144, Jacobson, Compressing TCP/IP Headers for Low Speed Serial Links, February 1990.
19
20 RFC 1321, Rivest and Dusse, The MD5 Message-Digest Algorithm, MIT Laboratory for Computer
21 Science, RSA Data Security Inc., April 1992.
22
23 RFC 1332, McGregor, The PPP Internet Protocol Control Protocol (IPCP), May 1992.
24
25 RFC 1661, Simpson, The Point-to-Point Protocol (PPP), July 1994.
26
27 RFC 1662, Simpson, PPP in HDLC-like Framing, July 1994.
28
29 RFC 1886, Thompson, Huitema, DNS Extensions to Support IP Version 6, December 1995.
30
31 RFC 1877, Cobb, PPP Internet Protocol Control Protocol Extensions for Name Server
32 Addresses, December 1995.
33
34 RFC 1889, Schulzrinne, Casner, Frederick, Jacobson, RTP: A Transport Protocol for Real-Time
35 Applications, January 1996.
36
37 RFC 1918, Rekhter, Moskowitz, Karrenberg, de Groot, Lear, Address Allocation for Private
38 Internets, February 1996.
39
40 RFC 1962, Rand, The PPP Compression Control Protocol (CCP), June 1996.
41
42 RFC 1974, Friend, Simpson, PPP Stac LZS Compression Protocol, August 1996.
43
44 RFC 1979, Woods, PPP Deflate Protocol, August 1996.
45
46 RFC 1994, Simpson, PPP Challenge Handshake Authentication Protocol (CHAP), August 1996.
47
48 RFC 2002, Perkins, IPv4 Mobility, May 1995.
49
50 RFC 2003, Perkins, IP Encapsulation within IP, October 1996.
51
-8- 3GPP2
1 RFC 2004, Perkins, Minimal Encapsulation within IP, October 1996.

2
3 RFC 2005, Solomon, Applicability Statement for IP Mobility Support, October 1995.
4
5 RFC 2006, Cong, Hamlen, Perkins, The Definitions of Managed Objects for IP Mobility Support
6 Using SMIv2, October 1995.
7
8 RFC 2118, Pall, Microsoft Point-To-Point Compression (MPPC) Protocol, March 1997.
9
10 RFC 2119, Bradner, Key words for use in RFCs to Indicate Requirement Levels, March 1997.
11
12 RFC 2136, Vixie, Thomson, Rekhter, Bound, Dynamic Updates in the Domain Name System
13 (DNS UPDATE), April 1997.
14
15 RFC 2138, Rigney, Rubens, Simpson, Willens, Remote Authentication Dial In User Service
16 (RADIUS), August 1997.
17
18 RFC 2139, Rigney, RADIUS Accounting, April 1997.
19
20 RFC 2290, Simpson, Mobile-IPv4 Configuration Option for PPP IPCP, February 1998.
21
22 RFC 2373, Hinden, Deering, IP Version 6 Addressing Architecture, July 1998.
23
24 RFC 2374, Hinden, O'Dell, Deering, An IPv6 Aggregatable Global Unicast Address Format, July
25 1998.
26
27 RFC 2401, Kent, Atkinson, Security Architecture for the Internet Protocol, November 1998.
28
29 RFC 2402, Kent, Atkinson, IP Authentication Header, November 1998.
30
31 RFC 2406, Kent, Atkinson, IP Encapsulating Security Payload (ESP), November 1998.
32
33 RFC 2407, Piper, The Internet IP Security Domain of Interpretation for ISAKMP, November 1998.
34
35 RFC 2408, Maughan et al, Internet Security Association and Key Management Protocol
36 (ISAKMP), November 1998.
37
38 RFC 2409, Harkins, Carrel, The Internet Key Exchange (IKE), November 1998.
39
40 RFC 2459, Housley, Housley, Polk, Solo, Internet X.509 Public Key Infrastructure Certificate and
41 CRL Profile, January 1999.
42
43 RFC 2460, Deering, Hinden, Internet Protocol, Version 6 (IPv6) Specification, December 1998.
44
45 RFC 2461, Narten, Nordmark, Simpson, Neighbor Discovery for IP Version 6 (IPv6), December
46 1998.
47
48 RFC 2462, Thomson and Narten, IPv6 Stateless Address Auto-configuration, December 1998.
49
50 RFC 2472, Haskin, Allen, IP Version 6 over PPP (IPv6CP), December 1998.
51
52 RFC 2474, Nichols, Blake, Baker, Black, Definition of the Differentiated Services Field (DS Field)
53 in the IPv4 and IPv6 Headers, December 1998.
54
55 RFC 2475, Blake, Black, Carlson, Davies, Wang, Weiss, An Architecture for Differentiated
56 Services, December 1998.
-9- 3GPP2
1
2 RFC 2484, Zorn, PPP LCP Internationalization Configuration Option, January 1999.
3
4 RFC 2486, Aboba, Beadles, The Network Access Identifier, January 1999.
5
6 RFC 2507, Degermark, Nordgren, Pink, IP Header Compression, February 1999.
7
8 RFC 2597, Heinanen, Baker, Weiss, Wroclawski, Assured Forwarding PHB Group, June 1999.
9
10 RFC 2598, Jacobson, Nichols, Poduri, An Expedited Forwarding PHB, June 1999.
11
12 RFC 2784, Farinacci et al, Generic Routing Encapsulation (GRE), March 2000.
13
14 RFC 2794, Calhoun, Perkins, Mobile NAI Extension, March 2000.
15
16 RFC 2865, Rigney, Willens, Reubens, Simpson, Remote Authentication Dial In User Service
17 (RADIUS), June 2000.
18
19 RFC 2866, Rigney, RADIUS Accounting, June 2000.
20
21 RFC 2868, Zorn et al., RADIUS Attributes for Tunnel Support, June 2000.
22
23 RFC 2890, Dommety, Key and Sequence Number Extensions to GRE, September 2000.
24
25 RFC 2983, Black, Differentiated Services and Tunnels, October 2000.
26
27 RFC 3006, Davie, Iturralde, Oran, Casner, Wroclawski, Integrated Services in the Presence of
28 Compressible Flows, November 2000.
29
30 RFC 3012, Calhoun, Perkins, Mobile IPv4 Challenge/Response Extensions, November 2000.
31
32 RFC 3024, Montenegro, Reverse Tunneling for Mobile IP, January 2001.
33
34 RFC 3041, Narten, Draves, Privacy Extensions for Stateless Address Autoconfiguration in IPv6,
35 January 2001.
36
37 RFC 3095, Borman, et al, Robust Header Compression (ROHC): Framework and four profiles:
38 RTP, UDP, ESP, and uncompressed, July 2001.
39
40 RFC 3162, Zorn et al., RADIUS and IPv6, August 2001.
41
42 RFC 3241, Borman, ROHC over PPP, January 2002.
43 3.1.2 3GPP2
44 [1] P.R0001cdma2000 Wireless IP Architecture Based on IETF Protocols, December 2000.
45
46 [2] N.S0017, International Implementation of Wireless Telecommunication Systems Compliant
47 with TIA/EIA-41, December 2000.
48
49 [3] TIA/EIA-553, Mobile Identification Number (MIN).
50
51 [4] A.S0017-0, 3GPP2 Access Network Interfaces Interoperability Specification, November 2001.
52
53 [5] C.S0001-A Introduction for cdma2000 Standards for Spread Spectrum Systems, June 2000.
54
- 10 - 3GPP2
1 [6] C.S0002-A, Physical Layer Standard for cdma2000 Standards for Spread Spectrum Systems,
2 June 2000.
3
4 [7] C.S0003-A, Medium Access Control (MAC) Standard for cdma2000 Standards for Spread
5 Spectrum Systems, June 2000
6
7 [8] C.S0004-A, Signaling Link Access Control (LAC) Standard for cdma2000 Standards for
8 Spread Spectrum Systems, June 2000.
9
10 [9] C.S0005-A, Upper Layer (Layer 3) Signaling Standard for cdma2000 Standards for Spread
11 Spectrum Systems, June 2000.
12
13 [10] C.S0016-A, Over-the-Air Service Provisioning of Mobile Stations in Wideband Spread
14 Spectrum Systems, December 2001.
15
16 [11] C.S0017-0-2, Data Service Options for Spread Spectrum Systems – Addendum 2, August
17 2000.
18
19 [12] TIA/EIA/IS-751N.S0009, TIA/EIA-41-D Modifications to Support IMSI, February 1998.
20
21 [13] TIA/EIA/TSB58-E, Administration of Parameter Value Assignments for cdma2000 Spread
22 Spectrum Standards, January 2002.
23
24 [14] TIA/EIA/TSB100-A, TR-45 Wireless Network Reference Model (NRM), March 2001.
25
26 [15] TIA/EIA/IS-856-1C.S0024 v3.0, cdma2000 High Rate Packet Data Air Interface Specification
27 - Addendum 1, December 2001January 2002.
28 3.1.3 TIA
29 [3] TIA/EIA-553-A, Mobile Station – Base Station Compatibility Standard, October 1999.
30 3.33.2 ITU-T
31 ITU-T Recommendation E.212, The International Identification Plan for Mobile Terminals and
32 Mobile Users.
33
34 ITU-T Recommendation X.509, Public-key and Attribute Certificate Frameworks.
35 3.3 Informative
36 3.3.1 3GPP2
37 [1] P.R0001cdma2000 Wireless IP Architecture Based on IETF Protocols, December 2000.
38
39 [2] N.S0017, International Implementation of Wireless Telecommunication Systems Compliant
40 with TIA/EIA-41, December 2000.
41
42 [13] C.R1001-D v1.0, Administration of Parameter Value Assignments for cdma2000 Spread
43 Spectrum Standards, April 2003.
44
45 [14] S.R0005-B, Network Reference Model (NRM) for cdma2000 Spread Spectrum Systems,
46 May 2001.
47
48
- 11 - 3GPP2
1 4 Protocol Reference Models

2 This section specifies the protocol architecture between the entities of the Wireless IP Network
3 architecture. Refer to [1] for a base description of the Wireless IP Network architecture, its
4 components and message flows. To support fast handoff, a new optional interface between
5 PDSN entities is defined in this specification. The architecture for both Mobile IP and Simple IP
6 has been amended to show the new reference point between two adjacent PDSNs.
7 4.1 Network Reference Models

8 Figure 1 shows a reference model for Simple IP service.
9
10 Figure 2 shows a reference model for Mobile IP service. For Internet access when the MS is in
11 the home network or roaming, the HA resides in a home access provider network. For private
12 network or home ISP access, the HA resides in the respective external network.
13
14 The IP Network entity in Figure 1 and Figure 2 represents IP Networks that may reside in the
15 public Internet as well as private IP networks between access provider networks and home IP
16 networks. The optional P-P interface is used to support fast handoff between PDSNs.
17
SS7 Network
MSC HLR
Visited Access Provider Home Access

Network (serving) Provider network
A1
RADIUS RADIUS
IP Network
Home IP network
Pi
R-P interface
A10, A11 RADIUS
Serving PDSN
Source RN Broker network
P-P interface
Pi
R-P interface
A10, A11
Mobile station Target PDSN
Target RN
Visited Access Provider
Network (target)
18
19
20
21 Figure 1 - Reference Model for Simple IP Access
- 12 - 3GPP2
SS7 Network
MSC HLR
Visited Access Provider Home Access

Network (serving) Provider network
A1
RADIUS RADIUS
IP Network
Home IP network
Pi
R-P interface
A10, A11 RADIUS
Serving PDSN
Source RN Broker network
P-P interface
Pi
R-P interface HA
A10, A11
Home IP network
Mobile station Target PDSN Private network
Target RN
Home access provider
Visited Access Provider
network
Network (target)
1
2
3
4 Figure 2 - Reference Model for Mobile IP Access
5
6 The MS is implemented as a single MT0 type device or as a MT2 and a TE2 pair. See [11] for
7 details.
8
9 Although Mobile IP and Simple IP services are represented in different protocol reference
10 models, the network shall provide both Simple IP and Mobile IP service simultaneously to an MS
11 using the same PPP session for IPv4. For IPv6 MSs, the network shall provide Simple IP
12 service. The network shall support IPv4 and IPv6 MSs simultaneously. The network shall
13 provide Simple IPv4 and/or Simple IPv6 service for the same MS over the same PPP session.
14 Support of IPv6 MSs in the network shall be independent of the IP version used for transport in
15 the RN.
16 4.2 Simple IP
17 Figure 3 shows the protocol reference model for Simple IPv4 or IPv6 service. Figure 4 shows the
18 protocol reference model for Simple IP access during fast handoff.
19
- 13 - 3GPP2
IP IP IP
PPP PPP
Link Link
LAC/ LAC/ Layer Layer
RLP RLP
R-P R-P
MAC MAC
Airlink Airlink PL PL PL PL
Mobile End
RN PDSN
Station Host
1
2
3 Figure 3 - Protocol Reference Model for Simple IP Access
4
IP IP IP
PPP PPP
Link Link
RLP RLP R-P P-P
R-P P-P
MAC MAC
Airlink Airlink PL PL PL PL PL PL
End
MS RN PDSNtarget PDSN serving
Host
P-P
Interface
5
6
7
8 Figure 4 - Protocol Reference Model for Simple IP Access During Fast Handoff
9
10 4.3 Mobile IP
11 Figure 5 and Figure 6 show the protocol reference model for Mobile IP control and user data,
12 respectively. IPSec is required in some situations, and not in other situations, as detailed in
13 Section 6.2.4.
14
- 14 - 3GPP2
MIP MIP IKE IKE MIP

UDP UDP UDP
IP/ IP/
IP IP
IPsec IPsec
PPP PPP
Link Link
RLP RLP
R-P R-P
MAC MAC
Airlink Airlink PL PL PL PL
Mobile
RN PDSN HA
Station
1
2
3 Figure 5 - Protocol Reference Model for Mobile IP Control and IKE
4
- 15 - 3GPP2
IP IP IP IP
IP/IPsec IP/IPsec
PPP PPP Link Link

Layer Layer
Link Link
RLP RLP
R-P R-P
MAC MAC
Mobile End
RN PDSN HA Host
Station
2
3
4 Figure 6 - Protocol Reference Model for Mobile IP Bearer Data
5
6 The protocol architecture for Mobile IP control and user data during fast handoff is illustrated in
7 Figure 7 and Figure 8, respectively.
8
MIP MIP IKE IKE MIP

UDP UDP UDP
I IP / IP /
IP P IPsec IPsec
PPP PPP
Link Link
RLP RLP P-P
R-P R-P P-P
MAC MAC
MS RN PDSNtarget PDSNserving HA
P-P
Interface
9
10
11 Figure 7 - Protocol Reference Model for MIP Control and IKE During Fast Handoff
12
- 16 - 3GPP2
IP IP
IP IP
IP/IPsec IP/IPsec
PPP PPP
Link Link Link Link
LAC/ LAC/ Layer Layer Layer Layer
RLP RLP
R-P R-P P-P P-P
MAC MAC
Airlink Airlink PL PL PL PL PL PL PL PL
Mobile RN HA End
PDSN target PDSN serving
Station Host
P-P
Interface
1
2
3 Figure 8 - Protocol Reference Model for MIP Bearer Data During Fast Handoff
4
5
6 Figure 9 and Figure 10 respectively show the protocol reference models for fast handoff. IKE
7 and IPSec are optional on the P-P interface.
8
9
R-P R-P P-P P-P

LAC Sig. Signaling Sig. IKE IKE Sig.
UDP UDP UDP UDP Link
Layer
IP IP IP IPsec IP IPsec
MAC Link Layer
Link Layer Link Layer Link Layer
Airlink PL PL PL PL PL
RN PDSN target PDSN serving

R-P Interface P-P Interface
10
11
12 Figure 9 - Protocol Reference Model for Signaling for Fast Handoff
13
14
- 17 - 3GPP2
L2 Relay L2 Relay PPP

Link
LAC GRE GRE GRE GRE Layer
IP IP IP/IPsec IP/IPsec
MAC Link Link Link Link
Layer Layer Layer Layer
Airlink PL PL PL PL PL
R-P Interface P-P Interface
RN PDSNtarget PDSNserving
1
2
3 Figure 10 - Protocol Reference Model for User Data for Fast Handoff
4
5 4.4 RADIUS
6 Figure 11 shows the protocol reference model for the RADIUS entities in the wireless network (as
7 illustrated in Figure 1 and Figure 2) between the PDSN (RADIUS client) and the Home RADIUS
8 server. In this model, the RADIUS servers in the visited network communicate with the RADIUS
9 servers in the home network via zero or more optional proxy (or Broker) RADIUS servers.
10
11 A RADIUS server may run IPv4, IPv6, or both. The method of interworking between IPv4 and
12 IPv6 RADIUS clients and servers is outside the scope of this specification.
13
RADIUS RADIUS RADIUS RADIUS RADIUS RADIUS
UDP UDP UDP UDP UDP UDP
IP IP IP IP IP IP
Link Link Link Link Link Link

Layer Layer Layer Layer Layer Layer
PL PL PL PL PL PL
RADIUS RADIUS RADIUS

PDSN Broker
Visited Home
(optional)
14
15
16 Figure 11 - RADIUS Protocol Reference Model
17
- 18 - 3GPP2
1 5 Simple IP Operation
2 This section describes the requirements and procedures for Simple IP operation for both IPv4
3 [RFC 791] and IPv6 [RFC 2460]. In this specification, Simple IP refers to a service in which an
4 MS is assigned an IP address and is provided IP routing service by an access provider network.
5 The MS retains its IP address as long as it is served by a radio network that has connectivity to
6 the address assigning PDSN. There is no IP address mobility beyond this PDSN. Secure
7 access to a home network via Simple IP is beyond the scope of this specification.
8 5.1 Common Service Specification

9 The common requirements for several network elements (e.g., PDSN and MS) for Simple IP
10 operation are described here.
11 5.1.1 PPP Session

12 PPP shall be the data link protocol between the MS and the PDSN. The PPP session shall be
13 established prior to any IP datagrams being exchanged between the MS and the PDSN.
14
15 PPP shall be supported as defined in the following standards with any limitations or extensions
16 described in this specification.
17
18 • Point to Point Protocol [RFC 1661];
19 • PPP octet oriented HDLC [RFC 1662];
20 • IPCP [RFC 1332] (for IPv4);
21 • IPv6CP [RFC 2472] (for IPv6);
22 • CHAP [RFC 1994];
23 • PAP [RFC 1334].
24
25 PPP encryption shall not be negotiated by either the MS or PDSN. Only one PPP session shall
26 be supported between the MS and the PDSN.
27 5.2 PDSN Requirements

28 The PDSN shall support Simple IP operation for both IPv4 and IPv6.
29
30 For an IPv6 MS, the PDSN shall be the link local router and the PPP termination point. There
31 shall be at least one /64 prefix assigned to each PPP session. Each /64 prefix shall be globally
32 unique.
34 5.2.1.1 Establishment
35 When the first R-P connection for the main service instance is established, the PDSN2 shall send
36 an LCP Configure-Request for a new PPP session to the new MS. If an RN opens an R-P
37 connection for which a PPP session already exists, the PDSN shall not send an LCP Configure-
38 Request message to the MS.
39
40 PPP shall support transparency in accordance with Section 4.2 of RFC 1662. The PDSN shall
41 attempt to negotiate a control character mapping with the minimum number of escaped
42 characters by proposing an ACCM of 0x00000000.
2
As specified in Section 12, at fast handoff establishment, a Target PDSN does not send PPP
control messages over new R-P connections.
- 19 - 3GPP2
1 5.2.1.2 Termination
2 The PDSN shall clear the PPP state if there is no established R-P or P-P session for the MS.
3 The PDSN shall clear the R-P and/or P-P session whenever the PPP session is closed or
4 expired. If the PDSN receives IP packets for an MS for which there is no established PPP
5 session, the PDSN shall silently discard the packet. The PDSN shall close the R-P and
6 associated P-P session whenever the MS closes the PPP session.
7
8 The PDSN may receive the Always On attribute with value ‘1’ from the HAAA in order to activate
9 the Always On service for a user. To implement Always On service for a user, the PDSN shall
10 utilize the expiration of the PPP inactivity timer and the procedures described in Section 5.2.1.8 to
11 determine if the PPP session should be closed.
12
13 If Always On service is not enabled and the PPP inactivity timer for a PPP session expires, the
14 PDSN shall close the PPP session.
15 5.2.1.3 PPP Session Authentication

16 The PDSN shall support the two authentication mechanisms: CHAP and PAP. The PDSN shall
17 also support a configuration option to allow an MS to receive Simple IP service without CHAP or
18 PAP. The PDSN shall propose CHAP in an initial LCP Configure-Request message that the
19 PDSN sends to the MS during the PPP establishment. If the MS is not configured to use CHAP
20 but to use PAP instead, and the MS proposes PAP in an LCP Configure-NAK, the PDSN shall
21 accept PAP by sending an LCP Configure-Request message with PAP. If the PDSN is
22 configured to allow the MS to receive Simple IP service without CHAP or PAP, the PDSN shall
23 adhere to the guidelines in Section 5.2.2.1.
24 5.2.1.4 Addressing with IPCP
25 5.2.1.4.1 IPv4 Addressing

26 For IPv4, the PDSN shall assign the MS an IP address for Simple IP service when presented with
27 a zero or non-zero IP address in the IP Address Configuration option, during the IPCP phase of
28 PPP. If the MS requests a non-zero IP address during the IPCP phase, the PDSN shall send an
29 IPCP Configure-Nak in response to the request in order to propose a different IP address. The
30 MS accepts the new address. The IP address may be a private address as per RFC 1918.
31
32 The PDSN shall implement IPCP configuration options as defined in RFC 1877 for the DNS
33 server address negotiation. The PDSN shall negotiate Primary and Secondary DNS server IP
34 addresses with the MS if the DNS Server Configuration options are received during the IPCP
35 phase. . If the PDSN supports DNS server IP address VSA, itThe PDSN shall determine if the M
36 bit is set in the DNS Server IP Address VSA received in the RADIUS Access-Accept message.
37 The PDSN shall select DNS Server IP Address VSA, with the M bit set, for DNS information. If
38 PDSN receives a RADIUS Access-Accept message from the Visited RADIUS server that has
39 DNS IP address VSA(s) with the following values included, then the PDSN shall apply local
40 policies to select the DNS IP Address VSA for DNS information.
41 • An DNS IP Address VSA with the Entity-Type subfield set to the value 1 (=HAAA) and
42 the M bit unset, and/or
43 • One or more DNS IP Address VSA(s) with the Entity-Type subfield set to the value 2
44 (=VAAA).

46 For an IPv6 MS, the PDSN shall be the default router and the PPP termination point. The PDSN
47 shall allocate one globally unique /64 prefix to each PPP link. The PDSN shall not construct any
48 global address from this prefix.
49 The PDSN shall support the following RFCs, with exceptions as noted in this specification:
50 • An IPv6 Aggregatable Global Unicast Address Format [RFC 3587];
- 20 - 3GPP2
1 • Internet Protocol, Version 6 (IPv6) Specification [RFC 2460];

2 • Neighbor Discovery for IP Version 6 (IPv6) [RFC 2461];
3 • IPv6 Stateless Address Auto-configuration [RFC 2462];
4 • Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version
5 6 (IPv6) Specification [RFC 2463];
6 • IP Version 6 over PPP [RFC 2472];
7 • IP Version 6 Addressing Architecture [RFC 3513].
8 The PDSN shall perform Interface-identifier negotiation as described in RFC 2472. The PDSN
9 shall provide a valid non-zero Interface-Identifier during its negotiation of the Interface-identifier.
10 The PDSN shall not have more than one Interface Identifier associated with the PPP connection,
11 i.e., the PDSN shall only use the Interface Identifier negotiated during the IPv6CP phase with the
12 MS. Because the Interface-Identifier is negotiated in the IPv6CP phase of the PPP connection
13 setup, it is not required to perform duplicate address detection for the link local address forms as
14 part of IPv6 stateless address auto-configuration [RFC 2462].
15 Following successful IPv6CP negotiation and the establishment of a unique link-local address for
16 both the PDSN and the MS, the PDSN shall immediately3 transmit initial unsolicited Router
17 Advertisement (RA) messages on the PPP link using its link-local address as a source address.
18 The PDSN shall include a globally unique /64 prefix in the Router Advertisement message to the
19 MS. The MS shall use this prefix to configure its global IPv6 addresses.
20 The PDSN shall send unsolicited Router Advertisement (RA) message for an operator
21 configurable number of times. Also, the PDSN shall set the interval between initial RA messages
22 to an operator configurable value, which may be less than
23 MAX_INITIAL_RTR_ADVERT_INTERVAL. After the configurable number of initial unsolicited RA
24 messages has been transmitted, the interval between the periodic transmissions of unsolicited
25 RA messages shall be controlled by the router configurable parameters MaxRtrAdvInterval and
26 MinRtrAdvInterval as defined in RFC 2461. The PDSN may set MaxRtrAdvInterval to a value
27 greater4 than 1800seconds and less than 1/3 of the AdvDefaultLifetime. The PDSN shall set
28 MinRtrAdvInterval4 to a fraction of MaxRtrAdvInterval as per RFC 2461.
29 The PDSN shall send a RA message in response to a Router Solicitation (RS) message received
30 from the MS. The PDSN may set the delay between consecutive (solicited RA) or (solicited
31 /unsolicited RA) messages sent to the all-nodes multicast address to a value less5 than that
32 specified by the constant MIN_DELAY_BETWEEN_RAS, contrary to the specification in sec.
33 6.2.6 of RFC 2461.
34 The advertised /64 prefix6 identifies the subnet associated with the PPP link. The /64 prefix
35 advertised by the PDSN shall be exclusive to the PPP session.
36 The PDSN shall set
37 • the M-flag = 0 and the O-flag = 0 in the RA message header;
38 • the L-flag = 0 and the A-flag =1 in the RA message Prefix Information Option.
39 The PDSN shall set the Router Lifetime value in the Router Advertisement message to a value of
40 216-1 (18.2 hrs).
41 The PDSN shall not send any redirect messages to the MS over the PPP interface.The PDSN
42 shall support:
43 IPv6 over PPP (or IPv6CP) [RFC 2472]
3
This is an exception to RFC 2461 necessary to optimize applicability over the cdma2000
wireless air-interface.
4
This may cause an exception to RFC 2461 as it may put the interval outside the normal range.
This exception is allowed by this specification to optimize IPv6 RA over the cdma2000 wireless
links.
5
links.
6
If the Access Service Provider desires to reduce frequent unsolicited RA for the prefix, it should
set the 32-bit Valid Lifetime and Preferred Lifetime fields for the advertised /64 prefix in the RA
message Prefix Information Option to a very high value (i.e., 0xFFFFFFFF to indicate prefix
validity for the lifetime of the PPP session).
- 21 - 3GPP2
1 Neighbor discovery for IPv6 [RFC 2461]

2 IPv6 stateless address auto-configuration [RFC 2462]
3 IPv6 addressing architecture [RFC 2373]
4 An IPv6 aggregatable global unicast address format [RFC 2374]
5 Privacy Extensions for Stateless Address Auto-configuration in IPv6 [RFC 3041]
6
7 For IPv6 the PDSN shall perform interface-identifier negotiation as described in RFC 2472. The
8 PDSN shall provide a valid non-zero interface-identifier during its negotiation of the interface-
9 identifier. Because the interface-identifier is negotiated in the IPv6CP phase of the PPP
10 connection setup, it is not required to perform duplicate address detection [RFC 2462]. The
11 PDSN shall not have more than one interface ID associated with the PPP connection, i.e., the
12 PDSN shall only use the interface ID negotiated during the IPv6CP phase with the MS.
13
14 Following successful IPv6CP negotiation and establishment of unique link-local address, the
15 PDSN shall initiate Router Advertisement messages using its link-local address as a source, as
16 per RFC 2461. The Router Advertisement messages contain a list of prefixes used by the MS to
17 configure site and/or global IPv6 addresses. These Router Advertisement messages shall be
18 sent an operator configurable number of times. The prefixes identify the subnet(s) associated
19 with a PPP link. All of the prefixes advertised shall be /64 and shall be exclusive to the PPP
20 session.
21 5.2.1.5 Dual Stack of IPv4 and IPv6 Requirements

22
23 If the NCP transitions to the stopped state (either because the NCP failed to establish, or
24 because the NCP was torn down gracefully) and the PDSN allows the establishment of that NCP
25 at a later time upon the receipt of NCP configure request, the NCP shall remain in the stopped
26 state.
27
28 5.2.1.55.2.1.6 Compression
29 The PDSN shall support the following header compression algorithms:
30
31 • Van Jacobson TCP/IP header compression [RFC 1144]
32
33 The PDSN may support the following header compression algorithms:
34
35 • ROHC, Framework and four profiles: RTP, UDP, ESP, and uncompressed [RFC 3095]
36 with ROHC over PPP [RFC 3241]
37 • IP Header compression [RFC 2507]
38
39 The PDSN shall support CCP [RFC 1962] for the negotiation of PPP payload compression. The
40 PDSN shall support the following types of PPP compression:
41
42 • Stac-LZS [RFC 1974];
43 • Microsoft Point-To-Point Compression Protocol [RFC 2118];
44 Deflate [RFC 1979]
45
46 The PDSN may support other PPP payload compression algorithms.
47 5.2.1.65.2.1.7 PPP Framing

48 The PDSN shall frame PPP packets sent on the PPP link layer using the octet synchronous
49 framing protocol defined in RFC 1662, except that there shall be no inter-frame time fill (see 4.4.1
50 of RFC 1662). That is, no flag octets shall be sent between a flag octet that ends one PPP frame
51 and the flag octet that begins the subsequent PPP frame.
- 22 - 3GPP2
1
2 For IPv6, the PDSN shall allow an information field at least as large as the minimum link MTU
3 size required for IPv6 (1280 octets, or a total PPP frame size minimum MTU of 1286 octets).
4 5.2.1.75.2.1.8 PPP Link Status Determination

5 If the PDSN supports Always On service, the PDSN shall support the following configurable timer
6 and counter:
7
8 • Echo-Reply-Timeout timer
9 • Echo-Request-Retries counter
10
11 Upon entering the IPCP Opened state on a PPP session configured for Always On Service, the
12 PDSN shall start the PPP inactivity timer for the PPP session in question. Upon expiration of the
13 PPP inactivity timer, the PDSN shall send an LCP Echo-Request message [RFC 1661] over the
14 main service instance, and start the Echo-Reply-Timeout timer for the PPP session in question.
15 It shall also initialize the Echo-Request-Retries counter to a configurable integer value.
16
17 Upon receipt of an LCP Echo-Reply message [RFC 1661] for the PPP session in question, the
18 PDSN shall stop the Echo-Reply-Timeout timer, reset the Echo-Request-Retries counter, and
19 restart the PPP inactivity timer.
20
21 Upon expiration of the Echo-Reply-Timeout timer when the Echo-Request-Retries counter value
22 is greater than zero, the PDSN shall send an LCP Echo-Request message, decrement the Echo-
23 Request-Retries counter by one, and start the Echo-Reply-Timeout timer.
24
25 Upon expiration of the Echo-Reply-Timeout timer when the Echo-Request-Retries counter value
26 is equal to zero, the PDSN shall release the PPP session.
27 5.2.2 RADIUS Support

28 The PDSN shall act as a RADIUS client in accordance with RFC 2865 and shall communicate
29 CHAP or PAP authentication information to the Visited RADIUS server in a RADIUS Access-
30 Request message. Upon receipt of the CHAP or PAP response from the MS, the PDSN shall
31 create an Access-Request message in accordance with Table 1.
- 23 - 3GPP2
Attribute Name Type Access- Access- Interface(s)

Request Accept
User-Name 1 M M PDSN <-> AAA
User-Password 2 O7 PDSN -> AAA
CHAP-Password 3 O8 PDSN -> AAA
NAS-IP-Address 4 O9 PDSN -> AAA
NAS-IPv6-Address 95 O PDSN -> AAA
CHAP-Challenge 60 O PDSN -> AAA
Correlation ID 26/44 M O PDSN <-> AAA
Always On 26/78 O PDSN <- AAA
NAS-Port-Type10 61 O PDSN -> AAA
1
2 (M) Indicates Mandatory Attribute
3 (O) Indicates Optional Attribute
4
5 Table 1 - Occurrence of RADIUS Attributes for Simple IP
6
7 There are additional RADIUS VSAs that may be returned in a RADIUS Access-Accept message
8 as per Annex D.
9
10 Correlation ID is in addition to those fields specified by RFC 2865 and RFC 3162.
11
12 The PDSN shall act as a RADIUS accounting client in accordance with RFC 2866 and shall
13 communicate user accounting information to the Visited RADIUS server in RADIUS Accounting-
14 Request records. The RADIUS Accounting-Request message shall contain the accounting
15 attributes as specified in Section 11.3.
16
17 The security of communications between the PDSN and RADIUS server may optionally be
18 protected with IP security. The establishment of the security association is outside the scope of
19 this specification.
20
21 When the PDSN sends a RADIUS Access-Request, it may not know a priori whether the MS
22 uses IPv4, IPv6, or both. Address assignment does not occur until after RADIUS authentication
23 and authorization has completed. As per RFC 3162, the IPv6 attributes may be sent along with
24 IPv4-related attributes within the same RADIUS message. The PDSN decides to use IPv4 and/or
25 IPv6 specific attributes that it receives in the Access-Accept message based on whether the MS
26 initiates IPCP and/or IPv6CP.
27 5.2.2.1 NAI Construction in the Absence of CHAP or PAP

28 In the event that the MS does not negotiate CHAP or PAP, no MS NAI is received by the PDSN.
29 In this case, the PDSN shall not perform additional authentication of the user. If the PDSN is
30 capable of constructing a properly formatted NAI [RFC 2486] based on the MSID then accounting
31 records shall be generated and keyed on the user’s constructed NAI. The NAI shall be
32 constructed in the form <MSID>@<realm>, where <MSID> is the MSID of the MS, and <realm>
33 is the name (RFC 2486) of the home network that owns the MS MSID. If the PDSN is unable to
34 construct an NAI for an MS, then the PDSN may deny service to the MS.
35
36 The MS uses one of the following MSID formats:
7
User-Password is mandatory if PAP.
8
CHAP-Password is mandatory if CHAP.
9
This is the IPv4 address of the RADIUS server interface of the PDSN; at least one of NAS-IP-
Address or NAS-IPv6-Address must be included.
10
The values are as follows: 22 (cdma2000) [5-9] or 24 (HRPD) [15], depending on the service
option number connected to the PDSN.
- 24 - 3GPP2
1
2 • International Mobile Subscriber Identity (IMSI) [E.212]
3 • Mobile Identification Number (MIN) [3]
4 • International Roaming MIN (IRM) [2]
5
6 The PDSN shall store the constructed NAI into accounting records, and the realm value may
7 optionally be used by the Visited RADIUS server to forward these records to the correct Home
8 RADIUS Server for proper summary and settlement11. The constructed NAI shall not be used for
9 authentication. If configured by the operator, the PDSN shall send RADIUS accounting
10 messages to the Visited RADIUS server using the constructed NAI in the absence of CHAP or
11 PAP.
12 5.2.3 Ingress Address Filtering

13 The Serving PDSN shall check the source IPv4 address of every packet received on the PPP link
14 from the MS. Upon receiving a packet from the MS, the PDSN shall discard the packet and send
15 an LCP Configure-Request message to restart the PPP session, if
16
17 The MS has been assigned one or more IP addresses by the PDSN and/or HA, but the
18 source IP address of the packet is not one of the addresses that has been assigned to
19 the MS and the packet is not a MIP RRQ or Agent Solicitation.
20 • The MS has not been assigned an IP address, and the packet is not a MIP RRQ or Agent
21 Solicitation.
22 Uupon receiving a packet from the MS with invalid12invalid source IP address, the PDSN shall
23 discard the packet and may send an LCP Configure-Request message to restart the PPP
24 session13 if IPCP has reached the open state..
25 If the PDSN receives an implementation-defined number of consecutive packets with an invalid
26 source IP address from the MS, the PDSN shall send an LCP Configure-Request message to the
27 MS.
28 For Mobile IP and simultaneous Simple IP and Mobile IP sessions see section 6.2.5.
29 For IPv6, the Serving PDSN shall check the prefix of the source IP address of every packet
30 received on the PPP link from the MS. If the prefix is not associated with the PPP Session of the
31 MS, then the PDSN shall discard the packet and send an LCP Configure-Request to restart the
32 PPP session.
33 5.3 RADIUS Server Requirements

34 The RADIUS Server shall follow the guidelines specified in RFCs 2865, 2866, and 3162.
35
36 The Visited and Home RADIUS server shall support the attributes in Table 1, the Interim
37 Accounting Record in Annex E as well as the accounting attributes listed in Section 11.4.
38
39 The Home RADIUS server may include the ‘Always On’ attribute in the RADIUS Access-Accept
40 message to indicate an “Always On Service” for a user, based on the User Profile.
41
42 If the MS uses CHAP or PAP, the PDSN shall send the Visited RADIUS server a RADIUS
43 Access-Request message with CHAP or PAP authentication information. The Visited RADIUS
11
The Home RADIUS Server may require an MSID to user conversion table to map the
constructed NAI to the user's actual NAI to complete the billing process in cases where the
constructed NAI differs from the actual NAI.
12
The source IP address from the MS is considered as invalid if it is not one of the addresses
that have been assigned to the MS or if the MS has not been assigned any IP addresses.
13
The reason to restart PPP is because the user could have started a Simple IP session during a
previous dormant handoff to another PDSN and returned; in this case the current PDSN would
not know the MS had invoked Simple IP and received another IP address. Thus, restarting PPP
will force the Simple IP session to get a topologically correct address.
- 25 - 3GPP2
1 server shall forward the RADIUS Access-Request message to the home network or a peer (e.g.,
2 a broker) if it does not have the authority to accept/deny the request. This is in accordance with
3 RFC 2865. Upon receiving a RADIUS Access-Request message, the Home RADIUS server
4 shall send a RADIUS Access-Accept message or Access-Reject message to the Broker or
5 Visited RADIUS server. The Visited RADIUS server shall send the received response to the
6 PDSN.
7
8 The PDSN shall send RADIUS Accounting-Request records to the Visited RADIUS server in
9 accordance with RFC 2866. The PDSN may also send Interim Accounting records between the
10 Accounting-Request Start and Stop messages as necessary in accordance with Annex E. The
11 Visited RADIUS server shall forward the RADIUS accounting records to the home or broker
12 network.
13
14 The security of communications between RADIUS servers may optionally be protected with IP
15 security. The establishment of the security association is outside the scope of this specification.
16 See RFC 2865 for additional RADIUS security requirements.
17 5.4 MS Requirements
18 The MS may optionally support Simple IP. The MS may choose Simple IP for IPv4 only, IPv6
19 only, or both IPv4 and IPv6 simultaneously. The MS shall access the cdma2000 packet data
20 service using the cdma2000 air interface [5-9] or HRPD [15].

22 The MS shall use PPP as the data link protocol for Simple IP.
24 The MS shall exchange LCP messages as described in RFC 1661.
25
26 PPP shall support control escaping in accordance with 4.2 of RFC 1662. The PPP Link Layer
27 shall support negotiation of Asynchronous Control Character Mapping as defined in RFC 1662.
28 The MS should negotiate a control character mapping. If the MS negotiates control character
29 mapping, it should attempt the minimum number of escapes by negotiating an ACCM of
30 0x00000000.
32 When the MS deactivates packet data service, the MS should send an LCP Terminate-Request
33 message to the PDSN to gracefully close the PPP session before releasing the packet data
34 service option connections with the RN.
35 5.4.1.3 Authentication
36 The MS shall support CHAP authentication for Simple IP. However, the network operator may
37 configure an MS not to use CHAP. In that case, the MS shall be permitted to skip over the CHAP
38 phase by sending a Configure-Reject message to the PDSN in response to a LCP Configure-
39 Request message that offers the CHAP option.
40
41 The MS may support PAP authentication for Simple IP. If the MS uses PAP, it shall respond to
42 an LCP Configure-Request message for CHAP with an LCP Configure-Nak proposing PAP.
43
44 For both CHAP and PAP, the MS shall send an NAI in the form of user@realm.
46 The MS may support simultaneous operation of IPCP and IPv6CP.
- 26 - 3GPP2
1 The MS may implement RFC 1877 in order to auto configure DNS server IP addresses. The MS
2 may negotiate Primary and Secondary DNS server IP addresses during the IPCP phase. The
3 MS may use default of zero for DNS server address negotiation.

5 For IPv4, the MS should send an IP address of 0.0.0.0 during the IPCP phase to request an IP
6 address from the network. The MS shall accept the address provided by the PDSN. If the MS
7 requests a non-zero IP address during the IPCP phase, the PDSN shall send an IPCP Configure-
8 Nak in response to the request in order to propose a different IP address. The MS shall accept
9 the new address.

11 For IPv6, the MS shall support the following RFCs, with exceptions as noted in this specification:
12 • An IPv6 Aggregatable Global Unicast Address Format [RFC 3587];
13 • Internet Protocol, Version 6 (IPv6) Specification [RFC 2460];
14 • Neighbor Discovery for IP Version 6 (IPv6) [RFC 2461];
15 • IPv6 Stateless Address Auto-configuration [RFC 2462];
16 • Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version
17 6 (IPv6) Specification [RFC 2463];
18 • IP Version 6 over PPP [RFC 2472];
19 • IP Version 6 Addressing Architecture [RFC 3513].
20 The MS should support Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [RFC
21 3041]. To avoid disruption of an active session, e.g., Voice over IP, the MS should not change the
22 IPv6 address used for that session.
23 For IPv6, the MS shall perform interface-identifier negotiation as described in RFC 2472. The MS
24 shall construct the link-local IPv6 address by pre-pending the link-local prefix FE80::/64 [RFC
25 3513] to the interface identifier negotiated during the IPv6CP negotiation phase [RFC 2472].
26 When the Interface-Identifier is negotiated in the IPv6CP phase of the PPP session setup, the MS
27 should not perform duplicate address detection for the link local address as part of IPv6 stateless
28 address auto-configuration [RFC 2462].
29 The MS shall construct global IPv6 addresses by pre-pending the prefix received from the Router
30 Advertisement messages (see the following paragraph) to the interface identifier negotiated
31 during the IPv6CP negotiation phase [RFC 2472] or to the interface identifiers generated using
32 techniques defined in RFC3041. The MS should not perform Duplicate Address Detection for
33 global IPv6 addresses (since the prefix used is a globally unique /64 and exclusive to the PPP
34 session).
35 Following the successful IPv6CP phase and auto-configuration of link-local address, the MS may
36 transmit a Router Solicitation (RS) message(s) if a Router Advertisement message has not been
37 received from the PDSN within a random amount of time between 0 and
38 MAX_RTR_SOLICITATION_DELAY seconds per RFC 2461.
39 The MS may set the upper bound of the delay to a value greater than that specified by the
40 constant MAX_RTR_SOLICITATION_DELAY in RFC 2461. The MS may also set the lower
41 bound of the delay to a value greater than 0. The MS may set the configurable number of RS
42 messages to a value less14 than that specified by the constant MAX_RTR_SOLICITATIONS in
43 RFC 2461. The MS may set the interval between the configurable number of RS messages to a
44 value less14 than or greater than that specified by the constant RTR_SOLICITATION_INTERVAL
45 in RFC 2461.
46 If the last RS message is sent and a RA message is not received after a router solicitation
47 interval, the MS shall send an IPv6CP Configure-Terminate message to the PDSN. Upon
48 reception of a RA message from the PDSN that contains the /64 globally unique prefix, the MS
49 shall perform stateless address auto-configuration for global IPv6 addresses as per RFC 2462
50 (and RFC 3041 for privacy purposes).
14
links.
- 27 - 3GPP2
1 After establishment of a PPP link with the PDSN, the MS shall treat that PDSN as the default
2 router until the PPP session is closed.For IPv6, the MS shall support:
3
4 IPv6 over PPP (or IPv6CP) [RFC 2472]
5 Neighbor discovery for IPv6 [RFC 2461]
6 The IPv6 addressing architecture [RFC 2373]
7 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [RFC 3041]
8 IPv6 stateless address auto-configuration [RFC 2462].
9
10 For IPv6, the MS shall perform interface-identifier negotiation as described in RFC 2472. When
11 the interface-identifier is negotiated in the IPv6CP phase of the PPP connection setup, the MS
12 should not perform duplicate address detection. The MS may also use additional (multiple)
13 identifiers, including randomly generated identifiers in support of RFC 3041.
14
15 The MS shall construct the link-local IPv6 address by pre-pending the link-local prefix FE80: /64
16 [RFC 2373] to the interface identifier received during the IPv6CP negotiation phase [RFC 2472].
17 The MS shall construct the global and site-local IPv6 addresses by pre-pending the prefixes
18 received from the Router Advertisements to the interface identifier received during the IPv6CP
19 negotiation phase [RFC 2472].
20
21 Following the successful IPv6CP phase and establishment of link-local address, the MS may
22 initiate router solicitation messages if a router advertisement has not been received from the
23 PDSN. Upon reception of router advertisements from the PDSN, the MS shall perform address
24 auto-configuration for site-local and global addresses.
25
26 Global and site-local addresses are 128 bit addresses formed by appending the interface
27 identifier to a prefix of appropriate length [RFC 2373].
28 5.4.1.5 Compression
29 The MS shall support Van Jacobson TCP/IP header compression [RFC 1144]. The MS
30 additionally may support the following header compression algorithms:
31
32 • IP Header Compression [RFC 2507]
33 • ROHC over PPP [RFC 3241]
34 • ROHC Framework and four profiles: RTP, UDP, ESP, and uncompressed [RFC 3095]
35
36 The MS shall use IPCP and/or IPv6CP to negotiate with the PDSN one or more header
37 compression capabilities.
38
39 The MS shall support the PPP Compression Control Protocol [RFC 1962]. The MS may support
40 PPP payload compression. If the MS intends to use PPP payload compression, the MS shall use
41 PPP Compression Control Protocol to negotiate a PPP payload compression algorithm supported
42 by the MS.The MS shall support the PPP Compression Control Protocol [RFC 1962]. If the MS
43 uses PPP payload compression, the MS shall use PPP Compression Control Protocol to
44 negotiate a PPP payload compression algorithm, and the MS shall support one of the following
45 compression algorithms:
46 Stac-LZS [RFC 1974]
47 Microsoft Point-To-Point Compression Protocol [RFC 2118]
48 Deflate [RFC 1979]
49
50 The MS may support additional PPP payload compression algorithms.
- 28 - 3GPP2
1 5.4.1.6 PPP Framing

2 The MS shall use the octet-synchronous framing protocol defined in RFC 1662. One exception is
3 there shall be no inter-frame time fill (i.e., no flag octets shall be sent between a flag octet that
4 ends one PPP frame and the flag octet that begins the subsequent PPP frame).15
5 5.4.1.7 PPP Link Status Determination

6 To support Always On service, the MS shall adhere to RFC 1661 section 5.8 “Echo-Request and
7 Echo-Reply” with regards to LCP Echo-Request message processing.
8
15
If the MS consists of a laptop and a relay-model handset, the laptop may send inter-frame time
fill that prevents the mobile from becoming dormant.
- 29 - 3GPP2
1 6 Mobile IPv4 Operation

2 This section describes the requirements and procedures for Mobile IP operation for IPv4 [RFC
3 2002-2006]. In this specification, Mobile IP refers to a service in which the user is able to
4 maintain a persistent IP address even when handing off between RNs connected to different
5 PDSNs. Mobile IPv4 provides the user IP routing service to a public IP network and/or secure IP
6 routing service to private networks.
7 6.1 Common Service Specification

8 The common requirements for several network elements (e.g., PDSN and MS) for Mobile IP
9 operation are described here.

11 See Section 5.1.1.
12
13 For Mobile IP, neither CHAP nor PAP should be performed. If CHAP or PAP is performed, longer
14 initial setup time and re-establishment time will occur as the result of an additional AAA traversal.
15
16 Note that the MN-FA Challenge Extension procedures [RFC 3012] are performed regardless of
17 whether or not CHAP/PAP is performed.
18 6.1.2 Mobile IP
19 The following standards shall be used for Mobile IPv4 operations with any limitations or
20 extensions described in this specification:
21
22 • RFC 2002-2006;
23 • Reverse Tunneling [RFC 3024];
24 • Foreign Agent Challenge/Response [RFC 3012];
25 • NAI Extension [RFC 2794].
26 6.1.3 Dynamic Home Agent and Home Address Assignment

27 In this specification, an MS may request dynamic HA and/or Home Address assignment during
28 the initial MIP registration according to the following scenarios of Table 2 and Table 3 (and also
29 see section 6.5.2.2).
30
31 If the network receives an RRQ from the MS with an HA IP address value of 0.0.0.0, the network
32 shall treat the value as 255.255.255.255 (see section 6.5.2.2).
33
Scenarios Type of Request Home Address Home Agent Address
Scenario 1 Dynamic case 0.0.0.0 255.255.255.255 or
0.0.0.0
Scenario 2 Semi-static case x.x.x.x 255.255.255.255 or
0.0.0.0
Scenario 3 Semi-static case 0.0.0.0 y.y.y.y

Scenario 4 Static case x.x.x.x y.y.y.y
34
35 Table 2 – Home Agent and Home Address Scenarios
36
37
- 30 - 3GPP2
Scenarios Description
Scenario 1 This is for dynamic Home Address assignment and a dynamic HA
assignment.
Scenario 2 In this scenario, the Home RADIUS server shall assign an appropriate HA to
the MS. The Home RADIUS server may use the specified Home Address to
select an HA for the MS.
Scenario 3 This corresponds to dynamic Home Address assignment and static HA
assignment.
Scenario 4 This is for static HA and static Home Address MIP registration, i.e., there is no
dynamic assignment.
1
2 Table 3 – Description of Scenarios
3
4 For details on dynamic HA assignment see the following:
5
6 • Section 6.2.2.4 for the PDSN
7 • Section 6.3.4 for the HA
8 • Section 6.4.1 for the Home RADIUS server
9 • Section 6.5.2.2 for the MS.
10 6.2 PDSN Requirements

11 The PDSN shall support Mobile IPv4 operation.

13 The PDSN shall support multiple Mobile IP Home Addresses over a single PPP session.
15 See Section 5.2.1.1.
17 The Serving PDSN shall close the PPP session if there is no established underlying R-P session
18 or P-P session for the MS, respectively. The PDSN shall clear the R-P session and P-P session,
19 whenever the PPP session is closed. If the PDSN receives IP packets for an MS for which there
20 is no established PPP session for the MS, the PDSN shall silently discard the packet.
21
22 If the PDSN receives a failure code in the RRP from the HA, then the PDSN shall deliver the RRP
23 to the MS, and shall not close the PPP session before a configurable timer expires. If the PDSN
24 generates a failure code, the PDSN shall deliver the RRP to the MS and shall not close the PPP
25 session before a configurable timer expires.
26
27 For Mobile IP service, the PPP inactivity timer shall be set to a value larger than the FA’s
28 maximum allowable values for Mobile IP registration lifetime. Satisfying this requirement may
29 imply over-riding the PDSN's configured PPP Idle Timeout value (attribute 28 in RFC 2865) for
30 this MS with the value received in the RADIUS Access-Accept message.
32 The PDSN shall initially propose CHAP in an LCP Configure-Request message to the MS. The
33 PDSN shall re-send an LCP Configure-Request message without the authentication option after
34 receiving the LCP Configure-Reject (CHAP or PAP) from the MS.

36 When only Mobile IP service is requested by the MS prior to the initial MIP registration, the MS
37 shall not include an IP-Address Configuration Option in the IPCP Configure-Request message to
- 31 - 3GPP2
1 the PDSN. If the MS includes an IP-Address Configuration Option in the IPCP Configure-
2 Request to the PDSN, the PDSN considers this as an MS using Simple IP service. In this case,
3 the PDSN shall send an IPCP Configure-NAK with a new proposed IP address for the MS. The
4 MS should then send an IPCP Configure-Request with the new IP address.
5
6 The PDSN shall not support RFC 2290. If the MS uses the Mobile IPv4 Configuration Option
7 [RFC 2290], the PDSN shall reply with an IPCP Configure-Reject message.
8
9 The PDSN shall implement the IPCP configuration options as defined in RFC 1877 for DNS
10 server address negotiation. The PDSN shall negotiate Primary and Secondary DNS server IP
11 addresses with the MS, if DNS Server Configuration options are received during the IPCP phase.

16 6.2.2 MIP Registration
17 6.2.2.1 Agent Advertisements

18 For the MS that uses Mobile IP, the PDSN shall begin transmission of an operator configurable
19 number of Agent Advertisements immediately following establishment of PPP, or upon receipt of
20 an Agent Solicitation message from the MS. If the MS sends an RRQ to the PDSN, the PDSN
21 shall cease sending Agent Advertisements. Once the PDSN sends the configurable number of
22 Advertisements, the PDSN shall not send further Advertisements, unless it receives an Agent
23 Solicitation message from the MS.
24
25 For Simple IP service, the PDSN shall not send any Agent Advertisements to the MS following
26 establishment of PPP unless the MS sends Agent Solicitation to the PDSN. If the PDSN receives
27 Agent Solicitation from a Simple IP user, the PDSN shall respond with an Agent Advertisement
28 with the 'R' bit set. If the PDSN receives an RRQ with the 'D' bit set, the PDSN shall send an
29 RRP with code 6577. In this case, the PDSN shall not close the PPP session.
30
31 The Mobile IP Registration Lifetime field in the Agent Advertisement shall be smaller than the
32 PPP inactivity timer.
33
34 Upon receiving a handoff indication including SID/NID/PZID of the previous PCF and
35 SID/NID/PZID of the current PCF, if the PDSN already supports a Mobile IP service for the MS,
36 the PDSN shall use this information to determine whether or not Mobile IP re-registration is
37 required for the MS. If re-registration is required, then the PDSN shall re-negotiate PPP and
38 send Agent Advertisements.
39
40 In order to minimize Agent Advertisements sent over the air, the PDSN shall not send unsolicited
41 Agent Advertisements to an MS periodically to refresh the FA advertisement lifetime. The MS
42 may send Agent Solicitations, when the FA advertisement lifetime expires. The Advertisement
43 Lifetime is a configurable value, and shall be set to 9000 seconds (the maximum ICMP router
44 advertisement lifetime).
45 6.2.2.2 Addressing and Mobile IP

46 The PDSN shall support RFC 2794, and therefore, support zero and non-zero Home Address
47 values in the MIP RRQ. For dynamic Home Address assignment, the PDSN shall accept Mobile
48 IP RRQs with a 0.0.0.0 source address from the MS, and shall use the NAI instead of the Home
49 Address in it’s pending registration request records, along with the Identification field [RFC 2794].
- 32 - 3GPP2
1 For dynamic Home Address assignment, the PDSN shall acquire the Home Address from the
2 Mobile IP RRP. In order to provide public network access and to provide private network access
3 across the Internet, the PDSN shall use a publicly routable and visible IP address.
4 6.2.2.3 MIP Extensions

5 The PDSN shall include the MN-FA Challenge Extension [RFC 3012] in the Agent Advertisement.
6 Because Advertisements are rarely sent (to save air resources), the PDSN shall include in the
7 RRP a new challenge that the MS should use in its next re-registration with this PDSN. On re-
8 registration, the PDSN may communicate user FAC authentication information to the Home
9 RADIUS Server, via broker servers, if required, in a RADIUS Access-Request message. The
10 frequency of this re-authentication and re-authorization is configurable by the operator. The
11 challenge shall be changed on a serving access provider configurable basis.
12
13 If the RADIUS attribute “MN-AAA Removal Indication” is included in the RADIUS Access-Accept
14 message, and if the RRQ contains an MN-HA Authentication Extension followed by the MN-FA
15 challenge and MN-AAA Authentication Extension, the PDSN shall remove the MN-FA challenge
16 and the MN-AAA Authentication Extensions when relaying the RRQ to the HA. Otherwise, the
17 PDSN shall relay the RRQ to the HA as received by the MS.
18 6.2.2.4 Dynamic Home Agent Assignment

19 The PDSN shall include the Home Address that it receives in the RRQ message from the MS in
20 the Access-Request message in RADIUS attribute 8 (Framed-IP-Address). The PDSN shall
21 include the HA Address that it receives in the RRQ message from the MS in the RADIUS Access-
22 Request message in the HA attribute (see Annex C). Upon receiving the RADIUS Access-
23 Accept message from the Home RADIUS server containing the assigned HA IP address in the
24 HA attribute, the PDSN shall relay the RRQ message to that HA IP address. Upon receiving an
25 RRP message with successful registration indication (code 0) for the MS, the PDSN shall update
26 the mobility binding for the MS using the HA address, the NAI, and the Home Address if non-zero
27 in the RRQ.
28 6.2.2.5 Private Network Support

29 It is possible that two different MSs served by a PDSN have the same, overlapping private
30 address because they belong to two different private networks. To support this scenario, the
31 PDSN forms a logical association that contains the R-P Connection ID, the MS’s Home Address,
32 and the HA address. When the PDSN receives a packet for a registered MS from the HA, the
33 PDSN maps the MS’s HA address and the Home Address to one association, and transmits the
34 packet on the R-P connection indicated by the R-P Connection ID of the association.
35
36 When processing additional MIP registrations for the same MS, if the PDSN receives an RRP
37 from a second HA that includes a private address as the Home Address, and if the private
38 address has already been assigned to the MS by another HA, the PDSN shall set the Code field
39 to 65 before forwarding the RRP to the MS. The first assigned address is not affected.
40 6.2.2.6 Reverse Tunneling

41 The PDSN shall reject a Mobile IP registration with an error code of 75, if a private Home
42 Address as defined in RFC 1918 is present in either the RRQ or RRP, and the RRQ did not
43 indicate reverse tunneling.
44
45 If the Home RADIUS Server sends a Reverse Tunnel Specification attribute in the RADIUS
46 Access-Accept message indicating that reverse tunneling is required, and the MS did not indicate
47 reverse tunneling in the RRQ, the PDSN shall reject the registration with an error code of 75. If
48 the MS negotiates reverse tunneling, then the PDSN shall reverse tunnel both direct delivered
49 and encapsulated packets. This applies to unicast, multicast, and broadcast IP destination
- 33 - 3GPP2
1 addresses, even if the direct delivery mode is used. See Reverse Tunneling [RFC 3024] for an
2 explanation of direct and encapsulated delivery styles.
3
4 The PDSN shall support both direct delivered and encapsulated packets.
5 6.2.2.7 DNS Address Assignment

6 If the PDSN supports the DNS Server IP Address VSA and NVSE and it receives a DNS Server
7 IP Address VSA in the RADIUS Access-Accept message from the RADIUS server or/and a DNS
8 Server IP Address NVSE in the MIP Registration Reply from the HA, then the PDSN may include
9 each received DNS Server IP Address in a DNS Server IP Address NVSE in the MIP Registration
10 Reply to the MS. The format of the DNS Server IP Address VSA is defined in Annex C, and the
11 format of the DNS Server IP Address NVSE is defined in section 6.6.
12 If the PDSN receives a DNS Server IP Address from both the Visited RADIUS and Home
13 RADIUS servers (entity type 1 and 2), and the PDSN supports the VSA, the PDSN shall
14 determine if the M bit is set in the DNS Server IP Address VSA received in the RADIUS Access-
15 Accept message to select the DNS Server IP Address VSA it forwards to the MS. The DNS
16 Server IP Address VSA with the M bit set, shall have precedence over the VSA that does not
17 have the M bit set. If the PDSN receives a RADIUSn Access-Accept message from the Visited
18 RADIUS server that has DNS IP address VSA(s) with the following values included, then the
19 PDSN shall apply local policies to select the DNS IP Address VSA for DNS information.
20 • An DNS IP Address VSA with the Entity-Type subfield set to the value 1 (=HAAA) and
21 the M bit unset, and/or
22 • One or more DNS IP Address VSA(s) with the Entity-Type subfield set to the value 2
23 (=VAAA).
24 6.2.3 RADIUS Support

25 The PDSN shall act as a RADIUS client in accordance with RFC 2865. On initial mobile access,
26 the PDSN shall communicate user FAC authentication information to the Home RADIUS Server,
27 via the broker RADIUS servers if required, in a RADIUS Access-Request message. On receipt of
28 the RRQ from the MS, and if SPI in the MN-AAA Authentication Extension is set to CHAP-SPI,
29 the PDSN shall create a RADIUS Access-Request message in accordance with Table 4
30
31 If the SPI in the MN-AAA Authentication Extension is set to CHAP SPI as per RFC 3012, the
32 PDSN shall use MD5 when computing the CHAP challenge. If the authentication succeeds, the
33 Home RADIUS server shall send a RADIUS Access-Accept message to the PDSN. If the
34 authentication fails, the Home RADIUS server shall send a RADIUS Access-Reject message to
35 the PDSN.
36
37 The inclusion of the NAS-IP-Address or the NAS-IPv6-Address, or both in the RADIUS Access-
38 Request message, depends on whether the PDSN has an IPv4 address or IPv6 address, or both.
39
40 The PDSN shall act as a RADIUS accounting client in accordance with RFC 2866 and shall
41 communicate user accounting information to the Visited RADIUS server in RADIUS Accounting-
42 Requests. The PDSN shall determine at completion of the IPCP phase that an Accounting-
43 Request (Start) record shall be sent to the RADIUS server following a successful Mobile IP
44 Registration Reply received from the HA. The Accounting-Request (Start) record shall contain
45 the Account Session ID and Correlation ID attribute generated by the PDSN.
46
47 The security of communications between PDSN and RADIUS server may optionally be protected
48 with IP security. The establishment of security is outside the scope of this specification.
49 6.2.4 IP Security Support

50 There may be a statically configured shared key for computing the Mobile IP HA-FA
51 Authentication Extension in Mobile IP registration messages. If such a shared key exists, the
52 PDSN and HA shall use it. Additional Security Associations (SAs) between the PDSN and HA
- 34 - 3GPP2
1 may also be supported for the protection of Mobile IP control messages and user data. This
2 specification supports the following options for the establishment of such additional SAs:
3
4 • Public certificates16
5 • Dynamic pre-shared IKE secret distributed by the Home RADIUS Server
6 • Statically configured IKE pre-shared secret.
7
8 The PDSN shall support IPSec and IKE. An SA between the PDSN and the HA may be
9 established using X.509 based certificates, or a pre-shared secret for IKE that may be statically
10 configured or dynamically provisioned by the Home RADIUS server. ESP is preferred and shall
11 be implemented. AH shall also be implemented in order to maintain backwards compatibility with
12 previous versions of this specification.
13
14 In the case of a carrier owned HA, and if mandated by carrier policy, the PDSN shall have a SA
15 with the HA in order for a RRQ to be successfully processed. The SA may formally be via IPSec
16 (i.e., ESP or AH) or via a Mobile IP HA-FA Authentication Extension.
17
18 An SA between the PDSN and the HA shall be established as follows:
19
20 When receiving a MIP RRQ containing a unicast HA IP address, the PDSN shall verify if a SA
21 currently exists with the HA. If an SA does not exist and one is required, the PDSN shall verify if
22 HA X.509 certificates exists. If no HA X.509 certificate exists, the PDSN shall verify if a root
23 certificate exists. If the necessary certificates do not exist, the PDSN shall verify if a statically
24 configured pre-shared secret for IKE exists. If the static pre-shared secret for IKE is also not
25 available, it shall include a request for a pre-shared secret for IKE in the RADIUS Access-
26 Request message. The Home RADIUS server shall include the pre-shared secret for IKE and a
27 KeyID in the RADIUS Access-Accept message if IPSec services are authorized for the user.
28
29 When dynamic HA assignment is used by the MS (scenario 1 and 2 from Section 6.1.3), the
30 PDSN shall always request the IKE pre-shared Secret from the Home RADIUS server. IPSec
31 support for dynamic HA assignment is further described in Section 6.2.4.2.
32 6.2.4.1 IPSec Service Authorized

33 If the home network authorizes IPSec services, the PDSN shall not forward an RRQ to the HA
34 unless an IPSec SA exists first. The PDSN shall send a failed RRP with an error code of 65 to
35 the MS if it is unable to establish an IPSec SA to the HA and IPSec security is authorized by the
36 Home RADIUS Server. The Home RADIUS Server authorizes the PDSN to either use an
37 existing SA with the corresponding HA or to establish a new SA if no prior SA exists. The PDSN
38 shall apply the same security service for all the MSs served by the same HA.
39
40 If an IPSec SA does not exist and IPSec is authorized, the PDSN shall establish a SA using IKE
41 with either X.509 or root certificates, or statically configured pre-shared secret for IKE, or
42 dynamically distributed pre-shared secret for IKE. The PDSN shall comply with the specifications
43 in IKE [RFC 2409] and the Annexes A and B in this specification.
44
45 The PDSN shall provide IPSec services as indicated by the Security Level attribute included in
46 the RADIUS Access-Accept message. The Security Level attribute included in the RADIUS
47 Access-Accept message allows the Home RADIUS server to indicate whether IP security should
48 be applied to MIP registration messages and MIP tunneled data between the HA and the PDSN,
49 or not to use IPSec at all. The same security level shall be applied for all users using the same
50 Home Agent. If the PDSN receives the deprecated value of '1' or '2', the PDSN shall use a
51 default value of '3'.
52
16
Refer to Annex A and B for details.
- 35 - 3GPP2
1 If reverse tunneling is required and IPSec security is authorized for tunneled data, then the PDSN
2 shall provide security on the reverse tunnel.
3
4 If the PDSN does not receive the Security Level attribute from the Home RADIUS server, and an
5 IPSec SA to the HA already exists, the PDSN shall continue to use the same SA. If it receives a
6 new pre-shared key and an SA already exists, the PDSN shall not renegotiate the ISAKMP SA. If
7 no SA exists, then the PDSN shall follow local security policy.
8
9 If an IPSec SA to protect control messages already exists with the HA, the PDSN shall ensure
10 the IPSec SA is maintained throughout the Mobile IP registration lifetime by periodically
11 refreshing the SA.
12 6.2.4.2 IPSec Service Not Authorized

13 If the Home RADIUS server does not authorize security for the MS, the PDSN shall not delete
14 existing IPSec SA with an HA. This is because IPSec should be authorized per PDSN-HA pair
15 and thus other MSs may be using the same IPSec SA.
16 6.2.4.3 Dynamic HA Assignment

17 When the PDSN receives a MIP RRQ containing a HA IP address of 255.255.255.255 (or
18 0.0.0.0), it shall always include the IKE Pre-shared Secret Request attribute in the RADIUS
19 Access-Request sent to the Home RADIUS server. The Home RADIUS server responds with a
20 RADIUS Access-Accept containing the allocated HA address and if IPSec services are
21 authorized for the user, the corresponding dynamic pre-shared secret and KeyID for IKE should
22 also be included. The PDSN shall verify if IPSec services are authorized by the presence of the
23 Security Level attribute. When IPSec service is authorized for the user, the PDSN shall then
24 determine from the received HA address whether an IPSec SA already exists. If an SA does not
25 exist, the PDSN shall determine if certificates or static pre-shared secret for IKE exist for the HA,
26 otherwise the pre-shared secret for IKE, if provided by the Home RADIUS server, shall be used
27 to establish the required SA.
28
29 If an SA already exists with the HA, the PDSN shall use the existing SA as is.
30 6.2.5 Ingress Address Filtering

31 Upon receiving a packet from the MS, the PDSN shall discard the packet if one of the following
32 conditions holds:
33 • the packet is received while the PPP negotiation is in progress (state is not open),
34 • the packet is received while MIP registration is pending17, but the source IP address
35 of the packet is invalid18, and the packet is not a MIP control packet (MIP RRQ or
36 Agent Solicitation).
37 For a Mobile IP session establishment over a Simple IP session, at the Simple IP establishment,
38 1. if the MS sends an Agent Solicitation to the PDSN, the PDSN shall respond with an
39 Agent advertisement and shall discard all IP packets with an invalid source IP
40 address while MIP registration is pending17.
41 2. If the MS doesn’t send Agent Solicitations but sends IP packets with an invalid
42 Source IP address, the PDSN may discard the packets and may send an Agent
43 Advertisement to the MS. If the PDSN sends Agent Advertisements to the MS as a
44 result of an Invalid Source IP address, it shall discard all IP packets with an invalid
45 source IP address while MIP registration is pending17.
46 If the PDSN receives an implementation-defined number of consecutive packets with an invalid
47 source IP address from the MS, the PDSN shall send an LCP Configure-Request message to the
48 MS.If the MS fails to register with the PDSN and continues to send IP packets with invalid source
17
i.e., between the NCP open state and completion of MIP registration.
18
The source IP address from the MS is considered as invalid if it is not one of the addresses
that have been assigned to the MS or if the MS has not been assigned any IP addresses.
- 36 - 3GPP2
1 IP address, the PDSN shall discard the packets and shall send an LCP Configure-Request
2 message to the MS to renegotiate the PPP session.See section 5.2.3 as it relates to IPv4.
3 6.3 Home Agent Requirements

4 The HA shall support basic MIP [RFC 2002-2006], reverse tunneling [RFC 3024], FAC [RFC
5 3012], and Mobile IP NAI Extension [RFC 2794]. In order to provide public network access and
6 private network access across the public network, the HA shall use a globally routable and visible
7 IP address.
8 6.3.1 Multiple Registrations

9 The HA shall support multiple registrations with the same NAI but different static Home
10 Addresses.:
11
12 Multiple registrations for the same NAI as long as each registration requests a different
13 non-zero address.
14 Multiple registrations for different NAIs.
15 6.3.2 MIP Authentication Support

16 When the HA receives an RRQ from a PDSN, it authenticates the RRQ using the MN-HA shared
17 key. At initial registration, the HA may not have the MN-HA shared key, the HA shall retrieve the
18 MN-HA shared key from the Home RADIUS server. Based on the policy of the home network,
19 the HA may also process the MN-AAA Authentication Extension as specified in RFC 3012, if
20 included in the RRQ.
21
22 If the HA policy dictates that the HA shall process the MN-AAA Authentication Extension, then the
23 HA shall authenticate the request by including the following attributes in a RADIUS Access-
24 Request message to the Home RADIUS server:
25
26 • User-Name (1) = MN-NAI field in the MN-NAI Extension
27 • CHAP-Password (3) =
28 • CHAP Ident field = High-order byte of the Challenge Field in the MN-FA Challenge
29 Extension
30 • String field = Authenticator field from the MN-AAA Authentication Extension
31 • CHAP-Challenge (60) = MD5 (Preceding MIP RRQ, Type, Subtype, Length, SPI),
32 followed by the least-order 237 bytes of the Challenge Field in the MN-FA Challenge
33 Extension. The MD5 checksum is computed over the MIP RRQ data preceding the MN-
34 AAA Authentication Extension and the Type, Subtype, Length, SPI fields of the MN-AAA
35 Authentication Extension.
36 • MN-HA SPI = to request the MN-HA shared key if not available at the HA. The MN-HA
37 shared key corresponds to a single user’s NAI or NAI and non-zero static IP address
38 pair.
39
40 If the MN-AAA Authentication Extension is not present in the RRQ or HA policy dictates that the
41 HA shall not process the MN-AAA Authentication Extension, and the HA requires the MN-HA
42 shared key from the RADIUS server, the HA shall send a RADIUS Access-Request19 that
43 includes a User Name, a User-Password and an MN-HA SPI.
44
45 The Home RADIUS server shall process the Access-Request. If the MN-HA shared key is
46 requested, the Home RADIUS server shall encrypt the MN-HA shared key in a RADIUS Access-
47 Accept using a method based on the RSA Message Digest Algorithm MD5 [RFC 1321] as
48 described in Section 3.5 of RFC 2868.
49
19
Construction of the message is implementation dependent.
- 37 - 3GPP2
1 The HA shall save the MN-HA shared key received from the Home RADIUS server for the
2 duration of the MIP session with the MS. Based on the local policy, the HA may store the MN-HA
3 shared key a certain time skew after releasing the mobility binding for the MS.
4 6.3.3 IPSec Support

5 The HA shall determine which type of security associations (if any) are required with a PDSN.
6 The HA shall use the same security policy as specified in the Home RADIUS server and returned
7 to the PDSN in the Security Level attribute.
8 The policy may be locally configured at the HA or may be obtained from the Home RADIUS
9 server in the security level attribute.
10 If IPSec is authorized and no SA is currently in place, the HA shall participate in ISAKMP and IKE
11 negotiation with the PDSN. The negotiation will result in establishing an IPSec SA that will be
12 used for all traffic between the HA and the PDSN.
13 Security associations may be authorized for MIP control and/or payload tunnels. Also, IKE
14 negotiation results in all MSs on a given PDSN belonging to the same HA receiving the same
15 security between the PDSN and HA for either registration messages and/or tunneled data.
16
17 The HA shall perform a similar operation as the Home RADIUS server to generate the pre-shared
18 secret for IKE (K), see algorithm for K in Section 6.4.3.
19
20 When an IKE request is received, the HA shall validate the timestamp in the KeyID field. This
21 timestamp eliminates the possibility of re-using a previously generated shared-key for IKE ‘K’
22 value while the secret key ‘S’ is still valid on the HA. The HA shall also use the 'S' Key indexed
23 by Home RADIUS server IP address from the KeyID field.
24
25 If there is no previously assigned 'S' Key, the S key is not found, or the timestamp in the KeyID is
26 greater than the ‘S’ expiration time, then the HA shall send a RADIUS Access-Request message
27 to the Home RADIUS server to request the S key.
28
29 That RADIUS Access-Request message shall contain
30
31 • The user name attribute consisting of a concatenation of the PDSN’s CoA and HA
32 address
33 • The ‘S’ Request attribute
34
35 The RADIUS Access-Accept message from the Home RADIUS server shall include the 'S' Key
36 and its lifetime, and may include the Security Level attribute. The HA shall save the 'S' Key
37 received from the Home RADIUS servers.
38
39 The HA shall compute the pre-shared secret “K” using KeyID (Annex C) and the 'S' Key (see
40 Section 6.4.3).
41
42 Each HA shall have a configurable, allowable time skew to be used to validate the freshness of
43 ‘K’.
44
45 The HA shall maintain expired ‘S’ keys for a configurable amount of time. This expired key shall
46 be used when KeyIDs are received that refer to the expired 'S' Key but falls within the allowable
47 time skew20.
48
49 The security method used between the HA and the Home RADIUS server is outside the scope of
50 this specification.
20
The skew serves to solve the case where RADIUS or IKE messages are lost and must be
transmitted yet the 'S' Key expires in the meantime. An example of the skew could be one
minute.
- 38 - 3GPP2
1
2 However, the Home RADIUS server may encrypt the 'S' Key and the 'S' Lifetime using a method
3 based on the RSA Message Digest Algorithm MD5 [RFC 1321] as described in Section 3.5 of
4 RFC 2868.
5
6 If mandated by carrier security policy, a carrier HA shall have a SA with the PDSN in order for a
7 registration request to be successfully processed. The SA may formally be via IPSec (e.g., ESP
8 or AH) or via a Mobile IP HA-FA Authentication Extension. Likewise, a HA shall accept or reject
9 a RRQ received directly from an MS with a 'D' bit set depending on security policy.
10 6.3.4 Dynamic Home Agent Assignment

11 During dynamic HA assignment, the HA IP address that is specified by the MS in the RRQ
12 message and the IP address of the dynamically assigned HA may not be the same. Upon receipt
13 of such a RRQ message in an IP packet with the destination IP address set to the HA unicast IP
14 address, the HA may accept the RRQ contrary to the specification in RFC 2002 or may reject it
15 with an error code of 136 in accordance with RFC 2002. The HA shall follow the procedures
16 described in Section 6.3.2 to complete its authentication process for the RRQ message. The HA
17 shall put its IP address in the HA IP address field of the RRP message to the MS.
18 6.3.5 DNS Address Assignment

19 The DNS server IP addresses may be configured at the HA, or received from the Home RADIUS
20 server in a RADIUS Access-Accept message. If the HA does not receive the DNS Server IP
21 Address VSA from the Home RADIUS server, then the HA may include configured21 DNS server
22 IP addresses in the DNS Server IP Address NVSE. If the HA includes the configured DNS server
23 IP addresses in the DNS Server IP Address NVSE, it shall set the Entity-Type field to 3 (see
24 section 6.6), and send the NVSE in a MIP Registration Reply message. If the HA receives the
25 DNS Server IP Address VSA from the Home RADIUS server, the HA may include the received
26 DNS server IP addresses in the DNS Server IP Address NVSE. If the HA includes the received
27 DNS server IP addresses in the DNS Server IP Address NVSE it shall set the Entity-Type field to
28 1 (see section 6.6) and send the NVSE in a MIP Registration Reply message
29
30 6.4 RADIUS Server Requirements

31 See Section 5.3.
32
33 In order to provide the functions defined in this specification, the Home and Visited RADIUS
34 servers shall support the attributes listed in Table 4, in addition to the standard RADIUS
35 attributes. The Broker RADIUS server shall support the decryption and re-encryption of the Pre-
36 shared Secret attribute and the MN-HA Shared Key attribute.
37
38
21
The DNS information may be pre-configured in the HA or the HA may acquire the DNS
information via other schemes.
- 39 - 3GPP2
Attribute Name Type Access- Access- Interface(s)

Request Accept
User-Name 1 M M PDSN -> AAA
HA -> AAA
User Password 2 O Note 1 HA -> AAA
CHAP-Password 3 M Note 2 PDSN -> AAA
HA -> AAA
CHAP-Challenge 60 OM Note 2 PDSN -> AAA
HA ->AAA
NAS-IP-Address 4 O22 Note 3 PDSN -> AAA
NAS-IPv6-Address 95 23 O Note 4 PDSN -> AAA
Foreign Agent Address 26/79 O PDSN -> AAA
Correlation ID 26 / 44 M O PDSN <-> AAA
Home Agent 26 / 7 M M PDSN <-> AAA
Framed-IP-Address 8 M O PDSN <-> AAA
IKE Pre-shared Secret Request 26 / 1 O PDSN -> AAA
Security Level 26 / 2 O AAA -> PDSN,
AAA -> HA
Pre-shared Secret 26 / 3 O AAA -> PDSN
Reverse Tunnel Specification 26 / 4 O AAA -> PDSN
KeyID 26 / 8 O AAA -> PDSN
‘S’ Key 26 / 54 O AAA -> HA
‘S’ Lifetime 26 / 56 O AAA -> HA
‘S’ Request 26 / 55 O HA -> AAA
MN-HA Shared Key 26 / 58 O AAA -> HA
MN-HA SPI 26 / 57 O HA -> AAA
Allowed Differentiated Services 26 / 73 O AAA -> PDSN
Marking
DNS Update Required 26 / 75 O AAA -> HA
Always On 26 / 78 O AAA -> PDSN
Service Option Profile 26 / 74 O AAA -> PDSN
Remote IPv4 Address 26 / 59 O AAA -> PDSN
Remote IPv6 Address 26 / 70 O AAA -> PDSN
Remote Address Table Index 26 / 71 O AAA -> PDSN
MN-AAA Removal Indication 26 / 81 O AAA->PDSN
NAS-Port-Type24 61 O Note 5 PDSN -> AAA
1
2 (M) Indicates Mandatory attribute
3 (O) Indicates optional attribute
4 Note 1: The password is configured between the HA and the AAA.
5 Note 2: For Mobile IP, this attribute is mandatory for the PDSN, and optional for the HA.
6 Note 3:This is the IPv4 address of the RADIUS server interface of the PDSN; at least one of
7 NAS-IP-Address or NAS-IPv6-Address shall be included.
8 Note 4: This attribute is included if the PDSN supports IPv6 addressing.
9 Note 5: The values are as follows: 22 (IS-2000) [5-9] or 24 (HRPD) [15], depending on the
10 service option number connected to the PDSN.
11 Table 4 – Occurrence of RADIUS Attributes for Mobile IP
22
This is the IPv4 of the RADIUS server interface of the PDSN; at least one of NAS-IP-Address
or NAS-IPv6-Address must be included.
23
This attribute is included if the PDSN supports IPv6 addressing.
24
The values are as follows: 22 (cdma2000) [5-9] or 24 (HRPD) [15], depending on the service
option number connected to the PDSN.
- 40 - 3GPP2
2 6.4.1 Dynamic Home Agent Assignment

3 The RADIUS based HAAA shall implement a HA selection algorithm to perform dynamic HA
4 assignment. The implementation details of this algorithm are outside the scope of this
5 specification. The HA selection algorithm shall satisfy the four scenarios described in Section
6 6.1.3. The HAAA shall return the assigned HA IP address in the HA attribute in the RADIUS
7 Access-Accept message to the PDSN.
8 6.4.2 MN-HA Shared Key Distribution

9 Upon receipt of a RADIUS Access-Request message from a HA containing the MN-HA SPI
10 attribute, the RADIUS server shall send a RADIUS Access-Accept message containing the MN-
11 HA shared key encrypted using a method based on RSA MD5 [RFC 1321] as described in
12 Section 3.5 of RFC 2868.
13 6.4.3 Dynamic Key Distribution Procedure

14 When the RADIUS Access-Request is received from the PDSN containing the IKE Pre-shared
15 Secret Request attribute, and IPSec services are authorized for the user, the Home RADIUS
16 server shall distribute a key identifier and pre-shared secret for IKE to the PDSN using the Pre-
17 shared Secret and KeyID attributes in the RADIUS Access-Accept message. The Home
18 RADIUS server generates a pre-shared secret for IKE by processing the Home RADIUS IP
19 address, FA IP address, and a timestamp as well as a secret key, known as the 'S' Key, through
20 the HMAC-MD5 hashing algorithm. The 'S' Key is known between the Home RADIUS server and
21 the HA. The 'S' Key is retrieved by the HA from the Home RADIUS server and has a
22 configurable lifetime. The lifetime of the 'S' Key is a Home RADIUS local policy, and is based on
23 the cryptographic strength of the ‘S’ Key. The pre-shared secret is generated using the following
24 formula:
25
26 K = HMAC-MD5 (Home RADIUS IP address | FA IP address | timestamp, ‘S’)
27
28 The Home RADIUS server hides pre-shared secrets for IKE using a method based on the RSA
29 Message Digest Algorithm MD5 [RFC 1321] as described in Section 3.5 of RFC 2868.
30 6.4.4 DNS Address Assignment

31 The RADIUS server may include the DNS Server IP Address VSA in the RADIUS Access-Accept
32 message in response to a RADIUS Access-Request message from the PDSN and/or the HA. If
33 the RADIUS server includes the DNS Server IP Address VSA, it shall include a Primary and a
34 Secondary DNS server IP addresses. The status of the ‘M’ bit in the DNS Server IP Address VSA
35 is controlled by the Home RADIUS server.
36 6.5 Mobile Station Requirements

37 The MS may support Mobile IPv4 service. The MS shall access cdma2000 packet data service
38 using the cdma2000 air interface [5-9] or HRPD [15].

40 The MS shall use PPP as the data link protocol for Mobile IP. The MS may support multiple
41 Mobile IP Home Addresses over a single PPP session.
43 Same as Section 5.4.1.1.
- 41 - 3GPP2
1
2 When the MS tries to register and receives an RRP message with a failure code, it shall do one
3 of the following:
4
5 • Retry Mobile IP registration over the existing PPP session.
6 • If existing Simple IP or Mobile IP sessions exist, give up on the failed Mobile IP
7 registration and continue using the existing sessions.
8 • Fall back to Simple IP by re-negotiating the PPP session.
9 • Terminate the PPP session.
11 The MS should not use CHAP or PAP for Mobile IP. When the MS receives an LCP Configure-
12 Request message requesting CHAP authentication, the MS should reply with an LCP Configure-
13 Reject message requesting no PPP authentication. The PDSN shall re-send an LCP Configure-
14 Request message without the authentication option after receiving the LCP Configure-Reject
15 message from the MS. The MS shall respond with an LCP Configure-Ack message as described
16 in RFC 1661.
17
18 If CHAP is performed, performance degradation will occur as the result of an unnecessary AAA
19 traversal.
20
21 FAC shall be performed regardless of whether or not CHAP is performed. The MS shall use the
22 challenge received in the Agent Advertisement or RRP to compute the MN-AAA authenticator.
23
24 As a further clarification to RFC 3012 section 8 (SPI For RADIUS AAA Servers):
25
26 If the challenge has fewer than 238 bytes, this algorithm includes the high-order byte in the
27 computation twice, but ensures that the challenge is used exactly as is. Additional padding is
28 never used to increase the length of the challenge; the input data is allowed to be shorter
29 than 237 bytes long.

31 If the MS uses Mobile IP only, the MS shall not use the IP-Address Configuration Option [RFC
32 1332]. On subsequent PPP session establishments while the MS intends to maintain a home IP
33 address, the MS shall omit the option25. Since the PDSN does not support RFC 2290, if the MS
34 uses the Mobile IPv4 Configuration Option, the PDSN replies with an IPCP Configure-Reject
35 message.
36
37 The MS may implement RFC 1877 in order to auto configure DNS server IP addresses. The MS
38 may negotiate Primary and Secondary DNS server IP addresses during the IPCP phase. The
39 MS may propose a DNS server address of zero to indicate an explicit request that the PDSN
40 provide the DNS server address information in a Configure-Nak.

25
If the MS that uses Mobile IP uses the IP-Address Configuration Option [RFC-1332] to indicate
the Home Address, the PDSN will consider it as an MS using Simple IP service and send a NAK
with an alternative address to the MS. The MS will respond with an IP Configure Request with
the alternative address.
- 42 - 3GPP2
1 6.5.2 MIP Registration
2 6.5.2.1 Agent Discovery

3 Immediately after a PPP session is established, the MS may send Agent Solicitations. In this
4 case, the MS should use the same procedure as described in Section 2.4 of RFC 2002. If the
5 MS does not have a Home Address, the MS shall use zero in the Source IP Address field of the
6 IP packet that contains the Agent Solicitation. The MS shall support RFC 3012.
7 6.5.2.2 Registration Messages

8 Upon receiving Agent Advertisements from the PDSN, the MS shall send an RRQ message.
9
10 The MS may request a non-zero home IP address belonging to its home IP network in the RRQ
11 or indicate that the HA should dynamically assign it an IP address. If the MS requests a dynamic
12 HA assignment, the MS shall set the HA IP address to either 255.255.255.255 or 0.0.0.0.
13 However, the MS should use 255.255.255.255. If the MS requests a static or already allocated
14 HA, it should set the HA IP address accordingly.
15
16 The Home and HA address allocations are based on the scenarios described in Section 6.1.3.
17
Scenario 1 To request a dynamic Home Address and a dynamic HA assignment, the MS shall
set the Home Address field to 0.0.0.0 and the HA address field to 255.255.255.255
or 0.0.0.0 in the RRQ message.
Scenario 2 To request a dynamic HA assignment only while requesting a previously assigned
Home Address, the MS shall set the Home Address field to the desired Home
Address, and the MS shall set the HA address field to 255.255.255.255 or 0.0.0.0 in
the RRQ message. If the MS receives a failed RRP, the MS may retry a MIP
registration under any of the scenarios.
Scenario 3 To request a dynamic Home Address allocation only while requesting a previously
assigned HA, the MS shall set the Home Address field to 0.0.0.0 and the MS shall
set the HA address field to the desired HA address in the RRQ message. If the MS
receives a failed RRP, the MS may retry a MIP registration under any of the
scenarios.
Scenario 4 When the MS is not requesting dynamic allocation of either a Home Address or a
HA address, the MS shall set the Home Address and HA address fields with the
desired IP addresses in the RRQ message. If the MS receives a failed RRP, the
MS may retry a MIP registration under any of the scenarios.
18
19 Table 5 – MS Registration Scenarios
20
21 While requesting a dynamic Home Address allocation, the MS shall use zero in the Source IP
22 Address field of the IP packet that contains the Mobile IP RRQ. In this case the NAI is used to
23 identify the MS.
24
25 During MIP re-registrations, the MS shall use the same HA IP address and the Home Address
26 that were assigned to it during the initial MIP registration.
27
28 Upon receipt of an RRP message with successful registration indication (code 0) during initial
29 registration, the MS shall accept the dynamically assigned HA address contained in the RRP
30 message, even if it is different from the HA address provided in the RRQ message.
31
32 If the MS had set up a Simple IP session and decides to run Mobile IP simultaneously using the
33 FA function in the PDSN, it shall send an Agent Solicitation to the PDSN. Upon receiving an
34 Agent Advertisement, the MS shall register with the PDSN and shall not use collocated CoA. The
- 43 - 3GPP2
1 MS may also register directly with the HA using a collocated CoA obtained from Simple IP IPCP
2 negotiation.
3
4 If the MS desires reverse tunneling, the MS shall set the T-bit in the RRQ message.
5
6 The MS shall not set the 'V' bit in the RRQ message.
7 6.5.2.3 MIP Extensions

8 The MS shall include the MN-NAI Extension [RFC 2794], MN-HA Authentication Extension [RFC
9 2002], MN-FA Challenge Extension [RFC 3012], and MN-AAA Authentication Extension [RFC
10 3012] in the RRQ message. Because advertisements are rarely sent to save air resources, the
11 MS should use the challenge value contained in the last received RRP in the case of re-
12 registrations as described in RFC 3012.
13
14 The MS shall compute the MN-AAA Authentication Extension, according to RFC 3012, based on
15 the shared secret the MS has with the Home RADIUS server. The MS shall compute the MN-HA
16 Authentication Extension, according to RFC 2002, based on the shared secret the MS has with
17 the HA. Computation of the extension shall include the Type and SPI field of the MN-HA
18 Authentication Extension itself. The MS may use the same shared-secret or different shared
19 secrets in the computation of the MN-AAA Authentication Extension and MN-HA Authentication
20 Extension. This is coordinated between the MS and its home network.
21 6.5.2.4 Private Network Support

22 If the MS wants private network access through Mobile IP, the MS shall use reverse tunneling.
24 When the MS wishes to terminate a MIP session, the MS may send a Mobile IP RRQ to the HA
25 with a Registration Lifetime of zero to gracefully close the MIP session before terminating the
26 packet data service with the RN26.
27 6.5.2.6 DNS address Assignment

28 If the MS receives at least one DNS Server IP Address NVSE (as defined in section 6.6) in the
29 MIP Registration Reply message, then the MS may use the DNS server IP address in the NVSE
30 instead of the DNS server IP address received during IPCP. If the MS receives multiple DNS
31 Server IP Address NVSEs, it may select an appropriate entity (i.e., HAAA/VAAA or HA), for
32 acquiring the DNS information, based on its internal policy.
33 If Reverse Tunneling is applied for the MIP session, and the MIP Registration Reply includes at
34 least one DNS Server IP Address NVSE with the entity-type field set to either 1 or 3 and the MS
35 supports the DNS Server IP Address NVSE, then the MS shall use the DNS server IP addresses
36 provided in the MIP Registration Reply. If the entity type is 3, the DNS information provided by
37 the HA may have precedence over that provided by the HAAA or the VAAA.
38 6.6 DNS Server IP Address NVSE

39 The NVSE contains a Primary and a Secondary DNS IP address and may be included in the MIP
40 Registration Reply message from the HA and/or the PDSN. The format of the NVSE shall be as
41 follows:
42
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Type Length Reserved
Vendor/Org-ID
26
The MS should send the RRQ with a lifetime of zero to free resources such as public
addresses in the HA.
- 44 - 3GPP2
Vendor-NVSE-Type Entity-Type Sub-Type1

Length Primary DNS IPv4 address
……….. Sub-Type2 Length Secondary DNS
IPv4 address
……………………….. Unused
1 Figure 12- NVSE for DNS server IP address
2
3 Type: 134
4 Length = 22
5 Vendor/Org-ID: 5535
6 Vendor-NVSE-Type: 17
7 Vendor-NVSE-Value: This field is formatted as follows:
8 Entity-Type: In the Registration Reply message this field identifies the
9 network entity that has provided the DNS information to the mobile station
10 so that it is aware of the source of the DNS information. Currently the
11 following types are defined:
12 HAAA = 1
13 VAAA = 2
14 HA = 3
15 Sub-Type1 (=1): This field indicates that the associated value field contains
16 the Primary DNS server IP address.
17 Length: 6
18 Vendor-Value: IPv4 address of primary DNS server.
19 Sub-Type (=2): This field indicates that the associated value field contains
20 the Secondary DNS server IP address.
21 Length: 6
22 Vendor-Value: IPv4 address of secondary DNS server.
23
24
25
- 45 - 3GPP2
1 7 Simultaneous Service
2 The PDSN shall support, and the MS may support, any of the following simultaneous packet data
3 session combinations:
4
5 • Simple IPv4 service & Simple IPv6 service
6 • Simple IPv4 service & Mobile IPv4 service
7 • Simple IPv6 service & Mobile IPv4 service
8 • Simple IPv4 service & Simple IPv6 service & Mobile IPv4 service
9
10 Additionally, multiple Mobile IPv4 sessions may be operated simultaneously. Although any of
11 these may run simultaneously, individual services are distinct. Within a single PPP session, the
12 PDSN shall support simultaneous operation of IPCP [RFC 1332] and IPv6CP [RFC 2462].
13 Simultaneous services are supported through re-negotiation of IPCP, IPv6CP, or MIP as
14 appropriate.
15
16 Each packet data sessions shall be authenticated and authorized independently. In addition,
17 each such session shall have unique accounting records. However, simultaneous Simple IPv4
18 and Simple IPv6 share a common authentication and authorization procedure as described in
19 Section 5.2.2.
20
- 46 - 3GPP2
1 8 IP Reachability Service
2 IP Reachability Service is the capability to update a DNS server in the home network with the
3 current authorized MS IP address. When the MS desires to be reached by a DNS hostname,
4 the Home RADIUS server (in the case of Simple IP or Mobile IP) or the HA (in the case of
5 Mobile IP only) may send a DNS Update [RFC 2136] to a DNS server to add an A Resource
6 Record.
7 The Update section of the DNS Update message contains the following values in ‘Host
8 address’ Resource Type Resource Record:
9
10 • Resource Name = username.realm27
11 • Resource Class = Internet address class
12 • IP Address = newly assigned IP address
13 The TTL (Time To Live) of the Update section in the DNS Update message should be zero so
14 that all queries for the address are resolved using the up to date authoritative server for the
15 user. This is because after the MS is assigned a different address, if the TTL were non-zero,
16 the cache entry of the querying endpoint would no longer be valid, and, in fact, the address
17 may have been given to a different MS.
18
19 The security between the DNS Server and Home RADIUS server or the HA is outside the scope
20 of this specification.
21
22 The method used by the Home RADIUS server and/or HA to determine the IP address of the
23 DNS server is outside the scope of this specification.
24
25 Multiple registrations for the same NAI shall not be permitted if the home network supports IRS
26 for the MS.
27 8.1 Simple IP Operation

28 When the Home RADIUS server receives a RADIUS Accounting-Request (Start) record
29 containing the Beginning-Session attribute and the IP-Technology attribute that indicates Simple
30 IP and the Home RADIUS server is configured to send DNS Update messages, the Home
31 RADIUS server shall request that the DNS server add an A Resource Record for the MS.
32 When the Home RADIUS server receives a RADIUS Accounting-Request (Stop) record for a
33 session, and the Home RADIUS server is configured to send DNS update messages, and the
34 Session-Continue attribute is either FALSE or absent, and the IP-Technology attribute indicates
35 Simple IP, the Home RADIUS server shall request that the DNS server delete the Resource
36 Record for the MS.
37 8.2 Mobile IP Operation

38 The DNS server may be updated by either the Home RADIUS server or the HA.
39 8.2.1 DNS Update by the Home RADIUS Server

40 If the Home RADIUS server receives a RADIUS Accounting-Request (Start) record containing
41 the Beginning Session attribute and the IP-Technology attribute indicates Mobile IP and the
42 Home RADIUS server is configured to send DNS Update messages for the Mobile IP sessions,
43 the Home RADIUS server shall request that the DNS server add an A Resource Record for the
27
The MS sends the NAI as ‘username @ realm’, and the Home RADIUS Server converts the
username@realm into ‘username.realm’. When the HA performs DNS update, the HA shall
convert the username@realm to username.realm.
- 47 - 3GPP2
1 MS. The Home RADIUS server caches the User Name, NAS IP Address, and Framed IP
2 address as received in the Accounting-Request (Start) record for the MS. If the “beginning
3 session” attribute is not included in the Accouting-Request (Start) record, the Home RADIUS
4 server shall not update the DNS server.
5
6 If the Home RADIUS server receives a RADIUS Accounting-Request (Stop) record containing the
7 IP-Technology attribute that indicates Mobile IP and that is associated with a previously cached
8 User Name, NAS IP Address, and Framed IP address, and the Session-Continue attribute is
9 either FALSE or absent, the Home RADIUS server shall request that the DNS server delete the
10 Resource Record for the MS.
11 8.2.2 DNS Update by the HA

12 If the Home RADIUS server receives a RADIUS Access-Request from an HA and the Home
13 RADIUS server is configured to request HA-based DNS updates, the Home RADIUS server shall
14 include the DNS-Update-Required attribute in the RADIUS Access-Accept message returned to
15 the HA.
16
17 If an initial Mobile IP registration is successful, and the HA is either configured to send DNS
18 Update messages or has received a DNS-Update-Required attribute in the RADIUS Access-
19 Accept message from the Home RADIUS server, the HA shall request the DNS server to add an
20 A Resource Record for the MS.
21
22 If the HA receives a Mobile IP RRQ with lifetime timer set to zero, or the Mobile IP lifetime
23 expires, or administrative operations invalidate the mobility binding for the MS, the HA shall
24 request that the DNS server delete the associated Resource Record.
25 8.3 IPv6 IRS

26 For IPv6 IRS support, the Home RADIUS server shall use the Resource Records defined in
27 [RFC 1886] as updated by [RFC 2874] and [RFC 3150]. The operation of IRS service for IPv6
28 users is identical to the procedures described for Simple IPv4 in Section 8.1.
29
30 If the MS uses both IPv4 and IPv6, the Home RADIUS server shall request that the DNS server
31 create or delete Resource Records for both IPv4 and IPv6.
32
- 48 - 3GPP2
1 9 Mobility Management
2 9.1 Mobility Within Radio Network

3 Mobility in the wireless IP network architecture is achieved via handoffs. When a handoff is
4 between PCFs with connectivity to the same PDSN so that the Serving PDSN remains the same
5 before, during, and after handoff, it is called PCF to PCF handoff. When PCFs are connected to
6 different PDSNs, the handoff is termed PDSN to PDSN handoff.
7 9.2 PCF to PCF Handoff

8 The link layer mobility management function is used to manage the change of the R-P session
9 point of attachment while maintaining the PPP session and IP address(es). The R-P session
10 point of attachment is the PDSN. When an MS moves from one PCF to another PCF, a new R-P
11 connection between the Target PCF and the Serving PDSN is established for every packet data
12 service instance.
13
14 PCF to PCF handoff may happen while an MS is active or dormant. The purpose of dormant
15 PCF handoff is to maintain the PPP session while an MS is dormant to minimize the use of airlink
16 resources.
17
18 The PCF to PCF handoff involves:
19
20 • PDSN selection
21 • New R-P session setup
22 • Previous R-P session tear down
23
24 The Target PCF triggers a new R-P session setup. If the PDSN selected is the same Serving
25 PDSN for the MS, then the PDSN triggers a release of the previous R-P session.
26
27 During a PCF to PCF handoff, the selection of the same PDSN is given priority in order to
28 maintain the existing PPP session between the PDSN and the MS. The PDSN supports a low
29 latency PCF to PCF handoff by bi-casting data to the target and previous PCF while the mobile
30 performs an active handoff. If a different PDSN is selected and the MS still desires packet data
31 service, then a PDSN to PDSN handoff may be performed (see Section 9.3).
32
33 Each PCF is uniquely identified. At handoff the new PCF performs PDSN selection and forwards
34 both the previous PCF’s identification and its own identification to the selected PDSN. The PDSN
35 uses this information to determine whether Mobile IP re-registration is required for the MS. If re-
36 registration is required, the PDSN sends Agent Advertisements to the MS after the PPP session
37 is established.
38
39 Detailed requirements and standard procedures for PCF to PCF handoff are described in [4].
40 9.3 PDSN to PDSN Handoff

41 Mobile IP provides the IP layer mobility management function that maintains persistent IP
42 addresses across PDSNs. For a Mobile IP based MS to maintain a persistent IP address while
43 moving between Serving PDSNs, the MS re-registers with its HA as per RFC 2002 with
44 extensions as outlined in Section 6.
45
46 For PDSN to PDSN handoff, the MS may be in active or dormant state. For an active state MS,
47 fast handoff may be supported between PDSNs. If fast handoff is supported, the Target PDSN
48 initiates establishment of a P-P session with the Serving PDSN according to the procedures
- 49 - 3GPP2
1 described later in Section 12. If the MS was in dormant state, the MS transitions to active state
2 for the purpose of establishing connectivity with the new PDSN.
3
4 The PDSN to PDSN link for supporting fast handoff is called the P-P interface. Fast handoff with
5 the P-P interface is used to keep the PPP session anchored when the PDSN to PDSN handoff is
6 performed. This interface prevents the existing PPP session from being re-negotiated, thereby
7 reducing service interruption time and data loss. The forward traffic received at the Serving
8 PDSN is tunneled through the appropriate P-P connection to the Target PDSN. The Target
9 PDSN then forwards the traffic to the MS over the corresponding R-P connection. The reverse
10 traffic from the MS is tunneled through the P-P interface from the Target PDSN to the Serving
11 PDSN. The Serving PDSN then forwards the traffic to the external network.
12
13 If fast handoff is not supported, the PDSN to PDSN handoff for Mobile IP involves:
14
15 • Establishment of a new PPP session;
16 • Detection of a new Foreign Agent via the Agent Advertisement Message;
17 • Authentication by RADIUS infrastructure;
18 • Registration with the Home Agent.
19
20 If fast handoff is supported, the PDSN to PDSN handoff for Mobile IP involves:
21
22 • Establishment of a P-P connection for each associated R-P connection and the
23 continuation of the current PPP session on the Serving PDSN;
24 • Establishment of a new PPP session by the Target PDSN when the MS becomes
25 dormant or the MS renegotiates PPP;
26 • Release of the associated P-P connections while the new PPP session is being
27 established at the Target PDSN;
28 • Detection of a new Foreign Agent via the Agent Advertisement Message;
29 • Authentication by RADIUS infrastructure;
30 • Registration with the Home Agent.
31
32 If fast handoff is not supported, the PDSN to PDSN handoff for Simple IP involves:
33
34 • Establishment of a new PPP session on the Target PDSN.
35
36 If fast handoff is supported, the PDSN to PDSN handoff for Simple IP involves:
37
38 • Establishment of a P-P connection for each associated R-P connection, and continuation
39 of the current PPP session on the Serving PDSN;
40 • Establishment of a new PPP session by the Target PDSN, when the MS becomes
41 dormant or the MS renegotiates PPP;
42 • Release of the associated P-P session while the new PPP session is being established
43 at the Target PDSN.
44
45 The P-P interface is specified in Section 12.
46
47
- 50 - 3GPP2
1 10 Quality of Service
2 The cdma2000 service options allow various voice and non-voice services to be defined and
3 specified independently within the confines of the physical layer and the multiplex sub-layer
4 interface [5-9]. The air interface is able to support multiple service instances of the same or
5 different packet data service options. cdma2000 specifications support a maximum of six service
6 instances per MS, each of which may have associated RLP and/or QoS parameter settings. The
7 MS and RN identify specific service instances with a unique number referred to as the Service
8 Reference ID (SR_ID).
9
10 Although this and subsequent sections contain text referring to multiple service instances, this
11 specification does not support the use of auxiliary service instances connected to a PDSN from
12 the same MS. This is because no standard exists for informing the PDSN how to map various
13 application flows down the proper auxiliary connections. The text referring to auxiliary service
14 instances is given for use by future releases of this specification.
15
16 As outlined in [1], the RN/PCF transfers data to the PDSN via R-P connections for all service
17 instances to the MS. There shall be one R-P connection for each service instance. The PDSN
18 shall identify a service instance via an SR_ID carried in R-P connection signaling. A single R-P
19 session shall be maintained for all the R-P connections associated with an MS. For each R-P
20 session there shall be one main service instance, and optionally one or more auxiliary service
21 instances. A single PPP session shall be associated with the R-P session. There shall be one
22 PPP session between the MS and the PDSN. A given PPP session shall support one or more IP
23 addresses. These IP addresses are not associated with a particular R-P connection.
24
25 In this specification, a service instance may carry multiple flows. A flow is a series of packets that
26 share a specific instantiation of IETF protocol layers. For example, an RTP flow may consist of
27 the packets of an RTP/UDP/IP protocol instantiation, all of which share the same source and
28 destination IP addresses and UDP port numbers.
29
30 Flows may be identified at the PDSN using packet filters. Packet filters are used to map forward
31 traffic to the corresponding auxiliary service instance.
32
33 The following figure is a graphical illustration of the relationships between MS IP addresses, PPP
34 session, R-P session, R-P connection, service instance, and SR_ID.
- 51 - 3GPP2
Flow 1 Flow n PDSN
PPP session
R-P session
R-P connection R-P connection R-P connection

1 2 3
Ch1=SR_ID1
Ch2=SR_ID2
Ch3=SR_ID3
BSC/PCF
Service Service Service

instance 1 instance 2 instance 3
PPP session MS
Flow 1 Flow n
1
2 Figure 13 - Graphical Illustration of Multiple Connection Relationships
3
4 In accordance with differentiated services standards, the MS may mark packets (i.e., in the
5 reverse direction). The PDSN limits the differentiated services markings that the MS applies to
6 packets based on the User Profile from the Home AAA server. The PDSN also provides a fixed
7 marking for Mobile IP based reverse tunneled traffic. This capability is especially useful for MSs
8 that cannot mark packets but that desire the benefits of differentiated services for traffic
9 traversing the Internet to a private network.
10
11 The remainder of this section covers the following topics:
12
13 • Section 10.1: Multiple Service Instances
14 • Section 10.2: QoS Flow Mapping and Treatments
15 • Section 10.3: Subscriber QoS Profile
16 10.1 Multiple Service Instances
17 10.1.1 MS Requirements
18 If the MS establishes multiple service instances, the MS shall always establish a main service
19 instance before establishing auxiliary service instances. The MS shall support a single PPP
20 session over multiple service instances. The MS shall send PPP control packets only over the
21 main service instance. The MS shall not send PPP control packets over auxiliary service
22 instances. The MS shall use octet-oriented HDLC framing per RFC 1662 over octet-oriented
23 service instances. The MS shall not use HDLC framing over non-octet oriented service
24 instances. If the MS uses Mobile IP, the MS shall send Mobile IP discovery and registration
25 messages over the main service instance.
- 52 - 3GPP2
1 10.1.2 PDSN Requirements

2 The PDSN shall support a single PPP session over multiple R-P connections for the same MS.
3 Each R-P connection corresponds to a service instance. The PDSN shall send PPP control
4 packets only over an R-P connection corresponding to the main service instance. The PDSN
5 shall not send PPP control packets over R-P connections corresponding to the auxiliary service
6 instances. The PDSN shall use octet-oriented HDLC framing over R-P connections
7 corresponding to octet oriented service instances. The PDSN shall not use HDLC framing over
8 an R-P connection corresponding to non-octet oriented service instances. For a Mobile IP MS,
9 the PDSN shall send Mobile IP discovery and registration messages over an R-P connection
10 corresponding to the main service instance.
11
12 The PDSN shall support handoff and may support fast handoff of multiple service instances. At
13 non-fast handoff of multiple service instances, failure of a fast handoff, or completion of the fast
14 handoff, the Target PDSN shall initiate PPP negotiation over the main service instance.
15
16 At dormant handoff of multiple service instances, the MS shall send its first origination for the
17 service instance that was first setup in the previous packet zone. That service instance
18 corresponds to the main service instance. If a previous PPP session is still maintained at the
19 PDSN, the PDSN shall re-negotiate PPP if:
20
21 • The PANID information indicates that the MS has moved from a different PDSN
22 coverage.
23 • The first A10 connection that was setup or restarted does not correspond to the existing
24 main service instance in the PDSN.
25 10.2 QoS Flow Mapping and Treatments

26 If the MS opens an auxiliary service instance, the PDSN shall reject the R-P connection for that
27 service instance because there is no mechanism in this specification to perform flow mapping in
28 the MS and PDSN.
29 10.3 Subscriber QoS Profile

30 When the MS establishes Mobile IP service, the PDSN shall perform authentication and
31 authorization of the MS with the HAAA server. When the MS establishes Simple IP service, the
32 PDSN shall perform authentication and authorization of the MS with the HAAA server, unless the
33 carrier has permitted null authentication28 as specified in 5.2.1.3, in which case the Subscriber
34 QoS Profile shall be locally provisioned in the PDSN. Assuming the MS is authenticated, the
35 HAAA may return Subscriber QoS Profile information via the VAAA to the PDSN in the
36 authentication response. The Subscriber QoS Profile consists of the following:
37
38 • The Allowed Differentiated Services Markings attribute
39 • The Service Option Profile attribute
40
41 The attributes are specified in Annex C. The PDSN uses the Subscriber QoS Profile as part of
42 the authorization for service instances. The PDSN shall store this information for subsequent
43 use. In the event of multiple NAIs per MS, the PDSN may receive a Subscriber QoS Profile for
44 each NAI. The PDSN shall store and handle multiple Subscriber QoS Profiles per MS.
45 10.3.1 Allowed Differentiated Services Marking

46 The Differentiated Services Code Points (DSCPs) supported in this specification shall be based
47 on the following RFCs:
48
28
This is the case in which the MS is permitted to negotiate Simple IP without CHAP or PAP.
- 53 - 3GPP2
1 • Class selectors: [RFC 2474] defines these as code points whose lower three bits (3, 4, 5)
2 are all zero. Therefore, there are eight such classes.
3 • Default Forwarding (often called Best Effort) is a class selector with class equal to 0.
4 • Assured Forwarding (AF) classes: see [RFC 2597].
5 • Expedited Forwarding (EF) Classes: see [RFC 2598].
6
7 When the MS marks IP packets with DSCPs, the PDSN shall ensure that only allowed DSCPs
8 are used as authorized by the HAAA in the users Subscriber QoS Profile. If the HAAA does not
9 include the Subscriber QoS Profile of the user in the RADIUS Access-Accept message, the
10 PDSN shall offer a default QoS to the user’s packets as provisioned by the service provider.
11
12 The Allowed Differentiated Services Marking attribute indicates the type of marking the user may
13 apply to a packet. The PDSN may re-mark the packet according to local policy if the type of
14 marking is not authorized by the user's Allowed Differentiated Services Marking attribute. The
15 attribute contains three bits, the 'A', 'E', and 'O' bits. When the ‘A’ bit is set, the user may mark
16 packets with any AF class. When the ‘E’ bit is set, the user may mark packets with EF class.
17 When the ‘O’ bit is set, the user may mark packets with experimental/local use classes. The Max
18 Class Selector field specifies the maximum class selector for which a user may mark a packet.
19 When all three bits are clear, and when the Max Class Selector is zero, the user may only send
20 packets marked best effort.
21
22 When reverse direction traffic arrives at the PDSN, the PDSN shall match the source address of
23 such packets to a source address that is associated with an authenticated NAI. The PDSN
24 should apply the associated Subscriber QoS Profile to the packet.
25 10.3.1.1 Differentiated Services and Tunnels

26 The Allowed Differentiated Services Marking attribute contains a reverse tunnel marking ('RT
27 Marking', see Annex C), which is the marking level the PDSN shall apply to reverse tunneled
28 packets when those packets are not marked [RFC 2983]. If the packets received from the MS
29 are marked, and traffic is to be reverse tunneled to the HA, the PDSN shall copy the (possibly re-
30 marked) inner packet marking to the outer header of reverse Mobile IP tunnels.
31
32 For forward traffic to the MS, the HA should set the differentiated services field of the HA-FA
33 tunnel to the differentiated services class of each received packet bound to the MS.
34 10.3.2 PDSN-Based R-P Admission Control

35 The PDSN may reject a new R-P connection request from the RN if:
36
37 • the number of connections requested by the user exceeds limits set by the Service
38 Option Profile; or,
39 • the service option is not on the list of allowed service options; or
40 • the connection is beyond the resources of the PDSN itself.
41
42 The HAAA may include a Subscriber QoS Profile in the AAA authorization response to the PDSN.
43
44 In the event there are multiple Subscriber QoS Profiles due to multiple NAIs per MS, the PDSN
45 shall combine the QoS parameters into a single Subscriber QoS Profile in accordance with local
46 policy. The default local policy is as follows:
47
48 • the total set of all service options
49 • the maximum of the maximum number of service instances.
50
- 54 - 3GPP2
1 11 Accounting
2 11.1 General
3 11.1.1 Usage Data Records

4 Packet Accounting parameters are divided into radio specific parameters collected by the RN,
5 and IP network specific parameters collected by the Serving PDSN. The Serving PDSN shall
6 merge radio specific parameters contained in R-P and P-P interface messages called Airlink
7 Records with IP network specific ones to form one or more Usage Data Records (UDR). After
8 merging, the Serving PDSN shall use RADIUS accounting messages to send UDR information to
9 the Visited RADIUS Server. This is outlined as below in Figure 14, and further detailed in the
10 subsequent sections. The Serving PDSN shall maintain UDR information until it receives positive
11 acknowledgment from the RADIUS server that the RADIUS server has correctly received the
12 RADIUS message. Likewise, the RADIUS server shall maintain the UDR until the record is
13 delivered to a Home RADIUS server, or removed by the operator billing system. The method by
14 which information is moved from a RADIUS server to a billing system is beyond the scope of this
15 specification as is the summary, reconciliation, and billing process used by the carriers.
RN
R-P Interfac e
1 Airlink Records
i.e., MSID, location, time on RADIUS Server
channel, etc.
RADIUS Records
2 PDSN adds more info
PDSN
and sends RADIUS
accounting info
16
17
18
19 Figure 14 - Accounting Architecture
20 11.1.2 Remote Address Accounting

21 The PDSN shall support remote address based accounting by counting the number of octets
22 exchanged between the MS and a remote IP address during a packet data session. The PDSN
23 shall allow for enabling of this accounting functionality on a per user (i.e., NAI) basis, as specified
24 in the User Profile information received from the Home RADIUS server during access
25 procedures.
26
27 The PDSN shall support the Remote IPv4/IPv6 Address and Remote Address Table Index
28 attributes as defined in Annex C. The Home RADIUS server may use multiple instances of the
29 Remote IPv4/IPv6 Address and Remote Address Table Index attributes in the RADIUS Access-
30 Accept message to authorize remote address accounting for the user for specific remote
31 addresses. A Remote IPv4/IPv6 Address attribute shall contain an address mask/prefix-length,
32 so that a given address and mask/prefix-length indicates multiple addresses to be used for
- 55 - 3GPP2
1 remote address accounting for the user29. The table indices specified by the Home RADIUS
2 server point to tables of addresses stored at the PDSN. The method of provisioning the tables at
3 the PDSN and the corresponding table indices at the Home RADIUS server is outside the scope
4 of this specification.
5
6 The PDSN shall support the Remote IPv4/IPv6 Address Octet Count attribute to count the
7 number of bytes sent/received to/from a given remote address or set of remote addresses. The
8 attribute contains a counter for forward traffic, a counter for reverse traffic, and the remote IP
9 address or set of remote addresses with the same mask or prefix length (if present), as specified
10 in Annex C. The PDSN shall generate a Remote IPv4/IPv6 Address Octet Count attribute for
11 each remote address or set of remote addresses as represented by a mask or prefix length in
12 use during a packet data session and authorized for the user by the RADIUS server. Hence, a
13 UDR may contain multiple instances of the Remote IPv4/IPv6 Address Octet Count attribute.
14 Therefore, the PDSN and the RADIUS server shall be capable of supporting multiple instances of
15 the Remote IPv4/IPv6 Address Octet Count attribute in the RADIUS Accounting-Request (Stop)
16 record and Interim messages. A remote address mask or prefix-length shall be used to indicate
17 a range of addresses for remote address accounting. The PDSN shall aggregate the byte counts
18 for all the remote IP addresses of that mask or prefix and generate one Remote IPv4/IPv6
19 Address Octet Count attribute.
20
21 If the Remote Address Table Index is used for remote address based accounting, the current
22 method is not easily scalable to multi-domain support, due to issues with table provisioning and
23 synchronization between realms. In this case, the remote address functionality shall be limited to
24 a single realm support from an access provider network point of view. All the PDSNs in a single
25 realm shall have the same set of tables. There is no explicit support in this specification for
26 coordinating table indices across realms. The Home RADIUS server shall be of the same realm
27 as the PDSN or it shall have coordinated its indices with the realm that owns the PDSN.
28
29 It is the responsibility of the Visited RADIUS server to ensure the remote address table indices
30 returned in a RADIUS Access-Accept message are consistent with the tables stored in the
31 PDSN. For example, the Visited RADIUS server may filter out the Remote Address Table Index
32 attributes contained in the RADIUS Access-Accept messages received from uncoordinated
33 realms.
34
35 When a packet is received in the forward direction, the PDSN shall examine the source IP
36 address of the packet. If the source IP address matches a remote address for the user, the
37 PDSN shall create a Remote IPv4/IPv6 Address Octet Count attribute as part of the UDR if it
38 does not exist and shall increment the octet counts.
39
40 When a packet is received in the reverse direction, the PDSN shall examine the destination IP
41 address of the packet. If the destination IP address matches a remote address for the user, the
42 PDSN shall create an instance of the Remote IPv4/IPv6 Address Octet Count attribute if it does
43 not exist and shall increment octet counts.
44
45 Both IPv4 and IPv6 remote addresses are supported in remote address accounting. The
46 structure of remote address tables, and the method of communicating such information to the
47 PDSN are outside the scope of this specification.
48 11.1.3 Accounting and Fast Handoff

49 If a P-P session exists, the Target PDSN shall forward the airlink records received from the
50 Target RN to the Serving PDSN over the P-P interface. The Target PDSN shall not alter the
51 airlink records. The Serving PDSN shall perform accounting functions for the data exchanged
52 over the P-P connection per Section 11.5.1, treating the Target PDSN as if it were a PCF. Once
29
An address mask of all ones means that all bits of the address shall be matched.
- 56 - 3GPP2
1 the Serving PDSN combines these with IP network specific parameters, the UDR is sent to the
2 RADIUS server as a RADIUS Accounting-Request record. This is outlined as below in Figure 15,
3 and detailed in the subsequent sections. Upon fast handoff, the Target PDSN shall store a copy
4 of the airlink records received at pre-setup of the R-P session.
5
6 Also, the Serving PDSN copies some of the data from the current UDR or UDRs to the new UDR
7 or UDRs while fast handoff is in progress. The PDSN accounting procedures ensure that no
8 double counting of usage occurs.
Target RADIUS
RN Server
1 3 UDR
Airlink Records
R-P • PDSN adds more info
• i.e., MSID, location, time on
Interface and sends complete
channel, etc. UDR
Target Serving
PDSN P-P Interface PDSN
2 Airlink Records
• i.e., MSID, location, time on
channel, etc.
9
10
11
12
13 Figure 15 - Accounting Architecture With Fast Handoff
14
15 11.1.4 Accounting Attribute Notation

16 A lower case letter implies an accounting attribute in an airlink record whereas a capital letter
17 implies an accounting attribute in a UDR. Thus attributes in Table 6 - Table 9 that apply to airlink
18 records use lower case letters, and attributes in Table 10 and Table 11 that apply to UDRs use
19 upper case letters.
20 11.2 Airlink Records

21 The RN generates one of four types of airlink records over the R-P interface:
22
23 • An R-P connection setup when the RN establishes an R-P session.
24 • An Active Start Airlink Record when the MS has started to use traffic channel(s).
25 • An Active Stop Airlink Record when the MS has stopped using traffic channel(s).
26 • A Short Data Burst (SDB) Airlink Record when a forward or reverse short data burst is
27 exchanged with the MS.
28
29 The PCF uses the R-P Connection ID as the PCF Session Identifier Key in R-P setup messages,
30 and the GRE key in R-P packets. For bi-directional keys, the PDSN also uses the RP
31 Connection ID as the GRE key in R-P packets.
32
- 57 - 3GPP2
1 For fast handoff, the Target PDSN forwards the airlink records to the Serving PDSN unchanged.
2 The Target PDSN shall store a copy of the airlink records received at pre-setup of the R-P
3 session for each R-P connection.
4
5 All the airlink records shall include a sequence number initialized to zero at R-P connection
6 setup. The sequence number is unique for a single identification triplet (R-P Connection ID, PCF
7 ID, and MSID). Upon receiving the connection setup airlink record, the Serving PDSN updates
8 the UDR with the airlink record information and stores the sequence number. The PCF shall
9 increment the sequence number modulo 256 in the subsequent airlink record transmitted over
10 the corresponding R-P connection. The Serving PDSN shall compare the received sequence
11 number with the previously stored sequence number (N). If the received sequence number is in
12 the range from (N+1) modulo 256 to (N+127) modulo 256, inclusive, the PDSN shall act
13 accordingly based on the information contained in the airlink record, and shall update its stored
14 sequence number. If the received sequence number is in the range from (N-128) modulo 256 to
15 (N-1) modulo 256, inclusive, the Serving PDSN shall ignore the message. The same procedure
16 continues for all the subsequent airlink records, until the closing of the R-P connection.
17
18 In the event of retransmission, the PCF shall retransmit with the same sequence number, and the
19 Serving PDSN shall not update the UDR if the same sequence number corresponding to a single
20 identification triplet is received. There should be only one outstanding unacknowledged airlink
21 record at any given time.
22
23 Detailed specifications of airlink records are in [4].
24 11.2.1 R-P Connection Setup Airlink Record

25 Table 6 contains fields present in the R-P Connection Setup airlink records.
26
Item Parameter Max Payload Format
Length
(octets)
y1 Airlink Record Type = 1 (Connection Setup) 4 integer
y2 R-P Connection ID 4 integer
y3 Airlink Sequence Number 4 integer
a1 MSID 15 string
a2 ESN 15 string
30
a3 MEID 14 string
d3 Serving PCF 4 ip-addr
d4 BSID 12 string
27
28 Table 6 – R-P Connection Setup Airlink Fields
29
30 Each R-P connection and each airlink record is indexed via the R-P Connection ID.
31
30
Either a2 or a3, or both shall be included.
- 58 - 3GPP2
1 11.2.2 Active Start Airlink Record

2 Table 7 contains fields present in Active Start airlink records.
3
Length
(octets)
y1 Airlink Record Type = 2 (Active Start) 4 integer
e1 User Zone 4 integer
f1 Forward Mux Option 4 integer
f2 Reverse Mux Option 4 integer
f5 Service Option 4 integer
f6 Forward Traffic Type (Primary, Secondary) 4 integer
f7 Reverse Traffic Type (Primary, Secondary) 4 integer
f8 Fundamental Frame Size (0/5/20 ms) 4 integer
f9 Forward Fundamental RC 4 integer
f10 Reverse Fundamental RC 4 integer
f14 DCCH Frame Size (0/5/20ms) 4 integer
i4 Airlink Priority 4 integer
4
5 Table 7 – Active Start Airlink Fields
6 If the e1, f1, f2, and/or i4 parameters in Table 7 change during the active session, the RN shall
7 send an Active Stop Airlink Record, and an Active Start Airlink Record with the new parameters.
8
9 f1 to f10 are fields from the service configuration record.
10 11.2.3 Active Stop Airlink Record

11 Table 8 contains fields present in Active Stop Airlink Records.
12
Length
(octets)
y1 Airlink Record Type = 3 (Active Stop) 4 integer
g8 Active Connection Time in Seconds 4 integer
13
14 Table 8 – Active Stop Airlink Fields
15 11.2.4 SDB Airlink Record

16 Table 9 contains fields present in SDB Airlink Records.
17
Length
(octets)
y1 Airlink Record Type = 4 (SDB) 4 integer
y4 Mobile Originated/Mobile Terminated Indicator 4 integer
g10 SDB Octet Count 4 integer
18
19 Table 9 – SDB Airlink Fields
- 59 - 3GPP2
2 11.3 PDSN Usage Data Record (UDR)

3 Table 10 contains the complete UDR and the description of each field.
4
Item Parameter Description
A. Mobile Identifiers
A1 MSID MS ID (e.g., IMSI, MIN, IRM)
A2 ESN Electronic Serial Number
A3 MEID Mobile Equipment Identifier
B. User Identifiers
B1 Source IP Address IPv4 address of the MS.
B2 Network Access user@domain construct which identifies the user and home network of the MS.
Identifier (NAI)
B3 Framed-IPv6- MS IPv6 prefix
Prefix
B4 IPv6 Interface ID See RFC 3162
C. Session Identifiers
C1 Account Session The Account Session ID is a unique accounting ID created by the Serving PDSN that
ID allows start and stop RADIUS records from a single R-P connection or P-P connection
to be matched
C2 Correlation ID The Correlation ID is a unique accounting ID created by the Serving PDSN for each
packet data session that allows multiple accounting events for each associated R-P
connection or P-P connection to be correlated.
C3 Session Continue This attribute when set to ‘true’ means it is not the end of a Session and an Accounting
Stop is immediately followed by an Account Start Record. ‘False’ means end of a
session.
C4 Beginning Session The attribute when set to ‘true’ means new packet data session is established; ‘false’
means continuation of previous packet data session. This attribute is contained in a
RADIUS Accounting-Request (Start) record.
D. Infrastructure Identifiers
D1 MIP Home Agent The IPv4 address of the HA
(HA)
D2 PDSN The IPv4 address of the PDSN.
Address
D3 Serving PCF The IP address of the serving PCF, i.e., the PCF in the serving RN.
D4 BSID SID + NID + Cell Identifier type 2
D5 IPv6 PDSN The IPv6 address of the PDSN
Address
E. Zone Identifiers
E1 User Zone Tiered Services user zone.
F. Session Status
F1 Forward Mux Forward direction multiplex option
Option
F2 Reverse Mux Reverse direction multiplex option
Option
F5 Service Option CDMA service option as received from the RN
F6 Forward Traffic Forward direction traffic type – either Primary or Secondary
Type
F7 Reverse Traffic Reverse direction traffic type – either Primary or Secondary
Type
F8 Fundamental Specifies the FCH Frame Size
Frame Size
F9 Forward The format and structure of the radio channel in the forward FCH. A set of forward
Fundamental RC transmission formats that are characterized by data rates, modulation characterized,
and spreading rates. [6]
F10 Reverse The format and structure of the radio channel in the reverse FCH. A set of reverse
Fundamental RC transmission formats that are characterized by data rates, modulation characterized,
and spreading rates. [6]
F11 IP Technology Identifies the IP technology to use for this call: Simple IP or Mobile IP.
F12 Compulsory Indicator of invocation of compulsory tunnel established on behalf of MS for providing
Tunnel Indicator private network and/or ISP access during a single packet data connection.
F13 Release Indicator Specifies reason for sending a stop record.
- 60 - 3GPP2
F14 DCCH Frame Size Specifies Dedicated Control Channel (DCCH) frame size.
F15 Always On Specifies the status of Always On service.

G. Session Activity
G1 Data Octet Count The total number of octets in IP packets sent to the user.
(Terminating)
G2 Data Octet Count The total number of octets in IP packets sent by the user.
(Originating)
G3 Bad PPP frame The total number of PPP frames from the MS dropped by the PDSN due to
count uncorrectable errors.
G4 Event Time This is an event timestamp which indicates one of the following:
The start of an accounting session if it is part of a RADIUS start message
The end of an accounting session if it is part of a RADIUS stop message
An interim accounting event if it is part of a RADIUS interim message.
G5 Remote IPv4 Contains the octet count associated with a remote IPv4 address; used for
Address Octet source/destination accounting.
Count
G6 Remote IPv6 Contains the octet count associated with a remote IPv6 address; used for
Address Octet source/destination accounting.
Count
G8 Active Time The total active connection time on traffic channel in seconds.
G9 Number of Active The total number of non-active to Active transitions by the user.
Transitions
G10 SDB Octet Count The total number of octets sent to the MS via Short Data Bursts.
(Terminating)
G11 SDB Octet Count The total number of octets sent by the MS via Short Data Bursts.
(Originating)
G12 Number of SDBs The total number of Short Data Burst transactions with the MS.
(Terminating)
G13 Number of SDBs The total number of Short Data Burst transactions with the MS.
(Originating)
G14 Number of HDLC The count of all bytes received in the reverse direction by the HDLC layer in the PDSN.
layer bytes
received
G15 Inbound Mobile IP This is the total number of octets in registration requests and solicitations sent by the
Signaling Octet MS.
Count
G16 Outbound Mobile This is the total number of octets in registration replies and agent advertisements sent to
IP Signaling Octet the MS.
Count
I. Quality of Service
I1 IP Quality of This attribute is deprecated.
Service (QoS)
I4 Airlink Priority Identifies Airlink Priority associated with the user. This is the user's priority associated
with the packet data service.
Y. Airlink Record Specific Parameters

Y1 Airlink Record 3GPP2 Airlink Record Type
Type
Y2 R-P Connection ID Identifier for the R-P Connection. This is the GRE key that uniquely identifies an R-P
connection (an A10 connection) between the PCF and the PDSN.
Y3 Airlink Sequence Sequence number for Airlink records. Indicates the sequence of airlink records for an
Number R-P connection.
Y4 Mobile Originated / Used only in SDB airlink records. Indicates whether the SDB is Mobile Originated or
Mobile Terminated Mobile Terminated.
Indicator
Z. Container
Z1 Container 3GPP2 Accounting Container attribute. This attribute is used to embed 3GPP2
AVPsVSAs and/or RADIUS attributes. This attribute is further described in Annex C.
1
2 Table 10 – Complete UDR
- 61 - 3GPP2
1 11.4 Accounting Formats

2 The RADIUS server shall support RADIUS attribute formats as defined in RFC 2865 and RFC
3 2866. The RN airlink records transmitted across the R-P interface and the P-P interface shall
4 follow the RADIUS format encapsulated in a MIP vendor specific attribute (attribute type 38).
5 Table 11 lists each accounting parameter and its associated RADIUS attribute.
6
7 Note: Attributes of type “26” defined in RFC 2865 and RFC 2866 are vendor specific, and are
8 used to transport 3GPP2 specific parameters. Attribute value types 26/60 to 26/69 within the
9 3GPP2 vendor specific space are reserved. The default Vendor ID value in Vendor Specific
10 attributes shall be 5535 defined in IANA in order for cdma2000 packet data service to support
11 global roaming. 3GPP2 attribute formats not defined in Annex C are included in Table 11.
- 62 - 3GPP2
1
2
RADIUS Attribute Definitions
Item Parameter Type/ Maximum Format Field Special Values
Vendor Payload
Type Length
(in octets)
3 A. Mobile Identifiers
A1 MSID 31 15 string Calling_ID
A2 ESN 26/52 15 string ESN ASCII string of ESN
A3 MEID 26/116 14 string MEID ASCII string of MEID
4 B. User Identifiers
B1 Source IP Address 8 4 ip-addr Framed IP Address
B2 Network Access Identifier (NAI) 1 72 string User-Name
B3 Source IPv6 Prefix 97 4-20 IPv6-prefix Framed IPv6 Prefix Carries the IPv6 prefix of the MS. The
length includes the reserved byte as well
as the prefix length field byte (see RFC
3162, section 2.3).
B4 IPv6 Interface ID 96 10 string Framed_Interface_ID See RFC 3162
5 C. Session Identifiers
C1 Account Session ID 44 8 string Acct_ Session_Id ASCII string of session ID
C2 Correlation ID 26/44 8 string Correlation_Id ASCII string of correlation ID
C3 Session Continue 26/48 4 integer 3GPP2_Session_cont 0=False, 1=True
C4 Beginning Session 26/51 4 integer 3GPP2_Begin_Session 0=False, 1=True
6 D. Infrastructure Identifiers
D1 MIP Home Agent (HA) 26/7 4 ip-addr 3GPP2_HA_IP_Addr
D2 PDSN Address 4 4 ip-addr NAS Address IPv4 address of the RADIUS client in the
PDSN
D3 Serving PCF 26/9 4 ip-addr 3GPP2_PCF IP_Addr The serving PCF is the PCF in the serving
RN.
D4 BSID 26/10 12 string 3GPP2_BSID A number formed from the concatenation of
SID (4 octets)+ NID (4 octets)+ Cell
Identifier (type 2) (4 octets). In the Cell
Identifier the 12 upper bits are the Cell Id
and the lower 4 bits are the Sector. Each
item is encoded using hexadecimal
uppercase ASCII characters.
D5 IPv6 PDSN Address 95 16 Ipv6-addr NAS IPv6 address
7 E. Zone Identifiers
- 63 - 3GPP2
E1 User Zone 26/11 4 integer 3GPP2_User_ID Least significant 16 bits hold user zone ID
(UZ_ID) next significant 15 bits hold user
zone system ID (UZ_SID) and most
significant bit always zero. UZ_ID and
UZ_SID are defined in [10].
1 F. Session Status
F1 Forward Mux Option 26/12 4 integer 3GPP2_FMUX
F2 Reverse Mux Option 26/13 4 integer 3GPP2_RMUX
F5 Service Option 26/16 4 integer 3GPP2_SO
F6 Forward Traffic Type 26/17 4 integer 3GPP2_FTYPE 0=Primary, 1=Secondary
F7 Reverse Traffic Type (Primary, Secondary) 26/18 4 integer 3GPP2_RTYPE 0=Primary, 1=Secondary
F8 Fundamental Frame Size 26/19 4 integer 3GPP2_FFSIZE 0=no fundamental, 1=5ms and 20ms mixed
frame, 2=20ms frame
F9 Forward Fundamental RC 26/20 4 integer 3GPP2_FRC See [6]
F10 Reverse Fundamental RC 26/21 4 integer 3GPP2_RRC See [6]
F11 IP Technology 26/22 4 integer 3GPP2_IP_Tech 1=Simple IP, 2=Mobile IP
F12 Compulsory Tunnel Indicator 26/23 4 integer 3GPP2_Comp_Flag 0=no tunnel
1=non-secure tunnel
2=secure tunnel
F13 Release Indicator 26/24 4 integer 3GPP2_Reason_Ind Reasons for stop record:
0=unknown
1=PPP/Service timeout
2=Handoff
3=PPP termination
4=Mobile IP registration failure
F14 DCCH Frame Format (0/5/20ms) 26/50 4 integer 3GPP2_DFSIZE 0=no DCCH, 1=5ms and 20ms mixed
frame, 2=20ms frame, 3=5ms frame
F15 Always On 26/78 4 integer 3GPP2_Always_ON Always On
0=no
1=yes
2 G. Session Activity
G1 Data Octet Count (Terminating) 43 4 integer Acct_Output_Octets
G2 Data Octet Count (Originating) 42 4 integer Acct_Input_Octets
G3 Bad PPP Frame Count 26/25 4 integer 3GPP2_Bad_Frame_Cou
nt
G4 Event Time 55 4 time Event_Timestamp
G5 Remote IPv4 Address Octet Count 26/72 variable32 octet string See Annex C
G6 Remote IPv6 Address Octet Count 26/9780 variable44 octet string See Annex C
G8 Active Time 26/49 4 integer 3GPP2_Active_Time
G9 Number of Active Transitions 26/30 4 integer 3GPP2_Num_Active
G10 SDB Octet Count (Terminating) 26/31 4 integer 3GPP2_SDB_Input_Octe
ts
G11 SDB Octet Count (Originating) 26/32 4 integer 3GPP2_SDB_Output_Octe
ts
- 64 - 3GPP2
G12 Number of SDBs (Terminating) 26/33 4 integer 3GPP2_NumSDB_Input

G13 Number of SDBs (Originating) 26/34 4 integer 3GPP2_NumSDB_Outpu
t
G14 Number of HDLC layer bytes received 26/43 4 integer 3GPP2_Num_Bytes_Rec The count of all bytes received in the
eived_Total reverse direction by the HDLC layer in the
PDSN.
G15 Inbound Mobile IP Signaling Octet Count 26/46 4 Integer 3GPP2_Mobile_IP_Signa This is the total number of octets in
ling_Inbound_Count registration requests and solicitations sent
by the MS.
G16 Outbound Mobile IP Signaling Octet Count 26/47 4 Integer 3GPP2_Mobile_IP_Signa This is the total number of octets in
ling_Outbound_Count registration replies and agent
advertisements, sent to the MS.
1 I. Quality of Service
I1 IP Quality of Service (QOS) 26/36 4 integer 3GPP2_IP_QOS This attribute is deprecated
I4 Airlink Priority 26/39 4 integer 3GPP2_Air_Prioirty Least significant 4 bits hold the priority
associated with the packet data service.
2 Y. Airlink Record Specific Parameters
Y1 Airlink Record Type 26/40 4 integer 3GPP2_Airlink_Record_T 1=Connection Setup
ype 2=Active Start
3=Active Stop
4=SDB Record
Y2 R-P Connection ID 26/41 4 integer 3GPP2_R-
P_Connection_ID
Y3 Airlink Sequence Number 26/42 4 Integer 3GPP2_Airlink_Sequenc
e_Number
Y4 Mobile Originated / Mobile Terminated Indicator 26/45 4 Integer 3GPP2_Mobile_Terminat 0=Mobile Originated
ed_Originated_Indicator 1=Mobile Terminated
3 Z. Container
Z1 Container 26/6 Variable string 3GPP2_Container See Annex C
4
5 Table 11 – Accounting Parameter Attribute RADIUS Definitions
6
7
- 65 - 3GPP2
1 11.5 PDSN Procedures

2 There are several kinds of events that cause the PDSN to take accounting action:
3
4 • Reception of R-P Connection Setup Airlink Record over R-P or P-P interface.
5 • R-P or P-P connection termination at the PDSN.
6 • Data service establishment or PPP renegotiation on the PDSN. This includes a PPP
7 session and packet service session (Simple IP or Mobile IP).
8 • Data service termination on the PDSN. This includes releasing the PPP session, or
9 release of a packet service session (Simple IP or Mobile IP).
10 • Arrival of forward direction or reverse direction user data.
11 • Reception of Active Start Airlink Record.
12 • Reception of Active Stop Airlink Record.
13 • Reception of SDB Airlink Record.
14 • Interim record trigger.
15 • Stop record trigger.
16 • Time of day timer expiry.
17
18 Each packet data session (i.e., Simple IP and/or Mobile IPv4 session) is identified by a
19 correlation ID provided to the HAAA at the time authentication/authorization is performed. Each
20 individual Simple IPv4, Mobile IPv4, and Simple IPv6 session shall be accounted for
21 independently. All UDR information is stored and transmitted per tuple of {assigned IPv4 address
22 or IPv6 prefix, NAI, (R-P or P-P connection ID)}. However, simultaneous Simple IPv4 and Simple
23 IPv6 shall use a common correlation ID because they use a common authorization procedure.
24 During the lifetime of the Simple IP and/or Mobile IP session, UDRs are created, modified,
25 maintained, copied, and released for each individual connection. The Serving PDSN shall create
26 one UDR per R-P connection ID and one UDR per P-P connection for each packet data session
27 established by the MS. An R-P connection may be directly connected to the serving PDSN or
28 indirectly connected via a P-P connection.
29
30 The PDSN closes a UDR when any of the following events occur:
31
32 • An existing R-P or P-P connection is closed.
33 • The PDSN determines the packet data session associated with the correlation ID has
34 ended.
35
36 At an initial R-P connection establishment, a UDR is created and initialized from relevant airlink
37 records. When there is a new R-P or P-P connection due to a handoff for an existing packet data
38 session, or when a new packet data session for an existing R-P or P-P connection is created
39 because PPP is renegotiated, or when there is a new R-P connection for an existing packet data
40 session, a UDR is created by copying data from a previous UDR. For example, during a fast
41 handoff, the PDSN copies packet data session information (e.g., IP address and NAI) from the
42 previous UDR associated with the source RN to the new UDR associated with the new RN.
43 Similarly, if the MS sends an LCP Configure-Request message over the main service instance to
44 restart the PPP session, the PDSN copies R-P or P-P connection data (e.g., F1-F14) from all
45 current UDRs of the entire packet data session to new UDRs for the new packet data session.
46 The Serving PDSN closes the previous UDRs and sends accounting records to the RADIUS
47 server.
48
49 Furthermore, during a fast handoff, either two R-P connections, an R-P and P-P connection, or
50 two P-P connections may exist momentarily with the same SR_ID and MSID due to the PDSN
- 66 - 3GPP2
1 bicasting31 to both the source and target RNs. Since the MS can connect to only one RN for a
2 given service instance, the PDSN accounting procedures ensure that double counting between
3 the current and new (copy) never occurs despite the PDSN bicasting of data to both service
4 instances.
5
6 RADIUS accounting messages are generated from the information in the UDR. The Correlation
7 ID is used to match different accounting records (Account Session IDs) across R-P connections
8 or P-P connections for a single packet data session. One Correlation ID for all R-P and P-P
9 connections is maintained for the life of a packet data session for each NAI and IP pair. The
10 Account Session ID is used to match a single RADIUS Start and Stop pair. A different Account
11 Session ID is used for each R-P connection and/or P-P connection. A new R-P connection due
12 to intra-PDSN handoff between PCFs shall result in a new R-P Connection ID and Account
13 Session ID. A new P-P connection due to fast handoff between the PDSNs shall result in a new
14 R-P Connection ID and Account Session ID. The MSID and SR_ID are used to select the proper
15 UDR after an intra-PDSN handoff. One R-P Connection ID may be associated with multiple
16 simultaneous NAI, IP pairs in the Serving PDSN (i.e., multiple packet data sessions).
17
18 Airlink records are only associated with an R-P connection IDor a P-P connection. The Serving
19 PDSN matches the R-P Connection ID in the airlink record to the R-P Connection ID in the
20 appropriate UDR(s). If more than one UDR matches, the actions are applied to all UDRs.
21
22 Some events cause certain UDR fields to change in the middle of a session. When this happens,
23 one of two approaches shall be taken: (1) a container attribute as specified in Annex C is created
24 and the changed fields are embedded in that container attribute. This allows the UDR to
25 continue to accumulate accounting information after an event without transmitting a RADIUS
26 message. Alternatively (2), the PDSN may send a RADIUS Stop record to capture accounting
27 data before the event, followed by a RADIUS Start record with the new field values. In fact, a
28 PDSN may send a RADIUS Stop and RADIUS Start anytime during a single session as long as
29 no accounting data is lost. In these cases, the PDSN shall send the same Correlation ID in both
30 the RADIUS Start and RADIUS Stop records.
31
32 The subsequent sections specify the actions to take for each event.
33 11.5.1 R-P Connection Setup Airlink Record Arrives

34 When the Serving PDSN receives an R-P Connection Setup Airlink Record over an R-P or P-P
35 connection as a result of a handoff, then the PDSN shall use the MSID and SR_ID to find the
36 correct UDR, and, either:
37
38 • Create a new Container attribute in the UDR with Container-Reason Handoff, Event-
39 timestamp current time and attributes D2 (in case of an IPv6 PDSN, D5), D3, D4, G1,
40 G2, G3, and G8-16, and all instances of G5/G6.
41 • Use information received from the RN to fill in the following fields: D3 and D4. The PDSN
42 fills in D2 (in case of an IPv6 PDSN, D5).
43 • Zero fields G1, G2, G3, G8-16; all instances of G5/G6 in the newly created accounting
44 container are eliminated.
45 • Mark the UDR as pending32 if the “S” bit in the A11 Registration-Request message or P-P
46 Registration-Request message that carries the Session Setup Airlink Record is set to '1'.
47 • When the Active Stop Airlink Record for the previous R-P or P-P connection arrives,
48 update the accounting fields inside the newly created accounting container. (See section
49 11.5.6 for further processing of the Airlink Stop Record).
31
Bi-casting occurs when the A11-Registration Request or P-P-Registration Request has the ‘S’
bit set to 1.
32
A "pending" UDR is one for which usage data is not accumulated because another UDR is
accumulating usage data, e.g., because of bicasting.
- 67 - 3GPP2
1 Or:
2 • Create a copy of the current UDR.
3 • Use information received from the RN to fill the following fields in the copy UDR: D3 and
4 D4. The PDSN fills in D2 (in case of an IPv6 PDSN, D5).
5 • Zero fields G1, G2, G3, and G8-16 in the copy UDR; all instances of G5/G6 in the copy
6 UDR are eliminated.
7 • Send a RADIUS Accounting-Request (Start) record containing a new Account Session ID
8 and the same Correlation ID.
9 • Mark the new UDR as pending if the “S” bit in the A11 Registration-Request message or
10 P-P Registration-Request message that carries the Session Setup Airlink Record is set
11 to '1'.
12 • When the Active Stop Airlink Record for the previous R-P or P-P connection arrives,
13 update the current UDR and send a RADIUS Accounting-Request (Stop) record based
14 on the current UDR. The RADIUS Accounting-Request (Stop) record contains a Session
15 Continue attribute with the value set to 1 (True), the same correlation ID, and the original
16 session ID. (See section 11.5.6 for further processing of the Airlink Stop Record).
17
18 Otherwise (i.e., there is no handoff), the Serving PDSN shall use the R-P Connection Setup
19 Airlink record (from the current RN) to fill the following fields of the new UDR:
20
21 • A1, A2, A3, D3, and D4
22 • Zero fields G1-G16.
23
24 The Serving PDSN shall populate the remaining fields of the UDR as specified in sections 11.5.2
25 and 11.5.5.
26 11.5.2 Packet Data Service Establishment

27 After the PDSN establishes a packet data service session (i.e., Simple IP or Mobile IP) on the
28 main service instance, or a new R-P connection setup associated with an auxiliary service
29 instance occurs with an existing packet data session, the Serving PDSN shall:
30
31 • Fill the following fields: B1, (in case of IPv6 MS, B3), B2, C1, C2, C4, D1, D2 (in case of
32 IPv6 PDSN, D5), F11, F12, and I1.
33 • Send a RADIUS Accounting-Request (Start) record based on the current UDR.
34 11.5.3 Packet Data Service Termination

35 After the Serving PDSN terminates packet data service to the MS for every UDR, the Serving
36 PDSN shall:
37
38 • Add a Session Continue attribute in the UDR with the value set to 0 (False).
39 • Send a RADIUS Accounting-Request (Stop) record based on the current UDR.
40 • Delete the UDR after receiving acknowledgment from the RADIUS server that it has
41 successfully received the UDR.
42
43 If the reason for the packet data termination is due to the MS sending an LCP Configure-Request
44 message, and if the MS is not in a fast handoff state, then for every UDR the Serving PDSN shall:
45
46 • Create a copy of the current UDR using A1, A2, A3, D3, D4, F1-F14 and I4 from the
47 current UDR in the new UDR.
48 • Zero fields G1, G2, G3, and G8-13 in the new UDR.
49 • Add a Session Continue attribute in the current UDR with the value set to 0 (False).
51 • Delete the current UDR after receiving acknowledgment from the RADIUS server that it
52 has successfully received the UDR.
- 68 - 3GPP2
1 • Follow Packet Data Service Establishment accounting procedures for each new UDR
2 immediately after packet data establishment.
3 11.5.4 User Data Through PDSN

4 For any user data processed by the Serving PDSN in the forward direction, the Serving PDSN
5 shall use the MS IP address and SR_ID to find the correct UDR. If the UDR is not pending then
6 the PDSN shall:
7
8 • Increment G1 before compression by the number of octets in IP packets sent to the user.
9 • Increment G16 before compression by the number of octets in Mobile IP signaling
10 packets33 sent to the user.
11 • If the source IP address of the user packet is one of the remote addresses authorized for
12 the user for destination based accounting, a G5/G6 instance is created in the UDR for
13 this address (if one does not exist already), and the Forward Octet Count field in this
14 G5/G6 instance is incremented before compression as necessary.
15
16 For any user data processed by the Serving PDSN in the reverse direction, the Serving PDSN
17 shall use the MS IP address and SR_ID to find the correct UDR. If the UDR is not pending then
18 the PDSN shall:
19
20 • Increment G2 after decompression by the number of octets in IP packets sent by the
21 user.
22 • Increment G14 by the number of octets received at the HDLC layer.
23 • Increment G15 after decompression by the number of octets in Mobile IP signaling
24 packets sent by the user.
25 • If the destination IP address of the user packet is one of the remote addresses
26 authorized for the user for destination based accounting, a G5/G6 is created in the UDR
27 for this address (if one does not exist already), and the Reverse Octet Count field in this
28 G5/G6 instance is incremented after decompression as necessary.
29
30 If the UDR is pending, the PDSN shall not modify the accounting usage data of the UDR.
31 11.5.5 Active Start Airlink Record Arrives

32 When the PDSN receives an Active Start Airlink record from the RN or Target PDSN, the Serving
33 PDSN performs the following.
34
35 If the UDR is new (some fields are blank), the Serving PDSN shall:
36
37 • Set UDR fields according to airlink record: E1 e1, F1-F10 f1-f10, F14 f14, and I4
38 i4
39 • If the UDR is pending, mark it as not pending.
40
41 Otherwise, if the airlink record indicates parameters E1, F1, F2, or I4 have changed, the Serving
42 PDSN shall either:
43
44 • Create a new Container attribute in the UDR with Container-Reason Parameter
45 change, Event-timestamp current time and attributes E1, F1, F2, G1, G2, G3, G8-G16,
46 I4, and all instances of G5/G6.
47 • Set UDR fields according to the airlink record. E1 e1, F1 <- f1, F2 <- f2, I4 i4, and
48 zero fields G1, G2, G3, and G8-16. All current instances of G5/G6 in the UDR are
49 eliminated.
50 Or:
33
This means IP, UDP, and the MIP message payload above UDP.
- 69 - 3GPP2
1 • Add a Session Continue attribute in the current UDR with the value set to 1 (True).
3 • Set UDR fields according to airlink record. E1 e1, F1 <- f1, F2 <- f2, I4 i4 and zero
4 fields G1, G2, G3, and G8-16. All current instances of G5/G6 in the UDR are eliminated.
5 • Send a RADIUS Accounting-Request (Start) record based on UDR containing a new
6 Account Session ID and same Correlation ID.
7
8 Finally, the PDSN shall increment G9 by one.
9 11.5.6 Active Stop Airlink Record Arrives

10 When the Serving PDSN receives an Active Stop Airlink record from the RN, the PDSN shall:
11
12 • Increment G8 by the value of g8.
13 11.5.7 SDB Airlink Record Arrives

14 The PDSN shall increment G1/G2 for all forward/reverse user data corresponding to the MS IP
15 address. When the Serving PDSN receives an SDB airlink record from the RN or the Target
16 PDSN, the Serving PDSN shall use the MS IP address and SR_ID to find the correct UDR or
17 UDRs in the event of multiple packet data sessions.
18
19 If the mobile originated / mobile terminated indicator is equal to one (mobile terminated SDB), the
20 Serving PDSN shall:
21
23 • Increment G12 by one.
24
25 If the mobile originated / mobile terminated indicator is equal to zero (mobile originated SDB), the
26 Serving PDSN shall use the MS IP address and SR_ID to find the correct UDR. The PDSN shall:
27
29 • Increment G13 by one.
30 11.5.8 Interim Record Trigger

31 When the Interim Record Trigger initiates, the Serving PDSN shall send a RADIUS Accounting-
32 Request Interim record based on the current UDR. The Interim Record Trigger is an operator
33 configurable time interval since the last RADIUS accounting record was sent for a UDR.
34 11.5.9 Stop Record Trigger

35 Additional conditions may trigger a RADIUS Accounting-Request (Stop) record to be sent by the
36 PDSN such as:
37
38 • When the size of the RADIUS accounting record to be sent for the UDR exceeds an
39 operator configurable threshold.
40 • Any time during a session as an implementation dictates.
41
42 When the Stop Record Trigger initiates, the PDSN shall add a Session Continue attribute in the
43 UDR with the value set to 1 (True). The PDSN shall send a RADIUS Accounting-Request (Stop)
44 record based on the current UDR and fields G1, G2, G3, G8-16 are zeroed and all current
45 instances of G5/G6 in the UDR are eliminated. Immediately afterwards, the PDSN shall send a
46 RADIUS Accounting-Request (Start) record based on the current UDR containing a new Account
47 Session ID and the same Correlation ID.
- 70 - 3GPP2
1 11.5.10 Time of Day Timer Expires

2 The time of day timer(s) shall be a set of operator configurable parameters for certain time(s) of
3 day. These timers may be used, for example, to delineate peak and off-peak billing hour
4 boundaries.
5
6 When an accounting time of day timer expires, the Serving PDSN shall either:
7
8 • Create a new Container attribute in the UDR with Container-Reason Tariff Boundary,
9 Event-timestamp current time and attributes G1, G2, G3, and G8-G16. Instances of
10 G5/G6 are copied to the container.
11 • Zero fields G1, G2, G3, and G8-16. All current instances of G5/G6 in the UDR are
12 eliminated.
13 Or,
14 • Add a Session Continue attribute in the UDR with the value set to 1 (True).
16 • Zero fields G1, G2, G3, and G8-16. All current instances of G5/G6 in the UDR are
17 eliminated.
18 • Send a RADIUS Accounting-Request (Start) record based on current UDR containing a
19 new Account Session ID and the same Correlation ID.
20
- 71 - 3GPP2
1 12 P-P Interface
2 12.1 Architecture
3 The network reference model is depicted in Figure 1 and Figure 2. This section describes the
4 functionality for a fast handoff in the context of an inter-PDSN handoff. This section provides P-P
5 interface details. See [4] for fast handoff procedures over the R-P interface.
6
7 With the implementation of the P-P Interface, the following additional functions are provided by
8 the PDSNs during fast handoff:
9
10 • For every R-P connection at the Target PDSN, there is a corresponding P-P connection.
11 • The Target PDSN does not terminate PPP.
12 • The Target PDSN provides transparent bi-directional transport of the bearer data stream
13 over the R-P and P-P connections.
14 • The Serving PDSN provides bi-directional transport of the bearer data stream over the P-
15 P connections.
16 • The Target PDSN forwards accounting related airlink records received over an R-P
17 connection to the Serving PDSN over the corresponding P-P connection.
18 • The Serving PDSN processes airlink records received over the P-P connection similar to
19 the airlink records received over the R-P connection by creating separate UDRs.
20 The Target PDSN becomes the Serving PDSN when all service instances on the Target
21 RN are released (e.g., dormant) or PPP is re-negotiated by the MS. When the MS closes
22 the PPP session, the Serving PDSN shall release the P-P connections, and the Target
23 PDSN shall release the R-P connections. At handoff, the Target PDSN shall use the
24 main service instance to carry on PPP negotiations.
25
26 During a fast handoff, either two R-P connections, an R-P and P-P connection, or two P-P
27 connections may exist momentarily with the same SR_ID and MSID due to the PDSN bicasting to
28 both the Source and Target RNs.
29 12.2 The P-P Interface Protocol

30 This section specifies the protocol and messages to be used for signaling for the P-P
31 connections. Implementation of the P-P Interface is independent of the physical and link layers of
32 the transport media over which the P-P connection(s) is/are to be established. The underlying
33 transport media provides UDP/IP based packet oriented connectivity.
34
35 There are two components for the P-P Interface:
36
37 • Signaling: Control messages shall be used for managing the P-P connection(s) between
38 Serving and Target PDSNs.
39 • Bearer Transport: GRE frames shall be used for the transport of bearer data frames
40 between Serving and Target PDSNs.
41
42 The Target PDSN shall initiate establishment of a P-P connection, whereas either the Serving
43 PDSN or the Target PDSN may initiate termination of the connection. Termination of a P-P
44 connection shall follow the procedures for R-P connections as specified in [4]. Once a P-P
45 connection has been established, the bearer portion of the P-P connection shall use GRE
46 framing (RFC 2784, RFC 2890) for the transport of bearer data frames. There shall be one P-P
47 connection between the Serving PDSN and the Target PDSN for each R-P connection between
48 the Target PDSN and Target RN. The GRE payloads in the P-P connection and R-P connection
49 shall be identical for the same connection.
- 72 - 3GPP2
1 12.2.1 Signaling
2 The following messages shall be used for P-P Interface call control and signaling34:
3
4 • P-P Registration-Request
5 • P-P Registration-Reply
6 • P-P Registration-Update
7 • P-P Registration-Acknowledge
8
9 These messages use the same format as R-P connection messages specified in [4], including
10 use of the same UDP port number ’699’. The entire signaling message shall be sent within a
11 single UDP datagram. The source IP address of the P-P Registration-Request message and P-P
12 Registration-Acknowledge messages is set to the Target P-P Address and the destination IP
13 address is set to the Serving P-P Address. The source IP address of the P-P Registration
14 Update-Request and P-P Registration-Reply messages is set to the Serving P-P Address and the
15 destination IP address is set to the Target P-P Address.
16
17 The initiator of the P-P connection (Target PDSN) shall pick an available source UDP port, and
18 send a P-P Registration-Request message to the desired destination (Serving PDSN) at UDP
19 port ‘699’. The recipient (Serving PDSN) shall send a P-P Registration-Reply message to the
20 initiator’s (Target PDSN) UDP port that initiated the P-P Registration-Request message. The
21 following indicates the setting of the fields within a P-P Registration signaling message:
22
23 • Care-of address = Target P-P Address (P-P Registration-Request message and
24 Acknowledge message)
25 • Home Address = 0.0.0.0 (all)
26 • HA Address = Serving P-P Address (P-P Registration-Request message, Reply
27 message, and Update message)
28 • MN-HA Authentication Extension = Target PDSN to Serving PDSN MIP Authentication
29 Extension
30
31 The procedures to support fast handoff over the R-P interface are defined in [4].
32 12.2.2 Bearer Transport

33 The P-P bearer frames shall use the same payload format as used on the R-P interface,
34 specified in [4]. The procedures for selection and use of the GRE key are as outlined in [4].
35 12.3 P-P Handoff

36 The P-P interface shall use the P-P Registration-Request message, P-P Registration-Reply
37 message, P-P Registration-Update message, and P-P Registration-Acknowledge message to
38 manage P-P connections. The following sections describe the messages and procedures for the
39 P-P interface.
40
41 In order to obtain packet data services, the MS performs registration with the packet data
42 network. The service instance(s) is/are assigned and an R-P connection(s) is/are established for
43 each service instance between the Serving RN and the Serving PDSN on behalf of the MS. For
44 multiple service instances, handling of the bearer data streams over the R-P connections is
45 determined according to Section 10.2.
46
47 During the course of the packet data session, the MS moves into the coverage area of a Target
48 RN, resulting in a hard handoff. The following two sections specify the hard handoff for active
49 and dormant service instances separately.
50
34
P-P messages use [4]; see corresponding R-P messages.
- 73 - 3GPP2
1 This specification assumes that RN specific handoffs move both active and dormant service
2 instances to the Target RN.
3 12.3.1 Active Service Instances

4 On detection of a condition that a hard handoff is required, the Source RN initiates handoff
5 procedures with the Target RN (via the MSC).
6
7 If the Serving PDSN is reachable from the Target RN, the fast handoff is performed as specified
8 in [4], and the Serving PDSN shall release:
9
10 • Existing R-P connection(s) to the Source RN if different from the Target RN
11 • P-P connection(s) associated with the MS35 as a result of a handoff back from the Target
12 PDSN to the Serving PDSN
13
14 If the Serving PDSN is not reachable from the Target RN, the Target RN selects a Target PDSN
15 and establishes one R-P connection for each service instance to that PDSN. The R-P
16 Registration-Request message(s) have the 'S' bit set to indicate bicasting of the bearer payloads
17 and contain the Serving P-P Address, the identity of the MS, and an R-P Connection Setup
18 Airlink Record. The Target PCF also includes an indication in the R-P Registration-Request to
19 indicate if the R-P connection carries the main service instance. The Target PDSN shall
20 immediately respond with an R-P Registration-Reply message that contains the serving P-P
21 address as received in the R-P Registration-Request message. For each R-P connection so
22 established, the Target PDSN attempts to establish a P-P connection to the Serving PDSN with
23 the 'S' bit set (to indicate bicasting of the bearer payloads).
24
25 The Serving PDSN shall use the SR_ID information in conjunction with the mobile identifier to
26 find the link layer context information associated with the service instance. The Serving PDSN
27 determines whether a P-P connection supports the main service instance to the MS. The
28 Serving PDSN shall apply existing link layer context (e.g., compression, PPP, etc.) when sending
29 packets on the P-P connection.
30
31 If the Serving PDSN accepts the P-P Registration-Request message, and this P-P connection
32 carries the main service instance, the Serving PDSN shall return a P-P Registration-Reply
33 message with a PPP Link Indicator Extension (see Section 12.6) that indicates that the P-P
34 connection supports the main service instance. The Serving PDSN shall start to bicast bearer
35 data that is appropriately conditioned according to the link layer control to both the Source RN via
36 the R-P connection (see Figure 17), or to the previous Target PDSN via the previous P-P
37 connection (see Figure 19), and the Target PDSN via the P-P connection. The Serving PDSN
38 shall bicast until it receives a P-P Registration-Request with the 'S' bit clear. The Target PDSN
39 shall forward bearer data to the Target RN via the R-P connection. The Target RN discards
40 bearer data until the associated service instance is successfully established.
41
42 Upon successful handoff of a service instance to the Target RN, the Target RN shall deliver the
43 bearer data from the associated R-P connection to the MS. Also, the Target RN sends an R-P
44 Registration-Request message with the ‘S’ bit clear and an Active Start Airlink Record to the
45 Target PDSN.
46
47 The Target PDSN shall forward the Active Start Airlink Record to the Serving PDSN over the just
48 established P-P connection(s) in a P-P Registration-Request message with the 'S' bit clear.
49 Upon reception of P-P Registration-Request messages with the ‘S’ bit clear, the Serving PDSN
50 shall release the corresponding R-P connections to the Source RN as identified by the SR_ID, or
51 the P-P connections to the previous Target PDSN.
35
In particular, this addresses the case of a new Target PDSN being exactly the same as the
currently Serving PDSN.
- 74 - 3GPP2
1
2 The Target and Serving P-P addresses, along with the GRE Key form the unique link layer ID for
3 each P-P connection. With the P-P connection(s) in place, bearer data frames pass over these
4 connection(s) in both directions via GRE framing. In the reverse direction, the Serving PDSN
5 shall accept the P-P frames, process and remove the GRE overhead, and then shall process the
6 GRE payload, as necessary. In the forward direction the Serving PDSN shall encapsulate bearer
7 data frames in GRE. The Target PDSN shall process and remove the GRE overhead before
8 passing the bearer data to the associated R-P connection. On the R-P connection, the Target
9 PDSN shall encapsulate the bearer data frames in GRE and shall forward them to the Target RN.
10 Thus, the Target PDSN shall provide a transparent bi-directional transport for the bearer data
11 frames between the R-P connection and the P-P connection so that there is a point-to-point link
12 layer connection for each service instance between the MS user and the Serving PDSN.
13
14 The Target PDSN shall maintain the P-P connections by periodically sending P-P Registration-
15 Request messages to the Serving PDSN with ‘S’ bit clear. The lifetime field in the P-P
16 Registration-Request message shall be set to a value large enough to prevent frequent re-
17 registrations. Each P-P connection shall be maintained as long as the corresponding R-P
18 connection exists at the Target PDSN. When all the service instances become dormant, or the
19 MS renegotiates PPP, the fast handoff shall be completed according to Section 12.4.5.
20 12.3.2 Dormant Service Instances

21 There are two cases to consider when an MS with dormant service instances moves to an RN in
22 a different packet zone:
23
24 • The MS has one or more dormant service instances and no active service instances.
25 • The MS has one or more dormant service instances and one or more active service
26 instances.
27
28 In the first case, usual dormant handoff procedures apply and there is no fast handoff.
29
30 In the second case, the active service instances are connected first. Then the Target PDSN
31 receives the R-P Registration-Request messages for the dormant service instances with the 'S'
32 bit cleared from the Target RN, and determines that there is a fast handoff already in progress for
33 the MS. The Target PDSN then shall establish P-P connections for each of the new R-P
34 connections to the Serving PDSN. If the Serving PDSN accepts the P-P Registration-Request
35 message, it shall return a P-P Registration-Reply message with PPP Link Indicator Extension
36 (see Section 12.6) if the P-P connection supports the main service instance.
37 12.4 Detailed P–P Interface Procedures
38 12.4.1 P-P Connection Establishment

39 When a Target PDSN that supports fast handoff receives an R-P Registration-Request from the
40 Target RN that contains a Serving P-P address, it shall establish a P-P connection to the Serving
41 PDSN. To establish a P-P connection the Target PDSN shall send a P-P Registration-Request
42 message to the Serving PDSN including the R-P Connection Setup Airlink Record36 (as received
43 from the Target RN) and start the timer Tregreq (see [4]). If this timer expires, the Target PDSN
44 shall resend the P-P Registration-Request with R-P connection Setup Airlink Record an operator
45 configurable number of times or until an Active Start Airlink Record is received from the Target
46 RN. In the event all these P-P Registration-Request messages fail, the fast handoff is
47 abandoned and the Target PDSN shall release all P-P connections, if any. The Target PDSN
48 shall negotiate PPP with the MS and shall send its own P-P address to the Target RN as Serving
36
Airlink records are sent over the P-P connection by the use of Critical Vendor/Organization
Specific Extension as specified in [4].
- 75 - 3GPP2
1 P-P address (see [4]).restart PPP over the main service instance, if it received an indication from
2 the Target RN that identifies the main service instance.
3
4 In the P-P Registration-Request message, the Target PDSN shall set the Home Address field to
5 zero, the HA Address field to the Serving P-P address, and the Care-of Address field to the
6 Target P-P address. The Mobile Identifier, SR_ID, and Target PDSN Session Identifier Key shall
7 be included in the Session Specific Extension. The Target PDSN shall assign a Target PDSN
8 Session Identifier Key for the P-P connection. The Target PDSN Session Identifier Key shall be
9 unique within a Target PDSN entity. The ‘S’, ‘T’, and ‘G’ bits shall be set. The Lifetime field shall
10 be set to Tpresetup, whose value is sufficient for the service instance to handoff from the Source RN
11 to the Target RN. The IP source and destination addresses in the IP header shall be set to the
12 Target P-P and the Serving P-P address, respectively.
13
14 If the P-P Registration-Request message is acceptable, the Serving PDSN shall update the
15 binding record for the MS by creating an association between among the IMSI, SR_ID, the Target
16 PDSN Session Identifier Key, Serving PDSN Session Identifier Key (if asymmetric P-P session
17 identifier keys are supported between the Target PDSN and the Serving PDSN), the Target P-P
18 address, and the Serving P-P address. The Serving PDSN shall indicate to the Target PDSN if
19 the newly established P-P connection is the main service instance by including the PPP Link
20 Indicator Extension with a value of 'main service instance, continuing (0)' in a P-P Registration-
21 Reply message to the Target PDSN.
22
23 The Serving PDSN shall assign a Serving PDSN Session Identifier Key37 for the P-P connection,
24 if asymmetric P-P session identifier keys are supported between the Target and Serving PDSNs.
25 The Serving PDSN Session Identifier Key is unique within a Serving PDSN entity. The Serving
26 PDSN shall return a P-P Registration-Reply message with an accept indication. In the P-P
27 Registration-Reply message, the Serving PDSN sets the MS Home Address field to zeros. The
28 HA Address fields shall be set to the serving P-P address of the Serving PDSN. The Mobile
29 Identifier, SR_ID and Serving PDSN Session Identifier Key shall be included in the Session
30 Specific Extension. The Lifetime field shall be set to Tpresetup (see [4]), whose value is sufficient
31 for the traffic channel to handoff from the Source RN to the Target RN. The IP source address
32 and the IP destination address in the IP header shall be set to Serving P-P PDSN address and
33 the Target P-PPDSN address, respectively.
34
35 On receipt of the P-P Registration-Reply message, the Target PDSN shall create a binding
36 record for the MS by creating an association between among the IMSI, SR_ID, the Serving PDSN
37 Session Identifier Key, and the Serving P-P Address information, the and TargetServing PDSN
38 Session Identifier Key, the R-P Interface PDSN Session Identifier Key, the Target PCF Session
39 Identifier Key, and the Target PCF IP address. Bearer data now flows both to the Source RN via
40 the R-P connection and to the Target PDSN over the newly established P-P connections, or for
41 the case of a continuing fast handoff, to the previous Target PDSN via the previous P-P
42 connection and to the Target PDSN over the newly established P-P connection.
43
44 The Target PDSN shall use the SR_ID and the Mobile Identifier to uniquely identify a packet data
45 service instance for a specific MS across RNs and PDSNs.
46
47 The GRE keys for the P-P session (i.e., the Target PDSN Session Identifier and Serving PDSN
48 Session Identifier) shall be chosen according to [4].
49
50 The Target PDSN shall forward the bearer data to the Target RN via the pre-setup R-P
51 connection. The Target RN discards bearer data until such time the service instances are
52 successfully handed over to it.
53
37
This is the same as the PCF Session Identifier Key as defined in [4].
- 76 - 3GPP2
1 On handoff of the active service instance(s) to the Target RN, the Target RN forwards the Start
2 Airlink Records to the Target PDSN over the pre-setup R-P connection(s), with R-P connection
3 Lifetime set to Trp38 (see [4]) and ‘S’ bit cleared39. The Target RN also starts periodically re-
4 registering with the Target PDSN before the expiration of the R-P connection Lifetime.
5
6 If the service instance is not handed over to the Target RN, the pre-setup R-P connection is
7 automatically released on expiry of timer Tpresetup (see [4]). 40
8
9 If the P-P connection has been established successfully by the time the Active Start Airlink
10 Record is received from the Target RN, the Target PDSN shall forward the Active Start Airlink
11 Record over the P-P connection to the Serving PDSN.
12
13 On receipt of the R-P-Registration-Request message with zero lifetime from the Source RN, or a
14 P-P Registration-Request message with zero lifetime from the previous Target PDSN (i.e., as in
15 Figure 19), the Serving PDSN shall stop transport of the user data stream to the Source RN or
16 previous Target PDSN and release the R-P or P-P connection, respectively. Also, following the
17 reception of the Active Stop Airlink Record the Serving PDSN may release the associated R-P
18 connection with the Source RN, or P-P connection to the previous Target PDSN. The Target
19 PDSN shall also start periodically re-registering with the Serving PDSN before the expiration of
20 the P-P connection Lifetime. On receipt of P-P Registration-Request message with ‘S’ bit not set,
21 the Serving PDSN shall stop transport of the bearer data stream to the Source RN or previous
22 Target PDSN.
23
24 If the service instances are not all handed over to the Target RN, the Target PDSN shall
25 automatically release the established P-P connections between the Target PDSN and the
26 Serving PDSN on expiry of timer Tpresetup.
27 12.4.2 P-P Establishment Connection Failure

28 When the Target PDSN receives the R-P Registration-Request from the Target RN, the Target
29 PDSN shall initiate setup of the P-P connections with the Serving PDSN. If the Serving PDSN
30 does not accept the connections, it shall return a P-P Registration-Reply message with a reject
31 result code.
32
33 Depending on the result code, the Target PDSN may attempt to retry setting up of the P-P
34 connection(s). If the P-P connection(s) cannot be established, the Target PDSN shall abandon
35 P-P connection establishment. If the Target PDSN has knowledge of the main service instance,
36 the Target PDSN should initiate PPP negotiation by sending an LCP Configure-Request over the
37 main service instance. Otherwise, the Target PDSN shall request release of all the R-P
38 connections with the Target RN for this MS.
39
40 At the time an Active Start Airlink Record is received from the Target RN, if the corresponding P-
41 P connection with the Serving PDSN has not yet been established successfully, the Target PDSN
42 shall fail the fast handoff. It shall initiate release of all P-P connections with the Serving PDSN
43 and all R-P connections with the Target RN for this MS. However, if the Target PDSN has
44 knowledge of the main service instance, the Target PDSN should initiate PPP negotiation by
45 sending an LCP Configure-Request over the main service instance. Otherwise, the Target PDSN
46 shall request release of all the R-P connections with the Target RN for this MS.
47
38
Trp is the lifetime of the R-P connection with the 'S' bit clear.
39
The Serving and Target RN should take appropriate measures to avoid rapid establishment
and release of the serving PDSN to RN R-P connections in the face of a ping-pong condition in
which the MS moves rapidly between the Serving and Target RN.
40
Tpresetup is the lifetime of the R-P connection with the 'S' bit set and is much shorter than Trp.
- 77 - 3GPP2
1 The P-P Registration-Request message may be retransmitted if no P-P Registration-Reply

2 message is received within a configurable time (TRegreq.). Setup of a P-P connection is
3 considered to have failed if no P-P Registration-Reply message is received after a configurable
4 number of P-P Registration-Request message retransmissions.
5 12.4.3 P-P Connection – Periodic Re-registration

6 The Target PDSN shall periodically refresh the P-P connection with the Serving PDSN by
7 sending a P-P Registration-Request message before P-P connection registration lifetime (Tpp41)
8 expires. The Serving PDSN shall return a P-P Registration-Reply message with an accept
9 indication, including the refreshed Lifetime timer value for the P-P connection. The P-P
10 Registration-Request message may be retransmitted if no P-P Registration-Reply message is
11 received within a configurable time.
12
13 If no P-P Registration-Replies are received after a configurable number of P-P Registration-
14 Request message retransmissions for a P-P connection, the Target PDSN shall renegotiate PPP
15 with the MS, if the PDSN has knowledge of the main service instance, otherwise, the Target
16 PDSN shall immediately release the P-P connections and the R-P connections for the MS. The
17 Serving PDSN shall release the PPP session if there is no P-P or R-P connection supporting the
18 main service instance.
19 12.4.4 P-P Interface Release Procedures

20 This section provides an overview of the P-P procedures. The complete P-P interface release
21 procedures, such as handling of timers, are identical to the R-P connection release procedures
22 found in [4].
23
24 The release of P-P connections can be initiated either by the Target PDSN or the Serving PDSN.
25 12.4.4.1 P-P Connection Release – Target PDSN Initiated

26 The Target PDSN shall initiate the release of a P-P connection if the corresponding R-P
27 connection has been released, or if executing a fast handoff completion. The Target PDSN shall
28 release a P-P connection by sending a P-P Registration-Request message to the Serving PDSN
29 with a lifetime field set to zero. The Target PDSN shall forward any Active Airlink Stop Record
30 received from the Target RN in the P-P Registration-Request message. The Serving PDSN shall
31 remove the binding information for the P-P connection, and returns a P-P Registration-Reply
32 message with a PPP Link Indicator Extension with the appropriate condition. On receipt of the P-
33 P Registration-Reply message, the Target PDSN shall remove binding information for the P-P
34 connection and may initiate PPP negotiation on the main service instance to the MS if the value
35 of the PPP Link Indicator Extension is set to one. The Serving PDSN shall release the
36 associated link context and R-P connection (if one exists).
37
38 If the Target PDSN does not receive a P-P Registration-Reply message after sending a
39 configurable number of P-P Registration-Request message retransmissions, the Target PDSN
40 shall remove the binding information for all the P-P and associated R-P connections for the MS.
41 12.4.4.2 P-P Connection Release – Serving PDSN Initiated

42 The Serving PDSN shall initiate the release of a P-P connection if the MS returns to an RN that
43 can reach the Serving PDSN, or if the PPP inactivity timer expires and the MS is not Always On,
44 or the Serving PDSN closes the PPP session, or if the MS renegotiates or closes PPP, or for
45 administrative reasons. The Serving PDSN may initiate release of a P-P connection by sending a
46 P-P Registration-Update message to the Target PDSN with a termination indication. When the
47 Serving PDSN releases the P-P connections because the MS terminates PPP, the Serving PDSN
48 shall indicate to the Target PDSN not to restart negotiate PPP. When the Serving PDSN
41
Tpp is the lifetime of the P-P connection.
- 78 - 3GPP2
1 releases the P-P connections because the MS renegotiates PPP, the Serving PDSN shall
2 indicate to the Target PDSN to restart negotiate PPP with a P-P Registration-Update message
3 containing a PPP Link Indicator Extension with a value of 1 (negotiate PPP). In this case, the
4 Target PDSN shall reuse the existing R-P connections to renegotiate the PPP link with the MS. If
5 the P-P connection is released by the serving PDSN without an indication to negotiate PPP, tThe
6 Target PDSN shall release the corresponding R-P connection if one exists. In either case, the
7 Target PDSN shall, remove the binding information for the P-P connection, and return a P-P
8 Registration-Acknowledge message. The Target PDSN shall send a P-P Registration-Request
9 message with a lifetime of zero containing any accounting related information received from the
10 Target RN. On receipt of the P-P Registration-Request message, the Serving PDSN shall
11 respond with a P-P Registration-Reply message and remove binding information for the P-P
12 connection along with any associated link context.
13
14 If the Serving PDSN does not receive a P-P Registration-Acknowledge message after
15 transmitting a configurable number of P-P Registration-Update messages, the Serving PDSN
16 shall remove the binding information for all the P-P connections for the MS. It shall also initiate
17 release of the associated link layer context for the MS and R-P connections if one exists.
18 12.4.5 P-P Fast Handoff Completion

19 At some point in time, all connected service instances on the Target RN go dormant. The Target
20 RN includes an “all dormant” VSE in the R-P Registration-Request sent to the Target PDSN
21 when the last service instance goes dormant. This R-P Registration-Request also contains an
22 Active Stop Airlink Record for that last service instance. The Target PDSN shall in turn forward
23 the "all dormant" VSE and the Active Stop Airlink Record in the P-P Registration Request to the
24 Serving PDSN. The Target PDSN shall initiate PPP negotiation with the MS when it receives an
25 Active Start Airlink Record from the Target PCF. Simultaneously, the Target PDSN shall initiate
26 release of the P-P connections with the Serving PDSN for the MS.
27
28 The Target PDSN becomes the new Serving PDSN after completing a new PPP session
29 negotiation with the MS. The Target PDSN shall update the Target RN with the new Serving P-P
30 Address (i.e., its own P-P address) in the next R-P Registration-Reply message. This update
31 occurs immediately as a result of an Active Start Airlink Record when the MS transitions from
32 dormant to active as a result of LCP renegotiation. The new Serving PDSN shall use the stored
33 R-P Connection Setup Airlink Record from the original R-P connection establishment for
34 accounting purposes. If the MS desires MIP service after the Target PDSN completes PPP
35 renegotiation, the MS shall perform MIP registration.
36 12.5 Bicasting Scenarios

37 Bicasting is temporary and starts at the Serving PDSN upon reception of a R-P or P-P
38 Registration-Request with the 'S' bit set. Unicast of the payload data resumes at the Serving
39 PDSN upon reception of a R-P or P-P Registration-Request with the 'S' bit clear. The following
40 scenarios show bicasting of payload data during fast handoff:
41
42 1. Intra PDSN (see Figure 16)
43 2. Inter PDSN, start of fast handoff (see Figure 17)
44 3. Intra PDSN, during fast handoff on Target PDSN (see Figure 18)
45 4. Inter PDSN, during a fast handoff from one Target PDSN to another Target PDSN
46 (see Figure 19).
47
48 Cases 1 and 3 are specified in [4].
49
- 79 - 3GPP2
Serving PDSN
R-
P
R-P interface
A1 inte
A10, A11
0, rfa
A1 c e
1
bicasting
Source RN Target RN
Mobile station
1
2 Figure 16 - Intra PDSN Handoff
3
P-P interface
Serving PDSN Target PDSN
bicasting
R-P interface
R-P interface
A10, A11
A10, A11
Source RN Target RN
Mobile station
4
5 Figure 17 - Inter PDSN, Beginning of Fast Handoff
6
- 80 - 3GPP2
P-P interface
Serving PDSN Target PDSN
R-P interface
R-
P
A10, A11
A1 int
0, erf
A1 ac
1 e
bicasting
Source RN Target RN
Mobile station
1
2 Figure 18 - Intra PDSN, Continuation of Fast Handoff on Target PDSN
P-P Interface 2
bicasting
P-P Interface 1
Serving PDSN Target PDSN 1 Target PDSN 2
R-P interface
R-P interface
A10, A11
A10, A11
Source RN Target RN
Mobile station
3
4 Figure 19 - Inter PDSN Handoff, Continuation of Fast Handoff Between Target PDSNs
5
6
- 81 - 3GPP2
1 12.6 PPP Link Indicator Extension

2 The format of a normal P-P vendor specific extension is as follows:
3
4
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Type Length Reserved
Vendor/Org-ID
Vendor-NVSE-Type Vendor-NVSE-Value
5
6 Type: 134
7 Length: 10
8 Vendor/Org-ID: 5535
9 Vendor-NVSE-Type: 16
10 Vendor-NVSE-Value:
11 0: main service instance, continuing
12 1: main service instance, restart negotiate PPP
13 2: main service instance, do not restart negotiate PPP
14
15 When the NVSE is present and set to zero, it serves simply to indicate the main service instance.
16 When set to one, it indicates that the PPP session is being renegotiated and the Target PDSN
17 should attempt to negotiate PPP by sending an LCP Configure-Request message to the MS over
18 the main service instance. When set to two, it indicates that the PPP session is closed and the
19 Target PDSN shall not attempt to negotiate the PPPThis VSE shall be present in a P-P
20 Registration-Reply message when the P-P connection for the main service instance is
21 established or released. It signifies that the associated service instance is the main service
22 instance. When the VSE is present and set to zero, it serves simply to indicate the main service
23 instance. When set to one, it indicates that the PPP session is being renegotiated and the Target
24 PDSN should attempt to re-start PPP by sending an LCP Configure-Request message to the MS
25 over the main service instance. When set to two, it indicates that the PPP session is terminating
26 and the Target PDSN should not attempt to restart the PPP session.
27
- 82 - 3GPP2
1 13 Radio Network Requirements
2 13.1 General
3 The PDSN interfaces to the Radio Network only through the R-P interface and there are no RN
4 dependent signaling messages transmitted to the PDSN. However, there are some general
5 requirements placed on the RN:
6
7 • Each RN is connected to at least one PDSN.
8 • The RN relays PPP octets between the MS and PDSN.
9 • The RN establishes an R-P connection for each MS initiated packet data service
10 instance. If the MS initiates multiple service instances, each R-P connection is directed
11 to the same PDSN.
12 • The RN terminates the R-P connection if the MS terminates the corresponding packet
13 data service instance with the service inactive indication.
14 • The RN terminates all the R-P connections for the MS if the MS terminates the packet
15 data session with a power down indication.
16 • The RN terminates the R-P connection upon request from the PDSN.
17 • For some service options, the RN may buffer user data from the PDSN when radio
18 resources are not in place or insufficient to support the flow of data.
19 • The RN passes octets between the MS and PDSN without any framing conversion.
20
21 Note: No changes to the IP version used in the RN are required in order to support IPv6 MSs,
22 i.e., the IP version used in the RN (including the R-P interface), shall be independent of the IP
23 version of the packets carried in the PPP Sessions.
24 13.2 R-P Interface Requirements

25 The PDSN and RN shall support the R-P interface defined as A10 and A11 interfaces of [4].
26
27 In order to support fast handoff, the PDSN and the RN will support enhancements to the
28 A10 and A11 interfaces defined in [4] although procedures in [4] only deal with a single service
29 instance.
30
31 The PDSN shall use sequential numbering in the GRE packet header of packets on the R-P
32 interface, to ensure sequential delivery of packets over the R-P interface, if any of the following
33 events occurs:
34
35 • The PDSN is configured to send GRE packets that contain incomplete PPP frames or
36 multiple PPP frames.
37 • The MS negotiates a header or payload compression algorithm that requires PPP frames
38 to be delivered in sequence.
39
40 13.3 R-P General Handoff Capabilities

41 These requirements cover the duration of a packet data session and include periods when the
42 RN does not allocate radio resources to the MS (if such a dormant/standby capability is
43 supported by the RN).
44
45 • The RN has the capability to determine when an MS enters its coverage area.
46 • The RN is able to determine with which PDSN an MS currently has a PPP session, if a
47 PPP session already exists.
48 • During a packet data session, an MS may move outside the coverage area of one RN
49 into the coverage area of another RN. If the previous and the new RN have connectivity
- 83 - 3GPP2
1 to the same PDSN, the RNs release and re-establish the R-P session so that it connects
2 the new RN serving the MS and the PDSN in such a way that the MS maintains the same
3 PPP session.
4 • During a packet data session, an MS may move outside the coverage area of one RN
5 into the coverage area of another RN. If the previous and the new RN do not have
6 connectivity to the same PDSN, the new RN immediately establishes a new R-P session
7 to a new PDSN.
8
9 Specific handoff procedures for the R-P are not called out in this specification but can be found in
10 [4].
11
- 84 - 3GPP2
1 Annex A: IKE/ISAKMP Payloads

2 This Annex addresses ISAKMP payloads in which multiple options exist (see RFC 2407-2409).
3 The following requirements shall be met by the PDSN and HA, assuming IP security between the
4 HA and PDSN is required. Payloads in which no options exist do not appear in this Annex.
5
6 Note: If the HA (home network) does not require any security then Annex A does not apply nor
7 does it apply to MSs using collocated CoA for Mobile IP.
8
9 ISAKMP Fixed Header
10
11 The PDSN in this specification shall use a Major and Minor Version of 0. The HA shall
12 minimally accept Major and Minor Version of 0. This specification does not make use of
13 the Fixed Header Authentication (A) bit.
14
15 Security Association Payload:
16
17 All Security Association Payloads shall use the IPSec DOI. The Phase 1 ISAKMP
18 Security Payload shall specify a situation of SIT_IDENTITY_ONLY. Phase 2 ISAKMP
19 Security Payloads shall specify a situation of SIT_IDENTITY_ONLY for all cases where
20 privacy or only authentication applies (as outlined in the PDSN and HA "IP Security"
21 sections of this specification).
22
23 Proposal Payload:
24
25 Because the MS first makes contact with the PDSN, the PDSN shall be the Initiator of the
26 Phase 1 ISAKMP SA. The HA shall be the Responder. The PDSN shall propose
27 ISAKMP to the HA for the Phase 1 ISAKMP SA.
28
29 For Phase 2 Quick Mode exchanges, both the PDSN and HA shall be Initiators and
30 Responders because symmetrical, bi-directional security between the PDSN and HA is
31 required. For message authentication, PDSNs conforming to this specification shall
32 propose both AH42 and ESP with the authentication option. The HA shall respond with
33 ESP if the PDSN has proposed it. For message privacy, the PDSN shall propose ESP.
34 For combined authentication and privacy, the PDSN shall propose ESP only.
35
36 Mobile IP registration control packets and IP in IP tunneled packets may be protected by
37 IPSec authentication, privacy, or both. Security policies to be used between the PDSN
38 and the HA in this specification is dictated by the home network not the access provider
39 network. The PDSN shall be capable of proposing authentication only, privacy only, and
40 both authentication and privacy. Service provider owned HAs shall accept and propose
41 only one of these, and the PDSN shall accept this proposal. The Home RADIUS server
42 may deliver a User Profile to the Visited RADIUS server and PDSN that indicates
43 whether security should be supported for IP in IP packets. If the Home RADIUS server
44 indicates a request for no security on the IP-in-IP tunneled packets, the PDSN shall not
45 delete existing IPSec security associations to the HA. This is because IPSec should be
46 authorized per PDSN-HA pair and thus other MSs may be using those IPSec security
47 associations.
48
49 The SPI shall be four octets.
50
42
Note that a future version of this specification is likely to no longer require AH, in accordance
with industry trends.
- 85 - 3GPP2
1 Transform Payload:
2
3 For Phase 1, the PDSN shall use KEY_IKE as the transform identifier. All
4 implementations shall support 3DES and RSA.
5
6 For Phase 2 Quick Exchange, the PDSN shall minimally support the ESP_3DES
7 transform identifier within a Transform Payload for IPSec ESP Proposal Payload. It shall
8 also support both HMAC-MD5 and HMAC-SHA1 as transform identifiers within a
9 Transform payload for IPSec AH Proposal Payload. Service provider HAs shall likewise
10 support these two transforms. The PDSN may optionally support and propose other
11 transforms. An HA shall select one of the transforms offered by the PDSN.
12
13 Key Exchange Payload
14
15 The PDSN and HA will exchange D-H (Diffie-Hellman) public values computed in the D-H
16 group negotiated as part of a protection suite in the first message exchange of Phase 1
17 for ISAKMP SA establishment. The PDSN shall specify Phase 1 authentication with
18 certificates when the HA's certificate or HA's root CA certificate is available.
19
20 Otherwise, if a Dynamic pre-shared IKE secret distributed by the Home RADIUS server is
21 available, the PDSN shall specify Phase 1 authentication with a pre-shared secret mode
22 of operation. In this case, the PDSN shall specify Phase 1 Aggressive mode only. This is
23 necessary in order that the KeyID field can be transmitted in the clear. The Home
24 RADIUS server shall insure that the value of the ‘S’ key is hard to guess (i.e., a properly
25 generated random number) in order to prevent dictionary attacks that are possible with
26 Aggressive mode. If the PDSN has a statically configured IKE secret for the SA with the
27 HA, then the PDSN shall specify Phase 1 authentication with pre-shared secret mode of
28 operation. In this case the PDSN may either use Main Mode or use Aggressive Mode.
29 Otherwise, if a pre-shared secret is available, the PDSN shall specify Phase 1
30 authentication with a pre-shared secret mode of operation. The PDSN shall specify
31 Phase 1 Aggressive mode only. It shall not specify Phase 1 Main mode. This is
32 necessary in order that the KeyID field can be transmitted in the clear. The Home
33 RADIUS server shall insure that the value of the ‘S’ key is hard to guess (i.e., a properly
34 generated random number) in order to prevent dictionary attacks that are possible with
35 Aggressive mode.
36
37 Identification Payload
38
39 For Phase 1 negotiation, the PDSN shall set the Protocol-Id field to zero or UDP. The
40 port number shall be set to zero or 500. If the HA receives any other values for these two
41 fields in the Identification Payload, IKE negotiation shall be aborted.
42
43 For IKE authentication using pre-shared secret the PDSN and HA shall minimally support
44 ID_KEY_ID in the ID Type field. For IKE authentication using Revised Public Key
45 Encryption with RSA using X.509 certificates, the PDSN and HA shall minimally support
46 ID_DER_ASN1_DN in the ID Type field.
47
48 For Phase 2 (Quick Mode), both the PDSN and HA shall include the client identifiers in
49 the form of optional Client Identification Payloads as specified in IKE (i.e., IDci and IDcr).
50 To apply IPSec on all traffic between the PDSN and the HA, the PDSN and the HA shall
51 exchange IDci and IDcr. The protocol and port number fields shall be “don’t care” by
52 setting them to 0 in both IDci and IDcr. The following is an example of the format of the
53 client identifiers.
54 IDCi: Protocol field = 0, Port = 0, Idtype = ID_IPV4_ADDR,
55 Identification_data = PDSN_IPV4_ADDR.
- 86 - 3GPP2
1 IDCr: Protocol field = 0, Port = 0, Idtype = ID_IPV4_ADDR,

2 Identification_data = HA_IPV4_ADDR.
3 Two separate Quick Mode negotiations shall be performed to establish two different
4 types of IPSec security associations between the PDSN and HA to protect Mobile IP
5 control messages and tunneled user data.
6
7 For IPSec security for Mobile IP control packets, the PDSN and HA shall exchange IDci
8 and IDcr. The protocol field shall be set to UDP and port number to 434 for both IDci and
9 IDcr.
10
11 IDCi: Protocol field = UDP, Port = 434, Idtype = ID_KEY_ID, Identification_data =
12 PDSN_IPV4_ADDR
13 IDCr: Protocol field = UDP, Port = 434, Idtype = ID_KEY_ID, Identification_data =
14 HA_IPV4_ADDR
15
16 For IPSec on the user’s tunneled data, the PDSN and the HA shall exchange client
17 identification using a tunnel protocol type that matches the encapsulation type requested
18 by the MS’s RRQ. Examples of IDCi and IDCr values when IP-IP tunnel is used are:
19
20 IDCi: Protocol field = IP-IP, Idtype = ID_KEY_ID, Identification_data =
21 PDSN_IPV4_ADDR
22 IDCr: Protocol field = IP-IP, Idtype = ID_KEY_ID, Identification_data =
23 HA_IPV4_ADDR
24
25 Certificate Payload
26
27 The Certificate Payload shall carry X.509 version three certificates.
28
29 Signature Payload
30
31 The PDSN and HA shall not include this payload.
32
33 Notification Payload
34
35 The Notification Payload carries error messages and reason codes regarding failure for a
36 peer to be able to establish a security association. The PDSN and HA handling of a
37 failed security association establishment is specified in the main body of the standard.
38
39 The PDSN and HA shall use the "SA Lifetime Notify" code as a trigger to refresh the
40 indicated security association.
41
42 Delete Payload
43
44 The PDSN shall send a delete payload upon a SA refresh or upon request from a service
45 provider administrator.
46
- 87 - 3GPP2
1 Annex B: Certificates
2 PDSNs and HAs shall use X.509 Version 3 certificates in conformance with RFC 2459. Each
3 PDSN and HA in a service provider network may have a unique certificate which will be
4 configured into the PDSN and HA. The method of configuration of certificates is outside the
5 scope of this specification.
6
7 Note: This Annex only applies to FA CoA. Security between a collocated CoA MS and the HA is
8 outside the scope of this specification.
9
10 Each service provider may be a Certificate Authority for itself and its client private networks and
11 partner ISPs for PDSNs and for HAs that may be accessed by PDSNs. All PDSNs and HAs shall
12 be configured with all service provider CA certificates. There should be one CA root certificate
13 from each service provider.
14
15 Certificates for PDSNs and HAs
16
17 The Distinguished Name [RFC 2459] contained in the Issuer field is of form:
18
19 cdma2000.service-provider-name
20
21 The PDSN or HA determines the issuing service-provider (i.e., the CA) from the service-provider-
22 name attribute of the Issuer's Distinguished Name. The PDSN and HA then use the service-
23 provider-name attribute to locally access the CA's public key.
24
25 The PDSN and HA shall use the SHA-1 as a hash function and either the RSA or DSA signing
26 algorithm, as specified in RFC 2459 to verify a certificate. The private network or ISP shall
27 provide the public key and Distinguished Name of the certificate.
28
29 The Distinguished Name contained in the Subject field is of form:
30
31 cdma2000. service-provider-name.PDSN.service-provider-identifier
32 cdma2000. service-provider-name.HA.service-provider-identifier
33
34 Certificates in the PDSN and HA will not use the Unique-Identifier field.
35
36 Certificate extensions for PDSN and HA certificates shall not be supported.
37
38 The method of providing PDSNs and HAs signed certificates to PDSNs and HAs is outside the
39 scope of this specification.
40
41 CA Certificates
42
43 Service provider CA certificates shall be configured into all PDSNs and HAs. A service provider
44 CA contains the public key that the PDSN or HA shall use to verify the signature of a certificate
45 received in a Phase 1 ISAKMP exchange.
46
47 A CA certificate shall conform to the X.509 V3 certificates in RFC 2459. Since the service
48 provider CA distributes its own certificate, the Authority Key Identifier and Subject Key Identifier
49 extensions shall not be included in the certificate.
50
51 The method by which service providers exchange their CA certificates, as well as of providing
52 certificates into PDSNs and HAs, is outside the scope of this specification.
53
- 88 - 3GPP2
1 Certificate Revocation List (CRL)

2
3 CRLs shall be used to store the identities of certificates that have been compromised or are
4 otherwise invalid. CRLs shall conform to X.509 v2 as specified in RFC 2459. A future version of
5 this specification may make use of the Online Certificate Status Protocol.
6
7 Service providers shall exchange revoked certificate information (e.g., serial number). The
8 frequency of the exchange is outside the scope of this specification.
9
10 Possession of a certificate does not imply service since the RADIUS server and Mobile IP
11 functions still control the user obtaining service, as well as the HA allowing access to the PDSN.
12
13 The CA certificate shall indicate the service provider CA as Issuer of the CRL. The DN of the
14 Issuer shall be of form:
15
16 cdma2000.service-provider-name
17
18 CRLs exchanged between service providers shall use the SHA-1 as a hash function and either
19 the RSA and DSA signing algorithm as specified in RFC 2459.
20
21 CRL extensions shall not be supported.
22
23 The method of exchanging CRLs between service providers, or to conveying certificates client
24 private network or partnering ISP, as well providing this information into PDSNs and HAs, is
25 outside the scope of this specification.
26
- 89 - 3GPP2
1 Annex C: RADIUS Attributes

2 Figure 20 shows the general Vendor Specific Format for all 3GPP2 RADIUS attributes. The type
3 and vendor ID are the same for every attribute. The vendor ID of 5535 is used to indicate
4 3GPP2. Note: All integers are in network byte order.
5
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Type Length Vendor-ID
Vendor-ID (cont) Vendor-Type Vendor-Length
Vendor-value
6
7 Figure 20 - 3GPP2 RADIUS Attribute Format
8
9
10 IKE Pre-shared Secret Request: Indicates that the PDSN needs a pre-shared secret for Phase
11 1 IKE negotiation with the HA. This may appear in a RADIUS Access-Request message for MIP,
12 but not for Simple IP.
13
14 Type: 26
15 Length = 12
16 Vendor ID: 5535
17 Vendor-Type = 1
18 Vendor-Length = 6
19 Vendor-Value =
20 1 - The PDSN requests a pre-shared secret for IKE
21
22 Security Level: Indicates the type of security that the home network mandates on the visited
23 network; this attribute optionally appears in the RADIUS Access-Accept message.
24
25 Type: 26
26 Length = 12
27 Vendor ID: 5535
28 Vendor-Type = 2
30 Vendor-Value =
31 1 - IPSec for registration messages (deprecated)
32 2 - IPSec for tunnels (deprecated)
33 3 - IPSec for tunnels and registration messages
34 4 - No IPSec security
35
36 Pre-shared secret: A pre-shared secret for IKE that optionally appears in a RADIUS Access-
37 Accept message.
38
39 Type: 26
40 Length = 24
41 Vendor ID: 5535
42 Vendor-Type = 3
44 Vendor-Value = binary value of the pre-shared secret
45
46 Reverse Tunnel Specification: Indicates the style of reverse tunneling that is required, and
47 optionally appears in a RADIUS Access-Accept message.
48
- 90 - 3GPP2
1 Type: 26
2 Length = 12
3 Vendor ID: 5535
4 Vendor-Type = 4
5 Vendor-Length = 6
6 Vendor-Value =
7 0 - Reverse tunneling is not required
8 1 - Reverse tunneling is required
9
10 Differentiated Services Class Option: This attribute is deprecated and is replaced by the
11 Allowed Differentiated Services Marking attribute. The Home RADIUS server authorizes
12 differentiated services via the Differentiated Services Class Options attribute, and optionally
13 appears in a RADIUS Access-Accept message.
14
15 Type: 26
16 Length = 12
17 Vendor ID: 5535
18 Vendor-Type = 5
20 Vendor-Value
21 0 - Best Effort
22 10 - AF11
23 12 - AF12
24 14 - AF13
25 18 - AF21
26 20 - AF22
27 22 - AF23
28 26 - AF31
29 28 - AF32
30 30 - AF33
31 34 - AF41
32 36 - AF42
33 38 - AF43
34 46 - EF
35
36 The above values are taken from RFC 2597 and RFC 2598. There is no intention to convey the
37 actual traffic specification parameters of the differentiated services service.
38
39 Home Agent: The address of the HA that appears in a RADIUS Access-Request message,
40 RADIUS Access-Accept message, and accounting messages.
41
42 Type: 26
43 Length = 12
44 Vendor ID: 5535
45 Vendor-Type = 7
47 Vendor-Value = 4 octet IP address
48
- 91 - 3GPP2
1 Accounting Container: Contains embedded 3GPP2 VSAs and/or RADIUS accounting

2 attributes.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Container-Reason Event-Timestamp Event-Timestamp
Type = 55 Length = 6
Event-Timestamp Value
Embedded 3GPP2 AVPsVSAs and/or RADIUS accounting attributes
3
4 Type: 26
5 Length >= 224
6 Vendor-ID: 5535
7 Vendor-Type: 6
8 Vendor-Length >= 168
9 Container-Reason:
10 1. Tariff Boundary
11 2. Parameter Change
12 3. Handoff
13 Event-Timestamp: Value = The Value field is four octets encoding an unsigned integer
14 with the number of seconds since January 1, 1970 00:00 UTC.
15 Embedded 3GPP2 AVPsVSAs and/or RADIUS accounting attributes: One or more
16 parameters relating to Container-Reason above.
17
18 KeyID: Contains the KeyID parameter used during IKE exchange between the PDSN and the
19 HA. This parameter is returned by the Home RADIUS server to the PDSN in the RADIUS
20 Access-Accept message.
21 Type: 26
22 Length = 28
23 Vendor ID: 5535
24 Vendor-Type = 8
26 Vendor-Value =
27 A number formed from the concatenation of the Home RADIUS IP Address, and
28 the FA IP address, and a 32-bit timestamp, where each address is encoded
29 using eight hexadecimal ASCII characters. The timestamp contains the number
30 of seconds since January 1, 1970 00:00 UTC.
31
32 ‘S’ Key: Contains the ‘S’ secret parameter used to make Pre-shared secret. This parameter is
33 returned by the Home RADIUS to the HA in the RADIUS Access-Accept message.
34 Type: 26
35 Length: greater than 9
36 Vendor ID: 5535
37 Vendor-Type = 54
38 Vendor-Length = 3 or greater
39 Vendor-Value = binary value of the secret.
40
41 ‘S’ lifetime: Contains the lifetime of ‘S’ secret parameter used to make Pre-shared secret. This
42 parameter is returned by the Home RADIUS to the HA in the RADIUS Access-Accept message.
43 Type: 26
44 Length = 12
45 Vendor ID: 5535
- 92 - 3GPP2
1 Vendor-Type = 56
2 Vendor-Length = 6
3 Vendor-Value = Number of seconds since January 1, 1970 00:00 UTC.
4
5 'S' Request: Indicates whether the HA requests a shared secret "S". This appears in a RADIUS
6 Access-Request message to the Home RADIUS server:
7
8 Type: 26
9 Length = 12
10 Vendor ID: 5535
11 Vendor-Type = 55
13 Vendor-Value =
14 1. The HA requests a 'S' secret for IKE
15
16 MN-HA shared key: A shared key for MN-HA that optionally appears in a RADIUS Access-
17 Accept message. The MN-HA shared key is encrypted using a method based on the RSA
18 Message Digest Algorithm MD5 [RFC 1321] as described in Section 3.5 of RFC 2868.
19
20 Type: 26
21 Length: 26 or greater
22 Vendor ID: 5535
23 Vendor-Type = 58
24 Vendor-Length = 20 or greater
25 Vendor-Value = two octets for the salt field as defined in RFC 2868 followed by at least
26 16 octets containing the binary value of the encrypted MN-HA shared secret
27
28 MN-HA SPI: The SPI for the MN-HA shared key that optionally appears in a RADIUS Access-
29 Request message. It is used to request an MN-HA shared key.
30
31 Type: 26
32 Length = 12
33 Vendor ID: 5535
34 Vendor-Type = 57
36 Vendor-Value = binary value of the MN-HA SPI
37
38 DNS Update Required: Indicates whether the HA needs to send DNS Update to the DNS
39 server. This optionally appears in a RADIUS Access-Accept message.
40
41 Type: 26
42 Length = 12
43 Vendor ID: 5535
44 Vendor-Type = 75
46 Vendor-Value =
47 0 - HA does not need to send DNS Update
48 1 - HA needs to send DNS Update
49
50 Remote IPv4 Address: Allows the PDSN to identify an IP address to be used for remote address
51 based accounting for the user. It is only used in RADIUS Access-Accept messages. Up to ten
52 instances of the attribute shall be supported in one RADIUS Access-Accept message.
53
- 93 - 3GPP2
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Subtype (=1) Length Value (Remote IPv4 address)
Value (Remote IPv4 address) Subtype (=2) Length
Value (remote IPv4 address mask)
1
2
3 Type: 26
4 Length ≥= 20
5 Vendor ID: 5535
6 Vendor-Type: 59
7 Vendor-Length ≥= 14
8 Subtype (=1): type for remote IPv4 address attribute of value 1
9 Length: length of remote IPv4 address attribute (=6 octets)
10 Remote IPv4 Address:
11 The Remote IPv4 Address sub-attribute contains an IPv4 address to be used for
12 remote address based accounting for the user. The address is used in
13 conjunction with the Remote Address Mask (below), to define the range of
14 address to be monitored.
15 Subtype (=2): type for remote IP address mask of value 2
16 Length: length of remote IP address mask attribute (=6 octets)
17 Remote Address Mask:
18 The Remote Address Mask sub-attribute contains an IPv4 address mask that
19 defines a set of remote addresses to be used for remote address based
20 accounting.
21
22 Remote IPv6 Address: Allows the PDSN to identify an IP address to be used for remote address
23 based accounting for the user. It is only used in RADIUS Access-Accept messages. Up to ten
24 instances of the attribute shall be supported in one RADIUS Access-Accept message.
25
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Value (Remote IPv6 address)
Value (Prefix length)
26
27 Type: 26
28 Length ≥= 32
29 Vendor ID: 5535
30 Vendor-Type: 70
31 Vendor-Length ≥=26
32 Subtype (=1): type for remote IPv6 address attribute of value 1
33 Length: length of remote IPv6 address attribute (=18 octets)
34 Remote IPv6 Address:
35 The Remote IPv6 Address field contains a corresponding IPv6 address to be
36 used for remote address based accounting for the user.
37 Subtype (=2): type for prefix length of value 2
- 94 - 3GPP2
1 Length: length of prefix length attribute (=4)

2 Prefix Length:
3 The prefix length specifies the number of leading bits that must be matched. The
4 prefix length is less than or equal to 128.
5
6 Remote Address Table Index: Contains the index to remote addresses used to generate
7 remote address accounting records. The Home RADIUS server returns this parameter to the
8 PDSN in the RADIUS Access-Accept message.
9
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Reserved Remote Address Table Index
10
11 Type: 26
12 Length ≥=12
13 Vendor ID: 5535
14 Vendor-Type: 71
16 Remote Address Table Index: The Table Index is an identifier to a table of remote
17 addresses, available at the PDSN, used for remote-based accounting for the user.
18
19 Remote IPv4 Address Octet Count: This attribute indicates an IPv4 address and how many
20 bytes have been received from and sent to this address over the course of the service being
21 provided to the user. It is only present in RADIUS Accounting-Records where the Acct-Status-
22 Type is set to Stop or Interim.
23
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Value (remote IPv4 address mask)
Subtype (=3) Length Value (forward octet count)
Value (forward octet count) Subtype (=4) Length
Value (reverse octet count)
24
25
26 Type: 26
27 Length ≥=32
28 Vendor ID: 5535
29 Vendor-Type: 72
31 Subtype (=1): type for remote address attribute of value 1
32 Length: length of remote address attribute (variable: 6 octets for IPv4 and 18 octets for
33 IPv6)
34 Remote Address:
35 The Remote Address Field contains an IPv4 or IPv6 address used for
36 destination-based remote address based accounting by the user.
37 Subtype (=2): type for remote IP address mask of value 2
38 Length: length of remote IP address mask attribute (=6 octets)
- 95 - 3GPP2
1 Remote Address Mask:

2 The Remote Address Mask sub-attribute contains an IPv4 address mask that
3 defines a set of remote addresses to be used for remote address based
4 accounting.
5 Subtype (=3): type for forward octet count attribute of value 3
6 Length: length of forward octet count attribute (6 octets)
7 Forward Octet Count:
8 The Forward Octet Count Field indicates how many bytes have been received
9 from the Remote Address.
10 Subtype (=4): type for reverse octet count attribute of value 4
12 Reverse Octet Count:
13 The Reverse Octet Count Field indicates how many bytes have been sent to the
14 Remote Address.
15
16 Remote IPv6 Address Octet Count: This attribute indicates an IPv6 address and how many
17 bytes have been received from and sent to this address over the course of the service being
18 provided to the user. It is only present in RADIUS Accounting-Records where the Acct-Status-
19 Type is set to Stop or Interim.
20
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Value (Prefix length)
Subtype (=3) Length Value (forward octet count)
Value (forward octet count) Subtype (=4) Length
Value (reverse octet count)
21
22
23 Type: 26
24 Length ≥= 44
25 Vendor ID: 5535
26 Vendor-Type: 9780
28 Subtype (=1): type for remote address attribute of value 1
29 Length: length of remote address attribute (variable: 6 octets for IPv4 and 18 octets for
30 IPv6)
31 Remote Address:
32 The Remote Address Field contains an IPv4 or IPv6 address used for
33 destination-based remote address based accounting by the user.
34 Subtype (=2): type for prefix length of value 2
35 Length: length of prefix length attribute (=4)
36 Prefix Length:
37 The prefix length specifies the number of leading bits that must be matched. The
38 prefix length is less than or equal to 128.
39 Subtype (=3): type for forward octet count attribute of value 3
41 Forward Octet Count:
- 96 - 3GPP2
1 The Forward Octet Count Field indicates how many bytes have been received
2 from the Remote Address.
3 Subtype (=4): type for reverse octet count attribute of value 4
4 Length: length of forward reverse octet count attribute (6 octets)
5 Reverse Octet Count
6 The Reverse Octet Count Field indicates how many bytes have been sent to the
7 Remote Address.
8
9 Allowed Differentiated Services Marking: Specifies if the user is able to mark packets with AF
10 (A), EF (E). The Max Class (i.e., Max Selector Class), specifies that the user may mark packets
11 with a Class Selector Code Point that is less than or equal to Max Class.
12
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Subtype (=1) Length A E O Unused
Subtype (=2) Length Max class Unused
Subtype (=3) Length RT marking Unused
13
14
15 Type: 26
16 Length = 20
17 Vendor ID: 5535
18 Vendor-Type: 73
20 Subtype (=1): flags for Allowed Diffserv class
21 Length: 3 flags (= 4 octets)
22 "A" bit set means the user can send packets with AF DSCPs
23 "E" bit set means the user can send packets with EF DSCP
24 "O" bit set means the use can mark packets for experimental or local use
25 Subtype (=2): Max class selection marking
26 Length: (=4 octets)
27 Value: See Reverse tunnel marking
28 Subtype (=3): Reverse tunnel marking
29 Length: (= 4 octets)
30 RT-Marking:
31 '000000' = Default or Best Effort Forwarding, also Selector Class 0
32 '001010' = AF11
33 '001100' = AF12
34 '001110' = AF13
35 '010010' = AF21
36 '010100' = AF22
37 '010110' = AF23
38 '011010' = AF31
39 '011100' = AF32
40 '011110' = AF33
41 '100010' = AF41
42 '100100' = AF42
43 '100110' = AF43
44 '101110' = EF
45 '001000' = Selector Class 1
- 97 - 3GPP2

4
5 Other six bit long patterns are legal for this attribute, but are not standardized and
6 therefore may have unpredictable behavior in public networks and other networks not
7 configured to accept non-standard markings
8
9 Service Option Profile: This attribute specifies the authorized packet data service options, the
10 respective number of simultaneous service instances of the given service option number (n), and
11 the total maximum number of simultaneous service instances. This attribute may appear in a
12 RADIUS Access-Accept message.
13
14 1 2 3
15 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
16 T Type Length Vendor-ID
17 y Vendor-ID (cont) Vendor-Type Vendor-Length
18 p Max service instances total
19 e Subtype (=1) Length Service Option n Max number of
20 : service instances
21 of Service Option n
22 2
23
24 Length >=16
25 Vendor ID: 5535
26 Vendor-Type: 74
27 Vendor-Length >=10
28 Maximum Service Instances:
29 The maximum number of service instances the user is allowed to establish
30 regardless of the service option numbers. '1' represents one service instance,
31 i.e., the main service instance. '0' is not an allowed value.
32 Subtype (=1): type for service option
33 Length: length for service option attribute in octets (4 octets)
34 Service Option number
35 Maximum Service instances for this service option \
36 Subtype 1 may be repeated, once for each authorized service option.
37
38 Always On: Attribute indicating if the user has the “Always On” service or not.
39
40 Type: 26
41 Length = 12
42 Vendor ID: 5535
43 Vendor-Type = 78
45 Vendor-Value =
46 0 - Inactive
47 1 - Active
48
49 Foreign Agent Address: The IPv4 address of the PDSN CoA contained in RRQ.
50
51 Type: 26
52 Length =12
53 Vendor ID: 5535
54 Vendor-Type = 79
56 Vendor-Value =
- 98 - 3GPP2
1 FA IPv4 Address
2
3 MN-AAA Removal Indication: When received in a RADIUS Access-Accept, the PDSN shall not
4 include the MN-AAA Authentication and MN-FA challenge extensions when relaying the RRQ to
5 the HA.
6
7 Type: 26
8 Length = 12
9 Vendor ID: 5535
10 Vendor-Type = 81
12 Vendor-Value =
13 1 - MN-AAA not required
14
15 DNS Server IP Address: This VSA may be present in a RADIUS Access-Accept message. It
16 includes a Primary and a Secondary DNS server IP addresses.
17
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Sub-Type (=1) Length Value (Primary DNS IPv4 address)
Value (Primary DNS IPv4 address) Sub-Type (=2) Length
Value (Secondary DNS IPv4 address) Value (Secondary DNS IPv4 address)
Sub-Type (=3) Length M Unused Sub-Type (=4)
Length Entity-Type Unused
18
19 Type: 26
20 Length: 28
21 Vendor ID: 5535
22 Vendor-Type: 117
23 Vendor-Length: 22
24 Sub-Type (=1):
25 Length: (=4 octets)
26 Vendor-Value: Primary DNS server IP Address.
27 Sub-Type (=2):
28 Length: (= 4 octets)
29 Vendor-Value: Secondary DNS server IP Address.
30 Sub-Type (=3): Flag
31 Length: (=1 octet)
32 Vendor-Value: "M” bit set to 1 indicates to the PDSN that the Primary and
33 Secondary DNS IP addresses provided by the Home RADIUS server shall
34 override the Primary and Secondary DNS addresses if provided also by the
35 Visited RADIUS server.
36
37 Sub-Type (=4):
38 Length: (=1 octet)
39 Vendor-Value: “Entity-Type” The network entity that inserted in the DNS
40 server IP address. Currently the following types are defined:
41 HAAA = 1
42 VAAA = 2
43
44
- 99 - 3GPP2
1 Annex D: 3GPP2 VSAs Table

2 The following table provides a guide to the 3GPP2 vendor specific attributes that may be found in
3 the Access Request/Reply and Accounting Request messages (following the RADIUS standard
4 approach). The entries in the table are defined as follows:
5
6 0 This attribute shall not be present.
7 0+ Zero or more instances of this attribute may be present.
8 0-1 Zero or one instance of this attribute may be present.
9 1 Exactly one instance of this attribute shall be present.
10
Parameter Type Acces Access Accounting Accounting Accounting
s- - Start Stop Interim
Reque ReplyA
st ccept
IKE Pre-shared 26/01 0-1 0 0 0 0
Secret Request
Security Level 26/02 0 0-1 0 0 0
Pre-shared Secret 26/03 0 0-1 0 0 0
Reverse Tunnel 26/04 0 0-1 0 0 0
Specification
Differentiated 26/05 0 0-1 0 0 0
Services Class
Option
Container 26/06 0 0 0 0+ 0+
Home Agent 26/07 0-1 0-1 0-1 0-1 0-1
KeyID 26/08 0 0-1 0 0 0
Serving PCF 26/09 0 0 1 1 1
BSID 26/10 0 0 1 1 1
User Zone 26/11 0 0 0-1 0-1 0-1
Forward Mux Option 26/12 0 0 0-1 0-1 0-1
Reverse Mux Option 26/13 0 0 0-1 0-1 0-1
Service Option 26/16 0 0 1 1 1
Forward Traffic Type 26/17 0 0 0-1 0-1 0-1
Reverse Traffic 26/18 0 0 0-1 0-1 0-1
Type
Fundamental Frame 26/19 0 0 0-1 0-1 0-1
Size
Forward 26/20 0 0 0-1 0-1 0-1
Fundamental RC
Reverse 26/21 0 0 0-1 0-1 0-1
Fundamental RC
IP Technology 26/22 0-11 0 1 1 1
Compulsory Tunnel 26/23 0 0-1 0-1 0-1 0-1
Indicator
Release Indicator 26/24 0 0 0 1 0
Bad PPP Frame 26/25 0 0 0 0-1 0-1
Count
Number of Active 26/30 0 0 0 1 1
Transitions
SDB Octet Count 26/31 0 0 0 0-1 0-1
(Terminating)
SDB Octet Count 26/32 0 0 0 0-1 0-1
- 100 - 3GPP2
(Originating)
Number of SDBs 26/33 0 0 0 0-1 0-1
(Terminating)
Number of SDBs 26/34 0 0 0 0-1 0-1
(Originating)
IP Quality of Service 26/36 0 0 0-1 0-1 0-1
Airlink Priority 26/39 0 0 0-1 0-1 0-1
Airlink Record Type 26/40 0 0 0 0 0
Airlink Sequence 26/42 0 0 0 0 0
Number
Number of HDLC 26/43 0 0 0 0-1 0-1
layer bytes received
Correlation ID 26/44 1 0-1 1 1 1
Mobile Originated / 26/45 0 0 0-1 0-1 0-1
Mobile Terminated
Indicator
Inbound Mobile IP 26/46 0 0 0 0-1 0-1
Signaling Octet
Count
Outbound Mobile IP 26/47 0 0 0 0-1 0-1
Signaling Octet
Count
Session Continue 26/48 0 0 0 1 0-1
Active Time 26/49 0 0 0 0-1 0-1
DCCH Frame 26/50 0 0 0-1 0-1 0-1
Format
Beginning Session 26/51 0 0 0-1 0 0
ESN 26/52 0 0 0-1 0-1 0-1
‘S’ Key 0 0-1 0 0 0
26/54
‘S’ Request 26/55 0-1 0 0 0 0
‘S’ Lifetime 26/56 0 0-1 0 0 0
MN-HA SPI 26/57 0-1 0 0 0 0

MN-HA Shared Key 26/58 0 0-1 0 0 0
Remote IPv4 26/59 0 0+ 0 0 0
Address
Reserved 26/60-
69
Remote IPv6 26/70 0 0+ 0 0 0
Address
Remote Address 26/71 0 0+ 0 0 0
Table Index
Remote IPv4 26/72 0 0 0 0+ 0+
Address Octet
Count
Allowed 26/73 0 0-1 0 0 0
Differentiated
Services Marking
Service Option 26/74 0 0-1 0 0 0
Profile
DNS Update 26/75 0 0-1 0 0 0
Required
Always On 26/78 0 0-1 0-1 0-1 0-1
Foreign Agent 26/79 0-1 0 0 0 0
- 101 - 3GPP2
Address
Remote IPv6 26/978 0 0 0 0+ 0+
Address Octet 0
Count
MN-AAA Removal 26/81 0 0-1 0 0 0
Indication
MEID 26/116 0 0 0-1 0-1 0-1
DNS Server IP 26/117 0 0+ 0 0 0
Address
1
- 102 - 3GPP2
1 Annex E: Interim RADIUS Accounting

2 A RADIUS Interim Accounting record (with Acct-Status-Type = Interim-Update (3)) shall contain
3 all of the attributes found in an Accounting (Stop) message with the exception of the Acct-Term-
4 Cause and Release-Indicator attributes. The Session Continue attribute, if included, shall be set
5 to 1. The values of the attributes in the RADIUS Interim Accounting record shall be cumulative
6 since the RADIUS Accounting-Request (Start) record.
7
8 Since the accounting information is cumulative, the PDSN shall ensure that only a single
9 generation of an interim Accounting message for a given user and IP address is present in
10 retransmission queues at any given time.
11
12 The PDSN may add a random delay between RADIUS Interim Accounting messages for
13 separate sessions. This will ensure that a cycle where all messages are sent at once is
14 prevented.
- 103 - 3GPP2

P.S0001-B v2.0 041004

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

P.S0001-B v2.0 041004

Uploaded by

Copyright:

Available Formats

1 3GPP2 P.

4 2 GLOSSARY AND DEFINITION............................................................................................... 2

1 6.4.4 DNS Address Assignment ....................................................................................... 41

7 8 IP REACHABILITY SERVICE ............................................................................................... 47

1 12.2 THE P-P INTERFACE PROTOCOL ..................................................................................... 72

20 ANNEX B: CERTIFICATES .......................................................................................................... 88

21 ANNEX C: RADIUS ATTRIBUTES .............................................................................................. 90

22 ANNEX D: 3GPP2 VSAS TABLE............................................................................................... 100

23 ANNEX E: INTERIM RADIUS ACCOUNTING ........................................................................... 103

1 P.S0001 Revision History

1 2 Glossary and Definition

1 NAS Network Access System

51 Access Provider Network:

6 Auxiliary Service Instance:

14 Broker RADIUS Server:

20 Broker RADIUS Network:

40 Home Access Provider Network:

5 Link Local Address:

16 Packet Data Service:

19 Packet Data Service Option:

21 Packet Data Session:

40 Serving R-P Address:

42 Serving P-P Address:

5 Target P-P Address:

2 3.1 Normative References

1 RFC 2004, Perkins, Minimal Encapsulation within IP, October 1996.

1 4 Protocol Reference Models

7 4.1 Network Reference Models

Visited Access Provider Home Access

Visited Access Provider Home Access

MIP MIP IKE IKE MIP

PPP PPP Link Link

MIP MIP IKE IKE MIP

R-P R-P P-P P-P

RN PDSN target PDSN serving

L2 Relay L2 Relay PPP

R-P Interface P-P Interface

RADIUS RADIUS RADIUS RADIUS RADIUS RADIUS

UDP UDP UDP UDP UDP UDP

Link Link Link Link Link Link

RADIUS RADIUS RADIUS

8 5.1 Common Service Specification

11 5.1.1 PPP Session

27 5.2 PDSN Requirements

33 5.2.1 PPP Session

15 5.2.1.3 PPP Session Authentication

24 5.2.1.4 Addressing with IPCP

25 5.2.1.4.1 IPv4 Addressing

45 5.2.1.4.2 IPv6 Addressing

1 • Internet Protocol, Version 6 (IPv6) Specification [RFC 2460];

1 Neighbor discovery for IPv6 [RFC 2461]

21 5.2.1.5 Dual Stack of IPv4 and IPv6 Requirements

47 5.2.1.65.2.1.7 PPP Framing

4 5.2.1.75.2.1.8 PPP Link Status Determination

27 5.2.2 RADIUS Support

Attribute Name Type Access- Access- Interface(s)

27 5.2.2.1 NAI Construction in the Absence of CHAP or PAP

12 5.2.3 Ingress Address Filtering

33 5.3 RADIUS Server Requirements

21 5.4.1 PPP Session

45 5.4.1.4 Addressing with IPCP

46 The MS may support simultaneous operation of IPCP and IPv6CP.