Saturday 11 May 2019

ChaaS: Monetizing Charging for 5G

In continuation to my previous 5G articles, I have decided to write down a detailed one on Charging; i.e how to make money out of not only 5G network infrastructure, but from the Charging System itself and add another petal to the XaaS Chain, which is ChaaS (Charging as a Service).

Very few people will initially agree that Charging can actually become a Service, since we are used to have a differential thought process, when it comes to Revenue assurance systems. CSPs and Telco vendors usually think Charging as an integral part of Revenue Management (or BSS) and hence always work towards the Telco only use cases. As a matter of fact, nobody has ever thought of it before seriously.

Now since 5G R15 is already released and R16 release is in progress, it is very clear from the Architecture  (Reference Point Architecture & Service Based Architecture) itself that Charging Function (CHF) is going to have a Service Based Interface (Nchf), just like other NFs of Control plane. Here 3GPP itself giving an opportunity to Telco vendors and CSPs to actually use the functionalities of CHF (5G version of OCS) as a Service and not the other way around. Having said that it is also very important to understand, what exactly the ChaaS is all about?

"ChaaS (Charging as a Service) goes beyond Telco. It is the capability of CHF to charge any digital service, offered by other non-Telco verticals, along with the traditional Time, Volume and Event Based Charging."




This is the time, when CSPs should take the lead over other verticals, which have never been thought of any connection with Telso business so far. Telcom industry has the potential to not only monetize the network infrastructure, by providing vertical industry use cases (mMTC, URLLC), but also to influence them and lead them to the ultimate goal of INDUSTRY 4.0.

"When we say, beyond Telco or Non-Telco-Verticals, it essentially not only mean about Infotainment media (Netflix, Spotify etc.), but it means non-IT verticals as well; such as, Cab hailing Services (Uber, Ola, Grab etc.), Logistics industries (DHL, Blue-dart, DTDC etc.), Petroleum Industries (BP, Essar, IOCL etc.) and so on..."

We will now go step by step and first we will look at a particular use case in details and understand the requirement. Then we will see the possibility of ChaaS around it and what would be the business model for the same. Lastly, I will detail the functional and non-functional gaps of current Charging System and how to fill them to make the ChaaS possible.

Requirements

Let us now dig deeper on how to make it possible and what should be the prime target vertical industries, when it comes to ChaaS. The first candidate industry should be the "Cab Hailing Services". It is no news that Cab hailing services are primarily rely on Mobile network coverage. One could never think of an App base taxi service just a decade before. And now even the smallest towns in under-developing countries are enjoying such services of on demand cabs, which is always a click away. And just like OTTs, here they (Cab industry) are using CSPs' network to run their business and earning easy money. However, OTTs have now started partnering with CSPs on revenue sharing basis, but for non-IT industries (such as a Taxi service) it is a bit complex, as for instance, Telcos ARPU is based on Bytes and time, but their (Taxi-Service) are on Km/ Miles. Solving this complex business partnership logic will take a significant time.

Business Model

What could be done here is that Telcos can take a lead by proposing them (Cab hailing services) a Charging Service. Cab hailing companies should only focus on their core business, which is getting more Kms/Miles from their cabs by innovative marketing & offers and leave the Charging complexity to CSPs ot telco-industry and share the revenue on basis of for example: No. of Charging-Events/ Invoice, Total Run-Time, Total Run-Distance etc. This way, Telco can not only earn extra business and revenue from their existing Charging platform, but they can further monetize it to create contextual offers out of the customers' persona.


Similarly, for Logistics industry as well, Telco can offer a charging service based on any parameters from their(Logistics) business logic (e.g Kms/Miles, Time of Delivery, Size of Logistics etc.). But there is a more important approach, which needs to be keep in mind, while addressing B2B or B2B2X model, "The Dimensions of Charging". While finding the Unit of Measure is one critical aspect of new business models, it is equally important to find how many dimensions, we can perform the charging on; for instance, a cab fleet, can be charged for How many distance it has traveled, but it can also be charged how much data user has consumed, during this fleet or how he has used the navigation-service or how much consumption of the resources are done from the data-center, where the mobile-app installed on, and so on...

Apart from this, B2B or B2B2X model will also demand "Real-Time Taxation" & "Real-Time Invoicing". This requirement should not be assumed to be offloaded to Billing System. Since this is something, needed on real-time basis, the Charging Systems (willing for ChaaS evolution), should have the realtime Taxation & Invoicing, for consumer services like Gas-Filling, Water-Vending-Machines, Cab-Fleet, Food-Ordering etc.


"It is clear that their is a visible possibility for ChaaS in a Non-IT vertical industries. But before we get excited, we should see, why it was not possible till date and even will not be if Telcos continue to use the legacy Charging approach (which is built only for Telco business)."


Functional Gaps & Fulfillment

Their are multiple factors to it and let us target one by one:
1. Non-Modular: Tightly coupled Charging(OCS) and Revenue Management(BSS) Systems
2. Industry Specific: Only Volume, Time and Event based Charging systems & Product Catalogue
3. Not Open & Lack of APIs: Charging only possible on 3GPP specific and some proprietary Protocols (CAP, Diameter, SCAP, RADIUS) only
4. Non-Cloud Native
5. Limited Scalability



1. Non-Modularity

Since CSPs will never compromise on their own systems and end users, while serving Charging services to Vertical industries, it make complete sense to deploy the ChaaS nodes separately form their Mobility nodes. But is it really possible to deploy only Charging, i.e without Billing? No matter how much the Telco vendors are claiming that their Charging System is completely separate from their Billing Platform, but in maximum cases, their systems are still tightly bound, due to which the stack size of deployment is huge, even just for an Online Charging System without Billing. And even if they are modular enough to run separately, still their systems work best only when deployed together (i.e OCS and Billing from same vendor). This again add to a higher CAPex, as operators gets less choices and end up paying more.

