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 almost every corporate event and function, Diversity is still not up to the mark, in most of the organizations. I will try to outline the real meaning of Diversity; it's need to the organization, including the top roadblocks in implementing the key measures to increase diversity and what can be the possible solutions to overcome those.

What is Diversity?

We certainly don't need a definition from a book for this word, as it is very subjective to the use case. In corporate world, Diversity should not only be limited to that people coming form different gender or religion/segment, nationality, but it is more about how to get different ideas, perspectives. In other words,

"Diversity is the enablement to get diverse ideas, to fix the common problems and improve continuously, by welcoming the new ways of working and respecting individuals."

Clearly diversity is not only about getting a few female employees in the team, or celebrating different religious festivals at workplace, it's about value sharing and respecting each other. Diversity goes beyond the target gender, religion and nationality ratio.

Why Diversity?

Every company is there to sell something. In many of the cases, the customers are individuals, coming from varied and diverse backgrounds, socially, economically, regionally and even comes from different genders. Hence, it requires a great amount of study and effort to understand individuals behaviours, requirements and feedbacks. Surveys can not be of help for everyone.

Consider a company is trying to launch a community platform for millennials, globally. The company needs to include many feature, considering various genders, nationality, religions, economy, literacy level etc. Still it will not get up to the mark for most of the users. The reason is simple, you can't just include everyone's view, just by googling or following some texts on some books, which were written decades ago.

How about we do it this way, that we include the diverse people in the company itself, who are coming from various religions, gender, nationality, economy and even literacy. If company include their ideas and views into the product, there are high chances that the platform will be liked more.

Roadblocks

Diversity as Compliance

The main showstopper is considering Diversity as a Responsibility.

"Diversity is not a Responsibility, but a Pathway to Success!"

Many organizations thinks diversity as one of the lose end and they just want to do it for the sake of compliance. However, by doing so, they remain very monotonous in their decision making and same people continue to make decisions and in many cases, doing the same mistakes again and again.

Culture and Mindset

Second problem is a inherited from the first one. Non-diverse groups, often stuck into a mono-mind set, where people sense a phobia, from moving away from the current ways of working. These people consider changing the culture as a risk, hence stuck in their frog-well for ever. Many people just consider themselves superior than others (at gender, class, socio-economic level) and hence feel disrespected working together the non-alike minded people, coming form other divers background.

Key Stake-Holders

In many cases, people at key positions are usually male and from good economies. For them numbers are everything when it comes to fill a key position at CXO level. Apart from People Officers (CHRO), most of the CX levels are suffering form Male dominance. In many cases, same group of people are just changing chairs in various companies, to become CXOs. In most of the cases, companies see diverse people at key position as a risk and often not willing to take that in order to secure the stakeholders wealth.

"It's a loop of Stake-holders, Wealth, Risk and Minimalist, when it comes to appointing a diverse person on a Key position"

 

In most of the cases, companies just fill entry level positions with few diverse workers, e.g Women, while lateral hiring does not consider any diversity boundaries and often dominated by a monopole.

What to do?

"When it comes to diversity, everyone talks about it, but hardly act what is necessary."

 

 Take the next Step: Inclusivity

Diversity is not done, until you get the ideas from most of the people. It's about getting and letting people involved in decision making and encourage/empower them to put forward their ideas, without a sense of fear. 

"Recruiting diverse people is one thing, but getting them to work collaboratively is the key."

Take the right steps, to ensure no one feel embarrassed, due to their failure and non-reciprocated actions, for such failures.

Create an Open Culture

Open culture doesn't end by putting cosmetic auto emails, with women shadows in background, but it starts from there. Create policies, where people are encouraged to put their own ideas forwards, rather than giving them choice to pick one form your own 5 ideas. Take their views into the account, include them in the decision making and create a healthy environment, which supports challenging the status quo and welcome new ideas.

Zero Tolerance to Racism and POSH

People feel secure, when they are protected by written laws, which are followed, when in need. Create fair examples and take a zero tolerance towards the critical issues like Racism and crime against different gender people, especially females and LGBTQA+ members. Create events, which burst the fun out of LGBTQA+ and the phobia associated with it.

"Do whatever it takes to feel people secure, so that they can focus on their job and ideas, rather than worrying about what other people thinking about them."

