Escolar Documentos
Profissional Documentos
Cultura Documentos
S0001-B
2 Version 2.0
3 Version Date: September, 2004
5 cdma2000 Wireless IP
6 Network Standard
10
11
12
13
14
COPYRIGHT
3GPP2 and its Organizational Partners claim copyright in this document and individual Organizational
Partners may copyright and issue documents or standards publications in individual Organizational
Partner's name based on this document. Requests for reproduction of this document should be
directed to the 3GPP2 Secretariat at secretariat@3gpp2.org.Requests to reproduce individual
Organizational Partner's documents should be directed to that Organizational Partner. See
www.3gpp2.org for more information.
15
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 Revision History
2
3 Revision Date
4 Rev. 0 Initial Publication November 2002
5 Rev. A Revision A of P.S0001 May 2001
6 Rev. B Version 1 of P.S0001 Revision B September 2002
7 Rev. B v2.0 Version 2 of P.S0001 Revision B September 2004
- ii - 3GPP2
1 CONTENTS
2
3 1 INTRODUCTION...................................................................................................................... 1
- iv - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
-v- 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 Figures
2
3 Figure 1 - Reference Model for Simple IP Access ........................................................................ 12
4 Figure 2 - Reference Model for Mobile IP Access......................................................................... 13
5 Figure 3 - Protocol Reference Model for Simple IP Access .......................................................... 14
6 Figure 4 - Protocol Reference Model for Simple IP Access During Fast Handoff ........................ 14
7 Figure 5 - Protocol Reference Model for Mobile IP Control and IKE ............................................ 15
8 Figure 6 - Protocol Reference Model for Mobile IP Bearer Data .................................................. 16
9 Figure 7 - Protocol Reference Model for MIP Control and IKE During Fast Handoff.................... 16
10 Figure 8 - Protocol Reference Model for MIP Bearer Data During Fast Handoff.......................... 17
11 Figure 9 - Protocol Reference Model for Signaling for Fast Handoff ............................................ 17
12 Figure 10 - Protocol Reference Model for User Data for Fast Handoff......................................... 18
13 Figure 11 - RADIUS Protocol Reference Model............................................................................ 18
14 Figure 12- NVSE for DNS server IP address ................................................................................ 45
15 Figure 13 - Graphical Illustration of Multiple Connection Relationships ....................................... 52
16 Figure 14 - Accounting Architecture .............................................................................................. 55
17 Figure 15 - Accounting Architecture With Fast Handoff ................................................................ 57
18 Figure 16 - Intra PDSN Handoff .................................................................................................... 80
19 Figure 17 - Inter PDSN, Beginning of Fast Handoff ...................................................................... 80
20 Figure 18 - Intra PDSN, Continuation of Fast Handoff on Target PDSN ...................................... 81
21 Figure 19 - Inter PDSN Handoff, Continuation of Fast Handoff Between Target PDSNs............. 81
22 Figure 20 - 3GPP2 RADIUS Attribute Format ............................................................................... 90
23
24
- vi - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 Tables
2
3 Table 1 - Occurrence of RADIUS Attributes for Simple IP ............................................................ 24
4 Table 2 – Home Agent and Home Address Scenarios ................................................................. 30
5 Table 3 – Description of Scenarios ............................................................................................... 31
6 Table 4 – Occurrence of RADIUS Attributes for Mobile IP............................................................ 40
7 Table 5 – MS Registration Scenarios............................................................................................ 43
8 Table 6 – R-P Connection Setup Airlink Fields ............................................................................. 58
9 Table 7 – Active Start Airlink Fields............................................................................................... 59
10 Table 8 – Active Stop Airlink Fields............................................................................................... 59
11 Table 9 – SDB Airlink Fields.......................................................................................................... 59
12 Table 10 – Complete UDR ............................................................................................................ 61
13 Table 11 – Accounting Parameter Attribute RADIUS Definitions.................................................. 65
14
- vii - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
- viii - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 1 Introduction
2 This specification defines requirements for support of wireless packet data networking capability
3 on a third generation wireless system based on cdma2000®1. This specification supports the
4 services and architecture in [1].
5
6 This specification defines the two methods for accessing public networks (Internet) and private
7 networks (intranets): Simple IP and Mobile IP. It describes the required Quality of Service,
8 Security, Mobility Management, and Accounting capabilities needed to support both methods.
9 IETF protocols are widely employed whenever possible to minimize the number of new protocols
10 required and to maximize the utilization of well accepted standards.
11
12 This specification is organized in the following structure:
13
14 • Sections 2 and 3 are the Glossary and Definitions, and References, respectively.
15 • Section 4 describes the protocol reference models for Simple IP, Mobile IP, RADIUS, and
16 the overall wireless packet data network.
17 • Sections 5 and 6 describe Simple IP operation and Mobile IP operation, respectively.
18 • Section 7 describes simultaneous Mobile IP and Simple IP services.
19 • Section 8 describes IP Reachability Service.
20 • Section 9 describes Mobility Management for PCF-PCF handoff, PDSN-PDSN handoff,
21 and PDSN-PDSN Fast Handoff.
22 • Section 10 describes Quality of Service requirements and operation.
23 • Section 11 describes Accounting architecture and parameters.
24 • Sections 12 and 13 describe the P-P Interface, and Radio Network Requirements,
25 respectively.
26
27 In this document, several key words are used to signify the requirements. The key words "shall",
28 "shall not", "should", "should not", and "may" are to be interpreted as described in RFC 2119 and
29 the TIA Engineering Style Manual.
30
1
cdma2000® is the trademark for the technical nomenclature for certain specifications and
standards of the Organizational Partners (OPs) of 3GPP2. Geographically (and as of the date of
publication), cdma2000® is a registered trademark of the Telecommunications Industry
Association (TIA-USA) in the United States.
-1- 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
2 2.1 Acronyms
3 AAA Authentication, Authorization, and Accounting
4 ACCM Asynchronous Control Character Map
5 AH Authentication Header
6 AVP Attribute Value Pair
7 BS Base Station
8 CA Certificate Authority
9 CCP Compression Control Protocol
10 CHAP Challenge Handshake Authentication Protocol
11 CoA Care-of address
12 CRL Certificate Revocation List
13 CSRC Contributing Source
14 D-H Diffie-Hellman
15 DN Distinguished Name
16 DNS Domain Name System
17 DSA Digital Signature Algorithm
18 DOI Domain Of Interpretation
19 ESP Encapsulating Security Payload
20 FA Foreign Agent
21 FAC Foreign Agent Challenge
22 GRE Generic Routing Encapsulation
23 HA Home Agent
24 HAAA Home AAA
25 HDLC High-level Data Link Control
26 HLR Home Location Register
27 HRPD High Rate Packet Data
28 IANA Internet Assigned Numbering Authority
29 IETF Internet Engineering Task Force
30 IKE Internet Key Exchange
31 IMSI International Mobile Subscriber Identity
32 IMT-2000 International Mobile Telecommunications - 2000
33 IP Internet Protocol
34 IPv4 Internet Protocol version 4
35 IPv6 Internet Protocol version 6
36 IPCP IP Control Protocol
37 ICMP Internet Control Message Protocol
38 IPv6CP IPv6 Control Protocol
39 IPSec IP Security
40 IRM International Roaming MIN
41 IRS IP Reachability Service
42 ISAKMP Internet Security Association and Key Management Protocol
43 ISP Internet Service Provider
44 LAC Link Access Control
45 LCP Link Control Protocol
46 MAC Medium Access Control
47 MEID Mobile Equipment Identifier
48 MIN Mobile Identification Number
49 MIP Mobile IP
50 MS Mobile Station
51 MSID Mobile Station ID
52 NAI Network Access Identifier
-2- 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
42 2.2 Definitions
43
44 A Resource Record:
45 The A resource record type is a record specific to the Internet class that stores a single
46 IPv4 address.
47
48 AAAA Resource Record:
49 The AAAA resource record type is a record specific to the Internet class that stores a
50 single IPv6 address.
-3- 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 Always On:
2 The Always On Service maintains the subscriber's packet data session in the local
3 network (i.e., for Always On service, the PDSN shall not initiate release of the
4 subscriber's packet data session, unless the PDSN determines the user is no longer
5 reachable).
22 Default Treatment:
23 The default treatment is the header and payload compressions that are applied to a
24 packet by PPP. The particular compression technique for a given packet is chosen from
25 the set of techniques negotiated during IPCP and CCP.
26 Fast Handoff:
27 An inter PDSN based low latency hard handoff between PCFs. Fast handoff between
28 two PDSNs allows a mobile’s PPP session to be maintained via a layer two tunnel
29 passing through a Target PDSN to the Serving PDSN. Note: There is also an intra
30 PDSN fast handoff that is described in [4] that is outside the scope of this specification.
31 Handoff:
32 In this specification the term "handoff" is defined to mean continuity of IP bindings or PPP
33 link layer state during an interface change from one entity to another. In the absence of
34 any continuity of state whatsoever, this specification does not refer to such interface
35 changes as "handoffs".
36 Home RADIUS:
37 The RADIUS server that resides in the Home IP Network.
38 HAAA:
39 The AAA server that resides in the Home IP Network.
43 Home Address:
44 An MS IP address that remains unchanged regardless of the MS's point of attachment to
45 the network.
-4- 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 Home IP Network:
2 The home network that provides IP based data services to the user. This network is
3 where the user's NAI is homed. This network may be a private network, publicly
4 accessible ISP network, or a cdma2000 wireless network.
33 Point of Attachment:
34 Point of attachment refers to the node where the MS is connected to access the IP
35 network. In the context of this specification, it refers to the PDSN entity.
36 Pi:
37 Pi is the interface between the PDSN and the public Internet.
38 P-P Connection:
39 A connection between a Serving and Target PDSN that uses a GRE tunnel to transport
40 user data for a single service instance during fast handoff.
41
42 P-P Interface:
43 The interface between the Target PDSN and the Serving PDSN that is used to support
44 fast handoff.
45 P-P Session:
46 The set of all P-P connections for a single MS.
-5- 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 PPP Session:
2 A PPP session describes the time during which the main service instance is maintained
3 between the MS and the Serving PDSN. The PPP session is maintained while the MS is
4 dormant. If a user hands off from one RN to another RN but is still connected to the
5 same PDSN, the PPP session remains.
6 Private Address:
7 An IP address conforming to RFC 1918.
8 Private Network:
9 An IP Network that resides behind a firewall and that may use private IP addresses.
10 RADIUS:
11 The specific AAA server implementation used in cdma2000 networks for AAA
12 functionality. The RADIUS servers may be located in the Home IP Network, the Broker
13 Network, or the Visited Access Provider Network.
14 Radio Network:
15 The RN is equivalent to the BS and the PCF as defined in the Network Reference Model
16 [14]. In this specification, the terms PCF and RN are used interchangeably when
17 describing handoffs across the R-P interface. The RN is equivalent to the Radio Access
18 Network (RAN) specified in [4].
19 R-P Connection:
20 A connection between a PCF and a PDSN that uses a GRE tunnel to transport user data
21 for a single packet data service instance. This is equivalent to the A10 connection
22 specified in [4].
23 R-P Interface:
24 The interface between the PCF and PDSN that transports user packet data and signaling
25 messages, as specified in [4].
26 R-P Network:
27 An IP network as defined in [4] connecting the RNs with the PDSNs.
28
29 R-P Session:
30 The R-P session is a collection of R-P connections for a single MS and is equivalent to a
31 Packet Data Session as specified in [4].
32 Service Instance:
33 A connection between an MS and PDSN used to transport user data for a packet data
34 service. Associated with each service instance is a packet data service option, a service
35 reference identifier (SR_ID), and an R-P connection. This specification defines two
36 categories of service instances, a main service instance and an auxiliary service
37 instance.
38 Serving PDSN:
39 A PDSN that supports the PPP session to an MS.
-6- 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 Target PDSN:
2 A PDSN that co-operates with a Target RN over the R-P interface, and co-operates with
3 the Serving PDSN over the P-P interface to provide link layer tunneling between the
4 Serving PDSN and the Target RN in the context of a fast handoff.
16 Visited RADIUS:
17 The RADIUS server that resides in the Visited Access Provider Network.
18
-7- 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 3 References
3 3.13.1.1 IETF
4 RFC 768, Postel, User Datagram Protocol, August 1980.
5
6 RFC 791, Internet Protocol, Sept. 1981.
7
8 RFC 792, Postel, Internet Control Message Protocol, September 1981.
9
10 RFC 793, Transmission Control Protocol, September 1981.
11
12 RFC1034, Mockapetris, Domain Names - Concepts and Facilities, November 1987.
13
14 RFC 1035, Mockapetris, Domain Names - Implementation and Specification, November 1987.
15
16 RFC 1122, Braden, Requirements for Internet Hosts - Communication Layers, October 1989.
17
18 RFC 1144, Jacobson, Compressing TCP/IP Headers for Low Speed Serial Links, February 1990.
19
20 RFC 1321, Rivest and Dusse, The MD5 Message-Digest Algorithm, MIT Laboratory for Computer
21 Science, RSA Data Security Inc., April 1992.
22
23 RFC 1332, McGregor, The PPP Internet Protocol Control Protocol (IPCP), May 1992.
24
25 RFC 1661, Simpson, The Point-to-Point Protocol (PPP), July 1994.
26
27 RFC 1662, Simpson, PPP in HDLC-like Framing, July 1994.
28
29 RFC 1886, Thompson, Huitema, DNS Extensions to Support IP Version 6, December 1995.
30
31 RFC 1877, Cobb, PPP Internet Protocol Control Protocol Extensions for Name Server
32 Addresses, December 1995.
33
34 RFC 1889, Schulzrinne, Casner, Frederick, Jacobson, RTP: A Transport Protocol for Real-Time
35 Applications, January 1996.
36
37 RFC 1918, Rekhter, Moskowitz, Karrenberg, de Groot, Lear, Address Allocation for Private
38 Internets, February 1996.
39
40 RFC 1962, Rand, The PPP Compression Control Protocol (CCP), June 1996.
41
42 RFC 1974, Friend, Simpson, PPP Stac LZS Compression Protocol, August 1996.
43
44 RFC 1979, Woods, PPP Deflate Protocol, August 1996.
45
46 RFC 1994, Simpson, PPP Challenge Handshake Authentication Protocol (CHAP), August 1996.
47
48 RFC 2002, Perkins, IPv4 Mobility, May 1995.
49
50 RFC 2003, Perkins, IP Encapsulation within IP, October 1996.
51
-8- 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
-9- 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1
2 RFC 2484, Zorn, PPP LCP Internationalization Configuration Option, January 1999.
3
4 RFC 2486, Aboba, Beadles, The Network Access Identifier, January 1999.
5
6 RFC 2507, Degermark, Nordgren, Pink, IP Header Compression, February 1999.
7
8 RFC 2597, Heinanen, Baker, Weiss, Wroclawski, Assured Forwarding PHB Group, June 1999.
9
10 RFC 2598, Jacobson, Nichols, Poduri, An Expedited Forwarding PHB, June 1999.
11
12 RFC 2784, Farinacci et al, Generic Routing Encapsulation (GRE), March 2000.
13
14 RFC 2794, Calhoun, Perkins, Mobile NAI Extension, March 2000.
15
16 RFC 2865, Rigney, Willens, Reubens, Simpson, Remote Authentication Dial In User Service
17 (RADIUS), June 2000.
18
19 RFC 2866, Rigney, RADIUS Accounting, June 2000.
20
21 RFC 2868, Zorn et al., RADIUS Attributes for Tunnel Support, June 2000.
22
23 RFC 2890, Dommety, Key and Sequence Number Extensions to GRE, September 2000.
24
25 RFC 2983, Black, Differentiated Services and Tunnels, October 2000.
26
27 RFC 3006, Davie, Iturralde, Oran, Casner, Wroclawski, Integrated Services in the Presence of
28 Compressible Flows, November 2000.
29
30 RFC 3012, Calhoun, Perkins, Mobile IPv4 Challenge/Response Extensions, November 2000.
31
32 RFC 3024, Montenegro, Reverse Tunneling for Mobile IP, January 2001.
33
34 RFC 3041, Narten, Draves, Privacy Extensions for Stateless Address Autoconfiguration in IPv6,
35 January 2001.
36
37 RFC 3095, Borman, et al, Robust Header Compression (ROHC): Framework and four profiles:
38 RTP, UDP, ESP, and uncompressed, July 2001.
39
40 RFC 3162, Zorn et al., RADIUS and IPv6, August 2001.
41
42 RFC 3241, Borman, ROHC over PPP, January 2002.
43 3.1.2 3GPP2
44 [1] P.R0001cdma2000 Wireless IP Architecture Based on IETF Protocols, December 2000.
45
46 [2] N.S0017, International Implementation of Wireless Telecommunication Systems Compliant
47 with TIA/EIA-41, December 2000.
48
49 [3] TIA/EIA-553, Mobile Identification Number (MIN).
50
51 [4] A.S0017-0, 3GPP2 Access Network Interfaces Interoperability Specification, November 2001.
52
53 [5] C.S0001-A Introduction for cdma2000 Standards for Spread Spectrum Systems, June 2000.
54
- 10 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 [6] C.S0002-A, Physical Layer Standard for cdma2000 Standards for Spread Spectrum Systems,
2 June 2000.
3
4 [7] C.S0003-A, Medium Access Control (MAC) Standard for cdma2000 Standards for Spread
5 Spectrum Systems, June 2000
6
7 [8] C.S0004-A, Signaling Link Access Control (LAC) Standard for cdma2000 Standards for
8 Spread Spectrum Systems, June 2000.
9
10 [9] C.S0005-A, Upper Layer (Layer 3) Signaling Standard for cdma2000 Standards for Spread
11 Spectrum Systems, June 2000.
12
13 [10] C.S0016-A, Over-the-Air Service Provisioning of Mobile Stations in Wideband Spread
14 Spectrum Systems, December 2001.
15
16 [11] C.S0017-0-2, Data Service Options for Spread Spectrum Systems – Addendum 2, August
17 2000.
18
19 [12] TIA/EIA/IS-751N.S0009, TIA/EIA-41-D Modifications to Support IMSI, February 1998.
20
21 [13] TIA/EIA/TSB58-E, Administration of Parameter Value Assignments for cdma2000 Spread
22 Spectrum Standards, January 2002.
23
24 [14] TIA/EIA/TSB100-A, TR-45 Wireless Network Reference Model (NRM), March 2001.
25
26 [15] TIA/EIA/IS-856-1C.S0024 v3.0, cdma2000 High Rate Packet Data Air Interface Specification
27 - Addendum 1, December 2001January 2002.
28 3.1.3 TIA
29 [3] TIA/EIA-553-A, Mobile Station – Base Station Compatibility Standard, October 1999.
30 3.33.2 ITU-T
31 ITU-T Recommendation E.212, The International Identification Plan for Mobile Terminals and
32 Mobile Users.
33
34 ITU-T Recommendation X.509, Public-key and Attribute Certificate Frameworks.
35 3.3 Informative
36 3.3.1 3GPP2
37 [1] P.R0001cdma2000 Wireless IP Architecture Based on IETF Protocols, December 2000.
38
39 [2] N.S0017, International Implementation of Wireless Telecommunication Systems Compliant
40 with TIA/EIA-41, December 2000.
41
42 [13] C.R1001-D v1.0, Administration of Parameter Value Assignments for cdma2000 Spread
43 Spectrum Standards, April 2003.
44
45 [14] S.R0005-B, Network Reference Model (NRM) for cdma2000 Spread Spectrum Systems,
46 May 2001.
47
48
- 11 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
SS7 Network
MSC HLR
A1
RADIUS RADIUS
IP Network
Home IP network
Pi
R-P interface
A10, A11 RADIUS
Serving PDSN
Source RN Broker network
P-P interface
Pi
R-P interface
A10, A11
Mobile station Target PDSN
Target RN
Visited Access Provider
Network (target)
18
19
20
21 Figure 1 - Reference Model for Simple IP Access
- 12 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
SS7 Network
MSC HLR
A1
RADIUS RADIUS
IP Network
Home IP network
Pi
R-P interface
A10, A11 RADIUS
Serving PDSN
Source RN Broker network
P-P interface
Pi
R-P interface HA
A10, A11
Home IP network
Mobile station Target PDSN Private network
Target RN
Home access provider
Visited Access Provider
network
Network (target)
1
2
3
4 Figure 2 - Reference Model for Mobile IP Access
5
6 The MS is implemented as a single MT0 type device or as a MT2 and a TE2 pair. See [11] for
7 details.
8
9 Although Mobile IP and Simple IP services are represented in different protocol reference
10 models, the network shall provide both Simple IP and Mobile IP service simultaneously to an MS
11 using the same PPP session for IPv4. For IPv6 MSs, the network shall provide Simple IP
12 service. The network shall support IPv4 and IPv6 MSs simultaneously. The network shall
13 provide Simple IPv4 and/or Simple IPv6 service for the same MS over the same PPP session.
14 Support of IPv6 MSs in the network shall be independent of the IP version used for transport in
15 the RN.
16 4.2 Simple IP
17 Figure 3 shows the protocol reference model for Simple IPv4 or IPv6 service. Figure 4 shows the
18 protocol reference model for Simple IP access during fast handoff.
19
- 13 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
IP IP IP
PPP PPP
Link Link
LAC/ LAC/ Layer Layer
RLP RLP
R-P R-P
MAC MAC
Airlink Airlink PL PL PL PL
Mobile End
RN PDSN
Station Host
1
2
3 Figure 3 - Protocol Reference Model for Simple IP Access
4
IP IP IP
PPP PPP
Link Link
LAC/ LAC/ Layer Layer
RLP RLP R-P P-P
R-P P-P
MAC MAC
Airlink Airlink PL PL PL PL PL PL
End
MS RN PDSNtarget PDSN serving
Host
P-P
Interface
5
6
7
8 Figure 4 - Protocol Reference Model for Simple IP Access During Fast Handoff
9
10 4.3 Mobile IP
11 Figure 5 and Figure 6 show the protocol reference model for Mobile IP control and user data,
12 respectively. IPSec is required in some situations, and not in other situations, as detailed in
13 Section 6.2.4.
14
- 14 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
IP/ IP/
IP IP
IPsec IPsec
PPP PPP
Link Link
LAC/ LAC/ Layer Layer
RLP RLP
R-P R-P
MAC MAC
Airlink Airlink PL PL PL PL
Mobile
RN PDSN HA
Station
1
2
3 Figure 5 - Protocol Reference Model for Mobile IP Control and IKE
4
- 15 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
IP IP IP IP
IP/IPsec IP/IPsec
Airlink Airlink PL PL PL PL PL PL
Mobile End
RN PDSN HA Host
Station
2
3
4 Figure 6 - Protocol Reference Model for Mobile IP Bearer Data
5
6 The protocol architecture for Mobile IP control and user data during fast handoff is illustrated in
7 Figure 7 and Figure 8, respectively.
8
I IP / IP /
IP P IPsec IPsec
PPP PPP
Link Link
LAC/ LAC/ Layer Layer
RLP RLP P-P
R-P R-P P-P
MAC MAC
Airlink Airlink PL PL PL PL PL PL
MS RN PDSNtarget PDSNserving HA
P-P
Interface
9
10
11 Figure 7 - Protocol Reference Model for MIP Control and IKE During Fast Handoff
12
- 16 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
IP IP
IP IP
IP/IPsec IP/IPsec
PPP PPP
Link Link Link Link
LAC/ LAC/ Layer Layer Layer Layer
RLP RLP
R-P R-P P-P P-P
MAC MAC
Airlink Airlink PL PL PL PL PL PL PL PL
Mobile RN HA End
PDSN target PDSN serving
Station Host
P-P
Interface
1
2
3 Figure 8 - Protocol Reference Model for MIP Bearer Data During Fast Handoff
4
5
6 Figure 9 and Figure 10 respectively show the protocol reference models for fast handoff. IKE
7 and IPSec are optional on the P-P interface.
8
9
Airlink PL PL PL PL PL
10
11
12 Figure 9 - Protocol Reference Model for Signaling for Fast Handoff
13
14
- 17 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
RN PDSNtarget PDSNserving
1
2
3 Figure 10 - Protocol Reference Model for User Data for Fast Handoff
4
5 4.4 RADIUS
6 Figure 11 shows the protocol reference model for the RADIUS entities in the wireless network (as
7 illustrated in Figure 1 and Figure 2) between the PDSN (RADIUS client) and the Home RADIUS
8 server. In this model, the RADIUS servers in the visited network communicate with the RADIUS
9 servers in the home network via zero or more optional proxy (or Broker) RADIUS servers.
10
11 A RADIUS server may run IPv4, IPv6, or both. The method of interworking between IPv4 and
12 IPv6 RADIUS clients and servers is outside the scope of this specification.
13
IP IP IP IP IP IP
PL PL PL PL PL PL
14
15
16 Figure 11 - RADIUS Protocol Reference Model
17
- 18 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 5 Simple IP Operation
2 This section describes the requirements and procedures for Simple IP operation for both IPv4
3 [RFC 791] and IPv6 [RFC 2460]. In this specification, Simple IP refers to a service in which an
4 MS is assigned an IP address and is provided IP routing service by an access provider network.
5 The MS retains its IP address as long as it is served by a radio network that has connectivity to
6 the address assigning PDSN. There is no IP address mobility beyond this PDSN. Secure
7 access to a home network via Simple IP is beyond the scope of this specification.
34 5.2.1.1 Establishment
35 When the first R-P connection for the main service instance is established, the PDSN2 shall send
36 an LCP Configure-Request for a new PPP session to the new MS. If an RN opens an R-P
37 connection for which a PPP session already exists, the PDSN shall not send an LCP Configure-
38 Request message to the MS.
39
40 PPP shall support transparency in accordance with Section 4.2 of RFC 1662. The PDSN shall
41 attempt to negotiate a control character mapping with the minimum number of escaped
42 characters by proposing an ACCM of 0x00000000.
2
As specified in Section 12, at fast handoff establishment, a Target PDSN does not send PPP
control messages over new R-P connections.
- 19 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 5.2.1.2 Termination
2 The PDSN shall clear the PPP state if there is no established R-P or P-P session for the MS.
3 The PDSN shall clear the R-P and/or P-P session whenever the PPP session is closed or
4 expired. If the PDSN receives IP packets for an MS for which there is no established PPP
5 session, the PDSN shall silently discard the packet. The PDSN shall close the R-P and
6 associated P-P session whenever the MS closes the PPP session.
7
8 The PDSN may receive the Always On attribute with value ‘1’ from the HAAA in order to activate
9 the Always On service for a user. To implement Always On service for a user, the PDSN shall
10 utilize the expiration of the PPP inactivity timer and the procedures described in Section 5.2.1.8 to
11 determine if the PPP session should be closed.
12
13 If Always On service is not enabled and the PPP inactivity timer for a PPP session expires, the
14 PDSN shall close the PPP session.
- 20 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
3
This is an exception to RFC 2461 necessary to optimize applicability over the cdma2000
wireless air-interface.
4
This may cause an exception to RFC 2461 as it may put the interval outside the normal range.
This exception is allowed by this specification to optimize IPv6 RA over the cdma2000 wireless
links.
5
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
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
28 5.2.1.55.2.1.6 Compression
29 The PDSN shall support the following header compression algorithms:
30
31 • Van Jacobson TCP/IP header compression [RFC 1144]
32
33 The PDSN may support the following header compression algorithms:
34
35 • ROHC, Framework and four profiles: RTP, UDP, ESP, and uncompressed [RFC 3095]
36 with ROHC over PPP [RFC 3241]
37 • IP Header compression [RFC 2507]
38
39 The PDSN shall support CCP [RFC 1962] for the negotiation of PPP payload compression. The
40 PDSN shall support the following types of PPP compression:
41
42 • Stac-LZS [RFC 1974];
43 • Microsoft Point-To-Point Compression Protocol [RFC 2118];
44 Deflate [RFC 1979]
45
46 The PDSN may support other PPP payload compression algorithms.
- 22 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1
2 For IPv6, the PDSN shall allow an information field at least as large as the minimum link MTU
3 size required for IPv6 (1280 octets, or a total PPP frame size minimum MTU of 1286 octets).
- 23 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
- 24 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1
2 • International Mobile Subscriber Identity (IMSI) [E.212]
3 • Mobile Identification Number (MIN) [3]
4 • International Roaming MIN (IRM) [2]
5
6 The PDSN shall store the constructed NAI into accounting records, and the realm value may
7 optionally be used by the Visited RADIUS server to forward these records to the correct Home
8 RADIUS Server for proper summary and settlement11. The constructed NAI shall not be used for
9 authentication. If configured by the operator, the PDSN shall send RADIUS accounting
10 messages to the Visited RADIUS server using the constructed NAI in the absence of CHAP or
11 PAP.
- 25 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 server shall forward the RADIUS Access-Request message to the home network or a peer (e.g.,
2 a broker) if it does not have the authority to accept/deny the request. This is in accordance with
3 RFC 2865. Upon receiving a RADIUS Access-Request message, the Home RADIUS server
4 shall send a RADIUS Access-Accept message or Access-Reject message to the Broker or
5 Visited RADIUS server. The Visited RADIUS server shall send the received response to the
6 PDSN.
7
8 The PDSN shall send RADIUS Accounting-Request records to the Visited RADIUS server in
9 accordance with RFC 2866. The PDSN may also send Interim Accounting records between the
10 Accounting-Request Start and Stop messages as necessary in accordance with Annex E. The
11 Visited RADIUS server shall forward the RADIUS accounting records to the home or broker
12 network.
13
14 The security of communications between RADIUS servers may optionally be protected with IP
15 security. The establishment of the security association is outside the scope of this specification.
16 See RFC 2865 for additional RADIUS security requirements.
17 5.4 MS Requirements
18 The MS may optionally support Simple IP. The MS may choose Simple IP for IPv4 only, IPv6
19 only, or both IPv4 and IPv6 simultaneously. The MS shall access the cdma2000 packet data
20 service using the cdma2000 air interface [5-9] or HRPD [15].
23 5.4.1.1 Establishment
24 The MS shall exchange LCP messages as described in RFC 1661.
25
26 PPP shall support control escaping in accordance with 4.2 of RFC 1662. The PPP Link Layer
27 shall support negotiation of Asynchronous Control Character Mapping as defined in RFC 1662.
28 The MS should negotiate a control character mapping. If the MS negotiates control character
29 mapping, it should attempt the minimum number of escapes by negotiating an ACCM of
30 0x00000000.
31 5.4.1.2 Termination
32 When the MS deactivates packet data service, the MS should send an LCP Terminate-Request
33 message to the PDSN to gracefully close the PPP session before releasing the packet data
34 service option connections with the RN.
35 5.4.1.3 Authentication
36 The MS shall support CHAP authentication for Simple IP. However, the network operator may
37 configure an MS not to use CHAP. In that case, the MS shall be permitted to skip over the CHAP
38 phase by sending a Configure-Reject message to the PDSN in response to a LCP Configure-
39 Request message that offers the CHAP option.
40
41 The MS may support PAP authentication for Simple IP. If the MS uses PAP, it shall respond to
42 an LCP Configure-Request message for CHAP with an LCP Configure-Nak proposing PAP.
43
44 For both CHAP and PAP, the MS shall send an NAI in the form of user@realm.
- 26 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 The MS may implement RFC 1877 in order to auto configure DNS server IP addresses. The MS
2 may negotiate Primary and Secondary DNS server IP addresses during the IPCP phase. The
3 MS may use default of zero for DNS server address negotiation.
- 27 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 After establishment of a PPP link with the PDSN, the MS shall treat that PDSN as the default
2 router until the PPP session is closed.For IPv6, the MS shall support:
3
4 IPv6 over PPP (or IPv6CP) [RFC 2472]
5 Neighbor discovery for IPv6 [RFC 2461]
6 The IPv6 addressing architecture [RFC 2373]
7 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [RFC 3041]
8 IPv6 stateless address auto-configuration [RFC 2462].
9
10 For IPv6, the MS shall perform interface-identifier negotiation as described in RFC 2472. When
11 the interface-identifier is negotiated in the IPv6CP phase of the PPP connection setup, the MS
12 should not perform duplicate address detection. The MS may also use additional (multiple)
13 identifiers, including randomly generated identifiers in support of RFC 3041.
14
15 The MS shall construct the link-local IPv6 address by pre-pending the link-local prefix FE80: /64
16 [RFC 2373] to the interface identifier received during the IPv6CP negotiation phase [RFC 2472].
17 The MS shall construct the global and site-local IPv6 addresses by pre-pending the prefixes
18 received from the Router Advertisements to the interface identifier received during the IPv6CP
19 negotiation phase [RFC 2472].
20
21 Following the successful IPv6CP phase and establishment of link-local address, the MS may
22 initiate router solicitation messages if a router advertisement has not been received from the
23 PDSN. Upon reception of router advertisements from the PDSN, the MS shall perform address
24 auto-configuration for site-local and global addresses.
25
26 Global and site-local addresses are 128 bit addresses formed by appending the interface
27 identifier to a prefix of appropriate length [RFC 2373].
28 5.4.1.5 Compression
29 The MS shall support Van Jacobson TCP/IP header compression [RFC 1144]. The MS
30 additionally may support the following header compression algorithms:
31
32 • IP Header Compression [RFC 2507]
33 • ROHC over PPP [RFC 3241]
34 • ROHC Framework and four profiles: RTP, UDP, ESP, and uncompressed [RFC 3095]
35
36 The MS shall use IPCP and/or IPv6CP to negotiate with the PDSN one or more header
37 compression capabilities.
38
39 The MS shall support the PPP Compression Control Protocol [RFC 1962]. The MS may support
40 PPP payload compression. If the MS intends to use PPP payload compression, the MS shall use
41 PPP Compression Control Protocol to negotiate a PPP payload compression algorithm supported
42 by the MS.The MS shall support the PPP Compression Control Protocol [RFC 1962]. If the MS
43 uses PPP payload compression, the MS shall use PPP Compression Control Protocol to
44 negotiate a PPP payload compression algorithm, and the MS shall support one of the following
45 compression algorithms:
46 Stac-LZS [RFC 1974]
47 Microsoft Point-To-Point Compression Protocol [RFC 2118]
48 Deflate [RFC 1979]
49
50 The MS may support additional PPP payload compression algorithms.
- 28 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
15
If the MS consists of a laptop and a relay-model handset, the laptop may send inter-frame time
fill that prevents the mobile from becoming dormant.
- 29 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
18 6.1.2 Mobile IP
19 The following standards shall be used for Mobile IPv4 operations with any limitations or
20 extensions described in this specification:
21
22 • RFC 2002-2006;
23 • Reverse Tunneling [RFC 3024];
24 • Foreign Agent Challenge/Response [RFC 3012];
25 • NAI Extension [RFC 2794].
- 30 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
Scenarios Description
Scenario 1 This is for dynamic Home Address assignment and a dynamic HA
assignment.
Scenario 2 In this scenario, the Home RADIUS server shall assign an appropriate HA to
the MS. The Home RADIUS server may use the specified Home Address to
select an HA for the MS.
Scenario 3 This corresponds to dynamic Home Address assignment and static HA
assignment.
Scenario 4 This is for static HA and static Home Address MIP registration, i.e., there is no
dynamic assignment.
1
2 Table 3 – Description of Scenarios
3
4 For details on dynamic HA assignment see the following:
5
6 • Section 6.2.2.4 for the PDSN
7 • Section 6.3.4 for the HA
8 • Section 6.4.1 for the Home RADIUS server
9 • Section 6.5.2.2 for the MS.
14 6.2.1.1 Establishment
15 See Section 5.2.1.1.
16 6.2.1.2 Termination
17 The Serving PDSN shall close the PPP session if there is no established underlying R-P session
18 or P-P session for the MS, respectively. The PDSN shall clear the R-P session and P-P session,
19 whenever the PPP session is closed. If the PDSN receives IP packets for an MS for which there
20 is no established PPP session for the MS, the PDSN shall silently discard the packet.
21
22 If the PDSN receives a failure code in the RRP from the HA, then the PDSN shall deliver the RRP
23 to the MS, and shall not close the PPP session before a configurable timer expires. If the PDSN
24 generates a failure code, the PDSN shall deliver the RRP to the MS and shall not close the PPP
25 session before a configurable timer expires.
26
27 For Mobile IP service, the PPP inactivity timer shall be set to a value larger than the FA’s
28 maximum allowable values for Mobile IP registration lifetime. Satisfying this requirement may
29 imply over-riding the PDSN's configured PPP Idle Timeout value (attribute 28 in RFC 2865) for
30 this MS with the value received in the RADIUS Access-Accept message.
31 6.2.1.3 Authentication
32 The PDSN shall initially propose CHAP in an LCP Configure-Request message to the MS. The
33 PDSN shall re-send an LCP Configure-Request message without the authentication option after
34 receiving the LCP Configure-Reject (CHAP or PAP) from the MS.
- 31 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 the PDSN. If the MS includes an IP-Address Configuration Option in the IPCP Configure-
2 Request to the PDSN, the PDSN considers this as an MS using Simple IP service. In this case,
3 the PDSN shall send an IPCP Configure-NAK with a new proposed IP address for the MS. The
4 MS should then send an IPCP Configure-Request with the new IP address.
5
6 The PDSN shall not support RFC 2290. If the MS uses the Mobile IPv4 Configuration Option
7 [RFC 2290], the PDSN shall reply with an IPCP Configure-Reject message.
8
9 The PDSN shall implement the IPCP configuration options as defined in RFC 1877 for DNS
10 server address negotiation. The PDSN shall negotiate Primary and Secondary DNS server IP
11 addresses with the MS, if DNS Server Configuration options are received during the IPCP phase.
12 6.2.1.5 Compression
13 See Section 5.2.1.6.
- 32 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 For dynamic Home Address assignment, the PDSN shall acquire the Home Address from the
2 Mobile IP RRP. In order to provide public network access and to provide private network access
3 across the Internet, the PDSN shall use a publicly routable and visible IP address.
- 33 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 addresses, even if the direct delivery mode is used. See Reverse Tunneling [RFC 3024] for an
2 explanation of direct and encapsulated delivery styles.
3
4 The PDSN shall support both direct delivered and encapsulated packets.
- 34 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 may also be supported for the protection of Mobile IP control messages and user data. This
2 specification supports the following options for the establishment of such additional SAs:
3
4 • Public certificates16
5 • Dynamic pre-shared IKE secret distributed by the Home RADIUS Server
6 • Statically configured IKE pre-shared secret.
7
8 The PDSN shall support IPSec and IKE. An SA between the PDSN and the HA may be
9 established using X.509 based certificates, or a pre-shared secret for IKE that may be statically
10 configured or dynamically provisioned by the Home RADIUS server. ESP is preferred and shall
11 be implemented. AH shall also be implemented in order to maintain backwards compatibility with
12 previous versions of this specification.
13
14 In the case of a carrier owned HA, and if mandated by carrier policy, the PDSN shall have a SA
15 with the HA in order for a RRQ to be successfully processed. The SA may formally be via IPSec
16 (i.e., ESP or AH) or via a Mobile IP HA-FA Authentication Extension.
17
18 An SA between the PDSN and the HA shall be established as follows:
19
20 When receiving a MIP RRQ containing a unicast HA IP address, the PDSN shall verify if a SA
21 currently exists with the HA. If an SA does not exist and one is required, the PDSN shall verify if
22 HA X.509 certificates exists. If no HA X.509 certificate exists, the PDSN shall verify if a root
23 certificate exists. If the necessary certificates do not exist, the PDSN shall verify if a statically
24 configured pre-shared secret for IKE exists. If the static pre-shared secret for IKE is also not
25 available, it shall include a request for a pre-shared secret for IKE in the RADIUS Access-
26 Request message. The Home RADIUS server shall include the pre-shared secret for IKE and a
27 KeyID in the RADIUS Access-Accept message if IPSec services are authorized for the user.
28
29 When dynamic HA assignment is used by the MS (scenario 1 and 2 from Section 6.1.3), the
30 PDSN shall always request the IKE pre-shared Secret from the Home RADIUS server. IPSec
31 support for dynamic HA assignment is further described in Section 6.2.4.2.
16
Refer to Annex A and B for details.
- 35 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 If reverse tunneling is required and IPSec security is authorized for tunneled data, then the PDSN
2 shall provide security on the reverse tunnel.
3
4 If the PDSN does not receive the Security Level attribute from the Home RADIUS server, and an
5 IPSec SA to the HA already exists, the PDSN shall continue to use the same SA. If it receives a
6 new pre-shared key and an SA already exists, the PDSN shall not renegotiate the ISAKMP SA. If
7 no SA exists, then the PDSN shall follow local security policy.
8
9 If an IPSec SA to protect control messages already exists with the HA, the PDSN shall ensure
10 the IPSec SA is maintained throughout the Mobile IP registration lifetime by periodically
11 refreshing the SA.
- 36 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 IP address, the PDSN shall discard the packets and shall send an LCP Configure-Request
2 message to the MS to renegotiate the PPP session.See section 5.2.3 as it relates to IPv4.
19
Construction of the message is implementation dependent.
- 37 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 The HA shall save the MN-HA shared key received from the Home RADIUS server for the
2 duration of the MIP session with the MS. Based on the local policy, the HA may store the MN-HA
3 shared key a certain time skew after releasing the mobility binding for the MS.
20
The skew serves to solve the case where RADIUS or IKE messages are lost and must be
transmitted yet the 'S' Key expires in the meantime. An example of the skew could be one
minute.
- 38 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1
2 However, the Home RADIUS server may encrypt the 'S' Key and the 'S' Lifetime using a method
3 based on the RSA Message Digest Algorithm MD5 [RFC 1321] as described in Section 3.5 of
4 RFC 2868.
5
6 If mandated by carrier security policy, a carrier HA shall have a SA with the PDSN in order for a
7 registration request to be successfully processed. The SA may formally be via IPSec (e.g., ESP
8 or AH) or via a Mobile IP HA-FA Authentication Extension. Likewise, a HA shall accept or reject
9 a RRQ received directly from an MS with a 'D' bit set depending on security policy.
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 cdma2000 Wireless IP Network Standard
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 3GPP2 cdma2000 Wireless IP Network Standard
42 6.5.1.1 Establishment
43 Same as Section 5.4.1.1.
44 6.5.1.2 Termination
45 Same as Section 5.4.1.2.
- 41 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1
2 When the MS tries to register and receives an RRP message with a failure code, it shall do one
3 of the following:
4
5 • Retry Mobile IP registration over the existing PPP session.
6 • If existing Simple IP or Mobile IP sessions exist, give up on the failed Mobile IP
7 registration and continue using the existing sessions.
8 • Fall back to Simple IP by re-negotiating the PPP session.
9 • Terminate the PPP session.
10 6.5.1.3 Authentication
11 The MS should not use CHAP or PAP for Mobile IP. When the MS receives an LCP Configure-
12 Request message requesting CHAP authentication, the MS should reply with an LCP Configure-
13 Reject message requesting no PPP authentication. The PDSN shall re-send an LCP Configure-
14 Request message without the authentication option after receiving the LCP Configure-Reject
15 message from the MS. The MS shall respond with an LCP Configure-Ack message as described
16 in RFC 1661.
17
18 If CHAP is performed, performance degradation will occur as the result of an unnecessary AAA
19 traversal.
20
21 FAC shall be performed regardless of whether or not CHAP is performed. The MS shall use the
22 challenge received in the Agent Advertisement or RRP to compute the MN-AAA authenticator.
23
24 As a further clarification to RFC 3012 section 8 (SPI For RADIUS AAA Servers):
25
26 If the challenge has fewer than 238 bytes, this algorithm includes the high-order byte in the
27 computation twice, but ensures that the challenge is used exactly as is. Additional padding is
28 never used to increase the length of the challenge; the input data is allowed to be shorter
29 than 237 bytes long.
41 6.5.1.5 Compression
42 Same as Section 5.4.1.5.
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 cdma2000 Wireless IP Network Standard
- 43 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 MS may also register directly with the HA using a collocated CoA obtained from Simple IP IPCP
2 negotiation.
3
4 If the MS desires reverse tunneling, the MS shall set the T-bit in the RRQ message.
5
6 The MS shall not set the 'V' bit in the RRQ message.
23 6.5.2.5 Termination
24 When the MS wishes to terminate a MIP session, the MS may send a Mobile IP RRQ to the HA
25 with a Registration Lifetime of zero to gracefully close the MIP session before terminating the
26 packet data service with the RN26.
26
The MS should send the RRQ with a lifetime of zero to free resources such as public
addresses in the HA.
- 44 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
- 45 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 7 Simultaneous Service
2 The PDSN shall support, and the MS may support, any of the following simultaneous packet data
3 session combinations:
4
5 • Simple IPv4 service & Simple IPv6 service
6 • Simple IPv4 service & Mobile IPv4 service
7 • Simple IPv6 service & Mobile IPv4 service
8 • Simple IPv4 service & Simple IPv6 service & Mobile IPv4 service
9
10 Additionally, multiple Mobile IPv4 sessions may be operated simultaneously. Although any of
11 these may run simultaneously, individual services are distinct. Within a single PPP session, the
12 PDSN shall support simultaneous operation of IPCP [RFC 1332] and IPv6CP [RFC 2462].
13 Simultaneous services are supported through re-negotiation of IPCP, IPv6CP, or MIP as
14 appropriate.
15
16 Each packet data sessions shall be authenticated and authorized independently. In addition,
17 each such session shall have unique accounting records. However, simultaneous Simple IPv4
18 and Simple IPv6 share a common authentication and authorization procedure as described in
19 Section 5.2.2.
20
- 46 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 8 IP Reachability Service
2 IP Reachability Service is the capability to update a DNS server in the home network with the
3 current authorized MS IP address. When the MS desires to be reached by a DNS hostname,
4 the Home RADIUS server (in the case of Simple IP or Mobile IP) or the HA (in the case of
5 Mobile IP only) may send a DNS Update [RFC 2136] to a DNS server to add an A Resource
6 Record.
7 The Update section of the DNS Update message contains the following values in ‘Host
8 address’ Resource Type Resource Record:
9
10 • Resource Name = username.realm27
11 • Resource Class = Internet address class
12 • IP Address = newly assigned IP address
13 The TTL (Time To Live) of the Update section in the DNS Update message should be zero so
14 that all queries for the address are resolved using the up to date authoritative server for the
15 user. This is because after the MS is assigned a different address, if the TTL were non-zero,
16 the cache entry of the querying endpoint would no longer be valid, and, in fact, the address
17 may have been given to a different MS.
18
19 The security between the DNS Server and Home RADIUS server or the HA is outside the scope
20 of this specification.
21
22 The method used by the Home RADIUS server and/or HA to determine the IP address of the
23 DNS server is outside the scope of this specification.
24
25 Multiple registrations for the same NAI shall not be permitted if the home network supports IRS
26 for the MS.
27
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 3GPP2 cdma2000 Wireless IP Network Standard
1 MS. The Home RADIUS server caches the User Name, NAS IP Address, and Framed IP
2 address as received in the Accounting-Request (Start) record for the MS. If the “beginning
3 session” attribute is not included in the Accouting-Request (Start) record, the Home RADIUS
4 server shall not update the DNS server.
5
6 If the Home RADIUS server receives a RADIUS Accounting-Request (Stop) record containing the
7 IP-Technology attribute that indicates Mobile IP and that is associated with a previously cached
8 User Name, NAS IP Address, and Framed IP address, and the Session-Continue attribute is
9 either FALSE or absent, the Home RADIUS server shall request that the DNS server delete the
10 Resource Record for the MS.
- 48 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 9 Mobility Management
- 49 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 described later in Section 12. If the MS was in dormant state, the MS transitions to active state
2 for the purpose of establishing connectivity with the new PDSN.
3
4 The PDSN to PDSN link for supporting fast handoff is called the P-P interface. Fast handoff with
5 the P-P interface is used to keep the PPP session anchored when the PDSN to PDSN handoff is
6 performed. This interface prevents the existing PPP session from being re-negotiated, thereby
7 reducing service interruption time and data loss. The forward traffic received at the Serving
8 PDSN is tunneled through the appropriate P-P connection to the Target PDSN. The Target
9 PDSN then forwards the traffic to the MS over the corresponding R-P connection. The reverse
10 traffic from the MS is tunneled through the P-P interface from the Target PDSN to the Serving
11 PDSN. The Serving PDSN then forwards the traffic to the external network.
12
13 If fast handoff is not supported, the PDSN to PDSN handoff for Mobile IP involves:
14
15 • Establishment of a new PPP session;
16 • Detection of a new Foreign Agent via the Agent Advertisement Message;
17 • Authentication by RADIUS infrastructure;
18 • Registration with the Home Agent.
19
20 If fast handoff is supported, the PDSN to PDSN handoff for Mobile IP involves:
21
22 • Establishment of a P-P connection for each associated R-P connection and the
23 continuation of the current PPP session on the Serving PDSN;
24 • Establishment of a new PPP session by the Target PDSN when the MS becomes
25 dormant or the MS renegotiates PPP;
26 • Release of the associated P-P connections while the new PPP session is being
27 established at the Target PDSN;
28 • Detection of a new Foreign Agent via the Agent Advertisement Message;
29 • Authentication by RADIUS infrastructure;
30 • Registration with the Home Agent.
31
32 If fast handoff is not supported, the PDSN to PDSN handoff for Simple IP involves:
33
34 • Establishment of a new PPP session on the Target PDSN.
35
36 If fast handoff is supported, the PDSN to PDSN handoff for Simple IP involves:
37
38 • Establishment of a P-P connection for each associated R-P connection, and continuation
39 of the current PPP session on the Serving PDSN;
40 • Establishment of a new PPP session by the Target PDSN, when the MS becomes
41 dormant or the MS renegotiates PPP;
42 • Release of the associated P-P session while the new PPP session is being established
43 at the Target PDSN.
44
45 The P-P interface is specified in Section 12.
46
47
- 50 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 10 Quality of Service
2 The cdma2000 service options allow various voice and non-voice services to be defined and
3 specified independently within the confines of the physical layer and the multiplex sub-layer
4 interface [5-9]. The air interface is able to support multiple service instances of the same or
5 different packet data service options. cdma2000 specifications support a maximum of six service
6 instances per MS, each of which may have associated RLP and/or QoS parameter settings. The
7 MS and RN identify specific service instances with a unique number referred to as the Service
8 Reference ID (SR_ID).
9
10 Although this and subsequent sections contain text referring to multiple service instances, this
11 specification does not support the use of auxiliary service instances connected to a PDSN from
12 the same MS. This is because no standard exists for informing the PDSN how to map various
13 application flows down the proper auxiliary connections. The text referring to auxiliary service
14 instances is given for use by future releases of this specification.
15
16 As outlined in [1], the RN/PCF transfers data to the PDSN via R-P connections for all service
17 instances to the MS. There shall be one R-P connection for each service instance. The PDSN
18 shall identify a service instance via an SR_ID carried in R-P connection signaling. A single R-P
19 session shall be maintained for all the R-P connections associated with an MS. For each R-P
20 session there shall be one main service instance, and optionally one or more auxiliary service
21 instances. A single PPP session shall be associated with the R-P session. There shall be one
22 PPP session between the MS and the PDSN. A given PPP session shall support one or more IP
23 addresses. These IP addresses are not associated with a particular R-P connection.
24
25 In this specification, a service instance may carry multiple flows. A flow is a series of packets that
26 share a specific instantiation of IETF protocol layers. For example, an RTP flow may consist of
27 the packets of an RTP/UDP/IP protocol instantiation, all of which share the same source and
28 destination IP addresses and UDP port numbers.
29
30 Flows may be identified at the PDSN using packet filters. Packet filters are used to map forward
31 traffic to the corresponding auxiliary service instance.
32
33 The following figure is a graphical illustration of the relationships between MS IP addresses, PPP
34 session, R-P session, R-P connection, service instance, and SR_ID.
- 51 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
PPP session
R-P session
Ch2=SR_ID2
Ch3=SR_ID3
BSC/PCF
PPP session MS
Flow 1 Flow n
1
2 Figure 13 - Graphical Illustration of Multiple Connection Relationships
3
4 In accordance with differentiated services standards, the MS may mark packets (i.e., in the
5 reverse direction). The PDSN limits the differentiated services markings that the MS applies to
6 packets based on the User Profile from the Home AAA server. The PDSN also provides a fixed
7 marking for Mobile IP based reverse tunneled traffic. This capability is especially useful for MSs
8 that cannot mark packets but that desire the benefits of differentiated services for traffic
9 traversing the Internet to a private network.
10
11 The remainder of this section covers the following topics:
12
13 • Section 10.1: Multiple Service Instances
14 • Section 10.2: QoS Flow Mapping and Treatments
15 • Section 10.3: Subscriber QoS Profile
17 10.1.1 MS Requirements
18 If the MS establishes multiple service instances, the MS shall always establish a main service
19 instance before establishing auxiliary service instances. The MS shall support a single PPP
20 session over multiple service instances. The MS shall send PPP control packets only over the
21 main service instance. The MS shall not send PPP control packets over auxiliary service
22 instances. The MS shall use octet-oriented HDLC framing per RFC 1662 over octet-oriented
23 service instances. The MS shall not use HDLC framing over non-octet oriented service
24 instances. If the MS uses Mobile IP, the MS shall send Mobile IP discovery and registration
25 messages over the main service instance.
- 52 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
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 cdma2000 Wireless IP Network Standard
1 • Class selectors: [RFC 2474] defines these as code points whose lower three bits (3, 4, 5)
2 are all zero. Therefore, there are eight such classes.
3 • Default Forwarding (often called Best Effort) is a class selector with class equal to 0.
4 • Assured Forwarding (AF) classes: see [RFC 2597].
5 • Expedited Forwarding (EF) Classes: see [RFC 2598].
6
7 When the MS marks IP packets with DSCPs, the PDSN shall ensure that only allowed DSCPs
8 are used as authorized by the HAAA in the users Subscriber QoS Profile. If the HAAA does not
9 include the Subscriber QoS Profile of the user in the RADIUS Access-Accept message, the
10 PDSN shall offer a default QoS to the user’s packets as provisioned by the service provider.
11
12 The Allowed Differentiated Services Marking attribute indicates the type of marking the user may
13 apply to a packet. The PDSN may re-mark the packet according to local policy if the type of
14 marking is not authorized by the user's Allowed Differentiated Services Marking attribute. The
15 attribute contains three bits, the 'A', 'E', and 'O' bits. When the ‘A’ bit is set, the user may mark
16 packets with any AF class. When the ‘E’ bit is set, the user may mark packets with EF class.
17 When the ‘O’ bit is set, the user may mark packets with experimental/local use classes. The Max
18 Class Selector field specifies the maximum class selector for which a user may mark a packet.
19 When all three bits are clear, and when the Max Class Selector is zero, the user may only send
20 packets marked best effort.
21
22 When reverse direction traffic arrives at the PDSN, the PDSN shall match the source address of
23 such packets to a source address that is associated with an authenticated NAI. The PDSN
24 should apply the associated Subscriber QoS Profile to the packet.
- 54 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 11 Accounting
2 11.1 General
RN
R-P Interfac e
1 Airlink Records
i.e., MSID, location, time on RADIUS Server
channel, etc.
RADIUS Records
2 PDSN adds more info
PDSN
and sends RADIUS
accounting info
16
17
18
19 Figure 14 - Accounting Architecture
- 55 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 remote address accounting for the user29. The table indices specified by the Home RADIUS
2 server point to tables of addresses stored at the PDSN. The method of provisioning the tables at
3 the PDSN and the corresponding table indices at the Home RADIUS server is outside the scope
4 of this specification.
5
6 The PDSN shall support the Remote IPv4/IPv6 Address Octet Count attribute to count the
7 number of bytes sent/received to/from a given remote address or set of remote addresses. The
8 attribute contains a counter for forward traffic, a counter for reverse traffic, and the remote IP
9 address or set of remote addresses with the same mask or prefix length (if present), as specified
10 in Annex C. The PDSN shall generate a Remote IPv4/IPv6 Address Octet Count attribute for
11 each remote address or set of remote addresses as represented by a mask or prefix length in
12 use during a packet data session and authorized for the user by the RADIUS server. Hence, a
13 UDR may contain multiple instances of the Remote IPv4/IPv6 Address Octet Count attribute.
14 Therefore, the PDSN and the RADIUS server shall be capable of supporting multiple instances of
15 the Remote IPv4/IPv6 Address Octet Count attribute in the RADIUS Accounting-Request (Stop)
16 record and Interim messages. A remote address mask or prefix-length shall be used to indicate
17 a range of addresses for remote address accounting. The PDSN shall aggregate the byte counts
18 for all the remote IP addresses of that mask or prefix and generate one Remote IPv4/IPv6
19 Address Octet Count attribute.
20
21 If the Remote Address Table Index is used for remote address based accounting, the current
22 method is not easily scalable to multi-domain support, due to issues with table provisioning and
23 synchronization between realms. In this case, the remote address functionality shall be limited to
24 a single realm support from an access provider network point of view. All the PDSNs in a single
25 realm shall have the same set of tables. There is no explicit support in this specification for
26 coordinating table indices across realms. The Home RADIUS server shall be of the same realm
27 as the PDSN or it shall have coordinated its indices with the realm that owns the PDSN.
28
29 It is the responsibility of the Visited RADIUS server to ensure the remote address table indices
30 returned in a RADIUS Access-Accept message are consistent with the tables stored in the
31 PDSN. For example, the Visited RADIUS server may filter out the Remote Address Table Index
32 attributes contained in the RADIUS Access-Accept messages received from uncoordinated
33 realms.
34
35 When a packet is received in the forward direction, the PDSN shall examine the source IP
36 address of the packet. If the source IP address matches a remote address for the user, the
37 PDSN shall create a Remote IPv4/IPv6 Address Octet Count attribute as part of the UDR if it
38 does not exist and shall increment the octet counts.
39
40 When a packet is received in the reverse direction, the PDSN shall examine the destination IP
41 address of the packet. If the destination IP address matches a remote address for the user, the
42 PDSN shall create an instance of the Remote IPv4/IPv6 Address Octet Count attribute if it does
43 not exist and shall increment octet counts.
44
45 Both IPv4 and IPv6 remote addresses are supported in remote address accounting. The
46 structure of remote address tables, and the method of communicating such information to the
47 PDSN are outside the scope of this specification.
29
An address mask of all ones means that all bits of the address shall be matched.
- 56 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 the Serving PDSN combines these with IP network specific parameters, the UDR is sent to the
2 RADIUS server as a RADIUS Accounting-Request record. This is outlined as below in Figure 15,
3 and detailed in the subsequent sections. Upon fast handoff, the Target PDSN shall store a copy
4 of the airlink records received at pre-setup of the R-P session.
5
6 Also, the Serving PDSN copies some of the data from the current UDR or UDRs to the new UDR
7 or UDRs while fast handoff is in progress. The PDSN accounting procedures ensure that no
8 double counting of usage occurs.
Target RADIUS
RN Server
1 3 UDR
Airlink Records
R-P • PDSN adds more info
• i.e., MSID, location, time on
Interface and sends complete
channel, etc. UDR
Target Serving
PDSN P-P Interface PDSN
2 Airlink Records
• i.e., MSID, location, time on
channel, etc.
9
10
11
12
13 Figure 15 - Accounting Architecture With Fast Handoff
14
- 57 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 For fast handoff, the Target PDSN forwards the airlink records to the Serving PDSN unchanged.
2 The Target PDSN shall store a copy of the airlink records received at pre-setup of the R-P
3 session for each R-P connection.
4
5 All the airlink records shall include a sequence number initialized to zero at R-P connection
6 setup. The sequence number is unique for a single identification triplet (R-P Connection ID, PCF
7 ID, and MSID). Upon receiving the connection setup airlink record, the Serving PDSN updates
8 the UDR with the airlink record information and stores the sequence number. The PCF shall
9 increment the sequence number modulo 256 in the subsequent airlink record transmitted over
10 the corresponding R-P connection. The Serving PDSN shall compare the received sequence
11 number with the previously stored sequence number (N). If the received sequence number is in
12 the range from (N+1) modulo 256 to (N+127) modulo 256, inclusive, the PDSN shall act
13 accordingly based on the information contained in the airlink record, and shall update its stored
14 sequence number. If the received sequence number is in the range from (N-128) modulo 256 to
15 (N-1) modulo 256, inclusive, the Serving PDSN shall ignore the message. The same procedure
16 continues for all the subsequent airlink records, until the closing of the R-P connection.
17
18 In the event of retransmission, the PCF shall retransmit with the same sequence number, and the
19 Serving PDSN shall not update the UDR if the same sequence number corresponding to a single
20 identification triplet is received. There should be only one outstanding unacknowledged airlink
21 record at any given time.
22
23 Detailed specifications of airlink records are in [4].
30
Either a2 or a3, or both shall be included.
- 58 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
18
19 Table 9 – SDB Airlink Fields
- 59 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
- 60 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
F14 DCCH Frame Size Specifies Dedicated Control Channel (DCCH) frame size.
G5 Remote IPv4 Contains the octet count associated with a remote IPv4 address; used for
Address Octet source/destination accounting.
Count
G6 Remote IPv6 Contains the octet count associated with a remote IPv6 address; used for
Address Octet source/destination accounting.
Count
G8 Active Time The total active connection time on traffic channel in seconds.
G9 Number of Active The total number of non-active to Active transitions by the user.
Transitions
G10 SDB Octet Count The total number of octets sent to the MS via Short Data Bursts.
(Terminating)
G11 SDB Octet Count The total number of octets sent by the MS via Short Data Bursts.
(Originating)
G12 Number of SDBs The total number of Short Data Burst transactions with the MS.
(Terminating)
G13 Number of SDBs The total number of Short Data Burst transactions with the MS.
(Originating)
G14 Number of HDLC The count of all bytes received in the reverse direction by the HDLC layer in the PDSN.
layer bytes
received
G15 Inbound Mobile IP This is the total number of octets in registration requests and solicitations sent by the
Signaling Octet MS.
Count
G16 Outbound Mobile This is the total number of octets in registration replies and agent advertisements sent to
IP Signaling Octet the MS.
Count
I. Quality of Service
I1 IP Quality of This attribute is deprecated.
Service (QoS)
I4 Airlink Priority Identifies Airlink Priority associated with the user. This is the user's priority associated
with the packet data service.
- 61 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
- 62 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1
2
RADIUS Attribute Definitions
Item Parameter Type/ Maximum Format Field Special Values
Vendor Payload
Type Length
(in octets)
3 A. Mobile Identifiers
A1 MSID 31 15 string Calling_ID
A2 ESN 26/52 15 string ESN ASCII string of ESN
A3 MEID 26/116 14 string MEID ASCII string of MEID
4 B. User Identifiers
B1 Source IP Address 8 4 ip-addr Framed IP Address
B2 Network Access Identifier (NAI) 1 72 string User-Name
B3 Source IPv6 Prefix 97 4-20 IPv6-prefix Framed IPv6 Prefix Carries the IPv6 prefix of the MS. The
length includes the reserved byte as well
as the prefix length field byte (see RFC
3162, section 2.3).
B4 IPv6 Interface ID 96 10 string Framed_Interface_ID See RFC 3162
5 C. Session Identifiers
C1 Account Session ID 44 8 string Acct_ Session_Id ASCII string of session ID
C2 Correlation ID 26/44 8 string Correlation_Id ASCII string of correlation ID
C3 Session Continue 26/48 4 integer 3GPP2_Session_cont 0=False, 1=True
C4 Beginning Session 26/51 4 integer 3GPP2_Begin_Session 0=False, 1=True
6 D. Infrastructure Identifiers
D1 MIP Home Agent (HA) 26/7 4 ip-addr 3GPP2_HA_IP_Addr
D2 PDSN Address 4 4 ip-addr NAS Address IPv4 address of the RADIUS client in the
PDSN
D3 Serving PCF 26/9 4 ip-addr 3GPP2_PCF IP_Addr The serving PCF is the PCF in the serving
RN.
D4 BSID 26/10 12 string 3GPP2_BSID A number formed from the concatenation of
SID (4 octets)+ NID (4 octets)+ Cell
Identifier (type 2) (4 octets). In the Cell
Identifier the 12 upper bits are the Cell Id
and the lower 4 bits are the Sector. Each
item is encoded using hexadecimal
uppercase ASCII characters.
D5 IPv6 PDSN Address 95 16 Ipv6-addr NAS IPv6 address
7 E. Zone Identifiers
- 63 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
E1 User Zone 26/11 4 integer 3GPP2_User_ID Least significant 16 bits hold user zone ID
(UZ_ID) next significant 15 bits hold user
zone system ID (UZ_SID) and most
significant bit always zero. UZ_ID and
UZ_SID are defined in [10].
1 F. Session Status
F1 Forward Mux Option 26/12 4 integer 3GPP2_FMUX
F2 Reverse Mux Option 26/13 4 integer 3GPP2_RMUX
F5 Service Option 26/16 4 integer 3GPP2_SO
F6 Forward Traffic Type 26/17 4 integer 3GPP2_FTYPE 0=Primary, 1=Secondary
F7 Reverse Traffic Type (Primary, Secondary) 26/18 4 integer 3GPP2_RTYPE 0=Primary, 1=Secondary
F8 Fundamental Frame Size 26/19 4 integer 3GPP2_FFSIZE 0=no fundamental, 1=5ms and 20ms mixed
frame, 2=20ms frame
F9 Forward Fundamental RC 26/20 4 integer 3GPP2_FRC See [6]
F10 Reverse Fundamental RC 26/21 4 integer 3GPP2_RRC See [6]
F11 IP Technology 26/22 4 integer 3GPP2_IP_Tech 1=Simple IP, 2=Mobile IP
F12 Compulsory Tunnel Indicator 26/23 4 integer 3GPP2_Comp_Flag 0=no tunnel
1=non-secure tunnel
2=secure tunnel
F13 Release Indicator 26/24 4 integer 3GPP2_Reason_Ind Reasons for stop record:
0=unknown
1=PPP/Service timeout
2=Handoff
3=PPP termination
4=Mobile IP registration failure
F14 DCCH Frame Format (0/5/20ms) 26/50 4 integer 3GPP2_DFSIZE 0=no DCCH, 1=5ms and 20ms mixed
frame, 2=20ms frame, 3=5ms frame
F15 Always On 26/78 4 integer 3GPP2_Always_ON Always On
0=no
1=yes
2 G. Session Activity
G1 Data Octet Count (Terminating) 43 4 integer Acct_Output_Octets
G2 Data Octet Count (Originating) 42 4 integer Acct_Input_Octets
G3 Bad PPP Frame Count 26/25 4 integer 3GPP2_Bad_Frame_Cou
nt
G4 Event Time 55 4 time Event_Timestamp
G5 Remote IPv4 Address Octet Count 26/72 variable32 octet string See Annex C
G6 Remote IPv6 Address Octet Count 26/9780 variable44 octet string See Annex C
G8 Active Time 26/49 4 integer 3GPP2_Active_Time
G9 Number of Active Transitions 26/30 4 integer 3GPP2_Num_Active
G10 SDB Octet Count (Terminating) 26/31 4 integer 3GPP2_SDB_Input_Octe
ts
G11 SDB Octet Count (Originating) 26/32 4 integer 3GPP2_SDB_Output_Octe
ts
- 64 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
- 65 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
- 66 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 bicasting31 to both the source and target RNs. Since the MS can connect to only one RN for a
2 given service instance, the PDSN accounting procedures ensure that double counting between
3 the current and new (copy) never occurs despite the PDSN bicasting of data to both service
4 instances.
5
6 RADIUS accounting messages are generated from the information in the UDR. The Correlation
7 ID is used to match different accounting records (Account Session IDs) across R-P connections
8 or P-P connections for a single packet data session. One Correlation ID for all R-P and P-P
9 connections is maintained for the life of a packet data session for each NAI and IP pair. The
10 Account Session ID is used to match a single RADIUS Start and Stop pair. A different Account
11 Session ID is used for each R-P connection and/or P-P connection. A new R-P connection due
12 to intra-PDSN handoff between PCFs shall result in a new R-P Connection ID and Account
13 Session ID. A new P-P connection due to fast handoff between the PDSNs shall result in a new
14 R-P Connection ID and Account Session ID. The MSID and SR_ID are used to select the proper
15 UDR after an intra-PDSN handoff. One R-P Connection ID may be associated with multiple
16 simultaneous NAI, IP pairs in the Serving PDSN (i.e., multiple packet data sessions).
17
18 Airlink records are only associated with an R-P connection IDor a P-P connection. The Serving
19 PDSN matches the R-P Connection ID in the airlink record to the R-P Connection ID in the
20 appropriate UDR(s). If more than one UDR matches, the actions are applied to all UDRs.
21
22 Some events cause certain UDR fields to change in the middle of a session. When this happens,
23 one of two approaches shall be taken: (1) a container attribute as specified in Annex C is created
24 and the changed fields are embedded in that container attribute. This allows the UDR to
25 continue to accumulate accounting information after an event without transmitting a RADIUS
26 message. Alternatively (2), the PDSN may send a RADIUS Stop record to capture accounting
27 data before the event, followed by a RADIUS Start record with the new field values. In fact, a
28 PDSN may send a RADIUS Stop and RADIUS Start anytime during a single session as long as
29 no accounting data is lost. In these cases, the PDSN shall send the same Correlation ID in both
30 the RADIUS Start and RADIUS Stop records.
31
32 The subsequent sections specify the actions to take for each event.
31
Bi-casting occurs when the A11-Registration Request or P-P-Registration Request has the ‘S’
bit set to 1.
32
A "pending" UDR is one for which usage data is not accumulated because another UDR is
accumulating usage data, e.g., because of bicasting.
- 67 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 Or:
2 • Create a copy of the current UDR.
3 • Use information received from the RN to fill the following fields in the copy UDR: D3 and
4 D4. The PDSN fills in D2 (in case of an IPv6 PDSN, D5).
5 • Zero fields G1, G2, G3, and G8-16 in the copy UDR; all instances of G5/G6 in the copy
6 UDR are eliminated.
7 • Send a RADIUS Accounting-Request (Start) record containing a new Account Session ID
8 and the same Correlation ID.
9 • Mark the new UDR as pending if the “S” bit in the A11 Registration-Request message or
10 P-P Registration-Request message that carries the Session Setup Airlink Record is set
11 to '1'.
12 • When the Active Stop Airlink Record for the previous R-P or P-P connection arrives,
13 update the current UDR and send a RADIUS Accounting-Request (Stop) record based
14 on the current UDR. The RADIUS Accounting-Request (Stop) record contains a Session
15 Continue attribute with the value set to 1 (True), the same correlation ID, and the original
16 session ID. (See section 11.5.6 for further processing of the Airlink Stop Record).
17
18 Otherwise (i.e., there is no handoff), the Serving PDSN shall use the R-P Connection Setup
19 Airlink record (from the current RN) to fill the following fields of the new UDR:
20
21 • A1, A2, A3, D3, and D4
22 • Zero fields G1-G16.
23
24 The Serving PDSN shall populate the remaining fields of the UDR as specified in sections 11.5.2
25 and 11.5.5.
- 68 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 • Follow Packet Data Service Establishment accounting procedures for each new UDR
2 immediately after packet data establishment.
33
This means IP, UDP, and the MIP message payload above UDP.
- 69 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 • Add a Session Continue attribute in the current UDR with the value set to 1 (True).
2 • Send a RADIUS Accounting-Request (Stop) record based on the current UDR.
3 • Set UDR fields according to airlink record. E1 e1, F1 <- f1, F2 <- f2, I4 i4 and zero
4 fields G1, G2, G3, and G8-16. All current instances of G5/G6 in the UDR are eliminated.
5 • Send a RADIUS Accounting-Request (Start) record based on UDR containing a new
6 Account Session ID and same Correlation ID.
7
8 Finally, the PDSN shall increment G9 by one.
- 70 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
- 71 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 12 P-P Interface
2 12.1 Architecture
3 The network reference model is depicted in Figure 1 and Figure 2. This section describes the
4 functionality for a fast handoff in the context of an inter-PDSN handoff. This section provides P-P
5 interface details. See [4] for fast handoff procedures over the R-P interface.
6
7 With the implementation of the P-P Interface, the following additional functions are provided by
8 the PDSNs during fast handoff:
9
10 • For every R-P connection at the Target PDSN, there is a corresponding P-P connection.
11 • The Target PDSN does not terminate PPP.
12 • The Target PDSN provides transparent bi-directional transport of the bearer data stream
13 over the R-P and P-P connections.
14 • The Serving PDSN provides bi-directional transport of the bearer data stream over the P-
15 P connections.
16 • The Target PDSN forwards accounting related airlink records received over an R-P
17 connection to the Serving PDSN over the corresponding P-P connection.
18 • The Serving PDSN processes airlink records received over the P-P connection similar to
19 the airlink records received over the R-P connection by creating separate UDRs.
20 The Target PDSN becomes the Serving PDSN when all service instances on the Target
21 RN are released (e.g., dormant) or PPP is re-negotiated by the MS. When the MS closes
22 the PPP session, the Serving PDSN shall release the P-P connections, and the Target
23 PDSN shall release the R-P connections. At handoff, the Target PDSN shall use the
24 main service instance to carry on PPP negotiations.
25
26 During a fast handoff, either two R-P connections, an R-P and P-P connection, or two P-P
27 connections may exist momentarily with the same SR_ID and MSID due to the PDSN bicasting to
28 both the Source and Target RNs.
- 72 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 12.2.1 Signaling
2 The following messages shall be used for P-P Interface call control and signaling34:
3
4 • P-P Registration-Request
5 • P-P Registration-Reply
6 • P-P Registration-Update
7 • P-P Registration-Acknowledge
8
9 These messages use the same format as R-P connection messages specified in [4], including
10 use of the same UDP port number ’699’. The entire signaling message shall be sent within a
11 single UDP datagram. The source IP address of the P-P Registration-Request message and P-P
12 Registration-Acknowledge messages is set to the Target P-P Address and the destination IP
13 address is set to the Serving P-P Address. The source IP address of the P-P Registration
14 Update-Request and P-P Registration-Reply messages is set to the Serving P-P Address and the
15 destination IP address is set to the Target P-P Address.
16
17 The initiator of the P-P connection (Target PDSN) shall pick an available source UDP port, and
18 send a P-P Registration-Request message to the desired destination (Serving PDSN) at UDP
19 port ‘699’. The recipient (Serving PDSN) shall send a P-P Registration-Reply message to the
20 initiator’s (Target PDSN) UDP port that initiated the P-P Registration-Request message. The
21 following indicates the setting of the fields within a P-P Registration signaling message:
22
23 • Care-of address = Target P-P Address (P-P Registration-Request message and
24 Acknowledge message)
25 • Home Address = 0.0.0.0 (all)
26 • HA Address = Serving P-P Address (P-P Registration-Request message, Reply
27 message, and Update message)
28 • MN-HA Authentication Extension = Target PDSN to Serving PDSN MIP Authentication
29 Extension
30
31 The procedures to support fast handoff over the R-P interface are defined in [4].
34
P-P messages use [4]; see corresponding R-P messages.
- 73 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 This specification assumes that RN specific handoffs move both active and dormant service
2 instances to the Target RN.
35
In particular, this addresses the case of a new Target PDSN being exactly the same as the
currently Serving PDSN.
- 74 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1
2 The Target and Serving P-P addresses, along with the GRE Key form the unique link layer ID for
3 each P-P connection. With the P-P connection(s) in place, bearer data frames pass over these
4 connection(s) in both directions via GRE framing. In the reverse direction, the Serving PDSN
5 shall accept the P-P frames, process and remove the GRE overhead, and then shall process the
6 GRE payload, as necessary. In the forward direction the Serving PDSN shall encapsulate bearer
7 data frames in GRE. The Target PDSN shall process and remove the GRE overhead before
8 passing the bearer data to the associated R-P connection. On the R-P connection, the Target
9 PDSN shall encapsulate the bearer data frames in GRE and shall forward them to the Target RN.
10 Thus, the Target PDSN shall provide a transparent bi-directional transport for the bearer data
11 frames between the R-P connection and the P-P connection so that there is a point-to-point link
12 layer connection for each service instance between the MS user and the Serving PDSN.
13
14 The Target PDSN shall maintain the P-P connections by periodically sending P-P Registration-
15 Request messages to the Serving PDSN with ‘S’ bit clear. The lifetime field in the P-P
16 Registration-Request message shall be set to a value large enough to prevent frequent re-
17 registrations. Each P-P connection shall be maintained as long as the corresponding R-P
18 connection exists at the Target PDSN. When all the service instances become dormant, or the
19 MS renegotiates PPP, the fast handoff shall be completed according to Section 12.4.5.
36
Airlink records are sent over the P-P connection by the use of Critical Vendor/Organization
Specific Extension as specified in [4].
- 75 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 P-P address (see [4]).restart PPP over the main service instance, if it received an indication from
2 the Target RN that identifies the main service instance.
3
4 In the P-P Registration-Request message, the Target PDSN shall set the Home Address field to
5 zero, the HA Address field to the Serving P-P address, and the Care-of Address field to the
6 Target P-P address. The Mobile Identifier, SR_ID, and Target PDSN Session Identifier Key shall
7 be included in the Session Specific Extension. The Target PDSN shall assign a Target PDSN
8 Session Identifier Key for the P-P connection. The Target PDSN Session Identifier Key shall be
9 unique within a Target PDSN entity. The ‘S’, ‘T’, and ‘G’ bits shall be set. The Lifetime field shall
10 be set to Tpresetup, whose value is sufficient for the service instance to handoff from the Source RN
11 to the Target RN. The IP source and destination addresses in the IP header shall be set to the
12 Target P-P and the Serving P-P address, respectively.
13
14 If the P-P Registration-Request message is acceptable, the Serving PDSN shall update the
15 binding record for the MS by creating an association between among the IMSI, SR_ID, the Target
16 PDSN Session Identifier Key, Serving PDSN Session Identifier Key (if asymmetric P-P session
17 identifier keys are supported between the Target PDSN and the Serving PDSN), the Target P-P
18 address, and the Serving P-P address. The Serving PDSN shall indicate to the Target PDSN if
19 the newly established P-P connection is the main service instance by including the PPP Link
20 Indicator Extension with a value of 'main service instance, continuing (0)' in a P-P Registration-
21 Reply message to the Target PDSN.
22
23 The Serving PDSN shall assign a Serving PDSN Session Identifier Key37 for the P-P connection,
24 if asymmetric P-P session identifier keys are supported between the Target and Serving PDSNs.
25 The Serving PDSN Session Identifier Key is unique within a Serving PDSN entity. The Serving
26 PDSN shall return a P-P Registration-Reply message with an accept indication. In the P-P
27 Registration-Reply message, the Serving PDSN sets the MS Home Address field to zeros. The
28 HA Address fields shall be set to the serving P-P address of the Serving PDSN. The Mobile
29 Identifier, SR_ID and Serving PDSN Session Identifier Key shall be included in the Session
30 Specific Extension. The Lifetime field shall be set to Tpresetup (see [4]), whose value is sufficient
31 for the traffic channel to handoff from the Source RN to the Target RN. The IP source address
32 and the IP destination address in the IP header shall be set to Serving P-P PDSN address and
33 the Target P-PPDSN address, respectively.
34
35 On receipt of the P-P Registration-Reply message, the Target PDSN shall create a binding
36 record for the MS by creating an association between among the IMSI, SR_ID, the Serving PDSN
37 Session Identifier Key, and the Serving P-P Address information, the and TargetServing PDSN
38 Session Identifier Key, the R-P Interface PDSN Session Identifier Key, the Target PCF Session
39 Identifier Key, and the Target PCF IP address. Bearer data now flows both to the Source RN via
40 the R-P connection and to the Target PDSN over the newly established P-P connections, or for
41 the case of a continuing fast handoff, to the previous Target PDSN via the previous P-P
42 connection and to the Target PDSN over the newly established P-P connection.
43
44 The Target PDSN shall use the SR_ID and the Mobile Identifier to uniquely identify a packet data
45 service instance for a specific MS across RNs and PDSNs.
46
47 The GRE keys for the P-P session (i.e., the Target PDSN Session Identifier and Serving PDSN
48 Session Identifier) shall be chosen according to [4].
49
50 The Target PDSN shall forward the bearer data to the Target RN via the pre-setup R-P
51 connection. The Target RN discards bearer data until such time the service instances are
52 successfully handed over to it.
53
37
This is the same as the PCF Session Identifier Key as defined in [4].
- 76 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 On handoff of the active service instance(s) to the Target RN, the Target RN forwards the Start
2 Airlink Records to the Target PDSN over the pre-setup R-P connection(s), with R-P connection
3 Lifetime set to Trp38 (see [4]) and ‘S’ bit cleared39. The Target RN also starts periodically re-
4 registering with the Target PDSN before the expiration of the R-P connection Lifetime.
5
6 If the service instance is not handed over to the Target RN, the pre-setup R-P connection is
7 automatically released on expiry of timer Tpresetup (see [4]). 40
8
9 If the P-P connection has been established successfully by the time the Active Start Airlink
10 Record is received from the Target RN, the Target PDSN shall forward the Active Start Airlink
11 Record over the P-P connection to the Serving PDSN.
12
13 On receipt of the R-P-Registration-Request message with zero lifetime from the Source RN, or a
14 P-P Registration-Request message with zero lifetime from the previous Target PDSN (i.e., as in
15 Figure 19), the Serving PDSN shall stop transport of the user data stream to the Source RN or
16 previous Target PDSN and release the R-P or P-P connection, respectively. Also, following the
17 reception of the Active Stop Airlink Record the Serving PDSN may release the associated R-P
18 connection with the Source RN, or P-P connection to the previous Target PDSN. The Target
19 PDSN shall also start periodically re-registering with the Serving PDSN before the expiration of
20 the P-P connection Lifetime. On receipt of P-P Registration-Request message with ‘S’ bit not set,
21 the Serving PDSN shall stop transport of the bearer data stream to the Source RN or previous
22 Target PDSN.
23
24 If the service instances are not all handed over to the Target RN, the Target PDSN shall
25 automatically release the established P-P connections between the Target PDSN and the
26 Serving PDSN on expiry of timer Tpresetup.
38
Trp is the lifetime of the R-P connection with the 'S' bit clear.
39
The Serving and Target RN should take appropriate measures to avoid rapid establishment
and release of the serving PDSN to RN R-P connections in the face of a ping-pong condition in
which the MS moves rapidly between the Serving and Target RN.
40
Tpresetup is the lifetime of the R-P connection with the 'S' bit set and is much shorter than Trp.
- 77 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
41
Tpp is the lifetime of the P-P connection.
- 78 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 releases the P-P connections because the MS renegotiates PPP, the Serving PDSN shall
2 indicate to the Target PDSN to restart negotiate PPP with a P-P Registration-Update message
3 containing a PPP Link Indicator Extension with a value of 1 (negotiate PPP). In this case, the
4 Target PDSN shall reuse the existing R-P connections to renegotiate the PPP link with the MS. If
5 the P-P connection is released by the serving PDSN without an indication to negotiate PPP, tThe
6 Target PDSN shall release the corresponding R-P connection if one exists. In either case, the
7 Target PDSN shall, remove the binding information for the P-P connection, and return a P-P
8 Registration-Acknowledge message. The Target PDSN shall send a P-P Registration-Request
9 message with a lifetime of zero containing any accounting related information received from the
10 Target RN. On receipt of the P-P Registration-Request message, the Serving PDSN shall
11 respond with a P-P Registration-Reply message and remove binding information for the P-P
12 connection along with any associated link context.
13
14 If the Serving PDSN does not receive a P-P Registration-Acknowledge message after
15 transmitting a configurable number of P-P Registration-Update messages, the Serving PDSN
16 shall remove the binding information for all the P-P connections for the MS. It shall also initiate
17 release of the associated link layer context for the MS and R-P connections if one exists.
- 79 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
Serving PDSN
R-
P
R-P interface
A1 inte
A10, A11
0, rfa
A1 c e
1
bicasting
Source RN Target RN
Mobile station
1
2 Figure 16 - Intra PDSN Handoff
3
P-P interface
bicasting
R-P interface
R-P interface
A10, A11
A10, A11
Source RN Target RN
Mobile station
4
5 Figure 17 - Inter PDSN, Beginning of Fast Handoff
6
- 80 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
P-P interface
R-P interface
R-
P
A10, A11
A1 int
0, erf
A1 ac
1 e
bicasting
Source RN Target RN
Mobile station
1
2 Figure 18 - Intra PDSN, Continuation of Fast Handoff on Target PDSN
P-P Interface 2
bicasting
P-P Interface 1
Serving PDSN Target PDSN 1 Target PDSN 2
R-P interface
R-P interface
A10, A11
A10, A11
Source RN Target RN
Mobile station
3
4 Figure 19 - Inter PDSN Handoff, Continuation of Fast Handoff Between Target PDSNs
5
6
- 81 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
- 82 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
2 13.1 General
3 The PDSN interfaces to the Radio Network only through the R-P interface and there are no RN
4 dependent signaling messages transmitted to the PDSN. However, there are some general
5 requirements placed on the RN:
6
7 • Each RN is connected to at least one PDSN.
8 • The RN relays PPP octets between the MS and PDSN.
9 • The RN establishes an R-P connection for each MS initiated packet data service
10 instance. If the MS initiates multiple service instances, each R-P connection is directed
11 to the same PDSN.
12 • The RN terminates the R-P connection if the MS terminates the corresponding packet
13 data service instance with the service inactive indication.
14 • The RN terminates all the R-P connections for the MS if the MS terminates the packet
15 data session with a power down indication.
16 • The RN terminates the R-P connection upon request from the PDSN.
17 • For some service options, the RN may buffer user data from the PDSN when radio
18 resources are not in place or insufficient to support the flow of data.
19 • The RN passes octets between the MS and PDSN without any framing conversion.
20
21 Note: No changes to the IP version used in the RN are required in order to support IPv6 MSs,
22 i.e., the IP version used in the RN (including the R-P interface), shall be independent of the IP
23 version of the packets carried in the PPP Sessions.
- 83 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 to the same PDSN, the RNs release and re-establish the R-P session so that it connects
2 the new RN serving the MS and the PDSN in such a way that the MS maintains the same
3 PPP session.
4 • During a packet data session, an MS may move outside the coverage area of one RN
5 into the coverage area of another RN. If the previous and the new RN do not have
6 connectivity to the same PDSN, the new RN immediately establishes a new R-P session
7 to a new PDSN.
8
9 Specific handoff procedures for the R-P are not called out in this specification but can be found in
10 [4].
11
- 84 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
42
Note that a future version of this specification is likely to no longer require AH, in accordance
with industry trends.
- 85 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 Transform Payload:
2
3 For Phase 1, the PDSN shall use KEY_IKE as the transform identifier. All
4 implementations shall support 3DES and RSA.
5
6 For Phase 2 Quick Exchange, the PDSN shall minimally support the ESP_3DES
7 transform identifier within a Transform Payload for IPSec ESP Proposal Payload. It shall
8 also support both HMAC-MD5 and HMAC-SHA1 as transform identifiers within a
9 Transform payload for IPSec AH Proposal Payload. Service provider HAs shall likewise
10 support these two transforms. The PDSN may optionally support and propose other
11 transforms. An HA shall select one of the transforms offered by the PDSN.
12
13 Key Exchange Payload
14
15 The PDSN and HA will exchange D-H (Diffie-Hellman) public values computed in the D-H
16 group negotiated as part of a protection suite in the first message exchange of Phase 1
17 for ISAKMP SA establishment. The PDSN shall specify Phase 1 authentication with
18 certificates when the HA's certificate or HA's root CA certificate is available.
19
20 Otherwise, if a Dynamic pre-shared IKE secret distributed by the Home RADIUS server is
21 available, the PDSN shall specify Phase 1 authentication with a pre-shared secret mode
22 of operation. In this case, the PDSN shall specify Phase 1 Aggressive mode only. This is
23 necessary in order that the KeyID field can be transmitted in the clear. The Home
24 RADIUS server shall insure that the value of the ‘S’ key is hard to guess (i.e., a properly
25 generated random number) in order to prevent dictionary attacks that are possible with
26 Aggressive mode. If the PDSN has a statically configured IKE secret for the SA with the
27 HA, then the PDSN shall specify Phase 1 authentication with pre-shared secret mode of
28 operation. In this case the PDSN may either use Main Mode or use Aggressive Mode.
29 Otherwise, if a pre-shared secret is available, the PDSN shall specify Phase 1
30 authentication with a pre-shared secret mode of operation. The PDSN shall specify
31 Phase 1 Aggressive mode only. It shall not specify Phase 1 Main mode. This is
32 necessary in order that the KeyID field can be transmitted in the clear. The Home
33 RADIUS server shall insure that the value of the ‘S’ key is hard to guess (i.e., a properly
34 generated random number) in order to prevent dictionary attacks that are possible with
35 Aggressive mode.
36
37 Identification Payload
38
39 For Phase 1 negotiation, the PDSN shall set the Protocol-Id field to zero or UDP. The
40 port number shall be set to zero or 500. If the HA receives any other values for these two
41 fields in the Identification Payload, IKE negotiation shall be aborted.
42
43 For IKE authentication using pre-shared secret the PDSN and HA shall minimally support
44 ID_KEY_ID in the ID Type field. For IKE authentication using Revised Public Key
45 Encryption with RSA using X.509 certificates, the PDSN and HA shall minimally support
46 ID_DER_ASN1_DN in the ID Type field.
47
48 For Phase 2 (Quick Mode), both the PDSN and HA shall include the client identifiers in
49 the form of optional Client Identification Payloads as specified in IKE (i.e., IDci and IDcr).
50 To apply IPSec on all traffic between the PDSN and the HA, the PDSN and the HA shall
51 exchange IDci and IDcr. The protocol and port number fields shall be “don’t care” by
52 setting them to 0 in both IDci and IDcr. The following is an example of the format of the
53 client identifiers.
54 IDCi: Protocol field = 0, Port = 0, Idtype = ID_IPV4_ADDR,
55 Identification_data = PDSN_IPV4_ADDR.
- 86 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
- 87 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 Annex B: Certificates
2 PDSNs and HAs shall use X.509 Version 3 certificates in conformance with RFC 2459. Each
3 PDSN and HA in a service provider network may have a unique certificate which will be
4 configured into the PDSN and HA. The method of configuration of certificates is outside the
5 scope of this specification.
6
7 Note: This Annex only applies to FA CoA. Security between a collocated CoA MS and the HA is
8 outside the scope of this specification.
9
10 Each service provider may be a Certificate Authority for itself and its client private networks and
11 partner ISPs for PDSNs and for HAs that may be accessed by PDSNs. All PDSNs and HAs shall
12 be configured with all service provider CA certificates. There should be one CA root certificate
13 from each service provider.
14
15 Certificates for PDSNs and HAs
16
17 The Distinguished Name [RFC 2459] contained in the Issuer field is of form:
18
19 cdma2000.service-provider-name
20
21 The PDSN or HA determines the issuing service-provider (i.e., the CA) from the service-provider-
22 name attribute of the Issuer's Distinguished Name. The PDSN and HA then use the service-
23 provider-name attribute to locally access the CA's public key.
24
25 The PDSN and HA shall use the SHA-1 as a hash function and either the RSA or DSA signing
26 algorithm, as specified in RFC 2459 to verify a certificate. The private network or ISP shall
27 provide the public key and Distinguished Name of the certificate.
28
29 The Distinguished Name contained in the Subject field is of form:
30
31 cdma2000. service-provider-name.PDSN.service-provider-identifier
32 cdma2000. service-provider-name.HA.service-provider-identifier
33
34 Certificates in the PDSN and HA will not use the Unique-Identifier field.
35
36 Certificate extensions for PDSN and HA certificates shall not be supported.
37
38 The method of providing PDSNs and HAs signed certificates to PDSNs and HAs is outside the
39 scope of this specification.
40
41 CA Certificates
42
43 Service provider CA certificates shall be configured into all PDSNs and HAs. A service provider
44 CA contains the public key that the PDSN or HA shall use to verify the signature of a certificate
45 received in a Phase 1 ISAKMP exchange.
46
47 A CA certificate shall conform to the X.509 V3 certificates in RFC 2459. Since the service
48 provider CA distributes its own certificate, the Authority Key Identifier and Subject Key Identifier
49 extensions shall not be included in the certificate.
50
51 The method by which service providers exchange their CA certificates, as well as of providing
52 certificates into PDSNs and HAs, is outside the scope of this specification.
53
- 88 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
- 89 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
- 90 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 Type: 26
2 Length = 12
3 Vendor ID: 5535
4 Vendor-Type = 4
5 Vendor-Length = 6
6 Vendor-Value =
7 0 - Reverse tunneling is not required
8 1 - Reverse tunneling is required
9
10 Differentiated Services Class Option: This attribute is deprecated and is replaced by the
11 Allowed Differentiated Services Marking attribute. The Home RADIUS server authorizes
12 differentiated services via the Differentiated Services Class Options attribute, and optionally
13 appears in a RADIUS Access-Accept message.
14
15 Type: 26
16 Length = 12
17 Vendor ID: 5535
18 Vendor-Type = 5
19 Vendor-Length = 6
20 Vendor-Value
21 0 - Best Effort
22 10 - AF11
23 12 - AF12
24 14 - AF13
25 18 - AF21
26 20 - AF22
27 22 - AF23
28 26 - AF31
29 28 - AF32
30 30 - AF33
31 34 - AF41
32 36 - AF42
33 38 - AF43
34 46 - EF
35
36 The above values are taken from RFC 2597 and RFC 2598. There is no intention to convey the
37 actual traffic specification parameters of the differentiated services service.
38
39 Home Agent: The address of the HA that appears in a RADIUS Access-Request message,
40 RADIUS Access-Accept message, and accounting messages.
41
42 Type: 26
43 Length = 12
44 Vendor ID: 5535
45 Vendor-Type = 7
46 Vendor-Length = 6
47 Vendor-Value = 4 octet IP address
48
- 91 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
- 92 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 Vendor-Type = 56
2 Vendor-Length = 6
3 Vendor-Value = Number of seconds since January 1, 1970 00:00 UTC.
4
5 'S' Request: Indicates whether the HA requests a shared secret "S". This appears in a RADIUS
6 Access-Request message to the Home RADIUS server:
7
8 Type: 26
9 Length = 12
10 Vendor ID: 5535
11 Vendor-Type = 55
12 Vendor-Length = 6
13 Vendor-Value =
14 1. The HA requests a 'S' secret for IKE
15
16 MN-HA shared key: A shared key for MN-HA that optionally appears in a RADIUS Access-
17 Accept message. The MN-HA shared key is encrypted using a method based on the RSA
18 Message Digest Algorithm MD5 [RFC 1321] as described in Section 3.5 of RFC 2868.
19
20 Type: 26
21 Length: 26 or greater
22 Vendor ID: 5535
23 Vendor-Type = 58
24 Vendor-Length = 20 or greater
25 Vendor-Value = two octets for the salt field as defined in RFC 2868 followed by at least
26 16 octets containing the binary value of the encrypted MN-HA shared secret
27
28 MN-HA SPI: The SPI for the MN-HA shared key that optionally appears in a RADIUS Access-
29 Request message. It is used to request an MN-HA shared key.
30
31 Type: 26
32 Length = 12
33 Vendor ID: 5535
34 Vendor-Type = 57
35 Vendor-Length = 6
36 Vendor-Value = binary value of the MN-HA SPI
37
38 DNS Update Required: Indicates whether the HA needs to send DNS Update to the DNS
39 server. This optionally appears in a RADIUS Access-Accept message.
40
41 Type: 26
42 Length = 12
43 Vendor ID: 5535
44 Vendor-Type = 75
45 Vendor-Length = 6
46 Vendor-Value =
47 0 - HA does not need to send DNS Update
48 1 - HA needs to send DNS Update
49
50 Remote IPv4 Address: Allows the PDSN to identify an IP address to be used for remote address
51 based accounting for the user. It is only used in RADIUS Access-Accept messages. Up to ten
52 instances of the attribute shall be supported in one RADIUS Access-Accept message.
53
- 93 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
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 Type: 26
4 Length ≥= 20
5 Vendor ID: 5535
6 Vendor-Type: 59
7 Vendor-Length ≥= 14
8 Subtype (=1): type for remote IPv4 address attribute of value 1
9 Length: length of remote IPv4 address attribute (=6 octets)
10 Remote IPv4 Address:
11 The Remote IPv4 Address sub-attribute contains an IPv4 address to be used for
12 remote address based accounting for the user. The address is used in
13 conjunction with the Remote Address Mask (below), to define the range of
14 address to be monitored.
15 Subtype (=2): type for remote IP address mask of value 2
16 Length: length of remote IP address mask attribute (=6 octets)
17 Remote Address Mask:
18 The Remote Address Mask sub-attribute contains an IPv4 address mask that
19 defines a set of remote addresses to be used for remote address based
20 accounting.
21
22 Remote IPv6 Address: Allows the PDSN to identify an IP address to be used for remote address
23 based accounting for the user. It is only used in RADIUS Access-Accept messages. Up to ten
24 instances of the attribute shall be supported in one RADIUS Access-Accept message.
25
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
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 Type: 26
28 Length ≥= 32
29 Vendor ID: 5535
30 Vendor-Type: 70
31 Vendor-Length ≥=26
32 Subtype (=1): type for remote IPv6 address attribute of value 1
33 Length: length of remote IPv6 address attribute (=18 octets)
34 Remote IPv6 Address:
35 The Remote IPv6 Address field contains a corresponding IPv6 address to be
36 used for remote address based accounting for the user.
37 Subtype (=2): type for prefix length of value 2
- 94 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
- 95 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
- 96 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 The Forward Octet Count Field indicates how many bytes have been received
2 from the Remote Address.
3 Subtype (=4): type for reverse octet count attribute of value 4
4 Length: length of forward reverse octet count attribute (6 octets)
5 Reverse Octet Count
6 The Reverse Octet Count Field indicates how many bytes have been sent to the
7 Remote Address.
8
9 Allowed Differentiated Services Marking: Specifies if the user is able to mark packets with AF
10 (A), EF (E). The Max Class (i.e., Max Selector Class), specifies that the user may mark packets
11 with a Class Selector Code Point that is less than or equal to Max Class.
12
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
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 Type: 26
16 Length = 20
17 Vendor ID: 5535
18 Vendor-Type: 73
19 Vendor-Length = 14
20 Subtype (=1): flags for Allowed Diffserv class
21 Length: 3 flags (= 4 octets)
22 "A" bit set means the user can send packets with AF DSCPs
23 "E" bit set means the user can send packets with EF DSCP
24 "O" bit set means the use can mark packets for experimental or local use
25 Subtype (=2): Max class selection marking
26 Length: (=4 octets)
27 Value: See Reverse tunnel marking
28 Subtype (=3): Reverse tunnel marking
29 Length: (= 4 octets)
30 RT-Marking:
31 '000000' = Default or Best Effort Forwarding, also Selector Class 0
32 '001010' = AF11
33 '001100' = AF12
34 '001110' = AF13
35 '010010' = AF21
36 '010100' = AF22
37 '010110' = AF23
38 '011010' = AF31
39 '011100' = AF32
40 '011110' = AF33
41 '100010' = AF41
42 '100100' = AF42
43 '100110' = AF43
44 '101110' = EF
45 '001000' = Selector Class 1
46 '010000' = Selector Class 2
47 '011000' = Selector Class 3
48 '100000' = Selector Class 4
- 97 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
- 98 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
1 FA IPv4 Address
2
3 MN-AAA Removal Indication: When received in a RADIUS Access-Accept, the PDSN shall not
4 include the MN-AAA Authentication and MN-FA challenge extensions when relaying the RRQ to
5 the HA.
6
7 Type: 26
8 Length = 12
9 Vendor ID: 5535
10 Vendor-Type = 81
11 Vendor-Length = 6
12 Vendor-Value =
13 1 - MN-AAA not required
14
15 DNS Server IP Address: This VSA may be present in a RADIUS Access-Accept message. It
16 includes a Primary and a Secondary DNS server IP addresses.
17
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
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 Type: 26
20 Length: 28
21 Vendor ID: 5535
22 Vendor-Type: 117
23 Vendor-Length: 22
24 Sub-Type (=1):
25 Length: (=4 octets)
26 Vendor-Value: Primary DNS server IP Address.
27 Sub-Type (=2):
28 Length: (= 4 octets)
29 Vendor-Value: Secondary DNS server IP Address.
30 Sub-Type (=3): Flag
31 Length: (=1 octet)
32 Vendor-Value: "M” bit set to 1 indicates to the PDSN that the Primary and
33 Secondary DNS IP addresses provided by the Home RADIUS server shall
34 override the Primary and Secondary DNS addresses if provided also by the
35 Visited RADIUS server.
36
37 Sub-Type (=4):
38 Length: (=1 octet)
39 Vendor-Value: “Entity-Type” The network entity that inserted in the DNS
40 server IP address. Currently the following types are defined:
41 HAAA = 1
42 VAAA = 2
43
44
- 99 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
- 100 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
(Originating)
Number of SDBs 26/33 0 0 0 0-1 0-1
(Terminating)
Number of SDBs 26/34 0 0 0 0-1 0-1
(Originating)
IP Quality of Service 26/36 0 0 0-1 0-1 0-1
Airlink Priority 26/39 0 0 0-1 0-1 0-1
Airlink Record Type 26/40 0 0 0 0 0
Airlink Sequence 26/42 0 0 0 0 0
Number
Number of HDLC 26/43 0 0 0 0-1 0-1
layer bytes received
Correlation ID 26/44 1 0-1 1 1 1
Mobile Originated / 26/45 0 0 0-1 0-1 0-1
Mobile Terminated
Indicator
Inbound Mobile IP 26/46 0 0 0 0-1 0-1
Signaling Octet
Count
Outbound Mobile IP 26/47 0 0 0 0-1 0-1
Signaling Octet
Count
Session Continue 26/48 0 0 0 1 0-1
Active Time 26/49 0 0 0 0-1 0-1
DCCH Frame 26/50 0 0 0-1 0-1 0-1
Format
Beginning Session 26/51 0 0 0-1 0 0
ESN 26/52 0 0 0-1 0-1 0-1
‘S’ Key 0 0-1 0 0 0
26/54
‘S’ Request 26/55 0-1 0 0 0 0
‘S’ Lifetime 26/56 0 0-1 0 0 0
- 101 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
Address
Remote IPv6 26/978 0 0 0 0+ 0+
Address Octet 0
Count
MN-AAA Removal 26/81 0 0-1 0 0 0
Indication
MEID 26/116 0 0 0-1 0-1 0-1
DNS Server IP 26/117 0 0+ 0 0 0
Address
1
- 102 - 3GPP2
P.S0001-Bv2.0 3GPP2 cdma2000 Wireless IP Network Standard
- 103 - 3GPP2