Letters

Billing/Settlement Platform “InfoBillingBrobCom” for VoIP and Data Services
Tomoyasu Sato†, Ken Kanishima, Shinya Takada, andMiyoshi Hanaki
Abstract
This article provides an overview of InfoBilling BrobCom, a fully integrated billing and settlement
platform that generates aggregate billing records for VoIP, VPN, and other services by collecting and correlating call detail records derived from distributed call control equipment, RADIUS authentication
servers, and other network elements.

1. Billing system for VoIP
Accompanying the penetration of ADSL (Asynchronous Digital Subscriber Lines) and the growing
number of always-on and broadband Internet connections, we have seen growing demand for content anddata delivery, VoIP (Voice over Internet Protocol),and other Internet-based services, which has fueled
demand for a comprehensive IP billing system. Providing VoIP services requires interoperability
between the legacy public switched telephone network (PSTN) and IP-based networks, so a viablebilling/settlement platform must be fully aware ofthis interoperability and be capable of using the same
billing records as the PSTN.
2. Overview of InfoBilling BrobCom
As illustrated in Fig. 1, InfoBilling BrobCom collects call detail records (CDRs) and logs fromRADIUS (Remote Authentication Dial-In User Service) servers and other servers providing services,from call agents (CAs) and gatekeepers (GKs) thatcontrol calls by the H.323 and Session Initiation Protocol (SIP) [1] used by VoIP, and from gateways(GWs) that provide an interface between PSTN andIP-based networks. InfoBilling BrobCom takes these† NTT Information Sharing Platform Laboratories
Musashino-shi, 180-8585 Japan
E-mail: sato.tomoyasu@lab.ntt.co.jp

Vol. 1 No. 1 Apr. 2003

various records and consolidates them into an aggregate billing record. The user responsible for thecharges is identified by a user ID corresponding to theuser’s authentication ID employed by RADIUS andother authentication servers. In VoIP, it is essential toclearly distinguish the parties making and receiving
the call, so an E.164 telephone number is used inaddition to the authentication ID. This corresponds toan ordinary telephone number or to a 050 number
used by VoIP. In situations where the SIP protocol isused, a SIP-URL is employed in addition to the user
ID and the E.164 telephone number.
The platform permits charges to be set and calculated for a full range of user call parameters and calling destinations including different calling routes,different time zones, or, in the case of VoIP, different
quality of service (QoS) requirements. The platform
also calculates VoIP charges with awareness of interconnectivity to the PSTN.
Beyond the ability to calculate metered charges fordata services based on connection time or quantity of
data, the platform is also able to calculate discounts
without violating service level agreements (SLAs).
The calculated charges are billed to the party making
the call, and, after details of the call have been generated and any applicable discounts factored in, billinginformation is output.
3. InfoBilling BrobCom Architecture
The InfoBilling BrobCom platform collects CDRs
73

Letters

and logs from call agents and servers, and uses thisdata as the basis of billing. In the PSTN, one can see
from Fig. 2 that call data is output by switches basedon SS7 (Signaling System no. 7). The output items
and data format are largely fixed because they arebased on a uniform standard.
In the same figure one can see that IP-based networks are quite different, because they are based oncall agents, servers, and assorted other network elements that are very different. A viable billing archi-

tecture must therefore be flexible and robust enoughto accommodate the collection of different kinds ofbilling records, the addition or modification of billing
parties, and the collection of records based on a rangeof different proprietary protocols and formats.
To achieve this robustness, an IP mediation-basedarchitecture has been adopted for the InfoBilling
BrobCom platform, as illustrated in Fig. 3. This system (i) collects CDRs and logs from call agents andvarious service-providing servers, (ii) converts theseFig. 1. InfoBilling BrobCom Service Overview.

Fig. 2. Scheme for collecting billing data across PSTN and IP networks.

74

NTT Technical Review

Letters

records to a standardized format, (iii) edits therecords (correlating, merging and splitting) to makethem useful for billing purposes, (iv) aggregates therecords, and finally (v) produces a single service
detail record. These processes are done by the billing

application.
4. InfoBilling BrobCom Functions
As illustrated in Fig. 4, InfoBilling BrobCom col-Fig. 3. IP Mediation-based billing platform architecture.

Fig. 4. InfoBilling BrobCom architecture.

Vol. 1 No. 1 Apr. 2003

75

Letters