Diversity has been and will always be one of the key pillar of organizational growth. Diversity impacts more to the bigger orgs, than it does to the SMEs. The larger orgnizations, works on larger scales, and hence covering more diverse people, as compared to the SMEs. Hence their requirement for a sound diversity and inclusion is important to ensure they are addressing most of the target segment.

Getting the Hardest Part of 5G

What is the hardest part for CSPs, while moving towards #5G;

Network Densification

New Spectrum

Network Planning,

Converging the legacy

Digital Transformation

Moving to Cloud???

Indeed these all are big rocks in the road towards 5G, but.... Despite being all these problems, CSPs are moving rapidly towards 5G, few have crossed 1Mn mark, while many are seeing 5G adaptation faster than that of it's predecessors (4G, 3G etc.)



In my opinion, the biggest problem CSPs have today is "Being not able to find newer ways of Monetisation!" In 5G it becomes more critical business element! In other words, "Legacy Charging Methodology & Lack of Dynamic Monetisation Models is putting CSPs at risk of uncertainty of Return on Investment they are doing for 5G!"

Many top Leaders of early 5G launchers have even confessed that they are still using traditional model of Bundle base or Volume/Time based Charging for their 5G Services, with a few $$ up than 4G.

It is evident that telcos are unable to find better ways to monetize the 5G services.

While CSPs are fighting their race of getting ahead in next gen network deployment & expansion, they need expert help and thought leadership, who can partner with them to find new innovative Charging & monetisation model, such as;

• Charging only when required Vs Always
• Finding new Unit of Measures Vs traditional
• Seconds, Minutes, KB, MB
• Charging-as-a-Service Vs Charging-System
• Precise-marketing over Mass-marketing
• Subscriber-Persona over Profiling
• Relatime Promotions Vs Near-Realtime
• Close-Loop-Feedback Vs Open-Loop
• B2B2X and B2X Vs B2C 

:

:

:

There are a number of such thought processes and not all of them are suitable for each CSP and different options will work for different CSPs. It depends on many factors, such as; Geography, Target Segment, Network Presence, Services Offered etc.



Hence, what also needed is a quick turnaround time, in decision making and implementation of changes. Most of these changes comes from a closed loop feedback mechanism, but many needs to be adapted as part of culture.

Agree?

DevOps: A Value Driver or a Deception

Ever since the inception of Web Development, the new and improved SDLC frameworks has been introduced Waterfall, Agile/ SAFe etc. And as Mobile internet becomes cheaper, Faster and convenient the App Development has taken the rise, which triggered the CI-CD (Continuous Integration & Continuous Delivery), which in turn gave rise to DevOPs. Before going into the Pros and Cons of DevOps, let us first understand what exactly DevOps means, how it functions, why it has been adopted by IT and Telco industries.

What is DevOps?

DevOps is an acronym for Development-Operations, where it is deemed that Product-Engineering (Development) & Operations teams should work collectively towards a common goal, by removing the iteration of enhancement-logging, internal-Trouble-Ticket and Bug-fixing flow to reduce the overall time from the Requirements Raised till it get Delivered and deployed into the Production-environment.


To further improve the DevOps methodology, a new type of Tech-resources have been introduced; "The DevOps Team".

"A DevOps team comprises of Tech-resources who are capable of understanding the Business Requirements, Operation Challenges and also the Product Development. The main goal of DevOPs is to reduce the overall time between the Requirement Raised by Customer & the  Deployment into the Production."

DevOps Formation

Hence DevOps team essentially a blend of Business-Analyst, Operation-Manager/Engineer and Product-Engineer and a resource is considered to be the best fit for DevOps, if he/she is having each of these competencies available. That is the reason now a days, market is thriving for DevOps Engineers, DevOps Managers etc.

How DevOps Work?

DevOps team usually works closely with Customer/Client. They help the customer for ease of Operations, by delivering traditional Operation & Managed Services tasks, along with taking the new requirements or enhancements/ bug-fixes and then same team works to Develop, Test, Deploy and Deliver the new enhancements in form of a Configuration Change, new Build or release inside th production environment.

CI-CD Operations

