Future Digital Blog

Discussing all things digital

Most telecom operators are still structured to support siloed physical network functions. They are not prepared for VNF's agile business model in which new services are launched rapidly. What are the considerations you need to do that, although they are beyond the basic tasks of migrating subscribers from PNFs to VNFs, are critical to the success of a migration?

When they first earned their fame for automotive excellence, Ferrari engineers were singularly focused on designing magnificent cars. It was up to the mechanic to figure out how to change the spark plugs without having to remove the engine entirely from the car. A similar thing happens in technology. Engineering is focused on bringing a product to market on time, with a distinguishing set of features, at a competitive price. The give and take between those three requirements leaves little room for considerations about maintenance, much less migration.

Besides, it's always assumed that maintenance will be handled by tools, and migration will be managed by the support organization.

Although true, it's not the whole story. The world of technology is full of horror stories about migrations, carried out by experts, that went terribly wrong. Migration is not simply a task that can be outsourced or delegated and forgotten about—particularly if it involves a paradigm shift.

Migration from physical to virtual network functions

This is particularly true of a migration from physical network functions (PNFs) to virtual network functions (VNFs).

To begin with, most telecom operators are still structured to support siloed physical network functions. They are not prepared for VNF's agile business model in which new services are launched rapidly, combined with third party services, scaled up for a particular event, and scaled back down after the event. Testing models, billing, procurement, management, and staffing are all optimized for PNFs.

If migration is simply outsourced to the lowest bidder, it's unlikely that these structural issues will be addressed. The result will be a functioning new technology with advantages that are not reflected in the bottom line of the business because they're mated to an old organizational structure

Performance characteristics and impact

Another critical factor to the success NFV is knowing which capabilities you need to keep and which capabilities you need to replace. For instance, any VNF that replaces a PNF will need to retain the original PNF's performance characteristics. Likewise for reliability, availability, and security. However, because all VNFs will run on a single infrastructure, a management platform that can orchestrate workloads in the most efficient way horizontally across the infrastructure becomes critical. Access to different parts of the multi-tenant infrastructure is likewise critical. As are governance an automated policy enforcement.

These are just some of the considerations that, although they are beyond the basic tasks of migrating subscribers from PNFs to VNFs, are critical to the success of a migration.

At Ericsson we recommend that you partner with a trusted support organization that has experience in PNF to VNF migrations and who will, above all, take the time to find out what your specific needs are.

However, that partnership and the migration will proceed much more smoothly if you understand not only the migration steps, but the larger organizational factors that are essential for the success of your NFV transformation.

To that end we've written an eBrief, the 8th in a series, to highlight the factors we think are most important to get right in a migration from PNFs to VNFs.

Download eBrief

Read previous NFV eBriefs.

Tags:
Build your cloud and NFV infrastructure Prepare your core network Inspiration & knowledge

Rick Ramsey
Follow Rick Ramsey:

Rick Ramsey

I started my high tech training as an avionics technician in the US Air Force. While studying Economics at UC Berkeley, I wrote reference manuals and developer guides for two artificial intelligence languages, ART and SYNTEL. At Sun Microsystems I wrote about hardware, software, and toolkits for developers and sysadmins, and published “All About Administering NIS+.” I served as information architect before joining BigAdmin, which morphed into the Systems Community at Oracle. I left Oracle in May of 2015, and now write for Ericsson.