Telecom Convergent Billing Rating


Convergent charging in billing (or in other words known as convergent billing), is a solution in the telecommunications industry that enables common management and rating of all users and all services for operators. It includes convergence of payment methods like prepaid and postpaid, basically the pre-pay customers are charged/ rated/ handled the same way as the postpaid customers.


This article provides some handful information about the rating process for billing system. Rating is one of the most important as well as critical module for a billing system. This article explains the rating process from its configuration point of view (means what are the guiding factors involved to rate an event).

We all want to know what happens when we pick-up a mobile phone and a call is connected


Acronym / Term Description
3PS Third-Party Settlement
AoC Advice of Charge
API Applications Programmer Interface, e.g. TIB/Rendezvous C API
CAM Customer Account Management
CCC Content Charging Component
CD04 Billing Development Unix Box
CDR Call Detail Record
CE Balance manager function of the application Commerce Engine (Core)
CMG Messaging System
Content Supplier A third party who owns content and/or applications
CRM Customer Relationship Management
CS Circuit Switched
CSR Customer Service Representative
CT Content
CUG Closed User Group
DA Derived Attribute
EA External Applications
EAI Enterprise Application Integration
EICD External Interface Control Document
External Applications Applications that will interact with the rating engine
MS Messaging
MVPN Mobile Virtual Private Network
PDP Packet Data Protocol
PS Packet Switched
SDP Service Delivery Platform
SMS Short Messaging System
TIB/AE TIBCO’s [4] Active Enterprise software
TIB/RV TIBCO’s [4] TIB/Rendezvous software
SDP Service Delivery Platform: The term for the platform that will deliver content events to the billing system for rating.
MRC Monthly Recurring Charge is a fixed monthly plan charge/s or the recurring charge for the service plan a customer have signed up for.

Rating Fundamentals

Rating Process

The rating process comprises 4 major steps. To provide an overall billing solution, the process steps will also integrate with other business/functional areas to ensure that they support the needs of downstream systems and that they themselves are adequately supported by upstream ones. Rating doesn’t mean to rate only usage events it does rating for non-usage events also.

Rating engine is integrated with Mediation/SCP/SDP/CAM/CRM/Roaming (inbound roaming events)/3PS (third party contents) systems.

Event Receipt

Events will be received from four main sources:

  • Mediation: if real-time processing system is down then supplies events data. A billing mediation platform is a system used to convert data of certain datatypes to other datatypes, usually for billing purposes. Billing Mediation Platforms are used by telephone companies, who typically need to process UDRs (Usage Detail Records). In call scenarios UDRs are most often known as CDRs (Call Detail Records), and among broadband carriers they are often referred to as IPDR.
  • Service Control Platform (SCP) : for real-time voice, data and messaging events.
  • Service Delivery Platform (SDP) : for content and m-commerce events. [1]
  • Internal: for events that are generated by The application (most non-usage events).


The event is guided by matching a pre-determined value (e.g., IMSI) on the event to an account.

  • Customer Purchase: where the event is a purchase-related fee (e.g., subscription) or has been generated by customer usage.
  • Roaming Partner: where the event has been identified as an inbound roaming event.
  • Third Party: where an agreed fee is payable for content but is not generated directly by customer usage.


This is the process that calculates the charge or charges for an event. This uses a combination of parameters, including the event type and sub-type, to determine what charges need to be calculated. For each charge required, a rate is derived using rating parameters and a calculation employed to generate the charge.

Where applicable, per event discounts are calculated within this step.


This step determines the account to which a charge (specific to GL accounts) should be posted. Inbound roaming charges are posted to Roaming Partner Accounts.

Finally, all rated charges along with invoice texts are kept in database and later on fetched during invoicing to produce the event details on customer’s bill.

Charge Types

The Rating process will need to produce non-usage (MRC, One-off etc.) and usage charges (events like voice, data etc.) as required by different product and service configuration characteristic for each telecom operator that uses a solution similar to the one described here. Following are the specific charge types that are required:

