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.

Road to 5G Policy and Charging Framework

I have been doing my study and research over past couple of quarters on early 5G deployments and evolution stages from EPC to Non-StandAlone 5G to StandAlone 5G-Core and then it triggered me what about PCC? How the Policy & Charging framework will have its journey from current state of EPC to the final Stand-Alone 5GC. I will cover in this article about what could be the possible incremental steps for PCC evolution during each of these stages and Vendors can ensure maximum ROI, while they deliver th each of these incremental stages.

PCC: 4G Vs 5G

It's no news that 5G is a big technology shift, in both terms; Functional and Non-Functional aspects. And PCC being an integral and one of the most important part of 5G Core, is also to be evolved into both aspects. So, I will put down both the aspects one by one and let us start with Non-Functional requirements first.

Non-Functional:

When it comes to 5G, it is evident that every NF(Network Function) has to be:
1. Virtual
2. Containerized
3. Orchestrated
4. Web-Scaled
5. 2 Speed Architecture


We will discuss each of the above 5 main building blocks of 5G NF in details.

1. Virtual:
I believe most of the vendors are already having this in place in some way or another, as an approach to reduce hardware dependency. But in many cases, they still require a specific set of hardware. Making an NF truly virtual, means it should be Hardware, Platform & Infra agnostic. Having said that it should be possible for operator to be in a position to use any COTS Physical Hardware, Any Hypervisor and even other infra options like, On-Premises-Virtualized, Public or Private Cloud and even Hybrid infrastructure. An NF should never be deemed as Virtual, until it has a certain dependency on a specific set of hardware. Vendors should guarantee that the functional and performance outcomes of Software (PCF & CHF) are identical irrespective of the underlying infrastructure type.

"This is the time BSS vendors should more focus on Software rather than becoming the Hardware specialists and remove their dependency on specific set of hardware!"

2. Containerized:
This is the next stage of NF evolution. Being Virtual is the essential part of 5GC, but it is not the ultimate goal. Containerization is not only a necessary requirement, but it also an unavoidable evolution step towards making the NFs truly agnostic and predictable. Containerization helps Vendors and Telcos to have a light weight Software package, which is independent of the underlying OS and infrastructure. Even today, most of the Telco vendors are having their BSS Softwares containerized, but they are struggling with the Database, especially who have been using RDBMS. RDBMS are fundamentally not designed to be containerized and hence vendors should take this evident problem as a serious note, that this is the time to shift to a Cloud-Native, Containerized Database; the choice is up to them, but sooner or later they have to shift; the sooner is better though.
By adopting Containerization, the NFs becomes truly virtual and agnostic. Docker is a classical Tool-kit for containerization. Being an open source Tool, it helps the vendors and telcos to bring down the CAPex with a wide community support and evolution guarantee.

3. Orchestrated:
Orchestration is the intermediate stage between Containerized/Virtual NFs and Web-Scaled architecture. Without being an end-to-end Orchestration, it becomes very difficult (if not impossible) to manage the overall NF infrastructure. Think about it this way, even if you have a containerized or virtual solution deployed, it becomes a tedious task to manage the Fault detection, when we have 100s of NF container deployed; Which NF is talking to which and how, at Which step the fault happened, Which NF logs, should we look for are few of many operation issues, which will not be addressed, until the robust Orchestration is in place. Additionally, Vendors should also make it possible to use Persistent Queue mechanism to provide high fault-tolerance and business-continuity. Centralized Logging, One-Touch Monitoring, Persistent Queue Management, Stateless-NFs are the main part, which needs to be taken care, while building an orchestration for 5G-NFs.


4. Web-Scaled:
The unpredictable load demand in 5G, will require an On-Demand Scalable NFs. However, the criteria for Scaling should not be common for every NF. For instance, PCF and CHF load is primarily based on TPS (Transaction Per Second) & No. of Concurrent Sessions, but for NFs like UPF, it is based on throughput, for Billing it may be no. of Invoice per second, and so on. So, the criteria for Auto-Scaling and Auto-Healing should be subjective to each NF-Type. In today's scenarios, most of the Web-Scaled Solutions are designed for Web-Applications and those should be modified (by Vendors) to comply with  the Telco requirements. Web-Scaled PCC solution is the ultimate target for 5G Non-Functional Requirements. The scaling should not only be automated, but it should be fast enough  to ensure no service interruption.


