When and how to virtualize networks

Virtualization of network functions – known as NFV[1] – is now mature and has demonstrated its advantages: reducing time to launch new services and optimizing CAPEX and OPEX. Thus, the question that arises for operators is no longer “should I virtualize? but “when and by what approach?” “.

The virtualization of network functions requires significant investment in the infrastructure since virtualized software functions require new, also virtualized, servers (IaaS), which the operator may not have or may not have in sufficient quantity.

To switch to NFV, the operator will ask three key questions.

1. Can network virtualization meet my challenges?

The benefit of network function virtualization depends on both the type of function considered and the nature of the investment expenditure that the operator must make to transform its network and develop its business. There are 3 possible scenarios with more or less triggering contexts.

First scenario, the operator is faced with the need to renew, update, or even acquire essential and costly functions which therefore require significant investment expenditure:

• either because major software such as EPC[2] or IMS[3], becomes obsolete and no longer receives vendor support;
• or because the operator needs to increase their capacity;

The operator cannot afford to invest massively in a technology with no future. He needs virtualization.

• or because the operator has identified a business need and wishes to position itself as soon as possible on a new growth driver: for example, the launch of the VoLTE.

In these three cases, the time has come for the operator to invest in virtualized network functions.

Second situation for the operator: some of its less expensive network functions, such as AAA or DNS functions, become obsolete or reach full capacity. To limit its capital expenditure, the operator may choose to renew these functions identically on its current technology and defer its investment in virtualized software and servers by 1 or 2 years.
However, if the operator already has the infrastructure capable of hosting virtualized functions, it may have the opportunity to accelerate its transition to virtualization.

In all cases where the operator has recently invested in its network software, and in the absence of triggers as described above, the transition to virtualization is not justified in the short term.

2. How should networks be virtualized?

Once it has identified situations conducive to virtualization, the operator must structure its approach over the medium term. There is no standard virtualization approach applicable worldwide. Each operator has its market specificities, business ambitions, budgetary and operational constraints that must be studied in detail using a rigorous methodology.

Leading the transformation of a network means building a master plan over several years comprising mainly:

• A state-of-the-art report on the operator’s network, including identification of the functions that are candidates for virtualization.
• A transformation plan giving a vision overall network and a detailed roadmap.
• A budget assessment with prioritization investments.
• Analysis of profitability and optimization of CAPEX and OPEX.
• A program governance framework.

3. How do I build my infrastructure as a service ?

The infrastructure hosting virtualized network functions is closely linked to the operator’s cloud strategy, i.e. its migration strategy to a virtualized infrastructure (IaaS) as well as its telecom/IT convergence strategy.

Two options are available to the operator to build the IaaS infrastructure on which virtualized functions will be deployed.

The infrastructure of the network function provider

Either the operator adopts an infrastructure provided by the seller of the network function. The supplier then designs, builds, and deploys the solution integrating hardware and software. In this case, the operator may choose to delegate certain responsibilities to this seller, such as:

• end-to-end solution deployment,
• solution operations and maintenance.

This option relieves it of significant engineering investments and limits its operational risks. The disadvantage is owner confinement: it will be very difficult for the operator to have functions offered by competing sellers deployed on these infrastructures. Even if it selects several suppliers to maintain a certain independence, it risks falling back into the silo operation to which it seeks to escape by virtualizing. It may make CAPEX savings in the short term but risks losing financially in the medium term.

An open source infrastructure

Or it chooses to build its own infrastructure based on Open Source bricks. Then, it is the operator who engineers the solution, chooses its hardware components and coordinates the deployments of the functions that it has selected with each supplier.

No more problem of owner confinement, but prerequisites that are not within everyone’s reach. Indeed, the operator must have the resources necessary to implement this model: a substantial budget, engineering teams capable of designing the infrastructure and defining a solid operational model with clear responsibility matrices, operating teams integrating network experts and IT experts.

Defining what, how and when virtualization requires, on the one hand, structuring the transformation of the networks over time using a master plan, and, on the other hand, defining the infrastructure that will host the functions.
The selection of the functions to be virtualized and their sequencing will be based on different criteria, including obsolescence, capacity needs, or the launch of a new service, and the investment period.
The choice of infrastructure will depend on the strategic ambition of the operator to evolve in the more or less long term towards IaaS and telecom/IT convergence. Two other parameters will also guide its choices: its budgetary capacity and the target operating model best suited to its situation.