Overview of ETSI NFV Network Slicing Report: Network Slicing Support with ETSI NFV Architectural Framework

Tetsuya Nakamura (t.nakamura@cablelabs.com), CableLabs, U.S.A.

IEEE Softwarization, December 2017


Network slicing has been defined by multiple Standards Definition Organizations (SDOs) and fora. However, the meaning and understanding of the network slicing concept are different from each other and there is no common definition. The ETSI NFV Network Slicing report [1] does not define additional network slicing use cases or features but analyses use cases related to network slicing as defined in other SDOs and industry fora. Furthermore, the report describes how these use cases could be mapped to the current NFV concepts and supported by the ETSI NFV architectural framework [2] and by NFV-MANO [3]. This article is aim to introduce a brief overview of the report [1].

As introduced in the previous newsletter [4] with article “SDN and NFV Evolution Towards 5G”, the network slicing concept was first defined by NGMN 5G White Paper [5] and the following network slicing paper [6]. Then, ONF [7] explained how to define and manage network slices with SDN and 3GPP has recently finalized the initial study for the management and orchestration of network slices in the context of 3GPP in TR 28.801 [8].


According to the information model described in 3GPP TR 28.801 [8], a network slice contains one or more network slice subnets, each of which in turn contains one or more network functions and can also contain other network slice subnets (see left-hand side of Figure 1). These network functions can be managed as Virtualized Network Functions (VNFs) and/or Physical Network Functions (PNFs). An NFV Network Service (NFV-NS) can thus be regarded as a resource-centric view of a network slice, for the cases where a Network Slice Instance (NSI) would contain at least one virtualised network function. A network slice subnet instance (NSSI) can be shared by multiple NSIs. The virtualised resources for the slice subnet and their connectivity to physical resources can be represented by the nested NFV-NS concept defined in ETSI GS NFV-IFA 014 [9] (see right-hand side of Figure 1), or one or more VNFs and PNFs directly attached to the NFV-NS used by the network slice.  The dotted arrows in Figure 1 illustrate this correspondence from a resource point of view.

Figure 1

Figure 1: Relating the information models between 3GPP and ETSI NFV [1]

3GPP TR 28.801 [8] identifies three management functions related to network slicing management, which include Communication Service Management Function (CSMF), Network Slice Management Function (NSMF), and Network Slice Subnet Management Function (NSSMF). As shown in Figure 2, the Os-Ma reference point can be used for the interaction between 3GPP slicing related management functions and NFV-MANO. To properly interface with NFV-MANO, the NSMF and/or NSSMF need to determine the type of NFV-NS or set of NFV-NSs, VNF and PNF that can support the resource requirements for a NSI or NSSI, and whether new instances of these NFV-NSs, VNFs and the connectivity to the PNFs need to be created or existing instances can be re-used.

Figure 2

Figure 2: Network slice management in an NFV framework [1]

From a resource management viewpoint, NSI can be mapped to an instance of a simple or composite NFV-NS or to a concatenation of such NFV-NS instances. From a resource management viewpoint, different NSIs can use instances of the same type of NFV-NS (i.e., they are instantiated from the same Network Service Descriptors (NSDs)) with the same or different deployment flavours. Alternatively, different NSIs can use instances of different types of NFV-NSs.

The first approach can be used if the NSIs share the same types of network functions (or a large common subset) but differ in terms of the performance expected from these network functions (and from the virtual links connecting them) and/or the number of instances to be deployed for each of them. If slices differ more significantly, mapping to different NFV-NSs, each with its own NSD can be considered. The same mapping principles apply to NSSIs.


According to ONF TR-526 [7], slicing requires the partitioning and assignment of a set of resources that can be used in an isolated, disjunctive or shared manner. A set of such dedicated resources can be called a slice instance. The report further states that a controller’s client context provides the complete abstract set of resources and supporting control logic for constituting a slice, including the complete collection of related client service attributes. The client context also offers to the client functions to manage-control the slice resources, including operations and management functions, whose visibility and availability for the client are determined by administrative policy. A controller’s server context contains everything necessary and sufficient for the controller to interact with a group of underlying resources. Resources fall into and may be combinations of the categories network, storage and compute.

ONF network slicing as defined in TR-526 [7] has the following implications in VNF configuration, NFV-NS, NSD (affinity, anti-affinity), Virtualised resources, etc. (ref., Figure 3).

  • The concept of SDN controller’s client context can be mapped to the concept of NFV-NS
  • The concept of SDN controller’s server context can be mapped to the concept of NFV NFVI resources

Figure 3

Figure 3: Mapping between ONF slicing concept and ETSI NFV elements [1]

Network slicing use cases analysis and potential impact to the NFV

The ETSI NFV Network Slicing report [1] analyzes network slicing use cases derived mainly from 3GPP to figure out potential impacts to the NFV architectural framework as well as security and reliability. For instance, one use case derived from 3GPP TR 28.801 [8] is a NSI creation, when the operator decides to create a new NSI. In this use case, the Network Function contained in the NSI defined in 3GPP can be either a VNF or a PNF. The resources of the VNFs are managed by the NFV-MANO system. The relation to NFV constructs is analyzed below:

  • Whenever a VNF is in use, deployment and management of the associated virtualised resources is supported by the NFV-MANO system, including any scale operation associated with reconfigurations. About VNF management, keeping in mind that a VNF is composed by virtualized resources and a network application; according to 3GPP definition, MANO takes care of the management of the virtualised resources and the 3GPP management system takes care of the 3GPP network application installed on them.
  • The QoS and availability requirements for resources supporting a network slice will be dealt by including appropriate information in the NSD, and the corresponding VNFDs of the relevant VNFs (e.g. affinity and anti-affinity rules, virtual link quality of service, etc.) and/or by selecting appropriate deployment flavours at instantiation time.

From security point of view, the allocated resources during NSI creation and the network slice management operations should be isolated from security view point. From reliability point of view, the availability and reliability of a NSI do not depend only on the availability and reliability properties of the physical and logical resources assigned during NSI creation, but also on run-time operations, e.g., maintaining the assigned resources to fulfil the availability and reliability requirements during the NSI lifecycle whenever accidental or intentional anomalies occur. Also, reliability of a NSI depends on the topology of the interconnections between the assigned resources.

The report [1] also analyzes other use cases such as NSSI creation, Priority of NSI for re-allocating the limited resources, and Network Slice as a Service. As a result, the recommendations to support network slicing capabilities by the ETSI NFV architectural framework are indicated. The below is part of them:

  • NFV-MANO reference points/interfaces
    • Determining the requirements on the lifecycle of the Network Service used as part of a Network Slice/Network Slice Subnet
    • Determining the policy handling requirements for Network Service instances such as prioritization
    • Determining the requirements for performance and fault data handling
  • Security
    • Resource isolation and allocation policy at NFV-NS, VNF, and NFVI levels
    • Isolation of network service management for multiple tenants
  • Reliability
    • Network Service instantiation used in the creation of a network slice instance, or in the network slice subnet instance
    • Maintaining the reliability of a network slice instance which is being terminated or after resource changes

Further analysis on whether there is any impact on those aspects is required.


The ETSI NFV Network Slicing report [1] analyzes use cases derived from external organizations and provides a set of recommendations on the evolution of NFV specifications to enable supporting the network slicing feature. The recommendations will be analyzed furthermore as part of the NFV specifications development to identify normative requirements of NFV-MANO, security, and reliability.



[1] ETSI GS NFV-EVE 012 (V3.1.1): “Network Functions Virtualisation (NFV) Release 3; Evolution and Ecosystem; Report on Network Slicing Support with ETSI NFV Architecture Framework”, December 2017.
[2] ETSI GS NFV 002 (V1.2.1): “Network Functions Virtualisation (NFV); Architectural Framework”, December 2014.
[3] ETSI GS NFV-MAN 001 (V1.1.1): “Network Functions Virtualisation (NFV); Management and Orchestration”, December 2014.
[4] IEEE Softwarization: “SDN and NFV Evolution Towards 5G”, September 2017.
[5] Next Generation Mobile Networks (NGMN) Alliance: “5G white paper”, Version 1.0, February 2015.
[6] NGMN Alliance: "Description of Network Slicing Concept", Version 1.0, January 2016.
[7] ONF TR-526, Applying SDN architecture to 5G slicing, Issue 1, April 2016.
[8] 3GPP TR 28.801 (V15.0.0): "Study on management and orchestration of network slicing for next generation network", September 2017.
[9] ETSI GS NFV-IFA 014 (V2.3.1): “Network Functions Virtualisation (NFV) Release 2; Management and Orchestration; Network Service Templates Specification”, August 2017.



