Convergent Billing – This post was originally published on 30-January-2014 on Linkedin but got deleted accidentally so republished on 30-January-2015. This post is meant for discussion and constructive arguments around telecom billing systems. This write up is neither a conclusion nor a research paper on prepaid/postpaid IN billing system architectures. This post can be taken as an observation and knowledge sharing idea out of on ground experience.
Online and offline charging are integral capabilities in any MNO/MVNO setup. Prepaid services always need online charging for real time service authorization, rating and balance management. Postpaid services can use this online charging architecture for new service offerings. Here comes OCS for required services where in-session charging and control are essential.
OCS (Convergent Billing) provides the charging platform for bearer, sub-system and application layers within IMS.
Routes, Singling and Controls
Proxy Call Session Control Function (CSCF) –Determines applicable I-CSCF, Routes SIP signalling between UE and S-CSCF, Resource control via embedded PCF.
- accepts requests and forward them on
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.
Convergent billing and DCC Architecture
Convergent billing and the split OCS architecture tend to present many benefits to the operator. They could bring out complexities as well where the implementation of business rules can prove to be very difficult. This means MNO often lose flexibility for when they offer freebies (airtime, sms etc) without proper strategy.
Now lets look at DCC or Diameter Credit Control request messages in OCS. These messages are sent by network elements over Ro Interface and received by online charging module message processor function. As part of processing these messages, this module 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.
End to End Architecture and OCS
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 contrary, OCS (by 3GPP architecture) has both rating and balance management functionality. For example in case 100 free minutes balance should reduce first before making an attempt to charge main airtime wallet. 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.
OCS & Its Efficiency
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 reducing 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.
Rating Engines & OCS
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 more charges/taxes which are based on usage patterns or an accumulated amount over a certain period). This functionality usually resides outside 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.
Future of Telecom Billing i.e OCS after AI, Data Science and NCS
Development of convergent billing is a continuous process. This process keeps rolling 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 Charging Trigger Functions (CTF) which is essentially a core function
- Charging Data Function (CDF)
- Online Charging Function (OCF)
The address list to which it can send its charging events and/or charging requests 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.
Different users need different security tools (Customer Prospective)
There is need of automated security assistant that learns the needs of the individual user and helps them to apply security tools. For me as an individual my cyber security needs are data confidentiality, data-loss tolerance limits and recovery costs. On back-end machine needs to learn my usage patterns, technical knowledge and security choices I make.
Books + Other readings Referred
- Open Internet
- Hands on personal research work @AILabPage
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.