Convergent Billing – 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. This post is meant for discussion and constructive arguments around telecom billing systems. This blog post 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 an on-ground experience.
OCS (Convergent Billing) provides the charging platform forbearer, sub-system and application layers within IMS.
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 let’s 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 interacts 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 – Convergent Billing
The high-speed driving need for OCS is to accommodate all the required changes in the modern time. Thus the change required in architecture is to adjust the sudden burst and dramatic rise in mobile data traffic. The intelligent system now needs to partner with artificial intelligence, quantum computing, machine learning and many more new generation network components. This is where then end-to-end architecture needs further consideration.
- The new networks are designed to transport higher loads, 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? Both utilize the diameter protocol to manage and monetize traffic.
- 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).
<
p style=”text-align: justify”>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.
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 it’s 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.
it’s 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 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.
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.
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 ratings 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 adapted 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.
Different users need different security tools (Customer Perspective)
There is a need for an automated security assistant that learns the needs of the individual user and helps them to apply security tools. For me as an individual, my cybersecurity needs are data confidentiality, data-loss tolerance limits and recovery costs. On the back-end, the machine needs to learn my usage patterns, technical knowledge and security choices I make.
Disclaimer
All credit and credits of contributions remain with original authors and I sincerely thanks for their contribution here. Welcome to the future of charging and billing systems. In this post, we have discussed the potential merger of AI and its bundle pack i.e. Machine Learning, data science and analytics. In the next post, we will pick up a specific use case to deliberate on.
Books + Other readings Referred
- Open Internet – NewsPortals, Economic development report papers
- Personal & professional working experience of @AILabPage members.
Feedback & Further Question
Do you have any questions about Deep Learning or Machine Learning? Leave a comment or ask your question via email. Will try my best to answer it.
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.
FacebookPage Twitter ContactMe LinkedinPage ==========================================================================
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!
Actually a best post with proper pictorial representation about Online Charging System.