Defining the role of convergence in Policy and Charging
Defining the role of convergence in Policy and Charging

A common engine for policy and charging

Over the past few decades, charging has been a critical element of telecom operations. With the evolution of mobile internet and high data usage, policy control has also become equally important. Although network operators and telecom vendors have always treated these two functions (Policy Control and Charging) differently, if you look closely, they are meant to complement each other and hence be aware of each other.

STL dPCC is a convergent policy and charging solution for all network types, ranging from 2G, 3G, 4G, VoLTE, FTTx, Wi-Fi, IoT and 5G. dPCC provides a common policy and charging engine, without any need of a reference-point (unlike Sy or proprietary), a Common Rating, Charging and Policy Catalogue and a common Subscriber-Profile-Repository for PCRF and OCS. The integrated functions deliver faster response time, reduced time to create a new product plan and reduced compute and storage requirements.

The time is right to converge policy and charging

If we consider recent trends in mobile data charging, more than 80% (in some geographies more than 95%) of data plans are of bundled, i.e one time charge for some gigabytes of usage along with other services. since, data usage is bundled, it does not require any rating/charging functionality, but only usage management.However, the online rating/charging traffic generated by such usage is more than 80% of total charging traffic hitting on OCS (Online Charging System). This is not only a waste of rating and charging resources, but also an overhead of unnecessary signalling over the WAN bandwidth. This problem has now become more severe, when we are in the age of biggest telecom industry revolution for data usage - 5G.
5G is here and we are seeing nation-wide 5G deployments in different parts of the world, the legacy PCC framework has to be addressed in smarter ways, to remove the unnecessary signalling load and also provide ease of operation at the same time. The concept of Mobile Edge Computing (MEC), is now taking shape and PCC should also adapt to this change.
But the question is, "Is there a way to mitigate or optimize this wastage?" The unequivocal answer is "Yes" and we will discuss that in the subsequent parts of this paper.
There have been attempts to make PCC (Policy & Charging Control) funtions work more closely; either by introduction of Sy interface between PCRF and OCS for realtime Counter Management or by implementing proprietary frameworks, but still this framework is working in silos and hence there is a lot of scope of improvement. Key areas to focus are as below:
  • Signalling Load Reduction
  • Hardware Reduction
  • Data-Replication Reduction
  • Ease of Operation

Key challenges in policy and charging

Although, there have been efforts to make Policy and Charging functions (PCRF & OCS) more efficient, but they fundamentally lack focus on expected outcomes, both in terms of efficiency and cost. Initially, solutions started with implementing their custom interfaces between OCS and PCRF, to have a synchronization of Policy and Rate Plans, then few moved to an integrated Product-Catalogue for Policy and Charging, but there have always been an additional layer of 2 different databases, one for OCS and one for PCRF. Even 3GPP has come up with a standard Sy reference point between PCRF and OCS to overcome the synchronization problem of the usage/quota and policy, but it actually added more complexity to the solution, by increasing the integration efforts and higher response times, by introducing an additional message between the 2 functions.
Even in the modern age, when fixed and wireless networks are converging, most of the solutions lack a common PCC solution, which can cater to such a mesh network; Mobility, Wi-Fi, FTTx, xDSL etc. This requires more money from CSPs pockets in form of CAPex and OPex.
It is evident from these trends that none of these approaches have shown favourable results, and hence it is not about a common policy and charging Solution for mobility network, but a converged PCC solution for creating a much-needed convergence of policy and charging across all the network segments ranging from fixed to Wi-Fi to mobility.

Recommendations for Policy and Charging

STL, as a data networks innovator, has spent considerable efforts in client engagement, post-production analysis (of PCC solution) and in research and development to find a smart way, so that a truly unified policy and charging control framework can be developped, not only mitigate the 4 major problem areas identified above, but also to offer Independant scalability of individual Modules; Charging-Function, Rating-Function, Policy-Function (PCRF), ABMF (Account Balance Management Fucntion)/ SPR etc.
Another set of problems come from the 5G aspect and MEC (Mobile Edge Computing), where the use cases define the overall network/solution architecture. "On Size Fits for All" kind of architecture does not have a place in the 5G game. Hence, it is important more than ever, to find best architecture, when implementing a specific use-case or set of use-cases in 5G. How to ensure what to put on edge and what not to? What to distribute and which ones to centralize? No matter the implementation type - Edge or Central - managability and data distribution is the next driver to think of, after the use-cases.
It’s well understood that MEC enables quicker response and dedicated use-cases/application access etc. for mission-critical and delay sensitive applications, but in a real world deployment, these edge deployments should not be in silos and there should be an operational ease, not only for the central network functions, but also for the Edge NFs as well. Hence, this gives rise to a new set of problems:
  • Deploy on edge, but manage centrally
  • Single UI operations
  • Distributed data and compute

