Telecom Billing - Rating Processes

Rating Process

Rating Engine receives the events in the form of data records called as Call Detail Records (CDRs) or Usage Detail Records (UDRs), which describe the use of a product/service. A CDR is a string of data that contains call information such as call date and time, call length, calling party, called party, etc., which are used to rate the events.

There is a list of basic functions of Rating/Rating Engine −

Accepting CDRs from the Mediation System or other service providers or roaming partners in case of roaming usage.
Validating the CDRs and eliminating any duplicate records. These duplicate events are stored in a database table for later verification.
To determine the customer account that has to be charged for the event. Here, Rate process picks up the event source ( Mobile Number or IP Address, etc.) and checks the database to verify if this event source is associated with any account. This step is called Event Guiding.
If the event can not be guided, then this event will be rejected and can be put in suspense category. These rejected events are stored in a database table for later verification.
To calculate the cost/price of the event as per the rating tariff (also referred as rate plan).
To apply any applicable rating time discounts. This could be first five minutes free and after that call will be charged at normal rate. Such type of discounts are called rating time discounts.
To store the rated event in the database for a billing purpose or send it to the external system for billing.

The following image shows an overview of the Rating Engine and its associated functions −

The customer's information determines the rate plan (rating tariff) to use in charge/price calculation. The rating engine uses the rating tables, and the event information from the CDRs (e.g. distance, time of day, location of the call, duration or volume of the event, etc.) to calculate the actual charge for each call.

Duplicate Events

A duplicate event is defined as any unbilled event that relates to another unbilled event in all of the following ways −

The account numbers are identical.
The event sources are identical.
The event type IDs are identical.
The event dates and times are identical.

Any other criteria can be defined in the billing system to identify duplicate events. There are a number of situations that may cause duplicate events to be submitted to the Billing system −

A failure of the mediation system's filtering mechanism.
Coding errors in the mediation system software.
A repetition of all or part of an event file being passed to the Rating Engine.

Rejected Events

When Billing System encounters a problem with a particular event, the offending event is rejected. Rejection may be due to problems with any of the following −

The event itself.
The rate plan.
Customer and account data.
Configuration data.

There are three main reasons for rejecting an event −

Parsing errors prevent the Billing System from reading the information in the event detail record. A parsing error may occur because the data in the event record is corrupt or in the wrong format.
Unguideable errors prevent Geneva from identifying the event source or account associated with the event. An unguideable error may occur because the event source does not yet exist in the Billing System database.
Unrateable errors prevent Billing System from calculating a cost for the event. An unrateable error may occur because of problems with a rate plan.

All the rejected events are posted to a special account, which is called internal account or suspense account and these rejected events are called suspense events. Finance department keeps track of all the rejected events and count them as a part of revenue loss. IT department always gives alot of attention to resolve rejected events and rate them properly to save revenue.

If a rejected event cannot be fixed and the Operator does not want to post it to an internal account, the event can be discarded. When an event is discarded, it will not be submitted to the Rating Engine and no further attempts to rate it will take place.

Real-Time Rating

Real-time rating is the process of taking events as they occur and rating them immediately, with as little delay as possible between event generation and costing. Real-time rating can be contrasted with file-based rating, where event details are stored in a file buffer for hours, days, or weeks before the whole file is finally rated.

Real-time system process includes e-commerce transactions and data download. Any application where events must be rated and applied quickly to a customer's account is a suitable candidate for real-time rating.

Rerating Events

There are several situations in which it may be necessary to rerate events. For example, when −

An error in the rate plan used resulted in incorrectly priced events.
The events were loaded against the wrong account (due to incorrect event source registration).
An existing rate plan was replaced at some point between the last and the next billing dates.
The rate plan, price plan, or event source for a product has been retrospectively changed.

The process for rerating events is very simple and it is as follows −

Unload/Unrate all the events from the database using provided utility. Most of the billing system provides a utility to unload or unrate all the rated events.
Fix the problem wherever it lies.
Resubmit the events for rating by the Rating Engine.

Partial Events

Partial events allow a customer's balance to be maintained while an event is in progress.

For example, in case of a long data download, mediation system will keep sending partial events to the billing system so that billing system keep rating them instead of waiting for event completion, and as soon as customer's credit limit breach, account will be barred and Network element will be informed to terminate the call.

Thresholds and Actions

The Rating Engine can automatically check to see if any rating time thresholds, including rating time discount thresholds, have been reached.

Rating time thresholds help in protecting operators from lots of revenue loss. For example, a customer may not be willing to pay more than his credit limit, in such a case, it becomes necessary to terminate customer's call as soon as it reaches to credit limit threshold.

If it is required to take rating time action, then it is important to have as much as real time rating as possible.

What is Next?

So far, we have seen how a customer generates usage and how mediation system pushes that usage (CDRs) to the Billing System and how a Billing System rate those CDRs.

In the next chapter, we will discuss how to collect all the rated CDRs for the whole month and generate final invoice/bill, which is sent to the end customer to collect revenue for the provided services.

Previous Page Print Page