Carriers are witnessing a trend that’s transformational rather than incremental in nature. Changing the way it’s deployed, managed and operated. This overhauling trend is “NFV – Network Function Virtualization”. Traditional architecture has long deployment cycles, costly replacements/add-ons to meet new requirements.  With limited capability to adapt dynamically to new service opportunities and use cases, inflexibilities of proprietary interfaces, requisites of complex vendor integrations, traditional architecture makes smallest modification a process that’s too sluggish to match the scaling and fast evolving subscriber needs. NFV substitutes cost-heavy network assets with ‘software’ – capable of running on commercial of-the-shelf hardware. Also, it is in a setup modelled to share commodity resources with the virtualization technology, chained together to perform in sync to deliver an end-to-end service. Adding a new component to the network or substituting it requires just a software image to be replaced on the virtual hardware, precisely repurposing the VM. This is easier and faster. Also, this creates the space of innovation for ISVs (independent software vendors) to add differentiating and new services. Though, starting with the goal of CAPEX reduction, the role of NFV evolved to offer:

• “CAPEX Reduction + OPEX Reduction + Higher Service Agility + Improved Operational Velocity”.

With the new goals, also evolved the role of the orchestrator in NFV. Orchestration though defined as automating the deployment and connection of multiple IT/network elements or software components; in carrier NFV, the functional zone of an orchestrator does not limit in a virtualized data center, hosting standardized resources within. Here, it needs to manage virtual machines, legacy devices and virtualized network functions instances that might be in the data center, in-the-network or at the customer premise. So, orchestration in carrier NFV can be defined as automating provisioning and management in an environment with:

• “Virtual Machines + Virtualized Network Functions + Independent Software Vendors+ the Legacy Network Devices”.

To address the need, ETSI has defined a framework for NFV Orchestration terming as MANO (Management and Orchestration). As shown, the new ecosystem includes operator systems (OSS/BSS/EMS), virtual network functions (VNF) instances and non-virtualized network devices and the newer managing elements in the NFV model. Already being a multi-vendor environment, NFV adds-on more complexity with new vendors in the ecosystem and the VM managers levelled at lower abstraction layer to handle this. It needs a holistic monitoring, which can be achieved with VNF and BSS/OSS vendors offering a rich set of APIs to communicate individual device behaviour to the orchestrator, using proprietary or standardized interfaces. An API open NFV system offers flexibility to choose best-of-breed applications. The ETSI architecture so defines the standards for these APIs – as were published in the IETF meet in March, 2014 and subsequent phases. Vendor integration between the VNF, ISVs and VM providers, reliability requirements (99.999 Availability) and MANO are the some of the key assessment areas for operators to consider in their RFPs as they roll-out the new systems. To assist the adaption , elitecore  has shaped-up testing labs to ensure it offers flexible frameworks with its core session manager offerings including industry-standard EliteAAA and NetVertex PCRF products, ready to scale to NFV requirements but with hassle-free integration with the complementary vendor ecosystem. A collaborative effort by vendors is required to deal with these fresh complexities – opening more APIs and adhering more of the open norms.  The benefits NFV promises are phenomenal and the earlier it is adapted, sooner will be the benefits reaped.