Non-Usage Charge Types

Non-usage charges encompass all charges that are not generated by customer or network activity. These charges are:

  • Activation: the charge is generated in response to activation of a package, product, feature or option. It is charged once only Customer Purchase.
  • Recurring: a specified amount is charged periodically usually in return for the provision of a product or service (e.g., product subscription, device rental, package option purchase). If the product or service is cancelled during the period of a recurring charge, then refund will be generated.
  • One-off: the charge is generated in response to an ad-hoc action (e.g., Customer Service charge). It is charged once only.
  • Payment Method: the charge is generated when the customer makes a payment using a specified payment method (e.g., surcharge for credit card payments). It is charged once only.

Usage Charge Types

Usage Charges are generated in response to customer or network events. These events fall into one of the following types:

  • Voice
  • Data
  • Messaging
  • Content

Unlike non-usage charges, usage charges will be calculated in one of the following ways:

  • Duration: the charge is calculated using the rate and the duration of the event (e.g., phone call, data session).
  • Flat Rate: the charge is a flat amount (i.e., the rate) for the whole event (e.g., an SMS message).
  • Volume: the charge is calculated using the rate and the volume of data transferred during a session.
  • Content: the charge is calculated using the rate and a unit of measure specified by the event (e.g., per bullet fired in a game).
  • Pre-Rated: the charge is taken directly from the event and may be re-rated, marked up, marked down or left unchanged.

Commerce Engine (Balance Manager)

All events are rated on real-time basis and this is achieved by Commerce Engine (CE) interface. The Commerce Engine interface is concerned with the real time handling of different event transaction types, Circuit Switched (CS) [3], Packet Switched (PS) [3], Messaging (MS) [3] and Content (CT) [3] for pre-paid and post-paid customers. The Commerce Engine is responsible for determining if the account used to pay for the requested service has enough available credit to allow that request to proceed.

The Commerce Engine (CE) interface uses TIBCO [4] as the transport layer and publish/subscribe as the invocation mechanism. The external applications will publish request messages to TIBCO and the CE will subscribe to TIBCO [4] in order to receive the messages. The CE will return no direct reply on receipt of the request messages. After processing the request message, the CE will respond by publishing the appropriate response or error message to TIBCO [4] using the reply subject supplied in the initial request message.

The Commerce Engine interface allows for the external applications to make requests of the CE (e.g. to reserve or debit a usage volume). The CE always responds to a request with a distinct response message (e.g. successful response or error). Therefore, the message interaction model is request response.

The commerce engine messages are transported over TIBCO’s [4] Active Enterprise (TIB/AE) and TIB/Rendezvous (TIB/RV). The following details the scenarios that the commerce engine interfaces support with respect to the transaction types, handling application and transport protocol.

  • The circuit switched transactions will be handled by the SCP and transported over TIB/RV.
  • The packet switched transactions will be handled by the AAA Server and transported over TIB/RV.
  • The messaging transactions will be handled by the CMG and transported over TIB/AE.
  • The content transactions will be handled by the CCC and transported over TIB/AE.
billing CE interfaces Telecom Convergent Billing Rating

Commerce Engine Interfaces

Figure 1: The diagram illustrates the architecture of the commerce engine interfaces.

Commerce Engine consists of

  • An Interface that is accessed by external systems such as IN servers and content servers
  • Caches of customer account balances and reservations
  • The application rating engines to perform rating of events
  • Business rules (Algorithms used for reverse rating and for calculation of the equivalent monetary amount to reserve) configured via expressions to control the size of reservations
billing Telecom Convergent Billing Rating

Billing Architecture

Figure 2: The diagram illustrates the Commerce Engine interfaces with External Applications.

Commerce Engine’s Functionality

Commerce Engine for a billing application has multiple functionalities. The most important are listed below

Balance Management

This provides event authorization, advice of change information and customer credit reservations.

