Cdma2000 Wireless IP Network Standard: 3GPP2 P.S0001-B Version Date: September, 2004

1 2 3 4
3GPP2 P.S0001-B Version 2.0 Version Date: September, 2004
5 6
cdma2000 Wireless IP 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
1 2 3 4 5 6 7
Revision History Revision Rev. 0 Rev. A Rev. B Rev. B v2.0 Initial Publication Revision A of P.S0001 Version 1 of P.S0001 Revision B Version 2 of P.S0001 Revision B Date November 2002 May 2001 September 2002 September 2004
- ii -
3GPP2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
CONTENTS 1 2 INTRODUCTION...................................................................................................................... 1 GLOSSARY AND DEFINITION............................................................................................... 2 2.1 2.2 3 ACRONYMS ......................................................................................................................... 2 DEFINITIONS........................................................................................................................ 3
REFERENCES......................................................................................................................... 8 3.1 NORMATIVE REFERENCES.................................................................................................... 8 3.1.1 IETF ........................................................................................................................... 8 3.1.2 3GPP2 ..................................................................................................................... 10 3.1.3 TIA............................................................................................................................ 11 3.2 ITU-T ............................................................................................................................... 11 3.3 INFORMATIVE .................................................................................................................... 11 3.3.1 3GPP2 ..................................................................................................................... 11
PROTOCOL REFERENCE MODELS ................................................................................... 12 4.1 4.2 4.3 4.4 NETWORK REFERENCE MODELS ........................................................................................ 12 SIMPLE IP ......................................................................................................................... 13 MOBILE IP......................................................................................................................... 14 RADIUS........................................................................................................................... 18
SIMPLE IP OPERATION ....................................................................................................... 19 5.1 COMMON SERVICE SPECIFICATION ..................................................................................... 19 5.1.1 PPP Session ............................................................................................................ 19 5.2 PDSN REQUIREMENTS ..................................................................................................... 19 5.2.1 PPP Session ............................................................................................................ 19 5.2.2 RADIUS Support...................................................................................................... 23 5.2.3 Ingress Address Filtering ......................................................................................... 25 5.3 RADIUS SERVER REQUIREMENTS ..................................................................................... 25 5.4 MS REQUIREMENTS .......................................................................................................... 26 5.4.1 PPP Session ............................................................................................................ 26
MOBILE IPV4 OPERATION .................................................................................................. 30 6.1 COMMON SERVICE SPECIFICATION ..................................................................................... 30 6.1.1 PPP Session ............................................................................................................ 30 6.1.2 Mobile IP .................................................................................................................. 30 6.1.3 Dynamic Home Agent and Home Address Assignment.......................................... 30 6.2 PDSN REQUIREMENTS ..................................................................................................... 31 6.2.1 PPP Session ............................................................................................................ 31 6.2.2 MIP Registration ...................................................................................................... 32 6.2.3 RADIUS Support...................................................................................................... 34 6.2.4 IP Security Support .................................................................................................. 34 6.2.5 Ingress Address Filtering ......................................................................................... 36 6.3 HOME AGENT REQUIREMENTS ........................................................................................... 37 6.3.1 Multiple Registrations .............................................................................................. 37 6.3.2 MIP Authentication Support ..................................................................................... 37 6.3.3 IPSec Support.......................................................................................................... 38 6.3.4 Dynamic Home Agent Assignment .......................................................................... 39 6.3.5 DNS Address Assignment ....................................................................................... 39 6.4 RADIUS SERVER REQUIREMENTS ..................................................................................... 39 6.4.1 Dynamic Home Agent Assignment .......................................................................... 41 6.4.2 MN-HA Shared Key Distribution .............................................................................. 41 6.4.3 Dynamic Key Distribution Procedure....................................................................... 41
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 9 7 8
3GPP2
6.4.4 DNS Address Assignment ....................................................................................... 41 6.5 MOBILE STATION REQUIREMENTS ...................................................................................... 41 6.5.1 PPP Session ............................................................................................................ 41 6.5.2 MIP Registration ...................................................................................................... 43 6.6 DNS SERVER IP ADDRESS NVSE ..................................................................................... 44 SIMULTANEOUS SERVICE.................................................................................................. 46 IP REACHABILITY SERVICE ............................................................................................... 47 8.1 SIMPLE IP OPERATION ...................................................................................................... 47 8.2 MOBILE IP OPERATION ...................................................................................................... 47 8.2.1 DNS Update by the Home RADIUS Server............................................................. 47 8.2.2 DNS Update by the HA............................................................................................ 48 8.3 IPV6 IRS .......................................................................................................................... 48 MOBILITY MANAGEMENT ................................................................................................... 49 9.1 9.2 9.3 10 MOBILITY WITHIN RADIO NETWORK .................................................................................... 49 PCF TO PCF HANDOFF..................................................................................................... 49 PDSN TO PDSN HANDOFF ............................................................................................... 49 QUALITY OF SERVICE ..................................................................................................... 51
10.1 MULTIPLE SERVICE INSTANCES ...................................................................................... 52 10.1.1 MS Requirements .................................................................................................... 52 10.1.2 PDSN Requirements ............................................................................................... 53 10.2 QOS FLOW MAPPING AND TREATMENTS ......................................................................... 53 10.3 SUBSCRIBER QOS PROFILE ........................................................................................... 53 10.3.1 Allowed Differentiated Services Marking ................................................................. 53 10.3.2 PDSN-Based R-P Admission Control...................................................................... 54 11 ACCOUNTING ................................................................................................................... 55 11.1 GENERAL ...................................................................................................................... 55 11.1.1 Usage Data Records ............................................................................................... 55 11.1.2 Remote Address Accounting ................................................................................... 55 11.1.3 Accounting and Fast Handoff .................................................................................. 56 11.1.4 Accounting Attribute Notation .................................................................................. 57 11.2 AIRLINK RECORDS ......................................................................................................... 57 11.2.1 R-P Connection Setup Airlink Record ..................................................................... 58 11.2.2 Active Start Airlink Record ....................................................................................... 59 11.2.3 Active Stop Airlink Record ....................................................................................... 59 11.2.4 SDB Airlink Record .................................................................................................. 59 11.3 PDSN USAGE DATA RECORD (UDR) ............................................................................. 60 11.4 ACCOUNTING FORMATS.................................................................................................. 62 11.5 PDSN PROCEDURES ..................................................................................................... 66 11.5.1 R-P Connection Setup Airlink Record Arrives ......................................................... 67 11.5.2 Packet Data Service Establishment ........................................................................ 68 11.5.3 Packet Data Service Termination ............................................................................ 68 11.5.4 User Data Through PDSN ....................................................................................... 69 11.5.5 Active Start Airlink Record Arrives........................................................................... 69 11.5.6 Active Stop Airlink Record Arrives........................................................................... 70 11.5.7 SDB Airlink Record Arrives...................................................................................... 70 11.5.8 Interim Record Trigger............................................................................................. 70 11.5.9 Stop Record Trigger ................................................................................................ 70 11.5.10 Time of Day Timer Expires................................................................................... 71 12 12.1 P-P INTERFACE ................................................................................................................ 72 ARCHITECTURE .............................................................................................................. 72
- iv -
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
3GPP2
12.2 THE P-P INTERFACE PROTOCOL ..................................................................................... 72 12.2.1 Signaling .................................................................................................................. 73 12.2.2 Bearer Transport...................................................................................................... 73 12.3 P-P HANDOFF ............................................................................................................... 73 12.3.1 Active Service Instances.......................................................................................... 74 12.3.2 Dormant Service Instances...................................................................................... 75 12.4 DETAILED PP INTERFACE PROCEDURES ....................................................................... 75 12.4.1 P-P Connection Establishment ................................................................................ 75 12.4.2 P-P Establishment Connection Failure.................................................................... 77 12.4.3 P-P Connection Periodic Re-registration.............................................................. 78 12.4.4 P-P Interface Release Procedures .......................................................................... 78 12.4.5 P-P Fast Handoff Completion .................................................................................. 79 12.5 BICASTING SCENARIOS .................................................................................................. 79 12.6 PPP LINK INDICATOR EXTENSION ................................................................................... 82 13 13.1 13.2 13.3 RADIO NETWORK REQUIREMENTS .............................................................................. 83 GENERAL ...................................................................................................................... 83 R-P INTERFACE REQUIREMENTS .................................................................................... 83 R-P GENERAL HANDOFF CAPABILITIES ........................................................................... 83
ANNEX A: IKE/ISAKMP PAYLOADS .......................................................................................... 85 ANNEX B: CERTIFICATES .......................................................................................................... 88 ANNEX C: RADIUS ATTRIBUTES .............................................................................................. 90 ANNEX D: 3GPP2 VSAS TABLE............................................................................................... 100 ANNEX E: INTERIM RADIUS ACCOUNTING ........................................................................... 103
-v-
3GPP2
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Figures
Figure 1 - Reference Model for Simple IP Access ........................................................................ 12 Figure 2 - Reference Model for Mobile IP Access......................................................................... 13 Figure 3 - Protocol Reference Model for Simple IP Access .......................................................... 14 Figure 4 - Protocol Reference Model for Simple IP Access During Fast Handoff ........................ 14 Figure 5 - Protocol Reference Model for Mobile IP Control and IKE ............................................ 15 Figure 6 - Protocol Reference Model for Mobile IP Bearer Data .................................................. 16 Figure 7 - Protocol Reference Model for MIP Control and IKE During Fast Handoff.................... 16 Figure 8 - Protocol Reference Model for MIP Bearer Data During Fast Handoff.......................... 17 Figure 9 - Protocol Reference Model for Signaling for Fast Handoff ............................................ 17 Figure 10 - Protocol Reference Model for User Data for Fast Handoff......................................... 18 Figure 11 - RADIUS Protocol Reference Model............................................................................ 18 Figure 12- NVSE for DNS server IP address ................................................................................ 45 Figure 13 - Graphical Illustration of Multiple Connection Relationships ....................................... 52 Figure 14 - Accounting Architecture .............................................................................................. 55 Figure 15 - Accounting Architecture With Fast Handoff ................................................................ 57 Figure 16 - Intra PDSN Handoff .................................................................................................... 80 Figure 17 - Inter PDSN, Beginning of Fast Handoff ...................................................................... 80 Figure 18 - Intra PDSN, Continuation of Fast Handoff on Target PDSN ...................................... 81 Figure 19 - Inter PDSN Handoff, Continuation of Fast Handoff Between Target PDSNs............. 81 Figure 20 - 3GPP2 RADIUS Attribute Format ............................................................................... 90
- vi -
3GPP2
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Tables
Table 1 - Occurrence of RADIUS Attributes for Simple IP ............................................................ 24 Table 2 Home Agent and Home Address Scenarios ................................................................. 30 Table 3 Description of Scenarios ............................................................................................... 31 Table 4 Occurrence of RADIUS Attributes for Mobile IP............................................................ 40 Table 5 MS Registration Scenarios............................................................................................ 43 Table 6 R-P Connection Setup Airlink Fields ............................................................................. 58 Table 7 Active Start Airlink Fields............................................................................................... 59 Table 8 Active Stop Airlink Fields............................................................................................... 59 Table 9 SDB Airlink Fields.......................................................................................................... 59 Table 10 Complete UDR ............................................................................................................ 61 Table 11 Accounting Parameter Attribute RADIUS Definitions.................................................. 65
- vii -
3GPP2
P.S0001-Bv2.0
3GPP2
1 2
P.S0001 Revision History

Revision 0 A Date December 2000 May 2001 Comments Initial Publication 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. This specification has been revised to support the following features: 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 This addendum is provided to correct errors and omissions in the 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.
September 2002
B v2.0
September 2004
3 4
- viii -
3GPP2
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
1 Introduction
This specification defines requirements for support of wireless packet data networking capability on a third generation wireless system based on cdma20001. This specification supports the services and architecture in [1]. This specification defines the two methods for accessing public networks (Internet) and private networks (intranets): Simple IP and Mobile IP. It describes the required Quality of Service, Security, Mobility Management, and Accounting capabilities needed to support both methods. IETF protocols are widely employed whenever possible to minimize the number of new protocols required and to maximize the utilization of well accepted standards. This specification is organized in the following structure: Sections 2 and 3 are the Glossary and Definitions, and References, respectively. Section 4 describes the protocol reference models for Simple IP, Mobile IP, RADIUS, and the overall wireless packet data network. Sections 5 and 6 describe Simple IP operation and Mobile IP operation, respectively. Section 7 describes simultaneous Mobile IP and Simple IP services. Section 8 describes IP Reachability Service. Section 9 describes Mobility Management for PCF-PCF handoff, PDSN-PDSN handoff, and PDSN-PDSN Fast Handoff. Section 10 describes Quality of Service requirements and operation. Section 11 describes Accounting architecture and parameters. Sections 12 and 13 describe the P-P Interface, and Radio Network Requirements, respectively.
In this document, several key words are used to signify the requirements. The key words "shall", "shall not", "should", "should not", and "may" are to be interpreted as described in RFC 2119 and the TIA Engineering Style Manual.
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. -13GPP2
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52
2 Glossary and Definition

2.1 Acronyms
AAA ACCM AH AVP BS CA CCP CHAP CoA CRL CSRC D-H DN DNS DSA DOI ESP FA FAC GRE HA HAAA HDLC HLR HRPD IANA IETF IKE IMSI IMT-2000 IP IPv4 IPv6 IPCP ICMP IPv6CP IPSec IRM IRS ISAKMP ISP LAC LCP MAC MEID MIN MIP MS MSID NAI Authentication, Authorization, and Accounting Asynchronous Control Character Map Authentication Header Attribute Value Pair Base Station Certificate Authority Compression Control Protocol Challenge Handshake Authentication Protocol Care-of address Certificate Revocation List Contributing Source Diffie-Hellman Distinguished Name Domain Name System Digital Signature Algorithm Domain Of Interpretation Encapsulating Security Payload Foreign Agent Foreign Agent Challenge Generic Routing Encapsulation Home Agent Home AAA High-level Data Link Control Home Location Register High Rate Packet Data Internet Assigned Numbering Authority Internet Engineering Task Force Internet Key Exchange International Mobile Subscriber Identity International Mobile Telecommunications - 2000 Internet Protocol Internet Protocol version 4 Internet Protocol version 6 IP Control Protocol Internet Control Message Protocol IPv6 Control Protocol IP Security International Roaming MIN IP Reachability Service Internet Security Association and Key Management Protocol Internet Service Provider Link Access Control Link Control Protocol Medium Access Control Mobile Equipment Identifier Mobile Identification Number Mobile IP Mobile Station Mobile Station ID Network Access Identifier
-2-
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 NAS NCP NID NVSE PAP PCF PDSN PHB Pi PL P-P PPP PSI PZID QoS RADIUS RLP RN R-P RRP RRQ RSA RTP SA SDB SHA SID SPI SR_ID SSRC SS7 TCP TFT TSIG TTL UDP UDR VAAA VLR VSA VSE
3GPP2
Network Access System Network Control Protocol Network ID Normal Vendor Specific Extension Password Authentication Protocol Packet Control Function Packet Data Serving Node Per Hop Behavior PDSN Internet (Interface) Physical Layer PDSN-PDSN (Interface) Point-to-Point Protocol PCF Session ID Packet Zone ID Quality of Service Remote Authentication Dial In User Service Radio Link Protocol Radio Network RN-PDSN Interface Mobile IP Registration Reply Mobile IP Registration Request Rivest-Shamir-Adleman public key algorithm Real-time Transport Protocol Security Association Short Data Burst Secure Hash Algorithm System Identification Security Parameter Index Service Reference Identifier Synchronization Source Signaling System 7 Transmission Control Protocol Traffic Flow Template Transaction Signature Time To Live User Datagram Protocol Usage Data Record Visited AAA Visitor Location Register Vendor Specific Attribute Vendor Specific Extension
2.2 Definitions
A Resource Record: The A resource record type is a record specific to the Internet class that stores a single IPv4 address. AAAA Resource Record: The AAAA resource record type is a record specific to the Internet class that stores a single IPv6 address. Access Provider Network: A cdma2000 wireless network that provides access to cdma2000 users.
-3-
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
3GPP2
Always On: The Always On Service maintains the subscriber's packet data session in the local network (i.e., for Always On service, the PDSN shall not initiate release of the subscriber's packet data session, unless the PDSN determines the user is no longer reachable). Auxiliary Service Instance: Auxiliary service instance refers to an additional service instance that is initiated on a per need basis, e.g., when a service such as VoIP is invoked. The QoS characteristics of a auxiliary service instance are based on the needs of the application using it, e.g., low delay, maximum bit rate, guaranteed bit rate, etc. The auxiliary service instances only exist for the time that they are needed by the requesting application. An auxiliary service instance begins after the PPP session is established, and ends no later than when the PPP session ends. Broker RADIUS Server: An intermediate RADIUS server that has security relationships with the Visited RADIUS server and the Home RADIUS server and is used to securely transfer RADIUS messages between the Visited Access Provider Network and the Home IP Network. In some situations, there may be more than one broker RADIUS server in the path between the Visited RADIUS server and the Home RADIUS server. Broker RADIUS Network: A collection of administrative domains that contain Broker RADIUS servers. Default Treatment: The default treatment is the header and payload compressions that are applied to a packet by PPP. The particular compression technique for a given packet is chosen from the set of techniques negotiated during IPCP and CCP. Fast Handoff: An inter PDSN based low latency hard handoff between PCFs. Fast handoff between two PDSNs allows a mobiles PPP session to be maintained via a layer two tunnel passing through a Target PDSN to the Serving PDSN. Note: There is also an intra PDSN fast handoff that is described in [4] that is outside the scope of this specification. Handoff: In this specification the term "handoff" is defined to mean continuity of IP bindings or PPP link layer state during an interface change from one entity to another. In the absence of any continuity of state whatsoever, this specification does not refer to such interface changes as "handoffs". Home RADIUS: The RADIUS server that resides in the Home IP Network. HAAA: The AAA server that resides in the Home IP Network. Home Access Provider Network: A cdma2000 wireless network that is the home for the mobile subscriber unit. The user may have a different home network for data services. Home Address: An MS IP address that remains unchanged regardless of the MS's point of attachment to the network.
-4-
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46
3GPP2
Home IP Network: The home network that provides IP based data services to the user. This network is where the user's NAI is homed. This network may be a private network, publicly accessible ISP network, or a cdma2000 wireless network. Link Local Address: An IPv6 address whose scope is local to a link. Main Service Instance: The service instance initiated by an MS that is used for PPP negotiation. This specification allows an MS exactly one main service instance. For any PPP session, the main service instance is established first, before any auxiliary service instances are established. SR_ID: The SR_ID is the service instance identifier used to identify a given service instance. Packet Data Service: A general term used for any packet switched data service offered by an access provider network to a user through the users MS. Packet Data Service Option: A number specified in [13] that is used to identify a packet switched data service. Packet Data Session: Describes continuous use of packet data service by the user. A packet data session begins when the user invokes packet data service. A packet data session ends when the user or the network terminates packet data service. During a particular Mobile IP packet data session, the user may change its point of attachment while maintaining the same home address. For Simple IP service, changing points of attachments constitutes a change in packet data session because a new IP address is assigned by the new point of attachment. For Simple IP service, a packet data session and a PPP session are concurrent, where as for Mobile IP service, the packet data session can exist through several changes of the PPP session. Point of Attachment: Point of attachment refers to the node where the MS is connected to access the IP network. In the context of this specification, it refers to the PDSN entity. Pi: Pi is the interface between the PDSN and the public Internet. P-P Connection: A connection between a Serving and Target PDSN that uses a GRE tunnel to transport user data for a single service instance during fast handoff. P-P Interface: The interface between the Target PDSN and the Serving PDSN that is used to support fast handoff. P-P Session: The set of all P-P connections for a single MS.
-5-
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43
3GPP2
PPP Session: A PPP session describes the time during which the main service instance is maintained between the MS and the Serving PDSN. The PPP session is maintained while the MS is dormant. If a user hands off from one RN to another RN but is still connected to the same PDSN, the PPP session remains. Private Address: An IP address conforming to RFC 1918. Private Network: An IP Network that resides behind a firewall and that may use private IP addresses. RADIUS: The specific AAA server implementation used in cdma2000 networks for AAA functionality. The RADIUS servers may be located in the Home IP Network, the Broker Network, or the Visited Access Provider Network. Radio Network: The RN is equivalent to the BS and the PCF as defined in the Network Reference Model [14]. In this specification, the terms PCF and RN are used interchangeably when describing handoffs across the R-P interface. The RN is equivalent to the Radio Access Network (RAN) specified in [4]. R-P Connection: A connection between a PCF and a PDSN that uses a GRE tunnel to transport user data for a single packet data service instance. This is equivalent to the A10 connection specified in [4]. R-P Interface: The interface between the PCF and PDSN that transports user packet data and signaling messages, as specified in [4]. R-P Network: An IP network as defined in [4] connecting the RNs with the PDSNs. R-P Session: The R-P session is a collection of R-P connections for a single MS and is equivalent to a Packet Data Session as specified in [4]. Service Instance: A connection between an MS and PDSN used to transport user data for a packet data service. Associated with each service instance is a packet data service option, a service reference identifier (SR_ID), and an R-P connection. This specification defines two categories of service instances, a main service instance and an auxiliary service instance. Serving PDSN: A PDSN that supports the PPP session to an MS. Serving R-P Address: The R-P network interface IP address of the Serving PDSN. Serving P-P Address: The P-P network interface IP address of the Serving PDSN.
-6-
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
3GPP2
Target PDSN: A PDSN that co-operates with a Target RN over the R-P interface, and co-operates with the Serving PDSN over the P-P interface to provide link layer tunneling between the Serving PDSN and the Target RN in the context of a fast handoff. Target P-P Address: The P-P network interface IP address of the Target PDSN. User Profile: The User Profile is an abstraction for the collection of all the parameters applied to the user. The User Profile includes the Subscriber QoS profile (which itself includes the Allowed Differentiated Services Marking and Service Option profile). Visited Access Provider Network: The visited service provider provides access services through the establishment of a service agreement with a home service provider. Visited RADIUS: The RADIUS server that resides in the Visited Access Provider Network.
-7-
3GPP2
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51
3 References
3.1 Normative References
IETF 3.13.1.1 RFC 768, Postel, User Datagram Protocol, August 1980. RFC 791, Internet Protocol, Sept. 1981. RFC 792, Postel, Internet Control Message Protocol, September 1981. RFC 793, Transmission Control Protocol, September 1981. RFC1034, Mockapetris, Domain Names - Concepts and Facilities, November 1987. RFC 1035, Mockapetris, Domain Names - Implementation and Specification, November 1987. RFC 1122, Braden, Requirements for Internet Hosts - Communication Layers, October 1989. RFC 1144, Jacobson, Compressing TCP/IP Headers for Low Speed Serial Links, February 1990. RFC 1321, Rivest and Dusse, The MD5 Message-Digest Algorithm, MIT Laboratory for Computer Science, RSA Data Security Inc., April 1992. RFC 1332, McGregor, The PPP Internet Protocol Control Protocol (IPCP), May 1992. RFC 1661, Simpson, The Point-to-Point Protocol (PPP), July 1994. RFC 1662, Simpson, PPP in HDLC-like Framing, July 1994. RFC 1886, Thompson, Huitema, DNS Extensions to Support IP Version 6, December 1995. RFC 1877, Cobb, PPP Internet Protocol Control Protocol Extensions for Name Server Addresses, December 1995. RFC 1889, Schulzrinne, Casner, Frederick, Jacobson, RTP: A Transport Protocol for Real-Time Applications, January 1996. RFC 1918, Rekhter, Moskowitz, Karrenberg, de Groot, Lear, Address Allocation for Private Internets, February 1996. RFC 1962, Rand, The PPP Compression Control Protocol (CCP), June 1996. RFC 1974, Friend, Simpson, PPP Stac LZS Compression Protocol, August 1996. RFC 1979, Woods, PPP Deflate Protocol, August 1996. RFC 1994, Simpson, PPP Challenge Handshake Authentication Protocol (CHAP), August 1996. RFC 2002, Perkins, IPv4 Mobility, May 1995. RFC 2003, Perkins, IP Encapsulation within IP, October 1996.
-8-
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
3GPP2
RFC 2004, Perkins, Minimal Encapsulation within IP, October 1996. RFC 2005, Solomon, Applicability Statement for IP Mobility Support, October 1995. RFC 2006, Cong, Hamlen, Perkins, The Definitions of Managed Objects for IP Mobility Support Using SMIv2, October 1995. RFC 2118, Pall, Microsoft Point-To-Point Compression (MPPC) Protocol, March 1997. RFC 2119, Bradner, Key words for use in RFCs to Indicate Requirement Levels, March 1997. RFC 2136, Vixie, Thomson, Rekhter, Bound, Dynamic Updates in the Domain Name System (DNS UPDATE), April 1997. RFC 2138, Rigney, Rubens, Simpson, Willens, Remote Authentication Dial In User Service (RADIUS), August 1997. RFC 2139, Rigney, RADIUS Accounting, April 1997. RFC 2290, Simpson, Mobile-IPv4 Configuration Option for PPP IPCP, February 1998. RFC 2373, Hinden, Deering, IP Version 6 Addressing Architecture, July 1998. RFC 2374, Hinden, O'Dell, Deering, An IPv6 Aggregatable Global Unicast Address Format, July 1998. RFC 2401, Kent, Atkinson, Security Architecture for the Internet Protocol, November 1998. RFC 2402, Kent, Atkinson, IP Authentication Header, November 1998. RFC 2406, Kent, Atkinson, IP Encapsulating Security Payload (ESP), November 1998. RFC 2407, Piper, The Internet IP Security Domain of Interpretation for ISAKMP, November 1998. RFC 2408, Maughan et al, Internet Security Association and Key Management Protocol (ISAKMP), November 1998. RFC 2409, Harkins, Carrel, The Internet Key Exchange (IKE), November 1998. RFC 2459, Housley, Housley, Polk, Solo, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, January 1999. RFC 2460, Deering, Hinden, Internet Protocol, Version 6 (IPv6) Specification, December 1998. RFC 2461, Narten, Nordmark, Simpson, Neighbor Discovery for IP Version 6 (IPv6), December 1998. RFC 2462, Thomson and Narten, IPv6 Stateless Address Auto-configuration, December 1998. RFC 2472, Haskin, Allen, IP Version 6 over PPP (IPv6CP), December 1998. RFC 2474, Nichols, Blake, Baker, Black, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, December 1998. RFC 2475, Blake, Black, Carlson, Davies, Wang, Weiss, An Architecture for Differentiated Services, December 1998.
-9-
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54
3GPP2
RFC 2484, Zorn, PPP LCP Internationalization Configuration Option, January 1999. RFC 2486, Aboba, Beadles, The Network Access Identifier, January 1999. RFC 2507, Degermark, Nordgren, Pink, IP Header Compression, February 1999. RFC 2597, Heinanen, Baker, Weiss, Wroclawski, Assured Forwarding PHB Group, June 1999. RFC 2598, Jacobson, Nichols, Poduri, An Expedited Forwarding PHB, June 1999. RFC 2784, Farinacci et al, Generic Routing Encapsulation (GRE), March 2000. RFC 2794, Calhoun, Perkins, Mobile NAI Extension, March 2000. RFC 2865, Rigney, Willens, Reubens, Simpson, Remote Authentication Dial In User Service (RADIUS), June 2000. RFC 2866, Rigney, RADIUS Accounting, June 2000. RFC 2868, Zorn et al., RADIUS Attributes for Tunnel Support, June 2000. RFC 2890, Dommety, Key and Sequence Number Extensions to GRE, September 2000. RFC 2983, Black, Differentiated Services and Tunnels, October 2000. RFC 3006, Davie, Iturralde, Oran, Casner, Wroclawski, Integrated Services in the Presence of Compressible Flows, November 2000. RFC 3012, Calhoun, Perkins, Mobile IPv4 Challenge/Response Extensions, November 2000. RFC 3024, Montenegro, Reverse Tunneling for Mobile IP, January 2001. RFC 3041, Narten, Draves, Privacy Extensions for Stateless Address Autoconfiguration in IPv6, January 2001. RFC 3095, Borman, et al, Robust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed, July 2001. RFC 3162, Zorn et al., RADIUS and IPv6, August 2001. RFC 3241, Borman, ROHC over PPP, January 2002. 3.1.2 3GPP2 [1] P.R0001cdma2000 Wireless IP Architecture Based on IETF Protocols, December 2000. [2] N.S0017, International Implementation of Wireless Telecommunication Systems Compliant with TIA/EIA-41, December 2000. [3] TIA/EIA-553, Mobile Identification Number (MIN). [4] A.S0017-0, 3GPP2 Access Network Interfaces Interoperability Specification, November 2001. [5] C.S0001-A Introduction for cdma2000 Standards for Spread Spectrum Systems, June 2000.
- 10 -
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
3GPP2
[6] C.S0002-A, Physical Layer Standard for cdma2000 Standards for Spread Spectrum Systems, June 2000. [7] C.S0003-A, Medium Access Control (MAC) Standard for cdma2000 Standards for Spread Spectrum Systems, June 2000 [8] C.S0004-A, Signaling Link Access Control (LAC) Standard for cdma2000 Standards for Spread Spectrum Systems, June 2000. [9] C.S0005-A, Upper Layer (Layer 3) Signaling Standard for cdma2000 Standards for Spread Spectrum Systems, June 2000. [10] C.S0016-A, Over-the-Air Service Provisioning of Mobile Stations in Wideband Spread Spectrum Systems, December 2001. [11] C.S0017-0-2, Data Service Options for Spread Spectrum Systems Addendum 2, August 2000. [12] TIA/EIA/IS-751N.S0009, TIA/EIA-41-D Modifications to Support IMSI, February 1998. [13] TIA/EIA/TSB58-E, Administration of Parameter Value Assignments for cdma2000 Spread Spectrum Standards, January 2002. [14] TIA/EIA/TSB100-A, TR-45 Wireless Network Reference Model (NRM), March 2001. [15] TIA/EIA/IS-856-1C.S0024 v3.0, cdma2000 High Rate Packet Data Air Interface Specification - Addendum 1, December 2001January 2002. 3.1.3 TIA [3] TIA/EIA-553-A, Mobile Station Base Station Compatibility Standard, October 1999.
3.33.2 ITU-T
ITU-T Recommendation E.212, The International Identification Plan for Mobile Terminals and Mobile Users. ITU-T Recommendation X.509, Public-key and Attribute Certificate Frameworks.
3.3
Informative
3.3.1 3GPP2 [1] P.R0001cdma2000 Wireless IP Architecture Based on IETF Protocols, December 2000. [2] N.S0017, International Implementation of Wireless Telecommunication Systems Compliant with TIA/EIA-41, December 2000. [13] C.R1001-D v1.0, Administration of Parameter Value Assignments for cdma2000 Spread Spectrum Standards, April 2003. [14] S.R0005-B, Network Reference Model (NRM) for cdma2000 Spread Spectrum Systems, May 2001.
- 11 -
3GPP2
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
4 Protocol Reference Models

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

