Docstoc

1xEV-DO Roaming Whitepaper

Document Sample
1xEV-DO Roaming Whitepaper Powered By Docstoc
					      1xEV-DO Roaming Guide

                    CDG Document 136
                           Version 1.1
                     November 8, 2006


                    CDMA Development Group
                  575 Anton Boulevard, Suite 560
                   Costa Mesa, California 92626
                    PHONE +1 888 800-CDMA
                         +1 714 545-5211
                      FAX +1 714 545-4601
                        http://www.cdg.org
                           cdg@cdg.org




                                Notice
Each CDG member acknowledges that CDG does not review the
disclosures or contributions of any CDG member nor does CDG verify
the status of the ownership of any of the intellectual property rights
associated with any such disclosures or contributions. Accordingly, each
CDG member should consider all disclosures and contributions as being
made solely on an as-is basis. If any CDG member makes any use of
any disclosure or contribution, then such use is at such CDG member's
sole risk. Each CDG member agrees that CDG shall not be liable to any
person or entity (including any CDG member) arising out of any use of
any disclosure or contribution, including any liability arising out of
infringement of intellectual property rights.
<page left intentionally blank>
1xEV-DO Roaming Guide                                                                                                                       Contents




                                                                                                                Contents
1. Introduction ................................................................................................................................ 9
2. Getting Started ......................................................................................................................... 11
       2.1 Coverage Area ................................................................................................................. 11
       2.2 Applications ...................................................................................................................... 12
       2.3 Network ............................................................................................................................ 12
       2.4 Security ............................................................................................................................ 13
       2.5 Billing ................................................................................................................................ 14
       2.6 Devices ............................................................................................................................. 15
       2.7 PRLs ................................................................................................................................. 15
       2.8 Testing .............................................................................................................................. 16
3. Network Architecture ............................................................................................................... 17
       3.1 Transport Mechanisms ..................................................................................................... 17
       3.2 Similarities between Voice and 1xEV-DO Roaming ........................................................ 17
       3.3 1xEV-DO elements that support inter-carrier roaming ..................................................... 18
                  3.3.1 Packet Data Serving Node (PDSN) ................................................................... 18
                  3.3.2 Authentication, Authorization, and Accounting (AAA) Servers ......................... 19
       3.4 Additional 1xEV-DO network elements and interfaces .................................................... 20
                  3.4.1 Packet Control Function (PCF) ......................................................................... 20
                  3.4.2 Radio Network Controller (RNC) ....................................................................... 21
                  3.4.3 A8 and A9 Interfaces ......................................................................................... 21
                  3.4.4 R-P Interface (A10 and A11) ............................................................................. 21
                  3.4.5 A12 Interface ..................................................................................................... 22
                  3.4.6 A13 Interface ..................................................................................................... 22
                  3.4.7 P-P Interface...................................................................................................... 22
       3.5 Mobility ............................................................................................................................. 23
                  3.5.1 Mobility Architecture .......................................................................................... 23
                  3.5.2 Intra-PDSN Handoffs ......................................................................................... 23
                  3.5.3 Inter-PDSN Handoffs ......................................................................................... 24
                  3.5.4 Inter-technology Handoff (1xRTT/1xEV-DO) .................................................... 25
       3.6 Network interconnection ................................................................................................... 26
                  3.6.1 Direct Interconnections ...................................................................................... 26
                  3.6.2 Indirect Interconnections ................................................................................... 27
                  3.6.3 CDMA packet data Roaming eXchange (CRX) ................................................ 27



Ref Doc 136, Ver. 1.0                                                                                                                       3
1xEV-DO Roaming Guide                                                                                                                       Contents




       3.7 Addresses ........................................................................................................................ 30
       3.8 Roaming architecture options .......................................................................................... 32
                  3.8.1 Simple IP ........................................................................................................... 32
                  3.8.2 Layer 2 Tunnel Protocol (L2TP) ........................................................................ 33
                  3.8.3 Mobile IP ............................................................................................................ 35
4. Security ..................................................................................................................................... 39
       4.1 Authentication Types ........................................................................................................ 39
       4.2 A12 Authentication ........................................................................................................... 39
       4.3 RADIUS Routing Issues ................................................................................................... 40
                  4.3.1 Non-unique realms ............................................................................................ 41
                  4.3.2 Common NAI/Password Fraud Scenario .......................................................... 41
       4.4 Issues Common to Both SIP and L2TP ........................................................................... 43
                  4.4.1 PPP Authentication............................................................................................ 43
                  4.4.2 PPP Authentication of Roamer by PDSN .......................................................... 44
       4.5 Issues Specific to SIP ...................................................................................................... 44
                  4.5.1 Precautions for Protecting the Home Network .................................................. 44
       4.6 Issues Specific to L2TP .................................................................................................... 46
                  4.6.1 L2TP Tunnel Setup and L2TP Authentication of LAC / LNS ............................. 46
                  4.6.2 Dual PPP Authentication of Roamer ................................................................. 48
                  4.6.3 Proxy PPP Authentication of Roamer ............................................................... 49
       4.7 Issues Specific to MIP ...................................................................................................... 50
                  4.7.1 Rejection of PPP Authentication by Roamer ..................................................... 50
                  4.7.2 Authentication of Roamer by PDSN/FA ............................................................ 50
                  4.7.3 Security between the PDSN/FA and HA ........................................................... 53
                  4.7.4 Authentication of Roamer by HA ....................................................................... 54
5. Billing ........................................................................................................................................ 57
       5.1 Infrastructure .................................................................................................................... 57
       5.2 UDRs ................................................................................................................................ 58
                  5.2.1 Account-Request Records ................................................................................ 58
                  5.2.2 Attributes ........................................................................................................... 58
       5.3 1xEV-DO Roaming Billing Architecture ............................................................................ 60
                  5.3.1 Bilateral Billing Architecture ............................................................................... 60
                  5.3.2 CRX Billing Model.............................................................................................. 62
       5.4 Back End Processing of UDR records ............................................................................. 65
                  5.4.1 Retail Billing ....................................................................................................... 65
                  5.4.2 Settlement ......................................................................................................... 65


Ref Doc 136, Ver. 1.0                                                                                                                       4
1xEV-DO Roaming Guide                                                                                                                       Contents




                  5.4.3 Identifying the Visited Operator ......................................................................... 66
                  5.4.4 Correlating Accounting Records ........................................................................ 66
                  5.4.5 Subscriber Identification .................................................................................... 67
       5.5 Custom Billing Requirements ........................................................................................... 67
       5.6 Billing Testing ................................................................................................................... 68
6. Devices ...................................................................................................................................... 69
       6.1 Device Provisioning .......................................................................................................... 69
                  6.1.1 PRLs .................................................................................................................. 69
                  6.1.2 CSIMs (R-UIMs) ................................................................................................ 69
                  6.1.3 Authentication Credentials ................................................................................ 70
                  6.1.4 Mobile IP Behavior ............................................................................................ 70
                  6.1.5 DNS Addresses ................................................................................................. 70
       6.2 Custom or Non-standard Device Behavior ...................................................................... 71
7. Testing ...................................................................................................................................... 73
       7.1 Devices ............................................................................................................................. 73
       7.2 Network ............................................................................................................................ 74
                  7.2.1 Interconnectivity................................................................................................. 74
                  7.2.2 AAA connectivity................................................................................................ 74
                  7.2.3 Home Network Access ...................................................................................... 74
       7.3 Authentication................................................................................................................... 74
                  7.3.1 HLR Authentication............................................................................................ 74
                  7.3.2 A12 Authentication ............................................................................................ 74
                  7.3.3 PDSN Authentication ......................................................................................... 75
                  7.3.4 Mobile IP Authentication: ................................................................................... 75
       7.4 Roaming Architecture Testing .......................................................................................... 75
                  7.4.1 Simple IP ........................................................................................................... 75
                  7.4.2 L2TP .................................................................................................................. 75
                  7.4.3 Mobile IP ............................................................................................................ 75
       7.5 Handoffs ........................................................................................................................... 76
       7.6 Billing ................................................................................................................................ 76
                  7.6.1 UDR generation ................................................................................................. 76
                  7.6.2 Settlement Testing............................................................................................. 76




Ref Doc 136, Ver. 1.0                                                                                                                       5
1xEV-DO Roaming Guide                                                                                                                       Contents




8. Conclusions .............................................................................................................................. 77
9. References ................................................................................................................................ 79
10. Terminology............................................................................................................................ 81
11. Overview of 1xEV-DO ............................................................................................................ 87
       History .................................................................................................................................... 87
       Overview ................................................................................................................................ 87
       1xEV-DO Advancements ....................................................................................................... 88
       Beyond 1xEV-DO Release 0 .................................................................................................. 89
       Deployment status.................................................................................................................. 90
12. Security Concepts.................................................................................................................. 91
       12.1 Secure connection concepts .......................................................................................... 91
                  12.1.1 Leased Line Connections ................................................................................ 91
                  12.1.2 Virtual Private Network (VPN) Connections .................................................... 91
                  12.1.3 Security Associations ...................................................................................... 91
                  12.1.4 Encryption ........................................................................................................ 91
                  12.1.5 IP Security (IPSec) .......................................................................................... 92
                  12.1.6 Shared Key Distribution ................................................................................... 93
       12.2 Authentication Protocols ................................................................................................ 94
                  12.2.1 Password Authentication Protocol (PAP) ........................................................ 94
                  12.2.2 Challenge Handshake Authentication Protocol (CHAP) ................................. 95
       12.3 Authentication Functions ................................................................................................ 96
                  12.3.1 MD5 (Message Digest Algorithm) ................................................................... 96
                  12.3.2 HMAC-MD5 (Keyed-hashing with MD5 for Message Authentication) ............. 97
13. Call Flow Examples................................................................................................................ 99
       13.1 Simple IP (SIP) Roaming Architecture ........................................................................... 99
                  13.1.1 SIP Call Setup Example Call Flow .................................................................. 99
                  13.1.2 SIP Call Teardown Example Call Flow.......................................................... 101
       13.2 Layer 2 Tunneling Protocol (L2TP) Roaming Architecture .......................................... 101
                  13.2.1 L2TP Call Setup Example Call Flow ............................................................. 101
                  13.2.2 L2TP Call Teardown Example Call Flow ....................................................... 105
       13.3 Mobile IP (MIP) Roaming Architecture ......................................................................... 106
                  13.3.1 MIP Call Setup Example Call Flow ................................................................ 106
                  13.3.2 MIP Call Teardown Example Call Flow ......................................................... 109




Ref Doc 136, Ver. 1.0                                                                                                                       6
1xEV-DO Roaming Guide                                                                                                                 Figures




                                                                                                            Figures
  Figure 3-1: Comparison of Voice and Data Roaming ................................................................. 17
  Figure 3-2: Types of AAA Servers .............................................................................................. 19
  Figure 3-3: 1xEV-DO Reference Architecture ............................................................................ 20
  Figure 3-4: R-P Interface ............................................................................................................ 22
  Figure 3-5: Mobility Architecture ................................................................................................. 23
  Figure 3-7: Basic CRX Model ..................................................................................................... 28
  Figure 3-8: CRX Model with L2TP/MIP Tunneling ..................................................................... 29
  Figure 3-9: Simple IP Roaming Model ........................................................................................ 33
  Figure 3-10: L2TP Roaming Model ............................................................................................ 34
  Figure 3-11: L2TP Tunneling Example ....................................................................................... 35
  Figure 3-12: Mobile IP Roaming Model ...................................................................................... 36
  Figure 3-13: MIP Tunneling Example ......................................................................................... 37
  Figure 4-1: A12 Interface ............................................................................................................ 40
  Figure 4-2: Common NAI/Password Fraud Scenario ................................................................. 42
  Figure 4-3: PPP Phases with Authentication .............................................................................. 43
  Figure 4-4: PPP Authentication with Simple IP .......................................................................... 44
  Figure 4-5: Using Simple IP with Private IP addresses .............................................................. 45
  Figure 4-6: Control Connection Setup with L2TP Authentication of LAC / LNS ......................... 46
  Figure 4-7: Tunnel Session Setup .............................................................................................. 47
  Figure 4-8: Dual PPP Authentication with L2TP ......................................................................... 48
  Figure 4-9: Proxy PPP Authentication with L2TP ....................................................................... 49
  Figure 4-10: Rejection of PPP Authentication by MIP Mobile .................................................... 50
  Figure 4-11: Failed FA Challenge Replay Check ....................................................................... 51
  Figure 4-12: FA Challenge Authentication of Mobile by PDSN/FA ............................................ 52
  Figure 4-13: Authentication of Mobile by HA .............................................................................. 55
  Figure 5-1: Bill Infrastructure Elements ...................................................................................... 57
  Figure 5-2: Bilateral Billing Mode (1) .......................................................................................... 60
  Figure 5-3: Bilateral Billing Model (2) ......................................................................................... 61
  Figure 5-4: Bilateral Billing Model (3) ......................................................................................... 62
  Figure 5-5: CRX Billing Model (1) ............................................................................................... 63
  Figure 5-6: CRX Billing Model (2) ............................................................................................... 64
  Figure 5-7: CRX Billing Model (3) ............................................................................................... 64
  Figure 13-1: IPSec AH and ESP Protocols ................................................................................ 93
  Figure 13-2: Example of PAP-based Authentication .................................................................. 94
  Figure 13-3: Example CHAP-based Authentication ................................................................... 95
  Figure 13-4: MD5 Algorithm........................................................................................................ 97
  Figure 13-5: HMAC-MD5 for MIP Authenticator values ............................................................. 97
  Figure 13-6: HMAC-MD5 for IKE pre-Shared Secret Key Distribution ....................................... 98
  Figure 14-1: Simple IP Call Setup Example Call Flow ............................................................... 99
  Figure 14-2: Simple IP Call Teardown Example Call Flow ....................................................... 101
  Figure 14-3: L2TP Call Setup Example Call Flow .................................................................... 102
  Figure 14-4: L2TP Call Teardown Example Call Flow ............................................................. 105
  Figure 14-5: MIP Call Setup Example Call Flow ...................................................................... 106
  Figure 14-6: MIP Call Teardown Example Call Flow ................................................................ 109




Ref Doc 136, Ver. 1.0                                                                                                             7
1xEV-DO Roaming Guide                                                                                                     Tables




                                                                                                     Tables
  Table 3-1: Required Public IP Addresses................................................................................... 31
  Table 3-2: Comparison of Roaming Architectures ..................................................................... 32
  Table 4-1: Authentication used with each Roaming Architecture ............................................... 39
  5-1: Recommend Accounting Attributes for Packet Data Billing ................................................ 59
  8-1: 1xEV-DO handoff testing combinations ............................ Error! Bookmark not defined.76




Ref Doc 136, Ver. 1.0                                                                                                 8
1xEV-DO Roaming WhitepaperGuide                                                         Introduction




                                                           1. Introduction

A direct evolution of the CDMA2000 third-generation wireless standards, CDMA2000 1xEV-
DO enables high-speed wireless connectivity comparable to wired broadband. Several
operators have successfully deployed this technology and consumers are currently enjoying
wireless access to the applications it affords.        However, despite these successful
deployments, there are relatively few instances of 1xEV-DO roaming between operators.
Consumers have come to expect that wireless services should work out of their home areas.
The business and high-end consumers, critical to the financial success of operators, demand
access to services and applications while abroad. Because of this, implementing 1xEV-DO
roaming between operators is a critical component to the service.

The purpose of this technical guide is to review what is required for operators to implement
1xEV-DO roaming. While implementing 1xEV-DO roaming is not inherently difficult, there
are a number of issues that must be considered in order to ensure a successful
implementation. This paper introduces and discusses these issues.

Currently, there are no CDMA2000 or 1xEV-DO standards which cover roaming. However,
reference documents developed by the CDG International Roaming Team (IRT) do provide
recommendations for packet data roaming. In addition to covering concepts in these
reference documents, this guide provides additional background and details to assist
readers without packet data roaming backgrounds in understanding the issues. This guide
does assume at least a basic understand of 1xEV-DO and packet data architecture
concepts; however, Appendix A provides an overview of 1xEV-DO technology and
architecture infrastructure elements are briefly introduced.




Ref Doc 136, Ver. 1.0                                                                     9
1xEV-DO Roaming WhitepaperGuide                                                        Getting Started




                                                      2. Getting Started

The following sections provide an overview of the various 1xEV-DO roaming issues
addressed by this guide. For the reader wishing to gain an appreciation for the breadth of
issues associated with implementing 1xEV-DO roaming, this section may stand alone as an
executive summary. For the reader seeking a greater understanding of 1xEV-DO roaming,
this section serves as a high level overview of issues that will be explored in more depth
later in this paper.


2.1 Coverage Area

Before proceeding with implementation, carriers will need to thoroughly understand their new
roaming partner‟s coverage area. At a high level, the partner‟s coverage area will likely have
been presented in the business case used to justify the roaming implementation effort.
However, this implementation effort will require network planners in the carrier organization
to address additional issues such as whether the partner supports both 1xRTT and 1xEV-
DO or 1xEV-DO only data service. While it is possible for carriers to support 1xEV-DO only,
most carriers are expected to support both. Note that because 1xRTT and 1xEV-DO are
separate networks, they may or may not serve the same coverage area. In many cases, the
1xRTT coverage area provided by carriers is larger than the 1xEV-DO coverage area. As a
result, the ability to support both will provide roamers with the largest extended coverage
area as well as provide the benefit of higher speed 1xEV-DO connectivity when available.
Accomplishing this involves the use of hybrid devices that can register in both 1xRTT and
1xEV-DO networks to support handoff of data sessions between these networks.

Another consideration is the Sector IDs used by each partner. The Sector ID of an 1xEV-DO
sector is the name it broadcasts to identify itself. The Sector ID is comprised of sector and
subnet identifiers. Within an 1xEV-DO network, each subnet may contain multiple sectors.
As carriers build out their 1xEV-DO networks with roaming partners, it is important to ensure
that Sector IDs are globally unique to prevent conflicts. Operators should use well-formed
“SectorIDs.” 3GPP2 standard IS-856 provides information on creating properly formed
Sector IDs.

Equally important to thoroughly defining the extended coverage area that includes the
roaming partner‟s network, is the distribution and continual update of this information within
the carrier organization. For example, engineering groups will use this information to
provision network equipment while device groups will use it to create preferred roaming lists
that allow roamers to receive desired system selection behavior. Similarly, equivalent
information about the carrier‟s own coverage area will need to be provided to the roaming
partner.




Ref Doc 136, Ver. 1.0                                                                      11
1xEV-DO Roaming WhitepaperGuide                                                         Getting Started




2.2 Applications

Determining which applications packet data customers are able to receive when roaming
impacts network, security, and billing decisions. Carriers should identify the types of
applications that will be supported for both inbound and outbound roamers. These
applications may include Internet, corporate VPN, BREW, and others. For each application,
issues such as access options, quality-of-service (QoS) requirements, and mobility should
be considered. In most cases roamers will access application servers in their home network
and the visited network need not be involved in the application being provided, only the
bandwidth used to provide the application. However, if carriers choose to allow roamers to
access application servers in the visited network, billing strategy and implementation will
need to be defined and coordinated between roaming partners. In either case, certain types
of applications such as Push-to-Talk service may require minimum QoS levels to function
properly. Carries must ensure that their roaming partner is capable of supporting these QoS
requirements if such applications are to be supported. Partners may require higher billing
rates when providing higher QoS guarantees to support these types of applications. If so,
these billing implications would be negotiated between the roaming partners.

With packet data enabled applications, there are two main roaming considerations. The first
is whether the application will work in the roaming partner‟s network. For example, can the
application reach its application server? If an application is statically configured with the IP
address of its application server and the home network uses private IP addresses with
Network Address Translation (NAT), the application may be able to reach its server from the
home network but unable to reach it when roaming outside of the home network. The
second is whether the applications need to be transparently maintained when the roamer
crosses PDSN, PCF, or RNC boundaries. Ability to support such application persistence
during mobility may require Mobile IP network architecture.


2.3 Network

Network architecture issues in 1xEV-DO roaming involve coordination of multiple networks.
These networks include access networks which contain radio transmission resources, home
and visited networks which encompass these access networks, and interconnectivity
between home and visited networks.         Presumably, carriers will have successfully
implemented 1xEV-DO service in their own network before embarking on expansion of their
1xEV-DO coverage area through roaming partners. Because the home networks of each
partner are already setup to support 1xEV-DO service, the focus of network architecture for
1xEV-DO roaming centers primarily on determining the most effective implementation for
interconnecting these networks.

Interconnection of roaming partner 1xEV-DO networks can be accomplished either directly
or indirectly. Regardless of which method is selected, the connectivity should guarantee
sufficient bandwidth to accommodate the maximum simultaneous data traffic anticipated
between roaming partner networks at any given time. Direct methods include leased lines


Ref Doc 136, Ver. 1.0                                                                        12
1xEV-DO Roaming WhitepaperGuide                                                           Getting Started




and Virtual Private Network (VPN) connections over the public Internet. Indirect connectivity
involves the use of a CDMA Packet Data Roaming eXchange (CRX) provider that acts as an
intermediary between roaming partner networks. The CRX provides connectivity as one of
several services intended to simplify roaming for CDMA packet data carriers. Whether
connecting directly or through a CRX, roaming partners will need to coordinate their
connectivity decisions. For example, network engineering groups within some carrier
organizations may require a particular connection method. Others may have accounting or
security requirements to maintain separate connections that ensure separation of
accounting, authentication, and payload traffic.

In addition to the underlying connectivity method, network planners in each roaming partner
organization will need to coordinate the choice of IP network architecture that will be used
between networks. This choice will be influenced by a variety of factors including whether
payload traffic should be tunneled back through the home network, whether roaming
subscribers should be able to directly access home network resources, and whether IP
addresses assigned to roamers belong to the home or visited network domain. The choice
of network architecture will also determine whether mobility requirements such as the ability
to transparently maintain applications and IP addresses across PDSN boundaries can be
supported. Architecture options include Simple IP, L2TP, and Mobile IP. Regardless of
which architecture is selected, coordination will be needed between roaming partners to
ensure that proper functionality and provisioning is provided in both the mobile devices and
network elements to support that architecture. This requires coordination both between
roaming partners and between various groups within each carrier organization.


2.4 Security

Since roaming partners already provide packet data service in their own network, they likely
already have firewalls in place to protect their networks from unwanted and malicious access
attempts. In the context of roaming, the security or IT departments of each roaming partner
will need to decide whether reconfiguration of these firewalls is required. Each carrier
should determine whether their roaming partner‟s network will be considered a “trusted”
network. If not, the question of how customers roaming in this “untrusted” network would
access home network resources should be addressed. One option is to open “holes” in
firewalls for each application that customers may use when roaming. Another is for the
firewall to transfer traffic from these applications to VPNs. The types of applications being
used may also influence firewall configuration. For example, firewall configuration may
interfere with customers being able to establish VPN connections to access their corporate
networks.

Since accounting traffic is directly involved in billing, many carriers take the precaution to use
separate connections for accounting and payload traffic. This precaution makes the
Authentication, Authorization, and Accounting (AAA) server less vulnerable to attack since it
is only accessible from the separate accounting connection.




Ref Doc 136, Ver. 1.0                                                                          13
1xEV-DO Roaming WhitepaperGuide                                                         Getting Started




The other major security consideration for carriers is the types of authentication supported
by the roaming partner. Because Home Location Register (HLR) authentication is not
provided in 1xEV-DO as it is in 1xRTT, local authentication in the access network is of
primary importance. This type of authentication is often referred to as A12 authentication
since the interface between the access network (AN) and the AAA in that network (AN-AAA)
is defined as the A12 interface. While technically not mandatory in 3GPP2 standards, the
current expectation is that all 1xEV-DO roaming carriers will support the A12 authentication
option. Additional types of authentication methods may be provided depending on the IP
network architecture being used. In all cases, coordination is required between roaming
partners to ensure that credentials and security keys are stored and exchanged
appropriately.


2.5 Billing

An integral part of any roaming implementation is ensuring the ability to bill the roaming
customer and the ability for operators to bill each other for providing service to inbound
roaming customers. A billing architecture and strategy must be agreed upon by 1xEV-DO
roaming partners.

Billing between roaming partners for 1xEV-DO is accomplished through the AAA
infrastructure using the RADIUS protocol. In order for packet data roaming to be
implemented between two operators, the AAA equipment of each operator must be
connected through an IP data connection. This connectivity could be done through a direct
connection or through a CRX network.