5. 2 Speed Architecture:
This is my favourite  part! 2 Speed Software architecture, essentially talks about 2 very practical deployment scenarios; Centralized and Distributed. In 5G, on the basis of Service & Demand Characteristic, Operator will decide to deployment strategy. For instance in case of a URLLC Service, the best way to minimize the latency and connection setup time, is to put everything on edge and close to application (Edge), while in case of a highly densed metropolitan, it is better to go with a high capacity centralized solution. Clearly, it is very difficult to have a single Software stack to cater both the requirements with desired SLAs and KPIs. So, better is to design 2 different architectures; one for Edge deployments & one for Centralized deployment. While Edge solution should be light weight and self-contained to deliver the reduced Response Time for relatively less connections, the Centralized solution should be more performance oriented in terms of handling Millions of connections and TPS, while using a distributed Database.

So, this concludes to a step-by-step evolution of the 5G-NFs and where, Vendors should start from and the Vision they should look for!

Funtional: 

The Functional requirements are huge, when it comes to 5G-PCC, because its not only about meeting the 5G-Tech-Specs, but also seeing how to monetize them. However, I will be having a separate write-up for Monetization, I will keep this article limited to Tech-Spec specific Functional Requirements only.
Based on the Tech-Specs for Policy & Charging of 3GPP, below should be the incremental aproach for 5G functional compliance:

1. 5G NSA Compliance
2. HTTP/2 Adaptation
3. N7 Interface
4. New 5G PCCRule and QoS attributes incorporation
5. N15 Interface
6. N25 Interface
7. N23 Interface
8. N40 Interface
9. Other Interfaces

1. 5G NSA Compliance:
As we know the migration strategy for 5G, will involve sequential approach, it is evident that most of the players will start with Non-Stand-Alone 5G deployment, with primary focus on the Radio network for higher speed. Here operators will be using the existing EPC (or 4G-Core) connected to the 5G-RAN. While it seems to have no change in the existing PCC (PCRF and OCS) at the architecture level, but it has everything to do with the primary requirement of this phase, i.e "High Speed". PCRF to have the support for the Extended-Bit-Rate (Higher than 4Gbps), along with the RAT-Type Support for NR and Access-Network support for 5GS to have the 4G-core ready to serve the 5G-RAN. Additionally, New QCI values (other than 1 to 9), will also be needed support, along with new dimension of QCI classification, which is "Delay-Critical-GBR". These changes will be very quick to implement and a faster way to claim 5G ready PCF.

2. HTTP/2 Adaptation:
The first thing to start with the Functional compliance in 5G PCC, is to have HTTP/2 adaptation. However, this itself is a major technological shift, as these systems were running over Diameter for decades. Shifting directly to HTTP/2 will also have incemental steps involved.
2.a External HTTP/2 Adaptor:
At this stage the prime objective will be to integrate with 5GC (SMF) over HTTP/2. And best way to do it to build an adaptation layer,  probably an external application. This external layer will just accept the HTTP/2 based Policy requests and convert into Diameter (Gx, Gy) messages and legacy PCRF/ OCS systems can work as is. This will be the first step to accept the HTTP/2 based requests and respond them accordingly. However, this external layer should have the capability to map 5G-QoS parameters  (5QI, QoS-Rules, PCC-Rules, QoS-Flow-ID, SUPI, GPSI etc.) to 4G-EPC QoS parameters (QCI, EPS-Bearer-QoS, PCC-Rules, EPS-Bearer-ID, IMSI, MSISDN etc). These systems will typically be used to show case the demo/POC to claim that vendor has the 5G ready PCC in place.
2.b Merging of HTTP/2 Access Layer:
This stage will be more from the source code perspective, where an additional Stack (apart from Diameter) will need to be added into PCC applications (PCRF, OCS). This is just to merge this  external adaptation layer inside the main code and this will also require significant changes in overall internal workflow of PCC. Vendors should use generic methods to convert the HTTP/2 and Diameter messages into REST based flows or internal/proprietory message flows, which will be identical to the core engine of PCC (PCRF or OCS). This will not only ensure the better dual stack support of both Diameter and HTTP/2, but also make the product future proof, where any additional protocol adaptor can be added into Access-Layer at a later stage.


