Packet Data International Roaming Team (PaDIRT)

1. Packet Data International Roaming Team(PaDIRT) Face to Face Meeting Miami June 22, 2006

2. Welcome! • Over 150 people attending the IRT this quarter • Nearly 50 people attending PaDIRT • Introductions please!

3. Agenda 9:00  - 9:30 Opening • Introductions • PaDIRT Overview • Reference Document Overview 9:30 – 10:00 Packet Data Roaming Network Incompatibility • Review incompatibility matrix • Review past resolution statement initiative • Review Mobile IP survey results 10:00 – 10:15 BREAK 10:15 – 11:15 Mobile IP Resolution Discussion • Refine draft text and prepare statement for plenary approval 11:15 – 11:45 RIM Roaming Overview (RIM)

4. Agenda (cont.) 11:45 – 12:30 Operator Issues   • Home DNS assignment with Mobile IP (Sprint) • IMSI issues for PD roaming (LU/TNZ) • CALEA for PD roaming (Sprint) • Post-implementation activities (TNZ) • New CRX peering point investigation (Syniverse) • EV-DO Roaming issues with NAI (Verizon Wireless) • UIM and the A12 interface (Qualcomm) • CRX settlement for packet data (CIBERNET) • New Issues? 12:30 – 1:30 LUNCH 1:30 – 1:45 EV-DO system selection and the TDS (in conjunction with VSWG) 1:45 – 3:00 Operator Issues (Continued) 3:00 – 3:15 BREAK

5. Agenda (cont.) 3:15 – 3:30 EV-DO wildcard usage – in conjunction with VSWG 3:30 – 4:30 MMD tutorial and roaming discussion (Qualcomm) 4:30 – 5:00 Inter-standard data roaming (Worldcell) * Neustar not able to give CRX evolution presentation this meeting

6. Overview PaDIRT = Packet Data International Roaming Team Pay dirt (PaDIRT) n. A useful or profitable discovery or venture. • Charter • Develop and standardize technical recommendations for CDMA2000 Packet Data Roaming • Facilitate discussion about packet data roaming issues between operators

7. PaDIRT Organization • Chaired by Neal Richardson, TNZ • Quarterly meetings co-located with the CDG IRT plenary • Conference calls between meetings • PaDIRT presents recommendations/solutions to IRT plenary • Accepted recommendations published as CDG references documents and/or CDG resolutions

8. PaDIRT Contact Information To be added to PaDRT email exploder, send email to: bcook@qualcomm.com On line information is available on Wiki: http://210.54.118.1/wiki/Packet_Data_Working_Group

9. PaDIRT Reference Documents

10. Process Flow

11. Mapping of Documents to Process

12. Packet Data Roaming Network CompatibilityandMobile IP Resolution Statement

13. PD Roaming Compatibility Matrix Serving Network Device • The following matrix identifies incompatibilities • “Device” indicates the technology preferred by the roaming device • “Serving Network” indicates the network technology available in the visited operator’s network

14. Matrix Text • The matrix identifies all the permutations of access technology required by a roaming device vs. the access technology offered by the visited operator’s network. It’s important to note that many networks and devices are flexible in what access technologies they are able to use. For example many devices are configured to use Mobile IP with Simple IP fallback. And many networks support Simple IP as well as Mobile IP. As long as the device and network have at least one option in common, access technology incompatibility should not be a problem. • The matrix lists the 3 different access technologies along the left side and across the top. The left side refers to the access technology that a device must have as required by its home operator. Note that a device is agnostic as to whether or not SIP or L2TP is used for access, and the matrix refers to the access technology the home operator requires their roaming devices to receive. The access technologies across the top refer to the capabilities of the visited operator’s network. For example, in order to support Mobile IP technology, the visited operator’s PDSNs must support the FA function. • The colors represent whether or not there is a significant compatibility issue. Obviously there is no issue if the technology required by the device and that provided by the network are the same, e.g. a device requiring Simple IP roaming onto a network that support Simple IP. These squares are marked in grey, and labeled as having no issues. The orange and yellow squares have potential incompatibility problems, and the red squares have significant problems. All of these cases are described

15. Matrix Text (cont.) • SIP device->SIP network: No Issue • SIP device->L2TP network: Potential Solution - In this case, the device’s home operator prefers the roaming device receives SIP service, but the visited operator network will only provide L2TP. The device is agnostic as to whether or not it receives SIP or L2TP service. Consequently, a potential solution is available. The device could be provided L2TP service, but it could appear to the device’s home operator that it received SIP service. In this case, the visited PDSN would still perform the L2TP LAC function, but the LNS would either be in the visited operator’s network, or it could be an LNS managed by the CRX. • SIP device->Mobile IP network: No Solution, but no known instances -If a roaming device required SIP service and the network only provided MIP service, then there would be an incompatibility problem. However, there are currently no known CDMA packet data networks that don’t currently offer SIP or L2TP service in addition to MIP. • L2TP device->SIP network: No Solution Identified -In instances where the device requires L2TP service, but the network only offers SIP service, there is an incompatibility problem for which there is no known solution. This is because the visited PDSN must support the LAC function in order for L2TP to be provided. • L2TP device->L2TP network: No Issue