Also, the billing information that is to be captured and passed by the visited operator must be
agreed upon. Packet data billing information is contained in User Data Records (UDRs)
captured by AAA infrastructure. The specific attributes contained in each UDR record, as
well as a minimum set of billing attributes, should be agreed upon by both roaming partners.

The billing settlement process involves operators determining the total amount of money
owed to each company for the servicing of the partner‟s inbound customers, and the net
balance being distributed to the operator owed more money. Such details as billing cycle
and the currency to be used for settlement must be determined. Also, the operators should
determine whether or not they will perform the settlement process themselves or offload it to
the CRX provider.

Finally, any specialized billing architectures implemented by both roaming partners should
be considered. If there is any external equipment used to provide differentiated billing, for
example, this equipment will likely not be present in the roaming partner‟s network and other
arrangements will need to be made.




Ref Doc 136, Ver. 1.0                                                                       14
1xEV-DO Roaming WhitepaperGuide                                                       Getting Started




2.6 Devices

1xEV-DO devices can include PC cards, as well as mobiles, and are offered with integrated
1xRTT functionality. The devices expected to operate in the partner‟s network should be fully
understood by the roaming partner, including the device models and configurations of each
model.

In general, devices must be certified in a laboratory environment prior to allowing it on the
operator‟s network. This can be a time-consuming process and roaming partners should
exchange devices early in the implementation process so this does not become a
bottleneck.

Also, in order to avoid compatibility problems, the way in which devices are configured
should be carefully considered in the context of the specifics of the roaming partner‟s
network. For example, a device might be configured to receive Mobile IP, but the roaming
partner‟s network doesn‟t offer Mobile IP service. Also the Preferred Roaming List (PRL) of
the device must be properly configured, which is described below.


2.7 PRLs

The Preferred Roaming List of the roaming device must be configured to acquire the 1xEV-
DO network. In general, most 1xEV-DO devices will run in hybrid mode, which means the
device can acquire both 1xEV-DO and 1xRTT systems, depending on availability. PRLs
should be constructed so that the desired systems on the roaming partner‟s networks are
acquired.

In order to construct the 1xEV-DO PRL, the Technical Data Sheet (TDS) of the roaming
partner must be available to the roaming partner. The TDS includes all of the technical
information describing the roaming partner‟s network required to write a PRL to acquire the
1xEV-DO network. This includes information not exchanged for the purposes of constructing
voice PRLs. An IS-683-C (or later version) is required to specify EV-DO systems. This is
sometimes referred to as an “extended” PRL.

Careful consideration should be used in creating the PRL as proper construction can be
complex, and errors can result in the loss or diminishment of service to the user. PRLs
should be tested on the roaming partner‟s network as soon as possible, and can be
performed prior to most other kinds of testing, e.g. network and billing testing.

Finally a good process for sharing updates to TDS information should be established
between roaming partners. Updates and changes to networks should be shared regularly
with the roaming partner via new TDS releases so that newly constructed PRLs accurately
reflect the network changes.




Ref Doc 136, Ver. 1.0                                                                     15
1xEV-DO Roaming WhitepaperGuide                                                       Getting Started




This paper does not go into the detail of PRLs and their use in data roaming. For
comprehensive information on PRLs, please consult CDG reference document #130, “PRL
Design, Maintenance and Testing.”


2.8 Testing

Testing is a crucial step in implementing 1xEV-DO which spans most of the areas cited.
Without proper testing, good service can not be assured, and in the worst cases, major
problems can arise the operators‟ networks.

Because device certification and lab testing can take considerable time, it is therefore
recommended that this begin as quickly as possible. Similarly, since PRLs and system
selection behavior can be tested prior to completion of network implementation, early testing
of them is recommended as well.

Network testing should generally be done in a structured manner beginning with basic
network connectivity and followed by specific network roaming implementation architectures
like Mobile IP or L2TP. Once basic network connectivity is implemented and tested, billing
testing should then be performed. To assist carriers in these testing efforts, network and
billing test plans are provided in CDG reference documents #121 and #129, respectively.

When network testing is completed, each mobile application that is expected to operate
while roaming in the partner‟s network should be tested. It is advisable that testing be
continued after launch, particularly when new network features or applications are
introduced.




Ref Doc 136, Ver. 1.0                                                                     16
1xEV-DO Roaming WhitepaperGuide                                                                           Network Architecture




                                                3. Network Architecture
3.1 Transport Mechanisms
Perhaps the most obvious of differences between voice and data roaming are the transport
mechanisms upon which each architecture is based. The transport mechanisms in voice
roaming are split between the packet-switched Signaling System #7 (SS7) network used for
signaling traffic and the circuit-switched trunking network used for voice traffic. Both of these
transport mechanisms are part of the traditional Public Switched Telephone Network
(PSTN). Alternatively, data roaming is entirely packet-switched and utilizes standard IP
networking equipment and protocols for transport of both signaling and user traffic. As such,
data roaming networks benefit from cost advantages, ubiquity of IP networking, and a large
pool of expertise for implementation and support. Because they are based on the same IP
networking concepts used in the public Internet, data roaming networks will continue to
benefit from advances in IP networking such as IPv6.


3.2 Similarities between Voice and 1xEV-DO Roaming

                                           Voice   Data
                       Home Network                              Home Network



              HLR/AC                                      AAA

                                MSC                                       HA/LNS/PDSN
                                                                          (MIP) (L2TP) (SIP)




                SS7                      PTSN               IP

                                                                          FA/LAC/PDSN
                                                                          (MIP) (L2TP) (SIP)



                        VLR
                                                          AAA

                           MSC/VLR

                       Visited Network                          Visited Network
                                                                                               User Traffic
                                                                                               Signaling




                      Figure 3-1: Comparison of Voice and Data Roaming

The illustration above shows a simplified comparison of voice and data roaming
architectures that emphasizes the infrastructure elements in each network that are involved
in interfacing with the partner network. Setting aside differences in transport mechanism and
nomenclature, both architectures clearly utilize similar functional elements to provide control,
authentication, and accounting services to support roaming.




Ref Doc 136, Ver. 1.0                                                                                              17
1xEV-DO Roaming WhitepaperGuide                                                     Network Architecture




Each architecture has infrastructure elements in the home and visited networks that are
responsible for control of user traffic. For voice calls, these elements are the Mobile
Switching Centers (MSCs). For data sessions, these elements are the Packet Data Serving
Nodes (PDSNs).

Likewise, each architecture has database elements in the home and visited networks that
are responsible for maintaining user profile information and providing authentication
services.    For voice calls, these elements include the Home Location Register /
Authentication Center (HLR/AC) in the home network and the Visited Location Register
(VLR) which is incorporated into the MSC in the visited network. For data sessions,
Authentication, Authorization, and Accounting (AAA) servers exist in the home and visited
networks to provide these services.

Conceptual similarities also exist in wholesale billing between roaming partners in each
architecture. While retail billing to the user may be vastly different for voice and data
services, wholesale billing in each architecture is based primarily on the amount of network
resources used by roamers in the visited network. This network usage is calculated based
on a specified unit of measurement. For a roaming voice call, this unit of measurement is
minutes of airtime; for a roaming data session, it is bytes of data. Of course, voice roaming
calls may also includes local, national, and international toll charges if roamers initiate calls
in the visited network. However, because data roaming does not rely on PSTN routing,
there are no such charges in wholesale billing for data roaming. Wholesale billing in data
roaming is based entirely on the number of bytes of data used in the visited network.


3.3 1xEV-DO elements that support inter-carrier roaming
3.3.1 Packet Data Serving Node (PDSN)

The PDSN performs several functions including Point-to-Point (PPP) session management,
packet routing, facilitating authentication, and generating accounting data. If roaming
partners implement Layer 2 Tunneling Protocol (L2TP) or Mobile IP (MIP), the PDSN will
include additional capabilities to support these architectures. In the case of L2TP, the visited
PDSN will provide L2TP Access Concentrator (LAC) capabilities. In the case of MIP, the
visited PDSN will provide Foreign Agent (FA) capabilities. These capabilities and
architectures will be discussed in more detail in the network architecture section this paper.

On the mobile side, the PDSN acts as a Network Access Server (NAS) and is responsible
for establishing, maintaining, and terminating PPP sessions between itself and the mobile
device. On the network side, the PDSN has a publicly visible IP address and acts as a
router by forwarding packets to and from other networks. The PDSN may either serve as
the interface between the carrier‟s 1xEV-DO network and any other networks or may sit
behind a border gateway that provides this interface.

To facilitate authentication, the PDSN acts as an AAA client during session establishment
and is responsible for granting or denying service to the mobile based on responses from the


Ref Doc 136, Ver. 1.0                                                                         18
1xEV-DO Roaming WhitepaperGuide                                                                        Network Architecture




AAA. Authentication issues will be discussed in more detail in the security section of this
paper.

3.3.2 Authentication, Authorization, and Accounting (AAA) Servers

The Home AAA (HAAA) in 1xEV-DO roaming is comparable to the Home Location Register
(HLR) in voice roaming. Both are primarily responsible for authentication and storing device
profile information. AAA servers communicate with other 1xEV-DO network elements over
the IP network using the Remote Authentication Dial-In User Service (RADIUS) protocol.
Note that unlike IS-95 and 1xRTT which utilize HLR-based authentication, 1xEV-DO relies
entirely on AAA servers for authentication. Authentication requests may be received from
PDSN, LNS, LAC, HA, FA, VAAA, or BAAA network elements. The AAA provides
authentication services for PPP Link Control Protocol (LCP) establishment in Simple IP and
secure tunnel establishment in L2TP and Mobile IP.

AAA servers also play an important role in wholesale billing between data roaming partners
as Usage Data Records (UDRs) are sent from a visited network by the VAAA to the HAAA in
a roamer‟s home network. These UDRs indicate the volume of data used by the roamer in
the visited network. This UDR data is the basis of inter-carrier billing in data roaming.

                                                                            PDSN
                              Border Gateway




                                                                                    XXX
                                            BAAA                  HAAA          (Home Network)




                                VAAA
                                                           VAAA
                  PDSN
                                                                         PDSN
                        YYY         YYY and ZZZ do not
                                    roam with each other
                                                                  ZZZ
                                                                                        User Traffic
                                       in this example                                  Signaling




                              Figure 3-2: Types of AAA Servers

AAA servers can be divided into three groups: Home AAA (HAAA), Visited AAA (VAAA), and
Broker AAA (BAAA). The HAAA stores user profile information and communicates with its
PDSN and VAAA servers in other networks. VAAA servers communicate with their PDSN
and HAAA servers in other networks. VAAA servers forward authentication requests from
their PDSN to the appropriate HAAA and relay the authorization response from the HAAA
back to their PDSN. BAAA act as intermediaries, forwarding requests and responses
between HAAA and VAAA servers.




Ref Doc 136, Ver. 1.0                                                                                           19
1xEV-DO Roaming WhitepaperGuide                                                                    Network Architecture




Figure 3-2: Types of AAA Servers illustrates each type of AAA server. The configuration
shown assumes that carrier XXX has roaming agreements with YYY and ZZZ. However,
YYY and ZZZ do not roam with one another. Carrier YYY connects with carrier XXX through
an intermediary such as a CDMA Packet Data Roaming Exchange provider (CRX) while
carrier ZZZ connects to XXX directly.

3.4 Additional 1xEV-DO network elements and interfaces

                                   RNC               PCF    R-P Interface
                            IP                A8                 A10
                                              A9                 A11

                                              A12                           PDSN




                                                                                   P-P Interface
                   Source AN                  A13
                                                           AAA
                                               RNC



                                         IP


                                                                            PDSN

                                    Other AN in
                    User Traffic   same network                     Other Network
                    Signaling




                        Figure 3-3: 1xEV-DO Reference Architecture

Data roaming between carriers is largely focused on interactions between PDSN and AAA
elements at the edge of each carrier‟s network. Within each of these networks, groupings of
Base Station (BS), Radio Network Controller (RNC), and Packet Control Function (PCF)
elements are collectively referred to as Radio Access Networks (RANs) or simply Access
Networks (ANs). The network hierarchy is such that a one-to-many relationship exists with
each element from the PDSN back to the mobile device. In other words, one PDSN may
serve many Ans; one PCF may serve many RNCs; and one RNC may serve multiple Ans.
These elements, their relation to PDSN and AAA elements, and the associated interfaces
are shown in Figure 3-3: 1xEV-DO Reference Architecture and briefly described in the
following subsections.

3.4.1 Packet Control Function (PCF)

The primary function of the PCF is to maintain the status of data calls so that mobile data
devices can transition between active and dormant states transparently. Because data calls
are bursty in nature, extended periods in which no traffic is being sent or received may
occur. During these periods, the RNC may command the mobile device to transition from
active to dormant state and release the radio resources to the device. This reduces battery
drain on the device and allows the radio resources to be made available to other devices
with an immediate need. To prevent the PPP session from being dropped by the PDSN



Ref Doc 136, Ver. 1.0                                                                                       20
1xEV-DO Roaming WhitepaperGuide                                                 Network Architecture




when this occurs, the PCF maintains the status of the data session, essentially hiding this
transition from the PDSN so that the device appears to still be active. If packets are
received while the device is dormant, the PCF buffers these packets until radio resources
can be setup and the device can be transitioned back to active. Once this occurs, the
buffered packets are delivered and the session continues without interruption.

The PCF is a logical entity. While it is often integrated into the RNC, it may also be
implemented as a standalone device that serves multiple RNCs.

3.4.2 Radio Network Controller (RNC)

The RNC in an 1xEV-DO network replaces the Base Station Controller (BSC) found in IS-95
and 1xRTT networks. The functions provided by the RNC are referred to as Session Control
and Mobility Management (SC/MM) functions. These functions include storage of session
related information, assignment of Unicast Access Terminal Identifiers (UATIs), access
authentication, and management of mobile device location.

Radio resources of all base stations in the access network are managed by the RNC. For
each mobile device in its access network, the RNC manages Radio Link Protocol (RLP)
sessions and performs per-link bandwidth management. The RNC communicates with base
stations within its network over either ATM or IP. As users roam between these base
stations, the RNC coordinates handoffs from one base station to another.

3.4.3 A8 and A9 Interfaces

A8 and A9 are the interfaces between RNC and PCF elements. The A8 interface carries
user traffic encapsulated using Generic Routing Encapsulation (GRE). The A9 interface
carries signaling information used to setup and tear down A8 connections and enable
handoffs between RNCs.

The A8 and A9 interfaces are commonly referred to collectively as the A8/A9 reference point
or the Aquinter interface. Note that these interfaces may or may not correspond to physical
interfaces depending on whether the PCF function is integrated into the RNC.

3.4.4 R-P Interface (A10 and A11)

A10 and A11 are the interfaces between PCF and PDSN elements. The A10 interface
carries user traffic encapsulated using GRE. The A11 interface carries signaling information
used to setup and tear down A10 connections and provide accounting information to the
PDSN. The A10 and A11 interfaces are commonly referred to collectively as the A10/A11
reference point, Aquater interface, or R-P interface.




Ref Doc 136, Ver. 1.0                                                                    21
1xEV-DO Roaming WhitepaperGuide                                                  Network Architecture




                                        RNC      PCF
                               IP                          A10
                                                           A11

                                                          R-P
                                                       Interface   PDSN

                            Radio Network (RN)



                                    Figure 3-4: R-P Interface

Note that while the interface is between the PCF and the PDSN, TIA-835 includes the PCF
as part of the Radio Network (RN) and defines the term “R-P interface” as being between the
more generic RN entity and the PDSN as shown above.

3.4.5 A12 Interface

A12 is the interface between the AN and the AAA serving that AN. Because 1xEV-DO
networks do not use HLR authentication, an alternative method of authenticating the mobile
device is provided using the A12 interface. This method is commonly referred to as either
access authentication or A12 authentication and prevents unauthorized mobile devices from
gaining access to the AN.

If authentication is successful, a Mobile Node Identifier (MN ID) for the mobile device is
returned by the AN-AAA to the AN via the A12 interface. This MN ID is unique within the
operator‟s network and used by the AN and the PCF on A8/A9 and A10/A11 interfaces to
enables handoffs of data sessions between ANs and between 1xEV-DO and 1xRTT
systems. Note that the MN ID returned as part of A12 must be the same as the MSID
(IMSI/MIN/IRM) on the 1xRTT network; otherwise, handoff will not occur.

3.4.6 A13 Interface

A13 is the interface between RNC elements in two different Ans served by the same PDSN.
This interface is used to maximize efficiency of handing off users between Ans. Using A13,
the target AN can receive MNID, session configuration parameters, and serving PDSN
address information from the source AN. This exchange of information allows the 1xEV-DO
session to be handed off from source to target AN while maintaining the identifiers and air
interface protocols. The A10 interface would be updated and PPP session with the PDSN
maintained. In the case of MIP architecture, no MIP re-registration would be required.

3.4.7 P-P Interface

P-P (i.e. PDSN-PDSN) is the interface between PDSNs. While this interface is defined to
support fast handoff procedures that allow a user to move from one PDSN network into
another without experiencing service interruption, it is not currently implemented by most
operators. If implemented, the interface facilitates fast handoffs by allowing the serving and
target PDSNs to setup P-P tunnel connections to correspond to each R-P connection. This


Ref Doc 136, Ver. 1.0                                                                      22
1xEV-DO Roaming WhitepaperGuide                                                         Network Architecture




allows the mobile device to maintain its PPP connection with the serving PDSN. New R-P
connections are established with the target PDSN, and all user traffic is forwarded through
this target PDSN between the mobile and the serving PDSN using the P-P connections.


3.5 Mobility
At the heart of user expectations in mobile communications is the ability to connect anytime
and anywhere whether moving or stationary. The initial challenge of mobility is to ensure
that users can receive service anywhere within the carrier‟s own network. The next
challenge is coordination between carriers to ensure that users can receive the same
services when they roam into a partner network.

3.5.1 Mobility Architecture

Mobility may occur at multiple layers as illustrated below. Each layer involves handing off a
user from one serving element to another.




                               Figure 3-5: Mobility Architecture1

For mobility between elements served by the same PDSN, A8/A9 and A10/A11 are used to
facilitate handoffs without interrupting service to the user. For mobility between areas
served by different PDSNs, Mobile IP architecture supports uninterrupted service and
persistence of IP addresses.

3.5.2 Intra-PDSN Handoffs

Intra-PDSN handoffs occur within a carrier‟s network when a user moves between base
stations, access networks, or PCFs served by the same PDSN. Handoffs between base




1 Source: 3GPP2 A.S0008-0 v3.0 (TIA-878-1), Interoperability Specification (IOS) for High Rate Packet
Data (HRPD) Access Network Interfaces, Figure 1.6-1, p. 1-5, May 2003



Ref Doc 136, Ver. 1.0                                                                             23
1xEV-DO Roaming WhitepaperGuide                                                  Network Architecture




stations in the same AN or between Ans served by the same PCF are handled without
affecting the R-P interface between PCF and PDSN. Note that since RNCs often integrate
PCF functionality, handing off from one AN to another often involves handing off from one
PCF to another.

PCF to PCF handoff involves creating a new R-P session between the target PCF and the
PDSN. Since the PDSN is the same for both PCFs, the existing PPP session and IP
address are maintained for the new R-P session. If the mobile device is in dormant state,
the handoff can be completed and the previous R-P session torn down. However, if the
mobile device is active, the PDSN may bicast data to both PCFs while the mobile performs
an active handoff. This bicasting method reduces latency experienced by the user during
the active handoff.

3.5.3 Inter-PDSN Handoffs

PDSN to PDSN handoffs may either occur between different PDSNs within a single carrier‟s
network or between roaming partner networks. PDSN to PDSN mobility is determined by
the IP architecture implemented by the network and supported by the mobile device.
Roaming between partner networks can occur using either Simple IP, L2TP, or Mobile IP
architectures. However, only Mobile IP supports mobility functions that allow users to
maintain IP addresses and data sessions across PDSN boundaries.

3.5.3.1 Simple IP

Simple IP is essentially the same basic IP protocol that is ubiquitously used on the Internet.
Because IP addresses are topologically significant in Simple IP, they are associated with
and assigned by the PDSN network and cannot be used in other PDSN networks.
Therefore, when a user is handed off from one PDSN to another in a Simple IP network, a
new PPP session must be established and new IP address assigned by the new PDSN.
This will cause the user‟s active data sessions to be dropped.

3.5.3.2 L2TP

L2TP is a variant of Simple IP that creates a dedicated tunnel between the partner and home
networks using two additional network elements known as the L2TP Network Server (LNS)
in the home network and L2TP Access Concentrator (LAC) in the partner network. This
allows the home network to provide roamers with home network IP addresses even though
they are receiving service in a partner network. However, since L2TP uses Simple IP, it
suffers from the same mobility limitation and cannot maintain an active session if the user
roams into a different network.

3.5.3.3 Mobile IP

Mobile IP can support IP address mobility for the duration of an active PPP session, even
through PDSN-to-PDSN handoff, and is the preferred architecture for packet data roaming.
Similar to L2TP, Mobile IP creates a tunnel between the partner and home networks using


Ref Doc 136, Ver. 1.0                                                                      24
1xEV-DO Roaming WhitepaperGuide                                                  Network Architecture




two additional network elements known as the Home Agent (HA) in the home network and
Foreign Agent (FA) in the partner network.

However, because Mobile IP is implemented at the network layer, unlike L2TP, user traffic
can be rerouted. When an active user roams into a network served by a different PDSN/FA,
a new tunnel is established between the HA in the home network and this new PDSN/FA.
Because the HA remains the same, traffic is simply rerouted from the old tunnel to the new
one while maintaining the same IP address.

3.5.3.4 PDSN to PDSN Fast Handoff

Though not currently implemented by most operators, PDSN to
PDSN fast handoff procedures utilize the P-P interface between
PDSNs. A P-P tunnel connections are setup between the serving
and target PDSNs for each R-P connection to allow the user‟s
PPP session to remain anchored to the serving PDSN. New R-P
connections are established with the target PDSN and all user
traffic is forwarded through the target PDSN between the mobile
and the serving PDSN using the P-P connections.

Once the mobile device transitions to dormant state or initiates
PPP renegotiation, a new PPP session will be established with        Figure 3-6: P-P
the target PDSN and the serving PPP and P-P sessions will be             Interface
released.    The goal of fast handoff is to prevent service
interruption to users as they move from one PDSN network to another. Fast handoff
procedures may be used with Simple IP, L2TP, or Mobile IP network architectures.

3.5.4 Inter-technology Handoff (1xRTT/1xEV-DO)

Many 1xEV-DO mobiles are hybrid devices with the capability to connect to both 1xRTT and
1xEV-DO networks. Use of these hybrid mobiles provides carriers with flexibility to
strategically deploy 1xEV-DO networks as a complement to 1xRTT coverage. When hybrid
mobiles in a 1xRTT network move into an 1xEV-DO coverage area, they may hand up from
1xRTT to 1xEV-DO for higher speed data service. Likewise, as they move out of 1xEV-DO
coverage into 1xRTT they may hand down to 1xRTT for lower speed data service.

However, hand up and hand down only occur when devices are in the dormant state. Hand
down occurs by the network forcing a device into dormancy, then switching to the 1xRTT
carrier. Hand up only occurs once a device has entered dormancy. Therefore, as long as a
device has data to send, it will remain on the 1xRTT network and not connect to the 1xEV-
DO network.

Handoff of a packet data session is facilitated by a unique value associated with the device.
This value is retrieved from the AN-AAA upon successful A12 authentication and used on




Ref Doc 136, Ver. 1.0                                                                     25
1xEV-DO Roaming WhitepaperGuide                                                   Network Architecture




the A8/A9 and A10/A11 interfaces. The MN ID permits handoffs of PDSN packet data
sessions between ANs and between 1xEV-DO and 1xRTT systems.

1xEV-DO and 1xRTT systems may or may not share the same PDSN. If they do, intra-
PDSN handoff procedures will apply and users moving between areas served by the PDSN
should not experience service interruption as they are handed off. If separate PDSNs are
involved, inter-PDSN handoff procedures will apply and service interruption will depend on
the IP network architectures being used and whether fast handoff procedures are
implemented.