A future-ready approach for policy and charging convergence

STL dPCC (Digital Policy and Charging Control) is a carrier-grade, convergent, realtime Policy and Charging solution, specifically designed to not only mitigate the fundamental problems of PCC framework, but also getting ready for 5G NSA and SA deployment, including MEC.
It is very clear from the above figure that STL dPCC is designed to not only cater to PCRF and OCS requirements into one box, but also to support multiple network segments and protocols at the same time.

The Convergent PCC

STL dPCC is a convergent rating, charging and policy solution, providing realtime policy enforcement and charging on a single instance. Below are the key features, which are the constituents of a convergent PCC:

A common PCC engine

STL dPCC is a convergent rating, charging and policy engine. However, all 3 Functions are logically separate and can scale independantly, but they all share a same cache and database, which allows dPCC to reduce time to respond to a Gy request, for which Gx session is already created, as it does not need to iterate multiple subscriptions, as it gets the information from existing Gx session. This removes the additional requirement of Sy signalling traffic and directly reduces one third of the Diameter traffic for Data.

Usage management over Gx or Gy

Since it is possible by dPCC to perform usage-management over Gx or Gy, for a bundled quota, it is possible to simply remove the signalling load toward OCS over Gy interface. This directly benefits not only the policy and charging solution, but also improves the performance of PDN-GW/GGSN, as less number of transactions are required over Gy. Additionally, it contributes to a faster time to connect to the user, hence improving the Quality of Experience and reducing churn risk.

Common product catalogue

STL dPCC offers a common product catalogue, for both policy and charging functions, i.e PCRF & OCS. This makes it not only easier to create the new product in lesser time, but also removes the additional layer of plan syncronization between OCS and PCRF. This reduces the test cycle as well for any new product or services offerings.

5G-ready dPCC

STL dPCC is a 5G-ready Policy and Charging solution. It is compliant with 3GPP-R15, 5G-NSA (Non-Stand-Alone) with Option-3 already supported for both PCRF and OCS. In PCRF, new requirements such as QCIs/5Qis, Extended Bit Rate etc. are currently supported, making dPCC the right choice for the telcos, starting with 5G trials or commercial launch. On OCS side, HTTP/2 based N40 interface is supported for providing charging support for 5G-NSA and SA (option-2, 3) deployments. Below are the key features, currently supported for 5G readiness:

  • Extended-MBR-DL/UL
  • Delay-Critical-GBR QCIs
  • New QCIs/5Qis (other than 1 to 9)
  • HTTP/2 based RESTful interface for charging

Deploy on Edge, but manage centrally

The follow attributes make it possible to deploy dPCC on Edge, but still manage from a single central GUI.

Data distribution function

STL dPCC provides options to intelligently distribute the Subscriber Profile to multiple SPRs (Databases), without any data replication. STL dPCC is a modular solution, where SPR and dPCC Engine can be scaled ìndepedently. Hence, if subscriber volume is increased significantly, as compared to the network TPS (Transaction Per Second), it is possible to only scale up the SPR and not the whole solution.
By virtue of DDF (Data Distribution Function), it is possible to distribute subscribers profiles, across multiple databases, without any data replication. This distribution can be based on MSISDN/ IMSI Range or Network Type or Location based. This information remains as a central configuration, while each of these SPRs (Database) can be deployed across multiple geographies, i.e closer to the edge to provide faster access and reduce overall response time.

Agnostic platform

STL dPCC is a network-, vendor- and protocol-agnostic platform. Below are the main elements, which makes dPCC a truly agnostic and convergent PCC solution.

Multiple protocol support

