instagram icon
MENU menu icon
back to blogBlog

Monetizing NFV

July 27, 2016 1:00 PM

Category: Cloud | by Damian Nowak

There have been a number of network transformation projects happening across the globe in recent months. These transformation projects range from smaller, friendly proof of concepts, e.g. in VIP Macedonia, as well as large multi-year projects, e.g. AT&T`s Domain 2.0 and Vodafone Ocean. According to Virtuapedia, an ongoing research project that defines the scope of the business opportunity that virtualization affords communications service providers (CSPs), approximately 37% of the communications industry is planning to virtualize a majority of network resources by 2019.

What do all these initiatives have in common?

The ultimate goal is to build a fully open, auto-scalable, virtualized network that is able to adapt to challenging market conditions in today`s fast-moving, always-online world. Adaptability being the key term. Revenue management systems are not exempt from the virtualization story; they need to be able to easily adapt to virtualized networks in order to monetize the new capabilities.

The challenges of virtualization when it comes to billing

Virtualized networks (consisting of platforms and applications running on them) enable extreme flexibility when it comes to adapting network capacity for different services according to current usage, or demand generated by connected subscribers. If you aren’t familiar with it, the standards body ETSI has created an initiative called NFV which provides a sound framework for making core network virtualization possible.  Virtualized Network Functions (VNF) deployed in virtualized infrastructure platforms scale independently, but in a controlled manner assured by NFV orchestration systems, such as RIFT.IO, in order to efficiently serve subscribers according to their changing usage patterns.

While virtualization promises ultimate flexibility, often it is the legacy, bare-metal revenue management solutions that cannot adapt as flexibly as other network functions and therefore force CSPs to add protective layers in the orchestration layer. In a recent VanillaPlus Roundtable session, the discussion was on mitigating the virtualized network deployment risks. Among others, the inflexibility of physical network functions in terms of capacity management was identified as a significant deployment risk.

While there are products that help control the network adaptation processes and ultimately protect external systems from overloading, this is actually counterintuitive to the self-adapting nature of virtualized networks. Thus bringing about new requirements for a revenue management system operating in such an environment: The flexibility and responsiveness of the revenue management system dealing with virtualized network functions must match the flexibility of the network, which generates chargeable events. Having a network able to provide nearly unlimited services and capacity without a revenue management system which is able to monetize them, well, makes little to no sense. In fact, the whole concept (and investment) of virtualization would then come into question.

Characteristics of a virtualized revenue management system

What does a revenue management system require in order to fit into a scalable network ecosystem? It must be as scalable as the network itself. Key characteristics of a scalable revenue management system include:

  • Modularized, multi-tier architecture 
Traditional differentiation of system tiers into “access,” “processing,” and “persistence” is not sufficient anymore. A more granular modularization is needed to allow for independent scaling of specific modules within a tier, in addition to independent scaling of different tiers.

  • Horizontal scalability 
Horizontal scalability is easier to achieve in highly-automated environments than vertical scalability. Horizontal scalability also provides a foundation for efficient scaling across boundaries of physical data centers, e.g. large Cassandra clusters deployed over geographically redundant sites running a single set of data or distributed systems with common access layer providing a transparent system view for subscribers. Redknee Unified Charging’s multi-campus is an example of such a solution.  

  • Adaptability to different NFV-I platforms
Redknee works with a number of CSPs who are evaluating multi-vendor strategies when it comes to NFV-Infrastructure, as well as VIM components. An adaptable system must be ready to be deployed in different NFV platforms, e.g. when a capacity of one deployment is exhausted, and another deployment is to be used. This adaptability also helps to avoid a vendor lock-in when it comes to NFV platforms.

  •             Adaptability to different NFV orchestration platforms
     The NFV orchestration platform is a key element of the scalable network. Revenue management systems need to be integrated in order to scale accordingly to changing network conditions.

With this in mind, it seems this new generation revenue management system, one that brings just as much flexibility and scalability as NFV does, is the key to enabling CSPs to fully monetize the capabilities made available with modern adaptable networks and truly unleash new service offerings to their subscribers.

Learn more

Redknee’s work in virtualization is enabling its clients to go to market confidently with a revenue management system designed to work seamlessly with any OpenStack-based NFV platform. Whether you are looking for a hybrid approach, private deployment or working in a public cloud environment, Redknee Unified is the key to monetizing your NFV investment. Learn more about our solution here, or contact us today at