Your Network's Edge®
Blog Post
You are here
5G - whichever way you slice it
Jun 24, 2019
In the last installment I endeavored to convince you that a lot of what you have heard about 5G is both technologically plausible and has real-life application. The higher data rates, enhanced connection densities, lower latencies, and higher reliability all enable real applications, and are all technologically realizable.
However, can 5G technologies really deliver on all of that? Yes and no. Each of the characteristics can be obtained, but maybe not all of them at the same time. But that’s OK since 5G was designed to enable applications, and each application has its own requirements and non-requirements. Viewing videos may require huge downstream bandwidth, but it doesn’t require low delay or above average reliability. V2V may require low delay and ultra-reliability, but doesn’t require much bandwidth.
So, it turns out that even if the technologies being developed for 5G will not enable simultaneously attaining gigantic bandwidth, super-low delay, and ultra-high reliability at the same time, they can still support each of the targeted applications.
One network to rule them all
But there is still potentially a problem here. Even if no single application requires pushing the boundaries of what is possible, we still want to simultaneously support all of these applications on a single network, i.e., a common air interface, a single backhaul, and a single mobile core. We don’t want each application to require its own resources, breaking down the unified 5G picture into a large number of unrelated technologies.
That’s why 5G defines network slicing. Network slicing is a tool to offer multiple isolated networks, customized for diverse use cases, which all share the same underlying resources. Recognizing that while it might be possible, but would not be economically feasible, to create the desired networking from completely physically isolated computing and network resources, network slices are understood to be logically (i.e., virtually) isolated.
The 3GPP differentiates between different slice types using a Slice/Service Type (SST) which can be further differentiated using a slice differentiator (SD). To date three types of slice have been defined:
| SST=1 | eMBB | suitable for general consumer high data-rate traffic, such as high quality video |
| SST=2 | URLLC | suitable for ultra-reliable low-latency applications, such as factory automation and V2x |
| SST=3 | mIoT | suitable for cost-effectively supporting a huge number of IoT devices |
The separation of a physical network into virtually isolated ones is well known to readers of this blog. We have been doing this for years using VLANs and VxLANs and VRFs and EVCs. How is network slicing any different?
Full isolation
In the past virtual isolation merely meant separation of traffic from different users. For example, a VLAN is a virtual instance of a LAN in the sense that if an Ethernet frame is flooded, it is only flooded inside the VLAN. There was never any expectation of any stronger sort of isolation, such as encryption in case a packet is (e.g., due to misconfiguration) forwarded outside the VLAN. There was certainly not any performance isolation – if one VLAN causes congestion in a switch then it may be felt by other VLANs traversing that switch. So, isolation was in reality best effort isolation (although service providers never admitted that to customers). In many cases the whole idea of VLANs being separate networks was a bit farcical, since many control or management entities dealt simultaneously with many VLANs.
In contrast to VLANs, network slices are truly separate networks. Each slice has its own forwarding, control, and management entities (with only the slice orchestration and classifiers in common). This is facilitated by the use of virtualized network functions (e.g., vrouters).
Network slices are also truly separate networks regarding fault management and performance. The behavior of one slice must have any effect on the performance of other slices. Once again, this is facilitated by the very nature of independent VNFs (although, physical network element failures may impact multiple slices). In extreme cases a particular slice may require dedicated physical elements (i.e., true physical isolation), but while not ruled out, this is expected to be an uncommon scenario.
Dynamic behavior
VLANs were never expected to be dynamic – in fact in enterprise environments it was common to allow months for a service provider to set up an EVC, and once up, such an EVC was expected to live for years. Set-up was often mostly manual with ticket creation in various departments, and commissioning testing that could be performed for days before fulfilment.
In contrast to VLANs, network slices are dynamic entities, set up and torn down on-demand in fractions of a second. In order to accomplish this slicing employs SDN and modern virtualization technologies.
The best way of internalizing the importance of network slices to the 5G architecture is to think of a service as being defined by its end-user's business logic, and the slice as the set of physical and virtual resources that realize this logic. Instantiating a service on-demand means locating and dedicating a set of resources that fulfils the requirements, and configuring these resources according to service attributes.
One tenet agreed upon by all is that network slices need to be programmable and to be able to expose their capabilities. The 5G core Service Based Architecture (SBA) contains a Network Slice Selection Function (NSSF) capable of selecting of the slice instances, determining their SST and SD, and interacting with all the rest of the network functions. The setup process is normally triggered as part of the registration procedure by the first Access and Mobility Management function (AMF) that receives the registration request from the UE. The AMF retrieves slices accessible to the user and by interacting with the NSSF selects the most appropriate slice instance.
More generally, any slice orchestrator needs to minimize service provider costs under the constraints of guaranteeing the promised attributes. Modern optimization software can carry out such planning tasks in fractions of a second, enabling greater energy efficiency and reduced costs. When powered by state-of-the-art AI/ML engines they may even operate when the tasks and the goals are incompletely defined.
That does compute
VLANs provided pure transport services, while modern services are bundled transport and computation services. So, network slices are comprised of virtual network and computational resources, and even storage may need to be mixed in. For this reason the NFV ISG has become interested in network slicing, and recently created a working group to address the relationship between NFV and 5G network slicing concepts.
Building on what we have previously defined so far, a network slice is a set of resources, both physical (switches and servers) and virtual (network and application functions). Thus, not only are applications seen by the end-user part of the slice, but so are network functions that serve the network operator (e.g., DPI, OAM, diagnostics, analytics, vEPC), and even virtualized lower layer functions (such as functions belonging to the 5G base station itself).
As an example, consider a hypothetical case of a terrorist spotted walking the streets of a major city. For privacy reasons this city does not continuously monitor all the connected cameras, nor does it routinely deploy face recognition software; however, in such an emergency the temporary invasion of privacy is warranted. A slice is set up and the face recognition software installed close to where the terrorist was last seen, perhaps pre-empting existing functionalities of lesser importance. The camera video is streamed to the deployed software until a hit is observed. The video if streamed to police headquarters, and the authorities can follow the terrorist as he moves around the city. Once apprehended, the face recognition software is uninstalled, any pre-empted applications reactivated, and all unnecessary information wiped.
Can I have another slice?
Once end-to-end slicing is fully implemented, the mobile operator can offer slice as a service. For example, an MVNO may build a consumer service based on leasing an eMBB slice from a mobile operator. An enterprise customer may wish to lease slices with several QoS mixes to connect its branches to its private data center. An electric utility may contract a long-term URLLC slice lease for its smart grid, while a rock band may take a one night lease, optimized for HD streaming for a performance.
To sum up
I hope that I have convinced you that network slices are different from previous virtual networks, and that the difference is just what is needed in today’s varied and dynamic world, and specifically for 5G. Although the fundamentals are now well understood, the mechanics are still evolving, and you can expect to hear more about the slicing story as the technology develops.
About RAD's Blog
We’ll be blogging on a wide range of hot topics affecting service providers and critical infrastructure network operators. Our resident experts will be discussing vCPE, Cyber Security, 5G, Industrial IoT and much, much more.