27 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. 5G Network Control in ITU-T SG13 – perspective and challenges:
   Presentation:
   https://www.itu.int/en/ITU-T/Workshops-and-Seminars/201711/Documents/Luca_Pesando.pdf

3. 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

4. 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.

5. 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

6. 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.

7. 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

8. 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

9. 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)

10. 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

11. 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

12. 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.

13. 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)

14. From ITU-T Y.3102 Framework of the IMT-2020 network (05/2018)

    Definitions:
    3.1.7 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.8 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.1.9 orchestration [ITU-T Y.3100]: In the context of IMT-2020, the processes aiming at the
    automated arrangement, coordination, instantiation and use of network functions and resources for
    both physical and virtual infrastructures by optimization criteria.
    ………………………………………………………………………………………………………….

    7.1 Support of network slicing:

    The IMT-2020 network is required to be flexible to support the extreme variety of requirements in
    terms of application services. Therefore, the IMT-2020 network is a network where multiple logical
    network instances, tailored to different customer specific requirements, can be created by using
    network slicing. The IMT-2020 network architecture is required to support multiple network slices
    and to allow a single user equipment (UE) to be attached to multiple network slices.
    When a UE registers with the IMT-2020 network, the UE is required to provide information for the
    selection of the required network slice(s) which the UE wishes to establish one or more sessions on.
    The selection of the network slice for the UE is triggered by the network access control function
    through its interaction with the network slice selection function. Details about network slice
    selection are provided in clause 8.

    7.2 Support of network capability exposure:

    Network slices are composed of network functions. The IMT-2020 network architecture is required
    to support network capability exposure in order to enable 3rd parties to use the capabilities provided
    by network slices as well as network functions.

15. 5G-Slicing-Enabled Scalable SDN Core Network: Toward an Ultra-Low Latency of Autonomous Driving Service

    Abstract:
    5G networks are anticipated to support a plethora of innovative and promising network services. These services have heterogeneous performance requirements (e.g., high-rate traffic, low latency, and high reliability). To meet them, 5G networks are entailed to endorse flexibility that can be fulfilled through the deployment of new emerging technologies, mainly software-defined networking (SDN), network functions virtualization (NFV), and network slicing. In this paper, we focus on an interesting automotive vertical use case: autonomous vehicles. Our aim is to enhance the quality of service of autonomous driving application. To this end, we design a framework that uses the aforementioned technologies to enhance the quality of service of the autonomous driving application. The framework is made of 1) a distributed and scalable SDN core network architecture that deploys fog, edge and cloud computing technologies; 2) a network slicing function that maps autonomous driving functionalities into service slices; and 3) a network and service slicing system model that promotes a four-layer logical architecture to improve the transmission efficiency and satisfy the low latency constraint. In addition, we present a theoretical analysis of the propagation delay and the handling latency based on GI/M/1 queuing system. Simulation results show that our framework meets the low-latency requirement of the autonomous driving application as it incurs low propagation delay and handling latency for autonomous driving traffic compared to best-effort traffic.

    Introduction
    The emerging 5G technology is foreseen as the promising solution to improve network performance and management while ensuring high data rate and enhanced quality of service. It is expected to support a variety of vertical industries such as manufacturing, automotive, healthcare, energy, media and entertainment [1]. Such verticals will spark different use cases, imposing new set of requirements (e.g., scalability, latency, reliability and availability) that the currently deployed networks, which are based on the “one-fit-all” conceptual paradigm, are not able to meet [2], [3]. Accommodating the new applications while supporting existing services imply having a programmable and flexible network infrastructure that can be shared by different network technologies (e.g., IoT, cellular and vehicular).

    One way to achieve such a design is a concept called network slicing. It consists of splitting the physical network infrastructure into multiple logical networks, referred to as slices. These slices are controlled and managed independently by the slice owners, which can be of two types: Over-The-Top (OTT) service providers and Virtual Mobile Network Operators (VMNO) [4]. Each slice is allocated a set of network functionalities that are selected from the shared network infrastructure. These functionalities can be virtualized using technologies such as SDN and NFV. Indeed, an SDN-based architecture was proposed in [5] to enable efficient and scalable network slicing. It deploys a controller between slice owners and the shared network infrastructure that provides an abstract view of the network resources to the slice owners while enabling them to transmit their service requirements to the network infrastructure using northbound interfaces.

    Published in: IEEE Journal on Selected Areas in Communications (Volume: 37, Issue: 8, Aug. 2019)

16. ITU-T q20/SG13 is working on Draft Recommendation ITU-T Y.IMT2020-NSC “IMT-2020 network slice configuration” Latest draft is TD469/WP1.

    Draft new Recommendation ITU-T Y.IMT2020-NSC
    IMT-2020 network slice configuration
    Summary
    The network slicing has been definitely regarded as a key technology to successfully deploy the IMT2020 network. The concept of network slicing and use cases in the IMT-2020 network are introduced in ITU-T Recommendation Y.3112. The use cases provides the slice service type to indicate a specific network slice and the slice user group for precisely representing the network slice in terms of performance aspects and business aspects.
    However, there is still a remaining work to further clarify, e.g., how to provide QoS to the network slice, how to make network slice instance, and how to associate the application services of UE with network slice.
    Therefore this Recommendation is to specify the network slice configuration in order to make and manage a network slice instance in the IMT-2020 network.

    This Recommendation is to specify the network slice configuration in order to make and manage a network slice instance in the IMT-2020 network. This recommendation covers (but is not limited to);
    – Examination on network slice template, network slice association, network slice type indicator, and network slice KPI
    – Evaluation on whether the relevant terms provide a clear explanations enough to create and control a network slice instance);
    – Association with application service and network slice type indicator;
    – Association with network slice KPI and PDU session QoS class;
    – Consideration of the extension of network slice template;
    – Procedures of network slice configuration (e.g., connecting the involved Network Functions and the transport nodes).

17. Nice answers to explain network slicing with real arguments and explaining everything about it. However, there doesn’t seem to be any accredited standards for 5G Network Slicing.

18. This IEEE Techblog post on Network Slicing was quite relevant!! Finally I have found something which helped me understand this new concept that facilitates multiple 5G private networks. However, it does require 5G SA with a 5G core network. Thanks!

19. Very comprehensive article on Network Slicing. I believe 3GPP work on that is progressing faster than in ITU-T SG13.

20. Informative article on 5G network slicing. However, the 3GPP specs and ITU-T SG13 recommendations on same or high level architecture documents- not implementation specs. Hence, there are no real standards for implementing network slicing. All the real work on 5G core and 5G network slicing seems to be done in 3GPP and NOT ITU or ETSI!

21. I’m reading your blog on 5G network slicing from my new iphone 4. Just wanted to say I love reading the IEEE Techblog and look forward to all your posts! Keep up the outstanding work!

22. This is an amazing post on network slicing, designed for all those who want to understand what this buzz phrase is all about. I’m sure people will appreciate this tutorial.

23. I am sure this article has enlightened all the 5G pundits on the reality of network slicing. It’s really a fastidious and comprehensive piece. Many thanks for your excellent research!

24. If you wish for to improve your knowledge of telecom/networking technology keep visiting the IEEE Techblog. You will be updated with the most recent news and commentary of importance to communications professionals.

25. Great post.

Comments are closed.