Network Slicing and 5G: Why it’s important, ITU-T SG 13 work, related IEEE ComSoc paper abstracts/overviews

Why end-to-end network slicing will be important for 5G:

In network slicing of a 5G network, the intent is to take infra­structure resources from the spectrum, antennas and all of the backend network and equipment and use it to create multiple sub-networks with different properties. Each sub-network slices the resources from the physical network, end to end, to create its own independent, no-compromise network for its preferred applications.

One slice type is specifically targeted for ultra-low latency and high reliability (like self-driving vehicles) (URRLC), another slice type is spe­cifically targeted for devices that don’t have large batteries (like sensors) (MMTC) and need efficiency and yet another slice type is targeted at ultra-high speed (eMBB) as required for 4K or immersive 3d video. While the initial standards work calls for only three slice types, the architec­tures are flexible for future slice types.

Since it would be far too expensive to allocate a complete end-to-end network to each type of slice, the network infrastructure that supports 5G (and likely 4G) will employ sharing techniques (virtualization and cloud), which allow for mul­tiple slice types to co-exist without having too many multiples of the resources.

…………………………………………………………………………………………………………………………………………………………………………………………..

In 2017, ITU–T Study Group 13 (SG13) cre­ated a Focus Group with a mandate to research the areas that needed standardization for the non-radio aspects of 5G. The harmonious oper­ation through software control, referred to as “softwarization” of all of the components of the 5G network, was one of the many subjects stud­ied by the Focus Group, and which is now being more formally considered by SG13. Many of the areas requiring control are not uniquely wireless components but are also involved in service providers’ other end-to-end-businesses. For example, the cloud and transport networks which interconnect them will require new agile control to ensure that the packet, non-packet interconnections and compute, meet the Quality-of-Service (QoS) demands of that slice. The success of 5G lies in entire ecosystems 5G slicing technology, to be truly successful, will need entire ecosystems to come together to solve and standardize their end-to-end applications.

Read more here and here.   ITU-T SG13 Working Party 1 Questions on Non Radio Aspects of IMT 2020 Networks & Systems:

WP1/13 IMT-2020 Networks & Systems 
Q6/13 Quality of service (QoS) aspects including IMT-2020 networks 
Q20/13 IMT-2020: Network requirements and functional architecture 
Q21/13 Network softwarization including software-defined networking, network slicing and orchestration 
Q22/13 Upcoming network technologies for IMT-2020 and Future Networks 
Q23/13 Fixed-Mobile Convergence including IMT-2020 

……………………………………………………………………………………………………………………………………………………………………………………………..

Selected IEEE ComSoc Papers on 5G Network Slicing:

Efficient and Secure Service-oriented Authentication Supporting Network Slicing for 5G-enabled IoT

by Jianbing Ni, Student Member, IEEE, Xiaodong Lin, Fellow, IEEE, Xuemin (Sherman) Shen, Fellow, IEEE (edited by Alan J Weissberger)

To be published in a future issue of IEEE Journal on Selected Areas in Communications sometime in 2018 

Abstract

“5G” network is considered as a key enabler in meeting continuously increasing demands for future Internet of Things (IoT) services which will connect numerous devices.  Those IoT demands include high data rate  and  very low network latency. To satisfy these demands, network slicing and FOG computing have been envisioned as promising solutions in service-oriented 5G architecture. However, security paradigms enabling authentication and confidentiality of 5G communications for IoT services remain elusive, but indispensable. In this paper, we propose an efficient and secure service oriented authentication framework supporting network slicing and fog computing for 5G-enabled IoT services.

Specifically, users may efficiently establish connections over a 5G core network and anonymously access IoT services under their delegation through proper network slices of 5G infrastructure.  The particular 5G service might be selected by FOG nodes based on the slice/service types of accessing services. The privacy preserving slice selection mechanism is introduced to preserve both configured slice types and accessing service types of users. In addition, session keys are negotiated among users, local fogs and IoT servers to guarantee secure access of service data in fog cache and remote servers with low latency. We evaluate the performance of the proposed framework through simulations to demonstrate its efficiency and feasibility under 5G infrastructure.

From the Introduction:

How to enhance security and privacy protection for IoT services powered by 5G is the focus of this paper.  To secure 5G-enabled IoT services, a national demand is to design efficient service-oriented authentication protocols for numerous users with the severe demands of different IoT services. To preserve user privacy, it is critical to hide users’ identities during service authentication. Thus, the challenge is to support anonymous service-oriented authentication with scalability of handing a large number of authentication requests.  Furthermore, after users’ identities are well protected, it is still possible for local fog nodes to identify users through some side-channel information, such as users’ accessing services, which results in unwelcome advertisements for users.

……………………………………………………………………………………………………………………………………………………………………………………………………………

Network slicing for 5G systems: A review from an architecture and standardization perspective

by Riccardo Trivisonno; Xueli An; Qing Wei

Published in: Standards for Communications and Networking (CSCN), 2017 IEEE Conference in Helsinki, Finland, 18-20 Sept. 2017.

Abstract:

The discussion around Network Slicing for 5G Systems is slowly converging to concrete solutions which will be adopted in the early deployment of 5G Networks due by 2020. In particular, within 3GPP standardization body, study items recently completed have finalized the definition of 5G System architecture, comprising Access and Core Networks, and defined the key design principles for End to End Network Slicing. This paper reviews the latest achievements of 3GPP SA2 and RAN3 Working Groups (WGs) in this respect, relating them to the genesis of Network Slicing and to prior 4G technical solutions, which can be considered precursors of the concept. Essentially, this paper timely clarifies how Network Slicing will be brought into real systems, and sheds some light on the necessary next steps to further progress on the topic.
Introduction:
In the ongoing hectic activities aiming at defining and standardizing 5G System (5GS) cornerstones, targeting an early deployment in the 2020 horizon, Network Slicing is amongst the most debated issues. The concept of Network Slicing was brought into the 5G system domain by early discussions among mobile network operators within NGMN. To shed some light on the concept, it is beneficial to fall back to its genesis.