STL dPCC is a network-agnostic solution and offers a wide range of North and Southbound Interface Protocols on single deployment. STL dPCC offers legacy protocol interfaces like CAP and RADIUS (for 2G, 3G and Fixed Line), Diameter for LTE, VoLTE & 5G-NSA, SFTP for Offline Charging and HTTP/2 for 5G-SA. STL dPCC has modular Access-Layer, which converts all incoming Southbound traffic-attributes (for example: AVPs in RADIUS and Diameter) to internal attributes (dPCC-Keys) and with the help of Enrichment Layer, by using on screen configuration. Same dPCC-Key can be mapped to different attributes coming from southbound channels; for example: dPCC-Key for Usage-Reporting is CS.SessionUsage. In case of LTE, Usage is reported in Usage-Monitoring-Info AVP (over Gx), while in RADIUS same is reported in Acct-Input-Octets and Acct-Output-Octets.
Hence, while usage is reported usage over Diameter (3G, LTE), dPCC maps the Usage-Monitoring-Info AVP to CS.Session Usage and when usage is reported over RADIUS (e.g FTTx, Wi-Fi), Acct-Input-Octets and Acct-Output-Octets are mapped to CS.SessionUsage. This makes the internal dPCC engine agnostic to the incoming protocol. Hence, it is possible to adapt to any protocol or add additional protocol adaptors, like HTTP/2 adaptor is added for 5G-SA support, without impacting the dPCC Engine source.

Dictionary management

STL dPCC provides Dictionary Management for RADIUS and Diameter Stack. This functionality has also been extended for HTTP/2. Unlike most other telecom solutions, where RADIUS and Diameter Dictionaries are part of Main Software-Binary, STL provides this functionality, as part of configuration. At any point of time, it is possible to Add, Delete or Update any Standard or Vendor Specific Dictionary, without getting stuck and waiting for a next release. Features like Tethering Detection, IPv6 Usage Report etc. are implemented by using various Vendor-Specific-Attributes (VSA). If such functionality is not given as part of configuration, CSP have to wait for the next software release and incur additional expenses.

Multiple identity support

Since dPCC is a network-agnostic solution, it provides support for multiple identities. It is possible to have a single subscriber accessing internet using different network-access-types and uses different identity for this. For example: UserName for FTTx, MAC-Address for Wi-Fi and IMSI/ MSISDN for Mobility. STL dPCC provides options to define multiple alternate identities and subscriber lookup option on either Primary or Alternate Identity. Hence, while subscriber is reporting usage on various network-types, it is possible to use same or different quota bucket for the same.

STL dPCC next-gen enabler use-cases

STL dPCC also provides several advanced use cases, like Charging over REST, which can be used to offer dPCC as a Charging Platform, AKA ChaaS (Charging as a Service). STL dPCC makes it possible to deploy this solution over cloud and offer it as a Charging Service, not only for the CSPs, but also to other industries, like Cab-Service-Companies, Utility Companies (Power, Water, Gas etc.) and even enterprises for their different charging use cases.
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 collaborating not just with OTTs, but also with the other industries. Some telcos have had few B2B2C use cases deployed in partnership with OTTs, but now is the time to think beyond it and look at other industries, which have never been an area of focus and begin the idea of B2B2X. ChaaS should be the first step towards exploring new revenue generation models, even before CSPs start with deploying 5G. It is true that there will be challenges and current charging systems will need a 180-degree shift, but this is the only way forward.

Conclusion

Legacy Policy and Charging framework, clearly needs a revamp, to reduce signalling load, increase performance and ease operations, along with support for 5G-SA and MEC. With STL dPCC, CSPs can not only converge Policy and Charging, but also enjoy the full potential of 5G-NSA, SA, along with mobile edge computing. STL dPCC makes it easier to deploy on Edge and manage centrally, without any data replication. By providing modular access and enrichment layer, multiple protocols, network-segments and identities are supported, in addition to the common product catalogue and dictionary management. CSPs enjoy the advantage of reduced Gy Signalling and enhanced overall network performance, while ensuring seamless business experience.
About the author
Satees Kumar is a passionate technologist with over 12 years’ experience in the telecommunication industry across various domains, form RAN to Packet Core to Next-Gen OSS/BSS. As a solution architect for Policy and Charging Solution at STL, Satees oversees all technical and architectural requirements of CSPs and helps the customer by advocating the right approach and designing the optimum Policy and Charging Solution for current and future needs. Satees is a pioneer in 5G research, specifically on service-based architecture, network slicing, private 5G networks and mobile edge computing solutions. He is also a great enthusiast of ChaaS (Charging as a Service) and continuously shares his upgraded approach for exploring various new dimensions and monetization possibilities of charging solutions, within and beyond the telecommunications domain. Connect him on [email protected]
Download whitepaper
Download the Whitepaper here