Figure 1 shows a reference model for Simple IP service. Figure 2 shows a reference model for Mobile IP service. For Internet access when the MS is in the home network or roaming, the HA resides in a home access provider network. For private network or home ISP access, the HA resides in the respective external network. The IP Network entity in Figure 1 and Figure 2 represents IP Networks that may reside in the public Internet as well as private IP networks between access provider networks and home IP networks. The optional P-P interface is used to support fast handoff between PDSNs.
MSC Visited Access Provider Network (serving)

A1
SS7 Network
HLR Home Access Provider network
RADIUS IP Network
RADIUS Home IP network

Pi
R-P interface A10, A11

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

A1
SS7 Network
HLR Home Access Provider network
RADIUS IP Network
RADIUS Home IP network

Pi
R-P interface A10, A11 Source RN Serving PDSN P-P interface

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

R-P PL P-P PL
Link Layer
P-P PL PL PL
MS
RN
PDSNtarget P-P Interface
PDSN serving
End Host
5 6 7 8 9 10 11 12 13 14
Figure 4 - Protocol Reference Model for Simple IP Access During Fast Handoff
4.3 Mobile IP
Figure 5 and Figure 6 show the protocol reference model for Mobile IP control and user data, respectively. IPSec is required in some situations, and not in other situations, as detailed in Section 6.2.4.
- 14 -
3GPP2
P.S0001-Bv2.0
3GPP2
MIP UDP IP
IKE MIP UDP IP IP/ IPsec
IKE UDP IP/ IPsec
MIP
PPP LAC/ RLP MAC Airlink LAC/ RLP MAC Airlink
PPP Link Layer R-P PL R-P PL PL PL Link Layer
1 2 3 4
Mobile Station
RN
PDSN
HA
Figure 5 - Protocol Reference Model for Mobile IP Control and IKE
- 15 -
3GPP2
P.S0001-Bv2.0
3GPP2
IP
IP IP/IPsec PPP LAC/ RLP MAC Airlink Link Layer R-P PL R-P PL PL PL Link Layer IP/IPsec
IP
IP
PPP LAC/ RLP MAC Airlink
Link Layer
Link Layer
PL
PL
2 3 4 5 6 7 8
Mobile Station
RN
PDSN
HA
End Host
Figure 6 - Protocol Reference Model for Mobile IP Bearer Data The protocol architecture for Mobile IP control and user data during fast handoff is illustrated in Figure 7 and Figure 8, respectively.
MIP UDP
MIP UDP I P
IKE
IKE UDP
MIP
IP
IP / IPsec
IP / IPsec
PPP
LAC/ RLP MAC Airlink LAC/ RLP MAC Airlink PL PL PL
PPP
Link Layer R-P R-P P-P P-P Link Layer
PL
PL
PL
MS
RN
PDSNtarget P-P Interface
PDSNserving
HA
9 10 11 12
Figure 7 - Protocol Reference Model for MIP Control and IKE During Fast Handoff
- 16 -
3GPP2
P.S0001-Bv2.0
3GPP2
IP IP IP/IPsec IP/IPsec
IP IP
PPP LAC/ RLP MAC Airlink LAC/ RLP MAC Airlink
PPP Link Layer R-P PL R-P PL P-P PL P-P PL PL PL PL Link Layer Link Layer Link Layer
PL
Mobile Station
RN
PDSN
target
PDSN
P-P Interface
serving
HA
End Host
1 2 3 4 5 6 7 8 9
Figure 8 - Protocol Reference Model for MIP Bearer Data During Fast Handoff Figure 9 and Figure 10 respectively show the protocol reference models for fast handoff. IKE and IPSec are optional on the P-P interface.
LAC
R-P Sig. UDP IP
R-P Signaling UDP IP Link Layer PL
P-P Sig.
IKE
IKE IP
P-P Sig. IPsec Link Layer
UDP IP IPsec Link Layer PL
UDP Link Layer PL
MAC Airlink
Link Layer PL
PL
RN R-P Interface
10 11 12 13 14
PDSN target
PDSN serving P-P Interface
Figure 9 - Protocol Reference Model for Signaling for Fast Handoff
- 17 -
3GPP2
P.S0001-Bv2.0
3GPP2
L2 Relay LAC MAC Airlink GRE IP

Link Layer
L2 Relay GRE IP
Link Layer
PPP GRE IP/IPsec

Link Layer
GRE IP/IPsec
Link Layer
Link Layer
PL
PL
R-P Interface
PL
PL
PL
P-P Interface
RN
PDSNtarget
PDSNserving
1 2 3 4 5 6 7 8 9 10 11 12 13
Figure 10 - Protocol Reference Model for User Data for Fast Handoff
4.4 RADIUS
Figure 11 shows the protocol reference model for the RADIUS entities in the wireless network (as illustrated in Figure 1 and Figure 2) between the PDSN (RADIUS client) and the Home RADIUS server. In this model, the RADIUS servers in the visited network communicate with the RADIUS servers in the home network via zero or more optional proxy (or Broker) RADIUS servers. A RADIUS server may run IPv4, IPv6, or both. The method of interworking between IPv4 and IPv6 RADIUS clients and servers is outside the scope of this specification.
RADIUS
RADIUS RADIUS
RADIUS RADIUS
RADIUS
UDP IP Link Layer PL
PDSN
RADIUS Visited
RADIUS Broker
(optional)
RADIUS Home
14 15 16 17
Figure 11 - RADIUS Protocol Reference Model
- 18 -
3GPP2
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42
5 Simple IP Operation
This section describes the requirements and procedures for Simple IP operation for both IPv4 [RFC 791] and IPv6 [RFC 2460]. In this specification, Simple IP refers to a service in which an MS is assigned an IP address and is provided IP routing service by an access provider network. The MS retains its IP address as long as it is served by a radio network that has connectivity to the address assigning PDSN. There is no IP address mobility beyond this PDSN. Secure access to a home network via Simple IP is beyond the scope of this specification.
5.1 Common Service Specification

The common requirements for several network elements (e.g., PDSN and MS) for Simple IP operation are described here. 5.1.1 PPP Session PPP shall be the data link protocol between the MS and the PDSN. The PPP session shall be established prior to any IP datagrams being exchanged between the MS and the PDSN. PPP shall be supported as defined in the following standards with any limitations or extensions described in this specification. Point to Point Protocol [RFC 1661]; PPP octet oriented HDLC [RFC 1662]; IPCP [RFC 1332] (for IPv4); IPv6CP [RFC 2472] (for IPv6); CHAP [RFC 1994]; PAP [RFC 1334].
PPP encryption shall not be negotiated by either the MS or PDSN. Only one PPP session shall be supported between the MS and the PDSN.
5.2 PDSN Requirements

The PDSN shall support Simple IP operation for both IPv4 and IPv6. For an IPv6 MS, the PDSN shall be the link local router and the PPP termination point. There shall be at least one /64 prefix assigned to each PPP session. Each /64 prefix shall be globally unique. 5.2.1 PPP Session
5.2.1.1 Establishment When the first R-P connection for the main service instance is established, the PDSN2 shall send an LCP Configure-Request for a new PPP session to the new MS. If an RN opens an R-P connection for which a PPP session already exists, the PDSN shall not send an LCP ConfigureRequest message to the MS. PPP shall support transparency in accordance with Section 4.2 of RFC 1662. The PDSN shall attempt to negotiate a control character mapping with the minimum number of escaped characters by proposing an ACCM of 0x00000000.
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
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
5.2.1.2 Termination The PDSN shall clear the PPP state if there is no established R-P or P-P session for the MS. The PDSN shall clear the R-P and/or P-P session whenever the PPP session is closed or expired. If the PDSN receives IP packets for an MS for which there is no established PPP session, the PDSN shall silently discard the packet. The PDSN shall close the R-P and associated P-P session whenever the MS closes the PPP session. The PDSN may receive the Always On attribute with value 1 from the HAAA in order to activate the Always On service for a user. To implement Always On service for a user, the PDSN shall utilize the expiration of the PPP inactivity timer and the procedures described in Section 5.2.1.8 to determine if the PPP session should be closed. If Always On service is not enabled and the PPP inactivity timer for a PPP session expires, the PDSN shall close the PPP session. 5.2.1.3 PPP Session Authentication The PDSN shall support the two authentication mechanisms: CHAP and PAP. The PDSN shall also support a configuration option to allow an MS to receive Simple IP service without CHAP or PAP. The PDSN shall propose CHAP in an initial LCP Configure-Request message that the PDSN sends to the MS during the PPP establishment. If the MS is not configured to use CHAP but to use PAP instead, and the MS proposes PAP in an LCP Configure-NAK, the PDSN shall accept PAP by sending an LCP Configure-Request message with PAP. If the PDSN is configured to allow the MS to receive Simple IP service without CHAP or PAP, the PDSN shall adhere to the guidelines in Section 5.2.2.1. 5.2.1.4 Addressing with IPCP 5.2.1.4.1 IPv4 Addressing For IPv4, the PDSN shall assign the MS an IP address for Simple IP service when presented with a zero or non-zero IP address in the IP Address Configuration option, during the IPCP phase of PPP. If the MS requests a non-zero IP address during the IPCP phase, the PDSN shall send an IPCP Configure-Nak in response to the request in order to propose a different IP address. The MS accepts the new address. The IP address may be a private address as per RFC 1918. The PDSN shall implement IPCP configuration options as defined in RFC 1877 for the DNS server address negotiation. The PDSN shall negotiate Primary and Secondary DNS server IP addresses with the MS if the DNS Server Configuration options are received during the IPCP phase. . If the PDSN supports DNS server IP address VSA, itThe PDSN shall determine if the M bit is set in the DNS Server IP Address VSA received in the RADIUS Access-Accept message. The PDSN shall select DNS Server IP Address VSA, with the M bit set, for DNS information. If PDSN receives a RADIUS Access-Accept message from the Visited RADIUS server that has DNS IP address VSA(s) with the following values included, then the PDSN shall apply local policies to select the DNS IP Address VSA for DNS information. An DNS IP Address VSA with the Entity-Type subfield set to the value 1 (=HAAA) and the M bit unset, and/or One or more DNS IP Address VSA(s) with the Entity-Type subfield set to the value 2 (=VAAA). 5.2.1.4.2 IPv6 Addressing For an IPv6 MS, the PDSN shall be the default router and the PPP termination point. The PDSN shall allocate one globally unique /64 prefix to each PPP link. The PDSN shall not construct any global address from this prefix. The PDSN shall support the following RFCs, with exceptions as noted in this specification: An IPv6 Aggregatable Global Unicast Address Format [RFC 3587];
- 20 -
3GPP2
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43
Internet Protocol, Version 6 (IPv6) Specification [RFC 2460]; Neighbor Discovery for IP Version 6 (IPv6) [RFC 2461]; IPv6 Stateless Address Auto-configuration [RFC 2462]; Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification [RFC 2463]; IP Version 6 over PPP [RFC 2472]; IP Version 6 Addressing Architecture [RFC 3513]. The PDSN shall perform Interface-identifier negotiation as described in RFC 2472. The PDSN shall provide a valid non-zero Interface-Identifier during its negotiation of the Interface-identifier. The PDSN shall not have more than one Interface Identifier associated with the PPP connection, i.e., the PDSN shall only use the Interface Identifier negotiated during the IPv6CP phase with the MS. Because the Interface-Identifier is negotiated in the IPv6CP phase of the PPP connection setup, it is not required to perform duplicate address detection for the link local address forms as part of IPv6 stateless address auto-configuration [RFC 2462]. Following successful IPv6CP negotiation and the establishment of a unique link-local address for both the PDSN and the MS, the PDSN shall immediately3 transmit initial unsolicited Router Advertisement (RA) messages on the PPP link using its link-local address as a source address. The PDSN shall include a globally unique /64 prefix in the Router Advertisement message to the MS. The MS shall use this prefix to configure its global IPv6 addresses. The PDSN shall send unsolicited Router Advertisement (RA) message for an operator configurable number of times. Also, the PDSN shall set the interval between initial RA messages to an operator configurable value, which may be less than MAX_INITIAL_RTR_ADVERT_INTERVAL. After the configurable number of initial unsolicited RA messages has been transmitted, the interval between the periodic transmissions of unsolicited RA messages shall be controlled by the router configurable parameters MaxRtrAdvInterval and MinRtrAdvInterval as defined in RFC 2461. The PDSN may set MaxRtrAdvInterval to a value greater4 than 1800seconds and less than 1/3 of the AdvDefaultLifetime. The PDSN shall set MinRtrAdvInterval4 to a fraction of MaxRtrAdvInterval as per RFC 2461. The PDSN shall send a RA message in response to a Router Solicitation (RS) message received from the MS. The PDSN may set the delay between consecutive (solicited RA) or (solicited /unsolicited RA) messages sent to the all-nodes multicast address to a value less5 than that specified by the constant MIN_DELAY_BETWEEN_RAS, contrary to the specification in sec. 6.2.6 of RFC 2461. The advertised /64 prefix6 identifies the subnet associated with the PPP link. The /64 prefix advertised by the PDSN shall be exclusive to the PPP session. The PDSN shall set the M-flag = 0 and the O-flag = 0 in the RA message header; the L-flag = 0 and the A-flag =1 in the RA message Prefix Information Option. The PDSN shall set the Router Lifetime value in the Router Advertisement message to a value of 216-1 (18.2 hrs). The PDSN shall not send any redirect messages to the MS over the PPP interface.The PDSN shall support: IPv6 over PPP (or IPv6CP) [RFC 2472] 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 This exception is allowed by this specification to optimize IPv6 RA over the cdma2000 wireless 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
3
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51
3GPP2
Neighbor discovery for IPv6 [RFC 2461] IPv6 stateless address auto-configuration [RFC 2462] IPv6 addressing architecture [RFC 2373] An IPv6 aggregatable global unicast address format [RFC 2374] Privacy Extensions for Stateless Address Auto-configuration in IPv6 [RFC 3041] For IPv6 the PDSN shall perform interface-identifier negotiation as described in RFC 2472. The PDSN shall provide a valid non-zero interface-identifier during its negotiation of the interfaceidentifier. Because the interface-identifier is negotiated in the IPv6CP phase of the PPP connection setup, it is not required to perform duplicate address detection [RFC 2462]. The PDSN shall not have more than one interface ID associated with the PPP connection, i.e., the PDSN shall only use the interface ID negotiated during the IPv6CP phase with the MS. Following successful IPv6CP negotiation and establishment of unique link-local address, the PDSN shall initiate Router Advertisement messages using its link-local address as a source, as per RFC 2461. The Router Advertisement messages contain a list of prefixes used by the MS to configure site and/or global IPv6 addresses. These Router Advertisement messages shall be sent an operator configurable number of times. The prefixes identify the subnet(s) associated with a PPP link. All of the prefixes advertised shall be /64 and shall be exclusive to the PPP session. 5.2.1.5 Dual Stack of IPv4 and IPv6 Requirements If the NCP transitions to the stopped state (either because the NCP failed to establish, or because the NCP was torn down gracefully) and the PDSN allows the establishment of that NCP at a later time upon the receipt of NCP configure request, the NCP shall remain in the stopped state. 5.2.1.55.2.1.6 Compression The PDSN shall support the following header compression algorithms: Van Jacobson TCP/IP header compression [RFC 1144]
The PDSN may support the following header compression algorithms: ROHC, Framework and four profiles: RTP, UDP, ESP, and uncompressed [RFC 3095] with ROHC over PPP [RFC 3241] IP Header compression [RFC 2507]
The PDSN shall support CCP [RFC 1962] for the negotiation of PPP payload compression. The PDSN shall support the following types of PPP compression: Stac-LZS [RFC 1974]; Microsoft Point-To-Point Compression Protocol [RFC 2118]; Deflate [RFC 1979]
The PDSN may support other PPP payload compression algorithms. 5.2.1.65.2.1.7 PPP Framing The PDSN shall frame PPP packets sent on the PPP link layer using the octet synchronous framing protocol defined in RFC 1662, except that there shall be no inter-frame time fill (see 4.4.1 of RFC 1662). That is, no flag octets shall be sent between a flag octet that ends one PPP frame and the flag octet that begins the subsequent PPP frame.
- 22 -
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
3GPP2
For IPv6, the PDSN shall allow an information field at least as large as the minimum link MTU size required for IPv6 (1280 octets, or a total PPP frame size minimum MTU of 1286 octets). 5.2.1.75.2.1.8 PPP Link Status Determination If the PDSN supports Always On service, the PDSN shall support the following configurable timer and counter: Echo-Reply-Timeout timer Echo-Request-Retries counter
Upon entering the IPCP Opened state on a PPP session configured for Always On Service, the PDSN shall start the PPP inactivity timer for the PPP session in question. Upon expiration of the PPP inactivity timer, the PDSN shall send an LCP Echo-Request message [RFC 1661] over the main service instance, and start the Echo-Reply-Timeout timer for the PPP session in question. It shall also initialize the Echo-Request-Retries counter to a configurable integer value. Upon receipt of an LCP Echo-Reply message [RFC 1661] for the PPP session in question, the PDSN shall stop the Echo-Reply-Timeout timer, reset the Echo-Request-Retries counter, and restart the PPP inactivity timer. Upon expiration of the Echo-Reply-Timeout timer when the Echo-Request-Retries counter value is greater than zero, the PDSN shall send an LCP Echo-Request message, decrement the EchoRequest-Retries counter by one, and start the Echo-Reply-Timeout timer. Upon expiration of the Echo-Reply-Timeout timer when the Echo-Request-Retries counter value is equal to zero, the PDSN shall release the PPP session. 5.2.2 RADIUS Support The PDSN shall act as a RADIUS client in accordance with RFC 2865 and shall communicate CHAP or PAP authentication information to the Visited RADIUS server in a RADIUS AccessRequest message. Upon receipt of the CHAP or PAP response from the MS, the PDSN shall create an Access-Request message in accordance with Table 1.
- 23 -
3GPP2
P.S0001-Bv2.0
3GPP2
Attribute Name User-Name User-Password CHAP-Password NAS-IP-Address NAS-IPv6-Address CHAP-Challenge Correlation ID Always On NAS-Port-Type10 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
Type 1 2 3 4 95 60 26/44 26/78 61
AccessRequest M O7 O8 O9 O O M O M
AccessAccept
Interface(s) PDSN <-> AAA PDSN -> AAA PDSN -> AAA PDSN -> AAA PDSN -> AAA PDSN -> AAA PDSN <-> AAA PDSN <- AAA PDSN -> AAA
O O
(M) Indicates Mandatory Attribute (O) Indicates Optional Attribute Table 1 - Occurrence of RADIUS Attributes for Simple IP There are additional RADIUS VSAs that may be returned in a RADIUS Access-Accept message as per Annex D. Correlation ID is in addition to those fields specified by RFC 2865 and RFC 3162. The PDSN shall act as a RADIUS accounting client in accordance with RFC 2866 and shall communicate user accounting information to the Visited RADIUS server in RADIUS AccountingRequest records. The RADIUS Accounting-Request message shall contain the accounting attributes as specified in Section 11.3. The security of communications between the PDSN and RADIUS server may optionally be protected with IP security. The establishment of the security association is outside the scope of this specification. When the PDSN sends a RADIUS Access-Request, it may not know a priori whether the MS uses IPv4, IPv6, or both. Address assignment does not occur until after RADIUS authentication and authorization has completed. As per RFC 3162, the IPv6 attributes may be sent along with IPv4-related attributes within the same RADIUS message. The PDSN decides to use IPv4 and/or IPv6 specific attributes that it receives in the Access-Accept message based on whether the MS initiates IPCP and/or IPv6CP. 5.2.2.1 NAI Construction in the Absence of CHAP or PAP In the event that the MS does not negotiate CHAP or PAP, no MS NAI is received by the PDSN. In this case, the PDSN shall not perform additional authentication of the user. If the PDSN is capable of constructing a properly formatted NAI [RFC 2486] based on the MSID then accounting records shall be generated and keyed on the users constructed NAI. The NAI shall be constructed in the form <MSID>@<realm>, where <MSID> is the MSID of the MS, and <realm> is the name (RFC 2486) of the home network that owns the MS MSID. If the PDSN is unable to construct an NAI for an MS, then the PDSN may deny service to the MS. The MS uses one of the following MSID formats: User-Password is mandatory if PAP. 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-IPAddress 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.
8 7
- 24 -
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43
3GPP2
International Mobile Subscriber Identity (IMSI) [E.212] Mobile Identification Number (MIN) [3] International Roaming MIN (IRM) [2]
The PDSN shall store the constructed NAI into accounting records, and the realm value may optionally be used by the Visited RADIUS server to forward these records to the correct Home RADIUS Server for proper summary and settlement11. The constructed NAI shall not be used for authentication. If configured by the operator, the PDSN shall send RADIUS accounting messages to the Visited RADIUS server using the constructed NAI in the absence of CHAP or PAP. 5.2.3 Ingress Address Filtering The Serving PDSN shall check the source IPv4 address of every packet received on the PPP link from the MS. Upon receiving a packet from the MS, the PDSN shall discard the packet and send an LCP Configure-Request message to restart the PPP session, if The MS has been assigned one or more IP addresses by the PDSN and/or HA, but the source IP address of the packet is not one of the addresses that has been assigned to the MS and the packet is not a MIP RRQ or Agent Solicitation. The MS has not been assigned an IP address, and the packet is not a MIP RRQ or Agent Solicitation. Uupon receiving a packet from the MS with invalid12invalid source IP address, the PDSN shall discard the packet and may send an LCP Configure-Request message to restart the PPP session13 if IPCP has reached the open state.. If the PDSN receives an implementation-defined number of consecutive packets with an invalid source IP address from the MS, the PDSN shall send an LCP Configure-Request message to the MS. For Mobile IP and simultaneous Simple IP and Mobile IP sessions see section 6.2.5. For IPv6, the Serving PDSN shall check the prefix of the source IP address of every packet received on the PPP link from the MS. If the prefix is not associated with the PPP Session of the MS, then the PDSN shall discard the packet and send an LCP Configure-Request to restart the PPP session.
5.3 RADIUS Server Requirements