Hence DevOps essentially backed with an Agile Software Development model along with CI-CD delivery. By adopting Agile, it can be ensured to prioritize the most critical and immediate requirements and then developing the same at a faster pace. CI-CD delivery model ensures that time taken between "Code Written by Developer in Development Environment" & "Deployed inside the Production Environment" should be as low as possible. For CI-CD, a delivery pipeline approach is adopted, where a logical build delivery pipeline is maintained between the Vendor's Build/Release Repository and the Client's Build Repository. However, this pipeline is further extended at both the ends. At Vendor's end the Build-Repository is connected with Development to Test to Performance Setup and at Client's end it is connected to Test, Staging, Pre-production and Finally to Production Environment.

It is also important to make sure that the Test environment at both  the end (Vendor & Client) should have automated test cases for regression, functional & performance, so that the release time can be minimized.

Why DevOps?

From the above sections, it is almost clear that main goal of DevOps is to minimize the Delivery time. To be more specific;

"DevOps is used by the industry to minimize the time taken in process of Requirement raised by the customer to Writing a Code to Test to Deliver to Deploy!"

The other objective of DevOps & CI-CD is from the business perspective. Consider a scenario, where an operator releases an RFP for some immediate and some futuristic requirements. Now in a traditional SDLC/Waterfall model, the Vendors submit their proposal considering it a one time delivery and try to cover everything. It is very likely that vendors will not be having every functionality Out-of-the-Box available at that time and hence will consider the delivery timeline accordingly. For this case, let us consider they propose a timeline of 9 months. Hence operator now need to wait for another 9 months to get the requirements delivered and use them. Even if the most immediate requirements are available Out-of-the-Box in vendor's solution from day one. On the other hand vendor will invest a huge amount in product/ solution to develop the delta requirements and will not be having any cash-flow until the project starts. The another problem with this approach is that when Operator releases an RFP, they try to predict the futuristic requirements, however in many cases the  actual requirements may change at the time of actual project delivery and at that time, Operator will suffer.


Now, in an Agile based DevOps delivery model, Vendor can work with Operator/Client to prioritize all requirements, in order of urgency and then can propose a project plan where customer can Go-live with the bare minimum immediate functionality within 2 months or less and by using a DevOps based CI-CD driven project plan, customer can have incremental delivery of new features after end of every sprint. If vendor can work smartly on this, they can show that all RFP requirements will be delivered within the same 9 months timeline, but not as one go, but on incremental basis and customer can get more and more benefits after each delivery. This is a win-win situation for both; Vendor and Operator. The Operator will be having their most painful area addressed immediately and Vendor will be having a Cash flow running from the Day-One of the Project and can use the project revenue for product development itself. In this model it is also possible to cater the change in requirements during the project delivery itself. After each sprint delivery, customer can come up with a more urgent requirements or they may ask to re-prioritize the whole feature-list. Customer may even decide that certain functionalities, which are part of future planning, are no longer required. This provides a great flexibility and maximize the return-on-investment done by Vendor and Operator.

Where to Apply DevOps?

"CI-CD and Agile development are the  essential ingredients for successful DevOps model. Hence, when we talk about DevOps, we obviously mean DevOps + CI/CD + Agile."

DevOps is most suited for the Solutions, which are close to the User, like User Interface, Engagement Framework, WebSelfCare, Mobile-Apps etc. These are known as IT solutions in Telco world. Since most of requirements in this span can be broken down into smaller features easily and hence can be delivered independently and incrementally, it makes DevOps a perfect fit for IT framework. For example, an operator wants to have a mobile app where user can View his profile, Change Plan, purchase a device, a SIM card and register online with Payment options as Credit-Card, Debit-card, Netbanking, Mobile-wallet and by Cash.
In a traditional Waterfall-SDLC, the delivering all of these requirements in one shot, will cost more than 6 months, easily. But if vendor follows the DevOps approach, they can deliver all the requirements incrementally, by prioritizing them, as per clients requirements.

Here these many requirements can be broken down into smaller features and then prioritized. Further all the requirements can be delivered independently on incremental basis as below:
1. A Mobile App for User's Account Summary
2. Option to change Plan
3. Option to Purchase new SIM with Payment only by Cash
4. Integration with one Payment gateway with Payment Method only by Netbanking
5. Listing of Mobile-Devices from One Vendor only
6. Listing of Mobile-Devices from 2 more vendors
7. Payment Method by Debi/Credit Card
8. Integration with logistic partner for Home Delivery
9. Payment Method by Mobile Wallet
10. Integration with more Payment Gateways
11. Integration with Market-Places (Amazon, Flipkart, Walmart etc.)