The problem statement originated back in 2015, at the time 5G use cases were analyzed ([1]), when it emerged 4G network architecture did not suit with the diversity of requirements derived from 5G use cases. 4G architecture was considered “not flexible and scalable enough to efficiently support a wider range of business needed when each has its own specific set of performance, scalability and availability requirements”. Additionally, it was argued that a future-proof 5G system should have been conceived allowing efficient introduction of new network services. From this simple and clear starting point, the concept of Network Slicing for 5G was introduced. According to NGMN, the network slicing concept consisted of 3 layers: Service Instance Layer, Network Slice Instance (NSI) Layer, and Resource layer. As described in [1], “the Service Instance Layer represents the services which are to be supported. Each service is represented by a Service Instance.” Also, [1] stated “a Service Instance can either represent an operator service or a 3rd party provided service”. Furthermore, NGMN assumed a network operator would use a Network Slice Blueprint to create an NSI. An NSI provides the network characteristics which are required by a Service Instance. An NSI may also be shared across multiple Service Instances provided by the network operator. An NSI was defined as “ a set of network functions, and resources to run these network functions, forming a complete instantiated logical network to meet certain network characteristics required by the Service Instance (s) ”. Network Slice Blueprint was defined as a complete description of the structure, configuration and the plans/work flows for how to instantiate and control the NSI during its life cycle. A Network Slice Blueprint enables the instantiation of a Network Slice and describes required physical and logical resources. NGMN definitions are sound and complete but, being written from network operator’s standpoint, they focus on the end service perspective and they fail to distinguish among domains they apply to. In particular, it is straightforward the Network Slice Blueprint definition includes system architecture, network lifecycle/management and resource/infrastructure aspects.

The implicit wide scope of such definitions and the appeal the slicing concept was gaining in the R&D community triggered a number of initiatives aiming at extending and clarifying the concepts in all possible concerned domains (see e.g. [2] for SDN related aspects, or [3] for protocols ecosystem issues). The bottom line is: to further progress in the definition of the technologies required to bring Network Slicing into real systems, it is essential to focus on a narrower scope.

The scope of this paper is restricted to 5G end to end System Architecture aspects (i.e. Access and Core networks), leaving aside network management, transport network, network and data centres infrastructure issues. The purpose of this paper is to examine the 4G legacy on Network Slicing (where related early concepts can be found), to review the current status of 5G system standardization in this respect, and to highlight the critical open points which will require significant effort before 5G standardization completes.

The paper is organized as follows: Sec II looks back to 4G systems, analysing early solutions which can be considered precursors of Network Slicing. Sec III presents an in-depth review of latest achievements from 3GPP WGs, which cast the actual foundations over which 5GS will be built. Sec IV highlights the key open issues on which research and standardization will further devote significant effort. Finally, Sec V concludes the paper.

………………………………………………………………………………………………………………………………………………………………………………………………………………………………………

Network Slicing for 5G: Challenges and Opportunities

by Xin Li; Mohammed Samaka; H. Anthony Chan; Deval Bhamare; Lav Gupta; Chengcheng Guo; Raj Jain

Published in: IEEE Internet Computing (Volume: 21Issue: 5, 2017)

Abstract:

Network slicing for 5G provides Network-as-a-Service (NaaS) for different use cases, allowing network operators to build multiple virtual networks on a shared infrastructure. With network slicing, service providers can deploy their applications and services flexibly and quickly to accommodate diverse services’ specific requirements. As an emerging technology with a number of advantages, network slicing has raised many issues for the industry and academia alike. Here, the authors discuss this technology’s background and propose a framework. They also discuss remaining challenges and future research directions.
Research in fifth-generation (5G) mobile networks has gained momentum in both academia and industry recently. These 5G mobile networks will carry a plethora of mobile devices and provide faster network connection speed. In addition, mobile data traffic in future 5G networks will experience explosive growth. According to the latest Cisco forecast,1 by 2020, the number of devices connected to mobile networks will exceed the world’s population, reaching 11.6 billion. At that time, mobile data traffic will be 30.6 exabytes per month, which is 8 times that in 2015. However, the most challenging aspect is that 5G networks will support a wide variety of use cases, as we’re entering the era of the Internet of Everything (IoE). Some applications, such as ultra-high defmition (UHD) video and augmented reality need high-speed, high-capacity communications, while others such as the mission-critical Internet of Things (IoT) and autonomous vehicles require ultralow latency, ultra-reliable services.

Traditional mobile communication networks employ the one-size-fits-all approach to providing services to mobile devices, regardless of the communication requirements of vertical services. This design philosophy can’t offer differentiated services. Hence, it’s necessary for the research community to explore new techniques to address the challenges associated with supporting vertical industries in 5G networks.

Software-defined networking (SDN) and network functions virtualization (NFV) have been proposed as key technologies to build softwarized, virtualized, and cloudified 5G systems in recent years. SDN2 decouples network control and data forwarding. Network control functions can run as applications independently in the logically centralized controllers. NFV3 decouples specific network functions from dedicated and expensive hardware platforms to general-purpose commodity hardware. Network operators can implement a variety of virtual network functions (VNFs) over the standard commodity servers. In addition, Mobile Edge Computing (MEC)4 as a key emerging technology in 5G is expected to serve low-latency communication that’s one of the use cases in future 5G. It moves computing, storage, and networking resources from remote public clouds closer to the edge of the network. Thus, mobile clients can request virtual resources within the access network and experience low end-to-end delay.

The concept of network slicing 5 has been proposed to address the diversified service requirements in 5G under the background of the aforementioned technologies. Network slicing is an end-to-end logical network provisioned with a set of isolated virtual resources on the shared physical infrastructure. These logical networks are provided as different services to fulfill users’ varying communication requirements. Network slicing provides a network-as-a-service (NaaS) model, flexibly allocating and reallocating resources according to dynamic demands, such that it can customize network slices for diverse and complex 5G communication scenarios.

Network slicing will be the fundamental feature of 5G networks. Slice-based 5G has the following significant advantages when compared with traditional networks:

  • Network slicing can provide logical networks with better performance than one-size-fits-all networks.
  • A network slice can scale up or down as service requirements and the number of users change.
  • Network slices can isolate the network resources of one service from the others; the configurations among various slices don’t affect each other. Therefore, the reliability and security of each slice can be enhanced.
  • Finally, a network slice is customized according to service requirements, which can optimize the allocation and use of physical network resources.