3.6 Network interconnection
Unlike voice roaming which involves the SS7/IS-41 network for transporting signaling traffic
and the PSTN network for transporting voice traffic, all traffic in data roaming is transported
over IP networks. As such, roaming partners have the option of creating a single IP network
interconnection for exchanging all data roaming traffic. However, a more common approach
utilized by carriers is the creation of separate interconnections for carrying AAA and user
traffic. This allows for sensitive traffic such as authentication and accounting to be isolated
from user traffic for security and manageability purposes. When multiple interconnections
are used, the choice of interconnection method for each one is independent. For example,
data roaming partners could choose to create one Virtual Private Network (VPN) connection
over the Internet for exchanging user traffic and one managed private connection using
leased lines for AAA traffic. This approach could be used by carriers concerned about
potential denial of service attacks on their AAA servers from users in the partner network.

3.6.1 Direct Interconnections

Direct interconnections between roaming partners can be accomplished using leased lines,
VPNs over the Internet, or VPNs over leased lines. Leased lines are dedicated, real-world
connections. While leased lines are inherently secure and guarantee availability of a
specified amount of bandwidth, these connections are also an expensive option. VPNs
provide the logical equivalent of a leased lines by creating an IPSec secured tunnel over the
public Internet without the expense of the dedicated leased line. Many carriers utilize the
VPN option for interconnection.

To ensure security when using the VPN option, use of Encapsulating Security Payload
(ESP) and Internet Key Exchange (IKE) with 3DES key encryption is recommended. ESP
provides secure packet flows with authentication, data confidentiality, and message integrity.
The alternative to ESP is Authentication Header (AH). However, AH does not provide
confidentiality and is, therefore, not recommended. IKE supports authentication and can be
used with single DES or 3DES. However, DES provides weaker encryption capabilities than
3DES and is, therefore, not recommended.




Ref Doc 136, Ver. 1.0                                                                       26
1xEV-DO Roaming WhitepaperGuide                                                  Network Architecture




3.6.2 Indirect Interconnections

Indirect interconnections involve the use of one or more intermediary providers that function
as proxies between roaming partners. In 1xRTT and 1xEV-DO data roaming, these
intermediary providers are known as a CDMA packet data Roaming eXchange (CRX)
providers. Similar to GPRS Roaming eXchange (GRX) providers in GPRS roaming, CRX
providers are in the business of facilitating data roaming between carriers.

While the interconnection between roaming partners is indirect when utilizing a CRX
provider, the interconnection between a carrier and a CRX provider is direct. As such the
aforementioned issues associated with direct interconnections apply between carriers and
CRX providers.

3.6.3 CDMA packet data Roaming eXchange (CRX)

CDMA packet data Roaming eXchanges (CRXs) are third party providers that facilitate
CDMA data roaming between carriers by offering IP network interconnection, AAA services,
and billing clearing and settlement services. Each of the services offered by CRX providers
are generally available separately, allowing carriers to utilize only those services needed.
For example, a carrier may choose to offload RADIUS data clearing and financial net
settlement functions to a CRX provider but maintain direct bilateral interconnections with
roaming partners to support user data transport.

Major benefits of the CRX model include scalability and simplicity. As carriers scale their
roaming business with additional roaming partners and networks, the CRX can serve as a
centralized hub for interconnecting the carrier to multiple roaming partner networks. Carriers
using CRX model need only maintain direct interconnections with the CRX. The CRX, in
turn, would maintain direct or indirect connections with each of the roaming partners, thereby
providing the carrier with indirect connectivity to each partner. Between each pair of roaming
partners, the CRX acts as a proxy, forwarding traffic in both directions. For billing, this
model can greatly simplify the task of clearing and settling wholesale charges between
multiple partners.

3.6.3.1 CRX Reference model

The illustration below shows a basic CRX interconnection model in which each roaming
partner has a direct connection to the same CRX provider. The reference model defines
three interfaces: Xa, Xd, and Xi. Xd is the physical interface between carrier and CRX
provider. Xa is an application level interface carried over the Xd physical interface that
connects the carrier‟s AAA server with the CRX provider‟s proxy AAA server. Xi is an
application level interface is used by the CRX provider‟s data clearing and financial
settlement systems to exchange User Data Records (UDRs) in RADIUS accounting format.




Ref Doc 136, Ver. 1.0                                                                      27
1xEV-DO Roaming WhitepaperGuide                                                            Network Architecture




                Home Network                        CRX                  Visited Network

                         Border                     Border                     Border
                        Gateway                    Gateway                    Gateway
                                      Xd                           Xd
                                   user traffic                user traffic

                                  AAA traffic                  AAA traffic

                        Xa                                                        Xa


                         Home                       Proxy                     Visited
                         AAA                        AAA                        AAA

                                                        Xi

                                                  Clearing &
                                                  Settlement




                                  Figure 3-7: Basic CRX Model


3.6.3.2 CRX connectivity

The CRX backbone is designed to be a secure and closed network. While CRX providers
may use public IP addresses for uniqueness, network elements in the CRX provider network
are invisible and unreachable from the public Internet. The Xd interface represents the
physical connectivity between a carrier and the CRX provider network. The Xd interface
carries both user and signaling traffic. This may include user data, L2TP or MIP tunneled
data, or AAA traffic (via the Xa interface carried over Xd). To maintain the security of the
CRX provider network, the Xd interface between carrier and CRX must be implemented
using either secure private lines or VPN connections with IPSec security.

The Xa application level interface facilitates the exchange of authentication, authorization,
and accounting information using RADIUS protocols and attributes defined in IS-835. The
CRX proxies RADIUS messages between the carrier‟s AAA server and the roaming partner
either directly or via a peer CRX provider. In cases in which the RADIUS message cannot
be successfully routed, the CRX proxy AAA will respond appropriately to the carrier AAA
server.

Since all accounting information is forwarded through the CRX provider‟s AAA proxy server,
the CRX provider is able to use this information to provide optional billing clearing and
settlement services for the carrier. The Xi application level interface allows the CRX
provider‟s billing clearing and settlement systems to retrieve this accounting information in
the form of User Data Records (UDRs) from the AAA proxy server.




Ref Doc 136, Ver. 1.0                                                                               28
1xEV-DO Roaming WhitepaperGuide                                                        Network Architecture




3.6.3.3 L2TP or MIP tunneling through a CRX

The previous reference model showed simple connectivity between border gateways of
roaming partners and a CRX. The following illustration expands this model to show the
connectivity in a common scenario in which roaming partners implement L2TP or MIP
tunneling. In such a scenario, LNS or HA servers would be located behind the border
gateway in the home network and LAC or FA servers would be located behind the border
gateway in the visited network. The L2TP or MIP tunneling between partners would be
essentially transparent to the CRX. In addition, because the CRX network is secure and
both invisible and unreachable from the public Internet, IPSec would not be required for the
L2TP or MIP tunnels.



         Home Network                          CRX                        Visited Network

                    Border                     Border                       Border
                   Gateway                    Gateway                      Gateway
                                  Xd                           Xd

                             tunneled data                tunneled data

     LNS or HA                AAA traffic                  AAA traffic                LAC or FA

                   Xa                                                           Xa


                    Home                       Proxy                        Visited
                    AAA                        AAA                           AAA

                                                   Xi

                                             Clearing &
                                             Settlement




                    Figure 3-8: CRX Model with L2TP/MIP Tunneling


3.6.3.4 CRX Peering

For simplicity, the above CRX models show roaming partners connecting through the same
CRX provider. However, carriers are not required to use the same CRX provider to achieve
interconnection because CRX providers should participate in peering to ensure that roaming
partners utilizing different CRX providers are able to interconnect. The CRX peering model
involves the use of a neutral service provider acting as a central peering point for multiple
CRX providers. The central peering point service provider facilitates cross-connects
between any participating CRX providers and maintains Service Level Agreements (SLAs)
with each CRX provider to ensure QoS. Carriers should verify that a particular CRX provider
participates in peering and that QoS across multiple CRX provider networks can be provided
without compromising end-to-end services.




Ref Doc 136, Ver. 1.0                                                                             29
1xEV-DO Roaming WhitepaperGuide                                                  Network Architecture




3.7 Addresses
The two types of addresses used to route data roaming messages include the Network
Address Identifier (NAI) and the IP address. These addresses are discussed in the following
sections.

3.7.1.1 Network Address Identifier

The NAI identifies a roaming subscriber and the home network domain to which the
subscriber belongs. NAI information is used to route RADIUS packets between visited and
home AAA servers. Note that there are two NAI‟s used in 1xEV-DO. One is used for A12
device authentication; the other is used for AAA user authentication. Carriers may or may
not use the same NAI for both authentication events.

The NAI is defined to be a fully qualified network name of the form <user>@<realm> in
accordance with RFC2486. While many operators populate the <user> portion of the NAI
with the Mobile Station Identifier (MSID) used by the home network to identify the subscriber,
operators are free to populate this <user> portion with any value. Note that the best source
of MSID is from the airlink record received from the PCF. The <realm> portion of the NAI
should always be populated with a domain name unique to the roamer‟s home network.

Before a data session may be setup in the visited network, a PPP session must be
established between the mobile and the serving PDSN. Authentication of the subscriber
occurs after the Link Control Protocol (LCP) phase of this Point-to-Point Protocol (PPP)
session establishment. The mobile provides its NAI to the serving PDSN which uses this
NAI to send an Access-Request message to authenticate the subscriber. This request is
sent to the AAA in the visited network (VAAA) and forwarded to the AAA in the home
network (HAAA) for authentication. Routing is usually based on the realm portion of the NAI
but may, alternatively, be based on a translation of the MSID into a realm value. Once
authenticated by the HAAA, an Access-Accept message will be returned. Upon receipt of
this message, the PDSN continues with PPP session establishment.

While it is not recommended, it is possible to skip the authentication. In such cases, the
mobile would not send an NAI value to the PDSN and would not be authenticated. In the
absence of an NAI from the mobile, the PDSN may be able to construct an NAI using the
MSID received in the air link record from the PCF. However, this approach is problematic
since realm values may not be unique and the possibility exists for a roamer to be
authenticated by a realm other than the home network.

3.7.1.2 IP Addresses

IP addresses are assigned to each infrastructure element as well as to roaming subscribers
to provide routable addresses. These addresses may be public or private depending on the
architecture implemented by roaming partners.




Ref Doc 136, Ver. 1.0                                                                      30
1xEV-DO Roaming WhitepaperGuide                                                     Network Architecture




The assignment of public versus private IP addresses to infrastructure elements involved in
roaming will depend on the architecture being used and whether the carrier has sufficient
available public IP address. Note that assignment of a public IP simply implies the use of a
unique address that is officially reserved from the Internet addressing authority; it does not
imply visibility or accessibility from the public Internet.

Infrastructure elements in each roaming partner network are assigned IP addresses that are
topologically associated with that network. Therefore, roaming elements that must be
directly reachable from a partner network must accessible via public IP addresses. This may
involve assigning public IP addresses to these elements or configuring firewalls with NAT to
associate private IP addresses assigned to these elements with public IP addresses.
Elements that need to be accessible via public IP address include:


                          Table 3-1: Required Public IP Addresses

           Architecture        Elements that require Public IP addresses
           All                 Home and visited AAA servers (HAAA and VAAA)
           Simple IP           Home network application servers
           L2TP                L2TP network servers (LNS)
           Mobile IP           Home and foreign agents (HA and FA)

If carriers have sufficient public IP addresses available, it is recommended that additional
elements such as PDSNs and all application servers be assigned public IP addresses as
well. Even though it may not be required by the current architecture, assignment of public IP
addresses to these elements will allow for easier future support of other roaming
architectures.

Roaming subscribers may be assigned either public or private IP addresses. Because IPv4
addresses are continuing to become scarce, carriers with an insufficient pool of public IP
addresses often use network address translation (NAT) and assign private IP addresses to
roaming subscribers. NAT allows carriers to use a small group of public IP addresses to
provide a large number of privately addressed roaming subscribers with access to outside
networks. This approach also prevents outside users from knowing the private address of
the mobile.

The long-term solution to the IPv4 address scarcity issue is migration from IPv4 to IPv6
which replaces the 32 bit dotted-decimal format address (e.g. 120.12.5.70) with a 128 bit
colon-hex format address (e.g. 2125:0E34:2FB6:0003:00FF:024B:EF10:78C3). The IPv6
address provides 64 bits for the network address and 64 bits for the host address, providing
more than a sufficient number of unique addresses for the foreseeable future. However,
migration to IPv6 will take several years as it impacts the entire infrastructure of the Internet
as well as the carrier network. Carriers are encouraged to use IPv4 to implement roaming
and consider IPv6 as a future goal.



Ref Doc 136, Ver. 1.0                                                                         31
1xEV-DO Roaming WhitepaperGuide                                                  Network Architecture




3.8 Roaming architecture options
Data roaming can be enabled between roaming partners using any of the following
architectures: Simple IP (SIP), Layer 2 Tunneling Protocol (L2TP), or Mobile IP (MIP). Each
of these architectures has advantages and disadvantages. The choice of architecture will be
dependent upon the features most important to the carriers and will impact the infrastructure
equipment involved and selection or configuration of roaming handset equipment.


                      Table 3-2: Comparison of Roaming Architectures

Consideration            Simple IP               L2TP                  Mobile IP
Elements requiring       (H-, V-, & AN-AAA),     (H-, V-, & AN-AAA),   (H-, V-, & AN-AAA),
public IP addresses      PDSN, and home          LNS                   HA and PDSN/FA
                         application servers
Element that assigns     Serving PDSN            L2TP Network          Home Agent (HA)
IP address to mobile                             Server (LNS)
Network that owns        Visited network         Home network          Home network
mobile‟s IP address
IP address mobility      None                    None                  Yes – enabled by
                                                                       CoA provided by FA
Possible to allow        No – home network       Yes                   Yes
roamers to have          does not assign
static IP addresses      mobile‟s IP address
All user traffic         No                      Yes – L2TP tunnel     Yes – MIP tunnel
tunneled back to                                 between LNS and       between HA and
home network                                     PDSN/LAC              PDSN/FA
Internet access path     Directly from visited   Through L2TP tunnel   Through MIP tunnel
                         network to Internet     to home network,      to home network,
                                                 then to Internet      then to Internet
Direct access to         Requires remote         Yes – mobile device   Yes – mobile device
home network             access from visited     is essentially        is essentially
application servers      network                 “placed” in home      “placed” in home
                                                 network               network

The table above provides a comparison of key considerations associated with each roaming
architecture while the following subsections provide implementation details and
recommendations.

3.8.1 Simple IP

The SIP roaming architecture model is illustrated below. Unlike L2TP and MIP, the roaming
mobile device receives its IP address from the visited network rather than the home network.



Ref Doc 136, Ver. 1.0                                                                     32
1xEV-DO Roaming WhitepaperGuide                                                       Network Architecture




The IP address is assigned by the serving PDSN during the IPCP phase of PPP session
establishment. The visited network may assign the mobile a public IP address or may use
NAT and assign the mobile a private IP address. In either case, the IP address presented to
other networks will be topologically associated with the visited network.


    Home Network                                              Visited Network

                                             VPN Connection
                                                                  NAT




             PDSN                       MS/AT can                            PDSN
                                        access public
    MS/AT must create
                                        Internet directly
    data session
                                        from visited                    Visited network
    between visited and
                                        network                         assigns IP address to
    home networks to
                        Application                                     MS/AT. Requires
    access home
                          Server                                        NAT if private IP
    network application
                                                                        address assigned
    servers



                              Figure 3-9: Simple IP Roaming Model


Because the mobile‟s IP address is associated with the visited network, there is no need to
tunnel back to the home network before accessing external networks. If roamers are
primarily using their data service for Internet access, this model provides the advantage of
direct access to the public Internet without the tunneling overhead inherent in L2TP and MIP
architectures.

However, if roamers need to access application servers in the home network, they must
access them remotely, unlike L2TP and MIP where roamers have direct access to home
network resources. As such, SIP requires application servers in the home network to have
public IP addresses that are visible to the visited network and firewalls in the visited and
home networks must be configured to allow roamers to remotely access these application
servers.

SIP architecture is also unable to support static IP addresses for roamers and does not allow
IP address mobility between networks. In addition, if mobile devices require access to home
network DNS or application servers, the home operator must configure these servers with
public IP addresses and ensure that firewall configuration allows these servers to be
reachable from visited networks. These limitations may or may not be important issues for
carriers considering the SIP roaming architecture.

3.8.2 Layer 2 Tunnel Protocol (L2TP)

Before describing the L2TP roaming architecture model, the status of this model in the IS-
835 standard (CDMA2000 Wireless IP Network Standard) should be noted. While L2TP is a



Ref Doc 136, Ver. 1.0                                                                           33
1xEV-DO Roaming WhitepaperGuide                                                   Network Architecture




commonly used protocol defined by the IETF, it has not yet been included in IS-835.
Moreover, as of IS-835 revision D, compatibility issues exist between IS-835 QoS
mechanisms and L2TP. However, the L2TP model is expected to be addressed in IS-835
revision E.

The L2TP roaming architecture model is illustrated below. Based on Simple IP, the L2TP
roaming model adds L2TP Network Server (LNS) and L2TP Access Concentrator (LAC)
elements to enable the roaming mobile device to receive its IP address from the home
network. The IP address is assigned by the LNS in the home network during L2TP
negotiation. The home network may assign the mobile a public IP address or may use NAT
and assign the mobile an internal IP address. In either case, the IP address presented to
other networks will be topologically associated with the home network.


    Home Network                                             Visited Network

                         LNS                VPN Connection
                                                               L2TP Tunnel




             PDSN                        MS/AT must                     PDSN / LAC
                                         tunnel back to
                                         home network to
     MS/AT can directly                  access public
     access application                  Internet                     Home network
     servers in home    Application                                   LNS assigns IP
     network without      Server                                      address to MS/AT
     using NAT



                                Figure 3-10: L2TP Roaming Model


L2TP provides the home network with the advantage of controlling their roaming customer‟s
IP addresses while disburdening the visited network from having to allocate IP addresses for
inbound roamers. In addition, since the home network controls the IP address, static IP
addresses can be assigned to roamers if desired.

All user traffic is tunneled between the home and visited networks using an L2TP tunnel
between the LNS in the home network and the PDSN/LAC in the visited network. Like the
MIP model, the L2TP model combines tunneling and home network IP address assignment
to logically place the roamer in the home network. This provides roaming customers with
transparent access to home network application servers. In addition, since these servers
are directly accessible, they do not require public IP addresses as with the SIP model and
may be hidden from the visited network for increased security.

Note that L2TP tunneling differs from MIP tunneling. L2TP tunneling involves the
establishment of a bidirectional tunnel between the LNC and the PDSN/LAC using UDP




Ref Doc 136, Ver. 1.0                                                                      34
1xEV-DO Roaming WhitepaperGuide                                                                   Network Architecture




encapsulation. Within this tunnel, a PPP session is established between the mobile and the
LNS as illustrated below.


        Since roamer’s address is                    UDP Header
   2                                                 PPP Header                PDSN/LAC receives,
        topologically associated with home                                 3
                                                      IP Header                decapsulates, and forwards
        network, LNS intercepts IP packets.
                                                    Dest: 10.20.30.40          PPP frames to visiting roamer
        LNS forwards them on PPP
        session to roamer via UDP                       Payload
        encapsulated L2TP tunnel


                                                                                   PPP Session between
                                                                                     Mobile and LNS

 Home
 Network                               LNS                              PDSN/LAC            PPP Header
                                                                                             IP Header
                                                                                          Dest: 10.20.30.40
              Internet                                                                           Payload


                                        1     Packets are sent to
                                              roamer’s address
     IP Header
                                              (10.20.30.40)
  Dest: 10.20.30.40
       Payload
                                   `                                      Roamer with Home             Visited
                                                                         Address = 10.20.30.40        Network

                                Figure 3-11: L2TP Tunneling Example


While L2TP extends the SIP model with some of the advantages of the MIP model, it also
shares some disadvantages of both SIP and MIP. Like the SIP model, L2TP does not
support IP address mobility between networks. Like the MIP model, tunneling between
home and visited networks introduces overhead and management burden. This burden is
most obvious in the case of customers that primarily use data service for Internet access.
Rather than accessing the Internet directly from the visited network as with SIP, access is
provided from the home network and tunneled to the visited network.

3.8.3 Mobile IP

The MIP roaming architecture model is illustrated below. Although any of the architectures
discussed in this paper can be used to implement 1xEV-DO roaming between partners, MIP
is the recommended model. Similar to the L2TP model, MIP uses two additional elements to
enable the roaming mobile device to receive its IP address from the home network. These
elements are the Home Agent (HA) in the home network and Foreign Agent (FA) which is
part of the PDSN in the visited network, referred to as the PDSN/FA.




Ref Doc 136, Ver. 1.0                                                                                          35
1xEV-DO Roaming WhitepaperGuide                                                          Network Architecture




    Home Network                                              Visited Network

                          HA                 VPN Connection                         FA provides
                                                                MIP Tunnel          Care-of
                                                                                    Address



             PDSN                         MS/AT must                         PDSN / FA
                                          tunnel back to
                                          home network to
     MS/AT can directly                   access public
     access application                   Internet                     Home network
     servers in home    Application                                    HA assigns IP
     network without      Server                                       address to MS/AT
     using NAT



                               Figure 3-12: Mobile IP Roaming Model


Like the L2TP model, MIP provides the home network with the advantage of controlling their
roaming customer‟s IP addresses while disburdening the visited network from having to
allocate IP addresses for inbound roamers. Since the home network controls the IP
address, static IP addresses can be assigned to roamers if desired. In addition, MIP
supports IP address mobility across networks.

The MIP model is based on the mobile device being assigned an IP address and associated
with a Care-of-Address (CoA). The IP address of the mobile is associated with the home
network. This address is assigned by the HA during MIP registration and remains
unchanged for the duration of the session. The CoA is associated with the visited network.
This address is provided to the HA by the PDSN/FA for routing purposes.

A tunnel is established between the HA and the PDSN/FA. If the mobile moves into a visited
network served by a different PDSN/FA, the new PDSN/FA will provide the HA with a new
CoA and a new tunnel will be established between the same HA and the new PDSN/FA. IP
packets sent to a mobile‟s IP address are received at the home network by the HA. The HA
encapsulates these into IP packets addressed to the CoA and routes them to the PDSN/FA
via the tunnel as illustrated below. The PDSN/FA decapsulates these IP packets and
forwards them to the mobile.




Ref Doc 136, Ver. 1.0                                                                             36
1xEV-DO Roaming WhitepaperGuide                                                                        Network Architecture




   2
        Since roamer’s home address                     IP Header
                                                                                  3   PDSN/FA receives,
        is topologically associated with             Dest: 90.80.70.60
                                                                                      decapsulates, and forwards
        home network, HA intercepts                     IP Header                     packets on PPP session to
        IP packets. HA encapsulates                  Dest: 10.20.30.40
                                                                                      visiting roamer
        and routes them to Care-of-                      Payload
        Address (90.80.70.60)

                                                                                             PPP Session between
                                                                                             Mobile and PDSN/FA


 Home
                                        HA                                PDSN/FA with                PPP Header
 Network
                                                                         CoA = 90.80.70.60             IP Header
                                                                                                  Dest: 10.20.30.40
              Internet                                                                                 Payload


                                           1   Packets are sent
                                               to the roamer’s
                                               home address
     IP Header                                 (10.20.30.40)
  Dest: 10.20.30.40
       Payload
                                    `                                          Roamer with Home            Visited
                                                                              Address = 10.20.30.40       Network

                                  Figure 3-13: MIP Tunneling Example


While IP-in-IP encapsulation as described above is the default tunneling method used, GRE
encapsulation may be used as an alternative. GRE tunneling is requested by setting the “G”
bit in the header of the MIP Registration-Request message.

In addition, reverse tunneling is recommended from the mobile back to the HA since the
mobile‟s IP address is associated with the home network and will not be topologically correct
for the visited network. Reverse tunneling is requested by setting the “T” bit in the header of
the MIP Registration-Request message.

Like the L2TP model, the MIP model combines tunneling and home network IP address
assignment to logically place the roamer in the home network. This provides roaming
customers with transparent access to home network application servers. In addition, since
these servers are directly accessible, they do not require public IP addresses as with the SIP
model and may be hidden from the visited network for increased security.

Note that MIP tunneling is different from L2TP tunneling which essentially extends a PPP
session from the mobile to the home network LNS. MIP tunneling uses IP encapsulation
and routing between the HA and PDSN/FA. As such, both the HA and PDSN/FA must have
public IP addresses.

