There is an increasing level of debate around the convergence or divergence of policy and charging functionality. Questions abound like whether or when should they reside on a common platform, be integrated, or remain on separate paths? Where should a CSP draw the line between the two sets of functionality? Does the market adhere to 3GPP’s definitions; are they keeping up; and what do they not cover that is critical to CSP’s evaluations of policy and charging solutions? These are all complex questions to tackle, so we’ll just begin digging in here and try to make some progress on addressing this issue. I recently chatted with Nigel Back of MATRIXX Software to shed some light on the discussion and begin to make sense of it.
What does it mean to be 3GPP Compliant and Still Be a Charging Solution?
Whether we’re talking about an OCS or a PCRF, those are just 3GPP’s functional definitions. So, a real time billing or policy management solution would incorporate those functions to comply with 3GPP, but product differentiation is about everything else: how well they scale; the quality of the tools around them for defining charging or policy rules and scenarios; and how well they integrate with other components in the whole architecture involved in real-time service delivery. I asked Back if he agreed with these assumptions and whether, for example, a real-time billing platform can provide OCS functionality, but that doesn’t mean it’s just an OCS?
Back says:
Yes, a great deal of the value rests in how easily and quickly new offers may be configured and deployed which demands strong support for …
– Creation: GUI based – intuitively simple to use. But some degree of expertise will always be required and I’m nervous when I hear claims that configuration is “so simple that we can give marketing direct access”. Service and offer design must always be sensitive to potential service interactions and exceptional cases which requires some level of technical expertise and experience. What is critical however, is that innovative and sophisticated offers can be created directly via the GUI without complex customization.
– Automation: For example, once a new offer is created, how quickly can it be copied across multiple systems. For scaling and redundancy, some deployments may have 20 or more platforms that offers need to be replicated across.
– Simulation: Does the solution economics and performance allow a ‘what-if’ simulation configuration to replay usage against different offers and determine revenue impact? For example, if I add a Facebook weekend bundle instead of flat rate, what’s the financial impact based on real usage data?
Back adds that physical aspects, such as scaling and performance, are generally outside of 3GPP’s scope but they are increasingly important as mobile data throughput and transaction complexity are revealing significant shortcomings in contemporary real-time technologies.
How standard are 3GPP standards?
There’s no question that 3GPP standards are increasingly incorporated in RFPs and RFQs. They play an important role in the marketplace. But when implementers get down to the details, there can be significant confusion across versions and in terms of which aspects of the standards are actually worth implementing in any given scenario. Back sheds light on this problem. He says:
The 3GPP standards define core functions and interfaces but….
Much of the OCS/PCRF standards content focuses on interoperability, technical compatibility between different 3GPP releases and integration with different access networks (GSM, UMTS, LTE, CDMA) etc. My guess is that less than 50% of the standards would be relevant to any current deployment. Of course the hard bit is determining which 50%, particularly when multiple vendors are involved.
The standards also allow significant flexibility in interpretation and extension so there is certainly no single correct way. For example, 3GPP Release 9 and later define PCRF data usage counting capabilities. These are also specified as an OCS function, driving the need for the Release 11 Sy interface over which the OCS can trigger the PCRF to apply bandwidth throttling on reaching a consumption threshold. A PCRF vendor will naturally interpret the standards in a way that reinforces their PCRF value proposition; an OCS vendor likewise. The debate can be confusing and distracting for the operator who more than ever needs an efficient and agile real-time platform to launch new services.
3GPP BSS standards do not mandate how functions are physically implemented. So the OCS/PCRF may be separate, integrated (via Sy) or fully unified. Often, technical legacy or organizational constraints drive a multi-vendor solution, or operators adopt a ‘best of breed’ approach assuming that no single vendor can be sufficiently competent across OCS and PCRF solutions. But at a recent Policy Control conference in Berlin, a number of vendor and operator presentations suggested a unified approach will be more effective in the long run. This is certainly our view in Matrixx where we see charging and policy as two sides of the same real-time coin. Looking at it another way, if you had the luxury of starting with a blank sheet of paper to design a real-time charging and policy solution addressing LTE business opportunities, it seems unlikely you would define separate elements with inevitable consequences for operational fragmentation and a need to align data and rule semantics across each element, often manually. I speak to many operators where very different views are held regarding OCS/PCRF architecture and functionality distribution, even within the same departments, it’s a hot debate right now.
In part 2, we ask “How far beyond the standards can you go, and what happens when you try?”
Please feel free to share opinions. The point of this exercise is to bring the ongoing dialogue, and debate, into the light.
Be the first to comment