With this in mind, next we discuss some details on network slicing for 5G networks and explore why 5G needs network slicing, as well as how to implement network slicing in 5G. For others’ work on network slicing for 5G, see the related subhead below.

Network Slicing in 5G

Fifth-generation networks need to integrate multiple services with various performance requirements — such as high throughput, low latency, high reliability, high mobility, and high security — into a single physical network infrastructure, and provide each service with a customized logical network (that is, network slicing). The Third-Generation Partnership Project (3GPP) has identified network slicing as one of the key technologies to achieve the aforementioned goals in future 5G networks. Some 3GPP work items have the features of network slicing: for example, the dedicated core (DÉCOR) feature supports the operator to deploy multiple dedicated core networks by sharing a common Public Land Mobile Network (PLMN). An exhaustive description about how the next-generation wireless system will support network slicing is provided elsewhere.6

Network slicing refers to partitioning of one physical network into multiple virtual networks, each architected and optimized for a specific application/service. Specifically speaking, a network slice is a virtual network that’s created on top of a physical network in such a way that it gives the illusion to the slice tenant of operating its own dedicated physical network. A network slice is a self-contained network with its own virtual resources, topology, traffIC flow, and provisioning rules. There might be various network slices to meet the specific communication needs of different users in the future mobile network systems. For example, a massive industrial IoT slice might need a light 5G core, with no handover but a large number of connections. On the other hand, a mobile broadband slice might need a high-capacity core, full feature mobility, and low latency. Slices are logically isolated, but resources can be shared among them. Figure 1 illustrates the network slicing concept.

Figure 1

Figure 1.Conceptual illustration of network slicing. NFV stands for Network Function Virtualization, RAN stands for radio access network, and SDN stands for software-defined networking.

………………………………………………………………………………………………………………………………………………………………………

Network slicing makes use of the concept known as network virtualization. Network virtualization enables flexible and dynamic network management to address the problem of network ossification by allowing multiple heterogeneous and service-specific virtual networks to share a single substrate network.

In addition, the emerging technologies software-defined networking (SDN) and network functions virtualization (NFV) are considered as the necessary tools to implement network slicing. The following work summarizes use of SDN and NFV to implement 5G network slicing.

Csaba Simon and colleagues1 propose a flexible 5G network architecture to support the coexistence of heterogeneous services and to quickly create services. The authors propose to use SDN and NFV in the architecture to realize the sharing of resources by different services and orchestrating resources automatically. The concept of resource slicing is similar to network slicing in the proposed architecture. Resource slices, which include virtual resources and virtual network functions, are tailored on-demand according to service categories, namely slice as a service (SlaaS).

Manuel Peuster and colleagues designed an NFV-based platform called Multi Datacenter service ChaIN Emulator (MeDICINE) for network services.2 It allows management and orchestration (MANO) system to deploy virtual network resources for network services in a multi-domain infrastructure. The design and implementation of this platform show that NFV plays an important role in realizing network slicing.

Navid Nikaein and colleagues3 proposed a novel slice-based 5G architecture based on SDN, NFV, and cloud computing. They designed the elements required to implement network slicing and present a validation prototype. The concept of a network store in this work can achieve dynamic 5G network slicing. The authors discuss building a multitenant and multiservice end-to-end 5G mobile network architecture using SDN, NFV, and network slicing in the 5G NORMA project.4

Mobile operators, hardware manufacturers and open source communities are also actively studying the ways to implement 5G network slicing. Ericsson and NTT DOCOMO successfully showed a dynamic 5G network slicing proof of concept on 9 June 2016.5 Ericsson6 discussed the decomposition schemes of radio access network (RAN) functions that can support network slicing. The schemes provide a meaningful guidance for implementing flexible and resilient RAN slices.

Very recently, Huawei (with other three enterprises) released a network slicing white paper.7 They discussed several key technologies, such as network management system and security to achieve service-guaranteed network slicing, which will be helpful for network industries.

It’s worth noting that the Open Network Automation Platform (ONAP), established in February 2017, is working on a cloud-centric and SDN/NFV-based network platform, which might lay the groundwork for the implementation of 5G network slicing. Also, currently, the Wireless World Research Forum (WWRF) is launching a working group for 5G network slicing.

…………………………………………………………………………………………………………………………………………………………………………………………………………………………

Network Slicing for 5G with SDN/NFV: Concepts, Architectures, and Challenges

by Jose Ordonez-Lucena; Pablo Ameigeiras; Diego Lopez; Juan J. Ramos-Munoz; Javier Lorca; Jesus Folgueira

Published in: IEEE Communications Magazine Volume: 55Issue: 5, May 2017 )

Abstract:

The fifth generation of mobile communications is anticipated to open up innovation opportunities for new industries such as vertical markets. However, these verticals originate myriad use cases with diverging requirements that future 5G networks have to efficiently support. Network slicing may be a natural solution to simultaneously accommodate, over a common network infrastructure, the wide range of services that vertical- specific use cases will demand. In this article, we present the network slicing concept, with a particular focus on its application to 5G systems. We start by summarizing the key aspects that enable the realization of so-called network slices. Then we give a brief overview on the SDN architecture proposed by the ONF and show that it provides tools to support slicing. We argue that although such architecture paves the way for network slicing implementation, it lacks some essential capabilities that can be supplied by NFV. Hence, we analyze a proposal from ETSI to incorporate the capabilities of SDN into the NFV architecture. Additionally, we present an example scenario that combines SDN and NFV technologies to address the realization of network slices. Finally, we summarize the open research issues with the purpose of motivating new advances in this field.
Overview:
The authors present the network slicing concept, with a particular focus on its application to 5G systems. They start by summarizing the key aspects that enable the realization of so-called network slices. Then they give a brief overview on the SDN architecture proposed by the ONF and show that it provides tools to support slicing. They argue that although such architecture paves the way for network slicing implementation, it lacks some essential capabilities that can be supplied by NFV.
……………………………………………………………………………………………………………………………………………………………………………..

Ericsson:  Network Slicing can be a piece of cake

Network slicing in essence means that connectivity becomes differentiated, enabling you to provide innovative business models and demonstrate additional value.

