Slicing Challenges for Operators

Introduction

An initial idea of network slices in standardization¹ was introduced in 2011 by the ITU-T (ITU-T, 2011) in the form of logically isolated network partitions (LINP), with a slice being considered as a unit of programmable resources such as network, computation and storage. Later, in 2016, the concept of network slicing has been formulated by the NGMN in (NGMN, 2015) as an enabler for (hopefully) achieving an efficient logical division of network resources (either physical or virtual) and service functions for different services on the same network infrastructure. The concrete settings of resources and service functions are selected and combined together with the aim of supporting a specific application or type of service.

The different types of services are in principle the ones under consideration for 5G services, as introduced in (ITU-R, 2015). These are the enhanced Mobile Broadband (eMBB), massive Machine-Type Communications (mMTC) and ultra-Reliable and Low Latency Communications (uRLLC). The eMBB service type encompasses the challenge of providing an extremely high volume of delivered data, due to e.g., (ultra) high-definition video sharing. The mMTC kind of service focuses on applications where a large number of connected IoT devices, such as sensors, representing a large number of sessions collectively create a significant amount of data passing through the network. Moreover, these data are often associated with requirements like privacy, data ownership, etc. Finally, the uRLLC type refers to services that require extremely low end-to-end latency, like Tactile Internet, Interactive Gaming, Automotive, or Industrial Automation. Figure 1 summarizes some characteristics of each type of service.

Figure 1.

Characteristics of different kinds of 5G services

Combining services like eMBB, uRLLC, and mMTC on the same network, makes it quite difficult to define a common engineering pattern capable of supporting simultaneously all the requirements of each of them. An approach to manage such deployment needs is to segregate those services into specialized network partitions or slices, designed, and optimized for each of the types of services to be provided.

Each slice is then tailored to such specific purpose, thereby avoiding unnecessary capabilities (for example, an instance of a mMTC slice may not require a TCP optimizer function, whereas an instance of an eMBB slice may need to invoke this capability). This form of flexible network resource consumption opens possibilities of new business models for network operators. However, the associated challenges are not minor, as described along this chapter.

Figure 2 provides a high-level overview of the slicing concept. Through the instantiation of distinct network slices, the operator will be able to provide completely different services in a dynamic and isolated manner despite that all of them actually run over the same physical infrastructure. Thus, the operators can initiate a transition from the existing design choices that rely upon multi-service networks deployed over one architecture conceived to fit all kinds of services (Doverspike, Ramakrishnan, & Chase, 2010), towards the approach of getting logical networks defined per service.

Figure 2.

Network slicing concept

Network slices are intended to behave like entirely independent networks. This implies that there should be mechanisms for properly isolating the slices (if required by the slice definition), thereby avoiding interference between one slice and the others. Furthermore, in some cases, there will be situations that will require that some of the slices to be interconnected to compose a service, raising the need for interworking (stitching) such independent logical constructs.