3. N7 Interface:
N7 interface implementation should be the first thing in vendors' checklist, when it comes to Stand-Alone 5GC. They can start by replacing or modifying their existing Gx  interface to N7. All the 4 main methods (Create, Update, Delete, Notify) of N7 reference point should be incorporated and supported as a replacement of their current stage of Gx Reference point (Initial, Update, terminate, Re-Authorize).

4. New 5G PCC-Rule & QoS Attributes:
This stage will be more form the actual compliance of Stand-Alone 5GC and will involve a significant change in source code. At this stage vendors' should decide, if they want to adapt a really micro-services based architecture to slice down the compliance parameters of all Session Management Policy Flows. This includes additional attributes inclusion in PCC-Rule definition, Separate configuration options for additional business Rules, like QoS-Rules, Network-Slicing Information and traffic-Steering based configuration options. This stage has a lot to include and can further be sliced down to multiple release cycles in order to bring down it to the incremental delivery. I will not list down all the parameters, but a detailed study of 3GPP tech-Specs, related to PCC will be required and same has to be incorporated. The level of compliance, however can be subjected to Vendors' choice or Business Availability/ Visibility, as complete compliance will take a very long time.

5. N15 Interface:
At this stage it will be better to understand more form Radio perspective and the main goal of this stage will be to position PCF as a converged Policy Controller. This PCF will be able to not only perform the Session & Access management Policies, but should also be able to make a Synchronization between these 2 types of Policies. 3GPP does not define any specific reference point interface between Access-Management PCF and Session-Management PCF, but to make a truly converged PCF, vendors' should either include both functionality in a single PCF or should have a synchronization mechanism between the 2 PCF. The later part is more preferable, as it allows to separately scale and configure the Access and Session Management Policies. However, Policy Configuration can be made centralized for both Access and Session Management, but I would still prefer to use separate PCF instances to deal with these policies separately. The reason is that both Access and Session Management demands a different set of response-time, functionality and scalability. Operator should be in a position to scale these two independently. Additionally, PCF at Access side in many cases may be deployed at Edge and for session management it will mostly be a centralized deployment. This is another reason for our 2 Speed Architecture, which we discussed above.


6. N25 Interface:
N25 interface is the one of the main requirement of 5GC, to make the Service-Based Architecture a reality. In 5GC, UDR is the single master database and it removes the dependency of multiple nodes (HSS, PCRF, OCS, IMS etc.) on multiple databases and also removes the synchronization issue between these many databases. The PCF should be in a position to use UDR as a main database for complete Subscriber, Subscription and Usage management and this is only possible after a complete compliance of N25 reference point interface along with the Nudr APIs.

7. N23 Interface:
N23 interface is between PCF and NWDAF (Network Data Analytics Function). This is one of the reason, PCF is termed as one of the most critical Network Function in 5GC and "The Most Intelligent Function" as well. NWDAF is having real-time network analytics information of all the NFs, at the system level and at the Network-Slice level as well. Hence NWDAF is having most valuable and critical information of the network, but it doesn't perform any action on its own. And the best part is that only PCF is having the access to this information (principally). This makes PCF very well informed about the real-time network status information, like Load, Stats, KPIs, Slice Utilization etc. PCF can use this information to perform change in policies; both Access-Management and Session-Management at subscriber level and at Slice level, to avoid any unwanted overload at any network function or at a network slice.

Industry Priority for Different 5G Network Functions

8. N40 Interface:
Charging will be the last touch point in 5G-PCC, as most of the systems will continue to support Diameter (Gy, Ro) for a very long time, during the transition phase from NSA to SA. But to make a truly Stand-Alone 5GC, it is important to migrate Gy to N40, just the way I explained for Gx to N7.

9. Other Interfaces:
The other interfaces are not part of immediate future requirements and most of the 5G use-cases will be complied with above approach only. However, still from the compliance perspective an incremental approach, below preference matrix can be taken forward:
N30 --> N5 --> N28

Conclusion:

The above methodology is based on the current Telco scenario and my market intelligence and there should be a scope of change in this. But I would still believe that this should be the path of 5G-PCC, as this involves lesser risk, early  5G Adaptation and a straight vision, while ensuring the immediate ROI.