The MIP roaming architecture model provides distinct advantages over both SIP and L2TP.
As such, the MIP model is the generally recommended architecture for operators planning to
implement 1xEV-DO roaming.




Ref Doc 136, Ver. 1.0                                                                                              37
1xEV-DO Roaming WhitepaperGuide                                                             Security




                                                                    4. Security
4.1 Authentication Types
Each roaming architecture discussed in this guide involves multiple stages of authentication.
The following table provides a summary of the various types of authentication that should
occur with each architecture.


            Table 4-1: Authentication used with each Roaming Architecture

Arch    Authentication                         Mechanism
SIP     1. Mobile by access network            A12 authentication using CHAP
        2. Mobile by PDSN                      PPP authentication using PAP or CHAP
L2TP    1. Mobile by access network            A12 authentication using CHAP
        2. Mobile by PDSN/LAC                  PPP authentication using CHAP or PAP
        3. Between PDSN/LAC and LNS            L2TP authentication based on CHAP
        4. Mobile by LNS                       PPP authentication using PAP or CHAP
MIP     1. Mobile by access network            A12 authentication using CHAP
        2. Mobile by PDSN/FA                   MIP FA challenge authentication
        3. Between PDSN/FA and HA              IPSec SA or MIP FA-HA authentication
        4. Mobile by HA                        MIP MN-HA authentication

Background information on roaming security concepts, including authentication protocols
and functions, is provided in section 12. Security Concepts.


4.2 A12 Authentication
A12 authentication applies to all roaming architectures discussed in this guide because it
involves authentication by the access network before reaching the PDSN.              A12
authentication of mobile devices in 1xEV-DO serves the same function as HLR
authentication in 1xRTT and IS-95 systems; namely, to protect the network from access by
unknown mobile devices. Without A12 authentication, any mobile that roams into a carrier‟s
access network is able to access the PDSN serving that network. With A12 authentication,
the RNC in the access network is able to authenticate new roamers and prevent unknown
ones from communicating with the PDSN, hence protecting the PDSN from denial-of-service
(DOS) style attacks.




Ref Doc 136, Ver. 1.0                                                                     39
1xEV-DO Roaming WhitepaperGuide                                                            Security




                              RNC

                        IP




                 Serving AN     A12
                                         AN-AAA                    HAAA


                                                                   Home Network

                   Visited Network

                                    Figure 4-1: A12 Interface


A12 authentication is named for the A12 interface between the access network and the local
VAAA server illustrated above. A12 authentication of the roamer uses CHAP and is similar
to PPP authentication with CHAP. However, even if CHAP is being used for PPP
authentication, a separate CHAP secret key must be provisioned in the mobile device to
support A12 authentication (i.e. the device will not use the PPP CHAP secret key for A12
authentication even if the values are the same). Coordination is required to ensure that the
A12 CHAP key provisioned in the mobile device is the same as the A12 CHAP key
provisioned in the AAA server. For trouble shooting purposes, the NAI of the A12 CHAP key
should be different from the standard PAP/CHAP key, e.g. <bob>@<realm.com> and
<bob>@<a12.realm.com>. Note that is a CSIM/R-UIM is used in the mobile device, then it
is understood that the AN-AA CHAP key will be in the CSIM/R-UIM.

While specified as an option in IS-878, A12 authentication is strongly recommended. If a
carrier chooses not to support A12 authentication and, accordingly, not to provision their
devices with an A12 CHAP key, roaming customers using these devices will not be able to
acquire 1xEV-DO service in partner networks that require A12 authentication. This would be
a significant hindrance to roaming as A12 authentication is expected to be implemented by
most, if not all, carriers. This expectation was recently strengthened in the CDMA
Developers Group (CDG) International Roaming Team (IRT) when all carrier members
agreed to implement A12 authentication.


4.3 RADIUS Routing Issues
RADIUS authentication and accounting messaging between home and visited networks is
necessary to support data roaming service. In order to route messages to the home
network, the visited network must first be able to determine the home network to which a
roamer belongs. The recommended approach is to use the realm (i.e. domain name) portion
of the roamer‟s NAI (<user>@<realm>). This realm is resolved by the V-AAA or CRX to the
home network AAA (HAAA) IP address to which the message can be routed. Whether this
address resolution is performed by the visited network or offloaded to the CRX will depend




Ref Doc 136, Ver. 1.0                                                                    40
1xEV-DO Roaming WhitepaperGuide                                                              Security




upon where the mapping information is maintained and how routing is performed by the
visited network.
4.3.1 Non-unique realms

Realm-based routing works well as long as realms are unique. Scenarios have arisen,
particularly with the use of enterprise realms, in which non-unique realms are used. This
practice is problematic as it may allow service to be provided while bypassing the home
network. Suppose that XYZ Corporation uses multiple carriers to provide their employees
around the world with 1xEV-DO data service using the domain name xyz.com. Because the
company wants to ensure that only their employees access their company network, RADIUS
messages are proxied to the company‟s AAA server for authentication. This problem arises
during roaming when an XYZ employee roams in the network of another carrier that provides
service for xyz.com. When this happens, the xyz.com realm will be recognized by the visited
network and a RADIUS access request will be sent directly to the company‟s AAA server for
authentication rather than to the home network.          The roaming subscriber will be
authenticated by the company‟s AAA server and receive data service in the visited network;
however, the home network is completely bypassed and receives no revenue from the
session.

There are two solutions for this scenario. The recommended solution is to ensure that realm
names are unique. For example, carrier Alpha could support alpha.xyz.com while carrier
Beta supports beta.xyz.com and both carriers would still be able to proxy authentications to
the company‟s AAA server at xyz.com. This solution is simple and maintains the canonical
realm-based routing paradigm.

The less preferred solution is to route RADIUS messages based on the MSID contained in
the airlink record received from the PCF. Using this approach, the visited network would first
use the MSID of the roamer to determine the realm of the home network and then route
messages to this realm. Aside from being a non-standard AAA implementation, this solution
requires more coordination between partners since each carrier must provide a complete list
of MSID ranges to each partner using MSID-based routing. One variant of this solution
would be for CRX providers to offer this MSID to realm translation in their proxy AAA
servers. While it would still require significant coordination, the CRX providers are a more
central point of contact between multiple partners and could provide this translation as an
optional service.
4.3.2 Common NAI/Password Fraud Scenario

The common NAI/password fraud scenario involves the legacy practice of using a common
NAI/password to provide network access to all subscribers. While not recommended for
roaming implementations, there may be carriers that continue to use this implementation for
some time. The goal of common NAI/password is to reduce complexity using a common
password that is published by the carrier and well known to customers. The problem with
this approach in a roaming environment is that while the NAI/password is well known to




Ref Doc 136, Ver. 1.0                                                                      41
1xEV-DO Roaming WhitepaperGuide                                                                                     Security




customers, it is also easily obtained by malicious roamers from other networks that may
attempt to use it fraudulently.

                            3 Common NAI/Password are
                               recognized and authentication
                                                                               2 Roamer’s NAI includes
                               succeeds. Roamer is able to receive                 Partner A’s realm, so NAI
                               data service in visited network.                    and password are sent in a
             HAAA                                                                  RADIUS Access-Request to
                                                                                   Partner A for authentication


                                               VPN
       Partner A
                                                                                             VAAA
   Authenticates and
 receives bill for roamer
  that isn’t a customer



                                                VPN                            Partner B
                                                                                Roamer
                                                                                                     Visited
                                                                                                     Network
                                                                                                    Network used
                                                                                                     fraudulently
          Partner B                                   1 Roamer from Partner B network
                                                         fraudulently uses Partner A’s
   Bypassed and does not
                                                         common NAI/password during
   get paid for data session
                                                         authentication in visited network



                       Figure 4-2: Common NAI/Password Fraud Scenario

As illustrated above, roamers from other carriers may fraudulently use the well-known
NAI/password pair in a visited network. When this occurs, the visited network will use the
realm of the NAI provided by the roamer to route the RADIUS access request. The home
network that owns the NAI/password pair receives this access request even though the
roamer is not their customer. Since the password is recognized, the roamer is authenticated
successfully and is able to receive packet data service in the visited network. In such a
case, all three carriers lose. The home network of the roamer does not receive the RADIUS
messages and is not able to collect for the data session. The network using the common
NAI/password not only authenticates a roamer that is not their customer but receives a bill
for this roamer‟s data session. Finally, the visited network that was defrauded will likely not
be able to collect on the bill sent to the network using the common NAI/password since it
was not their customer.

The preferred solution to this scenario is for carriers to avoid using a common NAI/password
for all subscribers. By using unique password/keys for each subscriber, carriers can protect
themselves as well as their partners. However, if common NAI/password must be used,
alternate solutions include having the visited network use MSID-based routing or having the
home network verify that it owns the MSID of the roamer being authenticated.




Ref Doc 136, Ver. 1.0                                                                                           42
1xEV-DO Roaming WhitepaperGuide                                                             Security




4.4 Issues Common to Both SIP and L2TP
4.4.1 PPP Authentication

As the name implies, PPP authentication occurs during the establishment of a PPP session.
PPP authentication allows a peer to authenticate itself before allowing network layer packets
to be exchanged. Where PPP authentication is used depends on the roaming architecture.
For SIP and L2TP architectures, PPP authentication occurs between the mobile device and
serving PDSN. For L2TP, it may also occur between the mobile device and the home LNS.
For MIP, PPP authentication is unnecessary since authentication of the mobile device
occurs during MIP registration.


                                        Up                        Negotiate
                             Dead                 Establish       authentication
                                                    (LCP)         method




                                       Failure   Authenticate
                                                  (PAP/CHAP)


                          Down
                                                        Success


                                                   Network
                                                    (IPCP)




                                                    Wait for
                           Terminate              Termination




                        Figure 4-3: PPP Phases with Authentication


Whether PPP authentication is used during PPP establishment is determined by the
contents of the LCP Configure-Request message. If no authentication protocol is
requested in this message, no authentication will be performed. However, if PPP
authentication is desired, the configure request message will contain the preferred
authentication protocol to be used. This may be either Password Authentication Protocol
(PAP) or Challenge Handshake Authentication Protocol (CHAP).

If the mobile supports the requested authentication method, it will acknowledge the request
and proceed from PPP Establish to PPP Authenticate phase as illustrated above. However,
if the mobile supports a different method, for example PAP rather than CHAP, it may
negatively acknowledge the message with a request for the alternate method and the PDSN
will decide whether the alternate authentication method is acceptable.

Note that the above behavior assumes that the mobile is configured for SIP. MIP configured
mobiles will respond to the configure request with an LCP Configure-Reject message.
Since MIP mobiles are authenticated during MIP registration, the PDSN will resend the



Ref Doc 136, Ver. 1.0                                                                     43
1xEV-DO Roaming WhitepaperGuide                                                                                                  Security




configure request without an authentication option and treat the roamer as a MIP device.
Technically, it is possible for carriers to allow calls to proceed without any authentication;
however, this is not recommended.

4.4.2 PPP Authentication of Roamer by PDSN

In both SIP and L2TP architectures, the mobile is authenticated by the PDSN using PPP
authentication. PAP password or CHAP secret key information must be coordinated
between the roaming partners and provisioned into both the mobile device and AAA server.


                    Roamer                             PDSN                        Visited AAA                      Home AAA


                                                                                        VAAA                             HAAA


  Establish PPP link               PPP LCP
  and negotiate
  authentication method      Configure Request / Ack



  Authenticate mobile            PAP or CHAP                         RADIUS                           RADIUS
  device to the PDSN           Request / Ack or               Access Request / Accept          Access Request / Accept
                          Challenge / Resp / Success




                          Figure 4-4: PPP Authentication with Simple IP


Password/key information is typically coordinated and provisioned between the mobile and
the HAAA server in the home network. In such cases, the VAAA in the visited network will
act as a proxy for RADIUS messages between the serving PDSN and the HAAA.

Password/key information may also be provisioned in the VAAA to allow for local
authentication in the visited network. However, this approach requires the home network to
trust the visited network to authenticate their roaming customers without involving the home
network and not typically implemented.


4.5 Issues Specific to SIP
4.5.1 Precautions for Protecting the Home Network

Since roamers are assigned IP addresses by the visited network, application servers in the
home network must have public IP addresses to be accessible to these roamers. Firewalls
should be configured so that these servers are only visible and accessible from the visited
network via the secure connection and not from the public Internet.

With these servers protected from access by the public Internet, the remaining security
concern resides with access from the visited network. Since customers from multiple
carriers may be roaming in the same visited network, the issue is how to allow the home



Ref Doc 136, Ver. 1.0                                                                                                           44
1xEV-DO Roaming WhitepaperGuide                                                                                         Security




network‟s roaming customers to access home network servers while preventing other
carrier‟s roaming customer from doing the same.

The solution is to create separate pools of IP addresses in the visited network so that each
pool of addresses is associated with a different roaming partner. This will allow firewalls in
the home network to block access from any IP address that does not belong to its pool.
However, defining these address pools and configuring firewalls requires significant
coordination between roaming partners.

When public IP addresses are assigned to roamers, the visited network need only select
from the appropriate public IP address pool when assigning the address. However, as
illustrated below, when private IP addresses are used, an extra level of complexity is
introduced.


 Application server IP address                                                           Since roamer is a Partner A
 advertised to visited network           Firewall prevents                               customer, IP address will
 and accessible via VPN                  access from roamers                             be assigned from pool that
 connection but is not visible or        that are not assigned                           can be mapped to a Partner
 accessible from public Internet.        from Partner A public                           A public IP address
                                         IP address pool         Maps private IP
                                                                 address assigned to
                                                                 roamer to a Public IP
                                                                 address associated
         App                                                     their home network
       Server

                                                  VPN                                               Partner A
            Partner A          Firewall                                                              Roamer


                                                                                 NAT
                                                  VPN            Firewall
                                                                                         PDSN

         App
       Server                       Firewall                                                 Partner B
                                                    IP address assigned from a                Roamer
                                                    pool that can is mapped to
           Partner B                                Partner B public IP addresses.
                                                    If roamer attempts to access
                                                    Partner A network, he will be
                                                    blocked by Partner A firewall.       Visited Network



                       Figure 4-5: Using Simple IP with Private IP addresses


When the visited network assigns private IP addresses to roamers, assignment must be
done in such a way that the private IP address can be translated by the NAT server to public
IP addresses belonging to the appropriate pool for that roamer‟s home network. One
approach is to maintain both private and public IP address pools associated with each
roaming partner and configure the NAT server to translate between them.




Ref Doc 136, Ver. 1.0                                                                                                  45
1xEV-DO Roaming WhitepaperGuide                                                         Security




4.6 Issues Specific to L2TP
As mentioned previously in the Network Architecture section, while L2TP is a commonly
used protocol defined by the IETF, it has not yet been included in the IS-835 standard
(CDMA2000 Wireless IP Network Standard).            Moreover, as of IS-835 revision D,
compatibility issues exist between IS-835 QoS mechanisms and L2TP. However, the L2TP
model is expected to be addressed in IS-835 revision E.

L2TP involves the establishment of a secure L2TP tunnel between the serving PDSN/LAC in
the visited network and the LNS in the home network. Calls begin in the same fashion as
SIP architecture with PPP link establishment between the PDSN/LAC and the mobile and
PPP authentication of the mobile by the PDSN/LAC. Once the PDSN/LAC recognizes the
mobile as valid, it will contact the home LNS to establish an L2TP tunnel.
4.6.1 L2TP Tunnel Setup and L2TP Authentication of LAC / LNS

Before a tunnel session can be brought up, a Control Connection must first be established
between the PDSN/LAC and the LNS. It is during the establishment of this control
connection that the PDSN/LAC and LNS are able to authenticate each other using a CHAP-
like authentication mechanism provided by L2TP.


                 PDSN/LAC                                              Home LNS




                          Start-Control-Connection-Request (SCCRQ)
                                  Challenge to authenticate LNS


                            Start-Control-Connection-Reply (SCCRP)
                             Response to Challenge received in SCCRQ
                               Challenge to authenticate PDSN/LAC

                         Start-Control-Connection-Connected (SCCCN)
                             Response to Challenge received in SCCRP




     Figure 4-6: Control Connection Setup with L2TP Authentication of LAC / LNS


As illustrated above, the PDSN/LAC initiates authentication of the LNS by including a
Challenge Authentication Attribute Value Pair (AVP) in the control connection request
message sent to the LNS. Note that just as CHAP-based authentication, the CHAP-like
L2TP authentication relies on provisioning of secret keys for each peer and use of a
cryptographic hash function such as MD5 to generate and validate challenge responses.

The LNS returns an appropriate hash response in a Challenge Response AVP included
in the control connection reply message sent back to the PDSN/LAC. Using the same



Ref Doc 136, Ver. 1.0                                                                 46
1xEV-DO Roaming WhitepaperGuide                                                           Security




mechanism, the LNS also includes a Challenge AVP in this message to initiate
authentication of the PDSN/LAC.

Once the control connection is established, the tunnel session may be brought up. The
message sequence for establishing the tunnel session is illustrated below.


                  PDSN/LAC                                       Home LNS




                                 Incoming-Call-Request (ICRQ)

                                  Incoming-Call-Reply (ICRP)

                                Incoming-Call-Connected (ICCN)




                             Figure 4-7: Tunnel Session Setup


Once the tunnel is established, the PPP session will be re-established directly between the
mobile and the home LNS. At this time, it is recommended that the LNS authenticate the
mobile device. This can be accomplished using either dual or proxy PPP authentication.




Ref Doc 136, Ver. 1.0                                                                   47
1xEV-DO Roaming WhitepaperGuide                                                                                           Security




4.6.2 Dual PPP Authentication of Roamer


                     Roamer                PDSN/LAC              Visited AAA             Home LNS              Home AAA


                                                                    VAAA                                         HAAA


  Establish PPP link           PPP LCP
  and negotiate
  authentication method   Configure Req / Ack



  Authenticate mobile         PAP or CHAP             RADIUS                               RADIUS
  device to the PDSN       Request / Ack or      Access Req / Accept               Access Request / Accept
                          Chall / Resp / Succ

  Mutually authenticate                                             L2TP
  LAC and LNS, setup                               Control Conn Request / Reply / Connected
  L2TP tunnel                                      Incoming Call Request / Reply / Connected


  Renegotiate PPP link
                                                      PPP LCP
  and authentication
  method                                        Configure Request / Ack



  Authenticate mobile                               PAP or CHAP                                      RADIUS
  device to the LNS                                Request / Ack or                             Access Req / Accept
                                            Challenge / Response / Success




                          Figure 4-8: Dual PPP Authentication with L2TP

As illustrated above, this approach allows the LNS to simply perform PPP authentication
directly with the mobile. It is termed dual PPP authentication since the mobile is directly
authenticated twice: once by the PDSN/LAC and once by the home LNS.

Dual authentication allows both the PDSN/LAC and LNS to directly authenticate the mobile
device. However, it may require support for LCP renegotiation of the PPP link and is less
efficient than forwarding the LCP and authentication information to the LNS for proxy PPP
authentication.




Ref Doc 136, Ver. 1.0                                                                                                   48
1xEV-DO Roaming WhitepaperGuide                                                                                             Security




4.6.3 Proxy PPP Authentication of Roamer


                     Roamer                PDSN/LAC                Visited AAA             Home LNS              Home AAA


                                                                      VAAA                                         HAAA


  Establish PPP link           PPP LCP
  and negotiate
  authentication method    Configure Req / Ack


  Authenticate mobile to      PAP or CHAP               RADIUS                               RADIUS
  PDSN but do not           PAP Request or         Access Req / Accept               Access Request / Accept
  provide success ack      CHAP Chall / Resp

  Mutually authenticate
  LAC and LNS, setup                                                  L2TP
  tunnel, and forward                                Control Conn Request / Reply / Connected
  mobile response for                                Incoming Call Request / Reply / Connected
  proxy authentication

  Authenticate mobile to
  LNS based on info                                  PAP or CHAP                                       RADIUS
  from LAC, and send                             PAP Ack or CHAP Success                          Access Req / Accept
  success ack to mobile




                           Figure 4-9: Proxy PPP Authentication with L2TP


As illustrated above, Proxy PPP authentication leverages the fact that a PPP authentication
request or challenge response has already been received by the PDSN/LAC. In this
approach, the PDSN/LAC authenticates the mobile with its AAA but refrains from providing
the final ack/success response to the mobile.

Rather than having the LNS initiate another direct PPP authentication phase with the mobile
device, the PDSN/LAC forwards LCP configuration and PPP authentication information for
the mobile to the LNS. This information is included in Proxy LCP and Authentication AVPs
in the L2TP Incoming-Call-Connected message send from the PDSN/LAC to the LNS
to complete bring up of the L2TP tunnel session. This approach is termed proxy PPP
authentication since the initial PPP authentication between the mobile and PDSN/LAC is
essentially proxied to the LNS for completion.

Proxy PPP authentication allows the LNS to authenticate the mobile without requiring the
mobile to undergo direct authentications from both the PDSN/LAC and LNS. However,
because the LNS is relying on information forwarded by the PDSN/LAC, it is essential that
the LNS perform L2TP authentication on the PDSN/LAC itself during L2TP control
connection setup.




Ref Doc 136, Ver. 1.0                                                                                                     49
1xEV-DO Roaming WhitepaperGuide                                                             Security




4.7 Issues Specific to MIP
4.7.1 Rejection of PPP Authentication by Roamer

Since authentication is performed during MIP registration using the Foreign Agent Challenge
mechanism, PPP authentication is unnecessary and would only add additional delay if
performed. Therefore, if a serving PDSN initially proposes PPP authentication in the LCP
Configure-Request message, mobile devices configured for MIP should respond with an
LCP Configure-Reject.


                                   MIP Mobile                                    PDSN/FA




              PDSN initially requests             LCP Configure-Request
              PPP authentication.               [Authentication-Protocol] CHAP

              Mobile rejects it since              LCP Configure-Reject
              authentication will occur         [Authentication-Protocol] CHAP
              during MIP registration

                                                  LCP Configure-Request
              PDSN resends without
              the PPP authentication
              request                               LCP Configure-Ack




              Figure 4-10: Rejection of PPP Authentication by MIP Mobile


Upon receipt of the reject from the mobile, the PDSN should resend the configure request
without an authentication option to indicate that PPP authentication will not be performed.
This LCP configuration message exchange is illustrated above. Note that the rejection is
also generally an indication for the PDSN to send an agent advertisement message to the
mobile upon completion of PPP setup.
4.7.2 Authentication of Roamer by PDSN/FA

MIP provides a Foreign Agent Challenge mechanism for preventing replays of earlier
registrations and authenticating roamers using the standard AAA infrastructure. The FA
Challenge begins with the PDSN/FA including a randomly selected challenge value during
agent discovery. Specifically, the challenge value is included in a Challenge extension in
each agent advertisement message sent by the PDSN/FA to the mobile.




Ref Doc 136, Ver. 1.0                                                                      50
1xEV-DO Roaming WhitepaperGuide                                                                   Security




In response to the challenge, the mobile includes MN-FA Challenge and MN-AAA
Authentication extensions2 in the MIP Registration Request message sent by the
mobile to the PDSN/FA. The MN-FA Challenge extension simply contains the challenge
value that was received in the last agent advertisement from the PDSN/FA. This MN-AAA
includes an authenticator value generated by the mobile using an HMAC-MD5 function that
takes the registration request message contents and the MN-AAA shared key as inputs.
The MN-AAA also includes an SPI value of CHAP_SPI to identify the authentication
algorithm being used. Note that because the MN-FA Challenge extension is included prior
to the MN-AAA extension in the registration request message, it is included as an input to
the HMAC-MD5 computation.

Upon receiving the registration request from the mobile, the PDSN/FA will check this
challenge value to ensure that it matches the one sent in the last agent advertisement. This
check prevents registration replays. If the challenge value is unknown, bad, missing, or
stale, the PDSN/FA will respond with a registration reply message containing an appropriate
error code as illustrated below. This response by the PDSN/FA represents a failure of the
MIP registration attempt by the mobile.


                 MIP Mobile                                                     PDSN/FA




                                           Agent Advertisement
                                         [Challenge] challenge value

                                       Registration Request (RRQ)
                             [MN-FA Challenge] missing or with a challenge value
                          different than the one received in the agent advertisement

                                        Registration Reply (RRP)
                                                 Error Code



                       Figure 4-11: Failed FA Challenge Replay Check


