5G – the software variable network

Network Slicing will require automated network orchestration to provide service assurance within and between slices.

This guest post from TEOCO’s Thomas Neubauer says that network slicing will underpin the ability of 5G networks to support new service models, requiring new approaches to service assurance and orchestration to deliver the software variable network.

What sort of network do you want?

5G networks – or at least those built to match the full 5G standard that is scheduled to be ratified in the second half of 2018 – will be capable of ‘network slicing’. Network Slicing will enable the same network resources to support different types, or classes, of services.

In this way, 5G technology promises to be very different from all of its predecessors. At its heart, a 5G network will be a programmable network, capable of delivering different things to different customers at the same time, over the same infrastructure.

Verizon in the USA has already launched its first 5G network in Michigan and plans to roll 5G out in ten trial locations. The Michigan network is an example of a 5G network built to meet a specific use case – delivering high speed fixed wireless backhaul infrastructure as an alternative to laying fibre cables. Verizon is one of 18 network operators committed to launching 5G services ahead of the final standards ratification.

The 5G new radio “non-stand-alone” standard is targeted to be finalised in the first quarter of 2018 – expect that to be confirmed at next year’s Mobile World Congress Barcelona; but the full 5G new radio “stand-alone” standard is not due to be ratified until the third quarter of next year at the earliest.

So while Verizon, and others, will be demonstrating how good 5G can be at targeting individual use-case scenarios, it won’t be until after the stand-alone standard is published (the completion of what is called “Release 15”) that we will be able to unleash the full network slicing capability of 5G.

Beyond NFV and SDN

Network slicing will be key in delivering the ‘network as a service’ movement. In part, it will be enabled because of the quickening move towards network function virtualisation (NFV) and software-defined networking (SDN) – but it’s a development that takes that concept even further and adds a new requirement onto the network management and orchestration system.

For example, in a network slicing environment, each slice can be configured with its own network architecture, engineering mechanism and network provisioning. In effect, each one becomes its own mini-network, requiring many of the same OSS/BSS support systems of the main network.

For example, one slice of the network might be devoted to connected cars while another is running an IoT application such as connected power meters. Very different standards of service are required for these two distinctly separate moving and non-moving applications.

We have been looking at how the network could monitor the health of a network slice against some pre-determined KPIs and make adjustments accordingly

Service assurance in a sliced network

That’s why we have been working in TM Forum catalyst group looking at how to deliver service assurance for individual applications sharing the same cell site but in different slices. In particular, we have been looking at how the network could monitor the health of a network slice against some pre-determined KPIs and make adjustments accordingly.

In this example we concentrated on the connected car market. Cars speeding along the motorways and highways will be sending and receiving vehicle to vehicle, vehicle to infrastructure and vehicle to network messages covering everything from road and weather conditions to engine temperatures and fuel consumption, while consuming broadband infotainment content. But when an accident or some other incident causes a long tail back, the concentration of connected cars in the network slice greatly increases compared to the expected demand and thus the situation changes dramatically.

The heavier load would raise an alarm against the KPIs as the quality of service being provided would have dropped. The network management system, or orchestrator, would be able to automatically respond to the fall in network performance by increasing the connected car slice to maintain service assurance – reducing the size back to its standard level when traffic returns to normal.

For this to happen successfully, the network orchestration system needs to be automated not only within the slice, but also co-ordinated across the entire mobile network.

These are being termed ‘closed-loop operations’ where the network is effectively able to heal itself and react to changing conditions in multiple industry verticals at the same time. This is more than a standard software-defined network, this is a network that is programmable and can be software-variable.

For this to happen successfully, the network orchestration system needs to be automated not only within the slice, but also co-ordinated across the entire mobile network. This ensures that the network load is balanced and that service assurance is maintained for all verticals and their different requirements.

This ability to slice the network into service segments opens up the potential for operators to develop and market new value-added services in network slice segments. That, in turn, will be underpinned by a programmable network that leverages automated, closed loop, assurance and optimisation to deliver the software variable network. 

By Thomas Neubauer, Vice President, Business Development & Innovations, TEOCO.