If we look closely, both Vendor and Operator are getting great benefit out of it. Vendor is having enough cash flow to use the same for Product development and Operator is having their most critical requirement addressed on the very first delivery, while ensuring a timely delivery of all requirements at a predefined sprint interval.

Where not to Apply DevOps?

Even though DevOps is a great industry practice, it does not suite well for every Telco Solution. Consider a case of a Network Element like PGW, where an Operator wants to have a support of Wi-Fi to LTE handover. Even this requirement can be broken down into multiple smaller features (or user-stories) and can be delivered to operator, but those can not be used as a feature in a production environment, since complete Handover support between Wi-Fi and LTE (and Vice-versa) will take at least 3-4 months of development time and minimum 1 Month of Testing and Integration/IOT efforts. Hence using a DevOps based CI-CD model will actually not give any benefit to the Operator, since it is unusable until the complete support.

To clarify more, let us take another example of PCRF requirement. An operator requested to have a support of P-CSCF restoration inside PCRF. Now to support it a usual Development effort is minimum 1 month and then 15-20 days of Testing, Integration and IOT. In short it can not be delivered and used in production environment before 2 Months from the date  of requirement raised.


Using DevOps for a solution segment, which demands a delivery cycle of more than 3 weeks, is not suitable and actually costs more to Vendors, since the cash flow is driven by delivery time in DevOps. For example, if a feature delivery happens after 3 months, vendor will have a cash crunch, for those 3 months and can end up hanging between Agile and Waterfall.

The another consideration is 'How critical the segment is?'. Upgrading a MobileApp or a SelfCare Portal is easy and takes very less time to complete and also it is not a business critical segment. If by some mean, the MobileApp is down for sometime or some features are not available, customer can still use the other services of the network. But if a critical network segment (like PCRF, OCS, PGW, Node-B, Transmission-Link etc.), is down during the upgrade, it is a direct loss of revenue, service and user experience to the Operator. Hence, frequently upgrading such critical elements is to be avoided.

Conclusion:

"DevOps framework looks very compelling to adopt, however just like all other methodology DevOps is also not meant for everything and if not adopted for perfect solution, it does more harm than that of Waterfall."

It is crystal clear that DevOps is a great framework to adapt, but for the right segment, which is IT in case of Telco.

" 'One size CI-CD and DevOps is a perfect fit for all segments', is not only an immature statement, but also a Suicidal decision for both Telcos and Vendors!"

Based on my market analysis and Telco research, I have come up with below diagram.

Delivery Timelines for Different Network Segments

This gives a perfect view what should be a typical timeline of an enhancement/feature delivery for different network segments. If we look closely, it is evident that the solutions, which are closer to user, have shortest delivery timelines and as we move away from the user interface and closer to Network Elements the delivery timeline increases respectively.

Network Slicing in 5G Why What and How

Mobile network has ever been evolving, ever since its inception. However the evolution rate has also been significantly accelerated after the introduction of Mobile Internet. We have witnessed a staggering rise in Mobile data consumption over the last couple of decades and its still growing at an unprecedented pace.
It's well known that primary  objective of Mobile network was to provide affordable communication services for mass market and slowly it has entered to Enterprise market as well, but main focus and earning anchor still remains the individual mobile users only. With the introduction of high speed internet offered in 4th generation mobile network (LTE), Operators and Telco vendors started looking up for new revenue resources from the Horizontal market segments, to recover the network transformation cost, such as OTT, Entertainment, Information, News, Sports etc. This gave the rise for the ICT industry, which has now been matured significantly.

Industry Journey So Far

Now the 5G is in its early phase, it become important, "How Operators will get the Return on investment, they will be doing on this huge network transformation!"

It is obvious that only by catering to the Retail market and traditional IoT services, the revenue realization will not happen and CSPs will continue to struggle for getting extra bucks for their network infrastructure cost.

"CSPs need to think beyond the Horizon of adjacent market and target the new Vertical segments, such as Healthcare, Industry Automation(IIoT), Smart Cities, V2X etc."

New Target Segment for CSPs