The RADIUS Server shall follow the guidelines specified in RFCs 2865, 2866, and 3162. The Visited and Home RADIUS server shall support the attributes in Table 1, the Interim Accounting Record in Annex E as well as the accounting attributes listed in Section 11.4. The Home RADIUS server may include the Always On attribute in the RADIUS Access-Accept message to indicate an Always On Service for a user, based on the User Profile. If the MS uses CHAP or PAP, the PDSN shall send the Visited RADIUS server a RADIUS Access-Request message with CHAP or PAP authentication information. The Visited RADIUS 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
11
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46
3GPP2
server shall forward the RADIUS Access-Request message to the home network or a peer (e.g., a broker) if it does not have the authority to accept/deny the request. This is in accordance with RFC 2865. Upon receiving a RADIUS Access-Request message, the Home RADIUS server shall send a RADIUS Access-Accept message or Access-Reject message to the Broker or Visited RADIUS server. The Visited RADIUS server shall send the received response to the PDSN. The PDSN shall send RADIUS Accounting-Request records to the Visited RADIUS server in accordance with RFC 2866. The PDSN may also send Interim Accounting records between the Accounting-Request Start and Stop messages as necessary in accordance with Annex E. The Visited RADIUS server shall forward the RADIUS accounting records to the home or broker network. The security of communications between RADIUS servers may optionally be protected with IP security. The establishment of the security association is outside the scope of this specification. See RFC 2865 for additional RADIUS security requirements.
5.4 MS Requirements
The MS may optionally support Simple IP. The MS may choose Simple IP for IPv4 only, IPv6 only, or both IPv4 and IPv6 simultaneously. The MS shall access the cdma2000 packet data service using the cdma2000 air interface [5-9] or HRPD [15]. 5.4.1 PPP Session The MS shall use PPP as the data link protocol for Simple IP. 5.4.1.1 Establishment The MS shall exchange LCP messages as described in RFC 1661. PPP shall support control escaping in accordance with 4.2 of RFC 1662. The PPP Link Layer shall support negotiation of Asynchronous Control Character Mapping as defined in RFC 1662. The MS should negotiate a control character mapping. If the MS negotiates control character mapping, it should attempt the minimum number of escapes by negotiating an ACCM of 0x00000000. 5.4.1.2 Termination When the MS deactivates packet data service, the MS should send an LCP Terminate-Request message to the PDSN to gracefully close the PPP session before releasing the packet data service option connections with the RN. 5.4.1.3 Authentication The MS shall support CHAP authentication for Simple IP. However, the network operator may configure an MS not to use CHAP. In that case, the MS shall be permitted to skip over the CHAP phase by sending a Configure-Reject message to the PDSN in response to a LCP ConfigureRequest message that offers the CHAP option. The MS may support PAP authentication for Simple IP. If the MS uses PAP, it shall respond to an LCP Configure-Request message for CHAP with an LCP Configure-Nak proposing PAP. For both CHAP and PAP, the MS shall send an NAI in the form of user@realm. 5.4.1.4 Addressing with IPCP The MS may support simultaneous operation of IPCP and IPv6CP.
- 26 -
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
3GPP2
The MS may implement RFC 1877 in order to auto configure DNS server IP addresses. The MS may negotiate Primary and Secondary DNS server IP addresses during the IPCP phase. The MS may use default of zero for DNS server address negotiation. 5.4.1.4.1 IPv4 Addressing For IPv4, the MS should send an IP address of 0.0.0.0 during the IPCP phase to request an IP address from the network. The MS shall accept the address provided by the PDSN. If the MS requests a non-zero IP address during the IPCP phase, the PDSN shall send an IPCP ConfigureNak in response to the request in order to propose a different IP address. The MS shall accept the new address. 5.4.1.4.2 IPv6 Addressing For IPv6, the MS shall support the following RFCs, with exceptions as noted in this specification: An IPv6 Aggregatable Global Unicast Address Format [RFC 3587]; Internet Protocol, Version 6 (IPv6) Specification [RFC 2460]; Neighbor Discovery for IP Version 6 (IPv6) [RFC 2461]; IPv6 Stateless Address Auto-configuration [RFC 2462]; Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification [RFC 2463]; IP Version 6 over PPP [RFC 2472]; IP Version 6 Addressing Architecture [RFC 3513]. The MS should support Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [RFC 3041]. To avoid disruption of an active session, e.g., Voice over IP, the MS should not change the IPv6 address used for that session. For IPv6, the MS shall perform interface-identifier negotiation as described in RFC 2472. The MS shall construct the link-local IPv6 address by pre-pending the link-local prefix FE80::/64 [RFC 3513] to the interface identifier negotiated during the IPv6CP negotiation phase [RFC 2472]. When the Interface-Identifier is negotiated in the IPv6CP phase of the PPP session setup, the MS should not perform duplicate address detection for the link local address as part of IPv6 stateless address auto-configuration [RFC 2462]. The MS shall construct global IPv6 addresses by pre-pending the prefix received from the Router Advertisement messages (see the following paragraph) to the interface identifier negotiated during the IPv6CP negotiation phase [RFC 2472] or to the interface identifiers generated using techniques defined in RFC3041. The MS should not perform Duplicate Address Detection for global IPv6 addresses (since the prefix used is a globally unique /64 and exclusive to the PPP session). Following the successful IPv6CP phase and auto-configuration of link-local address, the MS may transmit a Router Solicitation (RS) message(s) if a Router Advertisement message has not been received from the PDSN within a random amount of time between 0 and MAX_RTR_SOLICITATION_DELAY seconds per RFC 2461. The MS may set the upper bound of the delay to a value greater than that specified by the constant MAX_RTR_SOLICITATION_DELAY in RFC 2461. The MS may also set the lower bound of the delay to a value greater than 0. The MS may set the configurable number of RS messages to a value less14 than that specified by the constant MAX_RTR_SOLICITATIONS in RFC 2461. The MS may set the interval between the configurable number of RS messages to a value less14 than or greater than that specified by the constant RTR_SOLICITATION_INTERVAL in RFC 2461. If the last RS message is sent and a RA message is not received after a router solicitation interval, the MS shall send an IPv6CP Configure-Terminate message to the PDSN. Upon reception of a RA message from the PDSN that contains the /64 globally unique prefix, the MS shall perform stateless address auto-configuration for global IPv6 addresses as per RFC 2462 (and RFC 3041 for privacy purposes). This exception is allowed by this specification to optimize IPv6 RA over the cdma2000 wireless links. - 27 3GPP2
14
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
3GPP2
After establishment of a PPP link with the PDSN, the MS shall treat that PDSN as the default router until the PPP session is closed.For IPv6, the MS shall support: IPv6 over PPP (or IPv6CP) [RFC 2472] Neighbor discovery for IPv6 [RFC 2461] The IPv6 addressing architecture [RFC 2373] Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [RFC 3041] IPv6 stateless address auto-configuration [RFC 2462]. For IPv6, the MS shall perform interface-identifier negotiation as described in RFC 2472. When the interface-identifier is negotiated in the IPv6CP phase of the PPP connection setup, the MS should not perform duplicate address detection. The MS may also use additional (multiple) identifiers, including randomly generated identifiers in support of RFC 3041. The MS shall construct the link-local IPv6 address by pre-pending the link-local prefix FE80: /64 [RFC 2373] to the interface identifier received during the IPv6CP negotiation phase [RFC 2472]. The MS shall construct the global and site-local IPv6 addresses by pre-pending the prefixes received from the Router Advertisements to the interface identifier received during the IPv6CP negotiation phase [RFC 2472]. Following the successful IPv6CP phase and establishment of link-local address, the MS may initiate router solicitation messages if a router advertisement has not been received from the PDSN. Upon reception of router advertisements from the PDSN, the MS shall perform address auto-configuration for site-local and global addresses. Global and site-local addresses are 128 bit addresses formed by appending the interface identifier to a prefix of appropriate length [RFC 2373]. 5.4.1.5 Compression The MS shall support Van Jacobson TCP/IP header compression [RFC 1144]. The MS additionally may support the following header compression algorithms: IP Header Compression [RFC 2507] ROHC over PPP [RFC 3241] ROHC Framework and four profiles: RTP, UDP, ESP, and uncompressed [RFC 3095]
The MS shall use IPCP and/or IPv6CP to negotiate with the PDSN one or more header compression capabilities. The MS shall support the PPP Compression Control Protocol [RFC 1962]. The MS may support PPP payload compression. If the MS intends to use PPP payload compression, the MS shall use PPP Compression Control Protocol to negotiate a PPP payload compression algorithm supported by the MS.The MS shall support the PPP Compression Control Protocol [RFC 1962]. If the MS uses PPP payload compression, the MS shall use PPP Compression Control Protocol to negotiate a PPP payload compression algorithm, and the MS shall support one of the following compression algorithms: Stac-LZS [RFC 1974] Microsoft Point-To-Point Compression Protocol [RFC 2118] Deflate [RFC 1979] The MS may support additional PPP payload compression algorithms.
- 28 -
3GPP2
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8
5.4.1.6 PPP Framing The MS shall use the octet-synchronous framing protocol defined in RFC 1662. One exception is there shall be no inter-frame time fill (i.e., no flag octets shall be sent between a flag octet that ends one PPP frame and the flag octet that begins the subsequent PPP frame).15 5.4.1.7 PPP Link Status Determination To support Always On service, the MS shall adhere to RFC 1661 section 5.8 Echo-Request and Echo-Reply with regards to LCP Echo-Request message processing.
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
15
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
6 Mobile IPv4 Operation

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

The common requirements for several network elements (e.g., PDSN and MS) for Mobile IP operation are described here. 6.1.1 PPP Session See Section 5.1.1. For Mobile IP, neither CHAP nor PAP should be performed. If CHAP or PAP is performed, longer initial setup time and re-establishment time will occur as the result of an additional AAA traversal. Note that the MN-FA Challenge Extension procedures [RFC 3012] are performed regardless of whether or not CHAP/PAP is performed. 6.1.2 Mobile IP The following standards shall be used for Mobile IPv4 operations with any limitations or extensions described in this specification: RFC 2002-2006; Reverse Tunneling [RFC 3024]; Foreign Agent Challenge/Response [RFC 3012]; NAI Extension [RFC 2794].
6.1.3 Dynamic Home Agent and Home Address Assignment In this specification, an MS may request dynamic HA and/or Home Address assignment during the initial MIP registration according to the following scenarios of Table 2 and Table 3 (and also see section 6.5.2.2). If the network receives an RRQ from the MS with an HA IP address value of 0.0.0.0, the network shall treat the value as 255.255.255.255 (see section 6.5.2.2). Scenarios Scenario 1 Scenario 2 Scenario 3 Scenario 4 Type of Request Dynamic case Semi-static case Semi-static case Static case Home Address 0.0.0.0 x.x.x.x 0.0.0.0 x.x.x.x Home Agent Address 255.255.255.255 or 0.0.0.0 255.255.255.255 or 0.0.0.0 y.y.y.y y.y.y.y
34 35 36 37
Table 2 Home Agent and Home Address Scenarios
- 30 -
3GPP2
P.S0001-Bv2.0
3GPP2
Scenarios Scenario 1 Scenario 2 Scenario 3 Scenario 4 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
Description This is for dynamic Home Address assignment and a dynamic HA assignment. 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. This corresponds to dynamic Home Address assignment and static HA assignment. This is for static HA and static Home Address MIP registration, i.e., there is no dynamic assignment. Table 3 Description of Scenarios
For details on dynamic HA assignment see the following: Section 6.2.2.4 for the PDSN Section 6.3.4 for the HA Section 6.4.1 for the Home RADIUS server Section 6.5.2.2 for the MS.
6.2 PDSN Requirements

The PDSN shall support Mobile IPv4 operation. 6.2.1 PPP Session The PDSN shall support multiple Mobile IP Home Addresses over a single PPP session. 6.2.1.1 Establishment See Section 5.2.1.1. 6.2.1.2 Termination The Serving PDSN shall close the PPP session if there is no established underlying R-P session or P-P session for the MS, respectively. The PDSN shall clear the R-P session and P-P session, whenever the PPP session is closed. If the PDSN receives IP packets for an MS for which there is no established PPP session for the MS, the PDSN shall silently discard the packet. If the PDSN receives a failure code in the RRP from the HA, then the PDSN shall deliver the RRP to the MS, and shall not close the PPP session before a configurable timer expires. If the PDSN generates a failure code, the PDSN shall deliver the RRP to the MS and shall not close the PPP session before a configurable timer expires. For Mobile IP service, the PPP inactivity timer shall be set to a value larger than the FAs maximum allowable values for Mobile IP registration lifetime. Satisfying this requirement may imply over-riding the PDSN's configured PPP Idle Timeout value (attribute 28 in RFC 2865) for this MS with the value received in the RADIUS Access-Accept message. 6.2.1.3 Authentication The PDSN shall initially propose CHAP in an LCP Configure-Request message to the MS. The PDSN shall re-send an LCP Configure-Request message without the authentication option after receiving the LCP Configure-Reject (CHAP or PAP) from the MS. 6.2.1.4 Addressing with IPCP When only Mobile IP service is requested by the MS prior to the initial MIP registration, the MS shall not include an IP-Address Configuration Option in the IPCP Configure-Request message to
- 31 -
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
3GPP2
the PDSN. If the MS includes an IP-Address Configuration Option in the IPCP ConfigureRequest to the PDSN, the PDSN considers this as an MS using Simple IP service. In this case, the PDSN shall send an IPCP Configure-NAK with a new proposed IP address for the MS. The MS should then send an IPCP Configure-Request with the new IP address. The PDSN shall not support RFC 2290. If the MS uses the Mobile IPv4 Configuration Option [RFC 2290], the PDSN shall reply with an IPCP Configure-Reject message. The PDSN shall implement the IPCP configuration options as defined in RFC 1877 for DNS server address negotiation. The PDSN shall negotiate Primary and Secondary DNS server IP addresses with the MS, if DNS Server Configuration options are received during the IPCP phase. 6.2.1.5 Compression See Section 5.2.1.6. 6.2.1.6 PPP Framing See Section 5.2.1.7. 6.2.2 MIP Registration
6.2.2.1 Agent Advertisements For the MS that uses Mobile IP, the PDSN shall begin transmission of an operator configurable number of Agent Advertisements immediately following establishment of PPP, or upon receipt of an Agent Solicitation message from the MS. If the MS sends an RRQ to the PDSN, the PDSN shall cease sending Agent Advertisements. Once the PDSN sends the configurable number of Advertisements, the PDSN shall not send further Advertisements, unless it receives an Agent Solicitation message from the MS. For Simple IP service, the PDSN shall not send any Agent Advertisements to the MS following establishment of PPP unless the MS sends Agent Solicitation to the PDSN. If the PDSN receives Agent Solicitation from a Simple IP user, the PDSN shall respond with an Agent Advertisement with the 'R' bit set. If the PDSN receives an RRQ with the 'D' bit set, the PDSN shall send an RRP with code 6577. In this case, the PDSN shall not close the PPP session. The Mobile IP Registration Lifetime field in the Agent Advertisement shall be smaller than the PPP inactivity timer. Upon receiving a handoff indication including SID/NID/PZID of the previous PCF and SID/NID/PZID of the current PCF, if the PDSN already supports a Mobile IP service for the MS, the PDSN shall use this information to determine whether or not Mobile IP re-registration is required for the MS. If re-registration is required, then the PDSN shall re-negotiate PPP and send Agent Advertisements. In order to minimize Agent Advertisements sent over the air, the PDSN shall not send unsolicited Agent Advertisements to an MS periodically to refresh the FA advertisement lifetime. The MS may send Agent Solicitations, when the FA advertisement lifetime expires. The Advertisement Lifetime is a configurable value, and shall be set to 9000 seconds (the maximum ICMP router advertisement lifetime). 6.2.2.2 Addressing and Mobile IP The PDSN shall support RFC 2794, and therefore, support zero and non-zero Home Address values in the MIP RRQ. For dynamic Home Address assignment, the PDSN shall accept Mobile IP RRQs with a 0.0.0.0 source address from the MS, and shall use the NAI instead of the Home Address in its pending registration request records, along with the Identification field [RFC 2794].
- 32 -
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
3GPP2
For dynamic Home Address assignment, the PDSN shall acquire the Home Address from the Mobile IP RRP. In order to provide public network access and to provide private network access across the Internet, the PDSN shall use a publicly routable and visible IP address. 6.2.2.3 MIP Extensions The PDSN shall include the MN-FA Challenge Extension [RFC 3012] in the Agent Advertisement. Because Advertisements are rarely sent (to save air resources), the PDSN shall include in the RRP a new challenge that the MS should use in its next re-registration with this PDSN. On reregistration, the PDSN may communicate user FAC authentication information to the Home RADIUS Server, via broker servers, if required, in a RADIUS Access-Request message. The frequency of this re-authentication and re-authorization is configurable by the operator. The challenge shall be changed on a serving access provider configurable basis. If the RADIUS attribute MN-AAA Removal Indication is included in the RADIUS Access-Accept message, and if the RRQ contains an MN-HA Authentication Extension followed by the MN-FA challenge and MN-AAA Authentication Extension, the PDSN shall remove the MN-FA challenge and the MN-AAA Authentication Extensions when relaying the RRQ to the HA. Otherwise, the PDSN shall relay the RRQ to the HA as received by the MS. 6.2.2.4 Dynamic Home Agent Assignment The PDSN shall include the Home Address that it receives in the RRQ message from the MS in the Access-Request message in RADIUS attribute 8 (Framed-IP-Address). The PDSN shall include the HA Address that it receives in the RRQ message from the MS in the RADIUS AccessRequest message in the HA attribute (see Annex C). Upon receiving the RADIUS AccessAccept message from the Home RADIUS server containing the assigned HA IP address in the HA attribute, the PDSN shall relay the RRQ message to that HA IP address. Upon receiving an RRP message with successful registration indication (code 0) for the MS, the PDSN shall update the mobility binding for the MS using the HA address, the NAI, and the Home Address if non-zero in the RRQ. 6.2.2.5 Private Network Support It is possible that two different MSs served by a PDSN have the same, overlapping private address because they belong to two different private networks. To support this scenario, the PDSN forms a logical association that contains the R-P Connection ID, the MSs Home Address, and the HA address. When the PDSN receives a packet for a registered MS from the HA, the PDSN maps the MSs HA address and the Home Address to one association, and transmits the packet on the R-P connection indicated by the R-P Connection ID of the association. When processing additional MIP registrations for the same MS, if the PDSN receives an RRP from a second HA that includes a private address as the Home Address, and if the private address has already been assigned to the MS by another HA, the PDSN shall set the Code field to 65 before forwarding the RRP to the MS. The first assigned address is not affected. 6.2.2.6 Reverse Tunneling The PDSN shall reject a Mobile IP registration with an error code of 75, if a private Home Address as defined in RFC 1918 is present in either the RRQ or RRP, and the RRQ did not indicate reverse tunneling. If the Home RADIUS Server sends a Reverse Tunnel Specification attribute in the RADIUS Access-Accept message indicating that reverse tunneling is required, and the MS did not indicate reverse tunneling in the RRQ, the PDSN shall reject the registration with an error code of 75. If the MS negotiates reverse tunneling, then the PDSN shall reverse tunnel both direct delivered and encapsulated packets. This applies to unicast, multicast, and broadcast IP destination
- 33 -
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52
3GPP2
addresses, even if the direct delivery mode is used. See Reverse Tunneling [RFC 3024] for an explanation of direct and encapsulated delivery styles. The PDSN shall support both direct delivered and encapsulated packets. 6.2.2.7 DNS Address Assignment If the PDSN supports the DNS Server IP Address VSA and NVSE and it receives a DNS Server IP Address VSA in the RADIUS Access-Accept message from the RADIUS server or/and a DNS Server IP Address NVSE in the MIP Registration Reply from the HA, then the PDSN may include each received DNS Server IP Address in a DNS Server IP Address NVSE in the MIP Registration Reply to the MS. The format of the DNS Server IP Address VSA is defined in Annex C, and the format of the DNS Server IP Address NVSE is defined in section 6.6. If the PDSN receives a DNS Server IP Address from both the Visited RADIUS and Home RADIUS servers (entity type 1 and 2), and the PDSN supports the VSA, the PDSN shall determine if the M bit is set in the DNS Server IP Address VSA received in the RADIUS AccessAccept message to select the DNS Server IP Address VSA it forwards to the MS. The DNS Server IP Address VSA with the M bit set, shall have precedence over the VSA that does not have the M bit set. If the PDSN receives a RADIUSn Access-Accept message from the Visited RADIUS server that has DNS IP address VSA(s) with the following values included, then the PDSN shall apply local policies to select the DNS IP Address VSA for DNS information. An DNS IP Address VSA with the Entity-Type subfield set to the value 1 (=HAAA) and the M bit unset, and/or One or more DNS IP Address VSA(s) with the Entity-Type subfield set to the value 2 (=VAAA). 6.2.3 RADIUS Support The PDSN shall act as a RADIUS client in accordance with RFC 2865. On initial mobile access, the PDSN shall communicate user FAC authentication information to the Home RADIUS Server, via the broker RADIUS servers if required, in a RADIUS Access-Request message. On receipt of the RRQ from the MS, and if SPI in the MN-AAA Authentication Extension is set to CHAP-SPI, the PDSN shall create a RADIUS Access-Request message in accordance with Table 4 If the SPI in the MN-AAA Authentication Extension is set to CHAP SPI as per RFC 3012, the PDSN shall use MD5 when computing the CHAP challenge. If the authentication succeeds, the Home RADIUS server shall send a RADIUS Access-Accept message to the PDSN. If the authentication fails, the Home RADIUS server shall send a RADIUS Access-Reject message to the PDSN. The inclusion of the NAS-IP-Address or the NAS-IPv6-Address, or both in the RADIUS AccessRequest message, depends on whether the PDSN has an IPv4 address or IPv6 address, or both. The PDSN shall act as a RADIUS accounting client in accordance with RFC 2866 and shall communicate user accounting information to the Visited RADIUS server in RADIUS AccountingRequests. The PDSN shall determine at completion of the IPCP phase that an AccountingRequest (Start) record shall be sent to the RADIUS server following a successful Mobile IP Registration Reply received from the HA. The Accounting-Request (Start) record shall contain the Account Session ID and Correlation ID attribute generated by the PDSN. The security of communications between PDSN and RADIUS server may optionally be protected with IP security. The establishment of security is outside the scope of this specification. 6.2.4 IP Security Support There may be a statically configured shared key for computing the Mobile IP HA-FA Authentication Extension in Mobile IP registration messages. If such a shared key exists, the PDSN and HA shall use it. Additional Security Associations (SAs) between the PDSN and HA
- 34 -
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52
3GPP2
may also be supported for the protection of Mobile IP control messages and user data. This specification supports the following options for the establishment of such additional SAs: Public certificates16 Dynamic pre-shared IKE secret distributed by the Home RADIUS Server Statically configured IKE pre-shared secret.
The PDSN shall support IPSec and IKE. An SA between the PDSN and the HA may be established using X.509 based certificates, or a pre-shared secret for IKE that may be statically configured or dynamically provisioned by the Home RADIUS server. ESP is preferred and shall be implemented. AH shall also be implemented in order to maintain backwards compatibility with previous versions of this specification. In the case of a carrier owned HA, and if mandated by carrier policy, the PDSN shall have a SA with the HA in order for a RRQ to be successfully processed. The SA may formally be via IPSec (i.e., ESP or AH) or via a Mobile IP HA-FA Authentication Extension. An SA between the PDSN and the HA shall be established as follows: When receiving a MIP RRQ containing a unicast HA IP address, the PDSN shall verify if a SA currently exists with the HA. If an SA does not exist and one is required, the PDSN shall verify if HA X.509 certificates exists. If no HA X.509 certificate exists, the PDSN shall verify if a root certificate exists. If the necessary certificates do not exist, the PDSN shall verify if a statically configured pre-shared secret for IKE exists. If the static pre-shared secret for IKE is also not available, it shall include a request for a pre-shared secret for IKE in the RADIUS AccessRequest message. The Home RADIUS server shall include the pre-shared secret for IKE and a KeyID in the RADIUS Access-Accept message if IPSec services are authorized for the user. When dynamic HA assignment is used by the MS (scenario 1 and 2 from Section 6.1.3), the PDSN shall always request the IKE pre-shared Secret from the Home RADIUS server. IPSec support for dynamic HA assignment is further described in Section 6.2.4.2. 6.2.4.1 IPSec Service Authorized If the home network authorizes IPSec services, the PDSN shall not forward an RRQ to the HA unless an IPSec SA exists first. The PDSN shall send a failed RRP with an error code of 65 to the MS if it is unable to establish an IPSec SA to the HA and IPSec security is authorized by the Home RADIUS Server. The Home RADIUS Server authorizes the PDSN to either use an existing SA with the corresponding HA or to establish a new SA if no prior SA exists. The PDSN shall apply the same security service for all the MSs served by the same HA. If an IPSec SA does not exist and IPSec is authorized, the PDSN shall establish a SA using IKE with either X.509 or root certificates, or statically configured pre-shared secret for IKE, or dynamically distributed pre-shared secret for IKE. The PDSN shall comply with the specifications in IKE [RFC 2409] and the Annexes A and B in this specification. The PDSN shall provide IPSec services as indicated by the Security Level attribute included in the RADIUS Access-Accept message. The Security Level attribute included in the RADIUS Access-Accept message allows the Home RADIUS server to indicate whether IP security should be applied to MIP registration messages and MIP tunneled data between the HA and the PDSN, or not to use IPSec at all. The same security level shall be applied for all users using the same Home Agent. If the PDSN receives the deprecated value of '1' or '2', the PDSN shall use a default value of '3'.
16
Refer to Annex A and B for details. - 35 3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
3GPP2
If reverse tunneling is required and IPSec security is authorized for tunneled data, then the PDSN shall provide security on the reverse tunnel. If the PDSN does not receive the Security Level attribute from the Home RADIUS server, and an IPSec SA to the HA already exists, the PDSN shall continue to use the same SA. If it receives a new pre-shared key and an SA already exists, the PDSN shall not renegotiate the ISAKMP SA. If no SA exists, then the PDSN shall follow local security policy. If an IPSec SA to protect control messages already exists with the HA, the PDSN shall ensure the IPSec SA is maintained throughout the Mobile IP registration lifetime by periodically refreshing the SA. 6.2.4.2 IPSec Service Not Authorized If the Home RADIUS server does not authorize security for the MS, the PDSN shall not delete existing IPSec SA with an HA. This is because IPSec should be authorized per PDSN-HA pair and thus other MSs may be using the same IPSec SA. 6.2.4.3 Dynamic HA Assignment When the PDSN receives a MIP RRQ containing a HA IP address of 255.255.255.255 (or 0.0.0.0), it shall always include the IKE Pre-shared Secret Request attribute in the RADIUS Access-Request sent to the Home RADIUS server. The Home RADIUS server responds with a RADIUS Access-Accept containing the allocated HA address and if IPSec services are authorized for the user, the corresponding dynamic pre-shared secret and KeyID for IKE should also be included. The PDSN shall verify if IPSec services are authorized by the presence of the Security Level attribute. When IPSec service is authorized for the user, the PDSN shall then determine from the received HA address whether an IPSec SA already exists. If an SA does not exist, the PDSN shall determine if certificates or static pre-shared secret for IKE exist for the HA, otherwise the pre-shared secret for IKE, if provided by the Home RADIUS server, shall be used to establish the required SA. If an SA already exists with the HA, the PDSN shall use the existing SA as is. 6.2.5 Ingress Address Filtering Upon receiving a packet from the MS, the PDSN shall discard the packet if one of the following conditions holds: the packet is received while the PPP negotiation is in progress (state is not open), the packet is received while MIP registration is pending17, but the source IP address of the packet is invalid18, and the packet is not a MIP control packet (MIP RRQ or Agent Solicitation). For a Mobile IP session establishment over a Simple IP session, at the Simple IP establishment, 1. if the MS sends an Agent Solicitation to the PDSN, the PDSN shall respond with an Agent advertisement and shall discard all IP packets with an invalid source IP address while MIP registration is pending17. 2. If the MS doesnt send Agent Solicitations but sends IP packets with an invalid Source IP address, the PDSN may discard the packets and may send an Agent Advertisement to the MS. If the PDSN sends Agent Advertisements to the MS as a result of an Invalid Source IP address, it shall discard all IP packets with an invalid source IP address while MIP registration is pending17. If the PDSN receives an implementation-defined number of consecutive packets with an invalid source IP address from the MS, the PDSN shall send an LCP Configure-Request message to the MS.If the MS fails to register with the PDSN and continues to send IP packets with invalid source i.e., between the NCP open state and completion of MIP registration. 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.
18 17
- 36 -
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
3GPP2
IP address, the PDSN shall discard the packets and shall send an LCP Configure-Request message to the MS to renegotiate the PPP session.See section 5.2.3 as it relates to IPv4.
6.3 Home Agent Requirements

