1xEV-DO Roaming Guide, Ver 1.0, July 12, 2006 CDG136

1xEV-DO Roaming Guide
CDG Document 136 Version 1.3 April 26, 2007
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>
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.3
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
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
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
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
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.
1xEV-DO Roaming WhitepaperGuide
Introduction
1. Introduction
A direct evolution of the CDMA2000 third-generation wireless standards, CDMA2000 1xEVDO 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.
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 partners coverage area. At a high level, the partners 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 1xEVDO 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 partners 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 carriers own coverage area will need to be provided to the roaming partner.
11
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 partners 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
12
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 partners 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.
13
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 partners 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 partners network and other arrangements will need to be made.
14
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 partners 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 operators 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 partners network. For example, a device might be configured to receive Mobile IP, but the roaming partners network doesnt 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 1xEVDO 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 partners 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 partners 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 partners 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.
15
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 partners network should be tested. It is advisable that testing be continued after launch, particularly when new network features or applications are introduced.
16
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
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.
17
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 carriers 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
18
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 roamers 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.
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.
19
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
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 carriers 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
20
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.
21
RNC IP
PCF 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 operators 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
22
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 carriers 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 carriers 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
23
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 carriers 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 users 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
24
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 users 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.
Serving Network
PDSN
P-P Interface
PDSN
Target Network
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 1xEVDO 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
25
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, intraPDSN 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.
26
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 carriers AAA server with the CRX providers proxy AAA server. Xi is an application level interface is used by the CRX providers data clearing and financial settlement systems to exchange User Data Records (UDRs) in RADIUS accounting format.
27
Home Network
Border Gateway
CRX
Border Gateway Xd
Visited Network
Border Gateway user traffic AAA traffic Xa
Xd user traffic AAA traffic
Xa Home AAA
Proxy AAA Xi Clearing & Settlement
Visited AAA
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 carriers 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 providers 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 providers billing clearing and settlement systems to retrieve this accounting information in the form of User Data Records (UDRs) from the AAA proxy server.
28
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
Border Gateway
CRX
Border Gateway Xd tunneled data AAA traffic
Visited Network
Border Gateway
Xd tunneled data
LNS or HA Xa Home AAA
AAA traffic
LAC or FA Xa
Proxy AAA Xi Clearing & Settlement
Visited AAA
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.
29
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 NAIs 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 roamers 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.
30
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 All Simple IP L2TP Mobile IP Elements that require Public IP addresses Home and visited AAA servers (HAAA and VAAA) Home network application servers L2TP network servers (LNS) 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.
31
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 Elements requiring public IP addresses Element that assigns IP address to mobile Network that owns mobiles IP address IP address mobility Possible to allow roamers to have static IP addresses All user traffic tunneled back to home network Internet access path Simple IP (H-, V-, & AN-AAA), PDSN, and home application servers Serving PDSN Visited network None No home network does not assign mobiles IP address No L2TP (H-, V-, & AN-AAA), LNS L2TP Network Server (LNS) Home network None Yes Mobile IP (H-, V-, & AN-AAA), HA and PDSN/FA Home Agent (HA) Home network Yes enabled by CoA provided by FA Yes
Yes L2TP tunnel between LNS and PDSN/LAC Through L2TP tunnel to home network, then to Internet Yes mobile device is essentially placed in home network
Yes MIP tunnel between HA and PDSN/FA Through MIP tunnel to home network, then to Internet Yes mobile device is essentially placed in home network
Directly from visited network to Internet Requires remote access from visited network
Direct access to home network application servers
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.
32
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
VPN Connection
Visited Network
NAT
PDSN MS/AT must create data session between visited and home networks to Application access home Server network application servers
MS/AT can access public Internet directly from visited network
PDSN
Visited network assigns IP address to MS/AT. Requires NAT if private IP address assigned
Figure 3-9: Simple IP Roaming Model Because the mobiles 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 IS835 standard (CDMA2000 Wireless IP Network Standard) should be noted. While L2TP is a
33
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
LNS VPN Connection
Visited Network
L2TP Tunnel
PDSN MS/AT can directly access application servers in home Application network without Server using NAT
MS/AT must tunnel back to home network to access public Internet
PDSN / LAC
Home network LNS assigns IP address to MS/AT
Figure 3-10: L2TP Roaming Model L2TP provides the home network with the advantage of controlling their roaming customers 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
34
encapsulation. Within this tunnel, a PPP session is established between the mobile and the LNS as illustrated below.
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.
35
Home Network
HA VPN Connection
Visited Network
FA provides Care-of Address
MIP Tunnel
PDSN MS/AT can directly access application servers in home Application network without Server using NAT
MS/AT must tunnel back to home network to access public Internet
PDSN / FA
Home network HA assigns IP address to MS/AT
Figure 3-12: Mobile IP Roaming Model Like the L2TP model, MIP provides the home network with the advantage of controlling their roaming customers 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 mobiles 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.
36
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 mobiles 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.
37
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 SIP Authentication 1. Mobile by access network 2. Mobile by PDSN L2TP 1. Mobile by access network 2. Mobile by PDSN/LAC 3. Between PDSN/LAC and LNS 4. Mobile by LNS MIP 1. Mobile by access network 2. Mobile by PDSN/FA 3. Between PDSN/FA and HA 4. Mobile by HA Mechanism A12 authentication using CHAP PPP authentication using PAP or CHAP A12 authentication using CHAP PPP authentication using CHAP or PAP L2TP authentication based on CHAP PPP authentication using PAP or CHAP A12 authentication using CHAP MIP FA challenge authentication IPSec SA or MIP FA-HA authentication 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 carriers 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.
39
Security
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 roamers 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
40
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 companys 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 companys AAA server for authentication rather than to the home network. The roaming subscriber will be authenticated by the companys 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 companys 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
41
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 succeeds. Roamer is able to receive data service in visited network.
2 Roamers NAI includes
HAAA
Partner As realm, so NAI and password are sent in a RADIUS Access-Request to Partner A for authentication
VPN
Partner A
Authenticates and receives bill for roamer that isnt a customer
VAAA
VPN
Partner B Roamer
Visited Network Partner B

