Internet DRAFT - draft-netslices-usecases
draft-netslices-usecases
None K. Makhijani, ed
Internet-Draft J. Qin
Intended status: Informational R. Ravindran
Expires: April 21, 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
G. Fioccola
Telecom Italia
October 18, 2017
Network Slicing Use Cases: Network Customization and Differentiated
Services
draft-netslices-usecases-02
Abstract
Network Slicing is meant to enable creating (end-to-end) partitioned
network infrastructure that 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 use 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 https://datatracker.ietf.org/drafts/current/.
Makhijani, ed, et al. Expires April 21, 2018 [Page 1]
Internet-Draft Netslicing use cases October 2017
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 April 21, 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
(https://trustee.ietf.org/license-info) 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. A Generalized Network Slice as a Service . . . . . . . . . . 6
3.1. Resource Centric Service Concept . . . . . . . . . . . . 6
3.2. Strict Resource Demand . . . . . . . . . . . . . . . . . 7
3.3. Network Customization . . . . . . . . . . . . . . . . . . 7
3.4. NSaaS of Different Granularity . . . . . . . . . . . . . 7
3.5. Service customization across multi-provider multi-domains
as NSaaS . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Network Slicing in 3GPP Mobile Network . . . . . . . . . . . 10
4.1. Network Slices in 3GPP Systems . . . . . . . . . . . . . 10
4.2. Creating, Managing and Operating 3GPP Network Slices . . 11
5. Role of Virtualization in Network slicing . . . . . . . . . . 12
5.1. Virtualized Customer Premise Equipment . . . . . . . . . 12
5.2. Enhanced Broadband . . . . . . . . . . . . . . . . . . . 14
6. Services with Resource Assurance . . . . . . . . . . . . . . 16
6.1. Massive Machine to Machine Communication . . . . . . . . 16
6.2. Ultra-reliable Low Latency Communication . . . . . . . . 18
6.3. Critical Communications . . . . . . . . . . . . . . . . . 20
7. Network Infrastructure for new technologies . . . . . . . . . 23
7.1. ICN as a Network Slice . . . . . . . . . . . . . . . . . 23
7.2. New Verticals - ICN based service delivery . . . . . . . 24
Makhijani, ed, et al. Expires April 21, 2018 [Page 2]
Internet-Draft Netslicing use cases October 2017
7.2.1. Required Characteristics . . . . . . . . . . . . . . 25
8. Overall Use Case Analysis . . . . . . . . . . . . . . . . . . 26
8.1. Requirements Reference . . . . . . . . . . . . . . . . . 26
8.2. Mapping Common characteristics to Requirements . . . . . 26
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 28
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
13.1. Normative References . . . . . . . . . . . . . . . . . . 29
13.2. Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction
Network Slicing enables the creation of (end-to-end) partitioned
network infrastructure that 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:
o V2X (Vehicle-to-everything): Is a communication of information
from a vehicle to any other entity that may be another vehicle,
road-side network element or application end point.
o ITS (Intelligent Transportation Systems): Considered as an aspect
of how using Internet of Things resource like road sensors can
creates a smart transport network. The network offers services
related to transport and traffic management systems through flow
of information between road-side sensors, vehicles, smart devices
and humans.
Makhijani, ed, et al. Expires April 21, 2018 [Page 3]
Internet-Draft Netslicing use cases October 2017
o Over-the-top (OTT): A service, e.g., content delivery using a CDN
or a social networking service, operated by a different service
providers to which the users of the NSP service are attached to,
and to whom it serves as a communication (or bit pipe) provider
o Industry vertical: A collection of services or tools specific to
an industry, trade or market sector. also, referred to as Service
Verticals in this document.
o TETRA: Terrestrial trunked radio is a digital trunked mobile radio
standard to meet needs of public safety, transportation and
utilities like organizations.
o SLA: Service Level Agreement - A contract between a service
provider and an end user that stipulates a specified level of
service, support option, a guaranteed level of system performance
as relates to downtime or up-time.
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 is under the same
administrator's control but may also belong to different
administrative 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 as below in Figure 1
Makhijani, ed, et al. Expires April 21, 2018 [Page 4]
Internet-Draft Netslicing use cases October 2017
----------------------------
| Network Slice as a Service |
----------------------------
| _______
-----------------|----------------_----->| 3GPP |
| | | |______|
| | |
| | |
__________+______ ______+______ _______+__________
| Customization | | Resource | | New |
| | | assurance | | Technologies |
|_______________| |___________| |________________|
/\ /\ |
/| \ / |\ |
/ | \ / | \ |
_____/_ | _\_____ ____/___| _\______ ____|__
| vCPE | | | 5GEX | | mMTC || | uRLLC | | ICN |
|______| | |_______| |______|| |_______| |_____|
| |
| |
____|___ ___|___
| eMBB | | MCS |
|______| |_____|
Figure 1: Use case organization in the document
The remaining document is organized as below:
o In Section 3, Network Slice as a Service(NSaaS) delivery model is
described.
o Section 3.5, is a scenario for multi-domain network slice
coordination.
o In Section 4, 3GPP architecture for 5G is discussed as a use case
so that those requirements may be taken into consideration during
slicing activities in IETF.
o Other use cases are discussed from 2 perspectives
a Existing scenarios: Several already deployed use cases that
would further benefit operators when deployed through Network
Slice paradigm are discussed in Section 5.
b Differentiated service scenarios: that must absolutely meet
strict resource requirements, as if they use a dedicated
Makhijani, ed, et al. Expires April 21, 2018 [Page 5]
Internet-Draft Netslicing use cases October 2017
infrastructure. The example use cases are categorized in
Section 6.
o Section 7, has an example use case of cases where new technologies
can be verified or deployed using network slicing concept.
o In Section 8, the use case requirements are summarized which are
inputs to the [I-D.qiang-netslices-gap-analysis].
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 Slicing 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 overall QoE. More
recently, concepts such as edge computing allow opportunistic
placement of services to meet stringent requirements 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.
Makhijani, ed, et al. Expires April 21, 2018 [Page 6]
Internet-Draft Netslicing use cases October 2017
3.2. Strict Resource Demand
Several services are sensitive to response times and/or amount of
bandwidth, e.g. real time interactive multimedia, high bandwidth
video feed or remote access to an enterprise network. Failure to
meet these criteria lead 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 Granularity
In order to meet various requirements from the network slice tenant,
NSaaS should be provided with different granularities. Some typical
examples of granularities that a provider may offer are as follows.
o Network Domain - Network slice instances of different networks
i.e. access (wireless, fixed) network, transport network and core
network.
o Access technologies - Network slice instances of different
generations of cellular and fixed network technologies, i.e. 4G,
WiFi, Passive Optical Network (PON) and DSL.
o SLA requirements - Network slice instances of different SLA
requirements, i.e. low-latency network, legacy best-effort network
and network with guaranteed-bandwidth.
o Vertical applications - Network slice instances of different
industry verticals. i.e. manufacturing site, V2X, industrial IoT
and smart city.
Makhijani, ed, et al. Expires April 21, 2018 [Page 7]
Internet-Draft Netslicing use cases October 2017
o OTT services - Network slice instances of different applications
provided by OTT, i.e. messaging, payment, video streaming and
gaming.
o Cross domain services - Network slice instances of different
services across multi-provider domains such as l2, l3 VPN
services.
During the realization of network slice instance, 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.
The customization of different granularities of a network slice
introduce many challenges, especially in terms of network management
and orchestration. As a network slice provider (provider of end-to-
end slice service), 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 (as the differentiated services). Accordingly, network slice
provider is able to orchestrate specific instances based on these
exposed capabilities.
3.5. Service customization across multi-provider multi-domains as NSaaS
L2 and L3 connectivity services can be deployed in a multi-provider
multi-domain scenario and, in the SDN era, this implies the
decoupling of network resources for different service provider and
domain orchestrators. The allocation of network resources within the
domain of each service provider, involved by the end-to-end service,
can be defined as a network slice.
Within a single domain, provider is aware of the entire topology and
its own resource availability and has complete control over those
resources. However, in a multi domain scenario, the overall
knowledge of the resources and topologies cannot be made across
providers. Therefore, the exchange of information across these
providers have to be enabled, as shown in Figure 2, inspired by
[I-D.bernardos-nfvrg-multidomain] and
[I-D.ietf-opsawg-service-model-explained].
Makhijani, ed, et al. Expires April 21, 2018 [Page 8]
Internet-Draft Netslicing use cases October 2017
----------------------------
| Customer Service Requester |
----------------------------
|
(L2VPN/L3VPN |
Service | IF1
Model) | |
+ +
_____|____ ____|_____
| Multi | IF2 | Multi |
| Provider |<--------+---------->| Provider |
|____MdO_1_| |___ MdO_2_|
/\ /\
/ \ / \
/ \ IF3 / \
_______/__ _\_________ ________/_ _\________
| Domain | | Domain | | Domain | | Domain |
|___Orch___| |___Orch___| |___Orch___| |___Orch___|
Figure 2: Multi-domain, multi-provider connectivity services
The Figure 2 shows a multi provider MdO (MP-MdO) exposing an
interface 1 (IF1) to the tenant, interface 2 (IF2) to other multi
provider MdO (multi domain orchestrator) and an interface 3 (IF3) to
individual domain orchestrators. IF1 is exposed to the tenant who
could request his specific services and/or slices to be deployed.
IF2 is between the orchestrators and is a key interface to enable
multi-provider operation. IF3 focuses on abstracting the technology
or vendor dependent implementation details to support orchestration
in each network domain (see [!@I-D.bernardos-nfvrg-multidomain] for
details). The coordination alternatives between MP-MdOs are: *
Bilateral Cascading: providers can have long-lasting business
agreements only with their direct neighbors. * Full Mesh between MP-
MdOs: Providers can have long-lasting business agreement with any
provider (neighboring or remote).
This reference architecture is the main focus of the 5GEx European
Project.
Among applications, L2VPN and L3VPN wholesale end-to-end services in
a multi-provider and multi-domain scenario needs the following
characteristics for network slice management
o An automatic activation test and verification functionality (by
customer or orchestrator).
Makhijani, ed, et al. Expires April 21, 2018 [Page 9]
Internet-Draft Netslicing use cases October 2017
o Interface to modify parameters of L2VPN or L3VPN service such as
bandwidth or path redundancy.
Looking at Figure 2, the customer needs a new L2 end-to-end service
between CPEs across two domains (MP-MdO1 and MP-MdO2). As MP-MdO1
receives the service request, it is deployed as a network slice. In
this regards MP-Md01 has prior knowledge of topology and resource
across domains in some form, it then splits the service request into
a slice across each of the involved domain. Once service is set up:
MP-MdO1 allocates resources for the slice on SP1 domain while MP-MdO2
allocates on SP2 domain respectively.
[I-D.ietf-l2sm-l2vpn-service-model] and [RFC8049] can describe IF1
For L2 and L3 end-to-end services respectively. The ability to map
such services as network slice will be considerable opportunity for
dynamic cross-domain operations.
4. Network Slicing in 3GPP Mobile Network
Network Slicing is a core capability of the currently under
development 3GPP 5G phase 1 mobile system, as it makes it possible
for different service verticals, such as IoT and broadband
applications, to be deployed over a common shared 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].
3GPP is currently defining its own solution for network slicing. An
IETF effort in this field may, however, still be complementary in the
long run as IETF focuses on the IP infrastructure and protocols which
are generally out of scope of 3GPP. Challenges relevant to the IETF
include isolation between network slices, supporting sharing network
functions between several slices, building slices recursively from
smaller slice subnets, implementing slicing across different domains
for roaming, etc.
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) slices and core network slices
interwork to provide mobile connectivity. A device may access
multiple NS simultaneously through a single RAN. 3GPP defines slice
IDs (NSSAI) composed of a Slice Service Type (SST) and 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 NS
instances.
Makhijani, ed, et al. Expires April 21, 2018 [Page 10]
Internet-Draft Netslicing use cases October 2017
Figure 3 describes the general layout of Network Slicing in mobile
networks. A core network slice includes, a Session Management
Function (SMF), which manages PDU sessions, and a User Plane Function
(UPF). Some functions such as the Access and Mobility management
Function (AMF) are common and shared between multiple RAN and core
network slices.
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 3: 3GPP Network Slices
4.2. Creating, Managing and Operating 3GPP Network Slices
To create a network slice instance, mobile network operators define
"Network Slice Subnets" into OSS/BSS management system. NS subnets
are NS components including NFs and reserved network resources. OSS/
BSS communicates with the orchestrator, which, through the rest of
the NFV-MANO system, configures compute and network elements to
create, compose and activate slices.
Mobile network operators can modify the configuration of a RAN or
core network slice, while it is in use. To support this, the
operator needs to measure QoS/SLA data for hosted network services,
and associate results with the relevant network slice. Example of
operations include increase or decrease network capacity or compute
capacity of NFs; update the configuration of NFs; add, replace or
remove a NFs or a Network Slice Subnet.
Slice selection occurs in 2 phases: first, common functions
(including AMF) and available network slices are pre-selected when
the device registers with the network. Later on, the network
dynamically selects network slices when a device initiates
Makhijani, ed, et al. Expires April 21, 2018 [Page 11]
Internet-Draft Netslicing use cases October 2017
communication, based on a slice ID associated with the application
(on the device) that requests a new flow.
5. Role of Virtualization 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
network slice provider. One such use case is described below.
5.1. Virtualized Customer Premise Equipment
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.
Traditional CPE deployments 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.
Makhijani, ed, et al. Expires April 21, 2018 [Page 12]
Internet-Draft Netslicing use cases October 2017
|-----------------------|
| +------+ |------------------+-------+ campus
| |--| | | | vCPEx | -----[ ]
| | | | |------------------+-------+
| | | | | <====Broadband ==>
| ----- | | vCPE | | -----------------+-------+ branch
| ( ) |->| | | | vCPEy |------[ ]
| ( CSP )| | | |------------------+-------+
| (_____) | | | |<=== MPLS/4G. ==>
| | | | |------------------+-------+ main site
| |->| | | | vCPEz |----- [ ]
| +------+ |------------------+-------+
|-----------------------|
Figure 4: Virtualized CPE with distributed architecture
Figure 4 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.
A vCPE is a well-known concept[VCPEBBF] which when combined with WAN
technologies provides end to end visibility and reachability to
remote sites. However, there is no standard approach to connectivity
or management of various CPE functions. 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.
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.
Makhijani, ed, et al. Expires April 21, 2018 [Page 13]
Internet-Draft Netslicing use cases October 2017
+-------------+
| Slice |
| Resource Mgr|
+-------------+
|
| NS protocol or i/f
V
|--------------------------------------------------|
| |
| +-------------+ +-------------+ |
| | vCPE Slice | | CSP | |
| | 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 5: vCPE as a Network Slice
In Figure 5, 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.
5.2. 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.
For example, connected Virtual Reality(VR)/Augmented Reality(AR) is
the future use case of eMBB services. Notably, media processing for
AR/VR will require in-network processing functions 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.
Makhijani, ed, et al. Expires April 21, 2018 [Page 14]
Internet-Draft Netslicing use cases October 2017
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. Resource scaling for eMBB should be
dynamic because bandwidth is expensive and such vertical service
operators may not want to pay for unutilized bandwidth. Therefore,
slices should be able to monitor, negotiate and adjust the scale for
both bandwidth and service functions. Latency guarantees vary from
general services, therefore, as a first step, monitoring for quality
of service is needed and more advanced operation would involve
recovery and reparation of paths.
A typical eMBB slice Figure 6 from a network operator is a
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) An interface to subscriber database perhaps as a network
function, from multiple access network types (cellular, fixed).
(3) Live performance monitoring and resource negotiation loop.
(4) A well-coordinated network slice protocol that enables resource
allocation across different network domains.
Makhijani, ed, et al. Expires April 21, 2018 [Page 15]
Internet-Draft Netslicing use cases October 2017
+-------------------------+
| Slice Resource Manager |
+-------------------------+
| |
| NS control |
| |
+------------------+ +----------------+
| eMBB Network | | eMBB Network |
+------------------+ +----------------+
| |
V V
----------NS transport ----------------
| | |
V V V
---------------- ---------------- -----------
| Infrastructure | |Infrastructure | | DC |
| Domain A | | Domain B | | Domain C |
---------------- ---------------- -----------
Figure 6: Transport provider network operator view.
6. Services with Resource Assurance
6.1. Massive Machine to Machine Communication
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 7.
Makhijani, ed, et al. Expires April 21, 2018 [Page 16]
Internet-Draft Netslicing use cases October 2017
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 7: Workflow of wireless sensor network
Figure 7 shows, control of sensor data & behavior at scale, requiring
wide area coverage and power constrained communication. A few new
types of scenarios that require unique infrastructure are:
o Smart city networks: an integration of several public
infrastructures together through M2M communications. For example
Automatic metering (for gas, energy, water, etc.), environment
monitoring (for pollution, temperature, humidity, etc.), traffic
signal control etc.
o E-health communications that remote monitor the physical
conditions (e.g., heart rate, pulse, blood pressure etc.), and
accordingly take necessary measures remotely. E-health
communication network must be secure, reliable and fast but small-
size of data exchange.
mMTC Type Slices 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 delay sensitivity in industry
operations etc. The mMTC type slices should be conscious of
requirements of scale, variable data pattern, and energy efficient
communications.
Makhijani, ed, et al. Expires April 21, 2018 [Page 17]
Internet-Draft Netslicing use cases October 2017
6.2. Ultra-reliable Low Latency Communication
In uRLLC scenarios, data loss is not acceptable. Both data and
control planes may require significant enhancements to transmission
or information distribution protocols. [TR_3GPP_38.913] specifies
access network user plane latency as 1ms and reliability factor of
99.999% for transmission of a packet of size 32 bytes. The slices of
this type must be ensured that shared infrastructure absolutely does
not cause any adverse effects.
In the following sections three new uRLLC scenarios are described.
(1) Industrial operation: Operations in remote sites usually need
combined support of cellular and transport network. Operational
accuracy is characterized by
* Requires high-quality communication links between the control
site.
* Low latency and low jitter in communication path
* Closed control loop (Sensor -Controller - Actuator) as shown
in Figure 8, a typical control cycle time where network is
involved should be below 10ms [Tactile-Internet].
++++++++++ +++++++++++++++
+ Sensor +-->+ Transmitter +---+
++++++++++ +++++++++++++++ |
| ++++++++++++ ++++++++++++++
+-->+ Base +---->+ Controller +
+---+ Station +<----+ +
| ++++++++++++ ++++++++++++++
++++++++++++ ++++++++++++++ |
+ Actuator +<--+ Receiver + <--+
++++++++++++ ++++++++++++++
Figure 8: Industrial closed control loop
(2) Remote surgery enables surgeons to perform critical specialized
medical procedures remotely, providing accurate control and
haptic feedback.
A uRLLC network slice only accepts service specific traffic and must
not receive any other type of traffic to avoid negative impact on the
service operation. Capabilities required by uRLLC service provider
include
Makhijani, ed, et al. Expires April 21, 2018 [Page 18]
Internet-Draft Netslicing use cases October 2017
o Locations of the access nodes for terminals (devices, vehicles) to
the transport network and locations of the controller to construct
its own network topology within the network slice. In high
mobility scenario such as automotive verticals, the dynamic
topology adjustments are required without loss of data.
o Each service vertical has different performance requirements in
terms of latency, reliability and data rate etc., therefore, the
uRLLC network slice should allow customization for these
parameters.
o A uRLLC service provider should be able to registers self with
access rights to resource monitoring and negotiation loop.
A network slice provider offers a uRLLC Slice with the following
considerations
o Should support/provide specific data and control planes protocols
with significant enhancements for deterministic latency and
reliability (e.g. DetNet[I-D.dt-detnet-dp-sol] in data plane).
o Allow uRLLC service operator to access user admission and
authentication to its network slice in advance.
o The network coverage for a uRLLC service provisioning may be
limited to a confined area, either indoor or outdoor, network
operator needs to be able to coordinate resource allocation across
different access types and network domains.
A high-level Figure 9, shows a URLLC slice provider and service 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 9, 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.
Makhijani, ed, et al. Expires April 21, 2018 [Page 19]
Internet-Draft Netslicing use cases October 2017
+-----------------------------+
| |
| +---------+ | uRLLC service +---------+
| | Resource|<-----|---------------| uRLLC |
| +------ | Manager | | 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 9: Reference for uRLLC Network Slice.
6.3. 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. fire
fighters, paramedics), military, utility or commercial applications,
Makhijani, ed, et al. Expires April 21, 2018 [Page 20]
Internet-Draft Netslicing use cases October 2017
mainly using reliable voice or short data messaging over wireless
communication systems.
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).
3GPP defined on-network critical communication can be established
both via (a) over the network infrastructure to manage the call, (b)
off-network, where the terminals communicate directly to each other.
In the network slicing context, over the network, involves transport
networks for an always available, reliable, and zero packet loss
quality of traffic support to meet critical services requirements.
Maintaining a separate broadband infrastructure for critical
communications incurs a heavy deployment cost. Especially, as the
coverage of this separate network has to be extended to large-scale
nationwide geographies and remain interoperable is too expensive. As
new communication technologies emerge, public safety systems will
have to bear the state of the art adoption cost. A separate
infrastructure lacks flexibility to add new value-added services or
to take advantage of available commercial services.
While shared infrastructure, brings out challenges of these kind:
(1) 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.
(2) Zero congestion: It is not acceptable for critical calls to be
delayed at call setup times or be subjected to any other
congestion scenarios.
Having the Mission Critical Service (MCS) as a network slice benefit
from the following:
o Insertion and authorization of subscribers in a group
communication: In a critical infrastructure, the subscriber
authentication may be done earlier at the entry point
automatically through slice selection functional entity.
o Pre-allocated QoS Class Identifiers (QCIs): Generally, QCIs are
requested on per session basis which could slow down overall call
control setup and is undesirable for emergency services. When
operating in a slice, these resources maybe reserved ahead of time
in a coarse-grained manner instead of per session.
Makhijani, ed, et al. Expires April 21, 2018 [Page 21]
Internet-Draft Netslicing use cases October 2017
MCS 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 10 below, shows a mission critical
(MC) organization providing service agreement through a network slice
template with resource specification. The MCS 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 MCS 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.
Makhijani, ed, et al. Expires April 21, 2018 [Page 22]
Internet-Draft Netslicing use cases October 2017
+----------------------------------+
| |
| +------------------+ | service +------------------+
| | Slice Resource | |<-----------| Mission Critical |
| +--> | Manager |---+ | 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 10: 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].
Makhijani, ed, et al. Expires April 21, 2018 [Page 23]
Internet-Draft Netslicing use cases October 2017
Information-Centric Networking (ICN) addresses Internet's network
architectural design gaps based on evolving applications requirements
and end user behavior that 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
naming, security, caching, mobility, multicasting and computing in a
manner different from traditional host-centric communication model.
ICN's name-based abstraction to application minimizes bootstrap
configuration from the network, making it suitable to several
communication modalities such as multi-point-to-multi-point, AR/VR,
D2D and Ad hoc communication.
7.2. New Verticals - ICN based service delivery
Services over ICN slices can take advantage of its features such as:
(1) 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.
(2) 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.
(3) 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.
(4) Further saving bandwidth in the upstream link through
opportunistic caching is an inherent feature of ICN, this also
leads to energy efficient networking.
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 slices can
be offered over a network slicing framework built upon a programmable
pool of software and/or hardware based data plane resources.
Makhijani, ed, et al. Expires April 21, 2018 [Page 24]
Internet-Draft Netslicing use cases October 2017
7.2.1. Required Characteristics
In ICN, applications use Interest/Data or Get/Put 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 distributed
routing logic or through centralized application controllers. As a
result, it should be possible to deploy software or hardware based
network functions such as ICN routers and content producers and
distributors that serve and speak ICN protocols, or enabled through
service gateways at the edges of the network. 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 single service instance too. The latter approach has
implications with respect to consumer privacy, access control of name
data objects, and granularity of mobility handling [_5GICN_].
A basic ICN slice can be manifested as a resource isolated logical
network while sharing resources with other connectivity or IP based
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.
o Through a network slice template -ICN service providing entity
could specify specific locations (edge of network domains) to
deploy ICN-routers or other ICN-NFs (ICN aware network functions).
Its service definition varies with the type of service.
o Application driven connectivity between ICN network elements in
all segments and create an ICN based virtual topology.
o Mechanisms to deliver ICN user traffic over the infrastructure
such as overlay or, ICN NFs can be tightly integrated with the RAN
such as the eNodeB or implicitly using traffic classification
function at the edge and tunneled to ICN User Plane Function
(UPF).
o In addition, bandwidth and other network resources may be
requested from the underlay depending on its capability of
providing deterministic or statistically guarantees.
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.
Makhijani, ed, et al. Expires April 21, 2018 [Page 25]
Internet-Draft Netslicing use cases October 2017
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 demonstrate
several common functionalities. Therefore, a homogeneous approach
towards deployment and management is absolutely necessary.
8.2. Mapping Common characteristics to Requirements
(1) Resource Reservation: Compute and network resources are reserved
as part of initial creation and subsequently during the
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". A network slice
aware infrastructure shall be able to support mechanisms for
elastic scaling (up/down) of resources and their non-disruptive
provisioning.
(2) Resource Assurance: A network slice aware infrastructure allows
operators to allocate part of the network resources to meet
stringent resource characteristics. Scenarios in both Section 5
and Section 6 require on demand and dynamic adjustments. It may
not be possible to achieve this using centralize or API approach
with finer granularity of resources participating in constrained
path computation.
(3) Multi-dimensional service vertical: Network slicing supports
dynamic multi-services, multi-tenancy and the means for backing
vertical market players.
(4) 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 administrations.
Furthoremore, capabilities of each domain must be known in order
to validate if a slice can be created or not. All scenarios
Makhijani, ed, et al. Expires April 21, 2018 [Page 26]
Internet-Draft Netslicing use cases October 2017
mentioned require multi-domain coordination to connect and
administer different subnets.
(5) Operational Isolation: A network slice represents logical group
of network resources, functions and corresponding configurations
separating its behavior and hence operation from the underlying
physical network. Each network slice may have its own operator
that sees this slice as a complete network (i.e. with router
instances, policies, programmability, placement of virtual
network functions according to traffic patterns etc.) and can
manage as its own network.
(6) 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.
(7) 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). In this regard, monitoring probes are needed of
each network slice and resources associated with it.
+-------------------------------------+----------------------------+
| Requirements Illustrated above | Aggregated Requirements |
+-------------------------------------+----------------------------+
|1) Resource reservation | |
|6) Transparency | Req 1. Network Slicing |
|4) Multi-access knowledge | Specification |
|3) Multi-dimensional service vertical| |
+-------------------------------------+----------------------------+
|4) Multi-Domain coordination | Req 2. Network Slicing |
| | Cross-Domain |
|2) Resource Assurance | Coordination |
+-------------------------------------+----------------------------+
| | Req 3. Network Slicing |
|5) Operational/performance Isolation | Performance Guarantee|
| | and Isolation |
+-------------------------------------+----------------------------+
|7) Reliability | Req 4. Network Slicing OAM |
+-------------------------------------+----------------------------+
Figure 11: Mapping Common Characteristics to Requirements
NSaaS is a key for network operators to deploy network slices.
Having standard means to realize these use cases, enables (a)
Makhijani, ed, et al. Expires April 21, 2018 [Page 27]
Internet-Draft Netslicing use cases October 2017
different usecases to be uniformly understood by a network slice
provider, and (b) similar use cases to be understood in a similar
fashion by different network slice providers. Both these cases
should allow common mechanisms to map and allocate network slices
over the network infrastructure.
Due to the availability of diverse technologies in control and data
planes; the first step should be a top-down means to realize a slice
with a common technology independent information model. It may
describe a resource-centric slice with connectivity, storage, and
compute resources, network functions, and operational requirements,
that further get mapped to infrastructure resources and capabilities
for run-time operations and monitoring. This model may be used by an
orchestrator onboarding function for creating instances of network
slice services and distributing to network infrastructure providers.
9. Conclusion
A service should typically need a network slice for one of those
reasons:
(1) The service cannot provide optimal experience on a best-effort
network.
(2) 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.
Makhijani, ed, et al. Expires April 21, 2018 [Page 28]
Internet-Draft Netslicing use cases October 2017
11. IANA Considerations
There are no IANA actions requested at this time.
12. Acknowledgements
Note, the 5GEX L2VPN and L3VPN usecase is an independent contribution
by authors and is not endorsed by 5GEX. Many thanks to the following
reviewers for providing details for several use cases and for helping
with the review of the document.
Stewart Bryant (stewart.bryant@gmail.com), Hannu Flinck
(hannu.flinck@nokia-bell-labs.com), Med Boucadair
(mohamed.boucadair@orange.com), Dong Jie (dong.jie@huawei.com).
13. References
13.1. Normative References
[I-D.bernardos-nfvrg-multidomain]
Bernardos, C., Contreras, L., Vaishnavi, I., and R. Szabo,
"Multi-domain Network Virtualization", draft-bernardos-
nfvrg-multidomain-03 (work in progress), September 2017.
[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", draft-dt-detnet-dp-
sol-02 (work in progress), September 2017.
[I-D.geng-netslices-architecture]
67, 4., Dong, J., Bryant, S., kiran.makhijani@huawei.com,
k., Galis, A., Foy, X., and S. Kuklinski, "Network Slicing
Architecture", draft-geng-netslices-architecture-02 (work
in progress), July 2017.
[I-D.ietf-l2sm-l2vpn-service-model]
Wen, B., Fioccola, G., Xie, C., and L. Jalil, "A YANG Data
Model for L2VPN Service Delivery", draft-ietf-l2sm-l2vpn-
service-model-03 (work in progress), September 2017.
[I-D.ietf-opsawg-service-model-explained]
Wu, Q., LIU, W., and A. Farrel, "Service Models
Explained", draft-ietf-opsawg-service-model-explained-05
(work in progress), October 2017.
Makhijani, ed, et al. Expires April 21, 2018 [Page 29]
Internet-Draft Netslicing use cases October 2017
[I-D.pularikkal-virtual-cpe]
Pularikkal, B., Fu, Q., Hui, D., Sundaram, G., and S.
Gundavelli, "Virtual CPE Deployment Considerations",
draft-pularikkal-virtual-cpe-02 (work in progress),
February 2017.
[I-D.qiang-netslices-gap-analysis]
Qiang, L., Martinez-Julia, P., 67, 4., Dong, J.,
kiran.makhijani@huawei.com, k., Galis, A., Hares, S., and
S. Slawomir, "Gap Analysis for Transport Network Slicing",
draft-qiang-netslices-gap-analysis-01 (work in progress),
July 2017.
[RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data
Model for L3VPN Service Delivery", RFC 8049,
DOI 10.17487/RFC8049, February 2017,
<https://www.rfc-editor.org/info/rfc8049>.
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,
<https://arxiv.org/abs/1610.01182>.
[ICNRG] IRTF, "ICN Routing Group", November 2016,
<https://irtf.org/icnrg>.
[Tactile-Internet]
ITU-T, "Technology Watch Report, The Tactile Internet",
August 2014, <https://www.itu.int/oth/T2301000023/en>.
[TR_3GPP.33.899]
3GPP, "Study on the security aspects of the next
generation system", 3GPP TR 33.899 0.6.0, November 2016,
<http://www.3gpp.org/ftp/Specs/html-info/33899.htm>.
[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, <http://www.3gpp.org/ftp/Specs/html-info/38801.htm>.
[TR_3GPP_38.913]
3GPP, "Study on scenarios and requirements for next
generation access technologies", 3GPP TR 38.913 14.2.0,
March 2017,
<http://www.3gpp.org/ftp/Specs/archive/38_series/38.913>.
Makhijani, ed, et al. Expires April 21, 2018 [Page 30]
Internet-Draft Netslicing use cases October 2017
[TS_3GPP.23.501]
3GPP, "System Architecture for the 5G System", 3GPP
TS 23.501 0.2.0, February 2017,
<http://www.3gpp.org/ftp/Specs/html-info/23501.htm>.
[TS_3GPP.23.502]
3GPP, "Procedures for the 5G System", 3GPP TS 23.502
0.2.0, February 2017,
<http://www.3gpp.org/ftp/Specs/html-info/23502.htm>.
[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,
<http://www.3gpp.org/ftp/Specs/html-info/28500.htm>.
[VCPEBBF] Broadband Forum, "TR-345 Broadband Network Gateway and
Network Function Virtualization", Dec 2016,
<https://www.broadband-forum.org/technical/download/
TR-345.pdf>.
Authors' Addresses
Kiran Makhijani
Huawei Technologies
2890 Central Expressway
Santa Clara CA 95050
USA
Email: kiran.makhijani@huawei.com
Jun Qin
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
Email: qinjun4@huawei.com
Ravi Ravindran
Huawei Technologies
2890 Central Expressway
Santa Clara CA 95050
USA
Email: ravi.ravindran@huawei.com
Makhijani, ed, et al. Expires April 21, 2018 [Page 31]
Internet-Draft Netslicing use cases October 2017
Liang Geng
China Mobile
Beijing 100095
China
Email: gengliang@chinamobile.com
Li Qiang
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
China
Email: qiangli3@huawei.com
Shuping Peng
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
China
Email: pengshuping@huawei.com
Xavier de Foy
InterDigital Inc.
1000 Sherbrooke West
Montreal
Canada
Email: Xavier.Defoy@InterDigital.com
Akbar Rahman
InterDigital Inc.
1000 Sherbrooke West
Montreal
Canada
Email: Akbar.Rahman@InterDigital.com
Makhijani, ed, et al. Expires April 21, 2018 [Page 32]
Internet-Draft Netslicing use cases October 2017
Alex Galis
University College London
London
U.K.
Email: a.galis@ucl.ac.uk
Giuseppe Fioccola
Telecom Italia
Italy
Email: giuseppe.fioccola@telecomitalia.it
Makhijani, ed, et al. Expires April 21, 2018 [Page 33]
