Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Five myths about Network Function Virtualization (NFV)


Published on

A quick summary of my observations and notes about the top five myths about the NFV sales stories from vendors and market research firms. I have been working with major service providers (with them and as a contractor/consultant) for 15+ years and last two years on emerging technologies.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Five myths about Network Function Virtualization (NFV)

  1. 1. NFV-Myths 1. New Revenue 2. TCO Gains 3. Five 9’s 4. Evolution of OSS/BSS or Same OSS/BSS 5. Innovation
  2. 2. #01: New Revenue • From long tail applications – Quick & hours to launch new service – If successful, scale-up; If not, remove and reuse the infra for something else • Agility (first to market) – Hours instead of months. – Charge premium / additional charges for the express service • New Use cases (Green filed / OTT) – Service chaining – Managed services – Anything as a Service or Everything as a Service • New Services – Main challenge is with the manual processes and nothing to do with current infrastructure. So it’s all about cultural change and SOP change. – Scaling up / down would work only when there is a huge list of apps running in the DC / NFV-I. If not there is no benefit • Agility – Again, the delay is mainly from ‘decision’, ‘studying the market’ & UAT. In case of infra, the delay is typically caused by CPE/Last mile – Not sure anybody willing to pay for 1 hour leased line or FW. Enterprises do have planners / engineers. Most of them are price sensitive • New Use Cases – Can be done today with existing technology
  3. 3. #02: TCO Gains • Reduced Capital costs – Cheap hardware (or COTS / Whiteboxes) vs Proprietary NPU based HW • Reduced operations cost – Lower manpower – Increased productivity – Economies of scale (using same infra for multiple purposes and remove wastage) • Automation & Orchestration – Removing redundancies – Increased productivity • Reduced Capital costs – Typical spending is in the CE/Optical, Core or High end routers. Not sure anybody changing this with a X-86 – White boxes are ‘cheap’ but there won’t be any support. Unless the TELCO is self sufficient (e.g. Google/Facebook) this is going to be a big issue • Reduced operations cost – Field trip cost of $400 is in USA/EU/AU. But not in emerging markets. Staff costs do take a fair portion but the main cost comes from the HW itself. So negotiating the price with Vendor would result in better costs – Increased productivity with a different operations model – Economies of scale when there is a telco wide infra (NFV-I) and centralized mgmt. Not department / division based boundaries which is a norm in telecom industry. • Automation & Orchestration – Most abused word right now.
  4. 4. #03: Five 9’s • Higher availability of Node/Box – Purpose built hardware with 99.999 availability • Overall “system” design / config – Automation / orchestrated new VM replacing a faulty VM • Overall resiliency of the system – Put more cheap HW/SW to compensate the weaknesses in off the shelf hardware; or duplicate the infra • Higher availability of Node/Box – 99.xxxx makes $$$$$ to go up • Overall “system” design / config – If the ‘system’ realize that there is some problem. Also based on the process of VM life cycle management in the telco • Overall resiliency of the system – Increased costs. Most of the TELCO’s are balancing 999’s with $$$. • Four of the TELCOs (probably the largest four) in the region hinted they would be happy to go with 99.9 but at 25% savings
  5. 5. #04: Same OSS/BSS • Evolution from HW to Virtualized – Put add-ons to cover virtualized functions – Same software running on different hardware • Same operational processes (SOP) & skills – Hiding the complexity under orchestrator – Minimum skill-set change / vendor managed service • Same as traditional “box” based approach • Evolution from HW to Virtualized – Virtualized functions operate entirely in a different way. It’s no longer SNMP but managing the infra, hypervisor, apps, and service functions • Same operational processes (SOP) & skills – Massive skill change required to even implement in a lab. Orchestrator or for that matter any ‘program’ can only reduce complexity up to some extent. But to use that, one need to know how to; and what is best for the organization • Same as traditional “box” based approach – Voids the whole transition if it’s managed like a box (or like a POD with pre- packed/tested apps running on a COTS HW)
  6. 6. #05: Innovation • Opening up APIs – Enable innovation by opening up NW • Big Data / Analytics – Gain insights in to user behaviors and offer new services (long tail) • Face the OTT threat – Offer similar services (?) – Bundle with last mile • Opening up APIs – Very long hope, and still going on after many such attempts. Challenge is how to monetize the information from the network and what Unique value that can bring to the table. • Big Data / Analytics – Probably Google/Facebook knows much more about the user than the user him/her self. So again, need to capture the unique attribute or pack in a way that other businesses are willing to pay for the information. • Face the OTT threat – Multiple attempts made by operators across globe to offer ‘cloud based e-mail, storage, appstores, voip, whatsapp like apps etc. – Another myth in emerging markets where regulation is not as bad as in matured markets. There is plenty of competition (or totally no infra at all in the last mile) to void this case.