Principles of rating

The end user of a network is always a subscriber of the own network or of a roaming partner. The rating process also has to determine any other party that is involved in the network usage and calculate usage rates accordingly. Such other parties may be interconnect carriers, content providers or wholesale partners.

Diagram Rating process overview

Rating process overview

Diagram gives an overview of the OSB rating process:

• Usage records are generated by various UsageRecordSource. This may be elements of the own network or external sources, e.g. a roaming partner.
• Mediation reads the records from the sources, converts them to the OSB internal format and writes the resulting records into usage records files.
• Generated UsageRecordFile are registered in database tables for record accounting purposes.
• The RatingProcess reads its input from the UsageRecordControl table, rates the records of each input file and forwards them to the storage module.
• Storage is responsible to store the usage records in the database and to update affected balance sheets. In addition the module needs to track its work in the usage record accounting tables.

Performance issues

Before going one step further and discuss the three main processes of rating in more detail, we should identify the performance critical steps of the overall rating chain. It is not surprising that both of them are related to database, i.e., I/O, operations. There are two different concepts how OSB deals with this bottleneck:

• First of all the system must be designed to avoid unnecessary, redundant read and write operations on the database.
• Where this is not possible, we should avoid burst database access and try to balance the I/O over time instead.

The first performance critical step is in the record rating process. There we'll have to identify the OSB contracts, validate the network usage and choose the correct tariff system to rate the call. The goal is to "correctly" rate the network usage based on data that was valid at the time of the call. We simply can not afford to read the (rating relevant) contract data for every single usage record. The design of our solution should be based on the fact that, once created, contracts are changed only seldom.

The second performance issue is the process of storing the usage records in the database. This step typically inserts data into huge database tables and at the same time updates the balance sheets. The first issue is mainly a matter of the database design: Oracle offers partitioned tables and hashing mechanism to overcome the problems. For the second item we should keep in mind that it must be possible to run OSB applications concurrently: on-line, rating and billing. This means a balance sheet must be locked for shortest possible time only.
But there one more problem to solve: Some applications (currently billing and rating) lock more than one balance sheet before the changes are committed. This behaviour raises the following requirements: Firstly it must be possible to delay database transactions if a balance sheet is locked and secondly we have to handle deadlocks that result from crosswise locking of balance sheets. (One might think that deadlocking can be prevented by setting up rules on how database locks may be acquired. There are two reasons why I think that such an approach does not really solve the deadlock problem: Locks are acquired and released by applications, so how can enforce the locking rules in the OSB library? The library is more general and more stable if it can handle deadlocks properly, instead of specifying that any deadlock -due to locking rule violation or incomplete locking rules- result in undefined behaviour.)

Open issues

• Bundled rating: How do we implement something like 10 SGD per 100 MB transferred data? (It is implied that the 100 MB can be "consumed" during several connections.) Should we store the information that is needed to fulfill the requirement in the balance sheet? Or is a personalized product node more suitable?

Aspects of prepaid rating

Prepaid rating differs from postpaid rating in various manners. This section discusses some of the know issues and lists open questions on the implementation strategy in OSB.

The services that a rating server has to provide in prepaid network are commonly summarized as AAA: Authentication, Authorization and Accounting. Cisco provides the following short descriptions:

• Authentication validates a user's identity.
• Authorization limits what a user is allowed to do on the network, usually defined by a profile for the user or a group to which the user belongs.
• Accounting tracks what a user is doing or has done on the network.

For the OSB rating module the above means that the AAA services must be available as independent functionalities. The first idea for a mapping of the services to OSB library objects and functionality is given in the table below:

For a prepaid system it is inevitable that a user's credit is read from the database for each connection¹⁾.
Things are even worse: During authorization the rating system determines the maximum "connection volume" and the network will close the connection when this limit is reached. Once the call is completed, the rating system will receive the actual usage record and update the balance sheet accordingly. For us this means that the balance sheet of the resource must be locked from the moment the rating system tells the maximum call duration to the network until the final usage record is stored in the database. Should we maintain a real database lock (select ... for update) or set a flag in the balance sheet. In the latter case: what are the criteria to clear the flag if the completion usage record is never sent to the rating system?
¹⁾This is in contrast to a postpaid system where calls can be validated and rated using information that is cached in the memory of the rating process and later —when the records are written to the database— take corrective actions in case of erroneous assumptions.

