Internet DRAFT - draft-qin-netslices-use-cases
draft-qin-netslices-use-cases
Network Working Group J. Qin
Internet-Draft K. Makhijani
Intended status: Informational J. Dong
Expires: September 14, 2017 L. Qiang
S. Peng
Huawei Technologies
March 13, 2017
Network Slicing Use Cases: Network Customization for Different Services
draft-qin-netslices-use-cases-00
Abstract
Network Slicing (NS) is widely discussed and considered in 5G
communities and standard organizations as a key mechanism to meet
diverse service requirements concurrently with the same physical
network infrastructure. NS enables the operator to provide isolated
platform for service verticals, and deploy new services without
causing or experiencing any disruption to other already deployed
services in the same physical network infrastructure. This document
describes the typical use cases that could benefit from network
slicing, to support each case, the corresponding requirements on 5G
transport network will be analyzed.
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 [RFC2119].
Additionally, the key words "MIGHT", "COULD", "MAY WISH TO", "WOULD
PROBABLY", "SHOULD CONSIDER", and "MUST (BUT WE KNOW YOU WON'T)" in
this document are to interpreted as described in RFC 6919 [RFC6919].
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
Qin, et al. Expires September 14, 2017 [Page 1]
Internet-Draft Use Case for Network Slicing March 2017
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 14, 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Network Customization Requirement for Diverse Services . . . 4
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Network Customization Concept . . . . . . . . . . . . . . 4
2.3. Service Requirements from Customized Networks . . . . . . 4
3. Use Cases Demanding NS . . . . . . . . . . . . . . . . . . . 5
3.1. eMBB Type NS Use Case . . . . . . . . . . . . . . . . . . 5
3.1.1. HD Video . . . . . . . . . . . . . . . . . . . . . . 5
3.1.2. Virtual Reality (VR)/Augmented Reality (AR) . . . . . 5
3.2. uRLLC Type NS Use Case . . . . . . . . . . . . . . . . . 6
3.2.1. Industrial Operation and Inspection . . . . . . . . . 6
3.2.2. Remote Surgery . . . . . . . . . . . . . . . . . . . 6
3.2.3. Vehicle-to-everything (V2X) . . . . . . . . . . . . . 6
3.3. mMTC Type NS use case . . . . . . . . . . . . . . . . . . 7
3.3.1. Smart City . . . . . . . . . . . . . . . . . . . . . 7
3.3.2. Health Monitoring . . . . . . . . . . . . . . . . . . 7
3.4. Other Type NS Use Case . . . . . . . . . . . . . . . . . 7
3.4.1. Use Cases Have Mixed Requirements . . . . . . . . . . 8
3.4.2. Use Cases Have no Special Requirements . . . . . . . 8
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. Informative References . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
Qin, et al. Expires September 14, 2017 [Page 2]
Internet-Draft Use Case for Network Slicing March 2017
1. Introduction
Network Slicing (NS) has been widely discussed and considered in 5G
communities and standard organizations to meet the diverse service
requirements in different 5G service scenarios. NS refers to the
managed partitions of physical and/or virtual network resources,
network physical/virtual and service functions [RFC7665] that can act
as an independent instance of a connectivity network and/or as a
network cloud [I-D.gdmb-netslices-intro-and-ps]. As [TR23.799] of
3rd Generation Partnership Project (3GPP) identified, "Network
slicing enables the operator to create networks customized to provide
optimized solutions for different market scenarios which demands
diverse requirements, e.g. in the areas of functionality, performance
and isolation". Draft [I-D.gdmb-netslices-intro-and-ps] defines
network slicing in a broad context and suggests related problems and
work areas. Other standardization organizations like Next Generation
Mobile Networks (NGMN) [Network-Slicing-Concept] and ITU-T FG
IMT-2020 [FG-IMT2020-Gaps] also present their separate definitions of
NS.
To maximize resource utilization and minimize infrastructure cost,
services will need to be deployed simultaneously, next to each other
over a shared network as against the traditional monolithic model.
Service operators can utilize or benefit from Network Slicing through
multi-tenancy, enabling different customized infrastructures for
different group of services across different network segments and
operating them independently. Moreover, NS is also able to guarantee
the isolation between different network slices. The operation of the
data packets traversing one network slice do not adversely affect the
service operation in other network slices sharing the same underlying
packet network.
Transport networks need to provide the functionality and capability
required to support end-to-end network slicing. This draft presents
various use cases from diverse industries. In each use case, the
requirement for the transport network is analyzed.
1.1. Terminology
o Over-the-top (OTT): A service, e.g., content delivery using a CDN,
operated by a different operator than the NSP to which the users of
that service are attached.
o Industry Vertical: A collection of services or tools specific to an
industry, trade or market sector.
Qin, et al. Expires September 14, 2017 [Page 3]
Internet-Draft Use Case for Network Slicing March 2017
2. Network Customization Requirement for Diverse Services
2.1. Overview
It should be possible for the providers of above service categories
to continuously evolve, adapt, and differentiate themselves through
purpose-built infrastructures with minimal impact on network
deployment and operations. The motivation behind 5G Network slicing
paradigm is exactly that. By creating logically partitioned network
infrastructures, isolated platforms for various industry verticals
can be provided. NS is envisioned to enable new service deployments
without having to build new network infrastructures or causing
disruptions to other already deployed services in the network.
2.2. Network Customization Concept
Network slicing is enabled through customization. Customization
gives control to the operator (of a slice) to create, provision,
change and consume network resources to suit their service demands.
It requires ability to decompose resources from an underlying network
infrastructure and logically aggregate them to form a customized
network into a slice. These customizations are not only in the
context of the network characteristics but include network functions.
2.3. Service Requirements from Customized Networks
Services or Service Verticals (i.e. a service or group of services
specific to an industry or trade) refer to combination of service
segments in which services are offered to customers with customized
requirements. The customization may be along the following
constraints and features:
o Reliability
o Latency
o Bandwidth
o Redundancy
o Burst
o Security/Encryption
o Mobility
o Authentication
Qin, et al. Expires September 14, 2017 [Page 4]
Internet-Draft Use Case for Network Slicing March 2017
3. Use Cases Demanding NS
The International Telecommunication Union (ITU) has classified 5G
mobile network services into three categories: Enhanced Mobile
Broadband (eMBB), Ultra-reliable and Low-latency Communications
(uRLLC), and Massive Machine Type Communications (mMTC). Based on
this, we give representative use cases that demanding NS in each type
of the services.
3.1. eMBB Type NS Use Case
3.1.1. HD Video
Person-to-person or person-to-group video communication with high
resolution (4K/8K) and more advanced capabilities will have a much
wider usage in 5g era. The gathering in large stadium or some open-
air location, people can watch HD playback video, share live video or
post HD photos to social networks. The connection density and date
rate requirements will be high. Currently the 4K UHD video streaming
service promoted in UK needs at least 40Mbps consistent data rates
[BT-Ultra-HD-review], with 8K UHD and further evolutions these
requirements are likely to increase many fold. In 5g era an
environment will emerge in which video is available to everyone,
regardless of the physical location, the device being used, and the
network connection [NGMN-White-Paper].The number of concurrently
active connections, combined with the bandwidth required will present
a challenging situation for the transport network. For the network,
when a bandwidth intensive trasmission bursts, it is necessaryt to
avoid the performance of the other services being affected.
3.1.2. Virtual Reality (VR)/Augmented Reality (AR)
Virtual Reality(VR)/Augmented Reality(AR) is another demanding use
case of eMBB services. VR/AR video streaming will have far more
stringent network resource requirements than on-demand video content.
It may require it's own dedicated infrastructure with enhanced
network protocols. A mass adoption of bandwidth-hungry VR/AR
immersive services will have a significant impact on network
capacity. The 360 degree video on which VR/AR applications based
today are mostly low resolution, requiring a bandwidth of around 25
Mbit/s for streaming. But as display quality improves towards HD and
eventually retina resolution (5073x5707 per eye and upwards), the
bandwidth required will ramp up significantly. For retina experience
VR/AR, estimates suggest that bandwidths ranging from hundreds of
Mbit/s through to several gigabits per second will be needed for a
fully immersive mobile experience.
Qin, et al. Expires September 14, 2017 [Page 5]
Internet-Draft Use Case for Network Slicing March 2017
3.2. uRLLC Type NS Use Case
3.2.1. Industrial Operation and Inspection
In industry area, usually remote operations need the support of the
mobile transport networks. Remote operation solutions allow people
to operate machinery in a control center at another site that could
avoid the on-site dangers of industrial sites like waterworks, large
process plants, mines, harbors, chemical factory. On the other hand,
deploying a remote or tele-operation for heavy machinery and other
equipments in dangerous environment is one way to cut the size of the
on-site workforce. Securing a high-quality communication link
between the control site and the machines being operated is key to
accurate and effective remote operation. Remote operation requires
the communication with the characteristics of low latency and low
jitter. To manipulate equipment efficiently on a remote site, the
time interval between the instant an operator sends a control
instruction to the moment the equipment's reaction is sensed by the
operator must be as short as possible. A typical haptic control loop
in a remote operation application requires latency to be below
10ms[Technology-Watch-Report].
3.2.2. Remote Surgery
Remote surgery which enables surgeons to perform critical specialized
medical procedures remotely, allowing their vital expertise to be
applied globally. Providing the correct control and feedback for the
surgeon entails very strict requirements in terms of latency,
reliability and security.
3.2.3. Vehicle-to-everything (V2X)
Vehicle-to-everthing (V2X) refers to an intelligent transport system
where all vehicles and infrastructure systems are interconnected with
each other [5GAA White Paper]. This connectivity will provide more
precise knowledge of the traffic situation across the entire road
network which in turn will help: optimize traffic flows, reduce
congestion, cut accident numbers. V2X scenarios have certain common
network functions (dynamic topology, mobility, vehicle subscription)
and then there are specialized operations per services a. V2I in
short-range, adhoc routing, high reliability, higher layer security
and authentication; b. traditional broadband for Infotainment; c. in
network assistance for localized services.
Vehicles on the road cooperate, coordinate and share information with
other vehicles, the information could be collected from sensors on
the road and other vehicles. During the drive a vehicle may
subscribe to various location based services. A vehicle may become
Qin, et al. Expires September 14, 2017 [Page 6]
Internet-Draft Use Case for Network Slicing March 2017
part of of slices such that different customized slice serves low
latency and zero-packet loss slice perhaps with a Vehicular Ad Hoc
Network (VANET) type protocols for vehicle to vehicle and composed of
an access medium (either intelligent transportation systesm (ITS)
band or commercial-cellular) and a part transport and core. Vehicles
also may join remote diagnose network, in which diagnostics, or
software/firmware upgrades to vehicle maybe performed. Remote
diagnose, location-based services are of somewhat less sensitive to
response time. Vehicles will demand enhanced connectivity for in
vehicle entertainment, accessing the Internet, enhanced navigation
through instant and real-time information, autonomous driving, and
safety, which are resource intensive.
3.3. mMTC Type NS use case
3.3.1. Smart City
Smart city is about various kinds of public infrastructures
connecting and harmonizing (relate to machine-to-machine (M2M)
communications based on Internet of things (IoT)). Using various
data sensors, smart city technologies will be able to respond in
real-time to everyday events including metering (e.g., gas, energy,
and water), environment (e.g., pollution, temperature, humidity,
noise) monitoring, city or building lights management, vehicle
traffic control, public safety like nature disaster alerting and
forecasting, etc. The communication network enabling smart city need
to ensure reliable communication over the entire footprint of the
emergency services.
3.3.2. Health Monitoring
Applications of remote health monitoring will continue growing, such
applications will include several devices, like sensors, e.g., for
heart rate, pulse, blood pressure, temperature. Constantly
monitoring vital signs could prevent body conditions from becoming
acute, and adapt medication to meet changing conditions. E-Health
applications can be life critical and the system must be able to
reserve/prioritise capacity for the related communications including
out of coverage warnings. Identity, privacy, security and
authentication management must be ensured for each device.
3.4. Other Type NS Use Case
This type includes those use cases that do not have special
requirements for network infrastructure and those use cases that may
have mixed requirement (e.g. both eMBB and uRLL).
Qin, et al. Expires September 14, 2017 [Page 7]
Internet-Draft Use Case for Network Slicing March 2017
3.4.1. Use Cases Have Mixed Requirements
Use cases that have mixed requirements for the network are
pervasively existed. As described in section 2.1.2, AV/VR may have
high requirements for bandwidth. On the other hand, as most of the
applications for AR and VR are real-time, interactive VR/AR
applications are extremely sensitive to delay and require very low
end-to-end latency. Less than 20ms roundtrip is essential to avoid
users experiencing disorientation and dizziness, which can occur if
there is too much delay between the perception of an action and image
display. In remote controlling, remote operation requires the
communication with the characteristics of low latency and low jitter,
in case of video or voice assisted communication maintenance, the
bandwidth is also important.
Actually, usually most of the services have mixed requirements for
the network, especially for the mMTC type applications.
3.4.2. Use Cases Have no Special Requirements
Over-The-Top(OTT) services are the typical scenario of this kind.
OTT services are those associated with content, like video (with
normal definition), audio, IM messages, web-digital content, and
other media transmitted via the Internet, this kind of communications
are expected to be pervasive and part of everyday life. Most
commonly, a high degree of applications such as VOIP, CDNs are
deployed as OTT services with low expectations from the underlying
network as communication medium and subsequently by building their
own application infrastructure. The trend toward IP (or HTTP) based
content delivery may be perceived as an indicative of network as dumb
pipe. However, QoE is important to content delivery and requires
coordination with the ISPs. With a network slice which represents a
partitioned network infrastructure allocated for content delivery can
help create new opportunities for both network operators and content
providers.
4. Conclusions
Many vertical industries will migrate onto the 5G network, the goal
of 5G is to support various service scenarios from these verticals
that have very different network capability and performance demands.
The above listed typical use cases show that each scenario requires a
different network service and poses requirements that are different,
each of which usually has a set of unique requirements in delay,
jitter, bandwidth, security, availability et., al. These
requirements indicate that the 5G networks need to be more flexible
and scalable to support massive connections of diverse performance
requirements into a single network. The current transport network
Qin, et al. Expires September 14, 2017 [Page 8]
Internet-Draft Use Case for Network Slicing March 2017
architecture is not flexible and scalable enough to support the
various services scenarios and fulfill specific set of performance
requirements of each use case at the same time. Network slicing aims
to support services with diverse requirements to be provided on the
same physical network with guaranteed independence/isolation levels.
Each network slice appears to its users as an independent, dedicated
private network which is impervious to anything that is happening on
any of the other network slices. For the applications that do not
have special requirements for network, the emergence of NS will help
these applications work more economical and effective.
5. IANA Considerations
This document makes no request of IANA.
6. Security Considerations
The security considerations apply to each slice. In addition general
security considerations of underlying infrastructure whether isolated
communication with in a slice apply for links using wireless
technologies.
7. Acknowledgements
Thanks to Stewart Bryant for providing details for several use cases.
8. Informative References
[BT-Ultra-HD-review]
"BT", 2016, <http://www.techradar.com/reviews/audiovisual/
digital-tv-receivers/bt- ultra-hd-youview-box- 1301334/
review>.
[FG-IMT2020-Gaps]
"FG IMT-2020: Report on Standards Gap Analysis", 2015,
<http://www.itu.int/en/ITU-T/focusgroups/imt-2020>.
[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.
[Network-Slicing-Concept]
"Description of Network Slicing Concept", 2016,
<https://www.ngmn.org/uploads/
media/160113_Network_Slicing_v1_0.pdf>.
Qin, et al. Expires September 14, 2017 [Page 9]
Internet-Draft Use Case for Network Slicing March 2017
[NGMN-White-Paper]
"NGMN", 2016, <https://www.ngmn.org/uploads/media/
NGMN_5G_White_Paper_V1_0.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words
for Use in RFCs to Indicate Requirement Levels", RFC 6919,
DOI 10.17487/RFC6919, April 2013,
<http://www.rfc-editor.org/info/rfc6919>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<http://www.rfc-editor.org/info/rfc7665>.
[Technology-Watch-Report]
, 2016, <ITU-T, August 2014, Technology Watch Report, The
Tactile Internet, available at: http://ow.ly/Ubmow>.
[TR23.799]
"Study on Architecture for Next Generation System", 2012,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3008>.
Authors' Addresses
Jun Qin
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
China
Email: qinjun4@huawei.com
Kiran Makhijani
Huawei Technologies
2890 Central Expressway
Santa Clara CA 95050
Email: kiran.makhijani@huawei.com
Qin, et al. Expires September 14, 2017 [Page 10]
Internet-Draft Use Case for Network Slicing March 2017
Jie Dong
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
China
Email: jie.dong@huawei.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
Qin, et al. Expires September 14, 2017 [Page 11]
