none K. Makhijani
Internet-Draft J. Qin
Intended status: Informational R. Ravindran
Expires: January 2, 2018 Huawei Technologies
L. Geng
China Mobile
L. Qiang
S. Peng
Huawei Technologies
X. de Foy
A. Rahman
InterDigital Inc.
A. Galis
University College London
July 1, 2017

Network Slicing Use Cases: Network Customization and Differentiated Services


Network Slicing is meant to enable creating (end-to-end) partitioned network infrastructure which may include the user equipment, access/ core transport networks, edge and central data center resources to provide differentiated connectivity behaviors to fulfill the requirements of distinct services, applications and customers. In this context, connectivity is not restricted to differentiated forwarding capabilities but it covers also advanced service functions that will be invoked when transferring data within a given domain.

The purpose of this document is to focus on use cases that benefit from the usefulness of network slicing.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 2, 2018.

Copyright Notice

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

Network Slicing enables the creation of (end-to-end) partitioned network infrastructure which may include the user equipment, access/ core transport networks, edge and central data center resources to provide differentiated connectivity behaviors to fulfill the requirements of distinct services, applications and customers. In this context, connectivity is not restricted to differentiated forwarding capabilities but it also spans service, management and control plane support offered to a slice instance.

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

1.2. Terminology

Please refer to [I-D.geng-netslices-architecture] for related terminologies and definitions.

Additionally, the following terms are used -

2. Scope

To maximize resource utilization and minimize infrastructure cost, services will need to operate over a shared network infrastructure, as against the traditional monolithic model operated either as dedicated network or as an overlay. Service operators can utilize or benefit from Network Slicing through multi-tenancy, enabling different customized network infrastructures for different group of services across different network domains and operating them independently.

In this document, multi-domain refers to combination of different kinds of connection-technology network domains. For example, it may be a RAN, DSL etc in access; a fixed, wireless or mobile service provider network; as well as different technology domains in transport networks such as carrier ethernet, optical, MPLS, TE-tunnel etc. Often, a combination of technology domains are under the same administrator's control but may also belong to different adminisitrative systems and may require cross-domain coordination.

The document covers generalized as well as resource guaranteed service scenarios that can benefit by applying Network Slicing principles.

The remaining document is organized as below:

3. A Generalized Network Slice as a Service

Network slicing instances share a common infrastructure, which provide flexible design of a logical network with specific network functions customized to support differentiated performance requirements of vertical industry through logical or physical system isolation and certain OAM tools.

Traditionally, vertical industries run their services in a shared network environment upon which infrastructure owners and service providers offer standalone network capabilities including connections, storage and etc. Network slicing paradigm enables supporting the requirements of a network slicing tenant to be met individually. Hence it is anticipated that this type of new business model where network slice instances are leased to industry verticals as a service (i.e. Network Slcing as a Service, NSaaS) may become a norm in the near future.

3.1. Resource Centric Service Concept

Network services specify a set of resource requirements to offer desired Quality of Experience (QoE) to it consumers, using features offered by the control and forwarding planes. Traditional service guarantees are associated with resource attributes such as throughput, packet loss, latency, network bandwidth/burst or other bit rates and security. In addition, redundancy and reliability are provided by the infrastructure to improve over all QoE. More recently, concepts such as edge computing allow opportunistic placement of services to meet stringent requirments of low latency and/or high bandwidth applications.

Clearly the description of service delivery is more diverse now than before and demands higher degree of resource engineering and agility. The motivation behind Network slicing paradigm is to enable new service deployments without having to build new network infrastructures or causing disruptions to already deployed services in the network. In this regard, there are two primary characteristics NS should satisfy, a) Strict demand for network resource, b) Network Customization.

3.2. Strict Resource Demand

Several services are sensitive to response times and/or amount of bandwidth, e.g. realtime interactive multimedia, high bandwidth video feed or remote access to an enterprise network. Failure to meet these criteria leads to service degradation. Moreover, new industry verticals are evolving due to technological advancements in sensors, IoT, robotics and multi-media, along with new type of network interactions (both human-human or human-machine). These impose even stricter resource and connectivity requirements. The challenge lies in utilizing common network infrastructure and judiciously allocating available infrastructure resources.

3.3. Network Customization

To a network slice tenant, the ability to customize services dynamically is important. Customization gives control to the operator of a slice to create, provision and change network resources to suit their service demands. Customization enables decomposition of resources from an underlying network infrastructure and logically aggregate them as part of a slice. These customizations also include placement and logical connection of the network functions based on the service requirements.

3.4. NSaaS of Different Granularities

In order to meet various requirements from the network slice tenant, NSaaS should be be provided with different granularities. Some typical examples of granularities that a provider may offer are as follows.

During the realization of network slicing, it is also very important that sub-instance of a more general one can be provided with a finer granularity. In practice, it is up to the provider to decide the granularity to lease the network slice instances.

Editor's note: please revisit definitions for consistency.

3.5. Challenges in NSaaS

The flexibility and customization of different network slicing granularity introduce many challenges, especially in terms of network management and orchestration. As a network slice provider (provider of end-to-end slice orchestration), it is essential to have a comprehensive understanding of the network capability. This requires that network connectivity and resources can be exposed to the network slice tenants - the differentiated services offerers. Accordingly, network slice provider is able to orchestrate specific instances based on these exposed capabilities.

4. Network Slicing in 3GPP Mobile Network

Network Slicing is a core feature of the currently under development 3GPP 5G phase 1 mobile system, because it makes it possible for different vertical applications, such as IoT and broadband applications, to be deployed over a common infrastructure. More details can be found in [TS_3GPP.23.501], [TS_3GPP.23.502], [TR_3GPP.38.801], [TR_3GPP.33.899] and [TS_3GPP.28.500].

4.1. Network Slices in 3GPP Systems

In 3GPP systems a network slice is a complete logical network which provides telecommunication services and network capabilities. Distinct Radio Access Network (RAN) network slices and core network slices will interwork with each other to provide mobile connectivity. A device may access multiple network slices simultaneously through a single RAN.

3GPP defines slice IDs (named (S-)NSSAI in the standard) composed of a Slice Service Type (SST) and optionally a Slice Differentiator (SD). SST refers to an expected network behavior in terms of features and services (e.g. specialized for broadband or massive IoT), while SD helps distinguishing among several network slice instances.