Bypassed and does not get paid for data session
1 Roamer from Partner B network
Network used fraudulently
fraudulently uses Partner As common NAI/password during 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 roamers 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.
42
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.
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
43
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 VAAA Home AAA HAAA
PPP LCP
PAP or CHAP
RADIUS
RADIUS
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
44
Security
networks roaming customers to access home network servers while preventing other carriers 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 advertised to visited network and accessible via VPN connection but is not visible or accessible from public Internet.
Firewall prevents access from roamers that are not assigned from Partner A public IP address pool
App Server
VPN
Maps private IP address assigned to roamer to a Public IP address associated their home network
Since roamer is a Partner A customer, IP address will be assigned from pool that can be mapped to a Partner A public IP address
Partner A
Firewall
Partner A Roamer
VPN
NAT Firewall PDSN
App Server
Firewall IP address assigned from a pool that can is mapped to Partner B public IP addresses. If roamer attempts to access Partner A network, he will be blocked by Partner A firewall.
Partner B Roamer
Partner B
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 roamers 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.
45
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 CHAPlike authentication mechanism provided by L2TP.
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
46
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.
47
Security
4.6.2 Dual PPP Authentication of Roamer

Roamer PDSN/LAC Visited AAA Home LNS Home AAA
VAAA
HAAA
Establish PPP link and negotiate authentication method
PPP LCP
Configure Req / Ack
Authenticate mobile device to the PDSN
PAP or CHAP
Request / Ack or Chall / Resp / Succ
RADIUS
Access Req / Accept
RADIUS Access Request / Accept
Mutually authenticate LAC and LNS, setup L2TP tunnel Renegotiate PPP link and authentication method
L2TP
Control Conn Request / Reply / Connected Incoming Call Request / Reply / Connected
PPP LCP
Configure Request / Ack
Authenticate mobile device to the LNS
PAP or CHAP
Request / Ack or Challenge / Response / Success
RADIUS
Access Req / Accept
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.
48
Security
4.6.3 Proxy PPP Authentication of Roamer

Roamer PDSN/LAC Visited AAA VAAA Home LNS Home AAA HAAA
PPP LCP
PAP or CHAP
RADIUS
RADIUS
L2TP
PAP or CHAP
RADIUS
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.
49
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 PPP authentication. Mobile rejects it since authentication will occur during MIP registration PDSN resends without the PPP authentication request
LCP Configure-Request
[Authentication-Protocol] CHAP
LCP Configure-Reject
[Authentication-Protocol] CHAP
LCP Configure-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.
50
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.
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.
51
Security
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.
52
Security
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.
53
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 preshared 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 AccessRequest 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 AccessAccept 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.
54
Security
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.
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.
55
Security
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
56
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 subscribers 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 subscribers 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
RNC IP A8 A9 PCF R-P Interface A10 A11 PDSN AN AAA
Mediation/Billing Server
Figure 5-1: Bill Infrastructure Elements These infrastructure elements and their billing call flow functions are described later.
57
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 users 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 AccountingRequest 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 subscribers 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 arent covered in the table. Operators should explicitly note these required.
58
Billing
5-1: Recommend Accounting Attributes for Packet Data Billing