If the challenge value from the mobile matches the last one sent, the PDSN/FA is assured
that the message is not a replay attempt of a previous registration and will proceed with
authentication of the mobile. The PDSN/FA uses the information in the registration request
to construct a RADIUS Access-Request message and sends this message to its local
AAA server to authenticate the challenge response from the mobile as illustrated below.



2 While commonly referred to as simply the “MN-AAA” or “MN-AAA Authentication extension,” this
attribute is technically the Generalized Mobile IP Authentication Extension with an MN-AAA
Authentication subtype.



Ref Doc 136, Ver. 1.0                                                                            51
1xEV-DO Roaming WhitepaperGuide                                                              Security




 MIP Mobile                          PDSN/FA                      Visited AAA     Home AAA


                                                                     VAAA           HAAA


               Agent Advertisement
                   [Challenge]


          Registration Request (RRQ)
                       [NAI]
                [MN-FA Challenge]              Access-Request
                    [MN-AAA]                     [User-Name]
                  [Home Agent]                 [CHAP-Password]          Access-Request
                     [MN-HA]                   [CHAP-Challenge]
                                                                         Access-Accept
                                                Access-Accept




              Figure 4-12: FA Challenge Authentication of Mobile by PDSN/FA


Similar to the CHAP key used for CHAP-based PPP authentication of the mobile in SIP and
L2TP, the MN-AAA key must be coordinated and provisioned in both the mobile and the
AAA server. Since the MN-AAA key on the network side is maintained in the HAAA, the
VAAA typically acts as a proxy server between the PDSN/FA and the HAAA.

The HAAA will compute its own value for the authenticator using its MN-AAA secret key and
accept or deny the registration based on whether this computed authenticator value matches
the one received in the Access-Request message.

To clarify the attributes present in the registration and access request message, selected
contents of these messages that are relevant to the FA challenge mechanism are illustrated
below. In particular, these details are useful in better understanding the authenticator value
and mapping of attributes by the PDSN/FA.




Ref Doc 136, Ver. 1.0                                                                      52
1xEV-DO Roaming WhitepaperGuide                                                              Security




  Registration Request (RRQ):
         [NAI] Type = 131
                 Length
                 MN-NAI = <MSID>@<realm>

        [MN-FA Challenge] Type = 132
              Length
              Challenge = challenge value from Agent Advertisement [Challenge]

        [Generalized Mobile IP Authentication Extension] Type = 36
               Subtype = MN-AAA Authentication subtype
               Length
               SPI = CHAP_SPI
               Authenticator = Computed using hmac_md5 function based on inputs of:
                               data: RRQ message contents prior to [MN-AAA] extension +
                                     Type, Subtype, Length, and SPI fields of [MN-AAA]
                               datalen: length of the data field
                               Key: MN-AAA secret key provisioned in mobile
                               KeyLength: length of the MN-AAA secret key



  Access-Request
        [User-Name] Type = 1
               Length
               String = MN-NAI from RRQ [NAI]

         [CHAP-Password] Type = 3
               Length
               CHAP Ident = high-order byte of challenge from RRQ [MN-FA Challenge]
               String = Authenticator from RRQ [MN-AAA]

         [CHAP-Challenge] Type = 60
               Length
               String = MD5 result + least order 237 bytes of challenge from RRQ [MN-FA
                        Challenge]. MD5 result is computed over RRQ message contents
                        prior to [MN-AAA] + Type, Subtype, Length, SPI fields of [MN-AAA]



Following successful authentication of the mobile by the PDSN/FA, MIP registration
continues. The next step in the registration process involves security between the PDSN/FA
and the HA before the registration request from the mobile reaches the HA. These steps are
described in the next section.
4.7.3 Security between the PDSN/FA and HA

It is recommended that an IPSec security association using ESP exist between the
PDSN/FA and the HA before allowing the MIP registration request message to be forwarded
from the PDSN/FA to the HA. Normally this SA will already be established since it is used
for all traffic between the PDSN/FA and the HA. However, if no SA currently exists when a
registration request is received at the PDSN/FA, it is recommended that a new one be
established before the request is forwarded to the HA.



Ref Doc 136, Ver. 1.0                                                                       53
1xEV-DO Roaming WhitepaperGuide                                                              Security




This SA may be established using X.509 certificate, root certificate, or pre-shared secret key
for IKE either statically configured or dynamically provisioned by the home RADIUS server.
In the case of dynamic provisioning, the request for the pre-shared secret for IKE is included
in the RADIUS Access-Request message sent by the PDSN/FA. This request for pre-
shared secret for IKE is always included in the case of dynamic HA assignment (i.e. RRQ
containing an HA address of 0.0.0.0 or 255.255.255.255).

While an IPSec security association using ESP between PDSN/FA and HA is the more
secure approach and offers the option for data encryption, carriers may alternately use the
MIP HA-FA Authentication extension with shared keys. HA-FA authentication is similar to
the MN-HA authentication method. HA-FA authentication involves inclusion of an HA-FA
Authentication extension in the MIP Registration-Request message with an
authenticator value generated using an HMAC-MD5 function that takes the registration
request message contents and the shared key as a inputs.
4.7.4 Authentication of Roamer by HA

MIP provides an MN-HA Authentication mechanism to allow the HA to authenticate the
mobile. MN-HA authentication is initiated during MIP registration with the inclusion of an
MN-HA Authentication Extension in the MIP Registration-Request sent by the mobile
to the PDNS/FA. This MN-HA includes an authenticator value generated by the mobile
using an HMAC-MD5 function that takes the registration request message contents and the
MN-HA shared key as a inputs. If desired and coordinated between the mobile and home
network, the MN-HA shared key provisioned in the mobile may be the same as the MN-AAA
key used in FA Challenge authentication.

Once authentication of the mobile by the PDSN/FA has been completed and security
associations between the PDSN/FA and HA have been verified (or using HA-FA
mechanism), the registration request containing the MN-HA will be forwarded to the HA.
Note that because the HMAC-MD5 function involves hashing the contents of the registration
request message, including any extensions prior to the MN-HA, the PDSN/FA will forward
the complete original registration request so that the same contents may be used in the
HMAC-MD5 computation by the HA.

Before the HA can proceed with computing the authenticator, it must first obtain its MN-HA
shared key from the HAAA. The HA requests the MN-HA key by sending an Access-
Request message to its HAAA and including an MN-HA SPI extension. This extension will
include the MN-HA SPI field received in the registration request message from the
PDSN/FA. The HAAA returns an encrypted shared MN-HA key to the HA in an Access-
Accept message.

Once the HA has the MN-HA shared key, it computes an authenticator value using the
contents of the registration request message and this MN-HA key. The HA compares this
computed authenticator to the one received in the registration request and returns a MIP
Registration Reply message to the PDSN/FA accepting or denying the request.
Finally, this reply will be forwarded by the PDSN/FA to the mobile.


Ref Doc 136, Ver. 1.0                                                                      54
1xEV-DO Roaming WhitepaperGuide                                                                                          Security




  MIP Mobile                           PDSN/FA                                          HA                    Home AAA


                                                                                                               HAAA

               Agent Advertisement
                    [Challenge]

          Registration Request (RRQ)
                       [NAI]
                [MN-FA Challenge]              þ      FA Challenge Complete
                    [MN-AAA]                   þ      SA between PDSN/FA and HA
                  [Home Agent]
                     [MN-HA]
                                                   Registration Request (RRQ)
                                                                [NAI]                         Access-Request
                                                         [MN-FA Challenge]                      [MN-HA SPI]
                                                             [MN-AAA]
                                                           [Home Agent]
                                                              [MN-HA]
                                                                                              Access-Accept
                                                     Registration Reply (RRP)                [MN-HA Shared Key]
            Registration Reply (RRP)               [Code] = 1 (registration accepted)
          [Code] = 1 (registration accepted)



                            Figure 4-13: Authentication of Mobile by HA


To clarify the MN-HA attribute in the registration request message, contents of this attribute
are illustrated below. In particular, these details are useful in better understanding the
authenticator value.


  Registration Request (RRQ):
         [MN-HA] Type = 32
                 Length
                 SPI = identifies authentication algorithm and mode (HMAC-MD5) and secret
                        (shared key) used in computing Authenticator
                 Authenticator = Computed using hmac_md5 function based on inputs of:
                                  data: RRQ message contents prior to [MN-HA] extension +
                                        Type, Length, and SPI fields of [MN-HA]
                                  datalen: length of the data field
                                  Key: MN-HA secret key provisioned in mobile
                                  KeyLength: length of the MN-HA secret key



To clarify MN-HA shared key distribution from the HAAA to the HA, contents of the access
request and accept messages are illustrated below. In particular, these details are useful in
better understanding the key encryption mechanism.




Ref Doc 136, Ver. 1.0                                                                                                 55
1xEV-DO Roaming WhitepaperGuide                                                                Security




  Access-Request
        [VSA] Type = 26
               Length = 12
               Vendor ID = 5535 (i.e. 3GPP2)
               Vendor-Type = 57 (i.e. [MN-HA SPI])
               Vendor-Length = 6
               Vendor-Value = binary value SPI received in RRQ [MN-HA]



  Access-Accept
        [VSA] Type = 26
               Length = 26 or greater
               Vendor ID = 5535 (i.e. 3GPP2)
               Vendor-Type = 58 (i.e. [MN-HA Shared Key])
               Vendor-Length = 20 or greater
               Vendor-Value = Salt (2 octets) + String (at least 16 octets), where
                               Salt is a value used to ensure uniqueness of encryption key.
                               String is an encrypted string created using Tunnel-Password
                               method which is based on MD5 and specified in RFC 2868.
                               Inputs include:
                                     - Plaintext string of data-length and password
                                     - MN-HA secret key
                                     - Authenticator from corresponding Access-Request
                                     - Contents of Salt field




Ref Doc 136, Ver. 1.0                                                                         56
1xEV-DO Roaming WhitepaperGuide                                                                     Billing




                                                                           5. Billing

Billing is a critical component 1xEV-DO roaming. This includes both the retail billing of
customers for outbound roaming, as well as the wholesale billing of roaming partners for the
servicing of inbound subscribers. Packet data billing roaming implementation requirements
are captured in two CDG references documents, “Packet Data Billing Requirements and
Implementation” (#116) and “CDMA Packet Data Roaming eXchange Guidelines” (#94).
The former provides recommendations for implementing packet data roaming on a bilateral
basis, while the latter provides information on packet data billing when a CRX is involved.


5.1 Infrastructure

The billing function for 1xEV-DO is primarily integrated into existing multifunctional
infrastructure elements, and the general architecture is based on existing Internet
technology. The relevant infrastructure elements include:

       PCF – passes airlink records on the A10/A11 interface to the PDSN describing
        aspects of the subscriber‟s data session
       PDSN – generates User Data Records (UDRs) which are passed to the AAA server
        using the RADIUS protocol
       AAA – stores UDRs and acts as a proxy server to a subscriber‟s home AAA in
        roaming scenarios
       Operator Mediation and Retail Billing Systems – process UDRs in order to bill
        the user and settle inter-operator roaming charges




                          Figure 5-1: Bill Infrastructure Elements

    These infrastructure elements and their billing call flow functions are described later.




Ref Doc 136, Ver. 1.0                                                                          57
1xEV-DO Roaming WhitepaperGuide                                                                  Billing




5.2 UDRs

1xEV-DO billing leverages the RADIUS protocol, which is an Internet standard defined in the
IETF RFC 2138. The 3GPP2 standard, IS-835, adapts the RADIUS protocol for use in
authentication and accounting procedures for 1xEV-DO data services. The specified
accounting function includes the definition of UDRs that are used to bill the subscriber.

UDR records are initially generated by the PDSN, and include several fields of information
about a user‟s data session. These records are passed to the AAA server for authentication
and accounting purposes.

5.2.1 Account-Request Records

UDRs are packet data call records used in authentication and billing. The specific types of
UDRs used for billing, which are defined in RFC 2866, are known as RADIUS Accounting-
Request records. These records are analogous to the Call Detail Records (CDRs) used for
voice service. There are three types of Accounting-Request UDRs:

       Accounting Start: Indicates the beginning of the data session
       Interim Update: Provides an update on the data session; useful if Accounting Stop
        record is “lost”
       Accounting Stop: Indicates the end of the data session

5.2.2 Attributes

Accounting-Request records contain fields of information known as attributes, which provide
information about a subscriber‟s data session. This information is eventually used to bill the
subscriber.

The IS-835 standard comprehensively defines these attributes; however, the presence of
some of these attributes is left optional to the operator. In order to ensure commonality
among operators, CDG Reference Document #116 specifies which attributes should be
included in Accounting-Request messages for packet data roaming.

The following table summarizes the common attributes that should be available for packet
data roaming. The columns represent the attribute type and 3GPP2 item number, the
attribute name, and indication of which accounting

„X‟ indicates the attributes that shall be supported.

‟A‟ indicates the attributes that may be supported depending on the roaming agreement.

In many roaming partnerships, operators will have specific needs for attributes that aren‟t
covered in the table. Operators should explicitly note these required.



Ref Doc 136, Ver. 1.0                                                                      58
1xEV-DO Roaming WhitepaperGuide                                                                                     Billing




            5-1: Recommend Accounting Attributes for Packet Data Billing

   Type                               Accounting-

  (Item)   Attribute          Start      Stop       Interim   Description

    1      User-Name           X          X           X       The name of the user to be authenticated

  26/10    BSID                X          X           X       Identifies the serving carrier by SID/NID pair
  (D4)

  26/16    Service Option      A          A           A       Identifies the CDMA network, 1x or EVDO
   (F5)

  26/24    Release                        X                   Specifies reasons for sending a stop record
  (F13)    Indicator

  26/30    Number of                      A           A       The total number of non-active to active transitions by
  (G9)     Active                                             the user
           Transitions

  26/44    Correlation ID      X          X           X       Identifies the correlation of Start/Stop/Interim records
  (C2)                                                        for one session

  26/48    Session                        X                   Determine the end of a user data session
  (C3)     Continue

  26/49    Active Time                    A           A       The total active connection time
  (G8)

  26/80    Last User                      A           A       This is a Timestamp of the last known activity of the
  (G17)    Activity Time                                      user.
                                                              This attribute is only used for the end user billing, not
                                                              used for the settlement between operators.

  26/142   Carrier ID          X*         X*          X*      Identify the serving carrier
   (D8)                                                       *) This attribute will be approved as IS835-D.

    31     Calling-Station-    X          X           X       Indicates user‟s IMSI or MIN
           ID

    40     Acct-Status-        X          X           X       Indicates whether this message is a Start/Stop/Interim
           Type

    41     Acct-Delay-Time     X          X           X       Indicates the time in seconds since the message has
                                                              been sent

    42     Acct-Input-                    X           X       The total number of octets in IP packets sent by the
           Octets                                             user

    43     Acct-Output-                   X           X       The total number of octets in IP packets sent to the
           Octet                                              user

    44     Acct-Session-ID     X          X           X       Unique accounting ID that allows start and stop
                                                              RADIUS records to be matched

    55     Event-Time          X          X           X       An event timestamp indicating when the
   (G4)                                                       Start/Stop/Interim takes place. Be used in the billing
                                                              cycle (in UTC)




Ref Doc 136, Ver. 1.0                                                                                          59
1xEV-DO Roaming WhitepaperGuide                                                                   Billing




5.3 1xEV-DO Roaming Billing Architecture

This section describes the overall architectural flow of billing for 1xEV-DO roaming. This
includes an overview of two different billing architectures: The bilateral billing architecture
and the CRX billing architecture.

5.3.1 Bilateral Billing Architecture

The bilateral billing architecture assumes that there is a bilateral roaming agreement
between roaming partners with no CRX provider involved. The following descriptions and
diagrams describe the call flow procedures and the infrastructure elements involved.

1. The roaming MS first establishes an 1xEV-DO session with the visited network. When
A12/AN-AAA authentication is completed, the PCF establishes an R-P session with the
PDSN. The PDSN receives airlink records from the PCF which the PDSN uses in the
construction of UDRs. Note that A-12/AN-AAA is only relevant to the authentication process
and is not part of the accounting or billing process.




                           Figure 5-2: Bilateral Billing Mode (1)


2. Once the MS has created a PPP session with the PDSN and is authenticated, the PDSN
creates an Accounting Start UDR record. The UDRs contain several attributes relevant to
the data session, including information captured in the airlink records received from the PCF.
This Accounting Start Record is then passed from to the PDSN to the VAAA, which acts a
proxy to the HAAA. RADIUS records, including accounting UDRs, are usually routed to the
HAAA based on the realm of the NAI received from the MS. In some implementations,
however, the MSID (IMSI/MIN/IRM) of the MS is used for routing. Routing of RADIUS is
covered in section 4.3 RADIUS Routing Issues.




Ref Doc 136, Ver. 1.0                                                                       60
1xEV-DO Roaming WhitepaperGuide                                                                   Billing




3. Throughout a mobile‟s data session, Interim Accounting UDR records may be generated
by the PDSN to provide updates on the status of the data session. These Interim Accounting
records are passed onto the HAAA. Interim Accounting records may be used as a
“safeguard” in that they allow for the billing of a portion of a data session in the event the
Accounting Stop Record is not received. For this reason, it is recommended operators
generate Interim Accounting Records as often as every 15 minutes.

4. When the mobile‟s data session has been completed, an Accounting Stop Record is
generated by the PDSN, sent to the VAAA, and then passed on to the HAAA. Upon
reception of the Accounting Stop Record, the data session is considered to be complete and
ready for mediation and billing.




                           Figure 5-3: Bilateral Billing Model (2)


5. The operator‟s mediation and billing systems are used both for the retail billing of roaming
subscribers as well as wholesale settlement between operators. The home operator‟s billing
system generates retail bills for roaming subscribers through the UDRs received from the
visited operator. Also, operators use UDR records to settle for the total amount of roaming
services used by each roaming partner. CIBER records are not currently used for the
settlement process of packet data services.




Ref Doc 136, Ver. 1.0                                                                       61
1xEV-DO Roaming WhitepaperGuide                                                           Billing




                          Figure 5-4: Bilateral Billing Model (3)


5.3.2 CRX Billing Model

The CRX billing architecture assumes that a CRX provider is used to facilitate 1xEV-DO
roaming between operators roaming partners. The following descriptions and diagrams
describe the call flow and the infrastructure elements involved.

1. The roaming MS first establishes an 1xEV-DO session with the visited network. When
A12/AN-AAA authentication is completed, the PCF establishes an R-P session with the
visited PDSN. The visited PDSN receives airlink records from the visited PCF which are
used in the construction of UDRs. Note that the AN-AAA is not part of the accounting or
billing process. The CRX is not relevant to this portion of the call flow.




Ref Doc 136, Ver. 1.0                                                               62
1xEV-DO Roaming WhitepaperGuide                                                                  Billing




                             Figure 5-5: CRX Billing Model (1)


2. Once the MS has created a PPP session with the visited PDSN and is authenticated, the
visited PDSN creates an Accounting Start UDR record. The UDRs contain several attributes
relevant to the data session, including information from the airlink records received from the
PCF. This Accounting Start Record is passed from the VAAA via the CRX network to the
BAAA of the CRX, which, in turn, passes it on to the HAAA. Operators have the option to
simply pass on any UDRs for all roaming mobiles to the CRX and depend on the CRX to
appropriately route the UDR to the correct home operator. The CRX will generally use the
realm supplied by the MS to route UDRs to the home operator, however MSID
(IMSI/MIN/IRM) is sometimes used.

3. Throughout a mobile‟s data session, Interim Accounting UDR records may be generated
by the visited PDSN to provide updates on the status of the data session. Interim Accounting
records are also passed through the BAAA of the CRX and on to the HAAA. Interim
Accounting records may be used as a “safeguard” in that they allow for the billing of a
portion of a data session in the event the Accounting Stop Record is not received. For this
reason, it is recommended operators generate Interim Accounting Records as often as every
15 minutes.

4. When the mobile‟s data session has been completed, an Accounting Stop Record is
generated by the PDSN and sent to the VAAA. It is subsequently passed on through the
BAAA of the CRX and on to the HAAA. Upon reception of the Accounting Stop Record, the
data session is considered to be complete and ready to be billed.




Ref Doc 136, Ver. 1.0                                                                      63
1xEV-DO Roaming WhitepaperGuide                                                                    Billing




                             Figure 5-6: CRX Billing Model (2)


5. In the CRX model, the home operator‟s billing systems is still used for the retail billing of
roaming subscribers. However, wholesale settlement between operators is performed by the
CRX provider. The CRX determines the amount that should be settled between the
operators based on the aggregate amount owed for all of the UDRs sent and received
through the BAAA between roaming partners over a certain period of time. The CRX
provider presents statement to each operator indicating how much is owed by each party.




                             Figure 5-7: CRX Billing Model (3)




Ref Doc 136, Ver. 1.0                                                                        64
1xEV-DO Roaming WhitepaperGuide                                                                    Billing




5.4 Back End Processing of UDR records
5.4.1 Retail Billing

In general, operators bill their own outbound 1xEV-DO roaming customers however they
wish. For example, the home operator might choose to bill the outbound roaming customer
on a time basis, while settlement between operators is usually done by byte count. For
billing an outbound 1xEV-DO roaming customer, the home operator is only able to use
attributes received from the visited operator.

5.4.2 Settlement

Settlement refers to the process of financial reconciliation between operators for packet data
services used by each roaming partner‟s subscribers in the visited network. Document #116
requires that settlement be done on a volume (byte) basis, and the operator generating the
greater net outbound roaming data traffic pay the amount owed for this net balance to the
roaming partner.

In bilateral settlement, the operators engage in the settlement process without a CRX
serving as a third party intermediary. However, it is common for the CRX provider to
facilitate the settlement function between operators.

Document #116 recommends the following the steps be taken in the implementation of the
settlement process:

    1. The time cycle for settlement should be determined by the home and visited
       operator. If used, the CRX provider should be involved in the establishment of the
       time cycle.

    2. According to the schedule of the established time cycle, the home and visited
       operators should collect and reconcile all UDRs associated with 1xEV-DO roaming.
       The reconciliation process should include comparing the total number of UDRs and
       the total number of bytes of data consumed. If a CRX partner is used, the CRX
       partner can perform the entire reconciliation process. However, it is recommended
       that both operators also perform the reconciliation process to check against the CRX
       provider‟s results.

    3. Each operator and/or the CRX should check UDR attributes for format correctness.
       This check should be performed upon receiving each UDR in a RADIUS Accounting
       message (start, stop, or interim). If a UDR fails this check, the operator should report
       the erroneous UDR during the settlement process. Erroneous UDRs should not be
       ratable.




Ref Doc 136, Ver. 1.0                                                                         65
1xEV-DO Roaming WhitepaperGuide                                                                        Billing




             -   Record length check: Verifies that the length of each UDR attribute is
                 within the allowable range and that the actual UDR attribute is the same as
                 the length field indicates.

             -   Numeric check: Verifies that each field is encoded with a proper format.
                 For example, the MSID field should not be populated with string that has
                 alphabetical information.

             -   Future record check: Verifies that a UDR timestamp is not in the future as
                 compared to the current time of the check.

             -   Aged record check: Verifies that a UDR timestamp is not delayed later
                 than the time which is determined by roaming agreement.

    4. Rating functions should be applied to the UDR data to generate financial information
       to be presented in the Settlement Report. U.S. dollars should be used for financial
       settlement. The IMF rate on one specific Exchange Rate Date of the month should
       be used for the next billing cycle.

5.4.3 Identifying the Visited Operator

