Principles of rating
In OSB the rating process is responsible to retrieve the call records from the network, to rate the calls according to the tariff system that is valid for the involved parties and to store the rated usage records in the database.
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 gives an overview of the OSB rating process:
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:
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.)
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:
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:
|Authentication||Resources -> PPI -> PPN -> PP -> Contract
|Authorization||PPI -> PP -> available services
For a prepaid system it is inevitable that a user's credit is read from the
database for each connection1).
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?
1)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.
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:
These data allow us to calculate the percentage of records (relative to the original number) in a given status.
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.
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
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.
For each file
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).
|I||For each used service the tariff system ...|
|II||... lets the service class group determine the service class ...|
|III||... gets the tariff classification system (TCS) valid for this service class ...|
|IV||... lets the TCS determine the tariff class ...|
|V||... gets the tariff period group (TPG) valid for this tariff class ...|
|VI||... lets the TPG determine the tariff period ...|
|VII||... gets the tariff valid for the tariff class and period ...|
|VIII||... lets the tariff rate the CDR.|
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
The post processing stage involves the following
For each Cdr