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 [email protected]

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.

1xEV-DO Roaming Guide Contents

Ref Doc 136, Ver. 1.3 3

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 4

3.7 Addresses ........................................................................................................................ 30 3.8 Roaming architecture options .......................................................................................... 32

3.8.1 Simple IP ........................................................................................................... 32 3.8.2 Layer 2 Tunnel Protocol (L2TP) ........................................................................ 33 3.8.3 Mobile IP............................................................................................................ 35

4. Security ..................................................................................................................................... 39 4.1 Authentication Types........................................................................................................ 39 4.2 A12 Authentication ........................................................................................................... 39 4.3 RADIUS Routing Issues................................................................................................... 40

4.3.1 Non-unique realms ............................................................................................ 41 4.3.2 Common NAI/Password Fraud Scenario .......................................................... 41

4.4 Issues Common to Both SIP and L2TP ........................................................................... 43 4.4.1 PPP Authentication............................................................................................ 43 4.4.2 PPP Authentication of Roamer by PDSN.......................................................... 44

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

4.6 Issues Specific to L2TP.................................................................................................... 46 4.6.1 L2TP Tunnel Setup and L2TP Authentication of LAC / LNS............................. 46 4.6.2 Dual PPP Authentication of Roamer ................................................................. 48 4.6.3 Proxy PPP Authentication of Roamer ............................................................... 49

4.7 Issues Specific to MIP...................................................................................................... 50 4.7.1 Rejection of PPP Authentication by Roamer..................................................... 50 4.7.2 Authentication of Roamer by PDSN/FA ............................................................ 50 4.7.3 Security between the PDSN/FA and HA ........................................................... 53 4.7.4 Authentication of Roamer by HA....................................................................... 54

5. Billing ........................................................................................................................................ 57 5.1 Infrastructure .................................................................................................................... 57 5.2 UDRs................................................................................................................................ 58

5.2.1 Account-Request Records ................................................................................ 58 5.2.2 Attributes ........................................................................................................... 58

5.3 1xEV-DO Roaming Billing Architecture............................................................................ 60 5.3.1 Bilateral Billing Architecture............................................................................... 60 5.3.2 CRX Billing Model.............................................................................................. 62

5.4 Back End Processing of UDR records ............................................................................. 65 5.4.1 Retail Billing....................................................................................................... 65 5.4.2 Settlement ......................................................................................................... 65


Ref Doc 136, Ver. 1.3 5

5.4.3 Identifying the Visited Operator ......................................................................... 66 5.4.4 Correlating Accounting Records........................................................................ 66 5.4.5 Subscriber Identification .................................................................................... 67

5.5 Custom Billing Requirements........................................................................................... 67 5.6 Billing Testing ................................................................................................................... 68

6. Devices...................................................................................................................................... 69 6.1 Device Provisioning.......................................................................................................... 69

6.1.1 PRLs.................................................................................................................. 69 6.1.2 CSIMs (R-UIMs) ................................................................................................ 69 6.1.3 Authentication Credentials ................................................................................ 70 6.1.4 Mobile IP Behavior ............................................................................................ 70 6.1.5 DNS Addresses ................................................................................................. 70

6.2 Custom or Non-standard Device Behavior ...................................................................... 71 7. Testing ...................................................................................................................................... 73

7.1 Devices............................................................................................................................. 73 7.2 Network ............................................................................................................................ 74

7.2.1 Interconnectivity................................................................................................. 74 7.2.2 AAA connectivity................................................................................................ 74 7.2.3 Home Network Access ...................................................................................... 74

7.3 Authentication................................................................................................................... 74 7.3.1 HLR Authentication............................................................................................ 74 7.3.2 A12 Authentication ............................................................................................ 74 7.3.3 PDSN Authentication......................................................................................... 75 7.3.4 Mobile IP Authentication:................................................................................... 75

7.4 Roaming Architecture Testing.......................................................................................... 75 7.4.1 Simple IP ........................................................................................................... 75 7.4.2 L2TP .................................................................................................................. 75 7.4.3 Mobile IP............................................................................................................ 75

7.5 Handoffs ........................................................................................................................... 76 7.6 Billing................................................................................................................................ 76

7.6.1 UDR generation................................................................................................. 76 7.6.2 Settlement Testing............................................................................................. 76


Ref Doc 136, Ver. 1.3 6

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

1xEV-DO Roaming Guide Figures

Ref Doc 136, Ver. 1.3 7

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

1xEV-DO Roaming Guide Tables

Ref Doc 136, Ver. 1.3 8

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

Ref Doc 136, Ver. 1.3 9

1. Introduction

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

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

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

1xEV-DO Roaming WhitepaperGuide Getting Started

Ref Doc 136, Ver. 1.3 11

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 1xEV-DO or 1xEV-DO only data service. While it is possible for carriers to support 1xEV-DO only, most carriers are expected to support both. Note that because 1xRTT and 1xEV-DO are separate networks, they may or may not serve the same coverage area. In many cases, the 1xRTT coverage area provided by carriers is larger than the 1xEV-DO coverage area. As a result, the ability to support both will provide roamers with the largest extended coverage area as well as provide the benefit of higher speed 1xEV-DO connectivity when available. Accomplishing this involves the use of hybrid devices that can register in both 1xRTT and 1xEV-DO networks to support handoff of data sessions between these networks.

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

Equally important to thoroughly defining the extended coverage area that includes the roaming 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.


Ref Doc 136, Ver. 1.3 12

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