balance management process Telecom Convergent Billing Rating

Figure 3: The diagram illustrates Balance Management Process.


  • Method of checking and booking account funds based on available credit
  • Required to authorize multiple simultaneous requests for available funds from a single account
  • Moves through four stages:
    • Creation
    • Extension
    • Commit
    • Cancel

Reverse Rating:

  • Determines the amount of time or volume to be allocated for a transaction
  • Monetary amount is converted into a token of value. For example, number of seconds or volume of data
  • £1.00 = 1 minute of talk time = 1 token
  • The reverse of the normal rating process where an event is rated to generate a charge

Rules for Max Reservations

  • The Available Spend for a Credit Limit is determined by the Account balance, the unbilled charges and the Commerce Engine Open Reservations against the account.
  • Account balance transactions e.g. adjustment, invoice, payment.
  • Unbilled events charged to the account e.g. package/product activation event charges/one-off event charges/usage events rated but not yet billed.
  • Open reservations against the account.
  • Maximum token size is configured in Derived Attribute (DA) table.

 Advice of Charge

  • Allows the customer to know the cost they may incur for an item of content or the rate for volume-based or duration-based services.
  • The advice of charge information is returned in real-time and may include:
    • Available balance
    • Rate information such as cost per minute or a one-off charge
    • Maximum possible call duration, given the current balance

Reserve and Debit Message Flow in a Billing application

The Application’s core receives and responds to messages from external applications requesting credit to be reserved against a customer’s account and, if successful, later charging (committing) those reservations. This “reserve and debit” process flow represents the core’s primary mode of operation.

The following table shows messages sent from the external applications to the core and the expected response:

Message Expected response
ReserveUnitReq reserveUnitRes or reserveUnitErr
DebitUnitReq debitUnitRes or debitUnitErr
reserv and debit message flow Telecom Convergent Billing Rating

Reserve and Debit Message flow scenarios in a convergent billing application

Figure 4: The diagram illustrates the different message flow scenarios that can occur for event transactions between the Application Commerce Engine (CE) and the external applications.

Rating Engine

A server, let’s call it trerate, authorizes real-time events and passes completed events on to the rating engine, which combines normalisation and rating. The rating engine runs under the control of broker (BKR) process, which in turn is controlled by a backend monitor process (BMP). The BKR provides services to the other rating processes and manages the shared memory segments used for caching data from the database, and for inter process communication.

There are three cooperative processes normalisation process, rating process and output process (ENM, ERT and ERO) as part of the rating engine working together in the following way:

As an (alpha) event may originate from a number of different devices or sources, all events must be converted into a standard form, in the application this process is called normalisation and is performed by the ENMs. Once the ENM has normalised an event it then validates the event to ensure that all the fields required for rating are present and contain appropriate values. If an event cannot be normalised the ENM passes it directly to the ERO which writes the event and an associated error the event error table.

Once an event is normalised and validated, it is passed to the ERTs where it is rated. The charges generated by the ERT are passed to the EROs for loading into the charge table. Database loading can be done directly or by means of intermediate files and the SQL*Loader utility. If a charge cannot be generated the events is passed to the EROs for loading into the event error table.

Event Normalisation (ENM) process

Real time events are serviced through trerate. Trerate then passes on the event to ENM.

This process converts alpha events (input data) from file or from a remote host into normalised events.

  • Raw events are parsed into fields based on a DIL (Data Interface Language) specification. The DIL specification may perform initial cleansing.
  • Parsed field values are assigned to event direct variables.
  • A sequence of expressions performs final validation and calculates the final values of the event direct variables.
  • The normalised event is built by ordering the event direct variables according to the record layout.
  • Variables used by the ENM are defined with an Application Environment of Rating and a context of Normalised Event.

Event Rating (ERT) process