The HA shall support basic MIP [RFC 2002-2006], reverse tunneling [RFC 3024], FAC [RFC 3012], and Mobile IP NAI Extension [RFC 2794]. In order to provide public network access and private network access across the public network, the HA shall use a globally routable and visible IP address. 6.3.1 Multiple Registrations The HA shall support multiple registrations with the same NAI but different static Home Addresses.: Multiple registrations for the same NAI as long as each registration requests a different non-zero address. Multiple registrations for different NAIs. 6.3.2 MIP Authentication Support When the HA receives an RRQ from a PDSN, it authenticates the RRQ using the MN-HA shared key. At initial registration, the HA may not have the MN-HA shared key, the HA shall retrieve the MN-HA shared key from the Home RADIUS server. Based on the policy of the home network, the HA may also process the MN-AAA Authentication Extension as specified in RFC 3012, if included in the RRQ. If the HA policy dictates that the HA shall process the MN-AAA Authentication Extension, then the HA shall authenticate the request by including the following attributes in a RADIUS AccessRequest message to the Home RADIUS server: User-Name (1) = MN-NAI field in the MN-NAI Extension CHAP-Password (3) = CHAP Ident field = High-order byte of the Challenge Field in the MN-FA Challenge Extension String field = Authenticator field from the MN-AAA Authentication Extension CHAP-Challenge (60) = MD5 (Preceding MIP RRQ, Type, Subtype, Length, SPI), followed by the least-order 237 bytes of the Challenge Field in the MN-FA Challenge Extension. The MD5 checksum is computed over the MIP RRQ data preceding the MNAAA Authentication Extension and the Type, Subtype, Length, SPI fields of the MN-AAA Authentication Extension. MN-HA SPI = to request the MN-HA shared key if not available at the HA. The MN-HA shared key corresponds to a single users NAI or NAI and non-zero static IP address pair.
If the MN-AAA Authentication Extension is not present in the RRQ or HA policy dictates that the HA shall not process the MN-AAA Authentication Extension, and the HA requires the MN-HA shared key from the RADIUS server, the HA shall send a RADIUS Access-Request19 that includes a User Name, a User-Password and an MN-HA SPI. The Home RADIUS server shall process the Access-Request. If the MN-HA shared key is requested, the Home RADIUS server shall encrypt the MN-HA shared key in a RADIUS AccessAccept using a method based on the RSA Message Digest Algorithm MD5 [RFC 1321] as described in Section 3.5 of RFC 2868.
19
Construction of the message is implementation dependent. - 37 3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
3GPP2
The HA shall save the MN-HA shared key received from the Home RADIUS server for the duration of the MIP session with the MS. Based on the local policy, the HA may store the MN-HA shared key a certain time skew after releasing the mobility binding for the MS. 6.3.3 IPSec Support The HA shall determine which type of security associations (if any) are required with a PDSN. The HA shall use the same security policy as specified in the Home RADIUS server and returned to the PDSN in the Security Level attribute. The policy may be locally configured at the HA or may be obtained from the Home RADIUS server in the security level attribute. If IPSec is authorized and no SA is currently in place, the HA shall participate in ISAKMP and IKE negotiation with the PDSN. The negotiation will result in establishing an IPSec SA that will be used for all traffic between the HA and the PDSN. Security associations may be authorized for MIP control and/or payload tunnels. Also, IKE negotiation results in all MSs on a given PDSN belonging to the same HA receiving the same security between the PDSN and HA for either registration messages and/or tunneled data. The HA shall perform a similar operation as the Home RADIUS server to generate the pre-shared secret for IKE (K), see algorithm for K in Section 6.4.3. When an IKE request is received, the HA shall validate the timestamp in the KeyID field. This timestamp eliminates the possibility of re-using a previously generated shared-key for IKE K value while the secret key S is still valid on the HA. The HA shall also use the 'S' Key indexed by Home RADIUS server IP address from the KeyID field. If there is no previously assigned 'S' Key, the S key is not found, or the timestamp in the KeyID is greater than the S expiration time, then the HA shall send a RADIUS Access-Request message to the Home RADIUS server to request the S key. That RADIUS Access-Request message shall contain The user name attribute consisting of a concatenation of the PDSNs CoA and HA address The S Request attribute
The RADIUS Access-Accept message from the Home RADIUS server shall include the 'S' Key and its lifetime, and may include the Security Level attribute. The HA shall save the 'S' Key received from the Home RADIUS servers. The HA shall compute the pre-shared secret K using KeyID (Annex C) and the 'S' Key (see Section 6.4.3). Each HA shall have a configurable, allowable time skew to be used to validate the freshness of K. The HA shall maintain expired S keys for a configurable amount of time. This expired key shall be used when KeyIDs are received that refer to the expired 'S' Key but falls within the allowable time skew20. The security method used between the HA and the Home RADIUS server is outside the scope of this specification. 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
20
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38
3GPP2
However, the Home RADIUS server may encrypt the 'S' Key and the 'S' Lifetime using a method based on the RSA Message Digest Algorithm MD5 [RFC 1321] as described in Section 3.5 of RFC 2868. If mandated by carrier security policy, a carrier HA shall have a SA with the PDSN in order for a registration request to be successfully processed. The SA may formally be via IPSec (e.g., ESP or AH) or via a Mobile IP HA-FA Authentication Extension. Likewise, a HA shall accept or reject a RRQ received directly from an MS with a 'D' bit set depending on security policy. 6.3.4 Dynamic Home Agent Assignment During dynamic HA assignment, the HA IP address that is specified by the MS in the RRQ message and the IP address of the dynamically assigned HA may not be the same. Upon receipt of such a RRQ message in an IP packet with the destination IP address set to the HA unicast IP address, the HA may accept the RRQ contrary to the specification in RFC 2002 or may reject it with an error code of 136 in accordance with RFC 2002. The HA shall follow the procedures described in Section 6.3.2 to complete its authentication process for the RRQ message. The HA shall put its IP address in the HA IP address field of the RRP message to the MS. 6.3.5 DNS Address Assignment The DNS server IP addresses may be configured at the HA, or received from the Home RADIUS server in a RADIUS Access-Accept message. If the HA does not receive the DNS Server IP Address VSA from the Home RADIUS server, then the HA may include configured21 DNS server IP addresses in the DNS Server IP Address NVSE. If the HA includes the configured DNS server IP addresses in the DNS Server IP Address NVSE, it shall set the Entity-Type field to 3 (see section 6.6), and send the NVSE in a MIP Registration Reply message. If the HA receives the DNS Server IP Address VSA from the Home RADIUS server, the HA may include the received DNS server IP addresses in the DNS Server IP Address NVSE. If the HA includes the received DNS server IP addresses in the DNS Server IP Address NVSE it shall set the Entity-Type field to 1 (see section 6.6) and send the NVSE in a MIP Registration Reply message
6.4 RADIUS Server Requirements

See Section 5.3. In order to provide the functions defined in this specification, the Home and Visited RADIUS servers shall support the attributes listed in Table 4, in addition to the standard RADIUS attributes. The Broker RADIUS server shall support the decryption and re-encryption of the Preshared Secret attribute and the MN-HA Shared Key attribute.
21
The DNS information may be pre-configured in the HA or the HA may acquire the DNS information via other schemes. - 39 3GPP2
P.S0001-Bv2.0
3GPP2
Attribute Name User-Name User Password CHAP-Password CHAP-Challenge NAS-IP-Address NAS-IPv6-Address Foreign Agent Address Correlation ID Home Agent Framed-IP-Address IKE Pre-shared Secret Request Security Level Pre-shared Secret Reverse Tunnel Specification KeyID S Key S Lifetime S Request MN-HA Shared Key MN-HA SPI Allowed Differentiated Services Marking DNS Update Required Always On Service Option Profile Remote IPv4 Address Remote IPv6 Address Remote Address Table Index MN-AAA Removal Indication NAS-Port-Type24 1 2 3 4 5 6 7 8 9 10 11
Type 1 2 3 60 4 95 23 26/79 26 / 44 26 / 7 8 26 / 1 26 / 2 26 / 3 26 / 4 26 / 8 26 / 54 26 / 56 26 / 55 26 / 58 26 / 57 26 / 73 26 / 75 26 / 78 26 / 74 26 / 59 26 / 70 26 / 71 26 / 81 61
AccessRequest M O Note 1 M Note 2 OM Note 2 O22 Note 3 O Note 4 O M M M O
AccessAccept M
Interface(s) PDSN -> AAA HA -> AAA HA -> AAA PDSN -> AAA HA -> AAA PDSN -> AAA HA ->AAA PDSN -> AAA PDSN -> AAA PDSN -> AAA PDSN <-> AAA PDSN <-> AAA PDSN <-> AAA PDSN -> AAA AAA -> PDSN, AAA -> HA AAA -> PDSN AAA -> PDSN AAA -> PDSN AAA -> HA AAA -> HA HA -> AAA AAA -> HA HA -> AAA AAA -> PDSN AAA -> HA AAA -> PDSN AAA -> PDSN AAA -> PDSN AAA -> PDSN AAA -> PDSN AAA->PDSN PDSN -> AAA
O M O O O O O O O
O O O O O O O O O O O O Note 5
(M) Indicates Mandatory attribute (O) Indicates optional attribute Note 1: The password is configured between the HA and the AAA. Note 2: For Mobile IP, this attribute is mandatory for the PDSN, and optional for the HA. Note 3:This is the IPv4 address of the RADIUS server interface of the PDSN; at least one of NAS-IP-Address or NAS-IPv6-Address shall be included. Note 4: This attribute is included if the PDSN supports IPv6 addressing. Note 5: The values are as follows: 22 (IS-2000) [5-9] or 24 (HRPD) [15], depending on the service option number connected to the PDSN. 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
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
3GPP2
6.4.1 Dynamic Home Agent Assignment The RADIUS based HAAA shall implement a HA selection algorithm to perform dynamic HA assignment. The implementation details of this algorithm are outside the scope of this specification. The HA selection algorithm shall satisfy the four scenarios described in Section 6.1.3. The HAAA shall return the assigned HA IP address in the HA attribute in the RADIUS Access-Accept message to the PDSN. 6.4.2 MN-HA Shared Key Distribution Upon receipt of a RADIUS Access-Request message from a HA containing the MN-HA SPI attribute, the RADIUS server shall send a RADIUS Access-Accept message containing the MNHA shared key encrypted using a method based on RSA MD5 [RFC 1321] as described in Section 3.5 of RFC 2868. 6.4.3 Dynamic Key Distribution Procedure When the RADIUS Access-Request is received from the PDSN containing the IKE Pre-shared Secret Request attribute, and IPSec services are authorized for the user, the Home RADIUS server shall distribute a key identifier and pre-shared secret for IKE to the PDSN using the Preshared Secret and KeyID attributes in the RADIUS Access-Accept message. The Home RADIUS server generates a pre-shared secret for IKE by processing the Home RADIUS IP address, FA IP address, and a timestamp as well as a secret key, known as the 'S' Key, through the HMAC-MD5 hashing algorithm. The 'S' Key is known between the Home RADIUS server and the HA. The 'S' Key is retrieved by the HA from the Home RADIUS server and has a configurable lifetime. The lifetime of the 'S' Key is a Home RADIUS local policy, and is based on the cryptographic strength of the S Key. The pre-shared secret is generated using the following formula: K = HMAC-MD5 (Home RADIUS IP address | FA IP address | timestamp, S) The Home RADIUS server hides pre-shared secrets for IKE using a method based on the RSA Message Digest Algorithm MD5 [RFC 1321] as described in Section 3.5 of RFC 2868. 6.4.4 DNS Address Assignment The RADIUS server may include the DNS Server IP Address VSA in the RADIUS Access-Accept message in response to a RADIUS Access-Request message from the PDSN and/or the HA. If the RADIUS server includes the DNS Server IP Address VSA, it shall include a Primary and a Secondary DNS server IP addresses. The status of the M bit in the DNS Server IP Address VSA is controlled by the Home RADIUS server.
6.5 Mobile Station Requirements

The MS may support Mobile IPv4 service. The MS shall access cdma2000 packet data service using the cdma2000 air interface [5-9] or HRPD [15]. 6.5.1 PPP Session The MS shall use PPP as the data link protocol for Mobile IP. The MS may support multiple Mobile IP Home Addresses over a single PPP session. 6.5.1.1 Establishment Same as Section 5.4.1.1. 6.5.1.2 Termination Same as Section 5.4.1.2.
- 41 -
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44
3GPP2
When the MS tries to register and receives an RRP message with a failure code, it shall do one of the following: Retry Mobile IP registration over the existing PPP session. If existing Simple IP or Mobile IP sessions exist, give up on the failed Mobile IP registration and continue using the existing sessions. Fall back to Simple IP by re-negotiating the PPP session. Terminate the PPP session.
6.5.1.3 Authentication The MS should not use CHAP or PAP for Mobile IP. When the MS receives an LCP ConfigureRequest message requesting CHAP authentication, the MS should reply with an LCP ConfigureReject message requesting no PPP authentication. The PDSN shall re-send an LCP ConfigureRequest message without the authentication option after receiving the LCP Configure-Reject message from the MS. The MS shall respond with an LCP Configure-Ack message as described in RFC 1661. If CHAP is performed, performance degradation will occur as the result of an unnecessary AAA traversal. FAC shall be performed regardless of whether or not CHAP is performed. The MS shall use the challenge received in the Agent Advertisement or RRP to compute the MN-AAA authenticator. As a further clarification to RFC 3012 section 8 (SPI For RADIUS AAA Servers): If the challenge has fewer than 238 bytes, this algorithm includes the high-order byte in the computation twice, but ensures that the challenge is used exactly as is. Additional padding is never used to increase the length of the challenge; the input data is allowed to be shorter than 237 bytes long. 6.5.1.4 Addressing with IPCP If the MS uses Mobile IP only, the MS shall not use the IP-Address Configuration Option [RFC 1332]. On subsequent PPP session establishments while the MS intends to maintain a home IP address, the MS shall omit the option25. Since the PDSN does not support RFC 2290, if the MS uses the Mobile IPv4 Configuration Option, the PDSN replies with an IPCP Configure-Reject message. The MS may implement RFC 1877 in order to auto configure DNS server IP addresses. The MS may negotiate Primary and Secondary DNS server IP addresses during the IPCP phase. The MS may propose a DNS server address of zero to indicate an explicit request that the PDSN provide the DNS server address information in a Configure-Nak. 6.5.1.5 Compression Same as Section 5.4.1.5. 6.5.1.6 PPP Framing Same as Section 5.4.1.6.
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
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
6.5.2
MIP Registration
6.5.2.1 Agent Discovery Immediately after a PPP session is established, the MS may send Agent Solicitations. In this case, the MS should use the same procedure as described in Section 2.4 of RFC 2002. If the MS does not have a Home Address, the MS shall use zero in the Source IP Address field of the IP packet that contains the Agent Solicitation. The MS shall support RFC 3012. 6.5.2.2 Registration Messages Upon receiving Agent Advertisements from the PDSN, the MS shall send an RRQ message. The MS may request a non-zero home IP address belonging to its home IP network in the RRQ or indicate that the HA should dynamically assign it an IP address. If the MS requests a dynamic HA assignment, the MS shall set the HA IP address to either 255.255.255.255 or 0.0.0.0. However, the MS should use 255.255.255.255. If the MS requests a static or already allocated HA, it should set the HA IP address accordingly. The Home and HA address allocations are based on the scenarios described in Section 6.1.3. Scenario 1 Scenario 2 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. 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. 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. 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. Table 5 MS Registration Scenarios While requesting a dynamic Home Address allocation, the MS shall use zero in the Source IP Address field of the IP packet that contains the Mobile IP RRQ. In this case the NAI is used to identify the MS. During MIP re-registrations, the MS shall use the same HA IP address and the Home Address that were assigned to it during the initial MIP registration. Upon receipt of an RRP message with successful registration indication (code 0) during initial registration, the MS shall accept the dynamically assigned HA address contained in the RRP message, even if it is different from the HA address provided in the RRQ message. If the MS had set up a Simple IP session and decides to run Mobile IP simultaneously using the FA function in the PDSN, it shall send an Agent Solicitation to the PDSN. Upon receiving an Agent Advertisement, the MS shall register with the PDSN and shall not use collocated CoA. The
Scenario 3
Scenario 4
18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
- 43 -
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42
3GPP2
MS may also register directly with the HA using a collocated CoA obtained from Simple IP IPCP negotiation. If the MS desires reverse tunneling, the MS shall set the T-bit in the RRQ message. The MS shall not set the 'V' bit in the RRQ message. 6.5.2.3 MIP Extensions The MS shall include the MN-NAI Extension [RFC 2794], MN-HA Authentication Extension [RFC 2002], MN-FA Challenge Extension [RFC 3012], and MN-AAA Authentication Extension [RFC 3012] in the RRQ message. Because advertisements are rarely sent to save air resources, the MS should use the challenge value contained in the last received RRP in the case of reregistrations as described in RFC 3012. The MS shall compute the MN-AAA Authentication Extension, according to RFC 3012, based on the shared secret the MS has with the Home RADIUS server. The MS shall compute the MN-HA Authentication Extension, according to RFC 2002, based on the shared secret the MS has with the HA. Computation of the extension shall include the Type and SPI field of the MN-HA Authentication Extension itself. The MS may use the same shared-secret or different shared secrets in the computation of the MN-AAA Authentication Extension and MN-HA Authentication Extension. This is coordinated between the MS and its home network. 6.5.2.4 Private Network Support If the MS wants private network access through Mobile IP, the MS shall use reverse tunneling. 6.5.2.5 Termination When the MS wishes to terminate a MIP session, the MS may send a Mobile IP RRQ to the HA with a Registration Lifetime of zero to gracefully close the MIP session before terminating the packet data service with the RN26. 6.5.2.6 DNS address Assignment If the MS receives at least one DNS Server IP Address NVSE (as defined in section 6.6) in the MIP Registration Reply message, then the MS may use the DNS server IP address in the NVSE instead of the DNS server IP address received during IPCP. If the MS receives multiple DNS Server IP Address NVSEs, it may select an appropriate entity (i.e., HAAA/VAAA or HA), for acquiring the DNS information, based on its internal policy. If Reverse Tunneling is applied for the MIP session, and the MIP Registration Reply includes at least one DNS Server IP Address NVSE with the entity-type field set to either 1 or 3 and the MS supports the DNS Server IP Address NVSE, then the MS shall use the DNS server IP addresses provided in the MIP Registration Reply. If the entity type is 3, the DNS information provided by the HA may have precedence over that provided by the HAAA or the VAAA.
6.6 DNS Server IP Address NVSE

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

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

The DNS server may be updated by either the Home RADIUS server or the HA. 8.2.1 DNS Update by the Home RADIUS Server If the Home RADIUS server receives a RADIUS Accounting-Request (Start) record containing the Beginning Session attribute and the IP-Technology attribute indicates Mobile IP and the Home RADIUS server is configured to send DNS Update messages for the Mobile IP sessions, 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
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
3GPP2
MS. The Home RADIUS server caches the User Name, NAS IP Address, and Framed IP address as received in the Accounting-Request (Start) record for the MS. If the beginning session attribute is not included in the Accouting-Request (Start) record, the Home RADIUS server shall not update the DNS server. If the Home RADIUS server receives a RADIUS Accounting-Request (Stop) record containing the IP-Technology attribute that indicates Mobile IP and that is associated with a previously cached User Name, NAS IP Address, and Framed IP address, and the Session-Continue attribute is either FALSE or absent, the Home RADIUS server shall request that the DNS server delete the Resource Record for the MS. 8.2.2 DNS Update by the HA If the Home RADIUS server receives a RADIUS Access-Request from an HA and the Home RADIUS server is configured to request HA-based DNS updates, the Home RADIUS server shall include the DNS-Update-Required attribute in the RADIUS Access-Accept message returned to the HA. If an initial Mobile IP registration is successful, and the HA is either configured to send DNS Update messages or has received a DNS-Update-Required attribute in the RADIUS AccessAccept message from the Home RADIUS server, the HA shall request the DNS server to add an A Resource Record for the MS. If the HA receives a Mobile IP RRQ with lifetime timer set to zero, or the Mobile IP lifetime expires, or administrative operations invalidate the mobility binding for the MS, the HA shall request that the DNS server delete the associated Resource Record.
8.3 IPv6 IRS

For IPv6 IRS support, the Home RADIUS server shall use the Resource Records defined in [RFC 1886] as updated by [RFC 2874] and [RFC 3150]. The operation of IRS service for IPv6 users is identical to the procedures described for Simple IPv4 in Section 8.1. If the MS uses both IPv4 and IPv6, the Home RADIUS server shall request that the DNS server create or delete Resource Records for both IPv4 and IPv6.
- 48 -
3GPP2
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
9 Mobility Management
9.1 Mobility Within Radio Network
Mobility in the wireless IP network architecture is achieved via handoffs. When a handoff is between PCFs with connectivity to the same PDSN so that the Serving PDSN remains the same before, during, and after handoff, it is called PCF to PCF handoff. When PCFs are connected to different PDSNs, the handoff is termed PDSN to PDSN handoff.
9.2 PCF to PCF Handoff

The link layer mobility management function is used to manage the change of the R-P session point of attachment while maintaining the PPP session and IP address(es). The R-P session point of attachment is the PDSN. When an MS moves from one PCF to another PCF, a new R-P connection between the Target PCF and the Serving PDSN is established for every packet data service instance. PCF to PCF handoff may happen while an MS is active or dormant. The purpose of dormant PCF handoff is to maintain the PPP session while an MS is dormant to minimize the use of airlink resources. The PCF to PCF handoff involves: PDSN selection New R-P session setup Previous R-P session tear down
The Target PCF triggers a new R-P session setup. If the PDSN selected is the same Serving PDSN for the MS, then the PDSN triggers a release of the previous R-P session. During a PCF to PCF handoff, the selection of the same PDSN is given priority in order to maintain the existing PPP session between the PDSN and the MS. The PDSN supports a low latency PCF to PCF handoff by bi-casting data to the target and previous PCF while the mobile performs an active handoff. If a different PDSN is selected and the MS still desires packet data service, then a PDSN to PDSN handoff may be performed (see Section 9.3). Each PCF is uniquely identified. At handoff the new PCF performs PDSN selection and forwards both the previous PCFs identification and its own identification to the selected PDSN. The PDSN uses this information to determine whether Mobile IP re-registration is required for the MS. If reregistration is required, the PDSN sends Agent Advertisements to the MS after the PPP session is established. Detailed requirements and standard procedures for PCF to PCF handoff are described in [4].
9.3 PDSN to PDSN Handoff