Ref Doc 136, Ver. 1.3 13

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.


Ref Doc 136, Ver. 1.3 14

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.


Ref Doc 136, Ver. 1.3 15

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 1xEV-DO network. In general, most 1xEV-DO devices will run in hybrid mode, which means the device can acquire both 1xEV-DO and 1xRTT systems, depending on availability. PRLs should be constructed so that the desired systems on the roaming 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.


Ref Doc 136, Ver. 1.3 16

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.

1xEV-DO Roaming WhitepaperGuide Network Architecture

Ref Doc 136, Ver. 1.3 17

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.


Ref Doc 136, Ver. 1.3 18

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


Ref Doc 136, Ver. 1.3 19

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.


Ref Doc 136, Ver. 1.3 20

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


Ref Doc 136, Ver. 1.3 21

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

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

3.4.2 Radio Network Controller (RNC)

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

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

3.4.3 A8 and A9 Interfaces

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

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

3.4.4 R-P Interface (A10 and A11)

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


Ref Doc 136, Ver. 1.3 22

PDSN

A11

A10

R-PInterface

IP

RNC PCF

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


Ref Doc 136, Ver. 1.3 23

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


Ref Doc 136, Ver. 1.3 24

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


Ref Doc 136, Ver. 1.3 25

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.

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

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

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

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

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

P-PInterface

PDSN

ServingNetwork

PDSNTarget

Network

Figure 3-6: P-P Interface


Ref Doc 136, Ver. 1.3 26

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

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

3.6 Network interconnection

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

3.6.1 Direct Interconnections

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

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


Ref Doc 136, Ver. 1.3 27

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.


Ref Doc 136, Ver. 1.3 28

Visited NetworkHome Network

Xi

BorderGateway

ProxyAAA

BorderGateway

VisitedAAA

BorderGateway

HomeAAA

Clearing & Settlement

CRX

Xa Xa

user trafficuser traffic

AAA trafficAAA traffic

XdXd

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.


Ref Doc 136, Ver. 1.3 29

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.

Visited NetworkHome Network

Xi

BorderGateway

ProxyAAA

BorderGateway

VisitedAAA

BorderGateway

HomeAAA

Clearing & Settlement

CRX

Xa Xa

LAC or FALNS or HA

XdXd

tunneled datatunneled data

AAA trafficAAA traffic

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

3.6.3.4 CRX Peering

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


Ref Doc 136, Ver. 1.3 30

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 @ in accordance with RFC2486. While many operators populate the 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 portion with any value. Note that the best source of MSID is from the airlink record received from the PCF. The 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.


Ref Doc 136, Ver. 1.3 31

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

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

Table 3-1: Required Public IP Addresses

Architecture Elements that require Public IP addresses

All Home and visited AAA servers (HAAA and VAAA)

Simple IP Home network application servers

L2TP L2TP network servers (LNS)

Mobile IP Home and foreign agents (HA and FA)

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

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

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


Ref Doc 136, Ver. 1.3 32

3.8 Roaming architecture options

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

Table 3-2: Comparison of Roaming Architectures

Consideration Simple IP L2TP Mobile IP

Elements requiring public IP addresses

(H-, V-, & AN-AAA), PDSN, and home application servers

(H-, V-, & AN-AAA), LNS

(H-, V-, & AN-AAA), HA and PDSN/FA

Element that assigns IP address to mobile

Serving PDSN L2TP Network Server (LNS)

Home Agent (HA)

Network that owns mobiles IP address

Visited network Home network Home network

IP address mobility None None Yes enabled by CoA provided by FA

Possible to allow roamers to have static IP addresses

No home network does not assign mobiles IP address

Yes Yes

All user traffic tunneled back to home network

No Yes L2TP tunnel between LNS and PDSN/LAC

Yes MIP tunnel between HA and PDSN/FA

Internet access path Directly from visited network to Internet

Through L2TP tunnel to home network, then to Internet

Through MIP tunnel to home network, then to Internet

Direct access to home network application servers

Requires remote access from visited network

Yes mobile device is essentially placed in home network

Yes mobile device is essentially placed in home network

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

3.8.1 Simple IP

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


Ref Doc 136, Ver. 1.3 33

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

Home Network Visited Network

PDSN PDSN

ApplicationServer

Visited network assigns IP address to MS/AT. Requires NAT if private IP address assigned

MS/AT can access public Internet directly from visited network

MS/AT must create data session between visited and home networks to access home network application servers

NATVPN Connection

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 IS-835 standard (CDMA2000 Wireless IP Network Standard) should be noted. While L2TP is a


Ref Doc 136, Ver. 1.3 34

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.


PDSN PDSN / LAC

ApplicationServer

LNS

MS/AT must tunnel back to home network to access public Internet

MS/AT can directly access application servers in home network without using NAT

Home network LNS assigns IP address to MS/AT

L2TP TunnelVPN Connection

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


Ref Doc 136, Ver. 1.3 35

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.


Ref Doc 136, Ver. 1.3 36


PDSN PDSN / FA

ApplicationServer

HA FA provides Care-of Address

MS/AT must tunnel back to home network to access public Internet

MS/AT can directly access application servers in home network without using NAT

Home network HA assigns IP address to MS/AT

MIP TunnelVPN Connection

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

1xev-do roaming guide, ver 1.0, july 12, 2006 cdg136

Documents

roaming guide cdg document

cdg members sole risk

carrier roaming

network elements

roaming guide contents

network architecture

cdma development group

anton boulevard