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.
Conclusion – 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.