Convergent Billing- As One Product Catalog

V Sharma on December 12, 2015

Mobile Comerce

Abstract – This post Convergent Billing – “As one Product Catalog was originally published on 30-January-2014 on Linkedin but got deleted accidentally so republished on 30-January-2015 and  article is meant for discussion and constructive arguments only. The post is not an conclusion or guidelines book/paper on prepaid/postpaid IN billing. Questions and answers are welcome. Online and offline charging are integral capabilities in any MNO/MVNO setup. Prepaid services always require online charging for real time service authorization, rating and balance management.  Postpaid services can use this online charging architecture for new service offerings. The OCS is required for services where in-session charging and control are essential. It provides the charging platform for bearer, sub-system and application layers within IMS.

Proxy Call Session Control Function (CSCF–Determines applicable I-CSCF, Routes SIP signalling between UE and S-CSCF, Resource control via embedded PCF.

Serving CSCF–Responsible for session control, Interacts with service platforms, May behave as SIP proxy or user agent

  • accepts requests and services them internally or translates / fw them on
  • may terminate and independently generate SIP transactions

It consists of functional entities such as the adaptation layer, real-time billing engine, policy engine, transaction-processing engine and management engine..

Introduction – While Convergent billing and the split OCS architecture tend to present many benefits to the operator, they could bring out complexities where the implementation of business rules can prove to be very difficult, i.e. you lose flexibility in case you give freebies (airtime, sms etc). In actual usage, Diameter Credit Control Request messages sent by Network Elements over Ro Interface will be received by the Online Charging Module’s message processor function. As part of processing these messages, this module will need to interact with the Rating Function Module, as well as with the ABMF module. In Convergent billing systems, we have modules, which take care of Online Charging (Prepaid) and Interconnect billing (Batch/Postpaid) as part of a single billing system, like the OCS System.

Main Story – This is where then end-to-end architecture needs further consideration.
* How are calls routed in the first place?
* Are all calls sent to S-OCS and if no Free Call Balance call is re-routed to P-OCS?
* Are all calls handled by S-OCS and if no cached balance uses DCCA to do normal quota management with P-OCS (as per case 1 above)
* How does S-OCS get the 100 minute quota and expiry date to start with? (Push, pull?)
* Architecture should allow this to change (i.e. some value other than 100 free minutes, some interval other than 1-month, etc)
* What happens to a call where Free Call Balance is consumed during a call?
* What happens to calls from subscribers who have Free Call Balance but it cannot be used for this call type (e.g. international call, premium rate number).


There’s no single answer to this without end-to-end architectural analysis. In most modern Online Charging Systems, creating a recurring accumulator that provides x free minutes (or y free Gb…) that are provisioned every month and follows the “use them or lose them” method is pretty basic. The Billing Proxy can then send the relevant charges (if any) to the OCS.

On the contrary, OCS (by 3GPP architecture) has both Rating and Balance Management functionality. The “100 free minutes” is indeed a ‘balance’ that has to be decremented and managed at the end of a stated period. So it depends whether the OCS you refer to includes Balance Management or it is merely a Rating system and must fetch/store balance via Billing.

I assume for efficiency, OCS includes the 100 free units balance. Also, not clear what happens if the 100 minutes are exceeded. Does OCS still handle Rating or are all calls diverted to Billing for Rating purposes using (say) a $$ balance? Is it Prepaid, or only Postpaid? If Billing is doing online charging then Billing is an OCS too! If its only offline then I guess its Postpaid. Usually CDR’s need to be delivered to Billing (regardless of them being zero-rated due to 100 free minutes) for consolidated usage records, complaints handling, invoicing etc. So if Billing is only Postpaid, why do online charging? Just let the CDR’s flow and get zero-rated due to 100 free minutes allowance. If Billing is doing Prepaid as well.


its an Online Charging System, meaning you have 2 x OCS and hence 2 systems with split subscriber balances. 

An end-to-end architectural approach below.

(1) If you use DCCA from S-OCS to P-OCS for every call then P-OCS is the only OCS and S-OCS is really an SCP containing the Call Trigger Function (CTF) and performing CAP/Ro translation. Use of SCP/OCS is common architecture and if each call must be handled by P-OCS you may as well go for a full implementation.

(2) If S-OCS is acting as a free minutes cache then it can handle calls by decrementing free minutes without the need to refer every call to P-OCS. So how would these interact? Assume S-OCS is happily handling free calls for a subscriber based on a local “Free Call Balance” and need not refer to P-OCS… unless the Free Call Balance is consumed. Generally we can also assume this will happen mid-call.

Usually all rating and balance/accumulator updates happen inside the OCS. If the subscriber has a ‘free service usage credit’ (airtime, sms, data etc..) it is also being handled inside the OCS. The OCS performs both rating of events and the balance management function. 

DCCA/CAP/WIN/Parlay-X etc interactions are handled inside the “Protocol/Signalling Layer” or SCP so to speak. This is adopted from the classic SCP-SDP architecture of IN. 

There is some logic which might need to be performed in a batch (i.e. complex discounting or additional charges/taxes which are based on usage patterns or an accumulated amount over a certain period of time). This functionality usually resides outside of OCS. 

As such, ‘Convergent Billing’ usually consist of SCP + OCS + other functionalities (invoicing, re-rating, batch charging etc)

OCS was released and more fully defined in 3GPP Release 6. Based on core network development, its functional entities were extended to support bearer layer charging, event-based charging, rating function, and account balance management.


The development of convergent billing goes along with the changes in both telecom network architecture and new service development. As a focus in the telecom charging field, convergent billing is driven by the following core factors: Each Charging Trigger Function (CTF) would have Charging Data Function (CDF) and Online Charging Function address list to which it can send its charging events and/or charging requests. List is organized hierarchically. If the primary charging function is not available (e.g., out of service) then the CTF shall send the charging information to secondary charging function and so on. Each CDF in PLMN may know other CDF’s network addresses (e.g., for redundancy reasons, to be able to recommend another CDF address with the “Redirection Request” message). Worth remembering is that each network element that generates charging information will send the information only to the charging entities of the same PLMN, and not to charging entities in other PLMNs.

Sign-tConclusion – As a development trend for the operation support system, convergent billing has a broad scope that is not limited by a single standard. Its development may follow different directions. However, which is the best direction? The answer lies in the analysis of OCS development within the 3GPP framework, coupled with an evaluation of the driving factors and key capabilities required by convergent billing.   
There’s no single answer to this without end-to-end architectural analysis. Let us open a discussion on this and build some intelligence around it.


====================== About the Author =================================

Read about Author  at : About Me   

Thank you all, for spending your time reading this post. Please share your feedback / comments / critics / agreements or disagreement.  Remark for more details about posts, subjects and relevance please read the disclaimer.

FacebookPage                Twitter                          ContactMe                          LinkedinPage    ==========================================================================


Posted by V Sharma

Specialised in Financial Technology(FinTech), Artificial Intelligence for Fintech. Mobile Financial Services (Cross Border Remittances, Mobile Money, Mobile Banking, Mobile Payments), Data Science, IT Service Management, Machine Learning, Neural Networks and Deep Learning techniques in FinTech. Mobile Data and Billing & Prepaid Charging Services (IN, OCS & CVBS) with over 15 years experience. Led start ups & new business units successfully at local and international levels with Hands-on Engineering & Business Strategy.

One Comment

  1. Interesting article Vinod.
    In my experience and not necessarily following the 3GPP suggestions, it is better to have the OCS part separate from the SCP/transaction handling part. Keeping a separation between them allows a simpler way to add additional interconnection methods – whether simply new platform protocols such as e.g. wifi or new business methods such as say, 3rd party product sales.

    Also I believe that the OCS should see rating and charging a single real time task whether the ultimate account is to be deducted (prepaid) or added towards a periodic post paid charge. In this way an account can be defined at the beginning of the month as postpaid until a preset limit is reached at which point it is frozen until the subscriber prepays for more or part pays for their monthly bill in advance of the normal due date. This is a simple concept to explain to subscribers (which is a good thing!) as well as only needing a single repository and OCS – the decision as to whether an event can go ahead is defined by the user’s available credit – defined as remaining credit for the month in a postpaid account or as up front credit in an account that is either originally prepaid or has moved to this mode during the month. Rating for the different situations can be differential since a simple account check will determine the current state and thus which type of rating to apply. Again, conceptually simple for the consumer and straightforward to apply.

    Just my 2c!

    Liked by 1 person


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: