The ability to “virtualize” is critical for operators evolving toward ThinkingNetworks™.

Network Function Virtualization (NFV) implementations and virtualization of the Evolved Packet Core (EPC), as well as systems outside the EPC (e.g., billing), can significantly reduce network costs and help operators become more efficient in matching resources to network and service demands. NFV gives service providers the ability to elastically assign compute and storage resources through a software-only approach.

Assigning resources only where needed is important when it comes to Diameter network elements, especially the Diameter Signaling Router (DSR) and Policy Server (PCRF), which have to be “cloud ready” in order to successfully control LTE EPC functions.

Virtualization will essentially partition the resources of a hardware platform into unique “virtual machines.” These virtual machines replicate standalone functions currently supported on separate hardware. If more compute resources are needed to support a Diameter function, any available hardware can be chosen and a new instance of the virtual machine created by the hypervisor.

The same hardware could also be used to support instances of a policy function at the same time, if enough compute resources exist. It’s that ability to dynamically allocate additional compute and storage resources when needed – using a common pool of hardware – that makes virtualization so important.

The move to NFV implementations will mean operators expand virtual functions to support multiple regions, or extend functions to other partners as part of their cloud offerings. For example, MVNOs or multinational operators looking to put their packet core into the cloud can manage all services and countries through one implementation.

A Closer Look At NFV

At Tekelec, we have developed the Orchestrator, which determines through analytics and other inputs when additional resources are needed. The Orchestrator instructs the Virtualizer (the hypervisor) to create another instance of a function. The Virtualizer creates additional resources, and other instances of the DSR or PCRF per the Orchestrator’s instructions.

Since the Orchestrator is the function that determines what, when, and where additional compute and storage resources are needed, it goes into action when traffic levels in the Diameter network increase. It identifies the rise in traffic and determines if additional DSR or PCRF resources are needed to support the rise in traffic.

Once the Virtualizer implements the new instance of DSR or PCRF, the IP Flow Manager directs IP flows to the new instance of the function (since routing tables will not reflect newly configured hardware).

The communication and cooperation among these components gives networks the ability to expand and contract based on real-time traffic conditions. That capability will become invaluable to operators trying to balance the need for innovative services with the need to maintain network performance levels – both essential to the customer experience.

By Amir Majlesi, Technical Sales Manager

Top 5 operators Deutsche Telekom, Orange, Telecom Italia, Telefonica and Vodafone announced their decision at MWC11 in Barcelona to commercially launch Rich Communication Suite (RCS) across several European markets from late 2011. Other MNOs are expected to join this initiative. The launch will be based on a new adapted version of RCS Release 2.0, which is called RCS-e, and will be based on the use across networks of IP Multimedia Subsystem (IMS) technology, an architectural framework for delivering IP multimedia services. The idea is that mobile customers can use instant messaging (IM), live video sharing and file transfer simultaneously during calls across any device on any network operator in a simple and more intuitive way. This renewed focus is based on results from RCS trials to date and a better understanding of where operators can further enhance their offering to deliver more value to customers and complement established 3rd party services.

This is a pragmatic approach by MNOs to reduce time-to-market and stimulate roll-out of rich communication services in order to combat competitive pressures from over-the-top players. So far deployment of RCS faced two hurdles: unavailability of RCS-ready handsets and complexity of RCS interoperability between MNOs. The RCS-e initiative addresses both obstacles. RCS-e specification reduces terminal conformance requirements to core functionalities in order to ensure availability on low end devices and, therefore, boosts the market penetration curve. Strong endorsement of G5 MNOs pushes now the handset vendors to expedite introduction of RCS-ready phones or to open up their platforms to allow seamless integration of 3^rd party RCS clients into the phone’s native address book. Even Apple cannot continue to be silent about RCS anymore. On the other hand, RCS-e specification focuses on easy interoperability by making “social profile information via presence“ an optional feature. The fundamental mechanism that enables RCS-e is service or capability discovery using SIP OPTIONS. This discovery mechanism is important in that it allows users to determine what services are available before calling and allows operators to roll-out new agreed services to their own schedule. RCS-e provides an adaptive framework for deployment of additional services such as presence, social networking and location base services (LBS).

Moreover, this initiative fosters development of RCS based apps and a growing RCS ecosystem. We expect to see more innovative apps using enriched services that RCS makes possible. Think about for example how social networks, premium content providers, advertising firms, gaming or e-commerce businesses can benefit from rich services such as IM, video sharing and file transfer interoperable between all devices and networks.

Tekelec welcomes RCS-e and looks forward to working with operators on this initiative.