Roaming Analytics Platform V1.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

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


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


CTIA CIBER Root

Jack Brown
Ver 1.1
4
March 6, 2009


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

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


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


CIBER Record Structure

Jack Brown
Ver 1.1
8
March 6, 2009


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


Jack Brown
Ver 1.1
10
March 6, 2009


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


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

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


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


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


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

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

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


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


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

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


Inter-Standard Roaming Example

Jack Brown
Ver 1.1
22
March 6, 2009



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


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



Jack Brown
Ver 1.1
25
March 6, 2009

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

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



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

• 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


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



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


CDMA2000 Packet Data Roaming

Jack Brown
Ver 1.1
32
March 6, 2009


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


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


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


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


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


Simple IP

Jack Brown
Ver 1.1
38
March 6, 2009


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


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

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

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

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


Jack Brown
Ver 1.1
44
March 6, 2009

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

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


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


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

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

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


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

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

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


CDMA2000 Packet Data

Jack Brown
Ver 1.1
54
March 6, 2009



Jack Brown
Ver 1.1
55
March 6, 2009



Jack Brown
Ver 1.1
56
March 6, 2009



Jack Brown
Ver 1.1
57
March 6, 2009



Jack Brown
Ver 1.1
58
March 6, 2009



Jack Brown
Ver 1.1
59
March 6, 2009



Jack Brown
Ver 1.1
60
March 6, 2009



Jack Brown
Ver 1.1
61
March 6, 2009



Jack Brown
Ver 1.1
62
March 6, 2009



Jack Brown
Ver 1.1
63
March 6, 2009



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



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

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


Exchange rate date

Exchange quot;Settlement Report” date

Invoice due date

Payment due date Jack Brown
Ver 1.1
67
March 6, 2009


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


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

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



Jack Brown
Ver 1.1
71
March 6, 2009



Jack Brown
Ver 1.1
72
March 6, 2009

PDSN Accounting
The following RADIUS attributes are contained in the UDR sent by PDSN.

Jack Brown
Ver 1.1
73
March 6, 2009

PDSN Accounting

Jack Brown
Ver 1.1
74
March 6, 2009

PDSN Accounting

Jack Brown
Ver 1.1
75
March 6, 2009

PDSN Accounting

Jack Brown
Ver 1.1
76
March 6, 2009

PDSN Accounting

Jack Brown
Ver 1.1
77
March 6, 2009

PDSN Accounting

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

PDSN Accounting

Jack Brown
Ver 1.1
79
March 6, 2009

PDSN Accounting

Jack Brown
Ver 1.1
80
March 6, 2009

PDSN Accounting

Jack Brown
Ver 1.1
81
March 6, 2009



Jack Brown
Ver 1.1
82
March 6, 2009



Jack Brown
Ver 1.1
83
March 6, 2009



Jack Brown
Ver 1.1
84
March 6, 2009



Jack Brown
Ver 1.1
85
March 6, 2009



Jack Brown
Ver 1.1
86
March 6, 2009



Jack Brown
Ver 1.1
87
March 6, 2009



Jack Brown
Ver 1.1
88
March 6, 2009



Jack Brown
Ver 1.1
89
March 6, 2009



Jack Brown
Ver 1.1
90
March 6, 2009



Jack Brown
Ver 1.1
91
March 6, 2009



Jack Brown
Ver 1.1
92
March 6, 2009



Jack Brown
Ver 1.1
93
March 6, 2009



Jack Brown
Ver 1.1
94
March 6, 2009

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


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

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:
(2)Accept-reject received by visited operator and CRX (if applicable)
(3)MS authentication fails

1xRTT PDSN-AAA Successful Authentication
Success Criteria:
(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:
(2)Accept-reject received by visited operator and CRX (if applicable)
(3)MS authentication fails

Jack Brown
Ver 1.1
97
March 6, 2009


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


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

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

Jack Brown
Ver 1.1
99
March 6, 2009


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


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


Billing Record Exchange

Jack Brown
Ver 1.1
102
March 6, 2009


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

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

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

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


Jack Brown
Ver 1.1
107
March 6, 2009

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

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


Jack Brown
Ver 1.1
110
March 6, 2009

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)
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


Jack Brown
Ver 1.1
112
March 6, 2009

Records Rejected by Both
Serving and Home Carrier
Clearinghouses (Figure 5)
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
5. The remaining valid CIBER records are then forwarded to the Home Carrier
Billing System.

Jack Brown
Ver 1.1
113
March 6, 2009


Jack Brown
Ver 1.1
114
March 6, 2009

Records Rejected by both Home Carrier Billing System
and Both Clearinghouses
(Figure 6)
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

Jack Brown
Ver 1.1
115
March 6, 2009

Roaming Analytics Platform V1.1

Roaming Analytics Platform V1.1

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Roaming Analytics Platform V1.1

Ähnlich wie Roaming Analytics Platform V1.1 (20)

Mehr von Jack Brown

Mehr von Jack Brown (9)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Roaming Analytics Platform V1.1