However, each of the Vertical industry has its own use cases, network characteristic requirements and SLAs, which are very different not only from the current Telco use cases, but also from that of other verticals as well. For example: For an Automotive Production plant, the Bandwidth requirements are very tiny and they don't require extreme Mobility, but their main requirement is to connect Millions of devices per Square Km. and a very long (~10years) UE battery life. In another example of V2X or Connected Car segment, the main requirement is the extreme connectivity over the longer distance and superior mobility handover, typically between the heterogeneous Radio-Access-Networks and they also don't require a very high data rates. To complex things a bit more, let us introduce another use case of Remote Healthcare, where the requirement is not a great mobility experience, but a good bandwidth (100Mbps which is available in LTE as well) and a guaranteed Sub-Millisecond end-to-end latency.

Based on various industry use cases and SLA requirements, 3GPP has categorized the 5G use cases into 3 segments, namely:
eMBB: Enhanced Mobile Broadband (Gigabit Mobile Internet)
mMTC: Massive Machine Type Communication (~1Mn Connections per Sq-Km and 10 Years UE battery life)
URLLC: Ultra Reliable & Low Latency Communication (<10ms Latency, Tactile Internet, Immersive Experience)

If you need more detailed view on each of these segments, please checkout my earlier article here, since current write-up will be more focused on Network Slicing.

From above, its evident that a single network could simply not deliver everything out of it and we need to have a different approach and thought process to cater these requirements, the "Use case driven methodology"!

"5G deployments are driven by Use cases and not the other way around, unlike its predecessors!"

5G Three-Dimensional Use Cases and Requirements

What it means is that CSP should not deploy the 5G network first and then define the use case, it is capable to serve, but they should first define the use case and the SLAs, network-Characteristics requirements etc. and then design a specific network around it. But they simply can't have different networks for different use cases or can they? Actually they can! They don't need to have different physical networks for different use cases, instead they will be having logically separated networks, based on different use cases. This is where the concept of Network Slicing becomes not only relevant, but also necessary to implement.

"Term Network-Slicing essentially means set of logical Network-Functions grouped together to deliver specific service (or set of services), such that for the consumers it looks like a complete network!"

Network Slicing can be Horizontal and Vertical, based on the Service-Delivery requirements. For example: Only Access Network can be designed as a Slice to deliver only Radio Connectivity for a specific segment or a complete end-to-end Slice, containing Access and Core-Network NFs, for a Communication-Service.

Horizontal Network Slicing

Vertical Network Slicing

So, how does Network Slicing work? Well Network-Slicing is not a new concept, we have been unknowingly doing it for more than a decade, but in 5G, specially when talking about Vertical segment use cases, Network-Slicing is to be used at its full potential. Till 4G, we used to slice the Core network by use of APN (Access Point Name) and Location (MCC, MNC, LAC etc.). Here, different Core Network-Elements (SGSN, SGW, PGW, GGSN etc.) used to serve for different APNs, typically different for Voice and Data; and that's it!

However, in 5G Network-Slicing is more matured and essential Tech-tool, which allows CSPs to use each of their Network-Functions (Access and Core) efficiently, by diversifying different Slices. The idea of Network slicing is to Dynamically define the Slices and automatic creation and deletion of Network-Slices, driven by the service-requirements to deliver the efficiency & SLAs, which Service demands and optimize the CAPex/OPex at the same time.

Network Slicing Management

Above figure shows, how a Network-Slicing-Management framework looks like. As already explained above, 5G is a Use case driven technology, hence, the flow of Network-Slicing is also in the same line and it works from Top to bottom, i.e Use case triggers the network-requirements and network creates a network-slice (or use existing one) and after the usage is ended the network deletes the slice to minimize the resource utilization.


Let us now understand in detail, how exactly the  network slicing works! When a new Communication/Network Service is triggered, the CSMF checks, if it has a Service-Instance available, which matches the characteristics of the  requested service, if yes, it simply align the Service with that Service-Instance. If that is not the case, CSMF instantiates a new Service-Instance, which maps to an available Network-Slices. In case the CSMF could not find a suitable Network-Slice, it requests the NSMF to instantiate a new Network-Slice for the given Service-Instance Characteristics. CSMF will then creates an NST (network-Slice-Template), which contains the network-characteristics & NF requirements and maps the same with available Sub-Network-Instances to create a new Network-Slice and respond back to the CSMF with the new Slice information. In case CSMF could not find the available Sub-Network-Instances, matching with the requirements of NST, it then requests to NSSMF to create a suitable Sub-Network-Instance for the given NST and finally NSSMF may create a new Sub-Network-Instance from the available set of NFs or it may instantiate one or more NFs from the available Resources. This is a typical flow for the Network Slice Life-cycle Management.