Mobile IP provides the IP layer mobility management function that maintains persistent IP addresses across PDSNs. For a Mobile IP based MS to maintain a persistent IP address while moving between Serving PDSNs, the MS re-registers with its HA as per RFC 2002 with extensions as outlined in Section 6. For PDSN to PDSN handoff, the MS may be in active or dormant state. For an active state MS, fast handoff may be supported between PDSNs. If fast handoff is supported, the Target PDSN initiates establishment of a P-P session with the Serving PDSN according to the procedures
- 49 -
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
3GPP2
described later in Section 12. If the MS was in dormant state, the MS transitions to active state for the purpose of establishing connectivity with the new PDSN. The PDSN to PDSN link for supporting fast handoff is called the P-P interface. Fast handoff with the P-P interface is used to keep the PPP session anchored when the PDSN to PDSN handoff is performed. This interface prevents the existing PPP session from being re-negotiated, thereby reducing service interruption time and data loss. The forward traffic received at the Serving PDSN is tunneled through the appropriate P-P connection to the Target PDSN. The Target PDSN then forwards the traffic to the MS over the corresponding R-P connection. The reverse traffic from the MS is tunneled through the P-P interface from the Target PDSN to the Serving PDSN. The Serving PDSN then forwards the traffic to the external network. If fast handoff is not supported, the PDSN to PDSN handoff for Mobile IP involves: Establishment of a new PPP session; Detection of a new Foreign Agent via the Agent Advertisement Message; Authentication by RADIUS infrastructure; Registration with the Home Agent.
If fast handoff is supported, the PDSN to PDSN handoff for Mobile IP involves: Establishment of a P-P connection for each associated R-P connection and the continuation of the current PPP session on the Serving PDSN; Establishment of a new PPP session by the Target PDSN when the MS becomes dormant or the MS renegotiates PPP; Release of the associated P-P connections while the new PPP session is being established at the Target PDSN; Detection of a new Foreign Agent via the Agent Advertisement Message; Authentication by RADIUS infrastructure; Registration with the Home Agent.
If fast handoff is not supported, the PDSN to PDSN handoff for Simple IP involves: Establishment of a new PPP session on the Target PDSN.
If fast handoff is supported, the PDSN to PDSN handoff for Simple IP involves: Establishment of a P-P connection for each associated R-P connection, and continuation of the current PPP session on the Serving PDSN; Establishment of a new PPP session by the Target PDSN, when the MS becomes dormant or the MS renegotiates PPP; Release of the associated P-P session while the new PPP session is being established at the Target PDSN.
The P-P interface is specified in Section 12.
- 50 -
3GPP2
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
10 Quality of Service
The cdma2000 service options allow various voice and non-voice services to be defined and specified independently within the confines of the physical layer and the multiplex sub-layer interface [5-9]. The air interface is able to support multiple service instances of the same or different packet data service options. cdma2000 specifications support a maximum of six service instances per MS, each of which may have associated RLP and/or QoS parameter settings. The MS and RN identify specific service instances with a unique number referred to as the Service Reference ID (SR_ID). Although this and subsequent sections contain text referring to multiple service instances, this specification does not support the use of auxiliary service instances connected to a PDSN from the same MS. This is because no standard exists for informing the PDSN how to map various application flows down the proper auxiliary connections. The text referring to auxiliary service instances is given for use by future releases of this specification. As outlined in [1], the RN/PCF transfers data to the PDSN via R-P connections for all service instances to the MS. There shall be one R-P connection for each service instance. The PDSN shall identify a service instance via an SR_ID carried in R-P connection signaling. A single R-P session shall be maintained for all the R-P connections associated with an MS. For each R-P session there shall be one main service instance, and optionally one or more auxiliary service instances. A single PPP session shall be associated with the R-P session. There shall be one PPP session between the MS and the PDSN. A given PPP session shall support one or more IP addresses. These IP addresses are not associated with a particular R-P connection. In this specification, a service instance may carry multiple flows. A flow is a series of packets that share a specific instantiation of IETF protocol layers. For example, an RTP flow may consist of the packets of an RTP/UDP/IP protocol instantiation, all of which share the same source and destination IP addresses and UDP port numbers. Flows may be identified at the PDSN using packet filters. Packet filters are used to map forward traffic to the corresponding auxiliary service instance. The following figure is a graphical illustration of the relationships between MS IP addresses, PPP session, R-P session, R-P connection, service instance, and SR_ID.
- 51 -
3GPP2
P.S0001-Bv2.0
3GPP2
Flow 1
Flow n
PDSN
PPP session
R-P session
R-P connection 1
Ch1=SR_ID1
R-P connection 2
Ch2=SR_ID2
R-P connection 3
Ch3=SR_ID3
BSC/PCF
Service instance 1
Service instance 2
Service instance 3
PPP session
MS
Flow 1
Flow n
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
Figure 13 - Graphical Illustration of Multiple Connection Relationships In accordance with differentiated services standards, the MS may mark packets (i.e., in the reverse direction). The PDSN limits the differentiated services markings that the MS applies to packets based on the User Profile from the Home AAA server. The PDSN also provides a fixed marking for Mobile IP based reverse tunneled traffic. This capability is especially useful for MSs that cannot mark packets but that desire the benefits of differentiated services for traffic traversing the Internet to a private network. The remainder of this section covers the following topics: Section 10.1: Multiple Service Instances Section 10.2: QoS Flow Mapping and Treatments Section 10.3: Subscriber QoS Profile
10.1
Multiple Service Instances
10.1.1 MS Requirements If the MS establishes multiple service instances, the MS shall always establish a main service instance before establishing auxiliary service instances. The MS shall support a single PPP session over multiple service instances. The MS shall send PPP control packets only over the main service instance. The MS shall not send PPP control packets over auxiliary service instances. The MS shall use octet-oriented HDLC framing per RFC 1662 over octet-oriented service instances. The MS shall not use HDLC framing over non-octet oriented service instances. If the MS uses Mobile IP, the MS shall send Mobile IP discovery and registration messages over the main service instance.
- 52 -
3GPP2
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
10.1.2 PDSN Requirements The PDSN shall support a single PPP session over multiple R-P connections for the same MS. Each R-P connection corresponds to a service instance. The PDSN shall send PPP control packets only over an R-P connection corresponding to the main service instance. The PDSN shall not send PPP control packets over R-P connections corresponding to the auxiliary service instances. The PDSN shall use octet-oriented HDLC framing over R-P connections corresponding to octet oriented service instances. The PDSN shall not use HDLC framing over an R-P connection corresponding to non-octet oriented service instances. For a Mobile IP MS, the PDSN shall send Mobile IP discovery and registration messages over an R-P connection corresponding to the main service instance. The PDSN shall support handoff and may support fast handoff of multiple service instances. At non-fast handoff of multiple service instances, failure of a fast handoff, or completion of the fast handoff, the Target PDSN shall initiate PPP negotiation over the main service instance. At dormant handoff of multiple service instances, the MS shall send its first origination for the service instance that was first setup in the previous packet zone. That service instance corresponds to the main service instance. If a previous PPP session is still maintained at the PDSN, the PDSN shall re-negotiate PPP if: The PANID information indicates that the MS has moved from a different PDSN coverage. The first A10 connection that was setup or restarted does not correspond to the existing main service instance in the PDSN.
10.2
QoS Flow Mapping and Treatments
If the MS opens an auxiliary service instance, the PDSN shall reject the R-P connection for that service instance because there is no mechanism in this specification to perform flow mapping in the MS and PDSN.
10.3
Subscriber QoS Profile
When the MS establishes Mobile IP service, the PDSN shall perform authentication and authorization of the MS with the HAAA server. When the MS establishes Simple IP service, the PDSN shall perform authentication and authorization of the MS with the HAAA server, unless the carrier has permitted null authentication28 as specified in 5.2.1.3, in which case the Subscriber QoS Profile shall be locally provisioned in the PDSN. Assuming the MS is authenticated, the HAAA may return Subscriber QoS Profile information via the VAAA to the PDSN in the authentication response. The Subscriber QoS Profile consists of the following: The Allowed Differentiated Services Markings attribute The Service Option Profile attribute
The attributes are specified in Annex C. The PDSN uses the Subscriber QoS Profile as part of the authorization for service instances. The PDSN shall store this information for subsequent use. In the event of multiple NAIs per MS, the PDSN may receive a Subscriber QoS Profile for each NAI. The PDSN shall store and handle multiple Subscriber QoS Profiles per MS. 10.3.1 Allowed Differentiated Services Marking The Differentiated Services Code Points (DSCPs) supported in this specification shall be based on the following RFCs:
28
This is the case in which the MS is permitted to negotiate Simple IP without CHAP or PAP. - 53 3GPP2
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
Class selectors: [RFC 2474] defines these as code points whose lower three bits (3, 4, 5) are all zero. Therefore, there are eight such classes. Default Forwarding (often called Best Effort) is a class selector with class equal to 0. Assured Forwarding (AF) classes: see [RFC 2597]. Expedited Forwarding (EF) Classes: see [RFC 2598].
When the MS marks IP packets with DSCPs, the PDSN shall ensure that only allowed DSCPs are used as authorized by the HAAA in the users Subscriber QoS Profile. If the HAAA does not include the Subscriber QoS Profile of the user in the RADIUS Access-Accept message, the PDSN shall offer a default QoS to the users packets as provisioned by the service provider. The Allowed Differentiated Services Marking attribute indicates the type of marking the user may apply to a packet. The PDSN may re-mark the packet according to local policy if the type of marking is not authorized by the user's Allowed Differentiated Services Marking attribute. The attribute contains three bits, the 'A', 'E', and 'O' bits. When the A bit is set, the user may mark packets with any AF class. When the E bit is set, the user may mark packets with EF class. When the O bit is set, the user may mark packets with experimental/local use classes. The Max Class Selector field specifies the maximum class selector for which a user may mark a packet. When all three bits are clear, and when the Max Class Selector is zero, the user may only send packets marked best effort. When reverse direction traffic arrives at the PDSN, the PDSN shall match the source address of such packets to a source address that is associated with an authenticated NAI. The PDSN should apply the associated Subscriber QoS Profile to the packet. 10.3.1.1 Differentiated Services and Tunnels The Allowed Differentiated Services Marking attribute contains a reverse tunnel marking ('RT Marking', see Annex C), which is the marking level the PDSN shall apply to reverse tunneled packets when those packets are not marked [RFC 2983]. If the packets received from the MS are marked, and traffic is to be reverse tunneled to the HA, the PDSN shall copy the (possibly remarked) inner packet marking to the outer header of reverse Mobile IP tunnels. For forward traffic to the MS, the HA should set the differentiated services field of the HA-FA tunnel to the differentiated services class of each received packet bound to the MS. 10.3.2 PDSN-Based R-P Admission Control The PDSN may reject a new R-P connection request from the RN if: the number of connections requested by the user exceeds limits set by the Service Option Profile; or, the service option is not on the list of allowed service options; or the connection is beyond the resources of the PDSN itself.
The HAAA may include a Subscriber QoS Profile in the AAA authorization response to the PDSN. In the event there are multiple Subscriber QoS Profiles due to multiple NAIs per MS, the PDSN shall combine the QoS parameters into a single Subscriber QoS Profile in accordance with local policy. The default local policy is as follows: the total set of all service options the maximum of the maximum number of service instances.
- 54 -
3GPP2
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
11 Accounting
11.1 General
11.1.1 Usage Data Records Packet Accounting parameters are divided into radio specific parameters collected by the RN, and IP network specific parameters collected by the Serving PDSN. The Serving PDSN shall merge radio specific parameters contained in R-P and P-P interface messages called Airlink Records with IP network specific ones to form one or more Usage Data Records (UDR). After merging, the Serving PDSN shall use RADIUS accounting messages to send UDR information to the Visited RADIUS Server. This is outlined as below in Figure 14, and further detailed in the subsequent sections. The Serving PDSN shall maintain UDR information until it receives positive acknowledgment from the RADIUS server that the RADIUS server has correctly received the RADIUS message. Likewise, the RADIUS server shall maintain the UDR until the record is delivered to a Home RADIUS server, or removed by the operator billing system. The method by which information is moved from a RADIUS server to a billing system is beyond the scope of this 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 channel, etc. RADIUS Records PDSN 2 PDSN adds more info and sends RADIUS accounting info RADIUS Server
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
Figure 14 - Accounting Architecture 11.1.2 Remote Address Accounting The PDSN shall support remote address based accounting by counting the number of octets exchanged between the MS and a remote IP address during a packet data session. The PDSN shall allow for enabling of this accounting functionality on a per user (i.e., NAI) basis, as specified in the User Profile information received from the Home RADIUS server during access procedures. The PDSN shall support the Remote IPv4/IPv6 Address and Remote Address Table Index attributes as defined in Annex C. The Home RADIUS server may use multiple instances of the Remote IPv4/IPv6 Address and Remote Address Table Index attributes in the RADIUS AccessAccept message to authorize remote address accounting for the user for specific remote addresses. A Remote IPv4/IPv6 Address attribute shall contain an address mask/prefix-length, so that a given address and mask/prefix-length indicates multiple addresses to be used for
- 55 -
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52
3GPP2
remote address accounting for the user29. The table indices specified by the Home RADIUS server point to tables of addresses stored at the PDSN. The method of provisioning the tables at the PDSN and the corresponding table indices at the Home RADIUS server is outside the scope of this specification. The PDSN shall support the Remote IPv4/IPv6 Address Octet Count attribute to count the number of bytes sent/received to/from a given remote address or set of remote addresses. The attribute contains a counter for forward traffic, a counter for reverse traffic, and the remote IP address or set of remote addresses with the same mask or prefix length (if present), as specified in Annex C. The PDSN shall generate a Remote IPv4/IPv6 Address Octet Count attribute for each remote address or set of remote addresses as represented by a mask or prefix length in use during a packet data session and authorized for the user by the RADIUS server. Hence, a UDR may contain multiple instances of the Remote IPv4/IPv6 Address Octet Count attribute. Therefore, the PDSN and the RADIUS server shall be capable of supporting multiple instances of the Remote IPv4/IPv6 Address Octet Count attribute in the RADIUS Accounting-Request (Stop) record and Interim messages. A remote address mask or prefix-length shall be used to indicate a range of addresses for remote address accounting. The PDSN shall aggregate the byte counts for all the remote IP addresses of that mask or prefix and generate one Remote IPv4/IPv6 Address Octet Count attribute. If the Remote Address Table Index is used for remote address based accounting, the current method is not easily scalable to multi-domain support, due to issues with table provisioning and synchronization between realms. In this case, the remote address functionality shall be limited to a single realm support from an access provider network point of view. All the PDSNs in a single realm shall have the same set of tables. There is no explicit support in this specification for coordinating table indices across realms. The Home RADIUS server shall be of the same realm as the PDSN or it shall have coordinated its indices with the realm that owns the PDSN. It is the responsibility of the Visited RADIUS server to ensure the remote address table indices returned in a RADIUS Access-Accept message are consistent with the tables stored in the PDSN. For example, the Visited RADIUS server may filter out the Remote Address Table Index attributes contained in the RADIUS Access-Accept messages received from uncoordinated realms. When a packet is received in the forward direction, the PDSN shall examine the source IP address of the packet. If the source IP address matches a remote address for the user, the PDSN shall create a Remote IPv4/IPv6 Address Octet Count attribute as part of the UDR if it does not exist and shall increment the octet counts. When a packet is received in the reverse direction, the PDSN shall examine the destination IP address of the packet. If the destination IP address matches a remote address for the user, the PDSN shall create an instance of the Remote IPv4/IPv6 Address Octet Count attribute if it does not exist and shall increment octet counts. Both IPv4 and IPv6 remote addresses are supported in remote address accounting. The structure of remote address tables, and the method of communicating such information to the PDSN are outside the scope of this specification. 11.1.3 Accounting and Fast Handoff If a P-P session exists, the Target PDSN shall forward the airlink records received from the Target RN to the Serving PDSN over the P-P interface. The Target PDSN shall not alter the airlink records. The Serving PDSN shall perform accounting functions for the data exchanged 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
P.S0001-Bv2.0 1 2 3 4 5 6 7 8
3GPP2
the Serving PDSN combines these with IP network specific parameters, the UDR is sent to the RADIUS server as a RADIUS Accounting-Request record. This is outlined as below in Figure 15, and detailed in the subsequent sections. Upon fast handoff, the Target PDSN shall store a copy of the airlink records received at pre-setup of the R-P session. Also, the Serving PDSN copies some of the data from the current UDR or UDRs to the new UDR or UDRs while fast handoff is in progress. The PDSN accounting procedures ensure that no double counting of usage occurs.
Target RN 3 UDR
RADIUS Server
1 R-P Interface
Airlink Records i.e., MSID, location, time on channel, etc.
PDSN adds more info and sends complete UDR Serving PDSN
Target PDSN
P-P Interface 2 Airlink Records i.e., MSID, location, time on channel, etc.
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
Figure 15 - Accounting Architecture With Fast Handoff 11.1.4 Accounting Attribute Notation A lower case letter implies an accounting attribute in an airlink record whereas a capital letter implies an accounting attribute in a UDR. Thus attributes in Table 6 - Table 9 that apply to airlink records use lower case letters, and attributes in Table 10 and Table 11 that apply to UDRs use upper case letters.
11.2

Airlink Records
An R-P connection setup when the RN establishes an R-P session. An Active Start Airlink Record when the MS has started to use traffic channel(s). An Active Stop Airlink Record when the MS has stopped using traffic channel(s). A Short Data Burst (SDB) Airlink Record when a forward or reverse short data burst is exchanged with the MS.
The RN generates one of four types of airlink records over the R-P interface:
The PCF uses the R-P Connection ID as the PCF Session Identifier Key in R-P setup messages, and the GRE key in R-P packets. For bi-directional keys, the PDSN also uses the RP Connection ID as the GRE key in R-P packets.
- 57 -
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
3GPP2
For fast handoff, the Target PDSN forwards the airlink records to the Serving PDSN unchanged. The Target PDSN shall store a copy of the airlink records received at pre-setup of the R-P session for each R-P connection. All the airlink records shall include a sequence number initialized to zero at R-P connection setup. The sequence number is unique for a single identification triplet (R-P Connection ID, PCF ID, and MSID). Upon receiving the connection setup airlink record, the Serving PDSN updates the UDR with the airlink record information and stores the sequence number. The PCF shall increment the sequence number modulo 256 in the subsequent airlink record transmitted over the corresponding R-P connection. The Serving PDSN shall compare the received sequence number with the previously stored sequence number (N). If the received sequence number is in the range from (N+1) modulo 256 to (N+127) modulo 256, inclusive, the PDSN shall act accordingly based on the information contained in the airlink record, and shall update its stored sequence number. If the received sequence number is in the range from (N-128) modulo 256 to (N-1) modulo 256, inclusive, the Serving PDSN shall ignore the message. The same procedure continues for all the subsequent airlink records, until the closing of the R-P connection. In the event of retransmission, the PCF shall retransmit with the same sequence number, and the Serving PDSN shall not update the UDR if the same sequence number corresponding to a single identification triplet is received. There should be only one outstanding unacknowledged airlink record at any given time. Detailed specifications of airlink records are in [4]. 11.2.1 R-P Connection Setup Airlink Record Table 6 contains fields present in the R-P Connection Setup airlink records.
Item Parameter Max Payload Length (octets) 4 4 4 15 15 14 4 12 Format
y1 y2 y3 a1 a2 30 a3 d3 d4
Airlink Record Type = 1 (Connection Setup) R-P Connection ID Airlink Sequence Number MSID ESN MEID Serving PCF BSID
integer integer integer string string string ip-addr string
27 28 29 30 31
Table 6 R-P Connection Setup Airlink Fields Each R-P connection and each airlink record is indexed via the R-P Connection ID.
30
Either a2 or a3, or both shall be included. - 58 3GPP2
P.S0001-Bv2.0
3GPP2
1 2 3
11.2.2 Active Start Airlink Record Table 7 contains fields present in Active Start airlink records.
Item Parameter Max Payload Length (octets) 4 4 4 4 4 4 4 4 4 4 4 4 4 4 Format
y1 y2 y3 e1 f1 f2 f5 f6 f7 f8 f9 f10 f14 i4
Airlink Record Type = 2 (Active Start) R-P Connection ID Airlink Sequence Number User Zone Forward Mux Option Reverse Mux Option Service Option Forward Traffic Type (Primary, Secondary) Reverse Traffic Type (Primary, Secondary) Fundamental Frame Size (0/5/20 ms) Forward Fundamental RC Reverse Fundamental RC DCCH Frame Size (0/5/20ms) Airlink Priority
integer integer integer integer integer integer integer integer integer integer integer integer integer integer
4 5 6 7 8 9 10 11 12
Table 7 Active Start Airlink Fields If the e1, f1, f2, and/or i4 parameters in Table 7 change during the active session, the RN shall send an Active Stop Airlink Record, and an Active Start Airlink Record with the new parameters. f1 to f10 are fields from the service configuration record. 11.2.3 Active Stop Airlink Record Table 8 contains fields present in Active Stop Airlink Records.
Item Parameter Max Payload Length (octets) 4 4 4 4 Format
y1 y2 y3 g8
Airlink Record Type = 3 (Active Stop) R-P Connection ID Airlink Sequence Number Active Connection Time in Seconds
integer integer integer integer
13 14 15 16 17
Table 8 Active Stop Airlink Fields 11.2.4 SDB Airlink Record Table 9 contains fields present in SDB Airlink Records.
Item Parameter Max Payload Length (octets) 4 4 4 4 4 Format
y1 y2 y3 y4 g10
Airlink Record Type = 4 (SDB) R-P Connection ID Airlink Sequence Number Mobile Originated/Mobile Terminated Indicator SDB Octet Count
integer integer integer integer integer
18 19
Table 9 SDB Airlink Fields
- 59 -
3GPP2
P.S0001-Bv2.0 1 2 3 4
3GPP2
11.3
PDSN Usage Data Record (UDR)

Description MS ID (e.g., IMSI, MIN, IRM) Electronic Serial Number Mobile Equipment Identifier IPv4 address of the MS. user@domain construct which identifies the user and home network of the MS. MS IPv6 prefix See RFC 3162
Table 10 contains the complete UDR and the description of each field.
Item Parameter A. Mobile Identifiers A1 MSID A2 ESN A3 MEID B. User Identifiers B1 Source IP Address B2 Network Access Identifier (NAI) B3 Framed-IPv6Prefix B4 IPv6 Interface ID C. Session Identifiers C1 Account Session ID
The Account Session ID is a unique accounting ID created by the Serving PDSN that 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 F7 F8 F9 F10 F11 F12 F13 Forward Traffic Type Reverse Traffic Type Fundamental Frame Size Forward Fundamental RC Reverse Fundamental RC IP Technology Compulsory Tunnel Indicator Release Indicator Forward direction traffic type either Primary or Secondary Reverse direction traffic type either Primary or Secondary Specifies the FCH Frame Size The format and structure of the radio channel in the forward FCH. A set of forward transmission formats that are characterized by data rates, modulation characterized, and spreading rates. [6] The format and structure of the radio channel in the reverse FCH. A set of reverse transmission formats that are characterized by data rates, modulation characterized, and spreading rates. [6] Identifies the IP technology to use for this call: Simple IP or Mobile IP. Indicator of invocation of compulsory tunnel established on behalf of MS for providing private network and/or ISP access during a single packet data connection. Specifies reason for sending a stop record.
- 60 -
3GPP2
P.S0001-Bv2.0
3GPP2
F14 F15
DCCH Frame Size Specifies Dedicated Control Channel (DCCH) frame size. Always On Specifies the status of Always On service. The total number of octets in IP packets sent to the user. The total number of octets in IP packets sent by the user. The total number of PPP frames from the MS dropped by the PDSN due to uncorrectable errors. 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. Contains the octet count associated with a remote IPv4 address; used for source/destination accounting. Contains the octet count associated with a remote IPv6 address; used for source/destination accounting. The total active connection time on traffic channel in seconds. The total number of non-active to Active transitions by the user. The total number of octets sent to the MS via Short Data Bursts. The total number of octets sent by the MS via Short Data Bursts. The total number of Short Data Burst transactions with the MS. The total number of Short Data Burst transactions with the MS. The count of all bytes received in the reverse direction by the HDLC layer in the PDSN. This is the total number of octets in registration requests and solicitations sent by the MS. This is the total number of octets in registration replies and agent advertisements sent to the MS.
G. Session Activity G1 Data Octet Count (Terminating) G2 Data Octet Count (Originating) G3 Bad PPP frame count G4 Event Time
G5 G6 G8 G9
Remote IPv4 Address Octet Count Remote IPv6 Address Octet Count Active Time
Number of Active Transitions G10 SDB Octet Count (Terminating) G11 SDB Octet Count (Originating) G12 Number of SDBs (Terminating) G13 Number of SDBs (Originating) G14 Number of HDLC layer bytes received G15 Inbound Mobile IP Signaling Octet Count G16 Outbound Mobile IP Signaling Octet Count I. Quality of Service I1 I4 IP Quality of Service (QoS) Airlink Priority
This attribute is deprecated. 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
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10 11
11.4
Accounting Formats
The RADIUS server shall support RADIUS attribute formats as defined in RFC 2865 and RFC 2866. The RN airlink records transmitted across the R-P interface and the P-P interface shall follow the RADIUS format encapsulated in a MIP vendor specific attribute (attribute type 38). Table 11 lists each accounting parameter and its associated RADIUS attribute. Note: Attributes of type 26 defined in RFC 2865 and RFC 2866 are vendor specific, and are used to transport 3GPP2 specific parameters. Attribute value types 26/60 to 26/69 within the 3GPP2 vendor specific space are reserved. The default Vendor ID value in Vendor Specific attributes shall be 5535 defined in IANA in order for cdma2000 packet data service to support global roaming. 3GPP2 attribute formats not defined in Annex C are included in Table 11.
- 62 -
3GPP2
P.S0001-Bv2.0
3GPP2
1 2
RADIUS Attribute Definitions Item Parameter Type/ Vendor Type Maximum Payload Length (in octets) 15 15 14 4 72 4-20 Format Field Special Values
A. Mobile Identifiers A1 MSID A2 ESN A3 MEID B. User Identifiers B1 Source IP Address B2 Network Access Identifier (NAI) B3 Source IPv6 Prefix
31 26/52 26/116 8 1 97
string string string ip-addr string IPv6-prefix
Calling_ID ESN MEID Framed IP Address User-Name Framed IPv6 Prefix
ASCII string of ESN ASCII string of MEID
B4 IPv6 Interface ID C. Session Identifiers C1 Account Session ID C2 Correlation ID C3 Session Continue C4 Beginning Session D. Infrastructure Identifiers D1 MIP Home Agent (HA) D2 PDSN Address D3 D4 Serving PCF BSID
96 44 26/44 26/48 26/51 26/7 4 26/9 26/10
10 8 8 4 4 4 4 4 12
string string string integer integer ip-addr ip-addr ip-addr string
Framed_Interface_ID Acct_ Session_Id Correlation_Id 3GPP2_Session_cont 3GPP2_Begin_Session 3GPP2_HA_IP_Addr NAS Address 3GPP2_PCF IP_Addr 3GPP2_BSID
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). See RFC 3162 ASCII string of session ID ASCII string of correlation ID 0=False, 1=True 0=False, 1=True
IPv4 address of the RADIUS client in the PDSN The serving PCF is the PCF in the serving RN. 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
E. Zone Identifiers
- 63 -
3GPP2
P.S0001-Bv2.0
3GPP2
E1
User Zone
26/11
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].
F. Session Status F1 Forward Mux Option F2 Reverse Mux Option F5 Service Option F6 Forward Traffic Type F7 Reverse Traffic Type (Primary, Secondary) F8 Fundamental Frame Size F9 F10 F11 F12 F13 Forward Fundamental RC Reverse Fundamental RC IP Technology Compulsory Tunnel Indicator Release Indicator
26/12 26/13 26/16 26/17 26/18 26/19 26/20 26/21 26/22 26/23 26/24
4 4 4 4 4 4 4 4 4 4 4
integer integer integer integer integer integer integer integer integer integer integer
3GPP2_FMUX 3GPP2_RMUX 3GPP2_SO 3GPP2_FTYPE 3GPP2_RTYPE 3GPP2_FFSIZE 3GPP2_FRC 3GPP2_RRC 3GPP2_IP_Tech 3GPP2_Comp_Flag 3GPP2_Reason_Ind
F14 F15
DCCH Frame Format (0/5/20ms) Always On
26/50 26/78
4 4
integer integer
3GPP2_DFSIZE 3GPP2_Always_ON
0=Primary, 1=Secondary 0=Primary, 1=Secondary 0=no fundamental, 1=5ms and 20ms mixed frame, 2=20ms frame See [6] See [6] 1=Simple IP, 2=Mobile IP 0=no tunnel 1=non-secure tunnel 2=secure tunnel Reasons for stop record: 0=unknown 1=PPP/Service timeout 2=Handoff 3=PPP termination 4=Mobile IP registration failure 0=no DCCH, 1=5ms and 20ms mixed frame, 2=20ms frame, 3=5ms frame Always On 0=no 1=yes
G. Session Activity G1 Data Octet Count (Terminating) G2 Data Octet Count (Originating) G3 Bad PPP Frame Count G4 G5 G6 G8 G9 G10 G11 Event Time Remote IPv4 Address Octet Count Remote IPv6 Address Octet Count Active Time Number of Active Transitions SDB Octet Count (Terminating) SDB Octet Count (Originating)
43 42 26/25 55 26/72 26/9780 26/49 26/30 26/31 26/32
4 4 4 4 variable32 variable44 4 4 4 4
integer integer integer time octet string octet string integer integer integer integer
Acct_Output_Octets Acct_Input_Octets 3GPP2_Bad_Frame_Cou nt Event_Timestamp See Annex C See Annex C 3GPP2_Active_Time 3GPP2_Num_Active 3GPP2_SDB_Input_Octe ts
3GPP2_SDB_Output_Octe ts
- 64 -
3GPP2
P.S0001-Bv2.0
3GPP2
G12 G13 G14 G15 G16
Number of SDBs (Terminating) Number of SDBs (Originating) Number of HDLC layer bytes received Inbound Mobile IP Signaling Octet Count Outbound Mobile IP Signaling Octet Count
26/33 26/34 26/43 26/46 26/47
4 4 4 4 4
integer integer integer Integer Integer
3GPP2_NumSDB_Input 3GPP2_NumSDB_Outpu t 3GPP2_Num_Bytes_Rec The count of all bytes received in the eived_Total reverse direction by the HDLC layer in the PDSN. 3GPP2_Mobile_IP_Signa This is the total number of octets in ling_Inbound_Count registration requests and solicitations sent by the MS. 3GPP2_Mobile_IP_Signa This is the total number of octets in ling_Outbound_Count registration replies and agent advertisements, sent to the MS. 3GPP2_IP_QOS 3GPP2_Air_Prioirty This attribute is deprecated Least significant 4 bits hold the priority associated with the packet data service.
I. Quality of Service I1 IP Quality of Service (QOS) I4 Airlink Priority Y. Airlink Record Specific Parameters Y1 Airlink Record Type
26/36 26/39
4 4
integer integer
26/40
integer
Y2 Y3 Y4
R-P Connection ID Airlink Sequence Number Mobile Originated / Mobile Terminated Indicator
26/41 26/42 26/45
4 4 4
integer Integer Integer
3 4 5 6 7
3GPP2_Airlink_Record_T 1=Connection Setup ype 2=Active Start 3=Active Stop 4=SDB Record 3GPP2_RP_Connection_ID 3GPP2_Airlink_Sequenc e_Number 3GPP2_Mobile_Terminat 0=Mobile Originated ed_Originated_Indicator 1=Mobile Terminated 3GPP2_Container See Annex C
Z. Container Z1 Container
26/6
Variable
string
Table 11 Accounting Parameter Attribute RADIUS Definitions
- 65 -
3GPP2
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
11.5

