Network Slicing - 3GPP Use Case
draft-defoy-netslices-3gpp-network-slicing-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Xavier de Foy , Akbar Rahman | ||
| Last updated | 2017-03-06 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-defoy-netslices-3gpp-network-slicing-00
Network Working Group X. de Foy
Internet-Draft A. Rahman
Intended status: Informational InterDigital Communications, LLC
Expires: September 7, 2017 March 6, 2017
Network Slicing - 3GPP Use Case
draft-defoy-netslices-3gpp-network-slicing-00
Abstract
This document describes work conducted at the 3GPP standard
organization on 5G Network Slicing. Its goal is to provide a
detailed use case, and help better define requirements, for Internet
Protocols supporting 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 http://datatracker.ietf.org/drafts/current/.
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 September 7, 2017.
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
(http://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.
de Foy & Rahman Expires September 7, 2017 [Page 1]
Internet-Draft Network Slicing 3GPP Use Case March 2017
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. NS Work in 3GPP Prior to 5G Phase 1 . . . . . . . . . . . 3
2. Network Slicing Requirements in 3GPP . . . . . . . . . . . . 3
3. Network Slicing in Logical 5G Architecture in 3GPP . . . . . 4
3.1. Early Work on RAN Slicing . . . . . . . . . . . . . . . . 7
4. Management Aspect of Network Slicing in 3GPP . . . . . . . . 8
5. 5G Virtual Infrastructure Management in 3GPP . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
10. Informative References . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
This document describes work conducted at the 3GPP standard
organization on 5G Network Slicing. Its goal is to provide a
detailed use case, and help better define requirements, for Internet
Protocols supporting Network Slicing.
The concept of Network Slicing (NS) is considered a key mechanism for
5G networks to serve vertical industries with widely different
service needs, in term of latency, reliability, capacity, and domain
specific extra functionalities. It does so by exposing isolated
partitions of network resources and services. The IETF Bar-BoF
NETSLICES activity studies the need for supporting protocols. In
particular, [I-D.gdmb-netslices-intro-and-ps] defines Network Slicing
in a broad context and suggests related problems and work areas. It
also identifies the need to provide use cases such as, for example,
ultra-low latency and massive-connectivity machine communication
services. We propose to review ongoing NS work in 3GPP within the
present document. This constitutes in our view another valid type of
use case, since 3GPP architecture may ultimately use or integrate
with NS solutions defined in IETF.
Sections 2 to 6 aim to represent the current state of network slicing
and related aspects in 3GPP. We attempted to leave our own analysis
out of these sections and present it into section 7. For simplicity,
3GPP-specific acronyms are defined in the section they are used,
which is mostly section 3.
de Foy & Rahman Expires September 7, 2017 [Page 2]
Internet-Draft Network Slicing 3GPP Use Case March 2017
1.1. Background
The 3GPP standard organization is in the process of developing 5G
system architecture, which includes network slicing. In the present
document we will use information collected from 3GPP Release 15
specifications (as well as preliminary studies from Release 14 when
specifications are not yet available). This release aims to address
a more urgent subset of commercial needs in "5G Phase 1", with
expected deployments in 2020. Work on network slicing is split
between different working and study groups, reviewed here in separate
sections.
1.2. NS Work in 3GPP Prior to 5G Phase 1
While the present document will only focus on Network Slicing in 5G
Phase 1, an early form of network slicing was introduced in Release
13, with the Dedicated Core Network (DCN) or DECOR feature, where
dedicated core network nodes are forming a DCN serving subscribers or
devices with a certain "usage type" (e.g. machine-to-machine or
enterprise). In the Release 14 eDECOR feature, the DCN selection
mechanism was extended to be assisted by the device, which can now
send its usage type to the RAN. This is specified in [_3GPP.23.401].
Deployments are expected in 2017 and 2018.
2. Network Slicing Requirements in 3GPP
Network slicing requirements are included in [_3GPP.22.261]. There
are requirements related to:
o Provisioning: create/modify/delete network slices, provision
network functions to be used in slices, define network services
and capabilities supported by a network slice.
o Managing association to slices: configure association of devices
and services to network slices, move/remove user between/from
slices.
o Interoperating: support roaming and non-roaming using the same
home slice, support devices simultaneously connected to multiple
slices.
o Supporting performance and isolation: support dynamic slice
elasticity, ensure performance isolation during normal and elastic
slice operation and during slice creation or deletion, enable
operators to differentiate performance and functionalities between
slices.
de Foy & Rahman Expires September 7, 2017 [Page 3]
Internet-Draft Network Slicing 3GPP Use Case March 2017
3. Network Slicing in Logical 5G Architecture in 3GPP
5G network architecture is entering its normative stage in 2017 with
a "5G System - Phase 1" Release 15 work item, which is in the process
of producing two technical specifications: 23.501 "System
Architecture for the 5G System" and 23.502 "Procedures for the 5G
System". At this early stage, though, we will still need to refer to
the earlier technical report [_3GPP.23.799]. The following text
summarizes what has been agreed about network slicing (refer to
section 8.1 of that report for more details).
A network slice is a complete logical network including Radio Access
Network (RAN) and Core Network (CN). It provides telecommunication
services and network capabilities, which may vary (or not) from slice
to slice. Distinct RAN and core network slices will exist. A device
may access multiple slices simultaneously through a single RAN.
The device may provide Network Slice Selection Assistance Information
(NSSAI) parameters to the network to help it select a RAN and a core
network part of a slice instance for the device. A single NSSAI may
lead to the selection of several slices. The network may also use
device capabilities, subscription information and local operator
policies to do the selection.
A NSSAI is a collection of smaller components, Session Management
NSSAIs (SM-NSSAI), which each include a Slice Service Type (SST) and
possibly a Slice Differentiator (SD). Slice service type refers to
an expected network behavior in terms of features and services (e.g.
specialized for broadband or massive IoT), while the slice
differentiator can help selecting among several network slice
instances of the same type, e.g. to isolate traffic related to
different services into different slices.
A PDU session is a 5G concept for an association between the device
and a data network, which can be IP, Ethernet or Unstructured (i.e.
transparent to the 5G system). The device will associate an
application with one out of multiple parallel PDU sessions, each PDU
session correspond to one core network slice and one RAN slice.
Different PDU sessions may belong to different slices. More
precisely, an application will be associated with a SM-NSSAI (as
mentioned above, this includes a slice service type and may also
include a service differentiator), and data for this application will
be routed to a PDU session associated to this SM-NSSAI.
Part of the control plane, the Common Control Network Function
(CCNF), is common to all or several slices. It includes the Access
and mobility Management Function (AMF) as well as the Network Slice
Selection Function (NSSF), which is in charge of selecting core
de Foy & Rahman Expires September 7, 2017 [Page 4]
Internet-Draft Network Slicing 3GPP Use Case March 2017
network slice instances. Besides those shared functions, different
slices may also have dedicated control plane functions such as the
Session Management Function (SMF), which manages PDU sessions. User
plane functions are dedicated to each slice. The RAN selects a CCNF
for a new PDU session. CCNF may initiate the redirection of service
for a device towards another CCNF, initially at session setup, or
later on.
In figures 1 and 2 we attempt to represent the use of network slicing
in 3GPP logical architecture (those figures are our interpretation
and are not directly adapted from the report). Figure 1 represents
the role of NSSAI in network selection. Figure 2 represents the
major network functions and interfaces in the context of RAN and Core
Network slicing. The terms used in these diagrams were introduced
earlier. System description and diagrams in section 4 of
[_3GPP.23.501] can provide additional context.
de Foy & Rahman Expires September 7, 2017 [Page 5]
Internet-Draft Network Slicing 3GPP Use Case March 2017
+-------+
| |
|Device |
| |
RAN uses NSSAI +---+---+
to select CCNF |
\ |(NSSAI)
\ |
+---+---+
| +-------------+
CCNF uses NSSAI | RAN +---------+ |
to select slice | | | |
or redirect to +---+---+ | |
another CCNF | | |
\ |(NSSAI) | |
\ | | |
+-------+--------+ | |
| Common Control | | |
| Plane Network | | |
| Functions | | |
| (CCNF) | | |
+-----+----+-----+ | |
| | | |
| | | |
| | | |
+---------|----+----------|---+-------+
| | | |
+------------|---------------|-------+ |
| +---------++ +-----+----+ | |
| | | | | | |
| | +------+ | | +------+ | | |
| | | | | | | | | | |
| | |CP NF1| | | |UP NF1| | | |
| | | | | | | | | | |
| | +------+ | | +------+ | | |
| | ... | | ... | | |
| | | | | | |
| | +------+ | | +------+ | | |
| | | | | | | | | | |
| | |CP NFn| | | |UP NFn| | | |
| | | | | | | | | | |
| | +------+ | | +------+ | | |
| | | | | +---+
| +----------+ +----------+ |
+------------------------------------+
Core Network Slice Instances
Figure 1: Network Slice Selection in 3GPP architecture
de Foy & Rahman Expires September 7, 2017 [Page 6]
Internet-Draft Network Slicing 3GPP Use Case March 2017
CCNF Network Slice Instance
+-----------------+---------------------+
| | |
| | |
| +--------+ | +--------+ |
| | Control| | | Control| |
+--------+ Plane +----------+ Plane | |
| | | AMF... | | | SMF... | |
| | +--------+ | +----+---+ |
| | | | |
| | | | |
| | | | |
+---+--+ +-----------------+ | |
|Device| | | | |
+---+--+ | | | |
| | | | |
| | +--------+ | +------+-----+ |
| | | | | | User Plane | | +---------------+
+--------+ RAN +--------+ Functions +------+Data Network or|
| | | | | | | | The Internet |
| +--------+ | +------------+ | +---------------+
| | |
| | |
+-----------------+---------------------+
RAN Slice
Figure 2: Network Slices in 3GPP architecture
3.1. Early Work on RAN Slicing
In line with the logical architecture described above, early work on
RAN slicing is being conducted as part of the larger Release 14
"Study on New Radio Access Technology". Key principles are likely to
include the following, extracted from [_3GPP.38.801]:
1. RAN will support differentiated handling of traffic between pre-
configured, isolated RAN slices. How to perform this is left to
implementation.
2. Selection of the RAN slice will be based on IDs (which should be
the slice service type and slice differentiator defined above)
provided by the device or core network.
3. A RAN slice may or may not be available at a given location.
4. RAN will select the core network slice.
5. QoS differentiation within a RAN slice will be supported as well.
de Foy & Rahman Expires September 7, 2017 [Page 7]
Internet-Draft Network Slicing 3GPP Use Case March 2017
4. Management Aspect of Network Slicing in 3GPP
3GPP is developing a Release 14 "Study on management and
orchestration of network slicing for next generation network"
technical report [_3GPP.28.801], which defines an information model
where the network slice as well as physical and virtualized network
functions belong to the network operator domain, while the
virtualized resources belong to another domain operated by a
virtualization infrastructure service provider.
The concept of "sub-netslice" is used in the model, as defined
originally in [NGMN_Network_Slicing] (we will use the term sub-
netslices here, instead of the original subnet or sub-networks, which
can be confusing). Sub-netslice instances are comprised of physical
and virtual resources, have a life cycle independent from network
slices they belong to, can be shared between several network slices
and may be associated with other sub-netslice instances.
Multiple management use cases are described, ranging from creating
and monitoring a slice instance to configuring its SLA policy,
capacity and roaming support. It is also expected that some level of
slice management will be exposed to customers, and that operators
will have the possibility to create end-to-end network slices
involving multiple operators' networks.
Key issues are identified, including creating a slice across multiple
administrative domains, sharing a network slice between multiple
services, moving towards a more autonomous management, as well as
additional management specific key issues.
Finally, the life cycle of a slice is defined over 4 phases:
preparation phase including design and pre-provisioning, an
"instantiation, configuration and activation" phase, a run-time phase
including supervision and reporting, as well as upgrade,
reconfiguration and scaling, and a decommissioning phase.
5. 5G Virtual Infrastructure Management in 3GPP
To support the logical architecture defined earlier, some aspects of
virtualization infrastructure management are also being standardized
by 3GPP, through the activity "Management of mobile networks that
include virtualized network functions". This includes 5 work tasks,
the first of which deals with concept, architecture and requirements
[_3GPP.28.500], and 4 additional specialized work tasks on
configuration, fault, lifecycle and performance management, are in
the process of creating more detailed technical specification
documents.
de Foy & Rahman Expires September 7, 2017 [Page 8]
Internet-Draft Network Slicing 3GPP Use Case March 2017
The new 5G management system is tied to NFV-MANO, as defined by ETSI.
Its system architecture is described in [_3GPP.28.500] and
represented in Figure 3 (directly adapted from TS28.500). It defines
interconnections between the 3GPP management system and the NFV-MANO
system. NFV-MANO has the responsibility to manage NFV Infrastructure
(NFVI) and VNF lifecycle, and to report performance data, fault and
VNF instance information to 3GPP management system.
+--------------------------------------------+ +-------------+
| +----------------------------------+OSS/BSS| | NFV |(3)
| | NM | | (1)|Orchestrator +--+
| +--+--------------+--------------+-+ +----+ (NFVO) | |
+----|--------------|--------------|---------+ +-------------+ |
| | | |(2) |
| Itf-N | Itf-N | Itf-N | |
| | | +------+------+ |
| | | | | |
| +---------+------------+ | | | |
| |DM +----------------+ | | (5) | | |
| | | EM +------------------+ VNF | |
| | +-+--------+-----+ | | (5) | Manager | |
| +-----|--------|-------+ | +----------+ (VNFM) | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
+-+-+--+ | | +--+---++--+ (5) | | |
| | EM | | | | EM | +------+ | |
| +----+ | | +-------+ | +------+------+ |
| | | | | VNF | | |
| | +----++ +----+----+ +----+-----+ |(4) |
| | | | | | | | |
| | | | | VNF | | | |
| | | | | | |(7) | |
| | | | +-----+---+ | +------+------+ |
| | | | |(7) | | | |
| NE | | NE | +-----+----------+----+ | Virtualized | |
| (PNF)| |(PNF)| | | | Infrastruct.| |
| | | | | NFV Infrastructure | (6) | Manager +--+
| | | | | (NFVI) +-------+ (VIM) |
| | | | | | | |
+------+ +-----+ +---------------------+ +-------------+
Figure 3: 3GPP Network Management Architecture
The major building blocks on the left are from pre-existing 3GPP
architecture and on the right are from ETSI NFV architecture. Itf-N
is the traditional 3GPP management interface between the network
de Foy & Rahman Expires September 7, 2017 [Page 9]
Internet-Draft Network Slicing 3GPP Use Case March 2017
manager and domain and element managers, some of which will now be
collocated with VNFs. Other interfaces identified in the diagram are
defined as part of the NFV architecture and described in published
NFV specifications (which themselves do not make mention of network
slicing).
o (1) Os-Ma-nfvo enables managing Network Service Descriptors (NSD),
network service lifecycle, performance, faults and VNF packages.
The NSD information model is specified by ETSI NFV as well. It
enables describing network connectivity topology graphs where VNFs
are connected together through virtual links. An NSD also
includes VNF descriptors, which include memory and CPU
requirements, a link to a software image, initial setup scripts,
etc.
o (2) Or-Vnfm includes package management, VNF lifecycle/fault/
configuration management, virtualized resources management (in
indirect mode as seen below), and relays notifications from the
VNF or EM.
o (3) Or-Vi and (4) Vi-Vnfm are the northbound interface of the
Virtual Infrastructure Manager (VIM). The orchestrator can
basically use a direct interface to VIM, or indirectly go through
the VNF manager over Or-Vnfm. The orchestrator can add software
images, create/update/terminate virtualized compute/network/
storage resources allocations, manage resource capacity, manage
network virtual paths, run and query performance collection jobs,
set quotas. Location/affinity constraints can be applied when
creating resources.
o (5) Ve-Vnfm is used both between VNFM and EM and between VNFM and
VNFs. It includes lifecycle, performance, fault and configuration
management, as well as notifications from the EM that VNFM can
subscribe to.
o (6) Nf-Vi is for assignment of virtualized resources, hardware
resource configuration and state information exchange.
o (7) Vn-Nf represents the execution environment provided to the
VNF.
6. Security Considerations
The present section on network slicing security is based on the
"Study on Architecture and Security for Next Generation System", a
Release 14 study item. Its related technical report is
[_3GPP.33.899], and covers, among other areas, a network slicing
security area dealing with service access, network function sharing
de Foy & Rahman Expires September 7, 2017 [Page 10]
Internet-Draft Network Slicing 3GPP Use Case March 2017
and isolation. Multiple key issues are summarized here (refer to the
TR section 5.8 for more details):
1. Isolation requirements, especially performance isolation, ask for
data plane actions on one slice to have no influence on other
slices and for control plane actions (e.g. creation/update/
deletion) to have little influence on other slices. Lack of
isolation can enable DoS attacks from one slice to another,
especially since some functions can be shared between slices.
Moreover, a device can access multiple slices, which increases
the possibility for leakage/breach type of issues between slices,
both from the device and the service side.
2. Different slices may need to implement different security
policies, e.g. in term of authentication requirements (IoT vs.
mobile broadband user). Authentication may be centralized and/or
per-slice.
3. Security and privacy of devices' access to slices is also a
concern. It may be possible to forge slice selection information
for a device. Slice selection information sent over the access
network can also lead to confidentiality issues. The proposed
key hierarchy supports having different keys for different
slices. How to enable security isolation of a common control
plane between different slices is not addressed at this point.
4. Security of sensitive shared network elements such as the HSS
(which holds customers' profiles) is identified as a key issue as
well.
5. Slice management functions should be secured, since an attacker
may use them, e.g. to delete a slice. Slice management
capabilities exposed through APIs for 3rd parties are especially
vulnerable.
6. Security on inter-slice communications is an issue in several
scenarios, for example when multiple slices share control plane
functions, and when a RAN slice and a core network slice are
interconnected to form a complete slice. Each slice is
considered a different trusted domain.
7. A range of potential issues related to virtualization are yet to
be explored further, though it is not clear if they are in the
scope of 3GPP. Issues include for example isolation between VNFs
hosted by the same hypervisor, authentication between VNFs,
performance isolation between VNFs.
de Foy & Rahman Expires September 7, 2017 [Page 11]
Internet-Draft Network Slicing 3GPP Use Case March 2017
7. Conclusion
This document summarized our understanding of 5G architecture and
requirements for network slicing, as defined by 3GPP, in their
current state. Our goal was to provide context to IETF NETSLICES,
since a protocol or framework defined by IETF for network slicing may
be used to implement or interoperate with 3GPP-compliant 5G systems.
In reference to Figure 3, the scope of IETF involvement with network
slicing could be within NFV Infrastructure, as well as some aspects
of the control plane on the right-hand side of the figure.
Here is a list of discussion points gathered while preparing this
document, in no particular order:
1. The concept of "sub-netslice" in section 4 may be useful as a
building block, e.g. a single-domain, indivisible and composable
service chain that is used to assemble a network slice. Defining
the interfaces of such a component could help focusing on sharing
between slices and extending slices across domains.
2. A large portion of the NS-related logical architecture agreements
so far is focusing on network slice instance selection. 3GPP
architecture demonstrate a requirement for common authentication
and network slice selection functions. It is our understanding
that the described mechanism enables a wide variation of cases
associating "n" slices with "m" network services or applications
involving "p" end devices. For example: a single slice instance
could be associated with multiple IoT applications, each
connected to multiple devices. In another example, an
application may split its end users in 2 service categories with
different SLAs, using different network slice instances.
3. Interoperation between slices is a major risk factor on isolation
and can occur in various scenarios:
* "Interoperation for extension" when data and control plane are
interconnected for extending a slice between RAN and CN, or
between visitor and home networks in a roaming scenario.
* "Interoperation through network function sharing" occurs in
3GPP when some control planes functions are performed by
common functions.
* "Interoperation through end points" can occur on user devices
connected to multiple network slices, or on an application
server side interacting with clients over different slices.
de Foy & Rahman Expires September 7, 2017 [Page 12]
Internet-Draft Network Slicing 3GPP Use Case March 2017
4. Sharing and interoperation within slices is also a concern and
occurs at multiple levels: QoS differentiation within a given
slice, and sharing a single slice between multiple services.
Deployment of a single slice over multiple data centers is not an
explicitly described scenario but may possibly be implied by the
use of virtualization of core network function.
5. Managing and deploying 3rd party network services is a potential
use case for network slicing. For example, network slice
management will likely be partially exposed to customers.
Additionally, an early requirement, that was finally not included
in the 3GPP specifications for network slicing, mentioned
"hosting multiple 3rd parties (e.g., enterprises) or MVNOs".
6. There is a strict requirement for security and performance
isolation from data plane and control plane actions between
slices. Should network slices be allowed to tap into currently
unused resource capacity? There is a possible tradeoff here
between performance/network efficiency and isolation, since in
this case, through its normal operation, a slice may influence
another slice by denying it this extra capacity.
7. Beyond performance isolation, there are multiple security
concerns related to network slicing, including the need for
separate per-netslice security policies.
We hope these points will contribute to the ongoing discussion taking
place in IETF NETSLICES to define requirements and work areas related
to network slicing.
8. IANA Considerations
This document requests no IANA actions.
9. Acknowledgements
The authors would like to thank Ulises Olvera-Hernandez for his
contribution and comments.
10. Informative References
[_3GPP.22.261]
3GPP, "Service requirements for next generation new
services and markets", 3GPP TS 22.261 1.1.0, February
2017, <http://www.3gpp.org/ftp/Specs/html-info/22261.htm>.
de Foy & Rahman Expires September 7, 2017 [Page 13]
Internet-Draft Network Slicing 3GPP Use Case March 2017
[_3GPP.23.401]
3GPP, "General Packet Radio Service (GPRS) enhancements
for Evolved Universal Terrestrial Radio Access Network
(E-UTRAN) access", 3GPP TS 23.401 14.2.0, 12 2016,
<http://www.3gpp.org/ftp/Specs/html-info/23401.htm>.
[_3GPP.23.501]
3GPP, "System Architecture for the 5G System", 3GPP
TS 23.501 0.2.0, 2 2017,
<http://www.3gpp.org/ftp/Specs/html-info/23501.htm>.
[_3GPP.23.799]
3GPP, "Study on Architecture for Next Generation System",
3GPP TR 23.799 14.0.0, 12 2016,
<http://www.3gpp.org/ftp/Specs/html-info/23799.htm>.
[_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>.
[_3GPP.28.801]
3GPP, "Study on management and orchestration of network
slicing for next generation network", 3GPP TR 28.801
0.4.0, 1 2017,
<http://www.3gpp.org/ftp/Specs/html-info/28801.htm>.
[_3GPP.33.899]
3GPP, "Study on the security aspects of the next
generation system", 3GPP TR 33.899 0.6.0, 11 2016,
<http://www.3gpp.org/ftp/Specs/html-info/33899.htm>.
[_3GPP.38.801]
3GPP, "Study on the security aspects of the next
generation system", 3GPP TR 38.801 1.0.0, 12 2016,
<http://www.3gpp.org/ftp/Specs/html-info/38801.htm>.
[I-D.gdmb-netslices-intro-and-ps]
Galis, A., Dong, J., kiran.makhijani@huawei.com, k.,
Bryant, S., Boucadair, M., and P. Martinez-Julia, "Network
Slicing - Introductory Document and Revised Problem
Statement", draft-gdmb-netslices-intro-and-ps-02 (work in
progress), February 2017.
de Foy & Rahman Expires September 7, 2017 [Page 14]
Internet-Draft Network Slicing 3GPP Use Case March 2017
[NGMN_Network_Slicing]
NGMN, "Description of Network Slicing Concept", 1 2016,
<https://www.ngmn.org/uploads/
media/160113_Network_Slicing_v1_0.pdf>.
Authors' Addresses
Xavier de Foy
InterDigital Communications, LLC
Montreal
Canada
Email: Xavier.Defoy@InterDigital.com
Akbar Rahman
InterDigital Communications, LLC
Montreal
Canada
Email: Akbar.Rahman@InterDigital.com
de Foy & Rahman Expires September 7, 2017 [Page 15]