Ericsson has a complete solution for network slicing, with all the key components in place. Available now, it will let you get started with network slicing, and elevate your offerings above mobile broadband.

This paper looks at the practicalities of network slicing and automation, how to support a multitude of new use cases, and how to simplify operations with services which are quick to provision, replicate, scale, upgrade and delete. The paper also considers the business support and monetization aspects required to generate revenue using this technology, and concludes with an example of network slicing collaborative work with a leading network operator.

15 thoughts on “Network Slicing and 5G: Why it’s important, ITU-T SG 13 work, related IEEE ComSoc paper abstracts/overviews

  1. This blog helped me wrap my head around “slicing”. Just the right level of detail. Having the papers with overview also was very helpful.
    IMHO, the slicing for 5G will turn out to be far more complicated and difficult than currently expected, because the slices will be built on top of 5G which will itself be massively complicated to build. But what fun!

  2. by Ericsson
    Network slicing is a powerful virtualization capability and one of the key capabilities that will enable flexibility, as it allows multiple logical networks to be created on top of a common shared physical infrastructure. The greater elasticity brought about by network slicing will help to address the cost, efficiency, and flexibility requirements imposed by future demands.
    Technologies like SDN and network virtualization are enabling a drastic change to take place in network architecture, allowing traditional structures to be broken down into customizable elements that 