Here it is important that based on the operator defined configuration, Management Functions (CSMF, NSMF, NSSMF) can decide to delete or retain a particular network slice after the delivering the service. For instance, a Radio-Access-Network Slice for a Football ground can be dynamically created only for 3 hours match time and after that it can be deleted and the available resources, NFs can be aligned to some other Network-Slice.

Key Take away:

• Network Slicing is a methodology to design dynamic logical networks, derived from the service requirements
• A fine-grained network resource Optimization
• Network Slicing is not MVNO, but MVNO can be a Network-Slice example
• Network Slices can be Horizontal and Vertical
• One Network-Slice can serve more than one Service
• One Network-Function can be included in more than one Network-Slices

5G: Its now or Never for Vendors

Despite all the criticism and hype, 5G is finally here. Leading CSPs in North America & South Korea has already launched their services in multiple cities and many other are planning world wide. Even though the ROI and monetization is not concrete enough to realize, Telcos are being pushed to go for a try. In next 2 years, we could see significant large scale deployments of 5G across the globe.

Many Telco vendors are still holding their cards and due to the uncertainty of business outcomes and immediate revenue realization, they are in a dilemma whether they should go for the 5G ready network elements and solutions or not. Since 5G is a major technological and architectural shift from its predecessor (LTE), it demands a huge investment and a significant time to build up the  next gen mobile network solutions, it becomes important for Telco vendors to realize the ROI and the timeline, by when they could expect the large scale deployments.

Although, many of the leading CSPs like Verizon, AT&T, KT, CM etc. are deploying their next gen Radio solutions in NSA (EPC Assisted) mode, the speed of deployment is slower. Currently, they (CSPs) are focusing mainly on eMBB(Gigabit Mobile Internet) as one of the use case for delivering their  5G services and hence the target segment is mainly retail, which may not seems promising to many new-gen Telco-Vendors, especially those, who are mainly into the OSS and BSS solutions.

Based on the recent analysis done by TMF, the adoption rate will rise 2X for 5G over the next half decade(2020-2025). This clearly shows, why this is the right time for Telco vendors to start working on their 5G ready solutions, not only the Network-Equipment part, but also the BSS and OSS solutions.

" CSPs will need the monetization capabilities to realize more revenue form the services provided by their network-equipment and infrastructure and hence a robust, reliable and innovative OSS/BSS solutions will be required to minimize the cost and earn more revenue form their network solutions and services.
"

Many Telco giant vendors like Ericsson, Nokia and Cisco are mainly focusing on the 5G-Radio and 5G-Core Network Functions and solutions, while there are some new players like Affirmed Networks who are working on new 5G solutions like Network Slicing. Still there are very few who are actually working on the next gen BSS/OSS platform, which will be the key to monetize the overall 5G investment. Especially European Telcos like Orange, DT etc. are more interested in next-gen ODA (Open Digital Architecture) over the 5G network elements and this gives a chance for innovative BSS/OSS vendors to start now building the ODA based BSS/OSS solutions, which can earn them early business with leading CSPs, not only in Europe, but later in other parts of the world as well.

"
No matter, how desperate the CSPs are to get their 5G-NR deployed, but they will not be able to monetize it if they lack of the innovative monetization solutions.
"

Conclusion:
Telco-Vendor giants are mainly focusing on the New-Radio(gNB) and the User-Plan 5G-Core equipments(UPF), this gives an opportunity to the OSS/BSS vendors to start building their innovative monetization solutions and cloud native Digital-Platforms, in order to earn early 5G business, which will not only help them to realize the early revenue, but CSPs will also get more than they are investing in 5G transformation. And the key to earn early 5G business is to start now, as currently CSPs are also focusing on High capacity Radio and Packet core, but at a later stage(by end to 2019), they will need the  next-gen OSS/BSS, which will be the key for new players(telco-vendors)

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.

