Policy and Charging – Why Integration Is Not Enough

March 21, 2013 by Dave Labuda

Policy and Charging – Why Integration is not Enough

The telecom industry is emerging out of simple mobile data plans and into complex service and subscription models. These models create more sophisticated processes and transactions that multiply the performance and scale demands placed on both policy and charging systems. These two domains have evolved separately due to circumstance and technical limitations. The boundaries between them now cause onerous problems, however, which put customer experiences and operator differentiation at risk. In a market where customer-facing performance is critical, it doesn’t make sense to continue to manage policy and charging on separate paths; it’s time to unify them.

A Forced Division

Policy and charging emerged as separate domains largely for organizational reasons. Policy systems were designed to give operators control over the QoS of service flows and contexts in an IMS architecture. As data services became dominant – network groups found a different use for policy. As networks became flooded with smartphone usage, operators felt compelled to defend their network resources as they worked to cope with the massive increases in traffic volume and unpredictability borne of all-you-can-eat subscription models. They leveraged policy management systems as a stop-gap solution to implement fair usage, maintain QoS, and protect network resources from overloading.

In the meantime, online charging – initially used for prepaid voice – evolved over time into the IT domain. As more real-time billing, payment, and usage accounting demands emerged with new services and subscription models, charging was asked to do far more than just count usage on pre-paid plans. As data usage grew exponentially, more demands were placed on both policy and charging. Vendors and operators came to the conclusion that under this pressure to scale, these related domains should grow separately in order manage the load and meet performance requirements.

Challenges Result From Disparity

Policy and charging depend on each other; each domain is responsible for making customer-facing decisions regarding service usage based on subscriber, rate plan, and behavior information. Maintaining them separately has made managing customer experience a real challenge for mobile operators.

Latency problems that undermine service performance also tend to emerge as a result of the separate domains. Diameter signaling grows exponentially because of the extra hops required to communicate between separate policy and charging systems. The separate domains also increase data duplication and synchronization burdens, introducing fundamental data quality and compatibility problems common to loosely integrated but interdependent systems. As data volume grows, the problems grow; risks to service quality increase; and the cost to maintain or fix the problem increases too. And a simple mistake, such as a data or rule disparity on either side, such as a counter being incorrectly referenced or misspelled, can devastate user experience for millions of subscribers.

Worst, the complex, performance-restrained, and data challenged architecture tends to limit policy definition and enforcement to simple counting. Though 3GPP specs call for counting to live in the OCS, performance limitations have forced many operators to push counting into the PCRF. This has the unpleasant side effect of limiting how complex policy definition can become. In a world of simple services, where usage is counted against one subscriber’s limit, it’s been a manageable problem. Now that the industry is moving into far more complex service models – shared and 3rd party paid plans; bonus promotions; split personal and business usage for BYOD – limited policy definition constrains an operator’s ability to innovate service offerings and compete.

Proof in Performance

Performance and scale are the most often cited technical reasons operators keep policy and charging separate. If the performance issues are eliminated, however, it just doesn’t make sense to keep policy and charging separate. MATRIXX has demonstrated its ability to eliminate these traditional performance limitations. If an operator could start over, business demands would dictate unifying policy and charging from the start.

A unified policy and charging architecture would immediately drive signaling efficiencies; Sy handshakes would be eliminated, which would reduce as much as 30% of the transactions. The unified architecture would also allow for a single point of configuration and a single database for policy, charging, and subscriber profile information. This would eliminate most of the data duplication and synchronization problems.

More critically, unification would provide an operator distinct advantages in competitive differentiation and speed to market for new services. The intersection between policy and charging is a “change center” that’s at the heart of real-time BSS infrastructure. A unified architecture accelerates, simplifies, and improves an operator’s ability to define, launch, test, target, segment, and modify new service offerings. Its streamlined nature also allows for greater scalability with significant reductions in total cost of ownership to achieve a superior solution.

This entry was tagged Unified policy and charging