Network slicing is a 5G cutting-edge technology, which is able to create multiple types of virtual networks, tailored to accommodate different requirements for several use cases and verticals, on top of a common physical infrastructure.
Currently, operators need to build completely independent and siloed networks for different purposes. As an example, operators providing LTE for Internet broadband services cannot accommodate properly the requirements for IoT devices (e.g., smart meters), and they need to create IoT specific networks, such as Sigfox, preventing synergies among them.
In the future, using network slicing technologies, operators will be able to rely on a shared physical infrastructure to create multiple network slices that fit with the characteristics required by different use cases and vertical industries. For instance, an IoT slice does not need large bandwidth or mobility support, but it requires low signaling levels to reduce energy consumption. On the other hand, augmented reality requires highly distributed network nodes to reduce latency, ensuring a correct overlapping of virtual objects over real images.
Virtualization technologies are underpinning the 5G network slicing concept, fostering the ability to create networks in a very flexible manner. The slice life-cycle can be managed as any other virtualized networking entity (e.g., NFV), allowing operators to easily create end-to-end networks by combining virtualized network components.



There are multiple Standards Developing Organizations (SDOs) addressing the network slicing topic, describing the concept, identifying use cases and proposing architectures for different environments. The most relevant contributions (without any particular order) come from 5G Americas, NGMN, 3GPP, ETSI NFV and ONF.

5G Americas was one of the first organizations to publish a document with a clear view about network slicing. In [5G-Americas], 5G Americas refer to the use of network slicing as a way to provide flexibility on 5G networks, highlighting the big diversity of devices to justify the need to create multiple networks with different characteristics.
The ability to create and manage network slices in an agile manner is of paramount relevance. 5G Americas establishes a clear mapping between the ETSI NFV framework and slicing, considering that a network slicing can be built by combining multiple networks services (NSs), which in turn will use Virtual Network Functions (VNFs). This mapping would be described in a template.
In this sense, 5G Americas defined the Network Slice Life-Cycle Management component, which relies on the management on the underlying NSs. Physical network functions (PNFs), such as radio elements (e.g. eNBs), are a special case as they need to be shared among multiple network slices. The following Figure depicts this view.


Figure 1 – 5G Americas Network Slice Life-Cycle Management. Source: [5G-Americas]


NGMN (Next Generation Mobile Networks) has also been working on network slicing for a long time, having released several documents on this topic and significantly influenced the 3GPP 5G standardization.
In [NGMN-Concept], NGMN describes his view on network slicing, identifying a 3-layer perspective: the resources layer, the network slice layer and the services instances layer (see the Figure below). In this perspective, network slice instances are built by the combination of sub-network instances, eventually shared among multiple network slices. To describe this mapping, NGMN uses network slice blueprints (templates). On top of a network slice instance, multiple service instances can run (typically, verticals with similar characteristics).


Figure 2 – NGMN 3-layered perspective [NGMN-Concept].

In [NGMN-Arch] and [NGMN-WhitePaper], NGMN elaborates on the 5G end-to-end architecture, focusing on multiple-domain and multiple-administrative-domain environments, where a network slice can be built by combining pieces coming from different domains (see the Figure below). For NGMN, the dynamicity of the network slice instances (fast creation, scaling, termination, etc.) is of high value and will strongly leverage new use cases.

Figure 3 – NGMN view on multiple-administrative-domain environments [NGMN-Arch].


3GPP is the organization responsible for the specification of 5G. 3GPP started the study of the network slicing topic [3GPP-TR28.801], making a survey on the different slicing models and how they can apply to 5G networks. For 3GPP, network slicing will be an embedded feature.
3GPP defined three network slice types, based on the typical characteristics required for use cases and verticals: (1) eMBB (enhanced Mobile BroadBand), which is basically an extension of the 4G mobile broadband service; (2) URLLC (Ultra-Reliable Low Latency Communications), which provides low-latency and reliable communication; and mMTC (massive Machine Type Communications), which supports massive IoT devices with narrow bandwidth requirements.
Today, 3GPP is specifying the 5G architecture [3GPP-TR23.501] and procedures [3GPP-TR23.502]. 3GPP has designed the 5G Core with a NSSF (Network Slice Selection Function) component, with the particular purpose of slice selection. On 3GPP’s view, when a device attaches to the network, he gets assigned a particular slice type, according to his request and desired characteristics. Some complex devices may attach to multiple slices in case they require multiple characteristics (e.g. a car).
3GPP elaborates on how a slice can be built by using multiple Network Slice Subnet Instances (NSSIs) (e.g. RAN, 5G Core), reusing the NGMN naming, and combining them to create end-to-end slices with the desired characteristics (see the Figure below). 3GPP also considers the wholesaling option, where a Network Slice as a Service (NSaaS) model is used to create network slices that can be used by third parties Communications Service Provider (CSPs) to provide services to their customers (B2B2X – Business to Business to X).
It is important to remark that 3GPP has architected the new 5G Core to use a cloud-native approach, to take advantage of NFV and SDN technologies. For example, gateways are now stateless, which makes termination, scaling and migration operations easier, and the CUPS (Control and User Plane Separation) approach is used to align with the SDN model.

Figure 4 – 3GPP view on NSSIs combination to build a NSI [3GPP-TR28.801].


ETSI NFV has also approached network slicing in the 5G White Paper [ETSI-NFV-WhitePaper]. ETSI-NFV has created the NFV-EVE012 group to study the relationship between NFV and 5G network slicing concepts. As a result, the [ETSI-NFV-EVE012] document has been elaborated.
The ETSI NFV EVE012 document analyses the network slicing perspectives from NGMN, 3GPP and ONF, aligning mostly with them and trying to converge. It also makes a mapping between the NGMN and NFV concepts, comparing Network Slices and Networks Slice Subnets with NSs on the NFV framework, concluding that it makes sense to describe a Network Slice as a set of 1 or more NSs. Considering the traction and popularity of the NFV framework, this means that the NFV constructions can be reused of build networks slices. The following Figure depicts this model.

Figure 5 – ETSI NFV perspective mapping NGMN/3GPP Network Slicing and NFV concepts [ETSI-NFV-EVE012].

Although ETSI believes that most of the NFV features required are already available, they recognize that network slicing may require further evolutions, in particular, on resource isolation, multi-tenant, or security.
According to ETSI, the network slice Life-Cycle Management (LCM) functions will consume NFVO APIs for NS LCM, mapping network slices into networks services according to a Network Slice Template (NST). The slice management functions would be part of an OSS functional area, and standardized on top of NFV.

The ONF (Open Networking Foundation), which is responsible for the development of SDN technologies, has also approached the network slicing topic in the 5G context in [ONF-5G]. ONF takes the NGMN definitions and claims that the SDN architecture already provides the foundations for a common infrastructure to efficiently support multiple network slices on top. ONF claims that SDN controllers already provide a significant level of abstraction and isolation, as well as the agility required for 5G network slicing.


Life-Cycle Management

The network slice LCM is an important topic as it provides to the network slice the ability to be agile, facilitating the creation of slices, as well as ob-boarding, scaling, healing, modification, or termination, among others.

The network slice is firstly defined using a Network Slice Template (NST), sometimes also referred as blueprint, which is a descriptor where the network slice characteristics are described. In particular, it describes the list of NFV components (NSs) that need to be instantiated to set up a network slice instance, as well as other information, such as flavors, configurations, Life-Cycle stages, actions, monitoring, policy, SLA, etc. This descriptor has to be written in a human/machine readable language, such as TOSCA. Once the NST is defined, it can be on-boarded on the Slicing Manager component.

Besides on-boarding, NSTs can be managed in other ways. They can be removes permanently from the system, and they can also be disabled/enabled as a way to temporarily disallow/allow the instantiation of networks slice instances (NSIs) based on this template. NSTs can also be modified or replaced by a new version.

Based on an on-boarded NST, multiple NSIs can be instantiated. When a slice instantiation is triggered, the Slicing Manager triggers the instantiation of the underlying NSs, combining those network services if necessary to form a large end-to-end network slice. The model this combination is generically specified is still unclear (e.g. VNFs are combined into NSs using forwarding graphs (FGs)). NSIs are independent from each other, isolating resources and appearing to the customer as traditional networks.

During lifetime, running NSIs can be scaled. In particular, they can be scaled out or scaled in, in case more or less resources and performance is required, respectively. The NSI scaling policies are defined in the NST and monitoring data can be used to take autonomous decisions. The scaling of a NSI is accomplished by scaling the underlying NSs.

Generally, other types of NSI modifications can be allowed, for example, to start or stop NSs, to change its configurations, or to add/remove some NSs. NSIs can also be subject of any modification in response to a self-healing action in order to recover from a failure.

During lifetime, running NSIs can be monitored in order to get slice-level monitoring data and manage the slice performance. This monitoring can contribute to trigger the scaling, healing or modification actions. NSIs can also generate alarms to alert for any failure.

Finally, NSIs can be permanently terminated, triggering the termination of the underlying NSs and consequently release resources. After NSI termination, all related NSI state and information will be lost.


Use Cases

The creation of multiple slices for different purposes within a single operator is probably the most typical scenario of network slice utilization (appear as an enhanced APN (access point name)). As 5G will cope with different device and service characteristics, it needs to be able to create different networks to accommodate them.

However, there is another scenario of network slice utilization, which is the creation of network slices to be used by 3rd parties: Network Slicing as a Service (NSaaS). These 3rd parties can be, for example, Mobile Virtual Network Operators (MVNO), which use the slice to provide communication services to their customers, or utility providers (e.g. electricity suppliers), which can use the slice to get metering data. In the latter case, the network can be very dynamic, e.g. building the slice once a month just to collect metering data.

As network slices are expected to behave like traditional networks, slice customers are willing to manage the network using traditional tools, such as, Network Management Systems (NMSs) or Monitoring, keeping away from their eyes the underlying NFV and cloud resources complexity. So, in addition to network components itself, NSaaS providers must supply the slice customers with the appropriated management tools.
NSaaS providers must also make available for slice customers a set of APIs with the ability to trigger network slice LCM operations, such as, instantiation of a network slice, modification of a slice, scaling, healing, configuring, or terminating.

It is a duty of the NSaaS provider to map the customer-facing network slice requirements into NFV requirements and, in turn, to cloud resources, assuring that this mapping accomplishes the contracted network level (customer-facing) SLAs.



The 5GTango project will develop network slicing features as part of the Service Platform (SP) “product”. The SP will be able to create NSTs, as well as instantiate multiple NSIs and perform other LCM actions, such as, NSI termination, scaling, or healing, among others.

The Slice Manager will be the component responsible to manage the network slices. This component has two main sub-components: Slice2NS Mapper and Slice Lifecycle Manager. The Slice2NS Mapper is responsible for the mapping between the NSIs and the underlying NSs, while the Slice Lifecycle Manager is responsible for the NSI LCM. The Slice Manager will reuse the SP’s existing NFVO APIs to manage the underlying NSs. The NSTs will be stored in the Catalogue and the NSIR (NSI Repository) will store the records of the running NSIs and historical data in the Repository. The Figure below depicts the Slice Manager component architecture.

Figure 6 – 5GTango Slice Manager component architecture.


[5G-Americas] 5G Americas, Network slicing for 5G networks, November 2016.
[NGMN-Concept] NGMN Alliance, Description of network slicing Concept, January 2016.
[NGMN-Arch] NGMN Alliance, 5G End-to-End Architecture Framework, October 2017.
[NGMN-WhitePaper] NGMN Alliance, 5G White Paper, February 2017.
[3GPP-TR28.801] 3GPP TR 28.801, Study on management and orchestration of network slicing for next generation network (Release 15), Jan 2018.
[3GPP-TS23.501] 3GPP, System Architecture for the 5G System; Stage 2 (Release 15), December 2017.
[3GPP-TS23.502] 3GPP TS 23.502, Procedures for the 5G System; Stage 2 (Release 15), December 2017.
[ETSI-NFV-WhitePaper] ETSI NFV, White Paper on NFV priorities for 5G - network Operator Perspectives on NFV priorities for 5G, February 2017.
[ETSI-NFV-EVE012] - Network Functions Virtualisation (NFV); Evolution and Ecosystem; Report on network slicing Support with ETSI NFV Architecture Framework, October 2017.
[ONF-5G] Open networking Foundation, ONF, TR-526 Applying SDN Architecture to 5G Slicing, Issue 1, April 2016.


We use cookies to facilitate navigation and improve your experience across our website. By clicking "Accept", you will be storing these cookies.