If Telco-vendors really want to make ChaaS a reality, then their Charging systems should be modular and capable to deploy independently without the need of complete BSS stack. This way, CSPs can minimize the CAPex and only increase Charging Nodes without increasing the Billing Stack.


2. Industry Specific

This is one of the main reason, why even in labs, ChaaS never been possible. The current Rating Function and the Charging-Catalogue (Product Catalogue) are designed only for telcos UOMs(Unit of Measure), which are:
Volume (For Data): Bytes, KB, MB etc.
Time(For Voice): Second, Minute, Hour
Event (For SMS, MMS)

As a result, currently, where at one side Product catalogue is not able to configure Rating based on other UOMs, such as Kms, Miles, Litres etc. the Rating Function as well not able to do the Rating (Conversion of Currency to UOM and Vice-Versa).
So, we have 2 different target modules here, "Rating & Charging Function" and "Product Catalogue". To make ChaaS a reality, it should be possible in Product catalogue to define any Chargable Unit or UOM (Unit of Measure). Hence the configuration of UOM should not be restricted and it should be independent of the Source code. Ideally, it should be part of configuration only; where at one place you can register the UOM first and later same UOM should be available across the system to define the Rates, Free-units and Charges, while preparing the Product-Offers. Secondly, Charging System should be capable to Rate and Charge these Customized and non-telco UOMs, along with the Balance-Management of Free Units.


3. Not Open & Lack of APIs

Currently the Telco Charging systems are only designed to support Standard 3GPP interfaces (CAP, Diameter) only, along with some Vendor Specific ones (SCAP, RADIUS). However in 5G, 3GPP has defined another new HTTP/2 based Southbound interface(N28) between the CHF and Network elements, along with the Service based interface Nchf. Even though in Charging Technical Specifications, 3GPP is not considering any UOM other than Volume, Time and Event, it is upto the Telcos to extend it further, which they already got a REST based interface from 3GPP.


Another problem is that these verticals can not add additional stacks (e.g Diameter, CAP, RADIUS etc.) to their existing systems, just because some telco wants them to offer ChaaS. On the contrary, Telcos should make sure that they have REST based Open APIs available in their Charging Systems, which can simply be consumed by their(Verticals) systems. This APIs should not only be limited to simple Balance Management, but should actually be capable of Rating, Charging, Usage/Balance update as well. So, a lot work needs to be done to expose the right amount of APIs, which should be so defined and open in nature that they can cater to most (if not all) of the Vertical industry charging use cases.


4. Non-Cloud Native

Since ChaaS itself is a service and most likely it would work in a revenue sharing business model(B2B2C), hence the CAPex and OPex should be minimized, wherever possible. One substantially great way is to have Charging on Cloud. This not only helps in reducing the initial CAPex, but also meet the sudden demand in case of a load spike. Additionally, they can offer subscription based auto-subscribed Charging Services, where any Industry vendor(Uber, DHL etc.) can go on a portal and subscribe for a Charging service instantly; even though it is the last stage of ChaaS, but it is only possible if Charging is actually happening on cloud, to meet the real-time traffic demand. But there are many hurdles, which limits Telcos to put their Charging on Cloud.

No matter how much concerns or fear is their, but Cloud is the only way forward for Telcos. This is the only way, where CAPex first becomes OPex and then OPex reduces significantly, by automation and on demand infra setup. I am well assured that telco vendors are working hard to make their BSS (Billing, Charging)  systems cloud native, but their pace is slow and the reason for that is not their ability, but the market demand itself. Even today, operators are having concerns about the Security, Integrity and Authenticity of their Charging system. Since they have to deal with local laws and most of the times, it doesn't allows them to put their system on cloud and even if it does, they just don't want to be the first one to do so, as it is a lot of risk.

While, here vendors should work with more pace for making their systems truly Cloud-Native (and not just Cloud-Ready), regulatory bodies should also need to redefine the guidelines on how they can be optimized to have a balance between security and CAPex/OPex reduction. At the same time Cloud providers should also build more robust and convincing security mechanisms and should start their campaign for the same, so that Telco on Cloud can have their first couple of steps.


5. Limited Scalability

Even though Scalability is actually a Non-Functional attribute of any system, but in case of XaaS, it becomes a functoional one, because any offered service is described by its capability to scale automatically, quickly and reliably. In my opinion, Charging system will automatically becomes real-time Scalable, if its Cloud native. The main pain is to make the Database also Cloud native and Scalable, which is still lagging behind from rest of the NFs. Database scalabilty and choices are another topic itself, so I am limiting this to the Charging Systems only.


Conclusion


"In 5G CSPs will have a RISK equals (if not Greater than) of Verticals than they are having of OTTs today! "


It is important for Telcos to move towards 5G with their new product offerings, but it is also the time, when Telcos should start thinking about the possibilities to monetize their existing systems and not just with OTTs, but with the other Verticals. Telcos had few B2B2C use cases deployed in partnership with OTTs, but now is the time to think beyond IT and, towards the verticals, which have never been think of and incept the B2B2X. ChaaS should be the first step towards the new revenue generation, even before start deploying the 5G. It is acceptable that there are challenges to achieve it and current charging systems will be needed a 180-Degree shift, but this is the only way forward. While Charging on new Units of Measure will be a key aspect, it is important to include more than one dimension for charging along with features like Realtime Taxation and Invoicing, to fully align ChaaS with the vertical industries. The best approach is to start with one use case at a time and by using co-creation methodology, start extending the landscape.


No comments:

Post a Comment

Diversity, Dilemma and the Need

Diversity is always, one of the most talked about topic in modern industry, especially in the IT industry. Despite being discussed, in almos...