In this process the normalised event records are aggregated and rated (costed) by applying the appropriate tariffs.

  • Events are guided based on the Charge Party to a Service Name (unique) or Network Name (non-unique). Tariffs from all guided services become eligible.
  • Global and service tariffs are selected, based on eligibility criteria, to be applied.
  • Every tariff successfully applied produces a charge record (multiple rating).
  • Each charge is guided to an Account
  • For aggregation tariffs, the separate aggregation balance of an account is updated in real-time when the charge is guided to the account.

Event Rating Output (ERO) Process

In this process the normalised event records are guided to a customer account. It directs the rated events from the ENM and the ERT to a remote host, or to the database. Database loading can be done directly or by means of intermediate files and the SQL*Loader utility.

  • The Normalised Event is received directly from the ENM. The ERO waits for the ERT to send the generated Charge Records.
  • The mapping is based in the Direct Variables for inserting into the database, or the Charge Output Definition for output to a socket.
  • Synchronization is performed at configurable intervals to enable error recovery and restart.
  • The socket protocol outputs each record and waits for an acknowledgment.
  • The loader files and direct update mode, process the output in configurable sized batches.
  • The loader files are in SQL*Loader format including a load script, control file and a data file.
  • Partitioning configuration is stored in the loader files or processed immediately for direct loading
  • A unique index on the event table is used to detect duplicates. Duplicates are detected on insert and automatically stored in the event error table. The unique index can be customised to include the required fields in the event

Event Rating Broker (BKR) Process

Broker controls all the application caches. This is the mother process of all rating processes

This listens and responds to its children through a socket called broker socket.

The flow of processing in the BKR is as follows:

  • On startup, the BKR connects to the database and creates, or connects to, the caches used by the ERT and trerate processes.
  • If there are ENM, ERT, or ERO processes associated with that BKR, it creates, or attaches to, the shared memory segment and starts the ENM, ERT, and ERO processes that have been configured for that BKR.
  • If no ENM, ERT, and ERO processes are associated with that particular BKR, the BKR does not create or attach to any BKR shared memory segments. One BKR process can then be responsible for the caches and other BKRs responsible for one or more ENM, ERT, and ERO processes.
  • If all processes are running on one machine, the BKR performs no function other than to monitor the other processes, and to pass external commands onto the appropriate rating process.
  • Every certain configured amount of seconds, the BKR cleans up the rating streams and caches.

event rating broker Telecom Convergent Billing Rating

Figure 8: The diagram illustrates the flow between different components of Rating Engine.

Rating Technicals

Atomic and Non-Atomic Events

  • Atomic Event: whose charge can be predicted prior to the transaction commencing; event based (SMS and accessing content). This will involve a one-off charge amount.
  • Non-Atomic Event: whose charge cannot be predicted prior to the transaction commencing, but will instead be set based on the actual duration (voice)/ volume (data) used or consumed.


In order for a customer to be real time rated, for a single event, the following operations shuold be associated to a customer account:

  • Balance management, which provides event authorisation, advice of charge information, and customer credit reservations.
  • The normalisation of an event  where event and transaction data are converted into a standard format to be stored in the billing database.
  • The rating of an event where the normalised data above is aggregated and rated by applying the appropriate account tariffs.
  • The output of an event, in which the rated event records above are stored in the database for further processing of the invoice engine.
  • Billing ooperations there the rated event records are aggregated, and additional charges and discounts can be applied if case.(for example, for recurring events).

These operations are carried out in this scenario by the following components:

  • The rating server, which authorises real-time events, handles credit checking, and passes completed events on to the rating engine to be stored in the database.
  • The rating engine , which combines normalisation and rating. The rating engine is a series of pipelined processes. The input is the CDRs; output is database records containing normalised charges rated against an event.
  • The billing engine that passes information to the rating engine to generate recurring charges and/ or adjustments, calculating the associated billing charges.



Article reviewed and approved by: Garais Gabriel
PhD Lecturer at "School of Computer Science for Business Management" - Romanian-American University

Article Autor/s:

Bogdan Cazangiu

Software Development Team Lead

Leave a Reply