In order for settlement to occur, operators must be able to determine from which roaming
partner a given UDR was sent. This could be done using the NAS IP address attribute (#”)
of the visited operator‟s PDSN or the carrier-ID attribute.

The NAS IP address attribute is the IP address of the PDSN on which the data call was
originated. If the NAS IP address is the method used, the home operator must keep a table
of the IP addresses of each roaming partner‟s PDSNs to determine from which operator
each UDR originated.

The carrier-ID attribute (#) is generally the preferred identifier as it provides a single, globally
unique way of identifying a given carrier. It is based on the MCC (mobile country code) and
MNC (mobile network code) values assigned to an operator.

5.4.4 Correlating Accounting Records

For both wholesale and retail packet data billing, operators generally need to correlate
related accounting records. For example, the Accounting Start and Accounting Stop records
from a data session generally need to be matched in order to determine the amount of time
and/or data volume that the subscriber consumed.

The Correlation-ID attribute is a unique value generated by the PDSN that can be used to
associate all of the accounting records for a single data session, i.e. all of the accounting
records created for a PPP session will have the same Correlation-ID. This allows mediation
and billing systems to properly process related records.



Ref Doc 136, Ver. 1.0                                                                            66
1xEV-DO Roaming WhitepaperGuide                                                                  Billing




Note that for inter-PDSN handoffs, e.g. Mobile IP or 1xRTT/1xEV-DO inter-PDSN handoffs,
the target PDSN will generate a new Correlation-ID for the subscriber‟s data session that
was handed off. If the operator wishes to correlate the accounting records generated by the
two different PDSNs, the mediation and billing systems need to perform this function without
the benefit of an identical Correlation-ID. The P-P interface supports the handing off of
Correlation-ID to the target PDSN, but this interface is not widely deployed.

The Accounting-ID attribute allows the correlation of a single “set” of accounting records: a
single Accounting Start, a single Accounting Stop, and any number of Interim Update
records. In some operator implementations, only a single Accounting Start and Accounting
Stop record are generated for a data session. However, some operators generate an
Accounting Start and Stop records each time an MS moves from Idle to Active state and vice
versa. This can result in several sets of accounting records for a single data session,
although every accounting record will share the same Correlation-ID.

5.4.5 Subscriber Identification

For retail billing, operators must associate accounting records with the appropriate
subscriber. This may be done in different ways. Operators often use the MSID attribute
(IMSI/MIN/IRM) since many billing systems use this value as a key differentiator among
subscribers.

Note that in order for MSID to be used effectively for billing 1xEV-DO service, A12
authentication must be used. For 1xRTT, the MSID attribute is populated by an airlink
record received from the RAN. Since MSID (IMSI/MIN/IRM) isn‟t used in the air interface for
1xEV-DO, the MSID attribute can‟t be populated by this method. Instead, it is populated by
a value in the AN known as the MN ID (Mobile Node Identification). If A12 authentication is
employed, a Callback-ID attribute is returned from the AN-AAA during the authentication
procedure and used to populated MN ID. Otherise, the AN must randomly generate an MN
ID which results in an inconsistent MSID attribute for the same suscriber across data
sessions.

5.5 Custom Billing Requirements

IS-835 standards and CDG Reference Document #116 provide a good basis for
understanding the requirements for 1xEV-DO roaming billing. However, many operators
have specific billing requirements that must be met by customized network implementations.

For example, operators might require the tracking of data traffic to specific destination IP
addresses to allow for differentiated billing. Supporting this functionality for roaming users
would be likely to place specific requirements on roaming partners.




Ref Doc 136, Ver. 1.0                                                                      67
1xEV-DO Roaming WhitepaperGuide                                                                 Billing




In cases where such customized implementations are used, operators should communicate
these implementation requirements to potential roaming partners early in roaming
agreement discussions.

5.6 Billing Testing

Testing to ensure that billing systems function correctly is an essential part of every 1xEV-
DO roaming implementation. The CDG document entitled “Packet Data E2E Bill Test Plan”
(#129) presents a suggested test plan for 1xEV-DO billing. This is further discussed in
section 7. Testing.




Ref Doc 136, Ver. 1.0                                                                     68
1xEV-DO Roaming WhitepaperGuide                                                                 Devices




                                                                        6. Devices

Roaming partners should have a full understanding of the devices which will roam in each
others networks. This should include an understanding of roaming device configurations
and the ramifications those configurations will have in the visited operator‟s network.

6.1 Device Provisioning

In order to roam effectively, devices must be provisioned such that they interoperate
correctly with the visited network. Provisioning refers to the assigning of values to fields in a
device‟s non-volatile (NV) memory which control its behavior in specific ways.

The following device NV items are particularly important in roaming scenarios, and operators
should pay particular attention to their provisioning.

It is highly recommended that operators use Over-the-Air (OTA) provisioning system to
configure 1xEV-DO devices. However, it should be noted that 1xEV-DO only devices are
not currently capable of supporting over the air provisioning, while hybrid devices do have
this capability.

6.1.1 PRLs

PRLs are especially important for roaming scenarios and there should be a well-defined
process for managing them. In the case of roaming, roaming partners should have an
agreed upon process for sharing network changes so that PRLs can reflect those changes.

CDG document #130, “PRL Design, Maintenance and Testing” provides detailed information
on PRLs as they related to data roaming. Worth noting is that the use of EV-DO “wildcards”
is discouraged, which #130 explains in detail.

6.1.2 CSIMs (R-UIMs)

CSIMs are highly secured, access control devices that enable secure subscriber
authentication, data portability across multiple devices, network access across different
technologies, and a robust platform for value added applications. C.S0065 from 3GPP2
provides detailed technical information on the CSIM and its precursor, the R-UIM (C.S0023).

One of the primary items stored in the CSIM is the PRL. This allows the subscriber to move
a PRL to different devices. The CSIM also plays the role of authentication and security
when inserted into a mobile device. Operators can provision CSIMs with information such as
NAIs, passwords and the roaming list used in EVDO authentication. This information plays a
vital role when switching devices, as the subscriber can move the CSIM between EVDO
enabled devices and gain network access with the same subscription, thereby enabling



Ref Doc 136, Ver. 1.0                                                                         69
1xEV-DO Roaming WhitepaperGuide                                                              Devices




plastic roaming. Operators have the option to provision the EVDO parameters in the CSIM at
the smart card vendor‟s facility (pre-provisioning) or after the CSIM enters the field (post-
personalization done via the OTAPA/OTASP procedure)

6.1.3 Authentication Credentials

Its imperative devices are provisioned with the proper authentication credentials required for
all roaming scenarios a device might encounter. Authentication credentials are provisioned
in NV memory. Most password fields are writable (changeable) but not readable.
Provisioning of authentication credentials likely includes:

    -   AN-AAA (A12) NAI: NAI used for A12 authentication.

    -   AN-AAA (A12) Password: CHAP password used for NAI authentication.

    -   NAI: NAI used for PDSN authentication.

    -   PAP Password: PAP password used for PDSN authentication.

    -   CHAP Password: CHAP password used for PDSN authentication.

    -   Mobile IP Key: Key used for authentication of the MS with the HA.

 For more information on the authentication process, refer to section 4. Security.

6.1.4 Mobile IP Behavior

An IS-683 parameter determines a device‟s behavior with respect to Mobile IP (3GPP2
C.S0016-C Section 3.5.8). This is particularly important for roaming since Mobile IP is a
method for implementing roaming. Mobile IP might not be available in all operators‟
networks. The three values with which this field can be populated are:

    -   Mobile IP Only: The MS will attempt to acquire Mobile IP service. If Mobile IP
        service is unavailable, the MS will give up.

    -   Mobile IP with Simple IP Fallback: The MS will attempt to acquire Mobile IP
        service. If Mobile IP service is unavailable, the MS will accept Simple IP service.

    -   Simple IP Only: The MS will request and accept Simple IP service.

6.1.5 DNS Addresses

Devices often will require the provisioning of DNS address. In most cases, the primary and
secondary DNS server addresses used by the MS to access the Internet are acquired during
the IPCP portion of PPP. However, specific application-associated DNS server addresses



Ref Doc 136, Ver. 1.0                                                                      70
1xEV-DO Roaming WhitepaperGuide                                                           Devices




are also sometimes required. Also, in some cases, the main DNS servers of an operator are
also provisioned into the MS which will preclude IPCP configuration. In these cases, the MS
will generally need to access DNS servers in the home operator‟s network remotely while
roaming.


6.2 Custom or Non-standard Device Behavior
Some operators might have specific requirements which result in custom or non-standard
device behavior. Such requirements and device implementations should be communicated
with potential roaming partners as early in roaming agreement discussions as possible.
Custom device behavior should be thoroughly analyzed to fully understand its impact in
roaming scenarios.




Ref Doc 136, Ver. 1.0                                                                   71
1xEV-DO Roaming WhitepaperGuide                                                                Testing




                                                                     7. Testing

The testing 1xEV-DO roaming between roaming partners encompasses all of elements and
functions of the implementation. CDG reference documents entitled “Packet Data Roaming
E2E Network Test Plan” (#121) and “Packet Data Roaming E2E Billing Test Plan” (#129)
provide roaming test plans for network/device and billing functions respectively In general,
testing should be done in as methodical and organized a fashion as possible, and results
should be recorded for future reference. Different parts of testing are usually done as
different portions of the roaming implementation are completed, making the particular
scenario available. This is preferable to performing testing as a single effort after the
completion of the roaming implementation. Incremental testing can allows problems to be
fixed early and can reduce potential delays. Operators should use tools for logging
information devices and network for test calls.

The following is an overview of elements involved in 1xEV-DO roaming and considerations
for their testing. These are presented in the rough order in which it is recommended that
each is tested.


7.1 Devices
The devices of each roaming partner should be tested to ensure they function properly in the
others network. Early testing of the device should include system selection testing. Correct
system selection behavior of roaming devices can be tested before network components
have been implemented. Once a PRL has been designed, devices may be brought to the
roaming partner‟s network to ensure that the device is correctly accessing the intended
system in the appropriate locations. This generally requires special software and tools.

 Other aspects of device testing must be done in conjunction with components of network
 testing. For example, the actual devices that will be used in roaming should be testing
 when authentication is being tested between operators.

 For all device testing, information about the device should be recorded, as well as the
 successful or unsuccessful completion of each test. Device information to be recorded
 should include:

   -   Device manufacturer
   -   Device
   -   MIN/IRM/IMSI
   -   ESN/MEID
   -   PRL version number




Ref Doc 136, Ver. 1.0                                                                    73
1xEV-DO Roaming WhitepaperGuide                                                                   Testing




7.2 Network
The testing of operator network connectivity and devices‟ ability to reach their home
networks is the next logical step in testing. This testing should be done incrementally so that
identified problems are more easily discovered. The components of network testing should
include:

7.2.1 Interconnectivity

The first step in network testing is to ensure that the two roaming partners‟ data networks are
interconnected. This essentially means testing the VPN, leased line, or CRX data
connection that should exist between the networks. Network infrastructure elements that
must be accessed by the roaming partner, e.g. the home agents, should be tested
accessibility. This test may be accomplished through any simple network tool such as “ping”
or “tracert”.

7.2.2 AAA connectivity

The next basic network test is to ensure that both roaming partners‟ AAA servers have
interconnectivity. This is important since operators often separate AAA and user data.

7.2.3 Home Network Access
Operators should also test the ability to remotely reach each application server or network
element that roaming subscribers should be able to reach. Again, this may also be
accomplished through any number of simple network tools.


7.3 Authentication
Authentication testing has both device and network components. In the testing of
authentication, authentication failure should also be tested. It is a good idea to inspect the
authentication UDRs for cases involving RADIUS authentication testing to ensure the
attributes are reasonable and correct. The testing of authentication should include the
following:

7.3.1 HLR Authentication

Because 1xEV-DO is generally deployed as an overlay to 1xRTT, and handoffs will usually
occur between the technology, hybrid devices should be tested to ensure that can perform
HLR authentication while access 1xRTT.

7.3.2 A12 Authentication

Each device should be tested to ensure it correctly performs A12 device authentication with
the AN-AAA. This should include PAP and/or CHAP authentication. Also, authentication
failure testing should be performed with various permutations of incorrect login credentials,
e.g. poorly formed NAI, incorrect password, incorrect realm, etc.




Ref Doc 136, Ver. 1.0                                                                       74
1xEV-DO Roaming WhitepaperGuide                                                                      Testing




7.3.3 PDSN Authentication

Similar to A12, devices should be tested for successful and unsuccessful authentication
attempts with the PDSN/AAA.

7.3.4 Mobile IP Authentication:

For devices that will use Mobile IP for roaming, Mobile IP authentication should be tested in
the roaming partner‟s network. As detailed in section 4.7 Issues Specific to MIP, there are
several components to successful Mobile IP authentication. Again, authentication failure
should also be tested.


7.4 Roaming Architecture Testing

The roaming architecture(s) employed by the two roaming partners should each be tested.
Note that each roaming partner‟s network could support any combination of the three
available architecture options. Also, the devices might require the use of any combination as
well. Testing should be done with each device expected to roam, and using each
required/available architecture. Roaming architectures could include:

7.4.1 Simple IP

Testing of Simple IP is means successful authentication of the device, and the device be
able to access the home network and public Internet. The best way to perform this test is
through the testing of applications, e.g. WAP and the WWW.

7.4.2 L2TP

This testing is similar to Simple IP except that the device should receive its IP address from
the home networks. Again, applications should be used to ensure connectivity.

7.4.3 Mobile IP

Mobile IP also entails the home operator assigning the IP address. Included in this test
should be the ability to move from one PDSN to another without losing layer 3 connectivity.
This should include both intra-operator and inter-operator PDSN handoffs.

For Mobile IP testing, the amount of time required to perform a registration should be noted.
Devices are usually configured to give up on a Mobile IP registration request after a specific
period of time has elapsed. If the registration time length is close to this threshold, this could
cause problems in the roaming implementation.




Ref Doc 136, Ver. 1.0                                                                          75
1xEV-DO Roaming WhitepaperGuide                                                                     Testing




7.5 Handoffs

Inter-technology handoffs should be tested in a roaming environment. For example,
handoffs between 1xRTT and EV-DO should be performed in the roaming partners‟ network
to ensure proper functionality.


7.6 Billing

Once network testing is completed, billing testing can commence. If the test calls made
during the network testing portion are carefully logged with date, time, MSID, and other
relevant information, these calls may be checked for proper billing.

7.6.1 UDR generation

The first step is to make sure that accounting UDRs were correctly generated by the visited
operators PDSN and correctly passed to the broker AAA, if used, and to the home operator
AAA. The attributes should be inspected to ensure they correctly match the device
characteristics, e.g. MSID and ESN/MEID. Also, the time related attributes and kilobyte
usage should be checked for correctness. For example, the duration of the data session as
reflected on the UDR should closely match the duration of the call logged during network
testing. More information regarding attributes and there content can be found in section 5.
Billing.

7.6.2 Settlement Testing

The final step of billing testing is to ensure that the settlement process is correctly
functioning. Recall that the settlement process could be performed by the CRX provider, or
between the operators themselves.

The settlement test is relatively simple. Both the roaming partners and the CRX provider, if
applicable, should compute the total charge owed between the operators based on the
roaming agreement plan. The amount of money computed should be the same among each
entity. If the amount differs, each organization should work to correct the error on a daily
basis until it is resolved. If it is not able to be resolved, then the difference of the disputed
amount of money should be split between the operators.




Ref Doc 136, Ver. 1.0                                                                         76
1xEV-DO Roaming WhitepaperGuide                                                       Conclusions




                                                          8. Conclusions

Roaming is a critical component of an operator‟s 1xEV-DO offering. It can help expand an
operator‟s footprint, provide addition revenue, and increase customer satisfaction with the
service.

Several areas need to be considered in the implementation of 1xEV-DO roaming. However,
once an operator has successfully internally deployed an 1xEV-DO system, successfully
implementing roaming requires a relatively minor amount of work.

While there are issues specific to roaming, these should be very manageable. With proper
planning and testing, 1xEV-DO should be possible for all operators. This will increase the
value of 1xEV-DO to customers, operators, and the CDMA industry.




Ref Doc 136, Ver. 1.0                                                                   77
1xEV-DO Roaming WhitepaperGuide                                                     References




                                                             9. References
[1]    3GPP2 A.S0008-0. Interoperability Specification (IOS) for High Rate Packet Data
       (HRPD) Access Network Interfaces. V3.0. May 2003.

[2]    3GPP2 X.S0011-C. cdma2000 Wireless IP Network Standard. V2.0. July 2005.

[3]    Airvana. “All-IP 1xEV-DO Wireless Data Networks.” Technical White Paper. 2001.

[4]    Bender, Black, Grob, Padovani, Sindhushayana, Viterbi. “CDMA/HDR: a bandwidth-
       efficient high-speed wireless data service for nomadic users.”           IEEE
       Communications Magazine, Vol. 38, July 2000, pp70-78.

[5]    IETF RFC 1334. PPP Authentication Protocols. October 1992.

[6]    IETF RFC 1661. The Point-to-Point Protocol (PPP). July 1994.

[7]    IETF RFC 1994. PPP Challenge Handshake Authentication Protocol (CHAP).

[8]    IETF RFC 2104. HMAC: Keyed-Hashing for Message Authentication.

[9]    IETF RFC 2401. Security Architecture for the Internet Protocol. November 1998.

[10]   IETF RFC 2406. IP Encapsulating Security Payload (ESP). November 1998.

[11]   IETF RFC 2409. The Internet Key Exchange (IKE). November 1998.

[12]   IETF RFC 2661. Layer Two Tunneling Protocol “L2TP.” August 1999.

[13]   IETF RFC 2794. Mobile IP Network Access Identifier Extension for IPv4.

[14]   IETF RFC 2809. Implementation of L2TP Comulsory Tunneling via RADIUS.

[15]   IETF RFC 2865. Remote Authentication Dial In User Service (RADIUS)

[16]   IETF RFC 3012. Mobile IPv4 Challenge/Response Extensions. November 2000.

[17]   IETF RFC 3024. Reverse Tunneling for Mobile IP, revised. January 2001.

[18]   IETF RFC 3344. IP Mobility Support for IPv4. August 2002.

[19]   Nogee, Allen.    In-Stat.   “3G Deployment Update.”   Report No. IN0502117GW.
       March 2005.

[20]   3GPP2 C.P0065 CDMA 2000 Application on UICC for Spread Spectrum Systems
       (To be published)

[21]   3GPP2 C.S0023 Removable User Identity module for Spread Spectrum Systems




Ref Doc 136, Ver. 1.0                                                                   79
1xEV-DO Roaming WhitepaperGuide                                                      Terminology




                                                      10. Terminology

 1xRTT           CDMA2000 Single Carrier (1x) Radio Transmission Technology. Also
                 known as 1x or IS-2000. CDMA channel hosts both voice and data with
                 data speed up to 150kbps (50kbps average)


 1xEV-DO         CDMA2000 Evolution, Data Only. Also known as 1xEV-DO, DO, or IS-
                 856. CDMA channel is dedicated to data services with data speeds up to
                 2.4Mbps (400-600kbps average)


 3DES            Triple (3x) Data Encryption Standard.      Also known as DESede.
                 Encryption algorithm uses a 168-bit key (i.e. three 56-bit DES keys).
                 Used during IKE


 AAA             Authentication, Authorization, and Accounting server.  Similar to
                 HLR/VLR servers in a the mobile voice network. Communicates using
                 RADIUS.


 AH              Authentication Header. Provides authentication and message integrity
                 but does not support data confidentiality. Has been effectively replaced
                 by ESP


 AN              Access Network. Data network providing network access to the MS/AT


 AN-AAA          Access Network AAA


 AT              Access Terminal. 1xEV-DO nomenclature for the Mobile Station (MS).
                 This document uses “MS/AT” to refer to packet data capable mobile
                 devices


 BAAA            Broker AAA


 CHAP            Challenge Handshake Authentication Procotol.  3-way handshake
                 protocol used during link establishment and periodically anytime
                 thereafter to authenticate a user. Uses MD5




Ref Doc 136, Ver. 1.0                                                                  81
1xEV-DO Roaming WhitepaperGuide                                                        Terminology




 CoA             Care-of Address. Used in Mobile IP architecture. Temporary address
                 assigned to a Mobile IP enabled device in foreign domain. Messages
                 addressed to the device are routed by the HA to the CoA


 CRTP            Enhanced Compressed RTP

                                                    rd
 CRX             CDMA2000 Roaming eXchange. 3 party provider that facilitates CDMA
                 packet data roaming between carriers by providing interconnection, AAA,
                 billing, and settlement services


 CSIM            CDMA Subscriber Identity Module: Defined in 3GPP2 C.P0065, an R-
                 UIM on UICC Smartcard Platform.


 DES             Data Encryption Standard. Encryption algorithm that uses a 52-bit key.


 DIAMETER        AAA protocol designed to succeed RADIUS.


 DH1             Diffie-Helman group 1 key exchange. Cryptographic protocol that uses a
                 768 bit modulus to allow two parties to establish a shared secret key over
                 an insecure network. Used during IKE


 DH2             Diffie-Helman group 2 key exchange. Cryptographic protocol that uses a
                 1024 bit modulus to allow two parties to establish a shared secret key
                 over an insecure network. Used during IKE


 DNS             Domain Name Server. Provides translation between domain names and
                 IP addresses


 ESP             Encapsulating Security Payload. Used by IPSec to provide secure
                 packet flows with authentication, data confidentiality, and message
                 integrity


 1xEV-DO         See 1xEV-DO


 FA              Foreign Agent. Used in Mobile IP architecture


 FQDN            Fully Qualified Domain Name




Ref Doc 136, Ver. 1.0                                                                     82
1xEV-DO Roaming WhitepaperGuide                                                   Terminology




 GRE             Generic Routing Encapsulation. Transport layer encapsulation used by
                 PPTP


 GRX             GPRS Roaming eXchange


 HA              Home Agent. Used in Mobile IP architecture


 HAAA            Home AAA


 HDLC            High-level Data Link Control


 HDR             High Data Rate. Term has been replaced by HRPD


 HMAC-MD5        keyed-Hash Message Authentication Code using MD5. Used by IPSec
                 ESP


 HMAC-SHA-1      keyed-Hash Message Authentication Code using SHA-1. Used by IPSec
                 ESP


 HRPD            High Rate Packet Data. Also known as HDR and 1xEV-DO


 IKE             Internet Key Exchange. Protocol used to setup an IPSec security
                 association. Used with IPSec to authenticate each peer, negotiated
                 security policy, and handle exchange of session keys. Formerly known
                 as ISAKMP


 IPCP            Internet Protocol Control Protocol


 IPSec           IP Security Protocol. Uses AH, ESP, and IKE to provide secure
                 connections over insecure IP networks


 IPSec SA        IPSec Security Association.         Created during IPSec connection
                 establishment to define the rules of that specific connection


 IS-856          1xEV-DO air interface


 IS-2000         1xRTT air interface




Ref Doc 136, Ver. 1.0                                                              83
1xEV-DO Roaming WhitepaperGuide                                                        Terminology




 ISAKMP          Internet Security Association and Key Management Protocol


 L2TP            Layer 2 Tunneling Protocol


 LAC             L2TP Access Concentrator


 LCP             Link Control Protocol


 LNS             L2TP Network Server


 MD5             Message-Digest algorithm 5.      Hash function used by authentication
                 protocols such as CHAP


 MIP             Mobile IP


 MN              Mobile Node. Mobile IP term for a node that can change its point of
                 attachment to the Internet while maintaining the same IP address (i.e. an
                 MS/AT that supports Mobile IP)


 MN ID           Mobile Node Identity. Uniquely identifies an MN within a carrier‟s
                 network and is used on A8/A9 and A10/A11 interfaces to enable packet
                 data session handoffs between ANs and between 1xEV-DO and 1xRTT
                 systems. Since MSID (IMSI/MIN/IRM) is not used in the 1xEV-DO air
                 interface, the MSID is set to the value of the MN ID by the AN.


 MS              Mobile Station. Referred to as Access Terminal (AT) in packet data.
                 This document uses “MS/AT” to refer to packet data capable mobile
                 devices


 MS/AT           Mobile Station / Access Terminal. Used in this document to refer to
                 packet data capable mobile devices


 MSID            Mobile Station Identifier. May be IMSI, MIN, or IRM.


 NAI             Network Access Identifier. Constructed from mobile‟s username (MSID)
                 and provider‟s domain name (realm). NAIs should be fully qualified
                 network names of the format: <MSID>@<realm>




Ref Doc 136, Ver. 1.0                                                                   84
1xEV-DO Roaming WhitepaperGuide                                                       Terminology




 NAS             Network Access Server. An access gateway that authenticates users
                 and authorizes access to an internal network or the Internet. In the
                 packet data architecture, the PDSN acts as the NAS


 NAT             Network Address Translation


 NCP             Network Control Protocol


 NID             Network ID


 PAAA            Proxy AAA


 PAP             Password Authentication Protocol. Simple authentication protocol that is
                 considered insecure since it transmits unencrypted ASCII passwords


 PCF             Packet Control Function


 PDSN            Packet Data Serving Node


 P-P             PDSN-PDSN interface


 PPP             Point-to-Point Protocol


 PPTP            Point-to-Point Tunneling Protocol


 QoS             Quality of Service


 RADIUS          Remote Access Dial In User Service


 Replay          A replay attack involves reuse of previous messaging (e.g. MIP
                 registration request). Systems that do not provide sequence integrity are
                 vulnerable to these types of attacks.


 RLP             Radio Link Protocol


 ROHC            Robust Header Compression




Ref Doc 136, Ver. 1.0                                                                   85
1xEV-DO Roaming WhitepaperGuide                                                      Terminology




 RN              Radio Network


 R-P             RN-PDSN interface


 RTP             Real Time Protocol. A thin protocol that adds timing and sequencing
                 data to support real time transport of audio and video data over packet
                 networks


 R-UIM           Removable User Identity Module (see CSIM)


 SHA-1           Secure Hash Algorithm 1


 SIP             Simple IP


 SO              Service Option


 SO33            Service Option 33. CDMA service option for 1xRTT


 SO59            Service Option 59. CDMA service option for 1xEV-DO


 SID             System ID


 TCP             Transmission Control Protocol


 UDP             User Datagram Protocol


 UICC            Universal Integrated Circuit Card in defined in 3GPP2 C.S0074


 VAAA            Visited AAA


 VJHC            Van Jacobson Header Compression


 VPN             Virtual Private Network




Ref Doc 136, Ver. 1.0                                                                 86
1xEV-DO Roaming WhitepaperGuide                                                     Overview of 1xEV-DO




                                        11. Overview of 1xEV-DO

History

During the last twenty years, a paradigm shift from fixed to mobile telephony has occurred as
customers have come to expect ubiquitous access to voice and voicemail services. Today,
with the popularity of web surfing and email, these customers are beginning to question why
the same level of convenience is not available for data. While technologies such as WAP
and 1xRTT have introduced mobile data services, the speeds provided by these
technologies are simply not sufficient to provide customers with a comparable experience to
the high-speed DSL and cable modem access technologies that are now commonplace. In
response to this need for mobile high-speed data access, 1xEV-DO was developed.

1xEV-DO began as a technology called High Data Rate (HDR). The HDR concept was
originally introduced in July of 2000 in an IEEE Communications Magazine article entitled
“CDMA/HDR: a bandwidth-efficient high-speed wireless data service for nomadic users.” 3
Later in 2000, this technology was recognized by ITU as a 3G IMT-2000 standard and
renamed to CDMA2000 1xEV-DO Release 0. Today, the technology is commonly referred
to as 1xEV-DO and is published as High Rate Packet Data (HRPD) in TIA/EIA/IS-856 and
3GPP2 C.S0024 (“CDMA2000 HRPD Air Interface Specification”). Note that when simply
referred to as 1xEV-DO, the term implies the Release 0 version of the technology. 1xEV-DO
Release A introduces improvements to 1xEV-DO and is described later in this section.

Overview

1xEV-DO is a version of CDMA2000 that provides spectrally efficient, high-speed data
service. 1xEV-DO was developed to meet the IMT-2000 3G requirement to provide greater
than 2Mbps of downlink bandwidth. Not only does 1xEV-DO meet this requirement but it
does so using only 1.25MHz of frequency spectrum, one quarter of what is required for
WCDMA.        1xEV-DO achieves this spectral efficiency by leveraging the same RF
characteristics used by IS-95 and 1xRTT.

Unlike other 3G technologies that attempt to combine voice and data, 1xEV-DO was
developed and optimized specifically for data service. While complementary to 1xRTT voice
networks, 1xEV-DO is deployed using a separate 1.25MHz frequency spectrum. This
separation of networks alleviates the inefficiencies that arise from attempting to use a voice-
oriented network to meet the very different requirements of voice and data transmission.




3 P. Bender, P. Black, M. Grob, R. Padovani, N. Sindhushayana, A. Viterbi. “CDMA/HDR: a
bandwidth-efficient high-speed wireless data service for nomadic users.” IEEE Communications
Magazine, Vol. 38, July 2000, pp70-78.



Ref Doc 136, Ver. 1.0                                                                          87
1xEV-DO Roaming WhitepaperGuide                                                   Overview of 1xEV-DO




Additionally, because the 1xEV-DO data network is separate from the 1xRTT voice network,
carriers can deploy data services without impacting their revenue-generating voice network.
1xEV-DO hybrid devices register with both the 1xRTT and 1xEV-DO networks and are
capable of receiving both voice and data services. This provides carriers with the flexibility
to selectively rollout 1xEV-DO service as needed since 1xEV-DO hybrid Access Terminals
(ATs) can receive service from both networks. If an AT with an active 1xEV-DO data
session roams out of 1xEV-DO coverage, the network can seamlessly handoff the data
session, albeit at a lower data rate, to 1xRTT without losing connectivity.

1xEV-DO Advancements

Unlike the voice-centric design of 1xRTT networks that support fixed data rates, 1xEV-DO
continually adapts the data rate being provided to each individual user to the highest rate
capable of being received by that user. Each mobile is responsible for constantly measuring
channel quality based on the pilot channel being received, using this measurement to
estimate the maximum data rate that can be supported, and reporting this information to the
base station. Every few milliseconds, the base station uses this estimate to adjust the data
rate to the mobile. A Hybrid ARQ scheme is used to ensure that the estimate provided by
the mobile is reliable. 1xEV-DO also introduces adaptive modulation to allow the base
station to select the modulation format (QPSK, 8-PSK, 16-QAM) best suited to the data rate
being provided, further increasing bandwidth efficiencies.

Because data services typically involve more data being received than sent by users, 1xEV-
DO data rates on the forward link (from the base station to the mobile) and reverse link (from
the mobile to the base station) are independent and asymmetric. While peak data burst
rates of up to 2.457Mbps on the forward link and up to 153.6kbps on the reverse link are
possible, average rates available to each user are generally estimated in the 300-600kbps
range. Actual throughput is dependent on a variety of factors including the number of active
users in a sector and the mobile environment in which service is being provided. However,
according to a 2005 “3G Deployment Update” report by In-Stat, data rates for 1xEV-DO
networks typically approach 700-900kbps4.

To maximize data rates on the forward link, 1xEV-DO combines a TDM scheme with CDMA.
Using this scheme, each mobile receives a time slot during which they can receive the full
power of the base station transmitter to achieve the highest data rate capable of being
received by that mobile. The algorithm used to schedule time slots is optimized to provide
load balancing between multiple users according to each user‟s average throughput. The
result is an increase in total throughput and more efficient sharing of available resources
among simultaneous active users




4 Nogee, Allen. “3G Deployment Update.” In-Stat report IN0502117GW. March 2005.




Ref Doc 136, Ver. 1.0                                                                      88
1xEV-DO Roaming WhitepaperGuide                                                    Overview of 1xEV-DO




Other advancements in 1xEV-DO include always-on operation, use of turbo coding, and
more streamlined macro-diversity procedures. 1xEV-DO always-on operation uses fast
connection setup, teardown, and reconnect capabilities to provide users with the perception
of being continuously connected while allowing the network to reuse bandwidth during
periods in which users are not actively transmitting or receiving during their data sessions.
Turbo coding error correction maximizes information transfer rates over noisy channels.
1xEV-DO uses a turbo coding scheme with 100-400% redundancy (approximately 33%
greater maximum redundancy on its forward link than 1xRTT)5 to overcome receiver noise
and interference. Finally, unlike 1xRTT systems that use the network to combat fading by
transmitting the same data from multiple base stations and involving the base station
controller in forward link soft handoff, 1xEV-DO streamlines this process by allowing each
mobile to measure the quality of pilot signals from all nearby base stations and tell the
network which base station should be used.

Beyond 1xEV-DO Release 0

Following the publication of Release 0 in 2000, work began on further improving the
advancements offered by 1xEV-DO. In 2004, the next generation of 1xEV-DO technology,
referred to as 1xEV-DO Release A, was published in TIA-856-A (3GPP2 C.S0024-A). 1xEV-
DO Release A builds upon the advancements offered by Release 0 by increasing data rates,
enhancing quality of service (QoS), and reducing latency. Peak data rates are increased
from 2.4Mbps to 3.1Mbps on the forward link and from 153.6kbps to 1.8Mbps on the reverse
link. Combined with QoS enhancements at both the user and end-to-end application level,
lower latency to support delay-sensitive applications, and variable paging to support real-
time applications, Release A expands the suitability of 1xEV-DO technology to an even
wider range of applications including voice-over-IP (VoIP), video conferencing, and network
gaming.

Moving forward, the ability of 1xEV-DO Release A to support VoIP traffic will allow for
evolution to a single network. The combination of robust QoS support, reduced latency, and
migration to VoIP for voice services will allow carriers to consolidate both voice and data
onto an all-IP, QoS-enabled packet network in which voice is simply one type of data
service. In addition to the cost reductions from managing a single network, carriers will be
able to recognize additional cost reductions from opportunities such as the ability to
backhaul IP traffic from base stations using low cost Ethernet connections instead of
dedicated TDM trunks. This migration will offer the true win-win scenario with lower
operational costs for carriers and richer VoIP-based services for users.




5 Airvana. “All-IP 1xEV-DO Wireless Data Networks.” Technical White Paper. 2001.




Ref Doc 136, Ver. 1.0                                                                       89
1xEV-DO Roaming WhitepaperGuide                                                   Overview of 1xEV-DO




Deployment status

Trials of 1xEV-DO Release 0 began as early as 2002. Today, commercial deployments of
1xEV-DO continue at a rapid pace with 1xEV-DO Release A deployments expected to gain
momentum in 2006 and 2007. Countries with 1xEV-DO deployments include Australia,
Bermuda, Brazil, Chile, Czec Republic, Guatemala, Indonesia, Israel, Laos, New Zealand,
Pakistan, Romania, South Korea, Taiwan, and the United States.6




6 Nogee, Allen. “3G Deployment Update.” In-Stat report IN0502117GW. March 2005.




Ref Doc 136, Ver. 1.0                                                                      90
1xEV-DO Roaming WhitepaperGuide                                                     Security Concepts




                                             12. Security Concepts
12.1 Secure connection concepts
12.1.1 Leased Line Connections

Direct interconnection between carriers can be accomplished via leased lines or VPNs.
Leased lines provide the benefit of being dedicated connections with guaranteed throughput.
As private connections, leased lines provide inherent security. Additionally, VPN and
encryption techniques may be employed over leased lines to provide additional security as
needed. However, leased lines are an expensive option in most cases.
12.1.2 Virtual Private Network (VPN) Connections

The alternative to leased lines are VPN connections. These virtual connections use IPSec
tunnels between carriers to provide secure transport over an insecure medium such as the
Internet. VPNs are frequently used by operators to implement packet data roaming.
12.1.3 Security Associations

A Security Association (SA) is a unidirectional secure connection between one peer and
another. For bidirectional communication between peers, two SAs must be established,
one in each direction. Typically an IPSec connection, an SA is uniquely identified by a set of
three parameters referred to as a triple. These parameters are described below:

        Security Parameter Index (SPI): a unique 32-bit number that allows a connected
        peer to identify the SA. The SPI is included in secure messages associated with an
        SA to allow the recipient to identify which SA governs the message

        IP Destination Address: IP address of the destination peer

        Security Protocol: Identifies the security protocol used with the SA (e.g. AH or ESP)
12.1.4 Encryption

Encryption allows data to be securely transported between peers across an insecure
medium such as the Internet. This is accomplished by encrypting data using an encryption
key at a source peer, sending this encrypted ciphertext across the insecure medium, and
decrypting the data using a decryption key at destination peer.

Encryption algorithms may be symmetric or asymmetric. Symmetric encryption algorithms
use the same key to encrypt and decrypt data. Examples of symmetric encryption algorithms
include DES, 3DES (block ciphers), RC2, RC4, RC5 (stream ciphers), AES and Rijndael (up
to 256 bits key length). Asymmetric encryption algorithms use different keys to encrypt and
decrypt data. Examples of asymmetric encryption algorithms include RSA, Diffie Hellman
and Elliptic Curves. Key lengths range from 512 bits to 2048 bits. Diffie Hellman is used
specifically for key management.



Ref Doc 136, Ver. 1.0                                                                      91
1xEV-DO Roaming WhitepaperGuide                                                   Security Concepts




Symmetric encryption algorithms such as 3DES are recommended for use in data roaming
applications. These algorithms are much faster than asymmetric encryption algorithms and
are able to handle large volumes of data.
12.1.5 IP Security (IPSec)

IPSec provides security services to enable secure communication between peers and
replaces the older Point-to-Point Tunneling Protocol (PPTP). IPSec services include
mechanisms for peers to agree upon security protocols and encryption keys and procedures
for using these selections to ensure secure data transport. Once two peers have agreed on
the encryption mechanism there is said to be a “security association” between them.

IPSec defines two security protocols: Authentication Header (AH) and Encapsulated Security
Payload (ESP). AH provides integrity and authentication using functions such as MD5 and
checks the integrity of the whole IP datagram including the IP header itself. ESP provides
confidentiality in addition to integrity and authentication. However ESP does not check the
integrity of the IP header, only the payload.

AH is not compatible with carrier networks that employ Network Address Translation (NAT).
AH will fail authentication since hashing is done across the outer IP header at the source
peer and NAT then changes IP addresses in this outer header, resulting in a different hash
value calculated by the destination peer.

ESP may work with NAT if checksum verification is turned off. The issue is that when NAT
changes the IP addresses in the outer IP header, it will also change the TCP checksum,
causing ESP authentication to fail since the TCP checksum is part of the data hashed by
ESP. If NAT does not change the TCP checksum, TCP/UDP verification will fail. Therefore,
ESP may work only if it can be passed through NAT with TCP checksums disabled or
ignored by the receiver.

IPsec can either be used in transport mode to directly encrypt the traffic between two peers
or in tunnel mode to build “virtual tunnels” between two networks. These virtual tunnels are
more commonly known as Virtual Private Networks (VPNs). The encapsulation used with
AH and ESP protocols for each mode are illustrated below.




Ref Doc 136, Ver. 1.0                                                                    92
1xEV-DO Roaming WhitepaperGuide                                                                  Security Concepts




             Original         Original
                                         TCP      Data
             Packet          IP header



               AH             Original     AH
          Tranport Mode                           TCP      Data
                             IP header   header
                                         Authenticated


                                                         Encrypted
               ESP            Original    ESP                           ESP       ESP
          Tranport Mode                           TCP      Data
                             IP header   header                        trailer   authen
                                                   Authenticated



               AH            new outer     AH      Original
                                                               TCP       Data
           Tunnel Mode       IP header   header   IP header
                                               Authenticated


                                                                  Encrypted

              ESP            new outer    ESP      Original                          ESP       ESP
                                                               TCP       Data
           Tunnel Mode       IP header   header   IP header                         trailer   authen
                                                    Authenticated


                          Figure 12-1: IPSec AH and ESP Protocols


12.1.6 Shared Key Distribution

Used for symmetric encryption and HMAC, a shared key environment allows peers to use
the same key for both encryption and decryption of data. As such, a method is needed to
allow keys to be shared in a secure and scalable manner. The simplest approach is to
simply share key information over telephone or email. However, this approach is inherently
insecure. Moreover, for carriers planning to scale their data roaming business to include
many partners with secure connections to each, a scalable approach to distributing these
keys quickly becomes a necessity.

Diffie-Hellman Key Exchange addresses this problem and Internet Key Exchange (IKE) uses
Diffie-Hellman to ensure that a shared key can be generated and shared across a public
connection in a way that is infeasible for anyone to work out the key. This shared key can
then be used with an encryption algorithm such as 3DES. IKE requires that each peer be
provisioned with a common secret key to support mutual authentication and generation of
new secret keys that can be used for encrypting traffic.

Note that firewall rules will need to be added to allow IKE traffic. IKE traffic is carried over
UDP to the Internet Security Association Key Management Protocol (ISAKMP) port.




Ref Doc 136, Ver. 1.0                                                                                   93
1xEV-DO Roaming WhitepaperGuide                                                   Security Concepts




12.2 Authentication Protocols
12.2.1 Password Authentication Protocol (PAP)

The Password Authentication Protocol (PAP) provides a simple method for a server (i.e.
PDSN or LNS) to authenticate a mobile device using a 2-way handshake. However, it does
not provide strong authentication since password information is sent as plaintext and can be
intercepted by any device snooping the message exchange. For this reason, CHAP is
generally recommended. The only type of authentication discussed in this guide that allows
for the use of PAP is PPP authentication.


   Roamer                          PDSN                                 VAAA      HAAA


                                                                        VAAA      HAAA


        PAP Authenticate-Request
               [Peer-ID] NAI                RADIUS Access-Request
         [Password] PAP password               [User-Name] Peer-ID
                                                   [Password]

                                          RADIUS Access-Accept/Reject
        PAP Authenticate Ack/Nack




                   Figure 12-2: Example of PAP-based Authentication


The example illustrated above is used to explain PAP-based authentication. In this example,
a roaming mobile device is being authenticated by a serving PDSN. Authentication begins
with the mobile sending an PAP Authenticate-Request message containing its Peer-ID
and Password. The peer-ID is typically the NAI of the mobile (e.g. <user>@<realm>). The
password is a value provisioned into both the mobile and the HAAA server. Note that the
realm portion of NAI should be a registered FQDN (fully qualified domain name).

Upon receipt, the PDSN constructs a RADIUS Access-Request message containing the
user name (i.e. peer-ID) and password received from the mobile and sends this message to
its local VAAA. Since the corresponding password information for the user is typically
maintained in the HAAA in the home network, the VAAA will serve as a proxy between the
PDSN and the HAAA.

The HAAA receives the access request and looks up a password value for the user name
from its database of provisioned information. Depending on whether this provisioned
password matches the received password, the HAAA will return a RADIUS Access-
Accept or Access-Reject message. This message is mapped to a PAP Authenticate




Ref Doc 136, Ver. 1.0                                                                    94
1xEV-DO Roaming WhitepaperGuide                                                     Security Concepts




Ack or Authenticate-Nack message and sent to the mobile to indicate whether
authentication was successful.

12.2.2 Challenge Handshake Authentication Protocol (CHAP)

The Challenge Handshake Authentication Protocol (CHAP) provides a method for peers to
authenticate themselves using a 3-way handshake that provides significant advantages over
PAP. These advantages include stronger authentication and protection against playback
attacks. Stronger authentication is provided by replacing plaintext password exchange with
the use of shared secret key information and a cryptographic hash function such as MD5 to
generate and validate challenge responses. Protection against playback and repeated trial-
and-error attacks is provided through the use of an incrementally changing identifier and
variable challenge value.

CHAP is recommended for PPP authentication of mobile devices. CHAP is also used by
A12 authentication and variants of CHAP are used by L2TP for authentication of LNS and
LAC servers and MIP for authentication of the mobile to the FA.


   Roamer                       PDSN                                        VAAA    HAAA


                                                                             VAAA   HAAA


            CHAP Challenge
               [Identifier]
            [Challenge Value]

            CHAP Response
                [Identifier]               RADIUS Access-Request
               [Name] NAI                     [User-Name] Name
            [Response Value]           [CHAP-Challenge] Challenge Value
                                   [CHAP-Password] Response Value & Identifier


                                        RADIUS Access-Accept/Reject
         CHAP Success/Failure




                   Figure 12-3: Example CHAP-based Authentication


The example illustrated above is used to explain CHAP-based authentication. In this
example, a roaming mobile device is being authenticated by a serving PDSN.
Authentication begins with a CHAP Challenge message containing an Identifier and
Challenge Value being sent to the mobile device. The identifier allows for correlation of
challenges and responses and is also used as an input in response value generation. The




Ref Doc 136, Ver. 1.0                                                                      95
1xEV-DO Roaming WhitepaperGuide                                                      Security Concepts




challenge value is a unique numeric value specific to the challenge attempt and unlikely ever
to be repeated.

Upon receipt of the challenge message, the mobile combines the received identifier and
challenge values with a provisioned secret key value and performs an RSA Message Digest
Algorithm (MD5) hash function on this combined information to generate a response value to
the challenge. This Response Value is then returned in a CHAP Response message to the
PDSN. This message will also contain the name of the mobile and the identifier that was
received in the challenge.

Upon receipt, the PDSN constructs a RADIUS Access-Request message containing the
User-Name, CHAP-challenge, and CHAP-password and sends this message to its local
VAAA. The user name is the mobile name received in the response message. The
challenge is the challenge value that was sent to the mobile in the challenge message. The
password consists of both the response value received from the mobile and the identifier
associated with the challenge.

CHAP authentication relies on corresponding secret key information provisioned in both the
device being authentication and the device issuing the challenge. Since this corresponding
secret key information is typically maintained in HAAA in the home network, the VAAA will
serve as a proxy between the PDSN and HAAA.

The HAAA receives the access request and looks up the secret key value for the user name
from its database of provisioned information. As done by the mobile, the HAAA will combine
the identifier and challenge values with its provisioned secret key value and perform an MD5
hash function on this combined information to generate a response value. Depending on
whether the HAAA response value matches the one in the receive CHAP-password, the
HAAA will return a RADIUS Access-Accept or Access-Reject message. This message
is mapped to a CHAP Success or Failure message and sent to the mobile to indicate
whether authentication was successful.


12.3 Authentication Functions
12.3.1 MD5 (Message Digest Algorithm)

MD5 is a cryptographic hash function. The function takes as input a message of arbitrary
length and produces as output a 128-bit “message digest” (a.k.a. “fingerprint”) of the input as
illustrated below.




Ref Doc 136, Ver. 1.0                                                                       96
1xEV-DO Roaming WhitepaperGuide                                                 Security Concepts




                  input message                          “message digest”
                                            MD5
                 (arbitrary length)                       of input (128-bit)


                                Figure 12-4: MD5 Algorithm


Use of MD5 should make it infeasible to produce a message with a target message digest or
to produce two different message inputs with the same message digest. MD5 may be used
to compress a message before being encrypted with a secret key. Because this algorithm is
designed to allow for compact coding and fast operation, it is often used with CHAP or
combined with HMAC for authentication.

12.3.2 HMAC-MD5 (Keyed-hashing with MD5 for Message Authentication)

HMAC is a mechanism for message authentication that uses a cryptographic hash function,
such as MD5 or SHA-1, in combination with a shared secret key. Used with the MD5, this
function is referred to as HMAC-MD5. HMAC-MD5 breaks up input data into 512 bit blocks
and iterates these blocks over a compression function to produce a 128 bit result.

                                       Inputs


            hmac_md5 (data, datalen, Key, KeyLength, authenticator)



                                                                    result of the
         Data stream and              Shared secret key and
                                                                 hmac_md5 function
       length of data stream            length of shared
                                                                     (128 bits)
        being authenticated            secret key used for
                                         authentication


                 Figure 12-5: HMAC-MD5 for MIP Authenticator values


This HMAC-MD5 function call illustrated above is the form used to compute authenticator
fields for MIP authentication extensions. However, specialized versions of the HMAC-MD5
function may be used for functions such as IKE pre-shared secret key distribution as
illustrated below.




Ref Doc 136, Ver. 1.0                                                                  97
1xEV-DO Roaming WhitepaperGuide                                                    Security Concepts




                                                     Inputs


        Key = hmac_md5 (RADIUS IP address, FA IP address, timestamp, ‘S’ Key)


          Figure 12-6: HMAC-MD5 for IKE pre-Shared Secret Key Distribution


Carrier input indicates that certain vendor equipment may be configurable to use global
HMAC_MD5 instead of MD5. As this is not the expected scenario, such configuration and
would result in interoperability problems during authentication. Therefore, it is recommended
to that carriers verify the authentication algorithms being employed by partners during
implementation to ensure compatibility.




Ref Doc 136, Ver. 1.0                                                                     98
1xEV-DO Roaming WhitepaperGuide                                                                                                  Call Flow Examples




                                                              13. Call Flow Examples

13.1 Simple IP (SIP) Roaming Architecture
13.1.1 SIP Call Setup Example Call Flow


       Roamer                                    PDSN                                 Visited AAA                               Home AAA


                                                                                            VAAA                                      HAAA


           PPP LCP Configure Request
                  (Authentication-Protocol)
 1
                PPP LCP Configure Ack


                   CHAP Challenge
                     (Challenge-Value)

                   CHAP Response                        RADIUS Access Request
                  (Name, Response-Value)                   (Authenticator, User-Name,              RADIUS Access Request
                                                        CHAP-Challenge, CHAP-Password)            (Authenticator, User-Name,
 2                                                                                             CHAP-Challenge, CHAP-Password)

                                                                                                   RADIUS Access Accept
                                                         RADIUS Access Accept                              (Authenticator)
                                                                  (Authenticator)
                    CHAP Success


           PPP IPCP Configure Request
            (0.0.0.0, IP-Compression-Protocol)
 3
             PPP IPCP Configure Ack
                       (IP-Address)



                                                    RADIUS Accounting-Request
                                                         (Authenticator, Acct_Session_Id,      RADIUS Accounting-Request
                                                            Acct_Status_Type = Start)              (Authenticator, Acct_Session_Id,
                                                                                                      Acct_Status_Type = Start)
 4
                                                                                              RADIUS Accounting Response
                                                   RADIUS Accounting Response                              (Authenticator)
                                                                  (Authenticator)



                                              Data Session Established

                       Figure 13-1: Simple IP Call Setup Example Call Flow


     (1) PPP link establishment phase. The Link Control Protocol (LCP) is used to open
         the PPP connection. During this phase, the PDSN negotiates the authentication
         protocol to be used in authenticating the roamer. The proposed authentication
         protocol may be Password Authentication Protocol (PAP) or Challenge Handshake
         Authentication Protocol (CHAP). As CHAP is the more secure method, it is shown
         in this example. The mobile acknowledges the configure request.




Ref Doc 136, Ver. 1.0                                                                                                                        99
1xEV-DO Roaming WhitepaperGuide                                                  Call Flow Examples




   (2) PPP authentication phase. During this phase, the negotiated authentication
       protocol is used to authenticate the roamer. In this example, CHAP is used. The
       three-step CHAP authentication procedure begins with the PDSN sending a
       challenge value to the roamer. The roamer uses its provisioned CHAP key to
       calculate a response value and returns this response to the PDSN for verification.
       The PDSN queries its local AAA to verify the challenge response provided by the
       roamer. Since the corresponding CHAP key is typically maintained in the home
       AAA server, the local AAA server proxies the request to the HAAA. The HAAA uses
       its provisioned CHAP key to calculate a challenge response value and compares
       this calculated value to the one provided by the roamer. Upon successful validation,
       the HAAA returns an access accept message which is proxied by the VAAA to the
       PDSN. The PDSN then confirms successful authentication to the roamer.

       Note that the RADIUS messages contain authenticator values to protect requests
       and responses. Calculation of these authenticator values involves a shared secret
       key between the PDSN and RADIUS server and an MD5 hash function.

   (3) PPP network layer protocol phase. The IP Control Protocol (IPCP) is used to
       configure and enable IP protocol modules between the roamer and the PDSN.
       During this phase, the roamer requests assignment of an IP address from the visited
       PDSN by including an IP address of 0.0.0.0. The request may also include a
       preferred IP compression protocol (e.g. Van Jacobson Compressed TCP/IP). The
       visited PDSN acknowledges the request and provides an assigned IP address to the
       roamer in this acknowledgement.

   (4) Accounting start. The PDSN initiates billing by sending an accounting start
       message to the local AAA server. This message is also forwarded to the home
       network to allow both visited and home networks to maintain usage data record
       information. However, the visited network always controls accounting for incoming
       roamers in its network, regardless of roaming architecture.

       Note that, like RADIUS authentication messages, RADIUS accounting messages
       are protected using authenticator values calculated using the shared secret key and
       MD5 hash function.

       Following the initial accounting start message, the PDSN may send one or more
       interim accounting messages. In the event that the accounting stop record is lost,
       these interim messages allow the visited network to bill for data usage as of the last
       interim accounting message. All subsequent accounting interim or stop messages
       associated with this data session will use the same Acct-Session-Id present in the
       accounting start message.




Ref Doc 136, Ver. 1.0                                                                    100
1xEV-DO Roaming WhitepaperGuide                                                                                     Call Flow Examples




13.1.2 SIP Call Teardown Example Call Flow


       Roamer                        PDSN                                Visited AAA                               Home AAA


                                                                               VAAA                                      HAAA


                                     Data Session Established

           PPP LCP Terminate Request
 1
             PPP LCP Terminate Ack


                                        RADIUS Accounting-Request
                                            (Authenticator, Acct_Session_Id,      RADIUS Accounting-Request
                                               Acct_Status_Type = Stop)               (Authenticator, Acct_Session_Id,
                                                                                         Acct_Status_Type = Stop)
 2
                                                                                 RADIUS Accounting Response
                                        RADIUS Accounting Response                            (Authenticator)
                                                    (Authenticator)



                                     Data Session Terminated

                Figure 13-2: Simple IP Call Teardown Example Call Flow


     (1) PPP link termination phase. The Link Control Protocol (LCP) is used to close the
         PPP connection. In this example, termination is initiated by the roamer and the
         PDSN acknowledges the terminate request.

     (2) Accounting stop. Once the PPP session is closed between the roamer and the
         PDSN, the PDSN stops billing by sending an accounting stop message to the local
         AAA server. The accounting stop message contains the same Acct-Session-Id that
         was present in the corresponding accounting start message. This message is also
         forwarded to the home network to allow both visited and home networks to maintain
         usage data record information.

        Note that, like RADIUS authentication messages, RADIUS accounting messages
        are protected using authenticator values calculated using the shared secret key and
        MD5 hash function.




13.2 Layer 2 Tunneling Protocol (L2TP) Roaming
Architecture
13.2.1 L2TP Call Setup Example Call Flow




Ref Doc 136, Ver. 1.0                                                                                                           101
1xEV-DO Roaming WhitepaperGuide                                                                                                                                    Call Flow Examples




     Roamer                                 PDSN/LAC                             Visited AAA                                 Home LNS                                  Home AAA


                                                                                        VAAA                                                                                HAAA


         PPP LCP Configure Request
                (Authentication-Protocol)
 1
              PPP LCP Configure Ack


                 CHAP Challenge
                   (Challenge-Value)

                 CHAP Response                      RADIUS Access Request
                (Name, Response-Value)                (Authenticator, User-Name,
                                                   CHAP-Challenge, CHAP-Password)                                    RADIUS Access Request
 2                                                                                                     (Authenticator, User-Name, CHAP-Challenge, CHAP-Password)

                                                                                                                      RADIUS Access Accept
                                                     RADIUS Access Accept                                                       (Authenticator)
                                                             (Authenticator)




                                                         L2TP Start Control Connection Request (SCCRQ)
                                                 (Protocol-Version, Host-Name, Framing-Capabilities, Assigned-Tunnel-Id, Challenge)

                                                           L2TP Start Control Connection Reply (SCCRP)
                                                      (Protocol-Version, Framing-Capabilities, Host-Name, Assigned-Tunnel-Id,
                                                                          Challenge-Response, Challenge)
 3
                                                        L2TP Start Control Connection Connected (SCCCN)
                                                                               (Challenge-Response)

                                                          L2TP Zero Length Body (ZLB) Acknowledgement


                                                                          L2TP Tunnel Established


                                                                     L2TP Incoming Request (ICRQ)
                                                                     (Assigned-Session-ID, Call-Serial-Number)

                                                                    L2TP Incoming Call Reply (ICRP)
 4                                                                             (Assigned-Session-ID)

                                                                 L2TP Incoming Call Connected (ICCN)
                                                 (Proxy-Authen-Type, Proxy-Authen-Name, Proxy-Authen-ID, Proxy-Authen-Response)


                                                          L2TP Zero Length Body (ZLB) Acknowledgement


                                                                                                                                            RADIUS Access Request
                                                                                                                                              (User-Name, CHAP-Challenge,
                                                                                                                                                    CHAP-Password)

 5                                                                                                                                            RADIUS Access Accept
                                                                                                                                                     (Authenticator)
                                                          CHAP Success


                                                 PPP IPCP Configure Request
                                                   (0.0.0.0, IP-Compression-Protocol)
 6
                                                    PPP IPCP Configure Ack
                                                              (IP-Address)



                                                 RADIUS Accounting-Request
                                                    (Authenticator, Acct_Session_Id,
                                                       Acct_Status_Type = Start)                                  RADIUS Accounting-Request
                                                                                                         (Authenticator, Acct_Session_Id, Acct_Status_Type = Start)
 7
                                                                                                                 RADIUS Accounting Response
                                                RADIUS Accounting Response                                                      (Authenticator)
                                                             (Authenticator)



                                                               Data Session Established

                                     Figure 13-3: L2TP Call Setup Example Call Flow


     (1) PPP link establishment phase. Same as SIP call setup.




Ref Doc 136, Ver. 1.0                                                                                                                                                        102
1xEV-DO Roaming WhitepaperGuide                                                 Call Flow Examples




   (2) PPP authentication phase (by PDSN/LAC). During this phase, the negotiated
       authentication protocol is used to authenticate the roamer. In this example, CHAP is
       used. The three-step CHAP authentication procedure begins with the PDSN/LAC
       sending a challenge value to the roamer. The roamer uses its provisioned CHAP
       key to calculate a response value and returns this response to the PDSN for
       verification. The PDSN/LAC queries its local AAA to verify the challenge response
       provided by the roamer. Since the corresponding CHAP key is typically maintained
       in the home AAA server, the local AAA server proxies the request to the HAAA. The
       HAAA uses its provisioned CHAP key to calculate a challenge response value and
       compares this calculated value to the one provided by the roamer. Upon successful
       validation, the HAAA returns an access accept message which is proxied by the
       VAAA to the PDSN/LAC.

       Normally, the PDSN/LAC would complete the CHAP authentication procedure by
       sending a success message to the roamer. However, since this example involves
       proxy authentication, the PDSN/LAC defers this final step to the home LNS. At this
       stage, the PDSN/LAC has authenticated the roamer and can proceed with L2TP
       setup. During L2TP setup, the challenge and response information will be
       forwarded to the LNS for authentication after the L2TP tunnel is established. Once
       the LNS has completed proxy authentication, it will provide the success message to
       the roamer.

       If this example had used dual PPP authentication instead of proxy authentication,
       the CHAP authentication between roamer and PDSN/LAC would be completed and
       a second CHAP authentication procedure would be initiated by the LNS after LT2P
       setup.

       Note that the RADIUS messages contain authenticator values to protect requests
       and responses. Calculation of these authenticator values involves a shared secret
       key between the PDSN and RADIUS server and an MD5 hash function.

   (3) Control connection establishment and tunnel authentication. In order to
       establish an L2TP tunnel, a control connection for the tunnel must be established.
       Establishment of the control connection involves assigning a tunnel ID, identifying
       L2TP version and framing capabilities, and mutual authentication between
       PDSN/LAC and LNS. Tunnel ID, protocol version, and framing capabilities are
       identified in the start-control-connection-request (SCCRQ) and start-control-
       connection-reply (SCCRP) messages. In addition, the request message includes a
       challenge value to allow the PDSN/LAC to authenticate the LNS. Likewise, in
       addition to the challenge response from the LNS, the reply message contains a
       challenge value to allow the LNS to authenticate the PDSN/LAC. The challenge
       response from the PDSN/LAC is contained in the start-control-connection-connected
       (SCCCN) message.




Ref Doc 136, Ver. 1.0                                                                  103
1xEV-DO Roaming WhitepaperGuide                                               Call Flow Examples




       The Zero-Length Body (ZLB) message is simply a control packet with only an L2TP
       header. ZLB messages are used for explicitly acknowledging packets on the reliable
       control channel when there are no further messages waiting in queue for a peer.

   (4) L2TP session establishment. L2TP sessions are triggered by incoming (from
       PDSN/LAC) or outgoing (from LNS) calls and can only be initiated once the tunnel
       and corresponding control connection have been established. This example
       involves an incoming call from the roamer. The PDSN/LAC sends an incoming-call-
       request (ICRQ) message with a session ID and call serial number. The LNS
       acknowledges the request with an incoming-call-reply (ICRP) message using the
       same session ID. Finally, the PDSN/LAC acknowledges the reply with an incoming-
       call-connected (ICCN) message. Since proxy authentication is being used in this
       example, the connected message also contains the proxy authentication information
       to allow the LNS to authenticate the roamer.

       The Zero-Length Body (ZLB) message is simply a control packet with only an L2TP
       header. ZLB messages are used for explicitly acknowledging packets on the reliable
       control channel when there are no further messages waiting in queue for a peer.

   (5) PPP authentication phase (by LNS). The LNS maps the proxy authentication
       information received during L2TP session establishment to an access request to the
       HAAA. The HAAA uses its provisioned CHAP key to calculate a challenge response
       value and compares this calculated value to the one provided by the roamer (and
       received by the LNS in the proxy authentication information). Upon successful
       validation, the HAAA returns an access accept message. The LNS then informs the
       roamer that authentication was successful, thus completing the CHAP authentication
       process that was started between roamer and PDSN/LAC.

   (6) PPP network layer protocol phase. The PPP session is extended through the
       L2TP tunnel between roamer and LNS. The IP Control Protocol (IPCP) is used to
       configure and enable IP protocol modules between the roamer and the LNS. During
       this phase, the roamer requests assignment of an IP address from its home LNS by
       including an IP address of 0.0.0.0. The request may also include a preferred IP
       compression protocol (e.g. Van Jacobson Compressed TCP/IP). The home LNS
       acknowledges the request and provides an assigned IP address to the roamer in
       this acknowledgement.

   (7) Accounting start. Same as SIP call setup.




Ref Doc 136, Ver. 1.0                                                                104
1xEV-DO Roaming WhitepaperGuide                                                                                                                             Call Flow Examples




13.2.2 L2TP Call Teardown Example Call Flow


     Roamer                   PDSN/LAC                                Visited AAA                                   Home LNS                                 Home AAA


                                                                          VAAA                                                                                 HAAA


                                                  Data Session Established
         PPP LCP Terminate Request
 1
          PPP LCP Terminate Ack


                                                      L2TP Call Disconnect Notify (CDN)
                                                              (Result, Assigned-Session-ID)
 2
                                            L2TP Zero Length Body (ZLB) Acknowledgement


                                         L2TP Stop Control Connection Notification (StopCCN)
                                                                 (Assigned-Tunnel-ID, Result)
 3
                                            L2TP Zero Length Body (ZLB) Acknowledgement


                                     RADIUS Accounting-Request
                                       (Authenticator, Acct_Session_Id,
                                          Acct_Status_Type = Stop)                                       RADIUS Accounting-Request
                                                                                                (Authenticator, Acct_Session_Id, Acct_Status_Type = Stop)
 4
                                                                                                        RADIUS Accounting Response
                                     RADIUS Accounting Response                                                      (Authenticator)
                                               (Authenticator)




                                                  Data Session Terminated

                       Figure 13-4: L2TP Call Teardown Example Call Flow


     (1) PPP link termination phase. Same as SIP call teardown.

     (2) Session teardown. L2TP session may be torn down by either PDSN/LAC or LNS.
         In this example, the PDSN/LAC initiates teardown using the call-disconnect-notify
         (CDN) message. The LNS acknowledges the notify with a ZLB message.

     (3) Control connection teardown. Once the L2TP session is torn down, the
         PDSN/LAC initiates teardown of the control connection and tunnel using the stop-
         control-connection-notification (StopCCN) message. The LNS acknowledges the
         notification with a ZLB message.

     (4) Accounting stop. Same as SIP call teardown.




Ref Doc 136, Ver. 1.0                                                                                                                                              105
1xEV-DO Roaming WhitepaperGuide                                                                                                                                      Call Flow Examples




13.3 Mobile IP (MIP) Roaming Architecture
13.3.1 MIP Call Setup Example Call Flow


      Roamer                                  PDSN/FA                            Visited AAA                                      HA                                    Home AAA


                                                                                       VAAA                                                                                 HAAA


          PPP LCP Configure Request
                  (Authentication-Protocol)

           PPP LCP Configure Reject
 1                (Authentication-Protocol)

          PPP LCP Configure Request

               PPP LCP Configure Ack


          PPP IPCP Configure Request
                 ( IP-Compression-Protocol)
 2
            PPP IPCP Configure Ack


          ICMP Router Advertisement
                (Mobility-Agent-Advertisemnt,
                Care-of-Address, Challenge)

 3        MIP Registration Req (RRQ)
             (Lifetime, 0.0.0.0, Home-Agent,
         Care-of-Address, NAI, MN-FA-Challenge,
                     MN-AAA, MN-HA)



                                                    RADIUS Access Request
                                                      (Authenticator, User-Name,
                                                   CHAP-Challenge, CHAP-Password)                                       RADIUS Access Request
                                                                                                      (Authenticator, User-Name, CHAP-Challenge, CHAP-Password)
 4
                                                                                                                        RADIUS Access Accept
                                                     RADIUS Access Accept                                                    (Authenticator)
                                                            (Authenticator)




 5                                                  Assume IPSec SA already exists between PDSN/FA and HA

                                                                    MIP Registration Request (RRQ)
                                                                 (Lifetime, 0.0.0.0, Home-Agent, Care-of-Address,
                                                              NAI, MN-FA-Challenge, MN-AAA, Home-Agent, MN-HA)
                                                                                                                                          RADIUS Access Request
                                                                                                                                               (Authenticator, MN-HA-SPI)

 6
                                                                                                                                           RADIUS Access Accept
                                                                      MIP Registration Reply (RRP)                                       (Authenticator, MN-HA-Shared-Key)
          MIP Registration Reply (RRP)                         (Code = registration accepted, Lifetime, Home-Address)
               (Code = Registration Accepted,
                  Lifetime, Home-Address)

                                                                          MIP Tunnel Established


                                                  RADIUS Accounting-Request
                                                    (Authenticator, Acct_Session_Id,
                                                       Acct_Status_Type = Start)                                  RADIUS Accounting-Request
                                                                                                        (Authenticator, Acct_Session_Id, Acct_Status_Type = Start)
 7
                                                                                                                 RADIUS Accounting Response
                                                  RADIUS Accounting Response                                                 (Authenticator)
                                                            (Authenticator)



                                                                Data Session Established

                                       Figure 13-5: MIP Call Setup Example Call Flow


     (1) PPP link establishment phase. The Link Control Protocol (LCP) is used to open
         the PPP connection. Because MIP registration will include authentication of the
         roamer by the PDSN/FA, PPP authentication is unnecessary and undesirable.
         Therefore, as shown in this example, when the PDSN/FA proposes an
         authentication protocol in the LCP configure request, the mobile rejects the request.



Ref Doc 136, Ver. 1.0                                                                                                                                                          106
1xEV-DO Roaming WhitepaperGuide                                                Call Flow Examples




       Upon rejection, the PDSN/FA resends the request without a proposed authentication
       protocol to indicate that authentication will not be performed.     The mobile
       acknowledges this request.

   (2) PPP network layer protocol phase. The IP Control Protocol (IPCP) is used to
       configure and enable IP protocol modules between the roamer and the HA.
       Because the HA will assign the roamer its IP address during MIP registration, no IP
       address is provided in the IPCP configure request. Note that inclusion of an IP
       address would be interpreted by the PDSN/FA as a request for SIP while absence of
       an IP address is interpreted as a request for MIP. The preferred IP compression
       protocol (e.g. Van Jacobson Compressed TCP/IP) may still be requested. The
       PDSN/FA acknowledges the configure request.

   (3) Agent advertisement and MIP registration request. The PDSN/FA begins
       sending an operator configurable number of agent advertisements to the mobile
       immediately following negotiation of PPP.          These advertisements provide
       information such as the foreign agent care-of-address(es), the maximum MIP
       registration lifetime, and whether minimal encapsulation, GRE encapsulation, and
       reverse tunneling are supported. Also included in the agent advertisement is an FA
       challenge value used by the PDSN/FA to authenticate the roamer.

       Note that the maximum MIP registration lifetime value in the agent advertisement
       must be less than the PPP inactivity timer.

       The mobile initiates MIP registration using the MIP registration request (RRQ)
       message. Upon receiving this message, the PDSN/FA will stop sending additional
       agent advertisements. This RRQ message contains the following information:
           -   Bits indicating simultaneous bindings, broadcast datagrams, decapsulation
               by mobile, minimal encapsulation, GRE, and reverse tunneling
           -   Lifetime: Lifetime of the registration
           -   Home Address: Home IP address of 0.0.0.0
           -   Home Agent: IP address of the roamer‟s HA for the far end of the tunnel
           -   Care-of-Address: IP address for the local end of the tunnel
           -   Identification: used for matching replies to the request
           -   NAI extension: name of roamer (<MSID>@<realm>)
           -   MN-FA Challenge extension: FA challenge value from agent advertisement
           -   MN-AAA Authentication extension: Response to FA challenge
           -   MN-HA Authentication extension: used by HA to authenticate roamer

   (4) FA Challenge Authentication. Before sending the RRQ, the mobile uses its MN-
       AAA shared key to compute a challenge response to the challenge value received in
       the agent advertisement. This challenge response is included in the MN-AAA
       authentication extension of the RRQ. Upon receiving the RRQ, the PDSN/FA


Ref Doc 136, Ver. 1.0                                                                    107
1xEV-DO Roaming WhitepaperGuide                                                  Call Flow Examples




       queries its local AAA to validate the roamer based on this authentication information.
       Since the MN-AAA shared key is typically maintained in the home AAA, the VAAA
       proxies the request to the HAAA. The HAAA uses its provisioned MN-AAA shared
       key to calculate a challenge response value and compares this calculated value to
       the one provided by the mobile. Upon successful validation, the HAAA returns an
       access accept message which is proxied by the VAAA to the PDSN/FA.

   (5) Security between PDSN/FA and HA. The path between PDSN/FA and HA is
       typically secured using an IPSec security association (SA). Since this SA supports
       all MIP traffic between the PDSN/FA and HA, it will normally already be established
       and ready for use. However, if no SA exists, the path between PDSN/FA and HA
       should be secured either by establishing a new IPsec SA or by using MIP HA-FA
       authentication. HA-FA authentication is similar to MN-HA authentication and
       involves shared keys but does not provide encryption of data packets supported by
       an IPSec SA with ESP.

   (6) MN-HA authentication and tunnel establishment. In addition to the MN-AAA
       authentication extension that allows the PDSN/FA to authenticate the roamer, the
       RRQ message sent by the mobile also includes an MN-HA authentication extension
       that allows the HA to authenticate the roamer. The mobile uses its MN-HA shared
       key and the message contents to compute an authenticator value which is included
       in this MN-HA authentication extension. Upon receiving the RRQ, the HA queries
       the HAAA to obtain the MN-HA shared key. Using its MN-HA shared key and the
       message contents, the HA calculates an authenticator value and compares this
       calculated value to the one provided by the mobile. Upon successful validation, the
       MIP tunnel is established and the HA returns a registration reply (RRP) to the mobile
       to indicated that MIP registration has been accepted.

   (7) Accounting start. Same as SIP call setup.




Ref Doc 136, Ver. 1.0                                                                    108
1xEV-DO Roaming WhitepaperGuide                                                                                                                 Call Flow Examples




13.3.2 MIP Call Teardown Example Call Flow


     Roamer                    PDSN/FA                                Visited AAA                            HA                                  Home AAA


                                                                           VAAA                                                                    HAAA


                                                     Data Session Established
                                     MIP Registration Request (RRQ)
                                                 (Lifetime = 0)
 1
                                      MIP Registration Reply (RRP)
                                          (Code = registration timeout)




         PPP LCP Terminate Request
 2
           PPP LCP Terminate Ack


                                      RADIUS Accounting-Request
                                        (Authenticator, Acct_Session_Id,
                                           Acct_Status_Type = Stop)                          RADIUS Accounting-Request
                                                                                    (Authenticator, Acct_Session_Id, Acct_Status_Type = Stop)
 3
                                                                                            RADIUS Accounting Response
                                     RADIUS Accounting Response                                          (Authenticator)
                                                (Authenticator)



                                                     Data Session Terminated

                        Figure 13-6: MIP Call Teardown Example Call Flow


     (1) MIP session termination. In this example, the roamer initiates termination of the
         call. To gracefully close the MIP session before terminating the call with the base
         station, the mobile sends a MIP registration-request (RRQ) with a registration
         lifetime value of zero to the HA. This action allows the HA to free resources such as
         public addresses.

     (2) PPP link termination phase. Same as SIP call teardown.

     (3) Accounting stop. Same as SIP call teardown.




Ref Doc 136, Ver. 1.0                                                                                                                                  109

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:14
posted:9/18/2011
language:English
pages:109