By Glenn Seiler
Network functions virtualization has fast become of part of the road map for equipment vendors, operators and other suppliers in the industry. However, many see the transition from hardware- to software-based network functions as daunting and challenging. Let’s look at five issues that are creating barriers and consider solutions to overcome them.
Barrier No. 1: Erroneous perceptions
As operators think of technologies to address NFV, some of the first to come to mind are existing or familiar enterprise-class software products and they may assume they are adequate for carrier-class applications. This is incorrect, as enterprise solutions are not designed for the telecom environment and can’t deliver the carrier grade reliability that is required for this industry. However, NFV does require carrier grade reliability, and in fact, there are opportunities to deliver this today.
In other cases, perception or market hype outpaces reality. For example, many assume NFV programs with operators are in aggressive deployment today, but in actuality equipment running NFV solutions are still only sparse. Projects are largely still in trials and closer to research and development tests or proof-of-concepts versus live deployment in the actual mobile network.
Barrier No. 2: Legacy infrastructure
It’s true that many older or legacy products won’t be upgraded to support NFV. However, operators can still deploy NFV in many important and evolving applications. Some of the leading candidates for NFV look to be virtual CPE equipment and greenfield deployments of LTE-Advanced, the evolved packet core and virtualized base stations seem to be leading candidates for NFV. Additionally, virtual network functions can also run virtually on legacy infrastructure. Operators can deploy these new NFV functions gradually and use the return on these investments to start funding and expanding additional and more complex NFV projects.
Barrier No. 3: Financial
Traditionally, capital equipment was kept on the books and on the network until return on investment was achieved and then profits booked back to the capital expense investment. However, software accelerates the introduction of differentiated products and can drive profits sooner. R&D teams are excited about this, but they still need to sell NFV internally to business units whose perceptions of its financial risks and rewards may vary.
Barrier No. 4: Technological/operational
Operators must get comfortable with NFV and deliver on expected levels of reliability. They can’t sacrifice performance or carrier-grade reliability when moving to a virtualized architecture. Another technology challenge is that operators must eventually adapt to NFV’s forthcoming systems for management and orchestration of virtual services and functions. With NFV, the silos between equipment providers will be broken down and there will be mixed supplier environments, but getting everyone to accept and adopt the common interfaces and standard practices necessary won’t happen overnight.
Barrier No. 5: Network architecture
To make the most of use cases like multi-tenancy or service chaining in an NFV environment, creating new network architecture that is virtualized and programmable will be important. This is where software-defined networking technologies intersect with NFV. Programmable protocols like OpenFlow and SDN controllers such as OpenDaylight will be key in the move to this new network architecture.
Addressing key NFV issues
Suppliers will need to address these challenges today and prepare for the financial and operational benefits that come with NFV. In order to successfully achieve NFV, operators must demand solutions that allow them to maintain “six-nines” of reliability, ensuring that they can honor their service-level agreements. Additionally, it will be important to also seek solutions that can interface with existing operating support and business support systems and can support forthcoming MANO specifications. Ultimately, as customers move to NFV architectures, they must maintain carrier grade attributes without sacrificing performance.
Post originally published on RCR Wireless.