PDSN Procedures
Reception of R-P Connection Setup Airlink Record over R-P or P-P interface. R-P or P-P connection termination at the PDSN. Data service establishment or PPP renegotiation on the PDSN. This includes a PPP session and packet service session (Simple IP or Mobile IP). Data service termination on the PDSN. This includes releasing the PPP session, or release of a packet service session (Simple IP or Mobile IP). Arrival of forward direction or reverse direction user data. Reception of Active Start Airlink Record. Reception of Active Stop Airlink Record. Reception of SDB Airlink Record. Interim record trigger. Stop record trigger. Time of day timer expiry.
There are several kinds of events that cause the PDSN to take accounting action:
Each packet data session (i.e., Simple IP and/or Mobile IPv4 session) is identified by a correlation ID provided to the HAAA at the time authentication/authorization is performed. Each individual Simple IPv4, Mobile IPv4, and Simple IPv6 session shall be accounted for independently. All UDR information is stored and transmitted per tuple of {assigned IPv4 address or IPv6 prefix, NAI, (R-P or P-P connection ID)}. However, simultaneous Simple IPv4 and Simple IPv6 shall use a common correlation ID because they use a common authorization procedure. During the lifetime of the Simple IP and/or Mobile IP session, UDRs are created, modified, maintained, copied, and released for each individual connection. The Serving PDSN shall create one UDR per R-P connection ID and one UDR per P-P connection for each packet data session established by the MS. An R-P connection may be directly connected to the serving PDSN or indirectly connected via a P-P connection. The PDSN closes a UDR when any of the following events occur: An existing R-P or P-P connection is closed. The PDSN determines the packet data session associated with the correlation ID has ended.
At an initial R-P connection establishment, a UDR is created and initialized from relevant airlink records. When there is a new R-P or P-P connection due to a handoff for an existing packet data session, or when a new packet data session for an existing R-P or P-P connection is created because PPP is renegotiated, or when there is a new R-P connection for an existing packet data session, a UDR is created by copying data from a previous UDR. For example, during a fast handoff, the PDSN copies packet data session information (e.g., IP address and NAI) from the previous UDR associated with the source RN to the new UDR associated with the new RN. Similarly, if the MS sends an LCP Configure-Request message over the main service instance to restart the PPP session, the PDSN copies R-P or P-P connection data (e.g., F1-F14) from all current UDRs of the entire packet data session to new UDRs for the new packet data session. The Serving PDSN closes the previous UDRs and sends accounting records to the RADIUS server. Furthermore, during a fast handoff, either two R-P connections, an R-P and P-P connection, or two P-P connections may exist momentarily with the same SR_ID and MSID due to the PDSN
- 66 -
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
3GPP2
bicasting31 to both the source and target RNs. Since the MS can connect to only one RN for a given service instance, the PDSN accounting procedures ensure that double counting between the current and new (copy) never occurs despite the PDSN bicasting of data to both service instances. RADIUS accounting messages are generated from the information in the UDR. The Correlation ID is used to match different accounting records (Account Session IDs) across R-P connections or P-P connections for a single packet data session. One Correlation ID for all R-P and P-P connections is maintained for the life of a packet data session for each NAI and IP pair. The Account Session ID is used to match a single RADIUS Start and Stop pair. A different Account Session ID is used for each R-P connection and/or P-P connection. A new R-P connection due to intra-PDSN handoff between PCFs shall result in a new R-P Connection ID and Account Session ID. A new P-P connection due to fast handoff between the PDSNs shall result in a new R-P Connection ID and Account Session ID. The MSID and SR_ID are used to select the proper UDR after an intra-PDSN handoff. One R-P Connection ID may be associated with multiple simultaneous NAI, IP pairs in the Serving PDSN (i.e., multiple packet data sessions). Airlink records are only associated with an R-P connection IDor a P-P connection. The Serving PDSN matches the R-P Connection ID in the airlink record to the R-P Connection ID in the appropriate UDR(s). If more than one UDR matches, the actions are applied to all UDRs. Some events cause certain UDR fields to change in the middle of a session. When this happens, one of two approaches shall be taken: (1) a container attribute as specified in Annex C is created and the changed fields are embedded in that container attribute. This allows the UDR to continue to accumulate accounting information after an event without transmitting a RADIUS message. Alternatively (2), the PDSN may send a RADIUS Stop record to capture accounting data before the event, followed by a RADIUS Start record with the new field values. In fact, a PDSN may send a RADIUS Stop and RADIUS Start anytime during a single session as long as no accounting data is lost. In these cases, the PDSN shall send the same Correlation ID in both the RADIUS Start and RADIUS Stop records. The subsequent sections specify the actions to take for each event. 11.5.1 R-P Connection Setup Airlink Record Arrives When the Serving PDSN receives an R-P Connection Setup Airlink Record over an R-P or P-P connection as a result of a handoff, then the PDSN shall use the MSID and SR_ID to find the correct UDR, and, either: Create a new Container attribute in the UDR with Container-Reason Handoff, Eventtimestamp current time and attributes D2 (in case of an IPv6 PDSN, D5), D3, D4, G1, G2, G3, and G8-16, and all instances of G5/G6. Use information received from the RN to fill in the following fields: D3 and D4. The PDSN fills in D2 (in case of an IPv6 PDSN, D5). Zero fields G1, G2, G3, G8-16; all instances of G5/G6 in the newly created accounting container are eliminated. Mark the UDR as pending32 if the S bit in the A11 Registration-Request message or P-P Registration-Request message that carries the Session Setup Airlink Record is set to '1'. When the Active Stop Airlink Record for the previous R-P or P-P connection arrives, update the accounting fields inside the newly created accounting container. (See section 11.5.6 for further processing of the Airlink Stop Record).
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
31
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 Or:
3GPP2
Create a copy of the current UDR. Use information received from the RN to fill the following fields in the copy UDR: D3 and D4. The PDSN fills in D2 (in case of an IPv6 PDSN, D5). Zero fields G1, G2, G3, and G8-16 in the copy UDR; all instances of G5/G6 in the copy UDR are eliminated. Send a RADIUS Accounting-Request (Start) record containing a new Account Session ID and the same Correlation ID. Mark the new UDR as pending if the S bit in the A11 Registration-Request message or P-P Registration-Request message that carries the Session Setup Airlink Record is set to '1'. When the Active Stop Airlink Record for the previous R-P or P-P connection arrives, update the current UDR and send a RADIUS Accounting-Request (Stop) record based on the current UDR. The RADIUS Accounting-Request (Stop) record contains a Session Continue attribute with the value set to 1 (True), the same correlation ID, and the original session ID. (See section 11.5.6 for further processing of the Airlink Stop Record).
Otherwise (i.e., there is no handoff), the Serving PDSN shall use the R-P Connection Setup Airlink record (from the current RN) to fill the following fields of the new UDR: A1, A2, A3, D3, and D4 Zero fields G1-G16.
The Serving PDSN shall populate the remaining fields of the UDR as specified in sections 11.5.2 and 11.5.5. 11.5.2 Packet Data Service Establishment After the PDSN establishes a packet data service session (i.e., Simple IP or Mobile IP) on the main service instance, or a new R-P connection setup associated with an auxiliary service instance occurs with an existing packet data session, the Serving PDSN shall: Fill the following fields: B1, (in case of IPv6 MS, B3), B2, C1, C2, C4, D1, D2 (in case of IPv6 PDSN, D5), F11, F12, and I1. Send a RADIUS Accounting-Request (Start) record based on the current UDR.
11.5.3 Packet Data Service Termination After the Serving PDSN terminates packet data service to the MS for every UDR, the Serving PDSN shall: Add a Session Continue attribute in the UDR with the value set to 0 (False). Send a RADIUS Accounting-Request (Stop) record based on the current UDR. Delete the UDR after receiving acknowledgment from the RADIUS server that it has successfully received the UDR.
If the reason for the packet data termination is due to the MS sending an LCP Configure-Request message, and if the MS is not in a fast handoff state, then for every UDR the Serving PDSN shall: Create a copy of the current UDR using A1, A2, A3, D3, D4, F1-F14 and I4 from the current UDR in the new UDR. Zero fields G1, G2, G3, and G8-13 in the new UDR. Add a Session Continue attribute in the current UDR with the value set to 0 (False). Send a RADIUS Accounting-Request (Stop) record based on the current UDR. Delete the current UDR after receiving acknowledgment from the RADIUS server that it has successfully received the UDR.
- 68 -
3GPP2
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
Follow Packet Data Service Establishment accounting procedures for each new UDR immediately after packet data establishment.
11.5.4 User Data Through PDSN For any user data processed by the Serving PDSN in the forward direction, the Serving PDSN shall use the MS IP address and SR_ID to find the correct UDR. If the UDR is not pending then the PDSN shall: Increment G1 before compression by the number of octets in IP packets sent to the user. Increment G16 before compression by the number of octets in Mobile IP signaling packets33 sent to the user. If the source IP address of the user packet is one of the remote addresses authorized for the user for destination based accounting, a G5/G6 instance is created in the UDR for this address (if one does not exist already), and the Forward Octet Count field in this G5/G6 instance is incremented before compression as necessary.
For any user data processed by the Serving PDSN in the reverse direction, the Serving PDSN shall use the MS IP address and SR_ID to find the correct UDR. If the UDR is not pending then the PDSN shall: Increment G2 after decompression by the number of octets in IP packets sent by the user. Increment G14 by the number of octets received at the HDLC layer. Increment G15 after decompression by the number of octets in Mobile IP signaling packets sent by the user. If the destination IP address of the user packet is one of the remote addresses authorized for the user for destination based accounting, a G5/G6 is created in the UDR for this address (if one does not exist already), and the Reverse Octet Count field in this G5/G6 instance is incremented after decompression as necessary.
If the UDR is pending, the PDSN shall not modify the accounting usage data of the UDR. 11.5.5 Active Start Airlink Record Arrives When the PDSN receives an Active Start Airlink record from the RN or Target PDSN, the Serving PDSN performs the following. If the UDR is new (some fields are blank), the Serving PDSN shall: Set UDR fields according to airlink record: E1 i4 If the UDR is pending, mark it as not pending. e1, F1-F10 f1-f10, F14 f14, and I4
Otherwise, if the airlink record indicates parameters E1, F1, F2, or I4 have changed, the Serving PDSN shall either: Or:
33
Create a new Container attribute in the UDR with Container-Reason Parameter change, Event-timestamp current time and attributes E1, F1, F2, G1, G2, G3, G8-G16, I4, and all instances of G5/G6. Set UDR fields according to the airlink record. E1 e1, F1 <- f1, F2 <- f2, I4 i4, and zero fields G1, G2, G3, and G8-16. All current instances of G5/G6 in the UDR are eliminated.
This means IP, UDP, and the MIP message payload above UDP. - 69 3GPP2
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
Add a Session Continue attribute in the current UDR with the value set to 1 (True). Send a RADIUS Accounting-Request (Stop) record based on the current UDR. Set UDR fields according to airlink record. E1 e1, F1 <- f1, F2 <- f2, I4 i4 and zero fields G1, G2, G3, and G8-16. All current instances of G5/G6 in the UDR are eliminated. Send a RADIUS Accounting-Request (Start) record based on UDR containing a new Account Session ID and same Correlation ID.
Finally, the PDSN shall increment G9 by one. 11.5.6 Active Stop Airlink Record Arrives When the Serving PDSN receives an Active Stop Airlink record from the RN, the PDSN shall: Increment G8 by the value of g8.
11.5.7 SDB Airlink Record Arrives The PDSN shall increment G1/G2 for all forward/reverse user data corresponding to the MS IP address. When the Serving PDSN receives an SDB airlink record from the RN or the Target PDSN, the Serving PDSN shall use the MS IP address and SR_ID to find the correct UDR or UDRs in the event of multiple packet data sessions. If the mobile originated / mobile terminated indicator is equal to one (mobile terminated SDB), the Serving PDSN shall: Increment G10 by the value of g10. Increment G12 by one.
If the mobile originated / mobile terminated indicator is equal to zero (mobile originated SDB), the Serving PDSN shall use the MS IP address and SR_ID to find the correct UDR. The PDSN shall: Increment G11 by the value of g10. Increment G13 by one.
11.5.8 Interim Record Trigger When the Interim Record Trigger initiates, the Serving PDSN shall send a RADIUS AccountingRequest Interim record based on the current UDR. The Interim Record Trigger is an operator configurable time interval since the last RADIUS accounting record was sent for a UDR. 11.5.9 Stop Record Trigger Additional conditions may trigger a RADIUS Accounting-Request (Stop) record to be sent by the PDSN such as: When the size of the RADIUS accounting record to be sent for the UDR exceeds an operator configurable threshold. Any time during a session as an implementation dictates.
When the Stop Record Trigger initiates, the PDSN shall add a Session Continue attribute in the UDR with the value set to 1 (True). The PDSN shall send a RADIUS Accounting-Request (Stop) record based on the current UDR and fields G1, G2, G3, G8-16 are zeroed and all current instances of G5/G6 in the UDR are eliminated. Immediately afterwards, the PDSN shall send a RADIUS Accounting-Request (Start) record based on the current UDR containing a new Account Session ID and the same Correlation ID.
- 70 -
3GPP2
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
11.5.10 Time of Day Timer Expires The time of day timer(s) shall be a set of operator configurable parameters for certain time(s) of day. These timers may be used, for example, to delineate peak and off-peak billing hour boundaries. When an accounting time of day timer expires, the Serving PDSN shall either: Or, Add a Session Continue attribute in the UDR with the value set to 1 (True). Send a RADIUS Accounting-Request (Stop) record based on the current UDR. Zero fields G1, G2, G3, and G8-16. All current instances of G5/G6 in the UDR are eliminated. Send a RADIUS Accounting-Request (Start) record based on current UDR containing a new Account Session ID and the same Correlation ID. Create a new Container attribute in the UDR with Container-Reason Tariff Boundary, Event-timestamp current time and attributes G1, G2, G3, and G8-G16. Instances of G5/G6 are copied to the container. Zero fields G1, G2, G3, and G8-16. All current instances of G5/G6 in the UDR are eliminated.
- 71 -
3GPP2
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
12 P-P Interface
12.1 Architecture
The network reference model is depicted in Figure 1 and Figure 2. This section describes the functionality for a fast handoff in the context of an inter-PDSN handoff. This section provides P-P interface details. See [4] for fast handoff procedures over the R-P interface. With the implementation of the P-P Interface, the following additional functions are provided by the PDSNs during fast handoff: For every R-P connection at the Target PDSN, there is a corresponding P-P connection. The Target PDSN does not terminate PPP. The Target PDSN provides transparent bi-directional transport of the bearer data stream over the R-P and P-P connections. The Serving PDSN provides bi-directional transport of the bearer data stream over the PP connections. The Target PDSN forwards accounting related airlink records received over an R-P connection to the Serving PDSN over the corresponding P-P connection. The Serving PDSN processes airlink records received over the P-P connection similar to the airlink records received over the R-P connection by creating separate UDRs. The Target PDSN becomes the Serving PDSN when all service instances on the Target RN are released (e.g., dormant) or PPP is re-negotiated by the MS. When the MS closes the PPP session, the Serving PDSN shall release the P-P connections, and the Target PDSN shall release the R-P connections. At handoff, the Target PDSN shall use the main service instance to carry on PPP negotiations.
During a fast handoff, either two R-P connections, an R-P and P-P connection, or two P-P connections may exist momentarily with the same SR_ID and MSID due to the PDSN bicasting to both the Source and Target RNs.
12.2
The P-P Interface Protocol
This section specifies the protocol and messages to be used for signaling for the P-P connections. Implementation of the P-P Interface is independent of the physical and link layers of the transport media over which the P-P connection(s) is/are to be established. The underlying transport media provides UDP/IP based packet oriented connectivity. There are two components for the P-P Interface: Signaling: Control messages shall be used for managing the P-P connection(s) between Serving and Target PDSNs. Bearer Transport: GRE frames shall be used for the transport of bearer data frames between Serving and Target PDSNs.
The Target PDSN shall initiate establishment of a P-P connection, whereas either the Serving PDSN or the Target PDSN may initiate termination of the connection. Termination of a P-P connection shall follow the procedures for R-P connections as specified in [4]. Once a P-P connection has been established, the bearer portion of the P-P connection shall use GRE framing (RFC 2784, RFC 2890) for the transport of bearer data frames. There shall be one P-P connection between the Serving PDSN and the Target PDSN for each R-P connection between the Target PDSN and Target RN. The GRE payloads in the P-P connection and R-P connection shall be identical for the same connection.
- 72 -
3GPP2
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
12.2.1 Signaling The following messages shall be used for P-P Interface call control and signaling34: P-P Registration-Request P-P Registration-Reply P-P Registration-Update P-P Registration-Acknowledge
These messages use the same format as R-P connection messages specified in [4], including use of the same UDP port number 699. The entire signaling message shall be sent within a single UDP datagram. The source IP address of the P-P Registration-Request message and P-P Registration-Acknowledge messages is set to the Target P-P Address and the destination IP address is set to the Serving P-P Address. The source IP address of the P-P Registration Update-Request and P-P Registration-Reply messages is set to the Serving P-P Address and the destination IP address is set to the Target P-P Address. The initiator of the P-P connection (Target PDSN) shall pick an available source UDP port, and send a P-P Registration-Request message to the desired destination (Serving PDSN) at UDP port 699. The recipient (Serving PDSN) shall send a P-P Registration-Reply message to the initiators (Target PDSN) UDP port that initiated the P-P Registration-Request message. The following indicates the setting of the fields within a P-P Registration signaling message: Care-of address = Target P-P Address (P-P Registration-Request message and Acknowledge message) Home Address = 0.0.0.0 (all) HA Address = Serving P-P Address (P-P Registration-Request message, Reply message, and Update message) MN-HA Authentication Extension = Target PDSN to Serving PDSN MIP Authentication Extension
The procedures to support fast handoff over the R-P interface are defined in [4]. 12.2.2 Bearer Transport The P-P bearer frames shall use the same payload format as used on the R-P interface, specified in [4]. The procedures for selection and use of the GRE key are as outlined in [4].
12.3
P-P Handoff
The P-P interface shall use the P-P Registration-Request message, P-P Registration-Reply message, P-P Registration-Update message, and P-P Registration-Acknowledge message to manage P-P connections. The following sections describe the messages and procedures for the P-P interface. In order to obtain packet data services, the MS performs registration with the packet data network. The service instance(s) is/are assigned and an R-P connection(s) is/are established for each service instance between the Serving RN and the Serving PDSN on behalf of the MS. For multiple service instances, handling of the bearer data streams over the R-P connections is determined according to Section 10.2. During the course of the packet data session, the MS moves into the coverage area of a Target RN, resulting in a hard handoff. The following two sections specify the hard handoff for active and dormant service instances separately.
34
P-P messages use [4]; see corresponding R-P messages. - 73 3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51
3GPP2
This specification assumes that RN specific handoffs move both active and dormant service instances to the Target RN. 12.3.1 Active Service Instances On detection of a condition that a hard handoff is required, the Source RN initiates handoff procedures with the Target RN (via the MSC). If the Serving PDSN is reachable from the Target RN, the fast handoff is performed as specified in [4], and the Serving PDSN shall release: Existing R-P connection(s) to the Source RN if different from the Target RN P-P connection(s) associated with the MS35 as a result of a handoff back from the Target PDSN to the Serving PDSN
If the Serving PDSN is not reachable from the Target RN, the Target RN selects a Target PDSN and establishes one R-P connection for each service instance to that PDSN. The R-P Registration-Request message(s) have the 'S' bit set to indicate bicasting of the bearer payloads and contain the Serving P-P Address, the identity of the MS, and an R-P Connection Setup Airlink Record. The Target PCF also includes an indication in the R-P Registration-Request to indicate if the R-P connection carries the main service instance. The Target PDSN shall immediately respond with an R-P Registration-Reply message that contains the serving P-P address as received in the R-P Registration-Request message. For each R-P connection so established, the Target PDSN attempts to establish a P-P connection to the Serving PDSN with the 'S' bit set (to indicate bicasting of the bearer payloads). The Serving PDSN shall use the SR_ID information in conjunction with the mobile identifier to find the link layer context information associated with the service instance. The Serving PDSN determines whether a P-P connection supports the main service instance to the MS. The Serving PDSN shall apply existing link layer context (e.g., compression, PPP, etc.) when sending packets on the P-P connection. If the Serving PDSN accepts the P-P Registration-Request message, and this P-P connection carries the main service instance, the Serving PDSN shall return a P-P Registration-Reply message with a PPP Link Indicator Extension (see Section 12.6) that indicates that the P-P connection supports the main service instance. The Serving PDSN shall start to bicast bearer data that is appropriately conditioned according to the link layer control to both the Source RN via the R-P connection (see Figure 17), or to the previous Target PDSN via the previous P-P connection (see Figure 19), and the Target PDSN via the P-P connection. The Serving PDSN shall bicast until it receives a P-P Registration-Request with the 'S' bit clear. The Target PDSN shall forward bearer data to the Target RN via the R-P connection. The Target RN discards bearer data until the associated service instance is successfully established. Upon successful handoff of a service instance to the Target RN, the Target RN shall deliver the bearer data from the associated R-P connection to the MS. Also, the Target RN sends an R-P Registration-Request message with the S bit clear and an Active Start Airlink Record to the Target PDSN. The Target PDSN shall forward the Active Start Airlink Record to the Serving PDSN over the just established P-P connection(s) in a P-P Registration-Request message with the 'S' bit clear. Upon reception of P-P Registration-Request messages with the S bit clear, the Serving PDSN shall release the corresponding R-P connections to the Source RN as identified by the SR_ID, or the P-P connections to the previous Target PDSN. In particular, this addresses the case of a new Target PDSN being exactly the same as the currently Serving PDSN. - 74 3GPP2
35
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
3GPP2
The Target and Serving P-P addresses, along with the GRE Key form the unique link layer ID for each P-P connection. With the P-P connection(s) in place, bearer data frames pass over these connection(s) in both directions via GRE framing. In the reverse direction, the Serving PDSN shall accept the P-P frames, process and remove the GRE overhead, and then shall process the GRE payload, as necessary. In the forward direction the Serving PDSN shall encapsulate bearer data frames in GRE. The Target PDSN shall process and remove the GRE overhead before passing the bearer data to the associated R-P connection. On the R-P connection, the Target PDSN shall encapsulate the bearer data frames in GRE and shall forward them to the Target RN. Thus, the Target PDSN shall provide a transparent bi-directional transport for the bearer data frames between the R-P connection and the P-P connection so that there is a point-to-point link layer connection for each service instance between the MS user and the Serving PDSN. The Target PDSN shall maintain the P-P connections by periodically sending P-P RegistrationRequest messages to the Serving PDSN with S bit clear. The lifetime field in the P-P Registration-Request message shall be set to a value large enough to prevent frequent reregistrations. Each P-P connection shall be maintained as long as the corresponding R-P connection exists at the Target PDSN. When all the service instances become dormant, or the MS renegotiates PPP, the fast handoff shall be completed according to Section 12.4.5. 12.3.2 Dormant Service Instances There are two cases to consider when an MS with dormant service instances moves to an RN in a different packet zone: The MS has one or more dormant service instances and no active service instances. The MS has one or more dormant service instances and one or more active service instances.
In the first case, usual dormant handoff procedures apply and there is no fast handoff. In the second case, the active service instances are connected first. Then the Target PDSN receives the R-P Registration-Request messages for the dormant service instances with the 'S' bit cleared from the Target RN, and determines that there is a fast handoff already in progress for the MS. The Target PDSN then shall establish P-P connections for each of the new R-P connections to the Serving PDSN. If the Serving PDSN accepts the P-P Registration-Request message, it shall return a P-P Registration-Reply message with PPP Link Indicator Extension (see Section 12.6) if the P-P connection supports the main service instance.
12.4
Detailed PP Interface Procedures
12.4.1 P-P Connection Establishment When a Target PDSN that supports fast handoff receives an R-P Registration-Request from the Target RN that contains a Serving P-P address, it shall establish a P-P connection to the Serving PDSN. To establish a P-P connection the Target PDSN shall send a P-P Registration-Request message to the Serving PDSN including the R-P Connection Setup Airlink Record36 (as received from the Target RN) and start the timer Tregreq (see [4]). If this timer expires, the Target PDSN shall resend the P-P Registration-Request with R-P connection Setup Airlink Record an operator configurable number of times or until an Active Start Airlink Record is received from the Target RN. In the event all these P-P Registration-Request messages fail, the fast handoff is abandoned and the Target PDSN shall release all P-P connections, if any. The Target PDSN shall negotiate PPP with the MS and shall send its own P-P address to the Target RN as Serving Airlink records are sent over the P-P connection by the use of Critical Vendor/Organization Specific Extension as specified in [4]. - 75 3GPP2
36
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53
3GPP2
P-P address (see [4]).restart PPP over the main service instance, if it received an indication from the Target RN that identifies the main service instance. In the P-P Registration-Request message, the Target PDSN shall set the Home Address field to zero, the HA Address field to the Serving P-P address, and the Care-of Address field to the Target P-P address. The Mobile Identifier, SR_ID, and Target PDSN Session Identifier Key shall be included in the Session Specific Extension. The Target PDSN shall assign a Target PDSN Session Identifier Key for the P-P connection. The Target PDSN Session Identifier Key shall be unique within a Target PDSN entity. The S, T, and G bits shall be set. The Lifetime field shall be set to Tpresetup, whose value is sufficient for the service instance to handoff from the Source RN to the Target RN. The IP source and destination addresses in the IP header shall be set to the Target P-P and the Serving P-P address, respectively. If the P-P Registration-Request message is acceptable, the Serving PDSN shall update the binding record for the MS by creating an association between among the IMSI, SR_ID, the Target PDSN Session Identifier Key, Serving PDSN Session Identifier Key (if asymmetric P-P session identifier keys are supported between the Target PDSN and the Serving PDSN), the Target P-P address, and the Serving P-P address. The Serving PDSN shall indicate to the Target PDSN if the newly established P-P connection is the main service instance by including the PPP Link Indicator Extension with a value of 'main service instance, continuing (0)' in a P-P RegistrationReply message to the Target PDSN. The Serving PDSN shall assign a Serving PDSN Session Identifier Key37 for the P-P connection, if asymmetric P-P session identifier keys are supported between the Target and Serving PDSNs. The Serving PDSN Session Identifier Key is unique within a Serving PDSN entity. The Serving PDSN shall return a P-P Registration-Reply message with an accept indication. In the P-P Registration-Reply message, the Serving PDSN sets the MS Home Address field to zeros. The HA Address fields shall be set to the serving P-P address of the Serving PDSN. The Mobile Identifier, SR_ID and Serving PDSN Session Identifier Key shall be included in the Session Specific Extension. The Lifetime field shall be set to Tpresetup (see [4]), whose value is sufficient for the traffic channel to handoff from the Source RN to the Target RN. The IP source address and the IP destination address in the IP header shall be set to Serving P-P PDSN address and the Target P-PPDSN address, respectively. On receipt of the P-P Registration-Reply message, the Target PDSN shall create a binding record for the MS by creating an association between among the IMSI, SR_ID, the Serving PDSN Session Identifier Key, and the Serving P-P Address information, the and TargetServing PDSN Session Identifier Key, the R-P Interface PDSN Session Identifier Key, the Target PCF Session Identifier Key, and the Target PCF IP address. Bearer data now flows both to the Source RN via the R-P connection and to the Target PDSN over the newly established P-P connections, or for the case of a continuing fast handoff, to the previous Target PDSN via the previous P-P connection and to the Target PDSN over the newly established P-P connection. The Target PDSN shall use the SR_ID and the Mobile Identifier to uniquely identify a packet data service instance for a specific MS across RNs and PDSNs. The GRE keys for the P-P session (i.e., the Target PDSN Session Identifier and Serving PDSN Session Identifier) shall be chosen according to [4]. The Target PDSN shall forward the bearer data to the Target RN via the pre-setup R-P connection. The Target RN discards bearer data until such time the service instances are successfully handed over to it.
37
This is the same as the PCF Session Identifier Key as defined in [4]. - 76 3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
3GPP2
On handoff of the active service instance(s) to the Target RN, the Target RN forwards the Start Airlink Records to the Target PDSN over the pre-setup R-P connection(s), with R-P connection Lifetime set to Trp38 (see [4]) and S bit cleared39. The Target RN also starts periodically reregistering with the Target PDSN before the expiration of the R-P connection Lifetime. If the service instance is not handed over to the Target RN, the pre-setup R-P connection is automatically released on expiry of timer Tpresetup (see [4]). 40 If the P-P connection has been established successfully by the time the Active Start Airlink Record is received from the Target RN, the Target PDSN shall forward the Active Start Airlink Record over the P-P connection to the Serving PDSN. On receipt of the R-P-Registration-Request message with zero lifetime from the Source RN, or a P-P Registration-Request message with zero lifetime from the previous Target PDSN (i.e., as in Figure 19), the Serving PDSN shall stop transport of the user data stream to the Source RN or previous Target PDSN and release the R-P or P-P connection, respectively. Also, following the reception of the Active Stop Airlink Record the Serving PDSN may release the associated R-P connection with the Source RN, or P-P connection to the previous Target PDSN. The Target PDSN shall also start periodically re-registering with the Serving PDSN before the expiration of the P-P connection Lifetime. On receipt of P-P Registration-Request message with S bit not set, the Serving PDSN shall stop transport of the bearer data stream to the Source RN or previous Target PDSN. If the service instances are not all handed over to the Target RN, the Target PDSN shall automatically release the established P-P connections between the Target PDSN and the Serving PDSN on expiry of timer Tpresetup. 12.4.2 P-P Establishment Connection Failure When the Target PDSN receives the R-P Registration-Request from the Target RN, the Target PDSN shall initiate setup of the P-P connections with the Serving PDSN. If the Serving PDSN does not accept the connections, it shall return a P-P Registration-Reply message with a reject result code. Depending on the result code, the Target PDSN may attempt to retry setting up of the P-P connection(s). If the P-P connection(s) cannot be established, the Target PDSN shall abandon P-P connection establishment. If the Target PDSN has knowledge of the main service instance, the Target PDSN should initiate PPP negotiation by sending an LCP Configure-Request over the main service instance. Otherwise, the Target PDSN shall request release of all the R-P connections with the Target RN for this MS. At the time an Active Start Airlink Record is received from the Target RN, if the corresponding PP connection with the Serving PDSN has not yet been established successfully, the Target PDSN shall fail the fast handoff. It shall initiate release of all P-P connections with the Serving PDSN and all R-P connections with the Target RN for this MS. However, if the Target PDSN has knowledge of the main service instance, the Target PDSN should initiate PPP negotiation by sending an LCP Configure-Request over the main service instance. Otherwise, the Target PDSN shall request release of all the R-P connections with the Target RN for this MS.
38 39
Trp is the lifetime of the R-P connection with the 'S' bit clear. 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
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
3GPP2
The P-P Registration-Request message may be retransmitted if no P-P Registration-Reply message is received within a configurable time (TRegreq.). Setup of a P-P connection is considered to have failed if no P-P Registration-Reply message is received after a configurable number of P-P Registration-Request message retransmissions. 12.4.3 P-P Connection Periodic Re-registration The Target PDSN shall periodically refresh the P-P connection with the Serving PDSN by sending a P-P Registration-Request message before P-P connection registration lifetime (Tpp41) expires. The Serving PDSN shall return a P-P Registration-Reply message with an accept indication, including the refreshed Lifetime timer value for the P-P connection. The P-P Registration-Request message may be retransmitted if no P-P Registration-Reply message is received within a configurable time. If no P-P Registration-Replies are received after a configurable number of P-P RegistrationRequest message retransmissions for a P-P connection, the Target PDSN shall renegotiate PPP with the MS, if the PDSN has knowledge of the main service instance, otherwise, the Target PDSN shall immediately release the P-P connections and the R-P connections for the MS. The Serving PDSN shall release the PPP session if there is no P-P or R-P connection supporting the main service instance. 12.4.4 P-P Interface Release Procedures This section provides an overview of the P-P procedures. The complete P-P interface release procedures, such as handling of timers, are identical to the R-P connection release procedures found in [4]. The release of P-P connections can be initiated either by the Target PDSN or the Serving PDSN. 12.4.4.1 P-P Connection Release Target PDSN Initiated The Target PDSN shall initiate the release of a P-P connection if the corresponding R-P connection has been released, or if executing a fast handoff completion. The Target PDSN shall release a P-P connection by sending a P-P Registration-Request message to the Serving PDSN with a lifetime field set to zero. The Target PDSN shall forward any Active Airlink Stop Record received from the Target RN in the P-P Registration-Request message. The Serving PDSN shall remove the binding information for the P-P connection, and returns a P-P Registration-Reply message with a PPP Link Indicator Extension with the appropriate condition. On receipt of the PP Registration-Reply message, the Target PDSN shall remove binding information for the P-P connection and may initiate PPP negotiation on the main service instance to the MS if the value of the PPP Link Indicator Extension is set to one. The Serving PDSN shall release the associated link context and R-P connection (if one exists). If the Target PDSN does not receive a P-P Registration-Reply message after sending a configurable number of P-P Registration-Request message retransmissions, the Target PDSN shall remove the binding information for all the P-P and associated R-P connections for the MS. 12.4.4.2 P-P Connection Release Serving PDSN Initiated The Serving PDSN shall initiate the release of a P-P connection if the MS returns to an RN that can reach the Serving PDSN, or if the PPP inactivity timer expires and the MS is not Always On, or the Serving PDSN closes the PPP session, or if the MS renegotiates or closes PPP, or for administrative reasons. The Serving PDSN may initiate release of a P-P connection by sending a P-P Registration-Update message to the Target PDSN with a termination indication. When the Serving PDSN releases the P-P connections because the MS terminates PPP, the Serving PDSN 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
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
3GPP2
releases the P-P connections because the MS renegotiates PPP, the Serving PDSN shall indicate to the Target PDSN to restart negotiate PPP with a P-P Registration-Update message containing a PPP Link Indicator Extension with a value of 1 (negotiate PPP). In this case, the Target PDSN shall reuse the existing R-P connections to renegotiate the PPP link with the MS. If the P-P connection is released by the serving PDSN without an indication to negotiate PPP, tThe Target PDSN shall release the corresponding R-P connection if one exists. In either case, the Target PDSN shall, remove the binding information for the P-P connection, and return a P-P Registration-Acknowledge message. The Target PDSN shall send a P-P Registration-Request message with a lifetime of zero containing any accounting related information received from the Target RN. On receipt of the P-P Registration-Request message, the Serving PDSN shall respond with a P-P Registration-Reply message and remove binding information for the P-P connection along with any associated link context. If the Serving PDSN does not receive a P-P Registration-Acknowledge message after transmitting a configurable number of P-P Registration-Update messages, the Serving PDSN shall remove the binding information for all the P-P connections for the MS. It shall also initiate release of the associated link layer context for the MS and R-P connections if one exists. 12.4.5 P-P Fast Handoff Completion At some point in time, all connected service instances on the Target RN go dormant. The Target RN includes an all dormant VSE in the R-P Registration-Request sent to the Target PDSN when the last service instance goes dormant. This R-P Registration-Request also contains an Active Stop Airlink Record for that last service instance. The Target PDSN shall in turn forward the "all dormant" VSE and the Active Stop Airlink Record in the P-P Registration Request to the Serving PDSN. The Target PDSN shall initiate PPP negotiation with the MS when it receives an Active Start Airlink Record from the Target PCF. Simultaneously, the Target PDSN shall initiate release of the P-P connections with the Serving PDSN for the MS. The Target PDSN becomes the new Serving PDSN after completing a new PPP session negotiation with the MS. The Target PDSN shall update the Target RN with the new Serving P-P Address (i.e., its own P-P address) in the next R-P Registration-Reply message. This update occurs immediately as a result of an Active Start Airlink Record when the MS transitions from dormant to active as a result of LCP renegotiation. The new Serving PDSN shall use the stored R-P Connection Setup Airlink Record from the original R-P connection establishment for accounting purposes. If the MS desires MIP service after the Target PDSN completes PPP renegotiation, the MS shall perform MIP registration.
12.5
Bicasting Scenarios
Bicasting is temporary and starts at the Serving PDSN upon reception of a R-P or P-P Registration-Request with the 'S' bit set. Unicast of the payload data resumes at the Serving PDSN upon reception of a R-P or P-P Registration-Request with the 'S' bit clear. The following scenarios show bicasting of payload data during fast handoff: 1. 2. 3. 4. Intra PDSN (see Figure 16) Inter PDSN, start of fast handoff (see Figure 17) Intra PDSN, during fast handoff on Target PDSN (see Figure 18) Inter PDSN, during a fast handoff from one Target PDSN to another Target PDSN (see Figure 19).
Cases 1 and 3 are specified in [4].
- 79 -
3GPP2
P.S0001-Bv2.0
3GPP2
Serving PDSN R-P interface A10, A11