Tetsuya NakamuraTetsuya Nakamura serves as Principal Architect, Strategy and Innovation Group at CableLabs. Tetsuya is working on standardization effort at the ETSI NFV ISG as ISG Vice Chair. He is also working on CableLabs’ open source research efforts on NFV and SDN as OPNFV Ambassador and OpenDaylight Advisory Group.

Before joining CableLabs, Tetsuya worked at NTT for about 17 years. While at NTT DOCOMO, Tetsuya was in charge of NFV investigation for mobile networks, and actively involved in the ETSI NFV ISG as ISG Vice Chair, Vice Chair of Technical Steering Committee, and Chair of Software Architecture WG. He was also a founder of OPNFV and the initial Board member for NTT DOCOMO.



Elio SalvadoriDr. Elio Salvadori is the Director of CREATE-NET Research Center within Fondazione Bruno Kessler (FBK); he is responsible for managing, organizing, executing and monitoring of the activities of the Center.

He joined CREATE-NET in 2005 and since then he has served different roles within the organization: from 2007 to 2012 he has been leading the Engineering and Fast Prototyping (ENGINE) area. From 2012 to 2014 he has been acting as SDN Senior Advisor while holding a position as CEO in Trentino NGN Srl. He then moved fully back to CREATE-NET acting as Research Director and then as Managing Director until the incorporation within FBK at the end of 2016.

Prior to CREATE-NET, Dr. Salvadori has developed a mixed industrial and academical background: he graduated in 1997 at Politecnico di Milano through an internship pursued at CoreCom, a research lab funded by Politecnico and Pirelli Optical Systems (now Cisco Photonics). Afterward he has worked as systems engineer at Nokia Networks in Milan and then at Lucent Technologies in Rome. In 2001 he won a research grant at the University of Trento to pursue his PhD on Information and Communication Technologies. He received his PhD degree in March 2005 with a thesis on traffic engineering for optical networks.

During his research career, he has been involved in several national and European projects on SDN and optical networking technologies as well as on Future Internet testbeds.

His current research interests include software-defined networking (network virtualization and distributed controller architectures), Network Functions Virtualization (NFV) and next generation transport networks. He has published in more than 100 International refereed journals and conferences. He is a member of IEEE and ACM.



Subscribe to IEEE Softwarization

Join our free SDN Technical Community and receive IEEE Softwarization.

Subscribe Now


Article Contributions Welcomed

Download IEEE Softwarization Editorial Guidelines for Authors (PDF, 122 KB)

If you wish to have an article considered for publication, please contact the Managing Editor at sdn-editor@ieee.org.


Past Issues

November 2018

March 2018

January 2018

December 2017

September 2017

July 2017

May 2017

March 2017

January 2017

November 2016

September 2016

July 2016

May 2016

March 2016

January 2016

November 2015

IEEE Softwarization Editorial Board

Laurent Ciavaglia, Editor-in-Chief
Mohamed Faten Zhani, Managing Editor
TBD, Deputy Managing Editor
Syed Hassan Ahmed
Dr. J. Amudhavel
Francesco Benedetto
Korhan Cengiz
Noel Crespi
Neil Davies
Eliezer Dekel
Eileen Healy
Chris Hrivnak
Atta ur Rehman Khan
Marie-Paule Odini
Shashikant Patil
Kostas Pentikousis
Luca Prete
Muhammad Maaz Rehan
Mubashir Rehmani
Stefano Salsano
Elio Salvadori
Nadir Shah
Alexandros Stavdas
Jose Verger