Why Operators Virtualize: From Dedicated Cabinets to Standard Servers

For a long time the core of a mobile network was built like this: one function, one cabinet with the manufacturer's boards. It is reliable, but expensive and slow. In this lesson we look at what is wrong with that approach, what idea the operators proposed, and how a simple calculation shows the gain: six cabinets can be replaced by three servers. The idea is called NFV — Network Functions Virtualisation.

Goal and prerequisites

After this lesson you will be able to:

• explain how the core network was built before and why every function had its own spare capacity;
• say in plain words what NFV is and how a "function as a program" differs from a "function as a cabinet";
• name the benefits of NFV and three risks to think about in advance;
• calculate how many servers of a shared pool replace a set of cabinets at a given load;
• name the document and the year that started the work on NFV.

What you need to know first: course ipnet, lesson 1 (why voice and signalling moved to IP); course lte, lesson 6 (core equipment as cabinets with boards); course ims, lessons 1 and 13 (why IMS exists and how its functions look in real equipment). You already know the MME, S-GW, P-GW, HSS, PCRF and CSCF nodes — here we look not at what they do, but at where and how they run.

A real-life task

A small operator is preparing for New Year. On New Year's night the number of calls and SMS grows noticeably, but only for a few hours. The core nodes — MME, S-GW, P-GW, CSCF, HSS and PCRF — each stand in a separate cabinet. The capacity of a cabinet cannot be raised in a day: you must order boards from the manufacturer, wait for delivery, install and configure them. So every cabinet is bought at once with a reserve for the heaviest evening of the year.

The rest of the time that reserve sits idle, and the operator pays for it, for the floor space and for the electricity. The question of the lesson: can it be done differently — so that the reserve is shared and new capacity appears without ordering and installing a new cabinet?

How the core was built before

Every network function is a job that a node performs. The HSS stores subscriber data, the MME follows subscribers as they move, the CSCF manages sessions. Before, each such job got its own dedicated hardware (also called purpose-built hardware): a cabinet assembled by the manufacturer for one task, with its own boards, its own housing and its own firmware.

This approach has four features:

• Its own spare capacity. A cabinet is sized for the peak load of its function. The reserve of the neighbouring cabinet cannot help it.
• Its own spare parts. MME boards do not fit a CSCF, so the warehouse holds a set of spares for every cabinet type.
• Its own purchase cycle. New capacity means order, manufacture, delivery, installation and configuration.
• Its own lifetime. After a few years the cabinet becomes obsolete and everything must be repeated, although it brings almost no new revenue.

The operators themselves wrote about these problems in 2012: the variety of "boxes" grows, there is not enough space and power for them, and the life of the equipment gets shorter.

The idea: a function is a program

What does an HSS cabinet actually do? It runs a program written for its boards. The idea is to detach the program from a particular box: a network function is a program that can be started on an ordinary server.

A server is a computer without a screen and keyboard that works around the clock and answers requests from others. Such servers are made in large numbers for banks, shops and universities. In telecom they are called commercial off-the-shelf (COTS) servers — standard general-purpose servers. Synonyms: standard server, ordinary server, COTS server.

If all servers are the same, they can be put together into a shared pool — a common reserve of capacity. Any function takes from it as much as it needs now and gives it back when it does not. How several functions live on one server without disturbing each other is a separate topic. For now it is enough to know that a server can be divided into several independent "software copies of a computer", and each one hosts its own function.

What is NFV

NFV (Network Functions Virtualisation) — an approach in which a network function stops being a separate "iron box" and becomes a program that can be started on standard general-purpose servers from a shared pool.

Synonyms and spelling: NFV = Network Functions Virtualisation = virtualisation of network functions. ETSI documents spell the word with an "s" (Virtualisation), in the US it is written with a "z" (Virtualization); it is the same thing. "Virtualisation" here means exactly detaching a function from specific hardware.

Analogy 1: a kitchen. Before, every appliance had its own place and its own plug: a separate coffee machine, a separate kettle, a separate toaster. Now it is one kitchen where any appliance plugs into a shared socket. You can replace an appliance or add a new one without rewiring.

Analogy 2: a car-hire fleet. If every family keeps its own minibus by the house for a couple of trips a year, it stands idle most of the time. A hire fleet works differently: you take a car when you need it and return it. A pool of servers is such a fleet.

Let us compare the two ways of working:

Benefits and the price of the move

Benefits:

1. A shared pool instead of a reserve for every function. The peaks of different functions do not have to coincide in time, so the shared reserve can be smaller than the sum of separate reserves.
2. A fast start of a new service. No waiting for a cabinet to be delivered: the program starts on a server that is already in the pool.
3. Scaling by software. Scaling means increasing or decreasing capacity to follow the load. With NFV you start one more copy of the program or stop an extra one.
4. Fewer hardware types. One server type and one set of spares instead of a dozen different cabinets.

The price and the risks:

1. Voice and video performance. A media stream is a great many small packets per second. A special board copes with it on its own, while an ordinary server shared with neighbours finds it harder. How this is solved we will see in the next lessons.
2. Integrating several suppliers. The function from one supplier, the servers from another, the management from a third. Questions appear at the joints: who is responsible when something does not work?
3. New skills. An engineer who knew boards and cables now also needs skills in working with servers and automation.

💡 NFV does not make a function better. It stays the same function, with the same messages and nodes. What changes is what it runs on and how.

Worked example: how many servers the pool needs

Conditions of the learning model:

• six cabinets: MME, S-GW, P-GW, CSCF, HSS, PCRF;
• the average load of each is 30%;
• one pool server equals one cabinet in capacity;
• the target server load is 70%: this means 30% of the capacity stays in reserve for surges.

Load is the share of its capacity that a device uses. 30% means it works at a third and the rest sits idle. Target load is the level up to which a server is planned to be filled.

servers = ceil(cabinets × load / target)

Here ceil means rounding up. Step by step:

total load = 6 × 30% = 180%   (1.8 cabinets' worth of work)
servers    = 180% / 70% = 2.57
servers    = round up -> 3

We round up: you cannot buy two and a half machines, and two servers would carry 180% / 2 = 90% — above the target. Check: on three servers the load is 180% / 3 = 60%, which is not more than 70%. Result: three servers instead of six cabinets.

This is a simplified model. A real pool is sized by the peak load, not the average, and gets a spare server in case of a failure. But the principle is the same: the reserve is counted once for everyone.

Compare how a service used to be launched:

cabinet: order -> build -> ship -> install -> configure -> launch
pool:    pick free server -> start program -> configure -> launch

What matters is how many stages disappear: no manufacture, delivery or installation of a new cabinet.

History: where the idea came from

In October 2012 a group of network operators published a white paper (a document in which industry players set out their position and call for joint work) titled "Network Functions Virtualisation – An Introduction, Benefits, Enablers, Challenges & Call for Action". Its author list contains 13 organisations. The text set out the benefits and the difficulties and called for international collaboration.

In November 2012 the European standards institute ETSI created the working group ISG NFV (Industry Specification Group), which, according to ETSI, was founded by seven major operators. One of this group's documents is ETSI GS NFV 002 (its first version came out in 2013).

These are name labels: remember them as "who, when and what was published". No details are needed.

What can go wrong and how to find it

⚠️ A typical mistake is to think that "virtual" means "free and unlimited". Behind the pool stand real servers, floor space and electricity, and the pool is finite too.

Practice

1. Predict. The six cabinets are loaded not at 30% but at 50%. Will the pool need more or fewer servers than in the worked example? Do not calculate — name your answer by eye.
2. Check. Calculate 6 × 50% / 70% and round up. Did it match your guess?
3. Explain. Why can a pool of three servers serve six functions, although each of them used to occupy a whole cabinet?
4. Change. Six cabinets at 30%, but the target server load is 50%. How many servers are needed?
5. Do it yourself ⭐. Eight cabinets with an average load of 25%, target load 70%, one server equals one cabinet in capacity. How many servers are needed if you add one spare in case of a failure?

Self-check

Question 1. An operator bought a new cabinet with boards for the S-GW from the manufacturer. Is this NFV?

Explanation. No. The function is still tied to special hardware, with its own reserve and its own purchase. With NFV the same function runs as a program on standard servers from a shared pool.

Question 2. Why are there fewer servers in the pool than cabinets, although the total work is the same?

Explanation. In the cabinets the reserve was planned for each function separately, and most of it sat idle. In the pool the reserve is shared: you add up the total load (180%) and divide by the target load (70%). You get 2.57, so three servers instead of six cabinets.

Answers to the practice. 1 — more: the load is higher at the same target. 2 — 6 × 50% = 300%, 300% / 70% = 4.29, rounded up to 5. 3 — the reserve in the pool is shared instead of separate for every function, and the peaks of functions do not have to coincide. 4 — 180% / 50% = 3.6, up to 4 servers. 5 — 8 × 25% = 200%, 200% / 70% = 2.86, up to 3 servers; plus one spare is 4 servers.

Review and the criterion for moving on

Move on to the next lesson if, without hints, you can:

• explain how a "function as a cabinet" differs from a "function as a program" and what NFV is (with its synonyms);
• list the four benefits and the three risks of the move;
• calculate the size of a pool with the formula servers = ceil(cabinets × load / target), where ceil means rounding up;
• say what the operators and ETSI published, and when, in 2012.

Next. In the following lessons: how a data centre is built, the hypervisor and the virtual machine, the OpenStack platform, and then VNF, MANO, and containers with Kubernetes.

Standards and sources

• A group of network operators (13 organisations), Network Functions Virtualisation – An Introduction, Benefits, Enablers, Challenges & Call for Action (white paper, Issue 1, October 2012); the text is hosted on the ETSI portal: portal.etsi.org.
• ETSI GS NFV 002 — a document of the ISG NFV working group (the name only; first version — 2013).
• ETSI, "10 years of ETSI NFV" — on the creation of ISG NFV in November 2012: etsi.org.