RP A1 inte 0, rfa A1 c e 1
bicasting
Source RN
Target RN
1 2 3
Mobile station
Figure 16 - Intra PDSN Handoff
P-P interface Serving PDSN R-P interface A10, A11 Target PDSN R-P interface A10, A11 Target RN Mobile station
bicasting
Source RN
4 5 6
Figure 17 - Inter PDSN, Beginning of Fast Handoff
- 80 -
3GPP2
P.S0001-Bv2.0
3GPP2
P-P interface Serving PDSN Target PDSN R-P interface A10, A11
RP A1 int 0, erf A1 ac 1 e
bicasting
Source RN Target RN
1 2
Mobile station
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
Source RN
Target RN
3 4 5 6
Mobile station
Figure 19 - Inter PDSN Handoff, Continuation of Fast Handoff Between Target PDSNs
- 81 -
3GPP2
P.S0001-Bv2.0
3GPP2
1 2 3 4
12.6
PPP Link Indicator Extension
The format of a normal P-P vendor specific extension is as follows: 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 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
Type: 134 Length: 10 Vendor/Org-ID: 5535 Vendor-NVSE-Type: 16 Vendor-NVSE-Value: 0: main service instance, continuing 1: main service instance, restart negotiate PPP 2: main service instance, do not restart negotiate PPP When the NVSE is present and set to zero, it serves simply to indicate the main service instance. When set to one, it indicates that the PPP session is being renegotiated and the Target PDSN should attempt to negotiate PPP by sending an LCP Configure-Request message to the MS over the main service instance. When set to two, it indicates that the PPP session is closed and the Target PDSN shall not attempt to negotiate the PPPThis VSE shall be present in a P-P Registration-Reply message when the P-P connection for the main service instance is established or released. It signifies that the associated service instance is the main service instance. When the VSE is present and set to zero, it serves simply to indicate the main service instance. When set to one, it indicates that the PPP session is being renegotiated and the Target PDSN should attempt to re-start PPP by sending an LCP Configure-Request message to the MS over the main service instance. When set to two, it indicates that the PPP session is terminating and the Target PDSN should not attempt to restart the PPP session.
- 82 -
3GPP2
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
13 Radio Network Requirements

13.1 General
The PDSN interfaces to the Radio Network only through the R-P interface and there are no RN dependent signaling messages transmitted to the PDSN. However, there are some general requirements placed on the RN: Each RN is connected to at least one PDSN. The RN relays PPP octets between the MS and PDSN. The RN establishes an R-P connection for each MS initiated packet data service instance. If the MS initiates multiple service instances, each R-P connection is directed to the same PDSN. The RN terminates the R-P connection if the MS terminates the corresponding packet data service instance with the service inactive indication. The RN terminates all the R-P connections for the MS if the MS terminates the packet data session with a power down indication. The RN terminates the R-P connection upon request from the PDSN. For some service options, the RN may buffer user data from the PDSN when radio resources are not in place or insufficient to support the flow of data. The RN passes octets between the MS and PDSN without any framing conversion.
Note: No changes to the IP version used in the RN are required in order to support IPv6 MSs, i.e., the IP version used in the RN (including the R-P interface), shall be independent of the IP version of the packets carried in the PPP Sessions.
13.2
R-P Interface Requirements
The PDSN and RN shall support the R-P interface defined as A10 and A11 interfaces of [4]. In order to support fast handoff, the PDSN and the RN will support enhancements to the A10 and A11 interfaces defined in [4] although procedures in [4] only deal with a single service instance. The PDSN shall use sequential numbering in the GRE packet header of packets on the R-P interface, to ensure sequential delivery of packets over the R-P interface, if any of the following events occurs: The PDSN is configured to send GRE packets that contain incomplete PPP frames or multiple PPP frames. The MS negotiates a header or payload compression algorithm that requires PPP frames to be delivered in sequence.
13.3
R-P General Handoff Capabilities
These requirements cover the duration of a packet data session and include periods when the RN does not allocate radio resources to the MS (if such a dormant/standby capability is supported by the RN). The RN has the capability to determine when an MS enters its coverage area. The RN is able to determine with which PDSN an MS currently has a PPP session, if a PPP session already exists. During a packet data session, an MS may move outside the coverage area of one RN into the coverage area of another RN. If the previous and the new RN have connectivity
- 83 -
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11
3GPP2
to the same PDSN, the RNs release and re-establish the R-P session so that it connects the new RN serving the MS and the PDSN in such a way that the MS maintains the same PPP session. During a packet data session, an MS may move outside the coverage area of one RN into the coverage area of another RN. If the previous and the new RN do not have connectivity to the same PDSN, the new RN immediately establishes a new R-P session to a new PDSN.
Specific handoff procedures for the R-P are not called out in this specification but can be found in [4].
- 84 -
3GPP2
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
Annex A: IKE/ISAKMP Payloads

This Annex addresses ISAKMP payloads in which multiple options exist (see RFC 2407-2409). The following requirements shall be met by the PDSN and HA, assuming IP security between the HA and PDSN is required. Payloads in which no options exist do not appear in this Annex. Note: If the HA (home network) does not require any security then Annex A does not apply nor does it apply to MSs using collocated CoA for Mobile IP. ISAKMP Fixed Header The PDSN in this specification shall use a Major and Minor Version of 0. The HA shall minimally accept Major and Minor Version of 0. This specification does not make use of the Fixed Header Authentication (A) bit. Security Association Payload: All Security Association Payloads shall use the IPSec DOI. The Phase 1 ISAKMP Security Payload shall specify a situation of SIT_IDENTITY_ONLY. Phase 2 ISAKMP Security Payloads shall specify a situation of SIT_IDENTITY_ONLY for all cases where privacy or only authentication applies (as outlined in the PDSN and HA "IP Security" sections of this specification). Proposal Payload: Because the MS first makes contact with the PDSN, the PDSN shall be the Initiator of the Phase 1 ISAKMP SA. The HA shall be the Responder. The PDSN shall propose ISAKMP to the HA for the Phase 1 ISAKMP SA. For Phase 2 Quick Mode exchanges, both the PDSN and HA shall be Initiators and Responders because symmetrical, bi-directional security between the PDSN and HA is required. For message authentication, PDSNs conforming to this specification shall propose both AH42 and ESP with the authentication option. The HA shall respond with ESP if the PDSN has proposed it. For message privacy, the PDSN shall propose ESP. For combined authentication and privacy, the PDSN shall propose ESP only. Mobile IP registration control packets and IP in IP tunneled packets may be protected by IPSec authentication, privacy, or both. Security policies to be used between the PDSN and the HA in this specification is dictated by the home network not the access provider network. The PDSN shall be capable of proposing authentication only, privacy only, and both authentication and privacy. Service provider owned HAs shall accept and propose only one of these, and the PDSN shall accept this proposal. The Home RADIUS server may deliver a User Profile to the Visited RADIUS server and PDSN that indicates whether security should be supported for IP in IP packets. If the Home RADIUS server indicates a request for no security on the IP-in-IP tunneled packets, the PDSN shall not delete existing IPSec security associations to the HA. This is because IPSec should be authorized per PDSN-HA pair and thus other MSs may be using those IPSec security associations. The SPI shall be four octets.
Note that a future version of this specification is likely to no longer require AH, in accordance with industry trends. - 85 3GPP2
42
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55
Transform Payload: For Phase 1, the PDSN shall use KEY_IKE as the transform identifier. All implementations shall support 3DES and RSA. For Phase 2 Quick Exchange, the PDSN shall minimally support the ESP_3DES transform identifier within a Transform Payload for IPSec ESP Proposal Payload. It shall also support both HMAC-MD5 and HMAC-SHA1 as transform identifiers within a Transform payload for IPSec AH Proposal Payload. Service provider HAs shall likewise support these two transforms. The PDSN may optionally support and propose other transforms. An HA shall select one of the transforms offered by the PDSN. Key Exchange Payload The PDSN and HA will exchange D-H (Diffie-Hellman) public values computed in the D-H group negotiated as part of a protection suite in the first message exchange of Phase 1 for ISAKMP SA establishment. The PDSN shall specify Phase 1 authentication with certificates when the HA's certificate or HA's root CA certificate is available. Otherwise, if a Dynamic pre-shared IKE secret distributed by the Home RADIUS server is available, the PDSN shall specify Phase 1 authentication with a pre-shared secret mode of operation. In this case, the PDSN shall specify Phase 1 Aggressive mode only. This is necessary in order that the KeyID field can be transmitted in the clear. The Home RADIUS server shall insure that the value of the S key is hard to guess (i.e., a properly generated random number) in order to prevent dictionary attacks that are possible with Aggressive mode. If the PDSN has a statically configured IKE secret for the SA with the HA, then the PDSN shall specify Phase 1 authentication with pre-shared secret mode of operation. In this case the PDSN may either use Main Mode or use Aggressive Mode. Otherwise, if a pre-shared secret is available, the PDSN shall specify Phase 1 authentication with a pre-shared secret mode of operation. The PDSN shall specify Phase 1 Aggressive mode only. It shall not specify Phase 1 Main mode. This is necessary in order that the KeyID field can be transmitted in the clear. The Home RADIUS server shall insure that the value of the S key is hard to guess (i.e., a properly generated random number) in order to prevent dictionary attacks that are possible with Aggressive mode. Identification Payload For Phase 1 negotiation, the PDSN shall set the Protocol-Id field to zero or UDP. The port number shall be set to zero or 500. If the HA receives any other values for these two fields in the Identification Payload, IKE negotiation shall be aborted. For IKE authentication using pre-shared secret the PDSN and HA shall minimally support ID_KEY_ID in the ID Type field. For IKE authentication using Revised Public Key Encryption with RSA using X.509 certificates, the PDSN and HA shall minimally support ID_DER_ASN1_DN in the ID Type field. For Phase 2 (Quick Mode), both the PDSN and HA shall include the client identifiers in the form of optional Client Identification Payloads as specified in IKE (i.e., IDci and IDcr). To apply IPSec on all traffic between the PDSN and the HA, the PDSN and the HA shall exchange IDci and IDcr. The protocol and port number fields shall be dont care by setting them to 0 in both IDci and IDcr. The following is an example of the format of the client identifiers. IDCi: Protocol field = 0, Port = 0, Idtype = ID_IPV4_ADDR, Identification_data = PDSN_IPV4_ADDR.
- 86 -
3GPP2
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46
IDCr: Protocol field = 0, Port = 0, Idtype = ID_IPV4_ADDR, Identification_data = HA_IPV4_ADDR. Two separate Quick Mode negotiations shall be performed to establish two different types of IPSec security associations between the PDSN and HA to protect Mobile IP control messages and tunneled user data. For IPSec security for Mobile IP control packets, the PDSN and HA shall exchange IDci and IDcr. The protocol field shall be set to UDP and port number to 434 for both IDci and IDcr. IDCi: Protocol field = UDP, Port = 434, Idtype = ID_KEY_ID, Identification_data = PDSN_IPV4_ADDR IDCr: Protocol field = UDP, Port = 434, Idtype = ID_KEY_ID, Identification_data = HA_IPV4_ADDR For IPSec on the users tunneled data, the PDSN and the HA shall exchange client identification using a tunnel protocol type that matches the encapsulation type requested by the MSs RRQ. Examples of IDCi and IDCr values when IP-IP tunnel is used are: IDCi: Protocol field = IP-IP, Idtype = ID_KEY_ID, Identification_data = PDSN_IPV4_ADDR IDCr: Protocol field = IP-IP, Idtype = ID_KEY_ID, Identification_data = HA_IPV4_ADDR Certificate Payload The Certificate Payload shall carry X.509 version three certificates. Signature Payload The PDSN and HA shall not include this payload. Notification Payload The Notification Payload carries error messages and reason codes regarding failure for a peer to be able to establish a security association. The PDSN and HA handling of a failed security association establishment is specified in the main body of the standard. The PDSN and HA shall use the "SA Lifetime Notify" code as a trigger to refresh the indicated security association. Delete Payload The PDSN shall send a delete payload upon a SA refresh or upon request from a service provider administrator.
- 87 -
3GPP2
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53
Annex B: Certificates
PDSNs and HAs shall use X.509 Version 3 certificates in conformance with RFC 2459. Each PDSN and HA in a service provider network may have a unique certificate which will be configured into the PDSN and HA. The method of configuration of certificates is outside the scope of this specification. Note: This Annex only applies to FA CoA. Security between a collocated CoA MS and the HA is outside the scope of this specification. Each service provider may be a Certificate Authority for itself and its client private networks and partner ISPs for PDSNs and for HAs that may be accessed by PDSNs. All PDSNs and HAs shall be configured with all service provider CA certificates. There should be one CA root certificate from each service provider. Certificates for PDSNs and HAs The Distinguished Name [RFC 2459] contained in the Issuer field is of form: cdma2000.service-provider-name The PDSN or HA determines the issuing service-provider (i.e., the CA) from the service-providername attribute of the Issuer's Distinguished Name. The PDSN and HA then use the serviceprovider-name attribute to locally access the CA's public key. The PDSN and HA shall use the SHA-1 as a hash function and either the RSA or DSA signing algorithm, as specified in RFC 2459 to verify a certificate. The private network or ISP shall provide the public key and Distinguished Name of the certificate. The Distinguished Name contained in the Subject field is of form: cdma2000. service-provider-name.PDSN.service-provider-identifier cdma2000. service-provider-name.HA.service-provider-identifier Certificates in the PDSN and HA will not use the Unique-Identifier field. Certificate extensions for PDSN and HA certificates shall not be supported. The method of providing PDSNs and HAs signed certificates to PDSNs and HAs is outside the scope of this specification. CA Certificates Service provider CA certificates shall be configured into all PDSNs and HAs. A service provider CA contains the public key that the PDSN or HA shall use to verify the signature of a certificate received in a Phase 1 ISAKMP exchange. A CA certificate shall conform to the X.509 V3 certificates in RFC 2459. Since the service provider CA distributes its own certificate, the Authority Key Identifier and Subject Key Identifier extensions shall not be included in the certificate. The method by which service providers exchange their CA certificates, as well as of providing certificates into PDSNs and HAs, is outside the scope of this specification.
- 88 -
3GPP2
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
Certificate Revocation List (CRL) CRLs shall be used to store the identities of certificates that have been compromised or are otherwise invalid. CRLs shall conform to X.509 v2 as specified in RFC 2459. A future version of this specification may make use of the Online Certificate Status Protocol. Service providers shall exchange revoked certificate information (e.g., serial number). The frequency of the exchange is outside the scope of this specification. Possession of a certificate does not imply service since the RADIUS server and Mobile IP functions still control the user obtaining service, as well as the HA allowing access to the PDSN. The CA certificate shall indicate the service provider CA as Issuer of the CRL. The DN of the Issuer shall be of form: cdma2000.service-provider-name CRLs exchanged between service providers shall use the SHA-1 as a hash function and either the RSA and DSA signing algorithm as specified in RFC 2459. CRL extensions shall not be supported. The method of exchanging CRLs between service providers, or to conveying certificates client private network or partnering ISP, as well providing this information into PDSNs and HAs, is outside the scope of this specification.
- 89 -
3GPP2
P.S0001-Bv2.0
3GPP2
1 2 3 4 5
Annex C: RADIUS Attributes

