Putting Mediation to New Uses

historically placed on traditional Analytics and OSS systems by telcos have mainly been based on processing aggregated counter data. Today, these need to be adapted to accommodate raw event data at higher volumes and in real-time. Furthermore, network quality has become central to defining service experience. Yet despite these realities, misconfiguration, damaged equipment, failed upgrades and handset-related problems more often than not go undetected for long periods. Why?  It’s most often because data related to these (and other) issues is processed in siloes (different application suites for different source material) within the OSS domain with the result that seldom is a full, end-to-end view presented to the applications that would benefit from having one.

Without the proper tools for creating and acting on information at network-, customer-, and session-levels, hidden service problems, lack of root-cause analysis and a failure of pro-active retention activity lead to churn for the CSP, not to mention less than ideal customer awareness and communication efforts.

Despite this, traditional OSS management products are network-centric, displaying node health and performance through agreed Key Performance Indicator (KPI) metrics. This type of monitoring will doubtless continue to be an essential part of network management in the future, but more is needed today. Mediation applications, purposed to deliver OSS Mediation, provide the answer.

OSS Mediation shifts the focus from measuring how well services are performing to how performance actually affects the subscribers’ experience. Once this is added to traditional, network-centric OSS, service performance data can be contextualized to deliver impact analysis from an individual customer perspective. Mediation applications are perfect for this role.

From PCRF to Mediation-based Control of Policy Decisioning

Here I’m using Policy and Charging Rules Function or “PCRF” as a general industry-term, although the role Mediation can play in the context of Policy goes further than simply PCRF. CSPs need a Policy solution that removes the constraints associated with traditional PCRF products. These constraints are mainly related to a lack of flexibility, which can lead to complex requirements and long lead-times when operators want to add new services or make changes to policy rules.

Open platforms for PCRF that enable flexible configuration are required to meet operators’ goals of achieving new service deployment in days and in a cost-effective way. Mediation applications have characteristics that make it ideally suited to deliver what’s required.  Think about it:

• Integration and correlation of “all” the data from the network.
• Transformation and creation of drill down customer experience data for policy decisions in real-time.
• Derivation of churn, consumption and trend data from big data business intelligence repositories.
• Collects and Controls the charging dialogues between the network and the online/offline charging systems.
• Offering an integration layer to enable a partner eco-system.
• Control and management of network policy through PCRF functionality.

An “active,” mediation-based approach to controlling policy as a strategic rather than an enforcement tool enables the CSP to action much more than network protection and differentiated service charging. It means controlling the experience of the subscriber over a multitude of silos using a horizontal target architecture.  With a mediation-based approach, policy becomes a cornerstone for innovative service launches, increasing customer satisfaction and generating new revenue streams.

Now is the time to move in this direction with the CSPs PCRF; tomorrow mediation-based approaches are also needed in the next step of policy control, namely when the next generation of programmable networks are emerging with NFV & SDN.

Lean Stacks: Offload, Usage and KPI Management

Given the rapid pace of change in the communications industry, a new architecture specifically capable of enabling faster delivery of new services is mandatory.  That’s because traditional BSS and OSS stacks tend to be a barrier to this sort of progress, not an enabler.  Why? In part, the IT cost for enabling systems like legacy billing and network analytics to perform new functions is growing exponentially, as applications have to be adapted to accommodate the service delivery transition. 

We know that the cost-per-processed-event in legacy BSS is already prohibitive; yet what happens when these stacks have to take on the sort of lower-margin or even negative-margin services that CSPs need to deploy to compete in parallel to delivering the customer control functionality necessary to simultaneously support high margin, up sell services?