Type (Item) 1 26/10 (D4) 26/16 (F5) 26/24 (F13) 26/30 (G9) 26/44 (C2) 26/48 (C3) 26/49 (G8) 26/80 (G17) Attribute User-Name BSID Service Option Release Indicator Number of Active Transitions Correlation ID Session Continue Active Time Last User Activity Time X Start X X A AccountingStop X X A X A A Interim X X A Description The name of the user to be authenticated Identifies the serving carrier by SID/NID pair Identifies the CDMA network, 1x or EVDO Specifies reasons for sending a stop record The total number of non-active to active transitions by the user Identifies the correlation of Start/Stop/Interim records for one session Determine the end of a user data session A A The total active connection time This is a Timestamp of the last known activity of the user. This attribute is only used for the end user billing, not used for the settlement between operators. Identify the serving carrier *) This attribute will be approved as IS835-D. Indicates users IMSI or MIN Indicates whether this message is a Start/Stop/Interim Indicates the time in seconds since the message has been sent The total number of octets in IP packets sent by the user The total number of octets in IP packets sent to the user Unique accounting ID that allows start and stop RADIUS records to be matched An event timestamp indicating when the Start/Stop/Interim takes place. Be used in the billing cycle (in UTC)
X X A A
26/142 (D8) 31 40 41 42 43 44 55 (G4)
Carrier ID Calling-StationID Acct-StatusType Acct-Delay-Time Acct-InputOctets Acct-OutputOctet Acct-Session-ID Event-Time
X* X X X
X* X X X X X
X* X X X X X X X
X X
X X
59
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.
60
Billing
3. Throughout a mobiles 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 mobiles 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 operators mediation and billing systems are used both for the retail billing of roaming subscribers as well as wholesale settlement between operators. The home operators 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.
61
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.
62
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 mobiles 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 mobiles 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.
63
Billing
Figure 5-6: CRX Billing Model (2) 5. In the CRX model, the home operators 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)
64
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 partners 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 providers 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.
65
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 operators 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 partners 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.
66
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 subscribers 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) isnt used in the air interface for 1xEV-DO, the MSID attribute cant 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.
67
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 1xEVDO 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.
68
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 operators 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 devices 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
69
Devices
plastic roaming. Operators have the option to provision the EVDO parameters in the CSIM at the smart card vendors facility (pre-provisioning) or after the CSIM enters the field (postpersonalization 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 devices 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
70
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 operators 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.
71
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 partners 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
73
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.
74
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 partners 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 partners 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.
75
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.
76
Conclusions
8. Conclusions
Roaming is a critical component of an operators 1xEV-DO offering. It can help expand an operators 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.
77
References
9. References
[1] 3GPP2 A.S0008-0. Interoperability Specification (IOS) for High Rate Packet Data (HRPD) Access Network Interfaces. V3.0. May 2003. 3GPP2 X.S0011-C. cdma2000 Wireless IP Network Standard. V2.0. July 2005. Airvana. All-IP 1xEV-DO Wireless Data Networks. Technical White Paper. 2001. Bender, Black, Grob, Padovani, Sindhushayana, Viterbi. CDMA/HDR: a bandwidthefficient high-speed wireless data service for nomadic users. IEEE Communications Magazine, Vol. 38, July 2000, pp70-78. IETF RFC 1334. PPP Authentication Protocols. October 1992. IETF RFC 1661. The Point-to-Point Protocol (PPP). July 1994. IETF RFC 1994. PPP Challenge Handshake Authentication Protocol (CHAP). IETF RFC 2104. HMAC: Keyed-Hashing for Message Authentication. IETF RFC 2401. Security Architecture for the Internet Protocol. November 1998. IETF RFC 2406. IP Encapsulating Security Payload (ESP). November 1998. IETF RFC 2409. The Internet Key Exchange (IKE). November 1998. IETF RFC 2661. Layer Two Tunneling Protocol L2TP. August 1999. IETF RFC 2794. Mobile IP Network Access Identifier Extension for IPv4. IETF RFC 2809. Implementation of L2TP Comulsory Tunneling via RADIUS. IETF RFC 2865. Remote Authentication Dial In User Service (RADIUS) IETF RFC 3012. Mobile IPv4 Challenge/Response Extensions. November 2000. IETF RFC 3024. Reverse Tunneling for Mobile IP, revised. January 2001. IETF RFC 3344. IP Mobility Support for IPv4. August 2002. Nogee, Allen. March 2005. In-Stat. 3G Deployment Update. Report No. IN0502117GW.
[2] [3] [4]
[5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19]
[20]
3GPP2 C.P0065 CDMA 2000 Application on UICC for Spread Spectrum Systems (To be published) 3GPP2 C.S0023 Removable User Identity module for Spread Spectrum Systems
[21]
79
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) CDMA2000 Evolution, Data Only. Also known as 1xEV-DO, DO, or IS856. CDMA channel is dedicated to data services with data speeds up to 2.4Mbps (400-600kbps average) 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 Authentication, Authorization, and Accounting server. Similar to HLR/VLR servers in a the mobile voice network. Communicates using RADIUS. Authentication Header. Provides authentication and message integrity but does not support data confidentiality. Has been effectively replaced by ESP Access Network. Data network providing network access to the MS/AT Access Network AAA Access Terminal. 1xEV-DO nomenclature for the Mobile Station (MS). This document uses MS/AT to refer to packet data capable mobile devices Broker AAA Challenge Handshake Authentication Procotol. 3-way handshake protocol used during link establishment and periodically anytime thereafter to authenticate a user. Uses MD5
1xEV-DO
3DES
AAA
AH
AN AN-AAA AT
BAAA CHAP
81
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 Enhanced Compressed RTP CDMA2000 Roaming eXchange. 3rd party provider that facilitates CDMA packet data roaming between carriers by providing interconnection, AAA, billing, and settlement services CDMA Subscriber Identity Module: Defined in 3GPP2 C.P0065, an RUIM on UICC Smartcard Platform. Data Encryption Standard. Encryption algorithm that uses a 52-bit key. AAA protocol designed to succeed RADIUS. 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 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 Domain Name Server. Provides translation between domain names and IP addresses Encapsulating Security Payload. Used by IPSec to provide secure packet flows with authentication, data confidentiality, and message integrity See 1xEV-DO Foreign Agent. Used in Mobile IP architecture Fully Qualified Domain Name
CRTP CRX
CSIM
DES DIAMETER DH1
DH2
DNS
ESP
1xEV-DO FA FQDN
82
Terminology
GRE
Generic Routing Encapsulation. Transport layer encapsulation used by PPTP GPRS Roaming eXchange Home Agent. Used in Mobile IP architecture Home AAA High-level Data Link Control High Data Rate. Term has been replaced by HRPD keyed-Hash Message Authentication Code using MD5. Used by IPSec ESP keyed-Hash Message Authentication Code using SHA-1. Used by IPSec ESP High Rate Packet Data. Also known as HDR and 1xEV-DO 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 Internet Protocol Control Protocol IP Security Protocol. Uses AH, ESP, and IKE to provide secure connections over insecure IP networks IPSec Security Association. Created during IPSec connection establishment to define the rules of that specific connection 1xEV-DO air interface 1xRTT air interface
GRX HA HAAA HDLC HDR HMAC-MD5
HMAC-SHA-1
HRPD IKE
IPCP IPSec
IPSec SA
IS-856 IS-2000
83
Terminology
ISAKMP L2TP LAC LCP LNS MD5
Internet Security Association and Key Management Protocol Layer 2 Tunneling Protocol L2TP Access Concentrator Link Control Protocol L2TP Network Server Message-Digest algorithm 5. protocols such as CHAP Mobile IP 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) Mobile Node Identity. Uniquely identifies an MN within a carriers 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. Mobile Station. Referred to as Access Terminal (AT) in packet data. This document uses MS/AT to refer to packet data capable mobile devices Mobile Station / Access Terminal. Used in this document to refer to packet data capable mobile devices Mobile Station Identifier. May be IMSI, MIN, or IRM. Network Access Identifier. Constructed from mobiles username (MSID) and providers domain name (realm). NAIs should be fully qualified network names of the format: <MSID>@<realm> Hash function used by authentication
MIP MN
MN ID
MS
MS/AT
MSID NAI
84
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 Network Address Translation Network Control Protocol Network ID Proxy AAA Password Authentication Protocol. Simple authentication protocol that is considered insecure since it transmits unencrypted ASCII passwords Packet Control Function Packet Data Serving Node PDSN-PDSN interface Point-to-Point Protocol Point-to-Point Tunneling Protocol Quality of Service Remote Access Dial In User Service 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. Radio Link Protocol Robust Header Compression
NAT NCP NID PAAA PAP
PCF PDSN P-P PPP PPTP QoS RADIUS Replay
RLP ROHC
85
Terminology
RN R-P RTP
Radio Network RN-PDSN interface 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 Removable User Identity Module (see CSIM) Secure Hash Algorithm 1 Simple IP Service Option Service Option 33. CDMA service option for 1xRTT Service Option 59. CDMA service option for 1xEV-DO System ID Transmission Control Protocol User Datagram Protocol Universal Integrated Circuit Card in defined in 3GPP2 C.S0074 Visited AAA Van Jacobson Header Compression Virtual Private Network
R-UIM SHA-1 SIP SO SO33 SO59 SID TCP UDP UICC VAAA VJHC VPN
86
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 voiceoriented 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.
87
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, 1xEVDO 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 users 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.
88
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). 1xEVDO 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 realtime 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.
89
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.
90
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.
91
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.
92
Security Concepts
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.
93
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.
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 AccessAccept or Access-Reject message. This message is mapped to a PAP Authenticate
94
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 trialand-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.
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
95
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.
96
Security Concepts
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.
Data stream and length of data stream being authenticated
Shared secret key and length of shared secret key used for authentication
result of the hmac_md5 function (128 bits)
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.
97
Security Concepts
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.
98
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 VAAA
Home AAA HAAA
PPP LCP Configure Request