16. Matrix Text (cont). • L2TP device->Mobile IP network: No Solution, but no known instances -If a roaming device required L2TP service and the network only provided MIP service, then there would be an incompatibility problem. However, there are currently no known CDMA packet data networks that don’t currently offer SIP or L2TP service in addition to MIP. If L2TP is also offered in addition to L2TP, then there is no issue. If only SIP is offered in addition to MIP, then there is an incompatibility problem. • MIP device->SIP network: No Solution Identified - In instances where the device requires MIP service, but the network only offers SIP service, there is an incompatibility problem for which there is no known solution. This is because the PDSN must support the FA function in order for MIP service to be provided. • MIP device->L2TP network: No Solution Identified -In instances where the device requires MIP service, but the network only offers L2TP service, there is an incompatibility problem for which there is no known solution. This is because the PDSN must support the FA function in order for MIP to be provided. The L2TP LAC function isn’t relevant or mitigating. • MIP device->Mobile IP network: No Issue "http://210.54.118.1/wiki/PaDIRT_Incompatibility_Problem

17. Mobile IP Convergence Resolution • PaDIRT has tentatively agreed on using Mobile IP for packet data roaming • Working on Mobile IP Resolution Statement • Resolution statement intended to become CDG resolution statement • Strong statement in CDMA industry operator and vendor community • Draft discussed at last IRT face-to-face meeting

18. Mobile IP Convergence Resolution Statement • Draft stated: • Operators’ PDSNs should support the Foreign Agent function no later than 1/1/2007. • All new handsets should support Mobile IP capabilities no later than 1/1/2007.  Operators may or may not choose to provision handsets with the “Mobile IP with Simple IP fallback” configuration. •  Operators should support the Home Agent function and outbound Mobile IP packet data roaming no later than 1/1/2007. • It was decided more information on operator deployment plans was required • Mobile IP survey conducted to better understand deployment plans

19. Mobile IP Survey Results

20. New Resolution Straw Man • All CDMA network implementations will support Mobile IP for inbound roaming no later than 1/1/2008 2. All roaming packet data devices will use Mobile IP for roaming no later than 1/1/2011.

21. Operator Issues

22. Operator Issues • Home DNS assignment with Mobile IP (Sprint) • IMSI issues for PD roaming (LU/TNZ) • CALEA for PD roaming (Sprint) • Post-implementation activities (TNZ) • New CRX peering point investigation (Syniverse) • EV-DO Roaming issues with NAI (Verizon Wireless) • UIM and the A12 interface (Qualcomm) • CRX settlement for packet data (CIBERNET) • New Issues?

23. DNS Assignment and Mobile IP • Sprint originated issue • When roaming with Mobile IP, operators generally want home DNS server assigned • With Mobile IP, you generally complete PPP before authentication with the AAA • Usually results in visited DNS server assignment from visited PDSN

24. DNS Assignment and Mobile IP (cont.)

25. DNS issue - Possible Solutions • Option 1: Just use visited DNS • Option 2: Re-direct DNS at the HA • Option 3: Use I-835C proposed solution • Option 4: PPP re-sync • Option 5: PDSN assigns DNS based on IMSI (no AAA)

26. IMSI padding issue (TNZ) • The “MSID” UDR attribute is the IMSI/MIN of the MS. • Delivered from PCF->PDSN as airlink record • Delivered from PDSN to AAA as 15 digit UDR attribute • MSID attribute usually used to help in billing subscriber • For MIN/IRM-based IMSIs, the PCF will “pad” the first 5 digits, e.g. 111114083329482 • Vendors pad the field differently • Roaming could introduce unexpected padded format into billing systems • Operators have tentatively agreed to be consistent on padding with 0’s, e.g. 000004083329482

27. PD Roaming and CALEA • Issued is Sprint originated • How does this work for roaming? • Should we be consistent here? • Does MIP resolution address this issue?

28. Post Implementation (TNZ) • Testing new software releases • Lab testing facilities and code versions in remote (non-nz) labs • Access to end user devices in remote labs for testing • Issues with new software potentially breaking some existing partners • Notification and testing for roaming carrier network software upgrades • Notification periods • Determination of "fault" and commercial risk • Carrier expansion • Coordination of network build overseas (new PDSN's / HA's / AAA's) • Managing large lists (300+) of LAC/FA entries in NZ LNS/HA routers • Assure • Method/plan for ensuring that the roaming service remains operational • Lack of remote sites and equipment to determine this

29. New CRX peering point (Syniverse) • Cabo meeting VZW requested investigation into new CRX peering (geographic diversity) • Syniverse took action item to assess the possibility

30. UIM on A12 interface • The EVDO HardwareID value always comes from the equipment itself, even if there is a UIM inserted. • New additional A12 authentication check – does ESN/MEID match what’s in AN-AAA. • If the HardwareID is used (i.e. included and checked) on the A12 interface, it would stop a subscriber transferring their UIM from one mobile to another and continuing to use DO services.

31. PRL EV-DO wildcards • The SectorID is a 128 bit field broadcasted by EV-DO networks to identify themselves • The SubnetID is a 128 bit field in a PRL that is compared against broadcasted SectorIDs • Compared to determine if an attempt to acquire the system should be made • The mask/length indicates the number of bits which should be compared between the broadcasted SectorID and the PRL SubnetID. • A mask/length of /0 creates a wildcard in the PRL since the implication is that NO bits need to be compared • Some operators are using /0 wild cards in their PRLs. This works domestically without issues if the operator is the only EV-DO provider in their country. • Introduces problems for roaming. A wild card will pick up any EV-DO system, even if a roaming relationship doesn’t exist with the operator owning the system.