Half Baked Policy Requires Secret Sauce

Over the last few years, policy management and control has become the default answer to the question of how we control telecom services in real-time in order to protect the network or ensure users only get access to services to which they are entitled.

In its early days, policy was a fairly crude mechanism to provide traffic management solutions to ensure that the telecom network did not become overloaded. Since the introduction of European bill-shock legislation, it has become more relevant for CSPs to form a key linkage between charging and the transport network.

With increased competition from OTT service providers coupled with falling revenues and margins, the need for speedy introduction of new telecom services has never been more pressing for CSPs. A common response is tighter and better functional integration between the service design function within billing systems and policy management systems. But this approach alone remains a blunt instrument, causing serious problems that impact the user experience as well as affording very limited opportunities for service innovation.

Same old service

The problem with using the charging system plus policy system as the means by which a CSP innovates and takes new services to market is that the only thing they can do when the money runs down is degrade and then terminate the service.  Telecom service innovation has to be much more than changing the price of the service. As an illustration, a can of baked beans is still just a can of baked beans, no matter what its price. Yes, it’s possible to bundle several together and make an offer – but it is the same basic product on sale. This is exactly what the CSPs have been doing.  The billing system defines prices and packages (or bundles) of services – but it cannot define the actual service behaviour. This has been one of the main problems faced by CSPs over recent years.

The truth is, for complete service innovation in telecoms, modifications to the service itself (or application, if you prefer) need to take place. This is not the preserve of the billing system, nor of the policy system. The service, the billing/charging system and the policy system must all cooperate to determine how the new service behaves. To create something different from the standard fare of the competition, operators need to be far more innovative.

A casual consideration of this matter may lead to the conclusion that policy can indeed change customers’ behaviour. For instance, when a customer has used up the fair amount of bandwidth or reached the predefined spend limit, the policy system is invoked and the bandwidth reduced and then eventually cut-off. There you have it. Policy and billing applications can alter a customer’s pattern of behaviour, but it is a fairly unsophisticated approach that normally delivers a very poor user experience.

Lessons from history

We have been here before. Welcome back to 1995 and the early days of prepaid mobile telephony. You dial the number, make the call, and when your balance is used, it cuts-off the service. Subscribers are not alerted to a low balance and there is no announcement to make it explicit. They also did not receive a redirect to the top-up service, the call just ended with no explanation. That’s how it was, but whilst it worked, it wasn’t very user-friendly. It probably resulted in a huge number of calls to the customer services team, customer ill-feeling and all the commensurate costs.

Policy and charging have collaborated to change service behaviour, but not in the way that customers needed. The introduction of adapted service behaviour (such as warning announcements, the redirection to top up, and more) keeps the user informed and delivers a much better user experience. In short, the service evolved to change the behaviour and deliver a good user experience and the original business objective of not affording credit to prepaid subscribers.

The lesson learnt over the early years of mobile telecommunications is that applying controls to the transport bearer alone produces a very crude form of service behaviour. In fact, from the user’s perspective, it is akin to a service failure, or at least service degradation. This isn’t good for customer satisfaction. 

The complete solution is fully recognised and graphically explicit in the 3GPP policy standards. The reference architecture shows the charging system, policy and the applications (services) fully inter-connected with each other.

New service behaviours

Let’s consider another real-world example. Let’s assume the CSP wants a new service for families so that the children have services paid for on a prepaid basis.  When their balance is exhausted, some services will no longer work and others will have a restricted behaviour (e.g. they can phone home, or connect to their parents or their siblings, but no one else).

It’s clear that the charging system can inform the policy enforcement function when their prepaid balance is exhausted and ask it to block certain services. However, to enact the other functional changes (who the child is able to call on the services that are left in place),  the application must first be made aware that the condition has been reached and second, it must be changed to implement the required behaviour.

The market lessons are clear. CSPs must do more than sell the same things at different price-points, applying different amounts of pressure to the bit-pipe in order to degrade the services. They need to innovate in the service behaviour itself in order to provide customers with functionality that goes beyond the vanilla. Innovation is not just about pricing but must apply to the services on offer and at a price point that suits their users. Nothing else will suffice in the era of cut-price competition and ultra-competitive services.

Jonathan Bell, VP of Marketing at OpenCloud