(Authentication-Protocol)
1
PPP LCP Configure Ack
CHAP Challenge
(Challenge-Value)
CHAP Response
(Name, Response-Value)
RADIUS Access Request

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

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

(Authenticator)

(Authenticator)
CHAP Success
PPP IPCP Configure Request
(0.0.0.0, IP-Compression-Protocol)
PPP IPCP Configure Ack

(IP-Address)
RADIUS Accounting-Request
(Authenticator, Acct_Session_Id, 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.
99
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.
100
Call Flow Examples
13.1.2 SIP Call Teardown Example Call Flow
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
101
Call Flow Examples
Figure 13-3: L2TP Call Setup Example Call Flow (1) PPP link establishment phase. Same as SIP call setup.
102
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-controlconnection-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.
103
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-callrequest (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 incomingcall-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.
104
Call Flow Examples
13.2.2 L2TP Call Teardown Example Call Flow

Roamer PDSN/LAC Visited AAA VAAA Home LNS Home AAA HAAA
Data Session Established

PPP LCP Terminate Request
1
PPP LCP Terminate Ack L2TP Call Disconnect Notify (CDN)
(Result, Assigned-Session-ID)
L2TP Zero Length Body (ZLB) Acknowledgement
L2TP Stop Control Connection Notification (StopCCN)

(Assigned-Tunnel-ID, Result)
3
L2TP Zero Length Body (ZLB) Acknowledgement
(Authenticator, Acct_Session_Id, Acct_Status_Type = Stop)
(Authenticator, Acct_Session_Id, Acct_Status_Type = Stop)
4
RADIUS Accounting Response
(Authenticator)
RADIUS Accounting Response

(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 stopcontrol-connection-notification (StopCCN) message. The LNS acknowledges the notification with a ZLB message. (4) Accounting stop. Same as SIP call teardown.
105
Call Flow Examples
13.3 Mobile IP (MIP) Roaming Architecture

13.3.1 MIP Call Setup Example Call Flow
Roamer PDSN/FA Visited AAA VAAA
PPP LCP Configure Request PPP LCP Configure Reject PPP LCP Configure Request PPP LCP Configure Ack PPP IPCP Configure Request PPP IPCP Configure Ack ICMP Router Advertisement
HA
Home AAA HAAA
MIP Registration Req (RRQ)
RADIUS Access Request RADIUS Access Request RADIUS Access Accept
MIP Registration Request (RRQ) RADIUS Access Request RADIUS Access Accept MIP Registration Reply (RRP) MIP Registration Reply (RRP)
RADIUS Accounting-Request RADIUS Accounting-Request RADIUS Accounting Response RADIUS Accounting Response
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.
106
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 roamers 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 MNAAA 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
107
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.
108
Call Flow Examples
13.3.2 MIP Call Teardown Example Call Flow

Roamer PDSN/FA Visited AAA VAAA HA Home AAA HAAA
MIP Registration Request (RRQ) MIP Registration Reply (RRP)
PPP LCP Terminate Request PPP LCP Terminate Ack
RADIUS Accounting-Request RADIUS Accounting-Request RADIUS Accounting Response RADIUS Accounting Response
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.
109

1xEV-DO Roaming Guide, Ver 1.0, July 12, 2006 CDG136

Uploaded by

Copyright:

Available Formats

You might also like

1xEV-DO Roaming Guide, Ver 1.0, July 12, 2006 CDG136

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1xEV-DO Roaming Guide, Ver 1.0, July 12, 2006 CDG136

Uploaded by

Copyright:

Available Formats

1xEV-DO Roaming Guide

CDG Document 136 Version 1.3 April 26, 2007

<page left intentionally blank>