In part 2 (of 3) of this series on policy & charging (see part 1 here) , I asked Matrixx’s Nigel Back “How far beyond the 3GPP OCS and PCRF standards can you go, and what happens if you try?”
How far beyond the 3GPP OCS and PCRF standards can you go, and what happens if you try?
If a product supports OCS and PCRF, is there any reason why it would not go far beyond those specifications to offer greater capabilities than the specs account for or would that create issues regarding interoperability? I can certainly see scenarios where you can define and apply much more sophisticated charging rules that are important to billing, product definitions, or actual charges made against a balance or to a credit card. The 3GPP architecture mostly cares about “yes/no” and “stop/go” types of things. So, is the 3GPP aspect of a deployment affected negatively by functional expansion? Can it be exposed only to the information it needs, function as intended, and yet allow for a solution’s differentiating functions to work?
Back says:
Yes. In general, the standards aim to ensure inter-operability but do not go as far as defining specific use cases. So, subject to individual solution capabilities, there are few limits to the offers that can be imagined and implemented. The standards simply specify that the rating/policy engine is passed parameters over a defined interface and returns a result by the same interface. They do not, for example, mandate support for time of day or device dependent rating, QoS turbo-boost or a family shared balance. And they certainly don’t address real-time user interaction for self-care, notifications, promotions etc.
In practice, offer flexibility is of course constrained by the information visible to the charging system when a rating decision is executed. In this respect, the standards define a rich set of AVPs (Attribute Value Pairs) which are the parameters used to carry users’ session or call information from the network and application servers. For example, a time AVP in the charging request would be essential for Time of Day rating while a tariff dependent on the Radio Access Technology such as UMTS, LTE, or WiFi would use the RAT-AVP. Vendor specific (custom) AVPs – present in probably every deployment today – also allow rating and policy decisions to be influenced by information not defined within the standards. So, in short, there is plenty of flexibility to enable offers within the scope of the standards, albeit with the integration challenges arising from as many implementation variations as there are vendors (maybe more).
Back also says that the standards flexibility can be a double-edged sword. This relates to the ability of a solution to be adapted to different interface implementations without expensive coding, customization and delay. For example, he says, if Vendor A interconnects its OCS to Vendor B’s GGSN which supports a custom AVP (e.g. Device Type), how easily can the OCS be configured to include this new AVP in the rating decision? He says that Matrixx have designed their rating engines to accommodate these non-standard cases with simple configuration, but he’s seen “other solutions where this can only be done with M&M code (not the chocolate, but Months and Millions).”
He adds:
There are also important opportunities for enhancing OCS/PCRF solution value outside the scope of the standards, an important example being analytics capabilities and integration. Real-time mobile data charging and policy engines consume huge and growing volumes of transactional network and application data from which deep insight can be extracted. This can range from triggering promotions or notifications based on detection of a specific service usage, to deducing network or customer issues based on event volumes or patterns. The balance of real-time analytic functions between the OCS/PCRF and a full streaming analytics solution requires careful consideration but is an opportunity for value creation outside the standards’ scope.
Part 3 is coming soon, where we talk about how to trick 3GPP processes into allowing us to be more creative. In the meantime…I’d like to know if anyone has crashed into a brick wall trying to integrate two so-called 3GPP compliant platforms that are so highly customized that they are now a nightmare to integrate.
Be the first to comment