Roaming Analytics Platform V1.1

4,921 views

Published on

RCA - RAP Analytics

0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,921
On SlideShare
0
From Embeds
0
Number of Embeds
31
Actions
Shares
0
Downloads
1
Comments
0
Likes
8
Embeds 0
No embeds

No notes for slide

Roaming Analytics Platform V1.1

  1. 1. Prio Roaming Cost Analyzer - RCA Roaming Analytics Platform - RAP Network - Protocol - Billing Research Prio Confidential 2009 – Not for Outside Disclosure Jack Brown Ver 1.1 1 March 6, 2009
  2. 2. Roaming Analytics Research •CTIA CIBER • CIBER Record Structure • Inter-Standard Roaming Example • CDMA2000 Packet Data - Roaming • Billing Record Exchange - Syniverse Call Record Detail (CDR) Conversion Service • Fraud Management • Preferred Roaming List (PRL) • Subscriber Identification • Roaming Agreements • Automatic Message Accounting AMA Generic Requirements • Appendix - Acronyms - Standards Bodies - Example AMA Reports Jack Brown Ver 1.1 2 March 6, 2009
  3. 3. Roaming Analytics Research March 5th, 2009 Roaming Analytics Jack Brown Research Ver 1.0 March 6th, 2009 Roaming Analytics Jack Brown Research Ver 1.1 Jack Brown Ver 1.1 3 March 6, 2009
  4. 4. Roaming Analytics Research CTIA CIBER Root Jack Brown Ver 1.1 4 March 6, 2009
  5. 5. Roaming Analytics Research CTIA - The Wireless Association (previously the Cellular Telecommunications Industry Association), the membership organization founded in 1984 to represent wireless communications companies in the United States, developed a process and protocol with GTE to exchange call record information and invoice and pay each other for providing this service. The protocol developed required the use of a standard record format. The standard record scheme that was developed was called CIBER (Cellular Inter- carrier Billing Exchange Record) and the function known as CIBER Roaming Settlement System (also known as financial clearing and settlement) was developed and provided as a service to the members of CTIA by the CTIA. Jack Brown Ver 1.1 5 March 6, 2009
  6. 6. Roaming Analytics Research Eventually the CTIA decided to create a separate financial entity to perform this function and in 1988, Cibernet was created. Cibernet's role since its inception has been to define, developing and maintain the CIBER roaming settlement system. Following the success of roaming in the CDMA market, Cibernet established a London operation in 1995 to provide financial clearing settlement services to the emerging GSM market. Cibernet grew to become arguably the largest and most experienced financial clearing-house in the world. In 2000, Cibernet entered the data clearing market initially focused on the emerging market in India, one of the fastest growing and demanding mobile markets in the world, and now provides data clearing operations to over 45 networks in India, Central Asia, South East Asia and the African continent, processing large and growing TAP record volumes. Jack Brown Ver 1.1 6 March 6, 2009
  7. 7. Roaming Analytics Research In March 2003, Cibernet was sold by the CTIA to a group of private equity investors including Venturehouse Group and Jeong H. Kim. This group provided significant investment. A technology and platform called One1Clear was developed by CTO Michael Baldwin (ex Bell Labs) with an integrated and automated end-to-end clearing and settlement service. Cibernet recently launched fast forward, a set of intelligent consulting, tools and services to support wireless communications companies and mobile operators. In May 2007, Cibernet was acquired by Warburg Pincus. Most carriers use the services of clearinghouses to edit and forward CIBER records to the home companies for billing Jack Brown Ver 1.1 7 March 6, 2009
  8. 8. Roaming Analytics Research CIBER Record Structure Jack Brown Ver 1.1 8 March 6, 2009
  9. 9. Roaming Analytics Research The Cellular Intercarrier Billing Exchange Roamer Record™ or CIBER is the roaming record used by all carriers employing AMPS analog, CDMA and TDMA air interfaces, regardless of frequency. CIBER is a set of proprietary protocols for the exchange of billing information among wireless telecommunications companies, billing vendors, clearing houses, clearing banks and MACH. These are developed, maintained and updated by us. CIBER contains the record types employed to bill for air and toll calls, additional features, surcharges and other services. Also included in CIBER are the edit conditions, data dictionary and reject and return processes. Companies that wish to use the CIBER record format are required to pay a licence fee, where upon they are provided with the file formats and support. Jack Brown Ver 1.1 9 March 6, 2009
  10. 10. Roaming Analytics Research Jack Brown Ver 1.1 10 March 6, 2009
  11. 11. Roaming Analytics Research CIBER Record Structure CIBER – Cellular Intercarrier Billing Exchange Roamer Defined by Cibernet, CIBER is a protocol and specification for the exchange of billing information among roaming partners, their billing vendors, and data clearinghouses. CIBER records are exchanged among roaming partners to facilitate inter-carrier financial settlement and end user billing for roaming related charges. Note that CIBER records are only used for voice roaming as billing for packet data roaming is based on a different record known as a UDR. Jack Brown Ver 1.1 11 March 6, 2009
  12. 12. Roaming Analytics Research CIBER Record Structure There are two categories of CIBER records: X0 Records – No longer supported as of March 2006, X0 is the generic term for the original CIBER 2.0 version released in 1992. X0 records include types 10, 11, 20, 30, 40, and 50. The “0” in X0 refers to the last digit of these types (except for type 11 which serves as the exception to the rule). While X0 records are no longer valid for CIBER exchange, some operators continue to use X0 records natively in their billing systems and rely on third party conversion between X0 and X2 records as needed. X2 Records – The generic term for the CIBER 2.5 version released in 1999. X2 records include types 22, 32, 42, and 52. The “2” in X2 refers to the last digit of these types. X2 records may be either native (i.e., created from the billing system as X2 records) or converted (i.e., created as some other format and converted into X2 records). Jack Brown Ver 1.1 12 March 6, 2009
  13. 13. Roaming Analytics Research CIBER Record Structure This figure shows some of the information (fields) contained in a type 22 CIBER record. This example shows that the type 22 Ciber record field structure has been updated from the previous type 20 record structure to include additional fields that allow for telephone number portability (enabling telephone number transfer between carriers). This list shows that fields in the Ciber record primarily include identification of airtime charges, taxes, and interconnection (toll) charges. Jack Brown Ver 1.1 13 March 6, 2009
  14. 14. Roaming Analytics Research CIBER Record Structure Cibernet announced in the March 2006 CIBER Update that, as of January 16, 2007, the designated clearinghouses will have an edit in place that will prohibit exchange of the X0 Records. To ensure that there is no loss of revenue from rejection of records, carriers will have to migrate to the X2 Records before the January 16, 2007 flash-cut date. Prior to January 16, 2007, carriers can still exchange the older record types but carriers must inform all of their roaming partners that the older record types are still being used. After the January 16, 2007, flash-cut date, an edit will be in place at the clearinghouses to prevent the exchange of the older record types. If a carrier still wishes to exchange the older record types after the flash-cut date, then they will have to contact their respective clearinghouse and request that the clearinghouse bypass the edit. This also requires consent from each of their roaming partners (i.e. via bilateral agreement) and is not recommended as a long-term solution. Jack Brown Ver 1.1 14 March 6, 2009
  15. 15. Roaming Analytics Research CIBER Record Structure Migration from X0 Records to X2 Records Note: Within this document, ”X0 Records” indicates record types 10, 20, 30, or 50, and “X2 Records” indicates record types 22, 32, 42, and 52. Carriers who migrate to the X2 Records will enjoy a variety of benefits as a result of migrating: •The X2 Records are able to capture more information than the X0 Records, such as the caller ID, MDN, IMEI/MEID, called country, and serving country. •Using the X2 Records reduces the need to use two separate CIBER record types to capture all the necessary call detail. For example, if a carrier used to create a Type 10 for air-only call and a Type 20 for air and toll call, this information can now be captured and distinguished in just one Type 22 Record. •In utilizing the X2 Records, a carrier can reduce the number of calls to Customer Care by providing more detail on the subscriber bill such as features that were used during the call, length of the call, the called number, and the called place. This additional information can also help Customer Care better support customers when they call. •The X2 Records also ensure data integrity. With the validation of the records, through the clearinghouses and billing vendor, a carrier is assured that the data captured in the CIBER Records are accurate. Jack Brown Ver 1.1 15 March 6, 2009
  16. 16. Roaming Analytics Research CIBER Record Structure Migration from X0 Records to X2 Records •Several pieces of information from the CIBER Record can be included in the subscriber’s bill. Information that can be extracted from the CIBER Record to the subscriber bill is length of the call, where the call was placed, and any special features used during the call, i.e. directory assistance, call forwarding, and call waiting. Note that CIBER X0 also contains information that can be put into the subscriber’s bill; but that X2 contains more information such as the Caller ID (which may contain the calling number on a mobile- terminated call) and the serving country and called country (for even greater detail on where the call was placed and to where) Jack Brown Ver 1.1 16 March 6, 2009
  17. 17. Roaming Analytics Research CIBER Record Structure Wireless Number Portability (WNP) Cibernet introduced the X2 Record types in 1999 in response to the United States’ Wireless Number Portability (WNP) initiative. With WNP, a wireless subscriber has the ability to change carriers and keep the same phone number. The MIN is tied to a specific carrier, and previously served as the dial-able number as well as the network registration and call processing number. To support WNP, the MIN remained the same and a new number type/space called MDN was created. As an editorial convenience to manage the eventual replacement of MIN with IMSI, the term “MIN” is being replaced in many documents/standards with “MSID.” The MSID can either refer to the IMSI (up to 15-digits), the 10-digit MIN, or the 10-digit IRM. The first 5 or 6 digits of an IMSI or the first 6 digits of an MIN or IRM identify the carrier that owns the roaming subscriber; the MSID is generally not known to the subscriber. The MDN value is the subscriber’s dial-able number, and can be ported from one carrier to another. Jack Brown Ver 1.1 17 March 6, 2009
  18. 18. Roaming Analytics Research CIBER Record Structure Wireless Number Portability (WNP) The US, Canada, and New Zealand are currently splitting the MSID and MDN. Other countries are in the process of or planning to implement WNP. Although your country might not require WNP, if you have inbound roamers from areas that require WNP, then your billing systems must be able to handle WNP. The MSID field is required to be populated because this field is used by the clearinghouse to route the records appropriately to the correct home carrier. The MBI, which is the first 6 digits of a block of 10,000 MINs (called the line range), is used to uniquely identify a wireless carrier. Each serving carrier exchanges technical data sheets with their roaming partners, providing the market and BID information for each MBI line range. This information is used by each serving carrier to map the MBI to the home BID on the CIBER record. When IRMs (a subset of the 10-digit numbering space) are used, the first four digits of the IRM are typically sufficient to identify the home carrier. When a (true) IMSI is used instead of an MIN, the Mobile Country Code (MCC) and Mobile Network Code (MNC) digits at the start of the IMSI serve to identify the home carrier. Jack Brown Ver 1.1 18 March 6, 2009
  19. 19. Roaming Analytics Research CIBER Record Structure Wireless Number Portability (WNP) This split needs identification and population in the CIBER Record to correctly bill the subscriber’s home carrier via the MSID, and to identify the correct subscriber via the MDN. The MSID identifies the carrier and the MDN identifies the subscriber. The following sections provide examples on how to populate an X2 record when the MDN and MSID are split, and when the MIN (MSID) and MDN are identical. MDN/ MSID Split When a subscriber decides to port his/her number to another carrier, the subscriber will now have two numbers: the MIN (MSID), which identifies the subscriber’s carrier; and the MDN, which is the dial-able phone number of the subscriber. When populating the CIBER record, if the subscriber’s MIN is 301-555- 4321, and the MDN is 703-543-5387. The MSID field will be populated as follows: MSID 301555432100000 The MSISDN/MDN field will be populated as follows: MSISDN/MDN 703543538700000 Jack Brown Ver 1.1 19 March 6, 2009
  20. 20. Roaming Analytics Research CIBER Record Structure MDN/MIN (MSID) Split Not Required If the subscriber has not ported his/her number, in many cases, within the North American Numbering Plan, then the MIN and the MDN will be the same. When populating the CIBER Record, if the subscriber’s MDN is 301-555-4321. The MSID field will be populated as follows: MSID 30155543210000 The MSISDN/MDN field will be populated as follows: MSISDN/MDN 30155543210000 MSID Indicator It is also necessary to populate the MSID indicator to identify whether this field will contain either an ITU-T E.212 IMSI or an MIN. Jack Brown Ver 1.1 20 March 6, 2009
  21. 21. Roaming Analytics Research Data Message Handler The wireless industry has an additional format for passing usage information between carriers on signaling networks. Commonly referred to as DMH, or Data Message Handler, this format constructs records in packet data format. The packet format requirements are contained in IS-124, a standard approved by the Telephone Industry Association (TIA). The business rules for passing usage between carriers are contained in another CIBERNET standard, NSDPx, or Non-Signaling Data Protocol. The appended quot;xquot; can also be quot;Fquot; for fraud formats (data passed directly from switches to fraud platforms to detect illegal activity in a near-real-time environment), or quot;B/Squot; for billing/settlement formats (data passed from switches to both home and roam carriers for billing each other). Jack Brown Ver 1.1 21 March 6, 2009
  22. 22. Roaming Analytics Research Inter-Standard Roaming Example Jack Brown Ver 1.1 22 March 6, 2009
  23. 23. Roaming Analytics Research Inter-Standard Roaming Example Some Referenced Documents Ref Standard Description 1. C.S0024-0v4.0 cdma2000 High Rate Packet Data Air Interface Specification 2. 3GPP2 specification X.S0003-0 -- One-Way Roaming from X.S0004 to GSM 3. 3GPP2 specification X.S0023-B - Network Interworking between GSM MAP and TIA-41 MAPcdma2000 Support 4. 3GPP2 specification X.S0004-000E - Introduction to TIA-41 5. J-STD-038, Rev. B Joint TIA/ATIS standard for ISR. The 3GPP2 equivalent is X.S0023-B v 1.0. Jack Brown Ver 1.1 23 March 6, 2009
  24. 24. Roaming Analytics Research Inter-Standard Roaming Example The TIA/EIA standard J-038-B specifies the network services to be performed by the IIF in order to offer seamless voice and data roaming between ANSI and GSM networks. This section details service and feature support for one- way roaming from ANSI to GSM networks. In the case of an ANSI subscriber roaming on GSM, the following services are supported: • ANSI-41 VLR – The IIF emulates an ANSI-41 VLR to the subscriber’s home network. • GSM HLR - To the visited GSM network, the IIF emulates a GSM HLR. • GSM AuC - The IIF can perform full subscriber authentication as required by the visited GSM network. GSM Authentication algorithm A3 versions 1 and 2 must be fully supported and possibly some proprietary algorithms. The algorithm would depend on the GSM operator’s IMSI being used. Jack Brown Ver 1.1 24 March 6, 2009
  25. 25. Roaming Analytics Research Inter-Standard Roaming Example Jack Brown Ver 1.1 25 March 6, 2009
  26. 26. Roaming Analytics Research Inter-Standard Roaming Example The IIF supports the following services and features in the above setup: Authentication: The IIF, acting as the GSM AuC, handles the subscriber’s authentication when roaming in GSM. Upon receiving an authentication request from the GSM VLR, the IIF AuC generates the authentication triplets (RAND, SRES, Kc) and sends them to the GSM VLR. The GSM VPLMN performs the actual authentication using the GSM A3 algorithm COMP128. The GSM authentication is, typically, not translated back to CDMA authentication. Location Management: The IIF acting as the CDMA VLR and GSM HLR is responsible for the subscriber’s location management in GSM. When a CDMA subscriber first roams into a GSM network, a “Location Update” message is sent from the serving GSM VLR to the IIF. The IIF translates this into an ANSI-41 MAP message “REGNOT” and sends it to the home HLR. From the CDMA home network’s point of view, the CDMA subscriber is now located in a foreign CDMA VLR. When the subscriber roams back into the CDMA network, the subscriber’s home CDMA HLR sends an ANSI 41 MAP message “REGCANC” to the last registered CDMA VLR, which is the IIF. This causes the IIF to de-register the subscriber from the last real GSM VLR that the subscriber was registered in. Jack Brown Ver 1.1 26 March 6, 2009
  27. 27. Roaming Analytics Research Inter-Standard Roaming Example The IIF supports the following services and features in the above setup: • Call routing: The CDMA subscriber roaming in GSM appears to be roaming in another CDMA market. When receiving an incoming call, the CDMA home network requests a TLDN for call routing from the IIF. In turn, the IIF, acting as the GSM HLR, requests an MSRN from the visited GSM VLR. The IIF is responsible for handling the MSRN-to-TLDN conversion number formatting to accommodate both ANSI 41 A- and ANSI 41 C- compliant networks. The call is routed directly between the home MSC and the visited GSM MSC. •Voice Mail Deposit: Due to different implementations of voice mail call delivery in GSM and ANSI markets as well as non-implementation of optimal routing in most GSM networks, the call delivery to voice mail in GSM can be a problem. The J-038 standard has left the implementation of the voice mail delivery solution up to the service provider and IIF vendor. Different solutions to address this issue are available from ISR service bureau providers. Contact the CDG for information. Jack Brown Ver 1.1 27 March 6, 2009
  28. 28. Roaming Analytics Research Inter-Standard Roaming Example Subscriber Profile Translation: The IIF translates the CDMA subscriber’s HLR service profile to the corresponding GSM profile. This is done during initial registration and upon any change in profile that is network- or subscriber-initiated. Below is a list of some the services supported in GSM and the corresponding features in CDMA. Jack Brown Ver 1.1 28 March 6, 2009
  29. 29. Roaming Analytics Research Inter-Standard Roaming Example • Subscriber Control of Supplementary Services: In GSM, the IIF enables the subscriber control of supplementary services in two ways: • Use of GSM or dual-mode phone menu functions where the IIF maps the GSM MAP messages “Register_SS”, “Interrogate_SS”, “Erase_SS” to corresponding ANSI MAP “FEATREQ” •Use of CDMA-specific service codes (*codes) in GSM using USSD The IIF vendor or the service bureau provider should support both of the above in order to enable a seamless control of supplementary services in GSM. Jack Brown Ver 1.1 29 March 6, 2009
  30. 30. Roaming Analytics Research Inter-Standard Roaming Example For ISR, the CDMA operator should establish a business agreement with a GSM sponsor operator or with a service bureau that has access to GSM agreements. This agreement allows the CDMA operator to leverage the roaming agreements the GSM operator has already established with the many potential serving/visited carriers. It also simplifies the network architecture in that the CDMA operator need only establish a network link between the IIF and the GSM operator. The CDMA operator must also install its own signaling conversion platform or utilize a third party’s. A network between the CDMA operator and the conversion systems, as well as between the GSM operator and the conversion systems, must be established for signaling messages to be routed between each of the parties. When in a GSM network, the CDMA operator’s subscribers use the IMSI (GSM equivalent to MIN) of the GSM operator and look like an end subscriber of the GSM operator. To facilitate the air interface, the CDMA operator’s subscribers must use a GSM-capable handset while in GSM countries. Jack Brown Ver 1.1 30 March 6, 2009
  31. 31. Roaming Analytics Research Inter-Standard Roaming Example When the CDMA operator’s subscriber powers on the handset in the visited GSM network, the validation and authentication messages are routed to the signaling conversion platform (IIF) via the GSM operator. Signaling for validation is translated into ANSI-41 and the registration request is forwarded to the CDMA network while authentication occurs between the IIF and the GSM network. The subscriber must pass authentication and receive a positive registration acknowledgement from the CDMA network before being validated in the GSM network and allowed service. Jack Brown Ver 1.1 31 March 6, 2009
  32. 32. Roaming Analytics Research CDMA2000 Packet Data Roaming Jack Brown Ver 1.1 32 March 6, 2009
  33. 33. Roaming Analytics Research CDMA2000 Packet Data Roaming CDMA is one of the standards for Mobile Station communication. A typical CDMA2000 network includes terminal equipment, mobile termination, base transceiver stations (BTSs), base station controllers (BSCs / PCFs), PDSNs, and other CDMA network and data network entities. The PDSN is the interface between a BSC / PCF and a network router. Jack Brown Ver 1.1 33 March 6, 2009
  34. 34. Roaming Analytics Research CDMA2000 Packet Data Roaming In this illustration, a roaming mobile station user is receiving data services from a visited access provider network, rather than from the mobile station user’s subscribed access provider network. Jack Brown Ver 1.1 34 March 6, 2009
  35. 35. Roaming Analytics Research CDMA2000 Packet Data Roaming As the illustration shows, the mobile station, which must support either Simple IP or Mobile IP, connects to a radio tower and BTS. The BTS connects to a BSC, which contains a component called the Packet Control Function (PCF). The PCF communicates with the PDSN through an A10/A11 interface. The A10 interface is for user data and the A11 interface is for control messages. This interface is also known as the RAN-to-PDSN (R-P) interface. Jack Brown Ver 1.1 35 March 6, 2009
  36. 36. Roaming Analytics Research CDMA2000 Packet Data Roaming The IP networking between the PDSN and external data networks is through the PDSN-to-intranet/Internet (Pi) interface. You can use either an FE or GE interface as the Pi interface. For “back office” connectivity, such as connections to a AAA server, or to a RADIUS server, the interface is media independent but either an FE or GE interface is recommended. When a mobile station makes a data service call, it establishes a Point-to-Point Protocol (PPP) link with the PDSN. The PDSN authenticates the mobile station by communicating with the AAA server. The AAA server verifies that the user is a valid subscriber, determines available services, and tracks usage for billing. The method used to assign an IP address and the nature of the connection depends on service type and network configuration. Simple IP operation and Mobile IP operation are referred to as service types. The service type available to a user is determined by the mobile station, and by the type of service that the service provider offers. In the context of PDSN, a mobile station is the end user in both Simple IP and Mobile IP operation. Once the mobile station is authenticated, it requests an IP address. Simple IP stations communicate the request using the Internet Protocol Control Protocol (IPCP). Mobile IP stations communicate the request using Mobile IP registrations. Jack Brown Ver 1.1 36 March 6, 2009
  37. 37. Roaming Analytics Research CDMA2000 Packet Data Roaming With Simple IP, a service provider’s PDSN assigns a dynamic or static IP address to the mobile station during the PPP link setup. The mobile station retains this IP address as long as it is served by a radio network that has connectivity to the address-assigning PDSN. Therefore, as long as the mobile station remains within an area of RANs that is served by the same PDSN, the MS can move or roam inside the coverage area and maintain the same PPP links. If the mobile station moves outside the coverage area of the given PDSN, the mobile station is assigned a new IP address, and any application-level connections are terminated. A static IP address can be requested by the mobile station, and will be assigned if the address is within the pool of addresses and is available. Also an IP address can be statically specified in the AAA profile of the user using the “Framed-IP-Address” attribute. Jack Brown Ver 1.1 37 March 6, 2009
  38. 38. Roaming Analytics Research CDMA2000 Packet Data Roaming Simple IP Jack Brown Ver 1.1 38 March 6, 2009
  39. 39. Roaming Analytics Research CDMA2000 Packet Data Roaming A VPDN allows a private network dial-in service to span to remote access servers called Network Access Servers (NAS). The above figure illustrates a VPDN connection in the PDSN environment with Simple IP. In this scenario, the PDSN is acting as the NAS. Jack Brown Ver 1.1 39 March 6, 2009
  40. 40. Roaming Analytics Research CDMA2000 Packet Data Roaming A VPDN connection is established in the following order: 1. A PPP peer (mobile station) connects with the local NAS (the PDSN). 2. The NAS begins authentication when the client dials in. The NAS determines that the PPP link should be forwarded to a tunnel server for the client. The location of the tunnel server is provided as part of the authentication by the Remote Authentication Dial-in User Service (RADIUS) server. 3. The tunnel server performs its own authentication of the user and starts the PPP negotiation. It performs authentication for both the tunnel setup and the client. The PPP client is forwarded through a Layer 2 Tunneling Protocol (L2TP) tunnel over User Datagram Protocol (UDP). 4. The PPP setup is completed and all frames exchanged between the client and tunnel server are sent through the NAS. The protocols running within PPP are transparent to the NAS. Jack Brown Ver 1.1 40 March 6, 2009
  41. 41. Roaming Analytics Research CDMA2000 Packet Data Roaming PDSN Mobile IP With Mobile IP, the mobile station can roam beyond the coverage area of a given PDSN and still maintain the same IP address and application-level connections. Jack Brown Ver 1.1 41 March 6, 2009
  42. 42. Roaming Analytics Research CDMA2000 Packet Data Roaming The communication process occurs in the following order: 1. The mobile station registers with its Home Agent (HA) through an FA; in this case, the PDSN. 2. The HA accepts the registration, assigns an IP address to the mobile station, and creates a tunnel to the FA. This results in a PPP link between the mobile station and the FA (or PDSN), and an IP-in-IP or GRE tunnel between the FA and the HA. As part of the registration process, the HA creates a binding table entry to associate the mobile station’s home address with its Care-of address. Note While away from home, the mobile station is associated with a care-of address. This address identifies the mobile station’s current, topological point of attachment to the Internet, and is used to route packets to the mobile station. In IS-835-B networks, the foreign agent’s address is always used as the Care-of address. 3. The HA advertises that the network is reachable to the mobile station, and tunnels datagrams to the mobile station at its current location. 4. The mobile station sends packets with its home address as the source IP address. 5. Packets destined for the mobile station go through the HA; the HA tunnels them through the PDSN to the mobile station using the care-of address. 6. When the PPP link is handed off to a new PDSN, the link is re-negotiated and the Mobile IP registration is renewed. 7. The HA updates its binding table with the new care-of address. Jack Brown Ver 1.1 42 March 6, 2009
  43. 43. Roaming Analytics Research CDMA2000 Packet Data Roaming Prepaid Billing A PDSN can provide for real-time monitoring and rating of data calls for prepaid users. The prepaid billing solution for the PDSN is based on the RADIUS (AAA) server, and takes advantage of the existing flow-based accounting functionality. The prepaid billing feature requires the RADIUS server to interface with a Prepaid Billing Server (PBS) to relay real-time billing information between the PDSN and the PBS. A third-party Prepaid Billing Server controls the real-time rating of data calls and maintains balances in users’ accounts. The prepaid billing feature provides the following services: • Simple IP-based service metering in real time. • Undifferentiated Mobile IP service in real-time, with support for multiple Mobile IP flows per user. • Rating based on per-flow data volume, octet or packet count, and call duration. The following figure shows the network reference architecture for prepaid service. The PBS resides in the mobile station’s home network and is accessed by the home RADIUS server. Jack Brown Ver 1.1 43 March 6, 2009
  44. 44. Roaming Analytics Research CDMA2000 Packet Data Roaming Jack Brown Ver 1.1 44 March 6, 2009
  45. 45. Roaming Analytics Research CDMA2000 Packet Data Roaming For roaming users, the local RADIUS server in the visited network forwards AAA requests to the home RADIUS server, using a broker RADIUS server if required. For roaming prepaid users, this requires that the local and broker AAA servers forward the new vendor specific prepaid accounting attributes transparently to the home RADIUS server. In existing networks, where the home RADIUS server does not support the interface to the Prepaid Billing Server, AR can be placed in front of the home RADIUS server to act as a proxy. In this case AR forwards all authorization and accounting messages to /from the home RADIUS server and communicates with the PBS. This scenario is relevant if an operator already has a RADIUS server. While this architecture does impose some additional requirements on the RADIUS server, the interface towards the PDSN does not change. It is possible that an operator may want to use an existing WIN or IN based prepaid billing server. In this situation, the PBS will interface to the external prepaid billing server. Accounting Records The PDSN will continue to generate per flow accounting records in the same way as it does for non-prepaid users. However, the last Accounting Stop Request for a flow will contain the new prepaid Vendor Specific Attributes (VSAs) for reporting the final usage. Jack Brown Ver 1.1 45 March 6, 2009
  46. 46. Roaming Analytics Research CDMA2000 Packet Data Roaming How Prepaid Works in PDSN When a prepaid mobile user makes a data service call, the MS establishes a Point-to-Point Protocol (PPP) link with the PDSN. The PDSN authenticates the mobile station by communicating with the AAA server. The AAA server verifies that the user is a valid prepaid subscriber, determines what services are available for the user, and tracks usage for billing. Prepaid Simple IP Call Flow In the following scenario, the prepaid user has sufficient credit and makes a Simple IP data call. The user disconnects at the end of the call. Step 1 The MS originates a call by sending an origination message. A traffic channel is assigned, and the MS is authenticated using CHAP. Step 2 The PDSN determines that a Simple IP flow is requested and sends an Access Request to the RADIUS server. Step 3 The RADIUS Server looks up the user’s profile and determines that user has prepaid service. It sends an initial authentication request to the billing server. Step 4 The billing server checks that the user has sufficient quota to make a call, and returns the result. Step 5 The RADIUS Server sends an Access Accept message to PDSN indicating that this is a prepaid user. Step 6 The PDSN completes the PPP connection, and an IP address is assigned to the MS. Jack Brown Ver 1.1 46 March 6, 2009
  47. 47. Roaming Analytics Research CDMA2000 Packet Data Roaming Prepaid Simple IP Call Flow Step 7 PDSN sends an Accounting Request (Start) as normal, and sends an Access Request to AR for initial quota authorization. The request contains the Service Id VSA that indicates the call is Simple IP. Step 8 The RADIUS Server, knowing that this is a prepaid user, sends an initial quota authorization request to the billing server, which returns the quota information to the RADIUS Server. The RADIUS Server includes the quota information in the Access Accept message and sends it to the PDSN. Step 9 The PDSN saves the received quota information and monitors user data against this. When the quota is used up, the PDSN sends an Access Request to AR indicating the usage and reason “Quota Depleted.” Step 10 The RADIUS Server then sends a re-authorization request to PBS, which updates the user’s account, allocates additional quota, and returns the new quota information to the RADIUS Server. Step 11 The RADIUS Server includes the new quota information in the Access Accept message and sends it to the PDSN. The PDSN updates the new quota information in its tables, and adjusts the usage to allow for quota that was used since the Access Request was sent. The PDSN then continues to monitor the user data. Steps 9 - 11 are repeated as long as the user has sufficient quota. Step 12 When the user disconnects, the MS initiates release of the call and the traffic channel is released. The PDSN clears the session and sends an Accounting Request Stop record. The record includes the prepaid VSAs to report final usage. Step 13 The RADIUS Server updates its own records and sends final usage report to PBS. The PBS updates the user’s account and replies to the AR. And the AR sends the Accounting Response to PDSN. Jack Brown Ver 1.1 47 March 6, 2009
  48. 48. Roaming Analytics Research CDMA2000 Packet Data Roaming Prepaid Simple IP Call Flow Step 11 The RADIUS Server includes the new quota information in the Access Accept message and sends it to the PDSN. The PDSN updates the new quota information in its tables, and adjusts the usage to allow for quota that was used since the Access Request was sent. The PDSN then continues to monitor the user data. Steps 9 - 11 are repeated as long as the user has sufficient quota. Step 12 When the user disconnects, the MS initiates release of the call and the traffic channel is released. The PDSN clears the session and sends an Accounting Request Stop record. The record includes the prepaid VSAs to report final usage. Step 13 The RADIUS Server updates its own records and sends final usage report to PBS. The PBS updates the user’s account and replies to the AR. And the AR sends the Accounting Response to PDSN. Jack Brown Ver 1.1 48 March 6, 2009
  49. 49. Roaming Analytics Research CDMA2000 Packet Data Roaming Prepaid Mobile IP Call Flow In the following scenario, the prepaid user makes a Mobile IP data call. The user runs out of quota during the mobile IP data session and the PDSN disconnects the call. The call flow shows a single Mobile IP flow; however, additional flows are established and handled in a similar manner when the MS sends additional Mobile IP Registration Requests. Step 1 The MS originates a call by sending an Origination message. A traffic channel is assigned, but the MS skips CHAP. Step 2 The PDSN completes the PPP connection. Since the MS skips IP address assignment during IPCP the PDSN assumes Mobile IP. Step 3 The PDSN sends an Agent Advertisement with a FA-CHAP challenge, and the MS initiates a Mobile IP Registration Request with FA-CHAP response. Step 4 The PDSN sends the Access Request with FA-CHAP to the AR. The AR looks up the user’s profile and determines that the user has prepaid service. It the sends an authentication request to the billing server. Step 5 The billing server checks that the user has sufficient quota to make a call and returns an ok. The RADIUS Server sends an Access Accept message to the PDSN that indicates a prepaid user. Step 6 The PDSN forwards the mobile IP Registration Request to the Home Agent and receives a Registration Reply. The PDSN forwards the reply to the MS. Jack Brown Ver 1.1 49 March 6, 2009
  50. 50. Roaming Analytics Research CDMA2000 Packet Data Roaming Prepaid Mobile IP Call Flow Step 7 The PDSN sends an Access Request for initial quota authorization. The request contains Service Id VSA that indicates this is a Mobile IP call. The AR, knowing that this is a prepaid user, sends the initial quota authorization request to the PBS. The billing server returns the quota information to the AR, who includes the quota information in the Access Accept message and sends it to the PDSN. Step 8 The PDSN saves the received quota information and monitors the user data against this. When the quota is used up, the PDSN sends an Access Request to AR indicating the usage and reason “Quota Depleted.” Step 9 The AR sends re-authorization request to the PBS, who updates the user’s account, allocates additional quota, and returns the new quota information to the AR. Step 10 The AR includes the new quota information in the Access Accept message and sends it to the PDSN. The PDSN updates the new quota information in its tables, and adjusts usage to allow for quota used since the Access Request was sent. The PDSN then continues to monitor the user data. Steps 8-10 are repeated as long as the user has sufficient funds. Step 11 If the PDSN requests an additional quota but the user has run out, the PBS rejects the request with reason “Exceeded Balance,” and the AR sends an Access Reject to PDSN. Jack Brown Ver 1.1 50 March 6, 2009
  51. 51. Roaming Analytics Research CDMA2000 Packet Data Roaming Prepaid Mobile IP Call Flow Step 12 The PDSN deletes the Mobile IP flow, determines that this is the last flow, and requests release of the A10 connection by sending A11-Registration Update to the PCF. The PCF sends an ack message and initiates release of the traffic channel. Step 13 The PDSN clears the session and sends an Accounting Request Stop record. The record includes the prepaid VSAs to report final usage. Step 14 The AR updates its own records and sends final usage report to PBS, who updates the user’s account and replies to the AR. Step 15 The AR finally sends the Accounting Response to PDSN. Jack Brown Ver 1.1 51 March 6, 2009
  52. 52. Roaming Analytics Research CDMA2000 Packet Data Roaming PDSN Configuration for Simple IP The below figure is an example of PDSN architecture for Simple IP and its accompanying configuration. Jack Brown Ver 1.1 52 March 6, 2009
  53. 53. Roaming Analytics Research CDMA2000 Packet Data Roaming PDSN Configuration for Mobile IP The figure below is an example of PDSN architecture for Mobile IP service and its accompanying configuration. The example shows the configuration of PDSN1. Jack Brown Ver 1.1 53 March 6, 2009
  54. 54. Roaming Analytics Research CDMA2000 Packet Data Jack Brown Ver 1.1 54 March 6, 2009
  55. 55. Roaming Analytics Research CDMA2000 Packet Data Jack Brown Ver 1.1 55 March 6, 2009
  56. 56. Roaming Analytics Research CDMA2000 Packet Data Jack Brown Ver 1.1 56 March 6, 2009
  57. 57. Roaming Analytics Research CDMA2000 Packet Data Jack Brown Ver 1.1 57 March 6, 2009
  58. 58. Roaming Analytics Research CDMA2000 Packet Data Jack Brown Ver 1.1 58 March 6, 2009
  59. 59. Roaming Analytics Research CDMA2000 Packet Data Jack Brown Ver 1.1 59 March 6, 2009
  60. 60. Roaming Analytics Research CDMA2000 Packet Data Jack Brown Ver 1.1 60 March 6, 2009
  61. 61. Roaming Analytics Research CDMA2000 Packet Data Jack Brown Ver 1.1 61 March 6, 2009
  62. 62. Roaming Analytics Research CDMA2000 Packet Data Jack Brown Ver 1.1 62 March 6, 2009
  63. 63. Roaming Analytics Research CDMA2000 Packet Data Jack Brown Ver 1.1 63 March 6, 2009
  64. 64. Roaming Analytics Research CDMA2000 Packet Data The following logical interfaces comprise the Bilateral Billing reference model: Bd Interface – Provides IP data transport between the home and visited operator. Ba Interface – A connection between the AAA of the visited and home operator. This connection is used to perform proxy authentication of the MS, and is also used for the delivery of UDR data from the visited operator to he home operator Bi Interface – Used to collect UDR data from the AAA for reconciliation and settlement with the other operator. Jack Brown Ver 1.1 64 March 6, 2009
  65. 65. Roaming Analytics Research CDMA2000 Packet Data The bilateral billing model relies entirely on the passing of UDR data records from the visited AAA to the home AAA via the Ba interface. No CIBER records are required for the billing of packet data. The Bilateral Billing Model applies only to the volume of data used in the visited network by roaming mobiles from the home network. To ensure a common definition of volume, billing should be done on a byte/octet basis. Jack Brown Ver 1.1 65 March 6, 2009
  66. 66. Roaming Analytics Research CDMA2000 Packet Data Settlement Process Settlement refers to the process of financial reconciliation between operators for packet data services used by roaming subscribers in the visited network. The total amount of packet data consumed is determined entirely by AAA UDR records. UDRs generated by the visited operator are passed to the home operator via the Ba interface. Each operator collects all UDR data for the settlement process via the Bi interface. The home and visited operator should reconcile all the collected UDRs. The reconciliation process should include comparing the total number of UDRs and the total number of bytes of data consumed. In addition, converting and rating functions should be applied to the UDR data to generate financial information to be presented in the Settlement Report. US$ should be used for financial settlement. The IMF rate on one specific Exchange Rate Date of the month should be used for the next billing cycle. The Settlement Report should be used by the visited operator to generate a financial invoice for the home operator. The time cycle for settlement should be determined by the home and visited operator. However, the following presents an example of how the settlement cycle might typically be structured: Jack Brown Ver 1.1 66 March 6, 2009
  67. 67. Roaming Analytics Research CDMA2000 Packet Data Settlement Process Exchange rate date Exchange quot;Settlement Report” date Invoice due date Payment due date Jack Brown Ver 1.1 67 March 6, 2009
  68. 68. Roaming Analytics Research CDMA2000 Packet Data Settlement Process Format and Adequacy check Each operator should check the following UDR attributes for format correctness. •Record length check: This checks if the length of each UDR attribute is within the allowable range. It also checks if the actual attribute length is the same as the Length field indicates. •Numeric check: This checks if each field is encoded with the allowed format. For example, the MSID field should not be populated with string that has alphabetical information. •Future record check: This checks if an UDR timestamp is not in the future compared to the current time of the check. •Aged record check: This checks if an UDR timestamp is not delayed later than 30 days from the current time of the check. The format and adequacy check should be performed upon receiving UDR in a RADIUS Accounting message (start, stop, or interim). If the UDR fails the format or adequacy check, the operator should report the erroneous UDR during the settlement process. Erroneous UDR shall not be chargeable Jack Brown Ver 1.1 68 March 6, 2009
  69. 69. Roaming Analytics Research CDMA2000 Packet Data Settlement Process Billing Solution In Case of Trouble There may be cases during the settlement process when the total number of octets consumed differs between the home and visited operator settlement reports. There should be an allowance for an octet difference (xx%), which should be decided by the home and visited operators. Following is one example for dealing with this situation. The visited operator’s reports shall be considered the source data. The home operator’s reports shall be used to check accuracy If the source settlement figure is over xx% higher or lower than the check figure, both carriers shall investigate the trouble, and determine the cause by checking the following: Until the problem is resolved, settlement shall be done daily. Investigation shall continue for one month. After 1 month, if the cause of the discrepancy is still not determined, for days on which the difference in the sum of octet data traffic is over xx%, the financial difference should be divided equally between visited and home operators. Payment (last day of following month) shall be postponed to the next cycle. Jack Brown Ver 1.1 69 March 6, 2009
  70. 70. Roaming Analytics Research CDMA2000 Packet Data Required Attributes for Billing The following attributes are necessary for end-user billing and settlement between operators in 1X network packet data roaming. ‘X’ indicates the attributes that shall be supported. ’A’ indicates the attributes that may be supported depending on the roaming agreement Jack Brown Ver 1.1 70 March 6, 2009
  71. 71. Roaming Analytics Research CDMA2000 Packet Data Required Attributes for Billing The following attributes are necessary for end-user billing and settlement between operators in 1X network packet data roaming. ‘X’ indicates the attributes that shall be supported. ’A’ indicates the attributes that may be supported depending on the roaming agreement Jack Brown Ver 1.1 71 March 6, 2009
  72. 72. Roaming Analytics Research CDMA2000 Packet Data Required Attributes for Billing The following attributes are necessary for end-user billing and settlement between operators in 1X network packet data roaming. ‘X’ indicates the attributes that shall be supported. ’A’ indicates the attributes that may be supported depending on the roaming agreement Jack Brown Ver 1.1 72 March 6, 2009
  73. 73. Roaming Analytics Research CDMA2000 Packet Data Required Attributes for Billing PDSN Accounting The following RADIUS attributes are contained in the UDR sent by PDSN. Jack Brown Ver 1.1 73 March 6, 2009
  74. 74. Roaming Analytics Research CDMA2000 Packet Data Required Attributes for Billing PDSN Accounting The following RADIUS attributes are contained in the UDR sent by PDSN. Jack Brown Ver 1.1 74 March 6, 2009
  75. 75. Roaming Analytics Research CDMA2000 Packet Data Required Attributes for Billing PDSN Accounting The following RADIUS attributes are contained in the UDR sent by PDSN. Jack Brown Ver 1.1 75 March 6, 2009
  76. 76. Roaming Analytics Research CDMA2000 Packet Data Required Attributes for Billing PDSN Accounting The following RADIUS attributes are contained in the UDR sent by PDSN. Jack Brown Ver 1.1 76 March 6, 2009
  77. 77. Roaming Analytics Research CDMA2000 Packet Data Required Attributes for Billing PDSN Accounting The following RADIUS attributes are contained in the UDR sent by PDSN. Jack Brown Ver 1.1 77 March 6, 2009
  78. 78. Roaming Analytics Research CDMA2000 Packet Data Required Attributes for Billing PDSN Accounting The following RADIUS attributes are contained in the UDR sent by PDSN. The following list identifies the prepaid VSAs that can be included in the RADIUS attributes contained in the Accounting Stop Record: • crb-auth-reason • crb-duration • crb-total-volume • crb-uplink-volume • crb-downlink-volume • crb-total-packets • crb-uplink-packets • crb-downlink-packets • crb-session-id Jack Brown Ver 1.1 78 March 6, 2009
  79. 79. Roaming Analytics Research CDMA2000 Packet Data Required Attributes for Billing PDSN Accounting The following RADIUS attributes are contained in the UDR sent by PDSN. Jack Brown Ver 1.1 79 March 6, 2009
  80. 80. Roaming Analytics Research CDMA2000 Packet Data Required Attributes for Billing PDSN Accounting The following RADIUS attributes are contained in the UDR sent by PDSN. Jack Brown Ver 1.1 80 March 6, 2009
  81. 81. Roaming Analytics Research CDMA2000 Packet Data Required Attributes for Billing PDSN Accounting The following RADIUS attributes are contained in the UDR sent by PDSN. Jack Brown Ver 1.1 81 March 6, 2009
  82. 82. Roaming Analytics Research CDMA2000 Packet Data Jack Brown Ver 1.1 82 March 6, 2009
  83. 83. Roaming Analytics Research CDMA2000 Packet Data Jack Brown Ver 1.1 83 March 6, 2009
  84. 84. Roaming Analytics Research CDMA2000 Packet Data Jack Brown Ver 1.1 84 March 6, 2009
  85. 85. Roaming Analytics Research CDMA2000 Packet Data Jack Brown Ver 1.1 85 March 6, 2009
  86. 86. Roaming Analytics Research CDMA2000 Packet Data Jack Brown Ver 1.1 86 March 6, 2009
  87. 87. Roaming Analytics Research CDMA2000 Packet Data Jack Brown Ver 1.1 87 March 6, 2009
  88. 88. Roaming Analytics Research CDMA2000 Packet Data Jack Brown Ver 1.1 88 March 6, 2009
  89. 89. Roaming Analytics Research CDMA2000 Packet Data Jack Brown Ver 1.1 89 March 6, 2009
  90. 90. Roaming Analytics Research CDMA2000 Packet Data Jack Brown Ver 1.1 90 March 6, 2009
  91. 91. Roaming Analytics Research CDMA2000 Packet Data Jack Brown Ver 1.1 91 March 6, 2009
  92. 92. Roaming Analytics Research CDMA2000 Packet Data Jack Brown Ver 1.1 92 March 6, 2009
  93. 93. Roaming Analytics Research CDMA2000 Packet Data Jack Brown Ver 1.1 93 March 6, 2009
  94. 94. Roaming Analytics Research CDMA2000 Packet Data Jack Brown Ver 1.1 94 March 6, 2009
  95. 95. Roaming Analytics Research Example CDMA2000 Packet Data Carrier Inter-Connect Testing RADIUS Testing Prior to end to end connectivity testing, it is recommended that RADIUS messaging be tested. This includes authentication, authorization, and accounting. The AAA servers should be connected prior to testing. This should include all primary and secondary servers, including the AAAs of any applicable CRX provider(s). The ports used by the AAA servers should be indicated in operator TDSs. Testing should be performed to ensure that requests to primary servers correctly failover to secondary AAA servers. This would include AAA failover in the visited operator, home operators, and CRX (if applicable). Jack Brown Ver 1.1 95 March 6, 2009
  96. 96. Roaming Analytics Research Example CDMA2000 Packet Data Carrier Inter-Connect Testing Authentication AN-AAA A12 (EV-DO Only) If EV-DO service is being tested and the A12 interface has been implemented then both successful and unsuccessful authentication should be tested. AN-AAA (A12) Successful authentication Success Criteria: Note: NAI = AN-AAA NAI (1)Access-request received by home operator and CRX (if applicable) (2)Accept-accept received by visited operator and CRX (if applicable) (3)MS authenticated and gains access to network Jack Brown Ver 1.1 96 March 6, 2009
  97. 97. Roaming Analytics Research Example CDMA2000 Packet Data Carrier Inter-Connect Testing Similarly, authentication failure should be verified for A12. This should be done for the two described failure scenarios. AN-AAA (A12) Unsuccessful Authentication Success Criteria: (1)Access-request received by home operator and CRX (if applicable) (2)Accept-reject received by visited operator and CRX (if applicable) (3)MS authentication fails 1xRTT PDSN-AAA Successful Authentication Success Criteria: (1)Access-request received by home operator and CRX (if applicable) (2)Accept-accept received by visited operator and CRX (if applicable) (3)MS authenticated and gains access to network 1xRTT PDSN-AAA Unsuccessful authentication Success Criteria: (1)Access-request received by home operator and CRX (if applicable) (2)Accept-reject received by visited operator and CRX (if applicable) (3)MS authentication fails Jack Brown Ver 1.1 97 March 6, 2009
  98. 98. Roaming Analytics Research Example CDMA2000 Packet Data Carrier Inter-Connect Testing The following tests should be performed to ensure that accounting records and responses are correctly sent. In all cases, it should be confirmed that the attributes agreed upon by the operators and the CRX provider are present in the accounting records UDRs. Accounting-Start and Accounting-Response packet Accounting Start/Response Records Success Criteria: (1)Accounting-Start received by visited/home AAAs and CRX (if applicable) (2)Agreed upon attributes present in Accounting-Start record (3)Accounting-Response received by visited/home AAAs and CRX (if applicable) Jack Brown Ver 1.1 98 March 6, 2009
  99. 99. Roaming Analytics Research Example CDMA2000 Packet Data Carrier Inter-Connect Testing Interim-Accounting and Accounting-Response packet Interim/Response Records Success Criteria: (1)Interim Accounting received by visited/home AAAs and CRX (if applicable) within time period agreed upon by operators (2)Agreed upon attributes present in Interim-Accounting record (3)Accounting-Response received by visited/home AAAs and CRX (if applicable) Accounting-Stop/Response Records Success Criteria: (1)Accounting-Stop received by visited/home AAAs and CRX (if applicable) (2)Agreed upon attribute present in Accounting-Stop record (3)Accounting-Response received by visited/home AAAs and CRX (if applicable) Jack Brown Ver 1.1 99 March 6, 2009
  100. 100. Roaming Analytics Research Example CDMA2000 Packet Data Carrier Inter-Connect Testing Application Testing The following test cases are intended to record the success and failure of the applications expected to function in the packet data roaming environment. The following table should be used to identify which applications should be tested. Included in the table are common applications that should apply to most operators. These can omitted for operators that don’t wish to support these applications. Applications to be tested: Applications #1 WWW access #2 POP3 #3 SMTP #4 FTP Jack Brown Ver 1.1 100 March 6, 2009
  101. 101. Roaming Analytics Research Example CDMA2000 Packet Data Carrier Inter-Connect Testing Comparison of UDRs after Application Testing It is recommend that after application testing is performed, the UDR data capture by the home AAA, visited AAA, and CRX AAA (if applicable) is identical. The should be done by some automated way of compared these files, e.g. UNIX “same” command. UDR Files Sizes Visited AAA Home AAA CRX (if applicable) Jack Brown Ver 1.1 101 March 6, 2009
  102. 102. Roaming Analytics Research Billing Record Exchange Jack Brown Ver 1.1 102 March 6, 2009
  103. 103. Roaming Analytics Research Billing Record Exchange CDMA operators use CIBER (Cellular Inter-carrier Billing Exchange Roamer) records for the exchange of subscriber roaming usage. GSM operators use TAP (Transferred Account Procedure) for the same purpose The serving operator produces records in the format that its billing system uses. If the home operator cannot accept the format, then it is responsible for conversion into a format that it can process. Several vendors have the ability to convert between CIBER and TAP. The IIF service bureau providers usually include this service. Jack Brown Ver 1.1 103 March 6, 2009
  104. 104. Roaming Analytics Research Billing Record Exchange Occasionally, information is lost during conversion from TAP to CIBER or vice versa. For example, many TAP records do not separate air and toll in the call records, so CIBER5 using home operators may not be able to distinguish air charges from toll when the records arrive in their billing systems. During network testing, the CDMA and the GSM operators should exchange records to test their billing systems and ensure billing system compatibility with the conversions and formatting. Many other differences between the TAP and CIBER formats and processing must be resolved in order for GSM and CDMA operators to exchange roaming billing information. For instance, the settlement cycle for GSM operators using TAP is from the 1st-31st of the calendar month; while the standard settlement cycle for CDMA operators exchanging CIBER records is the 16th- 15th of the calendar month. This means that the dollar value of a TAP settlement cycle will not be equivalent to the value of a CIBER settlement cycle, and balancing procedures must be implemented to accommodate this difference. Another significant difference between TAP and CIBER is that CIBER supports only the US dollar as a valid currency; while TAP supports the US Dollar, the Euro and the SDR which is an exchange currency created by the International Monetary Fund (IMF). If a GSM operator uses either the Euro or the SDR, then the corresponding currency must be converted to US Dollars. Jack Brown Ver 1.1 104 March 6, 2009
  105. 105. Roaming Analytics Research Billing Record Exchange The following are some additional differences between the clearing and settlement of TAP and CIBER: Frequency of processing – CIBER files are processed once per day, while TAP files are processed many times throughout the day. Sequential Processing – CIBER files must be processed by sequence number, while TAP files are not required to be processed in sequence. Flexibility of Validation – An industry-defined set of edits are performed on all CIBER records. GSM operators have defined a standard set of validations to be performed on TAP records. However, operators can bilaterally agree to different validation rules. Billing records should be exchanged using EDI, unless otherwise agreed by the carriers or their vendor(s). Roaming agreements should describe fallback procedures for transfer failures or other delays in exchanging records. TAP and CIBER allow record exchange of up to 30 days after the call date. However, according to generally accepted procedures for TAP processing, the record must be returned to the home operator within 36 hours of the end of the call. Most home operators, however, expect records more quickly. Therefore, operators should agree on file exchange timescales. Rejected records or batches must be returned to the serving operator in its own record format. Jack Brown Ver 1.1 105 March 6, 2009
  106. 106. Roaming Analytics Research Billing Record Exchange When dealing with financial information, such as billing records, it is necessary to ensure that information is thoroughly checked (‘edited’), and that charges do not get lost (or duplicated) through the process of rejecting batches or individual records. It may be possible to resubmit batches or records once problems are corrected. There are two types of rejects and returns in CIBER: Batch-level, and Record level. As its name implies, a batch-level reject occurs when the next downstream entity cannot process the batch due to format errors or integrity issues. Similarly, a record-level reject occurs when a record fails a technical or business edit. The following sections describe some scenarios for batch-level and record level rejects, they do not constitute a complete set. Batch Level Rejects Rejection by Serving Carrier Clearinghouse (Figure 1) 1. A batch of CIBER records is generated by the Serving Carrier Billing System. The batch is then sent to the Serving Carrier Clearinghouse. 2. If the batch fails a technical edit, it is returned to the Serving Carrier Billing System which may then correct the batch and resubmit it to the Serving Carrier Clearinghouse. Jack Brown Ver 1.1 106 March 6, 2009
  107. 107. Roaming Analytics Research Billing Record Exchange Jack Brown Ver 1.1 107 March 6, 2009
  108. 108. Roaming Analytics Research Billing Record Exchange Rejection by Home Carrier Clearinghouse (Figure 2) 1. A batch of CIBER records is generated by the Serving Carrier Billing System and sent to the Serving Carrier Clearinghouse. 2. The Serving Carrier Clearinghouse does not find any problems with the batch and forwards it to the Home Carrier Clearinghouse. 3. If the Home Carrier Clearinghouse does find fault with the CIBER batch, then it can be rejected. Because the batch had already passed the Serving Carrier Clearinghouse edits, the fault may be a result of a transmission error. If the fault was the result of a technical error, the error should have been previously identified by the Serving Carrier Clearinghouse. 4. The problem is corrected by the Serving Carrier Clearinghouse and the CIBER batch is retransmitted to the Home Carrier Clearinghouse Jack Brown Ver 1.1 108 March 6, 2009
  109. 109. Roaming Analytics Research Billing Record Exchange No Batch Reject Allowed from Home Carrier Billing System (Figure 3) 1. A batch of CIBER records is generated by the Serving Carrier Billing System and sent to the Serving Carrier Clearinghouse. 2. The Serving Carrier Clearinghouse does not find any problems with the batch and forwards it to the Home Carrier Clearinghouse. 3. The Home Carrier Clearinghouse also does not find any problems with the batch and forwards it to the Home Carrier Billing System. 4. The Home Carrier Billing System finds fault with the batch. Because the batch financial totals have now been logged at both clearinghouses and the batch sequence number has been incremented, the Home Carrier Billing System is not allowed to reject the batch. It can, however, reject every record in that batch. Typically, because a batch has already passed through two clearinghouses, the Home Carrier Billing System will not find any technical errors with the batch. The Home Carrier Billing System may, however, determine that the batch does not comply with some prearranged business agreement. All the records in that batch are then rejected. Jack Brown Ver 1.1 109 March 6, 2009
  110. 110. Roaming Analytics Research Billing Record Exchange Jack Brown Ver 1.1 110 March 6, 2009
  111. 111. Roaming Analytics Research Billing Record Exchange Record Level Rejects It is possible for the Home Billing System and the Home or Serving Clearinghouses to reject only selected records from a batch. When handling rejected records, the entities that are involved should make any necessary financial adjustments to maintain billing integrity specific to their own systems. Records Rejected by Serving Carrier Clearinghouse (Figure 4) 1. A batch of CIBER records is generated by the Serving Carrier Billing System and sent to the Serving Carrier Clearinghouse. 2. The Serving Carrier Clearinghouse finds fault with some of the CIBER records. The valid records are forwarded to the Home Carrier Clearinghouse. 3. The erroneous records are batched and returned to the Serving Carrier Billing System, which should make any necessary financial adjustments to maintain billing integrity specific to its own systems. 4. The Home Carrier Clearinghouse, not finding fault with the batch of CIBER records sent from the Serving Carrier Clearinghouse, then forwards the valid batch of CIBER records to the Home Carrier Billing System Jack Brown Ver 1.1 111 March 6, 2009
  112. 112. Roaming Analytics Research Billing Record Exchange Jack Brown Ver 1.1 112 March 6, 2009
  113. 113. Roaming Analytics Research Billing Record Exchange Records Rejected by Both Serving and Home Carrier Clearinghouses (Figure 5) 1. A batch of CIBER records is generated by the Serving Carrier Billing System and sent to the Serving Carrier Clearinghouse. 2. The Serving Carrier Clearinghouse finds fault with some of the CIBER records. The valid records are forwarded to the Home Carrier Clearinghouse. 3. The erroneous records are batched and returned to the Serving Carrier Billing System. Upon receipt of the rejected records, it should make any necessary financial adjustments to maintain billing integrity specific to its own systems. 4. The Home Carrier Clearinghouse also finds fault with some of the CIBER records. The erroneous records are batched and sent back to the Serving Carrier Billing System via the Serving Carrier Clearinghouse. Upon receipt of the rejected records, the involved entities should make the necessary financial adjustments to maintain billing integrity specific to its own systems. 5. The remaining valid CIBER records are then forwarded to the Home Carrier Billing System. Jack Brown Ver 1.1 113 March 6, 2009
  114. 114. Roaming Analytics Research Billing Record Exchange Jack Brown Ver 1.1 114 March 6, 2009
  115. 115. Roaming Analytics Research Billing Record Exchange Records Rejected by both Home Carrier Billing System and Both Clearinghouses (Figure 6) 1. A batch of CIBER records is generated by the Serving Carrier Billing System and sent to the Serving Carrier Clearinghouse. 2. The Serving Carrier Clearinghouse finds fault with some of the CIBER records. The valid records are forwarded to the Home Carrier Clearinghouse. 3. The erroneous records are batched and returned to the Serving Carrier Billing System. Upon receipt of the rejected records, it should make any necessary financial adjustments to maintain billing integrity specific to its own systems. 4. The Home Carrier Clearinghouse finds fault with some of the CIBER records. The erroneous records are batched and sent back to the Serving Carrier Billing System via the Serving Carrier Clearinghouse. Upon receipt of the rejected records, the involved entities should make any necessary financial adjustments to maintain the billing integrity specific to its own systems. Jack Brown Ver 1.1 115 March 6, 2009

×