can be chained together programmatically to provide just the right level of connectivity, with each element running on the architecture of its choice. This is the concept of network slicing that will enable networks to be built in a way that maximizes flexibility.

    https://www.ericsson.com/digital-services/trending/network-slicing

  3. Thank for the explanation of Network Slicing. To some extent, it seems like a virtual private network for wireless, except it’s for different applications.

  4. ITU-T SG13 future recommendations related to 5G Network Slicing:

    -Y.NetSoft-SSSDN Q21/13 High level architectural model of network slice support for IMT-2020 – Part: SDN
    -Under study Y.NSOM Q21/13 Network slicing orchestration and management
    -Under study Y.SFCM Q21/13 Service function chaining in mobile network

  5. Alan, Thank you again for the interesting and thought provoking question at the IEEE 5G World event in Santa Clara. After consulting with our standardization experts, I better understand the concern you expressed at ITU-T SG13 being “years away” from the reality of end to end Network Slicing.

    We believe that the network slicing work done by multiple standards organizations (such as 3GPP, Broadband Forum, MEF, IETF, IEEE 802, ITU-T SG15) in addition to SG13, as well as the open source projects ongoing, will expedite implementation and deployment of solutions especially on EPG. For some examples of work in progress, please see the web sites of the organizations listed. Also, IEEE Communications Standards Magazine contains some relevant information on industry network slicing initiatives. https://ieeexplore.ieee.org/xpl/tocresult.jsp?isnumber=8412445

    While proprietary approaches might start slicing support, as is almost always the case with new technology to speed up deployment, nearly all long term support will be based on standards to allow consistent and interoperable slicing across equipment end to end and across layers.

  6. Nokia debuts open and programmable network slicing system: 10 October 2018

    Nokia has introduced an open and programmable fixed access network slicing system that will let service providers create a virtual slice that operates like a physical network. They can then run a dedicated controller for a view of their slice of the network. The system can scale up to a virtually unlimited number of discrete network slices. These can be operated independently to, for example, run 5G mobile transport, wholesale or business services.
    The new system is built around Nokia’s cloud-native software platform Altiplano and open standards. It uses open interfaces and Yang data models to create the virtual slice. Equipment from different vendors can sit alongside each other, in different slices or on the same slice.

    With the system, operators can control each slice they manage, and then determine the performance metrics for the network and services they deliver to customers. They can use Software Defined Access Networks (SDAN) to deliver new services and connect more users, segments and entities that would otherwise require parallel networks. Once deployed, Nokia’s Fixed Network Slicing solution can help services providers move toward a fully autonomous Network as a Service (NaaS) model.

    https://www.telecompaper.com/news/nokia-debuts-open-and-programmable-network-slicing-system–1264359

  7. GSA: 5G Network Slicing Use Cases

    Network Slicing is set to be a prominent feature of 5G to allow connectivity and data processing tailored to specific customers’ requirements. Mobile communications provided by smart networks will enhance the efficiency and productivity of business processes and will open up opportunities for operators to address the Business to Business segment more effectively.

    This paper proposes the adoption of a “generic slice template” that the industry can use as universal description. A generic slice template provides a universal description of a network slice type that can be used by infrastructure vendors, mobile network operators and slice buyers

    https://www.gsma.com/futurenetworks/wp-content/uploads/2018/04/NS-Final.pdf

  8. The ITU-T SG 13 work on Network Slicing is done in Q21/13 “Network softwarization including software-defined networking, network slicing and orchestration,” led by Kazunori TANIKAWA (Japan), Wei CHEN (China),
    Yushuang HU (China), and Sangwoo KANG (Korea).

    At the March 2019 meeting at Victoria Falls, Zimbabwe, China Mobile proposed initiating a new work item on scene requirement for supporting intelligent network slice in IMT-2020 networks – reference C579R1.

    1. ITU-T Y.3112 “Framework for the support of network slicing in the IMT-2020 network“(Rev.)

      This Recommendation describes the concept of network slicing and use cases of that a single UE attaches to multiple network slices simultaneously in the IMT-2020 network.
      This Recommendation specifies high-level requirements and high-level functional framework for the attaching to multiple network slices, and introduces a slice service type and a slice user group for precisely indicating and representing a specific network .
      This revision of this Recommendation provides more explanation about network slice selection.

      1 Scope
      This Recommendation describes the concept of network slicing and use cases of that a single UE attaches to multiple network slices simultaneously in the IMT-2020 network.
      This Recommendation specifies high-level requirements from service aspects as well as from network aspects, and high-level framework in terms of network functions. Furthermore, this Recommendation introduces a slice service type and a slice user group for precisely indicating and representing a specific network slice in terms of performance aspects and business aspects.
      This revision provides more explanation about network slice selection, and the structure of texts is slightly modified.

      2 References
      The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation.
      [ITU-T Y.3100] Recommendation ITU-T Y.3100 (2017), Terms and definitions for IMT-2020 network
      [ITU-T Y.3101] Recommendation ITU-T Y.3101 (2017), Requirements of IMT-2020 network.
      [ITU-T Y.3102] Recommendation ITU-T Y.3102 (2018), Framework of the IMT-2020 network.
      [ITU-T Y.3111] Recommendation ITU-T Y.3111 (2017), IMT-2020 network management and orchestration framework.
      [ITU-T Y.3150] Recommendation ITU-T Y.3150 (2018), High level technical characteristics of network softwarization for IMT-2020
      [ITU-R M.2083] Recommendation ITU-R M.2083-0 (2015), Framework and overall objectives of the future development of IMT for 2020 and beyond
      [ITU-R M.2410] Report ITU-R M.2410-0 (2017), Minimum requirements related to technical performance for IMT-2020 radio interface(s)

      3 Definitions
      3.1 Terms defined elsewhere
      This Recommendation uses the following terms defined elsewhere:
      3.1.1 IMT-2020 [ITU-T Y.3100]: Systems, system components, and related technologies that provide far more enhanced capabilities than those described in [b ITU R M.1645].
      NOTE – [b-ITU-R M.1645] defines the framework and overall objectives of the future development of IMT 2000 and systems beyond IMT-2000 for the radio access network.
      3.1.2 network function [ITU-T Y.3100]: In the context of IMT-2020, a processing function in a network.
      NOTE 1 – Network functions include but are not limited to network node functionalities, e.g. session management, mobility management and transport functions, whose functional behaviour and interfaces are defined.
      NOTE 2 – Network functions can be implemented on a dedicated hardware or as virtualized software functions.
      NOTE 3 – Network functions are not regarded as resources, but rather any network functions can be instantiated using the resources.
      3.1.3 network slice [ITU-T Y.3100]: A logical network that provides specific network capabilities and network characteristics.
      NOTE 1 – Network slices enable the creation of customized networks to provide flexible solutions for different market scenarios which have diverse requirements, with respect to functionalities, performance and resource allocation.
      NOTE 2 – A network slice may have the ability to expose its capabilities.
      NOTE 3 – The behaviour of a network slice is realized via network slice instance(s).
      3.1.4 network slice blueprint [ITU-T Y.3100]: A complete description of the structure, configuration and work flows on how to create and control a network slice instance during its life cycle.
      NOTE – A network slice template can be used synonymously with a network slice blueprint.
      3.1.5 network slice instance [ITU-T Y.3100]: An instance of network slice, which is created based on network slice blueprint.
      NOTE 1 – A network slice instance is composed of a set of managed run-time network functions, and physical/logical/virtual resources to run these network functions, forming a complete instantiated logical network to meet certain network characteristics required by the service instance(s).
      NOTE 2 – A network slice instance may also be shared across multiple service instances provided by the network operator. A network slice instance may be composed of none, one or more sub-network slice instances which may be shared with another network slice instance.
      3.2 Terms defined in this Recommendation
      This Recommendation defines no term.

      4 Abbreviations and acronyms
      This Recommendation uses the following abbreviations and acronyms:
      3G Third Generation
      4G Fourth Generation
      AR Augment Reality
      eMBB enhanced Mobile Broadband
      E2E End-to-End
      HD High Definition
      IMT International Mobile Telecommunications
      KPI Key Performance Indicator
      mMTC massive Machine Type Communications
      MANO Management and Orchestration
      MVNO Mobile Virtual Network Operator
      NACF Network Access Control Function
      NF Network Function
      NS Network Slice
      NSI Network Slice Instance
      NSSF Network Slice Selection Function
      NSTI Network Slice Type Indicator
      SMF Session Management Function
      SST Slice Service Type
      SUG Slice User Group
      UE User Equipment
      UHD Ultra-High Definition
      URLLC Ultra-Reliable Low Latency Communications
      V2X Vehicle to Everything
      VR Virtual Reality

      5 Conventions
      In this Recommendation:
      The keywords “is required to” indicate a requirement which must be strictly followed and from which no deviation is permitted, if conformance to this Recommendation is to be claimed.
      The keywords “is recommended” indicate a requirement which is recommended but which is not absolutely required. Thus, this requirement need not be present to claim conformance.
      The keywords “can optionally” indicate an optional requirement which is permissible, without implying any sense of being recommended. This term is not intended to imply that the vendor’s implementation must provide the option, and the feature can be optionally enabled by the network operator and/or service provider. Rather, it means the vendor may optionally provide the feature and still claim conformance with this Recommendation.

      6 Overview
      The IMT-2020 network is expected to be able to support a variety of services and applications beyond the current IMT [ITU-R M.2083]. In the IMT-2020 network, the services and the applications can have a variety of different requirements on functionality (e.g., priority, charging, policy control, security, and mobility), differences in performance requirements (e.g., latency, mobility, availability, reliability and data rates), or differences in serving users (e.g., public safety users, corporate customers, roamers, or hosted MVNO) [b-3GPP TS 22.261]. Network slicing is recognized as a key enabler for the support of different types of services as it can provide services over corresponding logically isolated network slices by slicing a single physical network into multiple, end-to-end (E2E) networks [ITU-T Y.3101][b-NGMN].
      Furthermore, a broad variety of capabilities can be tightly coupled with these intended different usage scenarios for IMT-2020 [ITU-R M.2083][b-3GPP TS 22.261]. The usage scenarios for IMT-2020 include:

      Enhanced Mobile Broadband (eMBB): This usage scenario pertain to high data rates, high user density, high user mobility, highly variable data rates, deployment, and coverage. The enhanced Mobile Broadband will come with new application areas and requirements in addition to existing Mobile Broadband applications for improved performance and an increasingly seamless user experience.
      Massive Machine Type Communications (mMTC): This usage scenario is characterized by a very large number of connected devices typically transmitting a relatively low volume of non-delay-sensitive data. Devices are required to be low cost, and have a very long battery life.
      Ultra-Reliable and Low Latency Communications (URLLC): This usage scenario has stringent requirements for capabilities such as throughput, latency and reliability. Some examples include wireless control of industrial manufacturing or production processes, remote medical surgery, distribution automation in a smart grid, transportation safety, etc.

      Network slicing enables a IMT-2020 network operator to provide customized networks by slicing a network into multiple, virtual, and end-to-end networks, referred to as network slices. Each network slice can be defined according to different requirements on functionality, performance and specific users.
      Figure 6-1 illustrates the concept of network slicing. A network slice is composed by a collection of the necessary network functions (e.g., being virtualized and/or physical, and using in either shared or slice specific [ITU-T Y.3101])) that support the service requirements of particular usage scenario (s). It is required to be possible to associate devices to their proper slices in order to meet respective requirements, based on device or service type. For example, a mobile phone requesting HD streaming service is associated to an eMBB slice. While the mMTC slice and the URLLC slice are allocated to a sensor measuring the temperature for an agricultural application and an automobile using V2X communication service, respectively.

      Network slicing allows the IMT-2020 network operator to provide dedicated logical networks (i.e., network slices) with customer specific functionalities. A network slice, spanning all the network segments including radio access network, transport network and core network, can be dedicated to specific types of service [ITU-T Y.3101]. When a UE is only associated to a single dedicated network slice, the IMT-2020 network can identify the association of the UE with a network slice based on user subscription, context, service provider’s policy, etc. Otherwise if a UE accesses multiple network slice instances simultaneously, it is recommended for UE to provide information to the network to assist the network slice selection process.

      For each network slice, dedicated resources (e.g., virtualized network functions, network bandwidth, QoS) are allocated and an error or fault occurred in one slice does not cause any effect in other slices. So far, mobile networks (e.g., 3G, 4G), mainly serving mobile phones, have been optimized for voice and internet services in centralized deployment. However, in the IMT-2020 network, they have to serve a variety of devices with different requirements and different needs. The above mentioned usage scenarios require different requirements on performance [b-Netmanias]. For instance, the mMTC usage scenario that connects stationary sensors measuring temperature, humidity, precipitation, etc. to mobile networks does not require features like handover or location update, which have been critical in serving mobile phones. For the eMBB usage scenario, high data rates are driven by the increasing use of data for services such as streaming (e.g., 4K/8K UHD) and interactive services (e.g., AR). These services come with stringent requirements for user experienced data rates as well as associated latency requirements to meet service requirements [ITU-R M.2410]. On the other hand, the URLLC usage scenario (e.g., autonomous driving, remote controlled robots) requires, unlike mobile broadband services, a substantially lower latency as well as higher reliability.

      8 High-level requirements of network slicing
      This clause specifies the high-level requirements from the service aspect as well as from the network slicing aspect.
      – A UE level network functions, e.g., registration management and mobility management, etc., are required to be shared among the multiple network slices.
      NOTE 1– Some of the shared functions can be global and be used for all network slices whereas some of them can be shared among the specific slices serving the same users.
      – The service level network functions, e.g., session management and data path control, etc., are required to allow to be used as NFs in each network slice.
      – The IMT-2020 network is required to instantiate at least one network slice instance (e.g., eMBB) inherited from the characteristics of the SST (e.g., eMBB).
      – A UE is recommended to provide all NSTI that it wishes to access to the IMT-2020 Network when the UE registers to the network.
      – A UE is required to provide single NSTI indicating a specific network slice when the UE requests the IMT-2020 network to establish a service session.
      – The IMT-2020 network is recommended to create a network slice instance based on the NSTI provided by the UE or default network slice instance if the NSTI is not available.
      NOTE 2 – The availability of default network slice instances depends on the IMT-2020 network operator’s policy.
      – The IMT-2020 network is required to select a network slice instance based on the NSTI provided by the UE or default network slice instance if the NSTI is not available.
      – The IMT-2020 network is recommended to allocate a default NSTI when a UE subscribes to the network.
      – The IMT-2020 network is recommended to add and/or remove the network functions in order to change the configuration of a network slice instance.
      – The IMT-2020 network is required to minimize the impact, in changing the configuration of a network slice, on services being provided by itself and other network slices.

      Appendix I: Descriptions of core network functions relevant to network slicing

      (This appendix does not form an integral part of this Recommendation.)

      Following texts, which are relevant to core network functions in IMT-2020 networks, are cited from [ITU-T Y.3102] for supporting consideration of the role of NACF.
      I.1 Network access control function (NACF)
      The NACF functionalities include registration management, connection management and session management function (SMF) selection.
      – Registration management
      When a UE accesses the network, NACF provides functionalities to register and de-register the UE with the network and it establishes the user context in the network. In the registration procedure, NACF performs, but is not limited to, network slice instance selection, UE authentication, authorization of network access and network services, network access policy control.
      – Connection management
      When a registered UE requests network services to the network, NACF provides functionalities to establish and release signalling connections between UE and core network. This includes mobility management functionalities.
      – SMF selection
      When a session establishment request message is received from UE, NACF performs discovery and selection of the SMF that is the most appropriate to manage the session.
      When network slicing is used and a NACF instance, which has received a registration request through a signalling message, cannot serve an appropriate network slice for the UE’s request, NACF instance re-allocation is required. Rerouting of the signalling message to the target NACF instance is required during the registration procedure to re-allocate the serving NACF instance including the transfer of the UE context.
      Depending on the deployment scenarios, the NACF functionalities in a network slice may be performed in distributed multiple NACF instances in order to minimize the signalling delays. In this case, local NACF instances distributed at the network edge can perform the mobility management functionalities for the (intra-RAT and inter-RAT) handovers. The serving NACF instance notifies UE location to SMF. If user plane function (UPF) re-allocation is required to support mobility, SMF selects a new UPF and performs inter-UPF mobility management. NACF re-allocation between local NACF instances can be performed if necessary.
      I.2 Session management function (SMF)
      This function provides functionalities to setup the IP or non-IP protocol data unit (PDU) connectivity (i.e., PDU session) for a UE as well as to control the user plane for that connectivity (e.g., selection/re-selection of user plane network functions and user path, enforcement of policies including QoS policy and charging policy). SMF gets policy information related to session establishment from the policy control function (PCF).
      SMF also provides IP address management functionalities for allocation and release of the UE’s IP address.
      I.3 Network function registry function (NFR)
      This function provides functionalities to assist the discovery and selection of required network functions. Each network function instance registers itself when instantiated and updates its status (i.e., activation/de-activation) so that NFR can maintain information of the available network function instances.
      Multiple instances may be discovered by NFR per discovery request from network functions (for example, NACF uses NFR to select appropriate SMF, ASF and PCF). In such cases, NFR responds to the requesting network function with a list of discovered network functions, network function capabilities and optionally additional selection rules. The requesting network function selects an instance from the list and updates NFR to reflect its selection.
      When the discovery of network function instances in different network slices is required, NFR instances in different network slices interact with each other. A typical example is the case of discovery of network functions (e.g., user plane function) in visited public land mobile network (VPLMN) when a UE roams.
      In general, each network slice instance has its own NFR, at least logically. In certain cases, e.g., if the network slice instances are in the same administrative domain, a single NFR instance can be shared by multiple network slice instances as shown in Figures 6-1 and 6-2.
      I.4 Network slice selection function (NSSF)
      This function provides functionalities to select appropriate network slice instances for a UE. When a UE requests registration with the network, NACF sends a network slice selection request to NSSF with preferred network slice selection information. The NSSF responds with a message including the list of appropriate network slice instances for the UE.
      I.5 Registration management (RM)
      A single UE can be served simultaneously by multiple network slice instances and a single NACF instance may be shared by the different network slice instances.
      The selection of a set of network slice instances for the UE is triggered by the first NACF instance but this may lead to NACF instance relocation. For example, when a NACF instance is not proper to serve the UE’s requirements related to a network slice, the NACF instance reroutes the UE registration request message to the appropriate NACF instance.

      Bibliography

      [b-3GPP TS 22.261] 3GPP TS 22.261, (2017), Service requirements for the 5G system.
      [b-3GPP TS 23.501] 3GPP TS 23.501, (2017), System Architecture for the 5G System.
      [b-NGMN] NGMN Alliance (2016), Perspectives on Vertical Industries and Implications for 5G
      [b-Netmanias] Korea Communication Review (2015), E2E Network Slicing – Key 5G technology
      [b ITU R M.1645] Recommendation ITU-R M.1645, (2003), Framework and overall objectives of
      the future development of IMT-2000 and systems beyond IMT-2000.

      1. Another ITU-T Recommendation related to Network Slicing: Y.3150 -High level technical characteristics of network softwarization for IMT-2020:

        This Recommendation describes how network softwarization (typically network slicing) contributes to IMT-2020 systems. The 20-page Recommendation explores network slicing from vertical aspect (different levels of abstraction) and horizontal aspect (from segments to end-to-end). It further studies network slicing for mobile fronthaul/backhaul, introduction to advanced data-plane programmability, and capability exposure. They are expected to lead to their detailed study.

        https://www.itu.int/ifa/t/2017/sg13/exchange/Presentation%20material/ (ITU log in required to access)

  9. Related ITU-T draft recommendation Y.IMT2020-ADPP: Advanced Data Plane Programmability for IMT-2020
    1. Scope
    This Recommendation describes the scenarios, requirements, architecture, functional design, and reference points of advanced data plane programmability for IMT-2020 networks, which supports the requirements of network evolution and accommodates convergent services in IMT-2020 networks.
    2. References
    The following ITU-T Recommendations and other references contain provisions, which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; all users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published.
    The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation.
    [ITU-T SG13] FG IMT-2020: Report on Standards Gap Analysis
    [ITU-T SG13 Q21, Draft Recommendation Y.IMT2020-NetSoft] Draft Recommendation Y.IMT2020-NetSoft, High level technical characteristics of network softwarization for IMT-2020
    [ITU-T Y.2601] Recommendation ITU-T Y. 2601, Fundamental characteristics and requirements of future packet based networks
    [ITU-T Y.2611] Recommendation ITU-T Y. 2611, High-level architecture of future packet-based networks
    [ITU-T Y.2612] Recommendation ITU-T Y. 2612, Generic requirements and framework of addressing, routing and forwarding in future, packet-based networks
    [ITU-T Y.3011] Recommendation ITU-T Y. 3011, Framework of network virtualization for future networks
    [ITU-T Y.3111] Recommendation ITU-T Y. 3111, IMT-2020 Network Management and Orchestration Framework
    [ITU-T Y.3300] Recommendation ITU-T Y. 3300, Framework of software-defined networking
    [ITU-T Y.3320] Recommendation ITU-T Y. 3320, Requirements for applying formal methods to software-defined networking

  10. From pg 16 of ITU-T GSTR-TN5G: Transport network support of IMT-2020/5G

    Support of 5G Slicing in the transport network:

    The transport network is, in general, a multi-service network and it can be expect that, in some cases, the common transport network infrastructure will be shared between 5G services, different 3GPP services (e.g., uRLLC, eMBB, etc.), and non-3GPP services. It is necessary to provide isolation between each of these services. From a management perspective the services supported by virtual networks (VNs) are established as described in section 8. The forwarding plane must ensure that the traffic from one VN is not (accidentally) delivered to a different VN.

    All traffic is at some point is encapsulated in IP packets that contend for a resource. All communications at some point may be impacted by resource contention. The description of traffic isolation in this TR only address the additional impact caused by the transport network. The transport network provides two types of resources as described below:

     Circuit switched resources: The transport network guarantees that it will have no additional impact on delay variation. The traffic loading on any other VN has no impact on the traffic in this VN, including QoS effects. A circuit switched is supported by a dedicated resource that is assigned when the connection is established. Examples of a dedicated resource are a wavelength or time slot. However, use of a circuit switched VN prevents the VN from sharing resources and potentially offering higher capacity (and lower delay) when
    high demand is encountered.

     Packet switched resources: The transport network will have some additional impact on the delay variation since the traffic loading of one VN may have an impact on the QoS provided to the traffic in other VNs. A packet switched VN is implemented by statistically multiplexing the traffic from two or more VNs onto a common circuit switched connection using a packet technology (e.g., Ethernet VLAN, MPLS tunnel). The impact on the QoS provided by one VN caused by the traffic on other VNs may be constrained by traffic engineering including, for example, limiting the statistical multiplexing ratio or traffic policing on each VN. However, since a packet switched VN shares its resources it can potentially offer higher capacity (and lower delay) depending on the traffic carried by other VNs that share those resources.

    https://www.itu.int/dms_pub/itu-t/opb/tut/T-TUT-HOME-2018-2-PDF-E.pdf

  11. Draft Recommendation ITU-T IMT2020-NSAA-reqts: Requirements for network slicing with AI-assisted analysis in IMT-2020 networks (posted 12 March 2019 at ITU-T SG 13 meeting at Victoria Falls, Zimbabwe)

    1. Scope:
    The Draft Recommendation describes the requirements for supporting AI-assisted analysis of network slice in IMT-2020 networks, which supports the AI-assisted analysis of network slice deployment and management.
    2. References
    The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation.
    [ITU-T X.yyy] Recommendation ITU-T X.yyy (date), Title.
    [ITU-T Y.3100] Recommendation ITU-T Y.3100 Corrigendum 1 (2018), Terms and definitions for IMT-2020 network.
    [TU-T Y.NetSoft-SSSDN] Draft Recommendation ITU-T Y.NetSoft-SSSDN (2019), High level technical charactristics of network slice support for IMT-2020 – part: SDN

    3 Definitions

    3.1 Terms defined elsewhere

    This Recommendation uses the following terms defined elsewhere:
    3.1.1 network slice [ITU-T Y.3100]: A logical network that provides specific network capabilities and network characteristics.
    NOTE 1 – Network slices enable the creation of customized networks to provide flexible solutions for different market scenarios which have diverse requirements, with respect to functionalities, performance and resource allocation.
    NOTE 2 – A network slice may have the ability to expose its capabilities.
    NOTE 3 – The behaviour of a network slice is realized via network slice instance(s).
    3.1.2 mobile network [Q.1762/Y.2802]: A network that provides wireless access to its services and supports mobility.optional quoted definition>.
    3.2 Terms defined in this Recommendation
    This Recommendation defines the following terms:
    3.2.1 :

    4 Abbreviations and acronyms:
    This Recommendation uses the following abbreviations and acronyms:

    5. Conventions used in this Recommendation:
    The keywords “is required to” indicate a requirement which must be strictly followed and from which no deviation is permitted, if conformance to this Recommendation is to be claimed.
    The keywords “is recommended” indicate a requirement which is recommended but which is not absolutely required. Thus, this requirement need not be present to claim conformance.
    The keywords “can optionally” indicate an optional requirement which is permissible, without implying any sense of being recommended. This term is not intended to imply that the vendor’s implementation must provide the option, and the feature can be optionally enabled by the network operator/service provider. Rather, it means the vendor may optionally provide the feature and still claim conformance with this Recommendation.

    6. Overview of network slicing with AI-assisted analysis in IMT-2020 networks:
    – Slice quality of experience (QoE) calculation: training business mean opinion score (MOS) [b-ITU-T P.800] model based on service MOS and network data, calculating slice service MOS
    – Network could take into account slice sevice level agreement (SLA) fulfilment to schedule new slice Resource within the resource configured by Management system.
    – Management could do resource Adjustment:based on slice QoE to adjust resource configuration

    7. Requirements for network slicing with AI-assisted analysis in IMT-2020 networks
    7.1 AI-assisted analysis for network slice’s requirement mapping:
    provide intelligent customer service and slice guidance to network slice customers to help them select and generate optimal and optimal customized network slice services.

    7.2 AI-assisted analysis for network slice’s deployment:
    By using AI to analyze network data, combined with the management of virtualized network resources, output slice management policy rules or slice optimization deployment templates.

    7.3 AI-assisted analysis for network slice’s scheduling management:
    By using AI to analyze network data, output the slice management strategy and realize the slice self-healing and self-optimization.

  12. The pros and cons of network slicing in 5G, by Tom Nolle, CIMI Corp

    Network slicing applies virtualization principles to mobile networks, and many tout it as the launchpad for a new wave of software-defined networking (SDN) and network functions virtualization (NFV) deployment. But arguments about the necessity and value of network slicing exist on both sides.

    Perhaps the best description of network slicing as a technology is horizontal virtualization. The basic strategy is to combine the following partitioned elements:

    -The 3GPP – 5G New Radio (NR) data plane network;
    -SDN technology that segments the edge and core networks; and
    -NFV architecture that virtualizes 5G control plane components.

    This then creates multiple independent virtual networks — or slices — that allow mobile operators to separate users, devices and applications that require a different quality of service (QoS). Slices can also be used to give mobile virtual network operators their own virtual infrastructure, potentially improving MVNO-based services.

    Horizontal slicing offers cross-application and cross-service segmentation of a network. Each horizontal slice has its own virtual resources highly independent of the resources used for other slices. This horizontal network slicing differs from current network segmentation — or vertical slicing — which doesn’t partition resources as much as it allocates them based on the application or mission.

    A network slicing implementation would presumably require a full implementation of 5G Core, which doesn’t have final specifications yet. A complete 5G NR and Core implementation would require considerable investment and a technology refresh, which may be difficult to justify given the current limited business case for 5G.

    In the end, the network slicing debate seems likely to come down to a matter of timing. Today’s dominant 5G non-standard model doesn’t include network slicing as a feature, so any application or service virtualization would have to be deployed based on cloud computing’s vertical virtualization model or an NFV deployment.

    The cloud model is currently far ahead of NFV, so virtualization with the 5G NSA deployments will likely progress with that model. This means network slicing would be retrofitted into 5G networks later, perhaps beyond 2025, when new applications actually demand the stringent separation of resources that network slicing provides.

    Some of the transitional issues related to network slicing — and even the business justifications for network slicing — may fall away if the final specifications follow cloud principles closely. Many operators that have been pushing for a cloud-native NFV model hope this will be the case, but that outcome is doubtful because 5G Core cites NFV specifications. As a result, we can’t truly balance the pros and cons of network slicing until we see more development in both the possible applications and the technical specifications for implementation.

    https://searchnetworking.techtarget.com/tip/The-pros-and-cons-of-network-slicing-in-5G?3/19/2019%20(UserUniverse:%20518460)

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

 
 

 

Recent Posts