Network slicing has long been proposed as the mechanism enabling multiple use cases to coexist over a common physical network, with each allocated the resources and QoS it needs under distinct SLAs (service level agreements). 5G has three broad service classes, defined by overall traffic and user characteristics – uRLLC (ultra-reliable low latency communication) for minimum delay; mMTC (massive machine-type communication) for high IoT device density at low speed; and eMBB (enhanced mobile broadband) for high speed and capacity.
All three of these have roots in 4G through early deployments, with a degree of customization available through features such as access point names (APNs) and Multi-Operator Core Network (MOCN). But the focus under 4G was primarily on eMBB – to provide a compelling mobile broadband experience supporting data rates good enough for high definition video streaming, for example. Applications under the Industrial IoT (IIoT), calling for ultra-low latency, tended to be deployed on dedicated infrastructure at considerable cost. The objective of network slicing under 5G was to consolidate as many applications as possible over a single physical infrastructure to gain scale economies and flexibility.
Network slicing can be seen as the equivalent of virtualization, divorcing higher level processes from underlying hardware infrastructure. But over 5G it has to span all components along an end to end communications path including RAN, backhaul and core, which is why the concept of slice was introduced. But the slicing alone cannot guarantee that the infrastructure actually has the resources and capabilities to meet all conceivable combinations of use cases.
For example, if there is high demand for ultra-low latencies driven by industrial processes, that would require additional edge compute power to perform the associated processing sufficiently close to the point of consumption. If on the other hand there was high demand for bandwidth in a given area driven by large numbers of users streaming 4K video, that might require more densification as well as extra backhaul capacity.
Then if there were large numbers of devices to be supported under the mMTC use case category, LPWAN protocols might need to be invoked in order to support sufficient numbers of links cost effectively. Network slicing oils the wheels but is not the engine.
In the core, additional server capacity can readily be made available, but the flexibility to meet varying demands across the three use cases requires a combination of NFV and software-defined networking (SDN)) to underpin network slicing.
NFV allows individual functions such as routing, intrusion detection and firewalling to be implemented as dedicated ‘software’ appliances on servers to give the required flexibility, so that computational resources can be switched between them readily. SDN separates the higher layer slicing from those underlying processes to facilitate the operational control.
SDN and NFV are then essential components of a flexible 5G infrastructure capable of supporting all three use cases cost effectively and scalably through network slicing. But they are not sufficient on their own. Operators will require a coherent strategy for evolving their infrastructures in line with expanding and changing demand across each of those use cases, focusing on the RAN, backhaul and core.
In the RAN, eMBB calls for high spectral efficiency as well as support for high frequency millimeter wave bands. The uRLLC in turn requires very low deterministic latency and low error rates, exerting huge pressure on fronthaul whichever medium is employed.
The mMTC use case requires low transmit power and ability to support large numbers of devices simultaneously. There are particular challenges at the RAN level when a large family of devices requires access asynchronously at random times to transmit small data payloads in a transactional way. The sporadic access means that there is at any one time a random subset of devices active. This in turn requires some form of random access protocol that prevents the RAN being swamped by large numbers of small transmissions, choking more time critical applications under the other two use cases.
The backhaul will be largely driven by capacity and performance, so that could be determined particularly by the eMBB demand, although latency could also dictate whether fiber is deployed in situations where microwave might otherwise be favored. In the core, latency considerations could determine where hardware is located, while eMBB would dictate capacity and performance.
For the mMTC case more attention has been paid to the RAN than the core, but a point to note is that there are big differences between individual mMTC applications, with some generating larger amounts of data and others involving many more devices in the millions across a relatively small footprint.
A few require low latency, but most are less delay-sensitive. This will require support for end to end protocols that can handle the different scenarios, while ensuring that time critical processes are prioritized and protected from negative impact. Network slicing will only enable that if the underlying infrastructure has been designed correctly.