Figure 20 shows the general Vendor Specific Format for all 3GPP2 RADIUS attributes. The type and vendor ID are the same for every attribute. The vendor ID of 5535 is used to indicate 3GPP2. Note: All integers are in network byte order. 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 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
Figure 20 - 3GPP2 RADIUS Attribute Format IKE Pre-shared Secret Request: Indicates that the PDSN needs a pre-shared secret for Phase 1 IKE negotiation with the HA. This may appear in a RADIUS Access-Request message for MIP, but not for Simple IP. Type: 26 Length = 12 Vendor ID: 5535 Vendor-Type = 1 Vendor-Length = 6 Vendor-Value = 1 - The PDSN requests a pre-shared secret for IKE Security Level: Indicates the type of security that the home network mandates on the visited network; this attribute optionally appears in the RADIUS Access-Accept message. Type: 26 Length = 12 Vendor ID: 5535 Vendor-Type = 2 Vendor-Length = 6 Vendor-Value = 1 - IPSec for registration messages (deprecated) 2 - IPSec for tunnels (deprecated) 3 - IPSec for tunnels and registration messages 4 - No IPSec security Pre-shared secret: A pre-shared secret for IKE that optionally appears in a RADIUS AccessAccept message. Type: 26 Length = 24 Vendor ID: 5535 Vendor-Type = 3 Vendor-Length = 18 Vendor-Value = binary value of the pre-shared secret Reverse Tunnel Specification: Indicates the style of reverse tunneling that is required, and optionally appears in a RADIUS Access-Accept message.
- 90 -
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
3GPP2
Type: 26 Length = 12 Vendor ID: 5535 Vendor-Type = 4 Vendor-Length = 6 Vendor-Value = 0 - Reverse tunneling is not required 1 - Reverse tunneling is required Differentiated Services Class Option: This attribute is deprecated and is replaced by the Allowed Differentiated Services Marking attribute. The Home RADIUS server authorizes differentiated services via the Differentiated Services Class Options attribute, and optionally appears in a RADIUS Access-Accept message. Type: 26 Length = 12 Vendor ID: 5535 Vendor-Type = 5 Vendor-Length = 6 Vendor-Value 0 - Best Effort 10 - AF11 12 - AF12 14 - AF13 18 - AF21 20 - AF22 22 - AF23 26 - AF31 28 - AF32 30 - AF33 34 - AF41 36 - AF42 38 - AF43 46 - EF The above values are taken from RFC 2597 and RFC 2598. There is no intention to convey the actual traffic specification parameters of the differentiated services service. Home Agent: The address of the HA that appears in a RADIUS Access-Request message, RADIUS Access-Accept message, and accounting messages. Type: 26 Length = 12 Vendor ID: 5535 Vendor-Type = 7 Vendor-Length = 6 Vendor-Value = 4 octet IP address
- 91 -
3GPP2
P.S0001-Bv2.0
3GPP2
1 2
Accounting Container: Contains embedded 3GPP2 VSAs and/or RADIUS accounting 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 Type Length Vendor-ID Vendor-ID (cont) Vendor-Type Vendor-Length Container-Reason Event-Timestamp Event-Timestamp Type = 55 Length = 6 Event-Timestamp Value Embedded 3GPP2 AVPsVSAs and/or RADIUS accounting attributes
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
Type: 26 Length >= 224 Vendor-ID: 5535 Vendor-Type: 6 Vendor-Length >= 168 Container-Reason: 1. Tariff Boundary 2. Parameter Change 3. Handoff Event-Timestamp: Value = The Value field is four octets encoding an unsigned integer with the number of seconds since January 1, 1970 00:00 UTC. Embedded 3GPP2 AVPsVSAs and/or RADIUS accounting attributes: One or more parameters relating to Container-Reason above. KeyID: Contains the KeyID parameter used during IKE exchange between the PDSN and the HA. This parameter is returned by the Home RADIUS server to the PDSN in the RADIUS Access-Accept message. Type: 26 Length = 28 Vendor ID: 5535 Vendor-Type = 8 Vendor-Length = 22 Vendor-Value = A number formed from the concatenation of the Home RADIUS IP Address, and the FA IP address, and a 32-bit timestamp, where each address is encoded using eight hexadecimal ASCII characters. The timestamp contains the number of seconds since January 1, 1970 00:00 UTC. S Key: Contains the S secret parameter used to make Pre-shared secret. This parameter is returned by the Home RADIUS to the HA in the RADIUS Access-Accept message. Type: 26 Length: greater than 9 Vendor ID: 5535 Vendor-Type = 54 Vendor-Length = 3 or greater Vendor-Value = binary value of the secret. S lifetime: Contains the lifetime of S secret parameter used to make Pre-shared secret. This parameter is returned by the Home RADIUS to the HA in the RADIUS Access-Accept message. Type: 26 Length = 12 Vendor ID: 5535
- 92 -
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53
3GPP2
Vendor-Type = 56 Vendor-Length = 6 Vendor-Value = Number of seconds since January 1, 1970 00:00 UTC. 'S' Request: Indicates whether the HA requests a shared secret "S". This appears in a RADIUS Access-Request message to the Home RADIUS server: Type: 26 Length = 12 Vendor ID: 5535 Vendor-Type = 55 Vendor-Length = 6 Vendor-Value = 1. The HA requests a 'S' secret for IKE MN-HA shared key: A shared key for MN-HA that optionally appears in a RADIUS AccessAccept message. The MN-HA shared key is encrypted using a method based on the RSA Message Digest Algorithm MD5 [RFC 1321] as described in Section 3.5 of RFC 2868. Type: 26 Length: 26 or greater Vendor ID: 5535 Vendor-Type = 58 Vendor-Length = 20 or greater Vendor-Value = two octets for the salt field as defined in RFC 2868 followed by at least 16 octets containing the binary value of the encrypted MN-HA shared secret MN-HA SPI: The SPI for the MN-HA shared key that optionally appears in a RADIUS AccessRequest message. It is used to request an MN-HA shared key. Type: 26 Length = 12 Vendor ID: 5535 Vendor-Type = 57 Vendor-Length = 6 Vendor-Value = binary value of the MN-HA SPI DNS Update Required: Indicates whether the HA needs to send DNS Update to the DNS server. This optionally appears in a RADIUS Access-Accept message. Type: 26 Length = 12 Vendor ID: 5535 Vendor-Type = 75 Vendor-Length = 6 Vendor-Value = 0 - HA does not need to send DNS Update 1 - HA needs to send DNS Update Remote IPv4 Address: Allows the PDSN to identify an IP address to be used for remote address based accounting for the user. It is only used in RADIUS Access-Accept messages. Up to ten instances of the attribute shall be supported in one RADIUS Access-Accept message.
- 93 -
3GPP2
P.S0001-Bv2.0
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 Type Length Vendor-ID Vendor-ID (cont) Vendor-Type Vendor-Length Subtype (=1) Length Value (Remote IPv4 address) Value (Remote IPv4 address) Subtype (=2) Length Value (remote IPv4 address mask) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Remote IPv6 Address: Allows the PDSN to identify an IP address to be used for remote address based accounting for the user. It is only used in RADIUS Access-Accept messages. Up to ten instances of the attribute shall be supported in one RADIUS Access-Accept message. 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 Subtype (=1) Length Value (Remote IPv6 address) Value (Remote IPv6 address) Value (Remote IPv6 address) Value (Remote IPv6 address) Value (Remote IPv6 address) Subtype (=2) Length Value (Prefix length) 26 27 28 29 30 31 32 33 34 35 36 37 Type: 26 Length = 32 Vendor ID: 5535 Vendor-Type: 70 Vendor-Length =26 Subtype (=1): type for remote IPv6 address attribute of value 1 Length: length of remote IPv6 address attribute (=18 octets) Remote IPv6 Address: The Remote IPv6 Address field contains a corresponding IPv6 address to be used for remote address based accounting for the user. Subtype (=2): type for prefix length of value 2 Type: 26 Length = 20 Vendor ID: 5535 Vendor-Type: 59 Vendor-Length = 14 Subtype (=1): type for remote IPv4 address attribute of value 1 Length: length of remote IPv4 address attribute (=6 octets) Remote IPv4 Address: The Remote IPv4 Address sub-attribute contains an IPv4 address to be used for remote address based accounting for the user. The address is used in conjunction with the Remote Address Mask (below), to define the range of address to be monitored. Subtype (=2): type for remote IP address mask of value 2 Length: length of remote IP address mask attribute (=6 octets) Remote Address Mask: The Remote Address Mask sub-attribute contains an IPv4 address mask that defines a set of remote addresses to be used for remote address based accounting.
- 94 -
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9
3GPP2
Length: length of prefix length attribute (=4) Prefix Length: The prefix length specifies the number of leading bits that must be matched. The prefix length is less than or equal to 128. Remote Address Table Index: Contains the index to remote addresses used to generate remote address accounting records. The Home RADIUS server returns this parameter to the PDSN in the RADIUS Access-Accept message. 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 Reserved Remote Address Table Index
10 11 12 13 14 15 16 17 18 19 20 21 22 23
Type: 26 Length =12 Vendor ID: 5535 Vendor-Type: 71 Vendor-Length =6 Remote Address Table Index: The Table Index is an identifier to a table of remote addresses, available at the PDSN, used for remote-based accounting for the user. Remote IPv4 Address Octet Count: This attribute indicates an IPv4 address and how many bytes have been received from and sent to this address over the course of the service being provided to the user. It is only present in RADIUS Accounting-Records where the Acct-StatusType is set to Stop or Interim. 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 Subtype (=1) Length Value (Remote IPv4 address) Value (Remote IPv4 address) Subtype (=2) Length 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 27 28 29 30 31 32 33 34 35 36 37 38
Type: 26 Length =32 Vendor ID: 5535 Vendor-Type: 72 Vendor-Length =26 Subtype (=1): type for remote address attribute of value 1 Length: length of remote address attribute (variable: 6 octets for IPv4 and 18 octets for IPv6) Remote Address: The Remote Address Field contains an IPv4 or IPv6 address used for destination-based remote address based accounting by the user. Subtype (=2): type for remote IP address mask of value 2 Length: length of remote IP address mask attribute (=6 octets)
- 95 -
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
3GPP2
Remote Address Mask: The Remote Address Mask sub-attribute contains an IPv4 address mask that defines a set of remote addresses to be used for remote address based accounting. Subtype (=3): type for forward octet count attribute of value 3 Length: length of forward octet count attribute (6 octets) Forward Octet Count: The Forward Octet Count Field indicates how many bytes have been received from the Remote Address. Subtype (=4): type for reverse octet count attribute of value 4 Length: length of forward octet count attribute (6 octets) Reverse Octet Count: The Reverse Octet Count Field indicates how many bytes have been sent to the Remote Address. Remote IPv6 Address Octet Count: This attribute indicates an IPv6 address and how many bytes have been received from and sent to this address over the course of the service being provided to the user. It is only present in RADIUS Accounting-Records where the Acct-StatusType is set to Stop or Interim. 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 Subtype (=1) Length Value (Remote IPv6 address) Value (Remote IPv6 address) Value (Remote IPv6 address) Value (Remote IPv6 address) Value (Remote IPv6 address) Subtype (=2) Length Value (Prefix length) Subtype (=3) Length Value (forward octet count) Value (forward octet count) Subtype (=4) Length Value (reverse octet count)
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41
Type: 26 Length = 44 Vendor ID: 5535 Vendor-Type: 9780 Vendor-Length =38 Subtype (=1): type for remote address attribute of value 1 Length: length of remote address attribute (variable: 6 octets for IPv4 and 18 octets for IPv6) Remote Address: The Remote Address Field contains an IPv4 or IPv6 address used for destination-based remote address based accounting by the user. Subtype (=2): type for prefix length of value 2 Length: length of prefix length attribute (=4) Prefix Length: The prefix length specifies the number of leading bits that must be matched. The prefix length is less than or equal to 128. Subtype (=3): type for forward octet count attribute of value 3 Length: length of forward octet count attribute (6 octets) Forward Octet Count:
- 96 -
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12
3GPP2
The Forward Octet Count Field indicates how many bytes have been received from the Remote Address. Subtype (=4): type for reverse octet count attribute of value 4 Length: length of forward reverse octet count attribute (6 octets) Reverse Octet Count The Reverse Octet Count Field indicates how many bytes have been sent to the Remote Address. Allowed Differentiated Services Marking: Specifies if the user is able to mark packets with AF (A), EF (E). The Max Class (i.e., Max Selector Class), specifies that the user may mark packets with a Class Selector Code Point that is less than or equal to Max Class. 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 Subtype (=1) Length A E O Unused Subtype (=2) Length Max class Unused Subtype (=3) Length RT marking Unused
13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
Type: 26 Length = 20 Vendor ID: 5535 Vendor-Type: 73 Vendor-Length = 14 Subtype (=1): flags for Allowed Diffserv class Length: 3 flags (= 4 octets) "A" bit set means the user can send packets with AF DSCPs "E" bit set means the user can send packets with EF DSCP "O" bit set means the use can mark packets for experimental or local use Subtype (=2): Max class selection marking Length: (=4 octets) Value: See Reverse tunnel marking Subtype (=3): Reverse tunnel marking Length: (= 4 octets) RT-Marking: '000000' = Default or Best Effort Forwarding, also Selector Class 0 '001010' = AF11 '001100' = AF12 '001110' = AF13 '010010' = AF21 '010100' = AF22 '010110' = AF23 '011010' = AF31 '011100' = AF32 '011110' = AF33 '100010' = AF41 '100100' = AF42 '100110' = AF43 '101110' = EF '001000' = Selector Class 1 '010000' = Selector Class 2 '011000' = Selector Class 3 '100000' = Selector Class 4
- 97 -
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
3GPP2 '101000' = Selector Class 5 '110000' = Selector Class 6 '111000' = Selector Class 7
Other six bit long patterns are legal for this attribute, but are not standardized and therefore may have unpredictable behavior in public networks and other networks not configured to accept non-standard markings Service Option Profile: This attribute specifies the authorized packet data service options, the respective number of simultaneous service instances of the given service option number (n), and the total maximum number of simultaneous service instances. This attribute may appear in a RADIUS Access-Accept message. 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 T Type Length Vendor-ID y Vendor-ID (cont) Vendor-Type Vendor-Length p Max service instances total e Subtype (=1) Length Service Option n Max number of : service instances of Service Option n 2 Length >=16 Vendor ID: 5535 Vendor-Type: 74 Vendor-Length >=10 Maximum Service Instances: The maximum number of service instances the user is allowed to establish regardless of the service option numbers. '1' represents one service instance, i.e., the main service instance. '0' is not an allowed value. Subtype (=1): type for service option Length: length for service option attribute in octets (4 octets) Service Option number Maximum Service instances for this service option \ Subtype 1 may be repeated, once for each authorized service option. Always On: Attribute indicating if the user has the Always On service or not. Type: 26 Length = 12 Vendor ID: 5535 Vendor-Type = 78 Vendor-Length = 6 Vendor-Value = 0 - Inactive 1 - Active Foreign Agent Address: The IPv4 address of the PDSN CoA contained in RRQ. Type: 26 Length =12 Vendor ID: 5535 Vendor-Type = 79 Vendor-Length = 6 Vendor-Value =
- 98 -
3GPP2
P.S0001-Bv2.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 FA IPv4 Address
3GPP2
MN-AAA Removal Indication: When received in a RADIUS Access-Accept, the PDSN shall not include the MN-AAA Authentication and MN-FA challenge extensions when relaying the RRQ to the HA. Type: 26 Length = 12 Vendor ID: 5535 Vendor-Type = 81 Vendor-Length = 6 Vendor-Value = 1 - MN-AAA not required DNS Server IP Address: This VSA may be present in a RADIUS Access-Accept message. It includes a Primary and a Secondary DNS server IP addresses. 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 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 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44
Type: 26 Length: 28 Vendor ID: 5535 Vendor-Type: 117 Vendor-Length: 22 Sub-Type (=1): Length: (=4 octets) Vendor-Value: Primary DNS server IP Address. Sub-Type (=2): Length: (= 4 octets) Vendor-Value: Secondary DNS server IP Address. Sub-Type (=3): Flag Length: (=1 octet) Vendor-Value: "M bit set to 1 indicates to the PDSN that the Primary and Secondary DNS IP addresses provided by the Home RADIUS server shall override the Primary and Secondary DNS addresses if provided also by the Visited RADIUS server. Sub-Type (=4): Length: (=1 octet) Vendor-Value: Entity-Type The network entity that inserted in the DNS server IP address. Currently the following types are defined: HAAA = 1 VAAA = 2
- 99 -
3GPP2
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10
Annex D: 3GPP2 VSAs Table

The following table provides a guide to the 3GPP2 vendor specific attributes that may be found in the Access Request/Reply and Accounting Request messages (following the RADIUS standard approach). The entries in the table are defined as follows: 0 0+ 0-1 1 Parameter This attribute shall not be present. Zero or more instances of this attribute may be present. Zero or one instance of this attribute may be present. Exactly one instance of this attribute shall be present. Type Acces sReque st 0-1 0 0 0 0 0 0-1 0 0 0 0 0 0 0 0 0 0 0 0 0-11 0 0 0 0 0 0 Access ReplyA ccept 0 0-1 0-1 0-1 0-1 0 0-1 0-1 0 0 0 0 0 0 0 0 0 0 0 0 0-1 0 0 0 0 0 Accounting Start 0 0 0 0 0 0 0-1 0 1 1 0-1 0-1 0-1 1 0-1 0-1 0-1 0-1 0-1 1 0-1 0 0 0 0 0 Accounting Stop 0 0 0 0 0 0+ 0-1 0 1 1 0-1 0-1 0-1 1 0-1 0-1 0-1 0-1 0-1 1 0-1 1 0-1 1 0-1 0-1 Accounting Interim 0 0 0 0 0 0+ 0-1 0 1 1 0-1 0-1 0-1 1 0-1 0-1 0-1 0-1 0-1 1 0-1 0 0-1 1 0-1 0-1
IKE Pre-shared Secret Request Security Level Pre-shared Secret Reverse Tunnel Specification Differentiated Services Class Option Container Home Agent KeyID Serving PCF BSID User Zone Forward Mux Option Reverse Mux Option Service Option Forward Traffic Type Reverse Traffic Type Fundamental Frame Size Forward Fundamental RC Reverse Fundamental RC IP Technology Compulsory Tunnel Indicator Release Indicator Bad PPP Frame Count Number of Active Transitions SDB Octet Count (Terminating) SDB Octet Count
26/01 26/02 26/03 26/04 26/05 26/06 26/07 26/08 26/09 26/10 26/11 26/12 26/13 26/16 26/17 26/18 26/19 26/20 26/21 26/22 26/23 26/24 26/25 26/30 26/31 26/32
- 100 -
3GPP2
P.S0001-Bv2.0
3GPP2
(Originating) Number of SDBs (Terminating) Number of SDBs (Originating) IP Quality of Service Airlink Priority Airlink Record Type Airlink Sequence Number Number of HDLC layer bytes received Correlation ID Mobile Originated / Mobile Terminated Indicator Inbound Mobile IP Signaling Octet Count Outbound Mobile IP Signaling Octet Count Session Continue Active Time DCCH Frame Format Beginning Session ESN S Key S Request S Lifetime MN-HA SPI MN-HA Shared Key Remote IPv4 Address Reserved Remote IPv6 Address Remote Address Table Index Remote IPv4 Address Octet Count Allowed Differentiated Services Marking Service Option Profile DNS Update Required Always On Foreign Agent
26/33 26/34 26/36 26/39 26/40 26/42 26/43 26/44 26/45 26/46 26/47 26/48 26/49 26/50 26/51 26/52 26/54 26/55 26/56 26/57 26/58 26/59 26/6069 26/70 26/71 26/72 26/73 26/74 26/75 26/78 26/79
0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0-1 0 0-1 0 0
0 0 0 0 0 0 0 0-1 0 0 0 0 0 0 0 0 0-1 0 0-1 0 0-1 0+
0 0 0-1 0-1 0 0 0 1 0-1 0 0 0 0 0-1 0-1 0-1 0 0 0 0 0 0
0-1 0-1 0-1 0-1 0 0 0-1 1 0-1 0-1 0-1 1 0-1 0-1 0 0-1 0 0 0 0 0 0
0-1 0-1 0-1 0-1 0 0 0-1 1 0-1 0-1 0-1 0-1 0-1 0-1 0 0-1 0 0 0 0 0 0
0 0 0 0 0 0 0 0-1
0+ 0+ 0 0-1 0-1 0-1 0-1 0
0 0 0 0 0 0 0-1 0
0 0 0+ 0 0 0 0-1 0
0 0 0+ 0 0 0 0-1 0
- 101 -
3GPP2
P.S0001-Bv2.0
3GPP2
Address Remote IPv6 Address Octet Count MN-AAA Removal Indication MEID DNS Server IP Address 1
26/978 0 26/81 26/116 26/117
0 0 0 0
0 0-1 0 0+
0 0 0-1 0
0+ 0 0-1 0
0+ 0 0-1 0
- 102 -
3GPP2
P.S0001-Bv2.0
3GPP2
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Annex E: Interim RADIUS Accounting

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

Cdma2000 Wireless IP Network Standard: 3GPP2 P.S0001-B Version Date: September, 2004

Uploaded by

Document Information

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

Cdma2000 Wireless IP Network Standard: 3GPP2 P.S0001-B Version Date: September, 2004

Uploaded by

Copyright:

Available Formats

1 2 3 4

3GPP2 P.S0001-B Version 2.0 Version Date: September, 2004

cdma2000 Wireless IP Network Standard

cdma2000 Wireless IP Network Standard

cdma2000 Wireless IP Network Standard

cdma2000 Wireless IP Network Standard

cdma2000 Wireless IP Network Standard

cdma2000 Wireless IP Network Standard

cdma2000 Wireless IP Network Standard

P.S0001 Revision History

cdma2000 Wireless IP Network Standard

cdma2000 Wireless IP Network Standard

2 Glossary and Definition

cdma2000 Wireless IP Network Standard

cdma2000 Wireless IP Network Standard

cdma2000 Wireless IP Network Standard

cdma2000 Wireless IP Network Standard

cdma2000 Wireless IP Network Standard

cdma2000 Wireless IP Network Standard

cdma2000 Wireless IP Network Standard

cdma2000 Wireless IP Network Standard

cdma2000 Wireless IP Network Standard

cdma2000 Wireless IP Network Standard

4 Protocol Reference Models

4.1 Network Reference Models

MSC Visited Access Provider Network (serving)

HLR Home Access Provider network

RADIUS Home IP network

R-P interface A10, A11

RADIUS Serving PDSN P-P interface Broker network

Figure 1 - Reference Model for Simple IP Access

cdma2000 Wireless IP Network Standard

MSC Visited Access Provider Network (serving)

HLR Home Access Provider network

RADIUS Home IP network

R-P interface A10, A11 Source RN Serving PDSN P-P interface

RADIUS Broker network

HA Home IP network Private network Home access provider network

cdma2000 Wireless IP Network Standard

Link Layer R-P PL R-P PL PL

Figure 3 - Protocol Reference Model for Simple IP Access

Link Layer R-P PL

PDSNtarget P-P Interface

cdma2000 Wireless IP Network Standard

IKE MIP UDP IP IP/ IPsec

IKE UDP IP/ IPsec

PPP LAC/ RLP MAC Airlink LAC/ RLP MAC Airlink

PPP Link Layer R-P PL R-P PL PL PL Link Layer

Figure 5 - Protocol Reference Model for Mobile IP Control and IKE

cdma2000 Wireless IP Network Standard

PPP LAC/ RLP MAC Airlink

PDSNtarget P-P Interface

cdma2000 Wireless IP Network Standard

PPP LAC/ RLP MAC Airlink LAC/ RLP MAC Airlink

R-P Sig. UDP IP

R-P Signaling UDP IP Link Layer PL

P-P Sig. IPsec Link Layer

UDP IP IPsec Link Layer PL

UDP Link Layer PL

PDSN serving P-P Interface

Figure 9 - Protocol Reference Model for Signaling for Fast Handoff

cdma2000 Wireless IP Network Standard

L2 Relay LAC MAC Airlink GRE IP