Figure 1 describes the general layout of Network Slicing in mobile networks. A core network slice is composed, on the control plane side, of a Session Management Function (SMF), which manages PDU sessions, and, on the user plane side, of a User Plane Function (UPF) and possibly other functions. It is interconnected with a RAN Slice to complete the user plane. Some functions on the control plane are common and shared between multiple RAN and core network slices. A primary example of such a shared function is the Access and Mobility management Function (AMF).

           Common Functions   Core Network Slice Instance
          |   +--------+    |     +--------+      |
          |   | Control|    |     | Control|      |
     +--------+ Plane  +----------+ Plane  |      |
     |    |   | AMF... |    |     | SMF... |      |
 +---+--+ |   +--------+    |     +----+---+      |
 |Device| +-----------------+          |          |
 +---+--+ |   +--------+    |   +------+-----+    |
     |    |   |        |    |   | User Plane |    | +---------------+
     +--------+  RAN   +--------+ Functions  +------+Data Network or|
          |   |        |    |   | UPF...     |    | | The Internet  |
          |   +--------+    |   +------------+    | +---------------+
          RAN Slice Instance

Figure 1: 3GPP Network Slices

4.2. Challenges

A core challenge here is to identify or develop a set of technologies suitable to implement the infrastructure over which 3GPP Network Slicing will be built, without requiring major rework of the 3GPP specifications. Among the specific challenges that an IETF NS framework will need to address, it will need to support sharing network functions between several slices, building slices recursively from smaller slices, implementing roaming across different domains, etc. The following subsections describe creation, management and operation of 3GPP network slices as currently planned in the specifications, in order to better understand those challenges.

4.3. Creating 3GPP Network Slices

To create a network slice instance, mobile network operators will start by describing it by assembling together "Network Slice Subnets", which are smaller components included in a RAN or core network slice. Network slice subnets include NFs and reserved network resources, in term of KPIs such as minimum and maximum throughput, delay, packet loss, etc. Network slice subnets can be shared between several network slices. Both network slices and their subnets are described by the operator through the OSS/BSS management system. The OSS/BSS translates this input from the operator into descriptors that are sent to an orchestrator. The orchestrator, through the rest of the NFV-MANO system, configures compute and network elements to create network slice subnets and compose them as a network slice. Beyond creation, RAN or core network slice activation is orchestrated as the activation of individual subnets, possibly in a given order.

Network slices are isolated from each other to avoid control plane congestion on one slice (e.g. using one SMF in slice dedicated for broadband applications) to affect the control plane of other slices (e.g. to affect potentially critical IoT applications). Since some common core network functions (AMF, PCF, UDM, etc.) are shared between multiple dedicated core network slices, the interaction between shared NFs and NFs in dedicated network slices should be isolated from each other as well.

Network slices creation will support different combinations of "n" network services, "m" client devices and "p" interconnections with external (sliced or non-sliced) networks and services. In 3GPP, RAN and core network slices are typically dedicated to a certain type of network services such as broadband or IoT, but may serve one or more network services of this type. Additionally, in some mobile networks, parts of the core network may not be implemented over a slice, while others are (e.g. SMF could be in a slice, while common functions are not). While this can lead to a sub-optimal isolation between slices, this effect can be partially compensated by over- provisioning non-sliced sections of the network.

4.4. Managing 3GPP Network Slices

Mobile network operators can modify the configuration of a RAN or core network slices, while it is in use. Example of such operations include:

Some operations affecting a shared slice may not be possible without affecting other network slices, and in this case may be replaced by other operations: for example, instead of changing the configuration of a shared AMF to accommodate the needs of a SMF, another network slice subnet with an AMF may be created, and replace the original AMF's slice for this SMF. The management system monitors performance of individual network slice components and coalesce performance data and events for the whole RAN or core network slice. This includes user and control traffic load data, QoS/SLA data, e.g. indicating whether services were provided at expected QoS/SLA level. The management system uses this information for example to decide to scale up or down NFs. Performance data and events from a shared network slice component will be attributed by the 3GPP management system to one of the RAN or core network slices that contain or interact with this shared component. To support roaming, mobile network operators will need to configure the interconnection between network slices on the home network and network slices on the visited network. On the visited side, the operator ensures that the proper network slice is selected for a roaming device. User traffic will flow through the visited network slice either directly to an external data network, or through the interconnected home network slice (both cases will need to be supported). From the end user perspective only the performance of the whole (visited + home) network slice is important. Mobile network operators may expose limited 3GPP network slice management to third party communication service providers (CSP), who may in turn consume this service or provide it to their own customers, as a form of "Slice as a Service" described in Section 3. Using this interface, a CSP can request the creation of a network slice using specifications of NFs, isolation, security, performance requirements (such as traffic demand requirements for the coverage areas, QoS for service). When an operator exposes management data (e.g. fault management data, performance data) about a network slice shared by multiple customers of a CSP, exposed management data of each customer can be isolated from each other.

                                       Limited NS |        |
            Limited NS                 Instance   |Customer|
 +-------+  Instance   +-------------+ Management |        |
 |Mobile |  Management |Communication+<-----------+--------+
 |Network+<------------+Service      |
 |       |             |Provider     +<-----------+--------+
 +-------+             +-------------+ Limited NS |        |
                                       Instance   |Customer|
                                       Management |        |

Figure 2: 3GPP Limited Network Slice Management Exposure

4.5. Operating 3GPP Network Slices

Slice selection occurs in 2 phases: first, when initially registering with the network, the device lists the slice IDs it wishes support for. This list could be part of the configuration of the device. The network uses it, among other information like device capabilities, subscription information and local operator policies, to pre-select one or more RAN slices and core network slices. In this process, a set of 5G Common Control Plane Functions (CCNF) are selected to process future requests from the device. No resource reservation occurs at this stage. Later on, a particular application is started on the device. Using a slice ID associated with the application, the device requests from the network the establishment of flows for this application. For example, this slice ID can be associated to the application by the application service provider. This slice ID is used by the network to select the actual RAN slice and core network slice that will host user and control plane flows and network functions. In the user plane, network resource reservation (in term of KPIs such as maximum throughput, delay, etc.) is applied at the individual application flow level (e.g. at the PDU Session level in 3GPP terms). In the control plane, resource reservation can be performed in a less granular fashion, e.g. reservation may occur once for a given slice. During the lifetime of a device connection to a network, application flows will be established and maintained through a given set of common control plane function (CCNF), which may rarely change. In general, a single device and a single CCNF will therefore interoperate with multiple slices simultaneously (e.g. a broadband and a Tactile Internet slice).

                RAN uses Slide IDs |Device |
                    to select CCNF +---+---+
                                  \    |(Slide IDs, a.k.a. NSSAI)
               CCNF uses Slide IDs |  RAN  +-------------+
                to select slices   +---+---+---------+   |
                              \        |(Slide IDs ) |   |
                               +-------+--------+    |   |
                               | Common Control |    |   |
                               | Plane Network  |    |   |
                               |    Functions   |    |   |
                               |    (CCNF)      |    |   |
                               +-----+----+-----+    |   |
                                     |    |          |   |
                        +------------|---------------|-------+   |
                        |  +---------++        +-----+----+  |   |
                        |  | +------+ |        | +------+ |  |   |
                        |  | |CP NF1| |        | |UP NF1| |  |   |
                        |  | +------+ |        | +------+ |  |   |
                        |  |    ...   |        |    ...   |  |   |
                        |  | +------+ |        | +------+ |  |   |
                        |  | |CP NFn| |        | |UP NFn| |  |   |
                        |  | +------+ |        | +------+ |  +---+
                        |  +----------+        +----------+  |
                             Core Network Slice Instances

