21 Apr 2011

Real-time rating with Oracle BRM

Oracle BRM 2 Comments

Nowdays, more and more companies would like to employ AAA GW real-time rating, yet they are faced with many questions. In this article, some of these will be answered, conventional batch rating will be contrasted with realtime rating, and some benefits of the latter will be shown.

In conventional batch rating, all event data are read from CDR/EDR files after events are already finished. Event data are processed, rated, and charged.

Picture 1: Conventional batch rating

In realtime rating, data are processed when events are attempted or even in progress. Events are authorized, reauthorized, and, at the end, charged.

Picture 2: Real-time rating

When planning a realtime system, it needs to be designed in a way that minimizes the posibility of interrupting services or incurring any revenue losses. To minimize those, latency, high availability architecture, cm/dm separation per service for easier production maintainance, and efficient monitoring all have to be taken into consideration.

Picture 3: Monitoring of real-time traffic with Enterprise Service Manager.

With realtime rating, prepaid and postpaid users can be accommodated in one system – such a system is called convergent billing. Realtime billing offers even more benefits, such as postpaid credit limits, and realtime feedback after customer usage.

Picture 4: Postpaid accounts can get credit limits - 32 Mbytes transferred in EU countries, 32 Mbytes transferred outside EU, 30 EUR prepaid account top-ups - and a threshold for notifications can be set.

Picture 5: Realtime feedback after customer usage on Android application, WAP portal, and USSD.

In one of the next articles, more details will be presented regarding AAA GW, interaction workflow for calls (mbi,) and gprs/mms/sms (diameter.) Follow us on Twitter, and stay tuned.

2 Responses to “Real-time rating with Oracle BRM”

  1. Ayazul Abdullah says:


    It’s me again. I’m interested in your real time rating. I’m currently assessing the architecture laid out by our SI. I won’t mention any names. How do you classify an architecture as high availability? Anyone can declare that theirs is HA, how much HA is actually good HA? Any variables that need to be considered? Any specific formula that I can refer to?

    Another question, with regards to AAA using diameter protocol. We are using pipeline to process the diameter packets, Diameter manager is not being implemented over here. Where can I find the log file, because in those days, when IPT manager was still still around, you can find the packets log files in $PIN_HOME/apps/radius_ipt/radius_ipt.log, but for diameter packet, I’m clueless.

    Please advice.

    Thanks in advance.


  2. admin says:

    Hi Ayazul,

    Our description of high-availability is the capacity of a system to maintain performance subsequent to the breakdown of one or more of the servers. A major component of high-availability is failover, that is the capability for client connections to transfer from a downed server to a functioning one should server failure occur, thereby allowing client applications to keep on operating.

    We agree with your statement that anyone can declare that his/her architecture is HA. Yet, it’s not possible to give a simple answer to your questions. We would first have to analyze the customer’s HA architecture and then do the required testing.

    Regarding the second question, in general you can find diameter logs in the /opt/portal/pre_dia/log directory.

    If you would like to go into more detail, please feel free to contact us directly.

    Best regards,

Leave a Reply