lects CDRs from call agents and servers, calculates
charges, and outputs the service details and billinginformation to the billing system, which is based oncontract data input from the service order processingsystem. Let us next examine the functions and rolesof the InfoBilling BrobCom platform in greater
detail.
IP mediation functions
A diverse range of different kinds of call agents andservers are distributed across IP-based networks, and,because these networks are implemented to exploit
the advantages and unique features of these various
network elements, the output format, the output
items, and the output timing of CDRs and logs willvary from one network element to the next. Furthermore, the billing information is not confined to a single CDR or log, so multiple CDR and logs must becollected and aggregated. In Fig. 4, for example,VoIP data is collected from call agents while PSTN
SS7 data is collected from the gateway. The IP mediation system collects the required usage informationfrom the various network elements (call agents andservers), and produces a single billing record byabsorbing different output formats and timing variations.
By matching the protocols and formats of the various call agents and servers, the IP mediation function
collects CDRs and logs from the network elements,and analyzes the content of this usage data. Since themediation function must correlate data from various
network elements to collect all the information needed in order to generate an aggregate billing record, it
must verify the arrival of related CDRs coming infrom network elements having different timing parameters. Once it has confirmed that all the relevant
CDRs have arrived, the mediation function merges orsplits the CDRs as required to produce an aggregate
billing record for the service associated with one call.
The mediation function not only collects the necessary usage information from distributed network elements to bill for VoIP services, but also, consideringthat VoIP communication involves interworking
between the PSTN and IP-based networks, is capableof generating an aggregate billing record based on
usage information derived from IP-based networks
and from the PSTN. Detailed billing records can thus
be produced for all kinds of service-level calls whereinterworking between the PSTN and IP-based networks is involved.
In the case of RADIUS and VPN services, billingrecords are generated based on the connection time76

and call amount for one call: information that isderived from logs coming from the server.
A notable feature of the IP mediation function isthat its aggregation capability and most of its otherfunctions can be simply modified by changing thevalues of settings, so the system can be flexibly
adapted to any combination or number of call agents,
servers, and other network elements in the IP network, and can therefore easily accommodate network
expansion.
Rating function
Charges are calculated from a tariff based on theaggregate billing record generated by the IP mediation function. The tariff has different rates for different call durations, time zones, distances, voice quality, and so on, and the rate is set based on these various incremental units.
Service detail platform functions
Based on the calculated metered charges, the user’s
usage is output in the form of a detailed call record.
Cyclic and one-time billing functions(Billing Platform)
In addition to calculating ratings, InfoBilling BrobCom can also generate cyclic billing (whether basic
charges are billed or not), and one-time billing such as
for maintenance or installation work. The cyclicbilling function calculates charges on a per-diem basis
and features a per-diem policy engine that can be flexibly set to accommodate any company’s policy.
Invoice processing function
An aggregate billing is generated based on theFig. 5. Business-to-Business-to-Customer (B2B2C) model.

NTT Technical Review

Letters

metered, cyclic, and one-time charge results. Variousdiscounts can also be factored in based on contractual information from the service order processing system. A discount calculation associated with a newplan can also be added on very easily. After thebilling records have been totaled and applicable discounts applied, the records are output for invoicing.
Finally, InfoBilling BrobCom also features theability to bill other providers at wholesale rates forservices that they extend to their own contractual customers based on a B2B2C (business-to-business-tocustomer) model, as shown in Fig. 5.
5. Conclusion
Up to now billing and settlement platforms havebeen based on the fundamental framework of voice
and data services, but future platforms will accommodate advanced usage-based billing and advanced
communication applications.
References[1] IETF, “SIP: Session Initiation Protocol,”
RFC3261, 2002.
[2] Oscar VasQuez, “Billing For IP Services
Remains A Challenge,” Business Communication Review, pp. 31-37, Dec.1999.

Tomoyasu SatoSenior Research Engineer, Network Application Platform Project, NTT Information Sharing
Platform Laboratories.
In 1992, he joined the Software Laboratories,NTT. His research area is IP network application
systems with IP network operation experiments.
Recently he has focused on establishing a network billing system architecture.

Ken Kanishima
Research Engineer, Network Application Platform Project, NTT Information Sharing Platform
Laboratories.
In 1995, he joined the Information Communication Systems Laboratories, NTT. With OSS
experience, his recent research area is billing
related systems. He is primarily in charge ofusage related parts. He received an MA degree insystems science from Tokyo Institute of Technology in 1995.

Shinya Takada
Research Engineer, Network Application Platform Project, NTT Information Sharing PlatformLaboratories.
In 1998, he joined the Software Laboratories,
NTT. His recent research area is billing relatedsystems. He is primarily in charge of CRM related parts. He received an MA degree in physics
from the University of Tokyo.

Miyoshi Hanaki
Senior Research Engineer, Supervisor, Network
Application Platform Project, NTT Information
Sharing Platform Laboratories.
He received the B.S. and M.S. degrees in information engineering from Kyoto University, in1983 and 1985, respectively. In 1985, he joined theElectrical Communication Laboratories, NTT Corporation. After OSS experience, his recent researcharea is billing-related systems. He is a member of
the Institute of Electrical and Electronics Engineers, the Institute of Electronics, Information andCommunication Engineers, and the Information
Processing Society of Japan.

Vol. 1 No. 1 Apr. 2003

77