In general the end users are are not known in the billing system, rather resources are used for identification. This means that resources must have flag prepaid.

How (and where) do we define what services are available for a prepaid resource?
When using existing classes the following approach could be used: Every prepaid resource get a template contract assigned. The first time a resource is activated we create a contract.

Where do we store the credit, how is it linked to one or more resources?
Logically this is at balance sheet level, because it stores information abount the current account status of a contract/customer.

Mediation

Record Accounting

OSB tracks the processing status of the usage records for each input file until the records are billed. The goal is to maintain processing statistics in a way that allows operators to get a quick, easy to understand overview and at the same provide enough detailed data to track each individual record. The complexity of the task arises from the fact that
a) one usage records can be written into several output files, e.g., end user records and whole-sale partner
b) several usage records may be combined into a single OSB record, e.g., assembly of partial usage records or merging records from different network elements.

For each incoming usage record file OSB maintains the following figures:

• original number of records
• number of current records
• number of rated records, i.e. stored the usage record database
• number of billed records, i.e. written to an invoice
• number of records with errors (anywhere in the processing chain)
• number of filtered records (anywhere in the processing chain)

These data allow us to calculate the percentage of records (relative to the original number) in a given status.

Record rating

The OSB rating process consists of the four modules record conversion, record dispatching, the actual rating process and the storage of the usage records. Diagram shows the collaboration of the 4 modules when the rating process is run in postprocessing batch mode.

Diagram Workflow OSB rating in batch mode

The module RecordConversion converts the incoming UsageRecordStream into the OSB internal ASN.1 usage record format and registers them in the database tables used for usage record accounting. In post-processing batch operation the conversion of usage records is independent of the three other modules.

The other three rating modules must run at the same time because they process and exchange individual usage records in ASN.1 format. This solution was choosen because it is flexible enough to support scaled, distributed rating applications: Using ASN.1 as exchange format enables us to use any communication protocol amongst the 3 modules.
(The disadvantage of the concept is that the ASN.1 encoded records are parsed three times. However this does not require I/O operations from permanent storage, so the impacts on the overall performance of the rating process should be aceptable.)

RecordDispatching reads the usage record control tables and processes the related usage record files. For each usage record it determines the rating engine to do the actual rating and forwards the record accordingly.
The RatingEngine determines the rates for every record, stores the result inside the record itself and sends the record to the storage module.
RecordStorage stores the usage records in the database and updates the control tables accordingly. It is the only module that needs to know about the database format of the usage records and to handle calls where several parties are involved.

Overview

For each file

• determine file attributes and generate reference lists
• for each record
  • determine chargeable parties
  • for each party
    • validate usage
    • determine applicable tariff system
    • have tariff system rated the record
      • for each used service
        • get tariff class and tariff period from tariff system
        • apply tariff
• perform usage record accounting

Determination of the tariff

Once rating has identified a party for which a usage record should be rated, it forwards the record to the applicable tariff system for the actual rating. In order to find the tariff that is to be used, the tariff system has to determine the tariff class and the tariff period (remember that a the tariff system links a pair tariff class, tariff period to a tariff).

Steps:

Record storage

For Prepaid:

Once the rating engine identifies the accounting request the Cdr needs to be stored in the database.

For each of the Cdr sent as input

• Convert the Cdr into OSB UsageRecord.
• Store the record in the OSB database.
• Return the status

Post Processing

The post processing stage involves the following

For each Cdr

• Encode the Cdr in the ASN.1 format
• Store the encoded Cdr contents in a file (possibly)
  In case of writing the ASN.1 contents into the file we have to take care of having some sort of a locking mechanism for the file.