2 Speed Software a Real Demand in 5G

5G is not just a next generation of Mobile Communication, but it is complete network transformation and the first step toward influencing the (Non-IT) Verticals.
5G is more relevant and different than previous generation (4G, 3G), when we talk about the use cases, its targeting. For more  details about the use case differentiation & categorization, please refer to my previous blog  https://goftelecome.blogspot.com/2018/10/5g-myths-facts-use-cases-solutions.html


5G is designed to deal with 3 very different and unique use (namely; eMBB, mMTC, URLLC) cases and it is supposed to handle all 3 dimensions so well, that it logically isolates the impact  on one another. While eMBB requires HUGE-DATA-RATES (~10Gbps), mMTC demands a DENSE-CONNECTIVITY(1Mn/Sq.Km) and a LONGER-UE-BATTERY-LIFE(~10Years) and on the other hand URLLC demands an ULTRA-RELIABLE-NETWORK with extremely LOW-LATENCY. All the use cases of 5G like 4K-Videos Streaming, Connected Cars & Logistics, AR/VR, Tactile Internet, Industry-Automation, Remote Healthcare etc. revolves around these 3 network characteristics.

Clearly a single network is just not suffice to cater all 3 requirements. But still 5G promises to offer each of these. And to make this happen, 5G leverages the 2 technologies; Network-Slicing & Mobile-Edge-Computing.

Network-Slicing is a set of Network-Functions grouped together to meet a certain network and service characteristics. It is possible to use a Network-Slice for more than one service. However, unlike many people think about it, network slicing is not a new concept, but the procedures to implement it has been refined significantly in 5G (3GPP-R15). Up until LTE, Network Slices are usually created only for the User-Plane Core network, basis on APN classification. But in 5G, Network Slicing is much more complex and covers not only the User-Plate Functions (UPF), but also the Control-Plane Functions (AMF, SMF, PCF, CHF, etc.) and the Access-Network (RAN, Fixed) as well. To manage and simplify this implementation 3GPP introduces few new NFs in Control Plane (Service-Based-Architecture) such as, NSSF, NRF and NEF. By analyzing the appropriate use-cases, a complex network topology and slices can be created dynamically by utilizing these new NFs.


Mobile-Edge-Computing (MEC) is again a relatively young concept, but not entirely new one. However the implementation of MEC in 5G is not just network in a box, but it is more subjective to the use-case, service-demand and cost. MEC solutions are not cost effective and increases the cost of implementation of a large scale network, hence it is important to analyze all the factors, before choosing the right topology blueprint.

"It is always said in 5G Centralized as much as you can and Distribute only what you must!"

MEC in 5G is actually, finding the right edge. It is the  right balance between the Service Demand Characteristics and the Cost involved. Below picture, gives a brief about how to decide, which compute technology should an operator adapt to, based on the latency and network setup time requirements.


If we look closely, we could say that in case of an Edge-Compute network, although the latency requirements are very stringent, but the number of connections are relatively less, hence it does not require a high performance Network-Function, but on the contrary it requires a very light-weight one which can minimize the HW cost and power requirements. But on the contrary, in case of a Centralized-Compute scenario, the requirement is a very high performance oriented NFs to cater Millions of connections and Transactions. In this (centralized) case, implementation cost can be higher, but performance should not be compromised.

Clearly a single Software framework can not cater to both of these requirements perfectly and this is the reason, why 2 Speed Software Architecture is required.

"One architecture is designed to be very light-weight, offering a faster response time while the second one is designed to be more performance oriented with capability to serve Millions of Connection & Transaction, by utilizing a bigger infrastructure"


I also  have some insight, on how vendors can achieve it. For instance, PCF can have First Architecture as a container based designed with collocated SPR (Database) and capability to be co-hosted on a common infrastructure along with other NFs  (AMF, SMF etc.). Many of the non-required modules, such as non-required Protocol-Stacks, Notification Channels etc. can be removed from the main code, to minimize the size of deployment and Response time. While in case of a performance oriented deployment, Internal modules of PCF (Access-Layer, Policy-Engine, Notification-Service, Policy-Catalogue etc.) can be distributed among multiple set of infrastructure separately to support Scalability of individual modules. Hence the Architecture of Software (of PCF) should also be engineered such that all these modules are separately deployed and scaled.