5G charging requirements haven’t killed your online charging system (just yet)

The adoption of 5G networks brings with it significant change. For consumers the most notable change will likely be the higher download speeds, and for some scenarios the much-improved latency. However, for me, the much more interesting changes reside within the core network itself. 

The move from monolithic core network elements to the service-based architecture and virtualized network functions that can, at least in theory, be provisioned and deployed dynamically is where it gets really interesting. This move serves as the foundation for network slicing, and with it the possibility to tailor connectivity services to end users in a new way.  

With significant change to the core network, also comes significant change to the support systems built around it. Including the billing and charging systems that make up the backbone of a communications service provider’s (CSP) monetization infrastructure, which is what this post will focus on.

The charging stack, as defined by 3GPP, has evolved from the 4G era online charging system (OCS), and offline charging system (OFCS), to the new converged charging system (CCS). 

On the face of it, 3GPP has taken the building blocks of the OCS and OFCS, merged them into the same stack, added new network-facing APIs for charging and policy, and thus made it “convergent” (online and offline charging combined). Like the underlying 5G core network, the changes need to be more than skin deep. 

To fully unlock the potential of the service-based architecture, network slicing, and improved operations the charging stack also needs to shift from monolithic components to a more scalable architecture based on cloud-technologies. 

You’ll hear a string of buzzwords (slice aware, microservices, containerized applications, Kubernetes, self-healing, auto-scaling, DevOps, CI/CD), and this is the natural evolutionary path to take. Vendors in this space (DigitalRoute included) must walk it to align with evolving requirements. To monetize network services built on a stand-alone (SA) 5G core, there are many good reasons to sunset the legacy OCS, and usher in the era of converged charging (built on cloud-native technologies). 

But (yes, there is a but), adopting a new approach to charging is a major transformation project. And it is close to a universal truth that large BSS transformation projects are risky, prone to delays, budget overruns, and can be highly questionable in terms of ROI. 

In addition to the risk of a large transformation, you also have to consider:

A. The uncertainty many operators face about how they are going to monetize their 5G services and achieve ROI on the network investment – “is it really all that different than the existing 4G charging model?”

B. The fact that many CSPs are not yet at a point where they are able to adopt a cloud-native stack and operations throughout their suite of business support systems. 

A picture starts to emerge here, one that I think many CSPs should consider in order to leverage the significant investment already made in the 4G OCS when rolling out support for 5G services. 

An existing OCS may not be able to support everything you’d ultimately want from your future charging system, but it can still do quite a lot. Especially within the confines of 4G-era product offerings and pricing models. This can be leveraged for 5G connectivity as well.  

Let me show you how. 

Step 1 

The net-new component in the 5G charging stack is the charging function (CHF). The CHF is required to interoperate and communicate with the 5G SA core. It does so over two main APIs:  

Nchf API:

• Reference point N28: Integration between CHF and the policy function for spending limit control. 
• Reference point N40: Integration between the CHF and the SMF/SMSF for converged (online and offline) charging flows (event and session based).
  

 Nnrf API

• Interface for registering the CHF with the network, required to receive charging traffic. 

By adding the CHF capability in front of an existing OCS, DigitalRoute can bridge the domains and leverage the existing account balance management and rating functions of the OCS on top of a 5G SA core. 

Step 2 

On the heels of the new 5G SA core elements, the next major change to manage will be the introduction of network slicing. To enable charging for a dynamic network infrastructure, where a new instance (slice) can be created or decommissioned at any point in time, a slice-aware charging solution is required. While this is a big change, requiring a move to cloud-native components that can be spun-up and scaled on demand, it is still possible to do this through a slice-aware charging function front-ending a static OCS (given it has the right product catalog entries). 

Step 3 

To fully embrace network slicing, and managing an expected growth in charging traffic, CSPs will ultimately want to migrate to an end-to-end charging architecture (including RF and ABMF) based on cloud-native technologies that provide the required elasticity and operational requirements that come with a virtualized core network.  

The point here is that the move from OCS/OFCS to CCS can (and in many cases should) be a stepwise migration, enabled by the introduction of a flexible charging function instead of opting for a risky big-bang CCS deployment. As an added bonus, this approach also serves as a solid foundation for breaking up data silos and ensures data can be routed to other key downstream systems besides charging (think analytics, enterprise partners, revenue assurance, etc.). 

Lead Product Manager @ DigitalRoute