Figure 3: 3GPP Network Slice Selection

5. Role of NFV in Network slicing

Virtualization is a key enabler of network slices; Many network services can be easily deployed using components of NFV framework like network functions, hardware decoupling and resource placement [#?NFVSLICE]. When deployed as a network slice, the resources associated with virtualized network services are managed uniformly by infrastructure provider. One such use case is described below.

5.1. Virtualized Customer Premise Equipment

5.1.1. Traditional Customer premise equipments(CPEs)

A CPE is an equipment that connects the customer premises to the provider’s network. A CPE may either be a layer-2 or a layer-3 device (the routing gateway) performing different network functions depending on the access technology (DSL modem, PON modem, etc.). Any services provided such as Internet access, IPTV, VoIP, etc. or network functions for example, local NAT, local DHCP, IGMP proxy-routing, PPP sessions, routing, etc. are also part of CPE. The installation of different on premise devices, entails a high cost for service providers in terms of both initial installation and operational support, since they are typically responsible for the end-to-end service.

                             +-----+      campus
                        |----| CPEx | -----[     ]
                        |    +-----+
 -----        Broadband |    +-----+      branch
(     ) ----------------|--->| CPEy |------[     ]
( CSP  )           MPLS |    +-----+
(____)            access|    +------+      main site
                        |--->| CPEz |----- [     ]

Figure 4: Traditional CPE architecture

Traditional CPE deployments are shown in figure Figure 4. These are service provider network functions installed on customer site to provide above mentioned functionalities along with remote site connectivity. Communication Service provider (CSP) is responsible for management and administration of connections and state with proper policy, bandwidth, security and QoS requirements.

5.1.2. Trends in CPE infrastructure

A virtualized CPE architecture moves several network functions from on premise to the service provider network to facilitate provisioning of new services to customers based on a lean CPE functions on premises such as minimizing number of network functions on customer premises, perhaps only layer-2 visibility among them with no need for routing gateways in the home network is suppressed. Several routing, NAT, firewall capabilities may be performed in the service provider’s cloud. A customer’s site is highly simplified with vCPE solution, perhaps requiring only access level connectivity on premise and moving other network functions to ISP’s cloud.

A vCPE when combined with SD-WAN technology provides service guarantees for different enterprise applications and with a generalized sliced approach, the solution can be customized on per enterprise basis using a standard approach to delivery of WAN solutions to multiple enterprises.

|              +------+ |------------------+-------+       campus
|           |--|      | |                  | vCPEx | -----[     ]
|           |  |      | |------------------+-------+
|           |  |      | | <====Broadband ==>
|    -----  |  | vCPE | | -----------------+-------+       branch
|  (      ) |->|      | |                  | vCPEy |------[     ]
| (   CSP  )|  |      | |------------------+-------+
|  (_____)  |  |      | |<===  MPLS/4G. ==>
|           |  |      | |------------------+-------+    main site
|           |->|      | |                  | vCPEz |----- [     ]
|              +------+ |------------------+-------+

Figure 5: irtualized CPE, with distributed architecture

Figure 5 shows a virtualized architecture in which many functions are moved to CSP’s cloud simplifying CPE on premises tremendously. Additional details of deployment architecture models are captured in [I-D.pularikkal-virtual-cpe] where full dissemination of data path and control plane functions is described. The figure shows vCPEx, vCPEy, vCPEz are virtualized CPEs on multiple sites of a specific customer, there may be set of different network functions in each x, y and z CPE. The vCPE instance in CSP cloud is integrated to each site performing service chains of network functions and resource allocations specific for ingress and egress path of each site. Challenges

A vCPE is a well-known concept[VCPEBBF] which when combined with WAN technologies provides end to end visibility and reachability to remote sites. It has been solved using network function virtualization (NFV) approaches and via offload of compute intensive functions to the CSP cloud for ease of management by CSP. However, there is no standard approach to connectivity or management of various CPE functions. Furthermore, it is highly desirable for customers to control and monitor their own network resources at both remote and local sites. Using network slicing, a greater level of agility can be achieved, with each customer dynamically managing its own network with the assistance of network slicing framework.

5.1.3. vCPE as a network slice

The benefit of self-managing a vCPE network slice is the capability to move network functions on premise of to the cloud. An obvious use case will be customer initiated gradual migration of network functions from a site to CSP cloud.

   +-------------+       +-------------+
   | E2E Slice   |       | Slice       |
   | Orchestrator|       | Resource Mgr|
   +-------------+       +-------------+
         |                     ^
         | NS protocol or i/f  |
         V                     V
 |                                                  |
 |   +-------------+       +-------------+          |
 |   | vCPE Slice  |       | CSP         |          |
 |   | Mgr/Monitor |       | vCPE subnet |          |
 |   +-------------+       +-------------+          |
 |                                                  |
 |  +--------+  +--------+  +--------+  +--------+  |
 |  | vCPEy  |  | vCPEy  |  | trans  |  | vCPEz  |  |
 |  | subnet |  | subnet |  | subnet |  | subnet |  |
 |  +--------+  +--------+  +--------+  +--------+  |
 |                                                  |
         |                               |
         | NS transport protocol or i/f  |
         V                               V
    [Campus]    [branch]    [Transport] [main site]

Figure 6: vCPE as a Network Slice

Editor's Note: TODO: here we have inconsistencies between the drafts and more importantly with the 3GPPP and TM forum.

In Figure 6, a slice for vCPE is shown. Using slice subnet approach, each vCPE site instance may be considered as an abstracted subnet, along with the WAN transport as another subnet. The network functions are chained in a distributed fashion between site vCPEs and CSP vCPE subnet. A monitoring function interfaces with CSP’s global slice manager for resource management. A south-bound interface through network slice transport protocol, realizes these functions on the infrastructure. Required Characteristics

Having a dedicated sliced network catering to dynamic customization of network functions with guaranteed resource method, simplifies network operations. In case of such vCPE type solutions, it is common for each customer to have its own private IP address space, therefore, the resource isolation must include address isolations as well. This may be achieved based on existing label techniques or through new network slicing data path protocol. Using NSaaS characteristics, network customization allows a tenants vCPE slice to place and manage NFs either from cloud or on-premise. While, the guarantees in connectivity through SD-WAN transport aligns with strict resource demand characteristic.

6. Services with Resource Assurance

6.1. Enhanced Broadband

Today, video consumes the largest amount of bandwidth over the Internet. As the higher resolution formats enter mainstream, even more bandwidth will be needed to stream 4K/8K/360 degree formats. The scenario in this section are discussed in regards to need for demands beyond best-effort network delivery, in particular requirements due to growth in data rate capacity, connection density and interactive media. These are equally applicable to both fixed and mobile networks.

6.1.1. Media delivery networks

                                                         |=>| DASH|
                                                         |  +-----+
 +------------+    +-------------+     -----     +-----+ |  +-----+
 | Content    |<==>| Transcoding |<=> (     ) ==>| CDN |=|=>| HDS |
 | Aquisition |    | Function    |   (  ISP  )   +-----+ |  +-----+
 +------------+    +-------------+    (____)             |  +-----+
                                                         |=>| HLS |
                                          Media delivery formats

Figure 7: Traditional Streaming Media Infrastructure

6.1.2. Enhanced Media Streaming Description

Today the video output format is HD with 1080p resolution with few services delivering up to 4K. Both Video-on-demand and live-linear channels (streaming live event feed) can be supported. Factors Influencing Enhanced Broadband Use Cases

Different service components of media delivery are shown in Figure 7 above and often an overlay or OTT infrastructure is used. A MBB service deployment requires acquiring content, transcoders and CDN servers and decoders (DASH, HLS, HDS etc) to support different delivery formats to different types of terminals. These can be viewed as specialized service functions in media streaming infrastructure. In the current form, the entire operation is (a) not flexible in terms of resources placement (on premise vs cloud vs proximity to destination), (b) is built on best-effort network of what's available resources, (c) Is slow in reactinf to network congestion leading to client-server based end to end stream optimizations derived from network conditions. Traditional Media Streaming Service Verticals

Another variation to media streaming is differentiation of resource requirements for different kinds of service deliveries. There are at least 3 different categories of media or content distribution:

Video on Demand (VOD)
Live streaming/Linear channels
Video conferencing

While (1) and (1) are one way content consumption, video conferencing requires 2-way or multi-way connection. It may consist of either person-person or person-group video communication. while buffering is feasible for VoD, realtime/live feeds need no buffers, avoid restransmissions and expect lower latency. New Verticals - Virtual Reality (VR)/Augmented Reality (AR)

Virtual Reality(VR)/Augmented Reality(AR) is the future use case of eMBB services. A 360-degree video in comparison is a lower resolution, requiring ~25 Mbps network bandwidth for streaming. For a network based AR/VR bandwidth required will be in the order of Gbps and latency less than 10 milliseconds for a fully immersive experience such as cloud-based VR gaming, fully-interactive media experience. Notably, media processing for AR/VR will remain same as in-network processing functions as shown in Figure 7 and high latencies between components could lead to downgrade of user experience. Therefore, an AR/VR stream requires a special infrastructure that differs from best-effort network.

6.1.3. eMBB Type Slices

A purpose-built network slice for eMBB streaming shall ensure to minimize processing overheads, it may be done by placement of network functions closer to subscribers.

    |     E2E Slice Orchestrator       |
    |                                  |
    |       +------------------+       |
    |       | eMBB Resource    |       |
    |  +--> |    Spec Guard    |---+   |
    |  |    +------------------+   |   |
    |  |                           |   |
    |  |    +----------+-------+   |   |
    |  +--->|  Resource Monitor|<--+   |
    |       +---------+--------+       |
    |           ^             |        |
                |             |
                | Real time feed|back
                |             |
    eMBB        |             |
    Network     |             v dynamic resource adjustment
 | +----------+-------+    +-----------+ |
 | |  Acquired Content|<-->| eMBB slice| |
 | |      subnet      |    | Customizer| |
 | +---------+--------+    +-----------+ |
 |         |       |                     |       +-+
 |         |       |                   =======>  | |
 |  +--------+  +-------+              | |       +-+  handheld
 |  | CDN1   |  | CDN2  |              | |      +---+
 |  | subnet |  | subnet|              ========>|   |
 |  +--------+  +-------+              | |      +---+ PC
 |      |          |                   | |
 |  +-----------------+                | |     +---------+
 |  | Encoders subnet |================+=+====>|         |
 |  +-----------------+                  |     +---------+ TV

Figure 8: Reference eMBB slice

See Figure 8 above for a reference slice.

6.1.4. Required Characteristics

A typical eMBB slice from a network operator is performance oriented service customization. An eMBB service slice template will allow a tenant to request or specify 1. CDN components (as service functions) - Regional network locations of CDN , encoders etc. - Location of acquired content. - Describes transport constraints for its own distribution network comprising of connectivity between content acquisition and Fan-out points. 2. A granularity of transport resource scaling. 3. An interface to subscriber database from multiple access network types (cellular, fixed). 4. Live performance monitoring - Through interface to network slice resource monitoring and negotiation loop. - A well-coordinated network slice protocol that enables resource allocation across different network domains.

Note in addition to eMBB, traditional CDN use cases can be deployed in a slice as well, see examples in [RFC6770].

|                    +-----------------------+                |
|          +-------->| E2E Slice Orchestrator|<----+          |
|          |         +-----------------------+     |          |
|          |                                       |          |
|   +------+-----------+               +-----------+-------+  |
|   |     Global       |               |     eMBB Slice    |  |
|   | Resource Manager |<------------> | Resource Allocator|  |
|   +------------------+               +-------------------+  |
|                                                             |
             |                        |
     -------  NS control -------------- NS control--
             |                        |
   ------------------          -----------------
  |  --------------  |        |  -------------- |
  | | eMBB Manager | |        | | eMBB Manager ||
  |  --------------  |        |  -------------- |
  |                  |        |                 |
  |                  |        |                 |
  |  --------------  |        |  -------------- |
  | | eMBB Network | |        | | eMBB Network ||
  | |--------------  |        |  -------------- |
  --------------------         -----------------
           | |                       | |
           V V                       V V
 ------------------NS transport ----------------
         |                  |             |
         V                  V             V
   ----------------  ----------------  -----------
  | Infrastructure | |Infrastructure | | DC       |
  |  Domain A      | | Domain B      | | Domain C |
   ----------------  ----------------  -----------

Figure 9: Transport provider network operator view. shows deployed eMBB slice components for reference.

6.2. Massive machine to machine communication

6.2.1. Wireless Sensor Networks

Sensor networks are widely deployed in industries such as agriculture, environmental monitoring and manufacturing. The general workflow of wireless sensor network is provided in Figure 10.

      6.Decided Behavior
     |                   |
+----v------+            |
|  Sensor   |            |
|(1. Data   |            |
|Collection)|            |
+----+------+            |
     |2.Collected Data   |  3.Aggregated  +---------------------+
     +------------->+----------+ Data     |     Data Center     |
                 |  Sink Node/ |----------> (4. Data Analysis   |
                 | Base Station|          |         &           |
     +---------->+--------------+--<------|  Behavior Decision) |
     |2.Collected Data   |  5. Decided    +---------------------+
+----+------+            |     Behavior
|  Sensor   |            |
|(1. Data   |            |
|Collection)|            |
+----^------+            |
     |                   |
      6.Decided Behavior

Figure 10: Workflow of wireless sensor network

As Figure 10 shows, sensors mainly collect data & behavior; rarely communicate with each other in traditional wireless sensor network. While in the scenarios discussed in this section, sensors or embedded devices will be more intelligent and carry out more frequent interactions that raises more challenges for mobile networks.

6.2.2. Massive Internet of Things Description

Machine-to-machine type communication will dominate communication paradigm in various industries such as healthcare, manufacturing, transportation, etc. In order to support the massive internet of things, traditional mobile networks have to be redefined — by creating the connectivity fabric for everything and bringing new levels of on-device intelligence. Factors Influencing Massive Internet of Things Use Cases

There are three main challenges raised by Massive Internet of Things use cases: New Massive Machine Type Communications (mMTC) Verticals

A few examples of new types of scenarios that require unique infrastructure are mentioned below. Smart City

Smart city networks is an integration of several public infrastructures together through M2M communications. For example

Building a smart city requires a variety of IoT networks to inter-operate together; these IoT networks are run by different departments with different access privileges for administration and access control. A smart-city network should be isolated from the public Internet. E-Health

E-health refers to the application that remote monitor the physical conditions (e.g., heart rate, pulse, blood pressure etc.), and accordingly take necessary medical measures remotely. Being a life-critical service, e-health communication network must be reliable and fast but small-size of data exchange. In addition, the privacy and security of user’s data must be guaranteed.

6.2.3. mMTC Type Slices

mMTC involves potentially a large number of small and power-constrained devices, therefore, resource allocation at scale is of particular importance in mMTC type slices. Furthermore, different kind of IoT devices may exhibit quite different traffic patterns e.g., continuous (heart rate monitors) & periodic delay tolerant (temperature sensors), delay sensitive (e.g., weather forecast & disaster alerting), mobility mode, security awareness etc. The mMTC type slices should be conscious of various requirements of scale, data pattern, reliability, security and energy efficient communications.

6.2.4. Required Characteristics

Different from eMBB and uRLLC type services, mMTC service does not have so much strict requirements on bandwidth and latency. Massive and ubiquitous connectivity support would become the biggest challenge of mMTC service. That is, for an network operator, mMTC is mainly concentrated in the access network side and most of the information flow should not pass through the transmission or core network, both for security and communication efficiency. The mobility management IoT gateway functions could be placed closer to terminals (e.g., base-stations, edge clouds, etc.). Consequently, an mMTC type slice should consist of plentiful access network resource, as well as normal yet reliable transmission network and core network resources in general.

6.3. Ultra-reliable low latency communication

6.3.1. Brief introduction

Not only, mission critical communication services but industrial manufacturing, production processes, remote medical surgery, and transportation safety (high mobility cases), etc scenarios require ultra-reliable communications with no packet loss.

6.3.2. Challenges

In uRLLC scenarios, both data and control planes may require significant enhancements to transmission or information distribution protocols. [TR_3GPP_38.913] specifies generic KPIs for access network user plane latency as 1ms and reliability factor of 99.999% for transmission of a packet of size 32 bytes. Although KPIs vary for different scenarios such as V2X(3-10ms, 99.999%), eMBB (4ms UL/DL each), In order to meet these, latency and reliability of the transport in mobile networks should also be considered.

6.3.3. New service verticals

In the following sections three new uRLLC scenarios are described. Industrial Operation and Inspection

Operations in remote industry sites usually need the support of mobile transport network. Accurately operating machinery (low latency and jitter) from remote locations requires high-quality communication links between the control site. Factors to consider * low latency and low jtter in communication path * Short time interval between an operator sending control signal tp equipment response.

In an industrial closed control loop (Sensor –Controller – Actuator) as shown in figure Figure 11, a typical control cycle time where network is involved should be below 10ms [White-paper-5GAA].

++++++++++   +++++++++++++++
+ Sensor +-->+ Transmitter +---+
++++++++++   +++++++++++++++   |
                               |   ++++++++++++     ++++++++++++++
                               +-->+   Base   +---->+ Controller +
                               +---+ Station  +<----+            +
                               |   ++++++++++++     ++++++++++++++
++++++++++++   ++++++++++++++  |
+ Actuator +<--+   Receiver + <--+
++++++++++++   ++++++++++++++

Figure 11: Industrial closed control loop Remote Surgery

Remote surgery which enables surgeons to perform critical specialized medical procedures remotely, allowing their vital expertise to be applied globally. Providing accurate control and feedback for the surgeon entails very strict requirements in terms of latency, reliability and security. Vehicle-To-Everything (V2X)

Vehicle-To-Everything (V2X) network uses precise knowledge of the traffic situation across the entire road/highway network to optimize traffic flows, reduce congestion, and minimize accidents. For uRLLC scenario,

6.3.4. Required Characteristics

A uRLLC network slice only accepts service specifc traffic and discards any other type of traffic to avoid negative impact on uRLLC service operation. Even within the same vertical different kind of services should be isolated. For example, in the V2X vertical, the network slice used for autonomous driving should not be used for in-vehicle infotainment. Capabilities required by uRLLC service provider include

From a network operator provides a uRLLC Slice with following considerations

The Figure 12, shows provider and operator view of the network. The monitoring of resources is done in the context of performance. A performance degradation would require resource adjustment. As shown in Figure 12, in one possible sliced model will have its own customizer that uses internal performance observing logic with in its slice by coordinating with different subnets/domains using southbound NS transport protocol and transfers this information to operator via a northbound NS protocol for resource adjustment.

It is implied that domains maybe different access technologies and need for a common performance metric propagation and resource allocation is important for a uRLLC slice to function properly.

|    E2E  Slice Orchestrator  |
|                             |
|       +---------+ +-----+   | uRLLC service +---------+
|       | Resource| | Perf| <-|---------------| uRLLC   |
|  +--- | view    | | Spec|   |  template     | service |
|  |    +---------+ +-----+   |               +---------+
|  |    +----------+--------+ |
|  +--->|Performance Monitor| |
|       +---------+------^--+ |
|                        | |  |
                         | | resource adjustment
                         | |
     performance  metrics| |
                         | |
  uRLLC slice            | v
| +--------+--+    +-----------+      |
| |  Subs     |<-->|uRLLC slice|      |
| |  Mgmt     |    |Customizer |      |
| +-------+---+    +---------^-+      |
|       +-------+------------|        |
|       |       |        +---v-----+  +
|  +--------+  +-------+ | micro   |  |
|  | GC-1   |  | GC-2  | | resource|  |
|  | subnet |  | subnet| | mgr     |  |
|  +--------+  +-------+ +---------+  |
|     |          |                    |
     | |        | |
     V V        V V
------------NS transport --------------
|                  |             |
V                  V             V
+--------------+  +------------+ +----------+
|  Domain A    |  | Domain B   | | Domain C |
+--------------+  +------------+ +----------+

Figure 12: Reference for uRLLC Network Slice.

6.4. Critical Communications

Critical communications are associated with emergency situations. Often referred to as mission critical, the communication has to be reliable and non-disruptive. Different scenarios of critical communications relate to public safety responders (e.g. firefighters, paramedics), military, utility or commercial applications, mainly using reliable voice or short data messaging over wireless communication systems.

6.4.1. Enhanced Public Safety Infrastructure

Traditional technologies for emergency communications are narrow band radio networks such as Land Mobile Radio (LMR) systems. Related systems such as [TETRA] or [P25] have dedicated frequencies and channels assigned to individual groups of users for instant voice or short messaging connection with a simple interface. Next-generation public safety communications are planned to be built with enhanced broadband voice, data and video communications services beyond narrowband LMR with broadband LTE networks for high speed data (ref 22.179 and FirstNet). Role of Transport and Fixed Networks

3GPP defined on-network critical communication can be established both - (a) over the network infrastructure to manage the call, (b) off-network, where the terminals communicate directly to each other. In slicing context, off-network is not not relevant to the topic, while, over the network, involves transport networks for a always available, reliable, and zero packet loss quality of traffic support to meet critical services requirements. Challenges for Enhanced Critical communication

Maintaining a separate broadband infrastructure for critical communications incur the following challenges:

Deployment Cost: Especially, as the coverage of this separate network has to be extended to large-scale nationwide geographies that is interoperable is not cost effective. As new communication technologies emerge, public safety systems will have to bear the state of the art adoption cost.
Lack of flexibility: in terms of adding new value added services or ability to take advantage of commercial services.

While shared infrastructure, brings out challenges of these kind:

Reliable support: Of basic mission critical services: Such as loss of information in voice communication is not acceptable in emergency services, if common infrastructure is to be used, it must assure no loss of information.
Zero congestion: It is not acceptable for critical calls to be delayed at call setup times or be subjected to any other congestion scenarios.

6.4.2. Enhanced Critical Service Type Slices

Having the eMC (enhanced mission critical) network slices benefit from the following:

eMC network slices are relatively straight forward as it only concerns with guaranteed bit rate (GBR) on per media basis and management of groups. From transport they should be able to request transport services based on GBR for reliable communication. A reference network slice in Figure 13 below, shows a mission critical (MC) organization providing service agreement through a network slice template with resource specification. The eMC slice sets up different subnetworks of different subscriber groups and manages its membership. These subnets are realized into the infrastructure across different domains through a network slice transport mechanism. The eMC must be capable of active resource monitoring to prevent congestions to ever occur as well as request additional transport resources in case of emergency event occurrence.

|     E2E Slice Orchestrator       |
|                                  |
|       +------------------+       |  service   +------------------+
|       | eMBB Resource    |       |<-----------| Mission Critical |
|  +--> |    Spec Guard    |---+   |  agreement |    Organization  |
|  |    +------------------+   |   |            +------------------+
|  |                           |   |
|  |    +----------+-------+   |   |
|  +--->|  Resource Monitor|<--+   |
|       +---------+--------+       |
|           ^             |        |
            |             |
            | Resource request
            |             | prioritized resource adjustment
  MC Network|Slice        v dynamic group management
| +----------+-------+    +-----------+ |
| |  Group Subs Mgmt |<-->| MC slice  | |
| |                  |    | Customizer| |
| +---------+--------+    +-----------+ |
|         |       |                     |     +-+
|         |       |        +---------+  + +-->| |
|  +--------+  +-------+   | GRP     |  |     +-+ MC-UE
|  | GC-1   |  | GC-2  |   | selector|  |     +-+
|  | subnet |  | subnet|   +---------+  | --->| |
|  +--------+  +-------+                |     +-+ MC-UE
|      |          |                     |
  | |                       | |
  V V                       V V
------------NS transport ----------------
|                  |             |
V                  V             V
----------------  ----------------  -----------
| Infrastructure | |Infrastructure | | MC server|
|  Domain A      | | Domain B      | | Domain C |
----------------  ----------------  -----------

Figure 13: Reference for Mission Critical Network Slice.

7. Network Infrastructure for new technologies

7.1. ICN as a Network Slice

ICN as in Information-Centric Networking is a culmination of multiple future Internet research efforts in various parts of the world, now being pursued under IRTF’s research task group called [ICNRG].

7.1.1. Information Centric Networks Description

Information-Centric Networking (ICN) addresses Internet’s network architectural design gaps based on evolving applications requirements and end user behavior which is significantly different from what IP was designed for, which was optimized for host-to-host communication paradigm. ICN is a non-IP paradigm based on name-based routing and offers many desirable networking features to applications such as, caching, mobility, multicasting and computing in a manner different from traditional host-centric communication model. ICN paradigm is aligned with the service-centric architectures enabled through frameworks like SDN, NFV, and Edge Computing. At a high level, ICN offers a name-based abstraction to application that doesn’t require further translation (as in domain names to IP mapping in current IP networking), making it suitable to several communication modalities such as multi-point-to-multi-point, D2D and Ad hoc communication. New Verticals – ICN based service delivery

Services over ICN slices can take advantage of its features such as:

In ICN, applications, services and content are addressed using names, hence end host resolution services like DNS can be avoided, this achieves name resolution to edge content or services without incurring additional RTT delays.
Service flows will be offered mobility and multicasting support, as the networking is session-less and optimized towards efficient movement of named data or networking named services and host level communication.
Services can be deployed at the very edges with ease as ICN routers are compute friendly, this is because states in the forwarding table can be that of either content or service resources.
Further saving bandwidth in the upstream link through opportunistic caching is an inherent feature of ICN, this also leads to energy efficient networking. Considerations for ICN Applications

When offered as a programmable and customizable logical network slice, ICN based services can be offered as a network slice in parallel with traditional IP based services. ICN can be realized as a slice [_5GICN_] based on the choice of data plane resource offered by the operators in different domains of the network such as the access, core network or main data centers. While the same resources can be used to support services over IP, proper resource isolation shall allow it to co-exist with ICN slices as well. ICN though initially was aimed to serve CDN applications such as video-on-demand or general web content distribution, it is equally adept to server real-time applications such as audio/video conferencing [ICN-AV], AR/VR applications, or IoT services. ICN slices can be offered over a network slicing framework built upon a programmable pool of software and/or hardware based data plane resources. Heterogeneous mix of pool of infrastructure resourcesis possible such as : Hardware decoupled network functions as in containers or VMs. Deeply programmable hardware resources include GPU, FPGAs [ClickNP], Smart NIC [Netronome] operated using P4 abstractions, that are supported over x-86 platform. Programmable hardware may also include commercial chips supported using P4 or POF allowing one to realize high performing novel data planes, e.g. [Barefoot]

7.1.2. ICN Type Slices Asks

In ICN, applications use Interest/Data abstractions over named resources resolved by ICN’s routing plane. An ICN slice shall be a programmable ICN-domain, in which content learning and distribution will be done using existing or new ICN aware routing and data plane protocols. As a result, it should be possible to deploy network functions such as ICN routers and content producers and distributors that serve and speak ICN protocols. Just as multiple service instances can be part of a slice, an ICN slices can multiplex heterogeneous services; on the other hand an ICN slice can be as granular as a service instance too. The latter approach has implications with respect to consumer privacy, access control of name data objects, and granularity of mobility handling.

7.1.3. Required Characteristics

A basic ICN slice can be manifested as a resource isolated logical network while sharing resources with other connectivity or service slices. An ICN slice relies on programmability and virtualization framework to manage the service slices, to allow maximum flexibility through ICN aware logically centralized control plane for icn service and slice management.

How multiple services will be deployed within an ICN aware slice may or may not be exposed to the network operator, depending on if the ICN slices are natively managed by it or a by other service providers.

7.2. Network Slices in Communication Endpoints

In this section connected endpoint use case are described to highlight significance of slicing in an end point.

7.2.1. Connected Vehicle

Connected vehicles are example of scenarios where a communication end point is split into 3 different type of services that vary in in terms of topology, bandwidth, latency, mobility and security.

V2I in short-range: requires ad hoc routing protocol, reliable data plane and higher layer security and authentication;
Traditional broadband for Infotainment: requires high speed connection bandwidth.
In network assistance for localized services: low speed, reliable connection for a short period of time. This service need to be highly secure and isolated because it connects vehicle to manufacturers who can alter component settings.

7.2.2. Sliced Terminal

A terminal, if authorized may be allocated dedicated resource for mission critical services and best-effort slice for normal connectivity.

7.2.3. Required Characteristics

A network operator that registers a subscriber is required to know how a terminal is used and which services, offered as a slice it is part of. A highly secure 3-way authentication between an operator, service provider and terminal is required to enable a slice on a device.

8. Overall Use case Analysis

The discussion in above use cases can be summarized as following in terms of the requirements for network slicing framework.

8.1. Requirements Reference

The following functional requirements are derived from discussions in above sections. They are described in details in [I-D.qiang-netslices-gap-analysis] document:

The differentiated services described in this document are in the context of sharing common network infrastructure. They also demonstrate several common functionalities. Therefore, a homogenous approach towards deployment and management is absolutely necessary.

8.2. Mapping Common characteristics to Requirements

8.2.1. Req.1 Network Slicing Resource Specification

Resource Reservation: compute and network resources are reserved as part of initial creation and subsequent maintenance of a slice. For example, a service may initially reserve resources for its own control plane, and then later it may reserve user plane flows for applications on demand. Reference use cases: Differentiated services discussed in section “Services with Resource Assurance”.
Transparency: Network slicing does not change the functionality of a scenario; It only facilitates creation of an isolated, an independently run infrastructure for that use case over a common network. Transparency promotes inter-operability and a common resource specification enables it.
Multi-access knowledge: Many services are scoped within an access domain that could be either fixed, wireless or cellular network. Each network domain has different characteristics, for example, it may use layer-2, layer-3 or MPLS connectivity or radio network. Dissemination of normalized resource characteristics should be done uniformly across all domains to simplify slice deployment.
Multi-dimensional service vertical: Network slicing supports dynamic multi-services, multi-tenancy and the means for backing vertical market players.

8.2.2. Req.2 Cross-Domain Coordination

Multi-domain coordination: Multi-domain refers to different technology related network domains. For example, it may be RAN, DSL etc, mobile core network, ISP or different domains in transport networks such as carrier ethernet, MPLS, TE-tunnel etc. Often, they are under same administrator's control but may require coordination across different administration. All scenarios mentioned require multi-domain coordination to connect and administer different subnets.
Automated Network Slice Management: Network slicing would need to be self-managed with automated deployment in order to cope with scalability.
Resource Assurance: All resource centric scenarios require on-demand and dynamic adjustments. It may not be possible to achieve this using centralize or API approach with fine granualrity of resources participating in constrained path computation. It can also be difficult to coordinate across different domains. Therefore, a network slice transport protocol that standardizes resource propagation in different subnets is needed. It is important for protocol (or interface) to be lightweight and distributed.

8.2.3. Req.3 Guaranteed Slice Performance and Isolation

Performance Isolation: resource or traffic congestion in a slice should not affect traffic on other slices sharing the same infrastructure.
Secure Isolation: network services hosted on a slice should not be able to breach into other slices deployed over the same infrastructure, e.g. a network function should not be able to intercept or inject traffic on another slice it is not connected to.
Operational Isolation: Each network slice may have its own operator that sees this slice as a complete network (i.e router instances, programmability, using any appropriate communication protocol, caches, provide dynamic placement of virtual network functions according to traffic patterns, to use its own controller, finally it can manage its network as its own).
Reliability: It is an important resource attribute in the type of service verticals described above. Many services verticals cannot deliver functionality unless the network is reliable (See remote industry operation, remote surgery and other uRLLC applications).
Function Sharing: a given physical or virtual function or possibly slice subnet may be interconnected with more than one slice simultaneously. Examples include a client device or, in 3GPP systems, the AMF. An auto discovery of such attributes is necessary as an exception to isolation.
Slice identification: It is needed to uniquely specify and resolve resources and for slice-lifecycle in management plane. In control and data plane identification isolates and secures resources among the slices.

8.2.4. Req.4 OAM Operations with Customized Granularity

Independent per slice management plane: Since a sliced network is purpose-built, the intelligence to run, control, manage, operate and administer a slice is with the provider of service in a slice.

8.3. Mapping Common Characteristics to Requirements

The above discussion is summarized in Figure 14 as below:

| Scenario/  |          driving factors           |    Mapped  |
| service    |                                    |Requirements|
| eMBB,uRLLC,| (a) uniform resource reservation   |  REQ.1     |
| mMTC       | (b) multi-access  connectivity     |            |
|            | (c) transparency for portability   |            |
| 3GPP       |   and inter-operability to support |            |
| NSaaS      |   differentiated service verticals.|            |
| AR/VR,V2X  | (a) Total resource required is sum | REQ.2      |
| NSaaS      | of resource in each subnet part of |            |
|            | slice.                             |            | 
|            | (b) Dynamic adjustment is necessary|            |
|            | (c) Abstraction is important       |            |
|            | both for secure exposure of network|            |
|            | and resource components in multi-  |            |
|            | domain/operator E2E slice concept. |            |
|  NSaaS     |  Need mechanisms to ensure         |    REQ.3   |
|  remote    |   (a) E2E resource Isolation       |            |
|  surgery,  |   (b) Secure Isolation             |            |
|  industry  |   (c) Operational Isolation        |            |
|emergency   |   (d) Performance isolation        |            |
|            | (a) Independent per slice manage-  |    REQ.4   |
|  NSaaS     | ment plane                         |            |
|            | (b) E2E orchestration              |            |

Figure 14

Table: Mapping Common Characteristics to Requirements

8.4. Other Challenges and Considerations

These observations impose several challenges on network transport.

Within each domain it should be permissible to deploy different traffic engineering techniques, for example, FlexE, MPLS, RSVP-TE, DETNET or SDN based TE.
Within each domain different transport techniques may be deployed, for example L2 or L3 virtual networks such as VLAN, GUE, VxLAN, etc. or Software Function Chaining (SFC) such as NSH.
No two network infrastructures are alike, technologies such as, edge computing, NFV, SDN, cloud are partially deployed today. There is no assumption about whether a service is available as a physical node or a virtual node.
Optimal placement of resources on-demand is only possible when infrastructure supports it. A capability exposure of a domain could facilitate such functions.
At a massive scale, it is extremely complex to centralize global view of resources and be able to monitor and distribute on-demand. Incorporating domain-to-domain communication about data and control for a specific network slice shall be considered.

The challenge lies in stitching end to end slice monitoring and customization through above described multi-dimensional heterogenity.

Network operators would exploit network slicing for:

9. Conclusion

A service should typically need a network slice for one of those reasons:

The service cannot provide optimal experience on a best-effort network.
It is inefficient and expensive to build a separate infrastructure.

The separation from a generalized network, should allow new services to use newer or different protocols in network, transport and management layer/plane for that service (as in the case of ICN, mMTC, uRLL). The goal of Network slices is to offer enriched service verticals with very different network capability and performance demands but also simplify from the traditional service delivery models.

There is need for a uniform framework for end to end network slicing specifications that spans across multiple technology domains and can drive extensions in those technolgy-areas for support of Network slices.

10. Security Considerations

The security considerations apply to each kind of slice. In addition general security considerations of underlying infrastructure whether isolated communication with in a slice apply for links using wireless technologies.

11. IANA Considerations

There are no IANA actions requested at this time.

12. Acknowledgements

Thanks to the following reviewers for providing details for several use cases and for helping with review of the document.

Stewart Bryant (, Hannu Flinck (, Med Boucadair (, Dong Jie (

13. References

13.1. Normative References

[I-D.dt-detnet-dp-sol] Korhonen, J., Andersson, L., Jiang, Y., Finn, N., Varga, B., Farkas, J., Bernardos, C., Mizrahi, T. and L. Berger, "DetNet Data Plane Encapsulation", Internet-Draft draft-dt-detnet-dp-sol-01, June 2017.
[I-D.geng-netslices-architecture] 67, 4., Dong, J., Bryant, S.,, k., Galis, A., Foy, X. and S. Kuklinski, "Network Slicing Architecture", Internet-Draft draft-geng-netslices-architecture-01, June 2017.
[I-D.pularikkal-virtual-cpe] Pularikkal, B., Fu, Q., Hui, D., Sundaram, G. and S. Gundavelli, "Virtual CPE Deployment Considerations", Internet-Draft draft-pularikkal-virtual-cpe-02, February 2017.
[I-D.qiang-netslices-gap-analysis] Qiang, L., Martinez-Julia, P., 67, 4., Dong, J.,, k., Galis, A., Hares, S. and S. Slawomir, "Gap Analysis for Transport Network Slicing", Internet-Draft draft-qiang-netslices-gap-analysis-01, July 2017.
[P25] "Project25"
[RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, K. and G. Watson, "Use Cases for Content Delivery Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, November 2012.
[TETRA] ETSI, "'TETRA and Critical Communications Evolution (TCCE)'", Jun 2017.

13.2. Informative References

[_5GICN_] IEEE Communication, "Delivering ICN Services in 5G using Network Slicing. 'Asit Chakraborti, Syed Obaid Amin, Aytac Azgin, Ravi Ravindran, G.Q.Wang'", May 2017.
[Barefoot] Barefoot, "Barefoot", 2017.
[ClickNP] ACM SIGCOMM, "ClickNP: Highly Flexible and High Performance Network Processing with Reconfigurable Hardware. 'B. Li, et al'", 2017.
[ICN-AV] IEEE Transaction on Emerging Network Architecture (under submission),, "SRMCA: Scalable and Realiable Multimedia Communication Architecture. 'Asit Chakraborti, Syed Obaid Amin, Aytac Azgin, Ravi Ravindran, G.Q.Wang.'", 2017.
[ICNRG] IRTF, "ICN Routing Group", November 2016.
[Netronome] Netronome, "Netronome", 2017.
[TR_3GPP.33.899] 3GPP, "Study on the security aspects of the next generation system", 3GPP TR 33.899 0.6.0, November 2016.
[TR_3GPP.38.801] 3GPP, "Study on new radio access technology Radio access architecture and interfaces", 3GPP TR 38.801 1.0.0, March 2017.
[TR_3GPP_38.913] 3GPP, "Study on scenarios and requirements for next generation access technologies", 3GPP TR 38.913 14.2.0, March 2017.
[TS_3GPP.23.501] 3GPP, "System Architecture for the 5G System", 3GPP TS 23.501 0.2.0, February 2017.
[TS_3GPP.23.502] 3GPP, "Procedures for the 5G System", 3GPP TS 23.502 0.2.0, February 2017.
[TS_3GPP.28.500] 3GPP, "Telecommunication management; Management concept, architecture and requirements for mobile networks that include virtualized network functions", 3GPP TS 28.500 1.3.0, 11 2016.
[VCPEBBF] Broadband Forum, "TR-345 Broadband Network Gateway and Network Function Virtualization", Dec 2016.
[White-paper-5GAA] 5G Automotive Association, "The Case for Cellular V2X for Safety and Cooperative Driving", November 2016.

Authors' Addresses

Kiran Makhijani Huawei Technologies 2890 Central Expressway Santa Clara, CA 95050 EMail:
Jun Qin Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing , 100095 EMail:
Ravi Ravindran Huawei Technologies 2890 Central Expressway Santa Clara, CA 95050 EMail:
Liang Geng China Mobile Beijing , 100095 EMail:
Li Qiang Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing , 100095 EMail:
Shuping Peng Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing , 100095 EMail:
Xavier de Foy InterDigital Inc. 1000 Sherbrooke West Montreal , Canada EMail:
Akbar Rahman InterDigital Inc. 1000 Sherbrooke West Montreal , Canada EMail:
Alex Galis University College London London , U.K. EMail: