Internet DRAFT - draft-bernardos-spawn-use-cases
draft-bernardos-spawn-use-cases
SPAWN G. Papadopoulos
Internet-Draft IMT Atlantique
Intended status: Standards Track P. Thubert
Expires: September 26, 2019 Cisco
F. Theoleyre
CNRS
CJ. Bernardos
UC3M
March 25, 2019
SPAWN use cases
draft-bernardos-spawn-use-cases-00
Abstract
The wireless medium presents significant specific challenges to
achieve properties similar to those of wired deterministic networks.
At the same time, a number of use cases cannot be solved with wires
and justify the extra effort of going wireless. This document
presents some of these use-cases.
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/.
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 26, 2019.
Copyright Notice
Copyright (c) 2019 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
Papadopoulos, et al. Expires September 26, 2019 [Page 1]
Internet-Draft SPAWN use cases scenarios March 2019
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Amusement Parks . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Use Case Description . . . . . . . . . . . . . . . . . . 4
2.2. Specificities . . . . . . . . . . . . . . . . . . . . . . 5
2.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 5
2.4. Asks for SPAWN . . . . . . . . . . . . . . . . . . . . . 6
3. Wireless for Industrial Applications . . . . . . . . . . . . 6
3.1. Use Case Description . . . . . . . . . . . . . . . . . . 6
3.2. Specificities . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Control Loops . . . . . . . . . . . . . . . . . . . . 6
3.2.2. Unmeasured Data . . . . . . . . . . . . . . . . . . . 7
3.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 7
3.4. Asks for SPAWN . . . . . . . . . . . . . . . . . . . . . 8
4. Pro Audio and Video . . . . . . . . . . . . . . . . . . . . . 8
4.1. Use Case Description . . . . . . . . . . . . . . . . . . 8
4.2. Specificities . . . . . . . . . . . . . . . . . . . . . . 9
4.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 9
4.4. Asks for SPAWN . . . . . . . . . . . . . . . . . . . . . 9
5. UAV control . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Use Case Description . . . . . . . . . . . . . . . . . . 9
5.2. Specificities . . . . . . . . . . . . . . . . . . . . . . 9
5.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 10
5.4. Asks for SPAWN . . . . . . . . . . . . . . . . . . . . . 10
6. Edge Robotics control . . . . . . . . . . . . . . . . . . . . 10
6.1. Use Case Description . . . . . . . . . . . . . . . . . . 10
6.2. Specificities . . . . . . . . . . . . . . . . . . . . . . 11
6.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 11
6.4. Asks for SPAWN . . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Informative References . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
Based on time, resource reservation, and policy enforcement by
distributed shapers, Deterministic Networking provides the capability
to carry specified unicast or multicast data streams for real-time
applications with extremely low data loss rates and bounded latency,
Papadopoulos, et al. Expires September 26, 2019 [Page 2]
Internet-Draft SPAWN use cases scenarios March 2019
so as to support time-sensitive and mission-critical applications on
a converged enterprise infrastructure.
Deterministic Networking in the IP world is an attempt to eliminate
packet loss for a committed bandwidth while ensuring a worst case
end-to-end latency, regardless of the network conditions and across
technologies. It can be seen as a set of new Quality of Service
(QoS) guarantees of worst-case delivery. IP networks become more
deterministic when the effects of statistical multiplexing (jitter
and collision loss) are mostly eliminated. This requires a tight
control of the physical resources to maintain the amount of traffic
within the physical capabilities of the underlying technology, e.g.,
by the use of time-shared resources (bandwidth and buffers) per
circuit, and/or by shaping and/or scheduling the packets at every
hop.
Key attributes of Deterministic Networking include:
o time synchronization on all the nodes,
o centralized computation of network-wide deterministic paths, and
o new traffic shapers within and at the edge to protect the network.
Wireless operates on a shared medium, and transmissions cannot be
fully deterministic due to uncontrolled interferences, including
self-induced multipath fading. Scheduling transmissions enables to
alleviate those effects by leveraging diversity in the spatial, time
and frequency domains, enabling Scheduled Predictable and Available
Wireless Networks (SPAWN).
The wireless and wired media are fundamentally different at the
physical level, and while the generic Problem Statement
[I-D.ietf-detnet-problem-statement] for DetNet applies to the wired
as well as the wireless medium, the methods to achieve SPAWN
necessarily differ from those used to support Time-Sensitive
Networking over wires.
So far, Open Standards for Deterministic Networking have prevalently
been focused on wired media, with Audio/Video Bridging (AVB) and Time
Sensitive Networking (TSN) at the IEEE and DetNet
[I-D.ietf-detnet-architecture] at the IETF. But wires cannot be used
in a number of cases, including mobile or rotating devices,
rehabilitated industrial buildings, wearable or in-body sensory
devices, vehicle automation and multiplayer gaming.
Purpose-built wireless technologies such as [ISA100], which
incorporates IPv6, were developed and deployed to cope for the lack
Papadopoulos, et al. Expires September 26, 2019 [Page 3]
Internet-Draft SPAWN use cases scenarios March 2019
of open standards, but they yield a high cost in OPEX and CAPEX and
are limited to very few industries, e.g., process control, concert
instruments or racing.
This is now changing:
o IMT-2020 has recognized Ultra-Reliable Low-Latency Communication
(URLLC) as a key functionality for the upcoming 5G,
o IEEE 802.11 is integrating real-time applications in the charter
of the Extreme High Throughput (EHT) Task Group (to be formed at
the time of this writing), and
o the IETF has produced an IPv6 stack for IEEE Std. 802.15.4
TimeSlotted Channel Hopping (TSCH) and an architecture
[I-D.ietf-6tisch-architecture] that enables Scheduled Predictable
and Available Wireless Networks (SPAWN) on a shared MAC.
This draft extends the "Deterministic Networking Use Cases"
[I-D.ietf-detnet-use-cases] and describes a number of additional use
cases which require deterministic flows over wireless links and
possibly complex multi-hop paths called Tracks.
2. Amusement Parks
2.1. Use Case Description
The digitalization of Amusement Parks is expected to decrease
significantly the cost for maintaining the attractions. By
monitoring in real-time the machines, predictive maintenance will
help to reduce the repairing cost as well as the downtime. Besides,
the attractions may use wireless transmissions to interconnect
sensors and actuators, to privileged reconfigurability, and
standardization.
Attractions may comprise a large set of sensors and actuators, which
react in real time. Typical applications (ordered by criticality in
descending order) are:
o emergency: safety has to be preserved. An attraction has to be
stopped if a failure is detected;
o real-time control: real-time applications embedded in the
attraction need to trigger an action when an event is detected.
For instance, a photograph can be taken when a car crosses an
actuator, combined with a wireless ID that the tourists wear;
Papadopoulos, et al. Expires September 26, 2019 [Page 4]
Internet-Draft SPAWN use cases scenarios March 2019
o predictive maintenance: statistics are collected to predict the
future failures, or to compute later more complex statistics about
the attraction's usage, the downtime, its popularity, etc.
2.2. Specificities
Amusement parks comprise a variable number of attractions, mostly
outdoor. Thus,
The tourists are free to move from an attraction to another, covering
a large geographical area. Wearable devices are expected for a user
experience personalisation. Thus, some devices may be mobile, while
the rest of the infrastructure remains static.
The infrastrcuture is typically multi-scale:
o local area: the sensors and actuators controlling the attractions
are co-located. Real-time flows are localized, a set of sensors
triggering actuators. Maintenance flows are mostly lrage-range,
interconnected with the information system;
o wearable devices are free to move in the park. They exchange
traffic locally (identification, personalization, multimedia) or
globally (billing child tracking);
o global information system manages the whole park, and exchange
commands or information with the different parts.
2.3. The Need for Wireless
Amusement parks cover large areas and a global interconnection would
require a huge length of cables. Wireless also optimizes the
reconfigurability, enabling to plug novel services easily to increase
e.g. the interactivity.
Attractions comprise mobile components (e.g. robots, wagons), which
require wireless connections since cables are particulalry
inconvenient and source of failures in such conditions.
Wearable devices have to support by nature wireless transmissions.
They aim to enable novel high-value services. VIP tickets are
nowadays more and more popular. Wireless wearable devices may help
to reduce the operating costs [disney-VIP] and increasing the number
of charged services provided to the audience (VIP tickets,
interactivity, etc.)
Papadopoulos, et al. Expires September 26, 2019 [Page 5]
Internet-Draft SPAWN use cases scenarios March 2019
2.4. Asks for SPAWN
The networ infrastructure has to support heterogenous traffic, with
very different criticalities. Thus, flow isolation has to be
provided, where best effort traffic only
We have to schedule appropriately the transmissions, even in presence
of mobile devices. While the [I-D.ietf-6tisch-architecture] already
proposes an architecture for synchronized, IEEE Std. 802.15.4 Time-
Slotted Channel Hopping (TSCH) networks, 6TiSCH focused on best-
effort IPv6 flows. SPAWN expects to schedule appropriately the
transmissions, across heterogeneous technologies, with strict SLA
requirements.
Nowadays, long-range wireless transmissions are used for best-effort
traffic, and [IEEE802.1TSN] is used for critical flows using Ethernet
devices. However, we need an IP enabled technology to interconnect
large areas, independent of the PHY and MAC layer to maximize the
compliance.
3. Wireless for Industrial Applications
3.1. Use Case Description
A major use case for networking in Industrial is the control networks
where periodic control loops operate between a sensor that measures a
physical property such as the temperature of a fluid, a Programmable
Logic Controller that decides an action such as warm up the mix, and
an actuator that performs the required action, e.g., inject power in
a resistor.
3.2. Specificities
3.2.1. Control Loops
Process Control designates continous processing operations, e.g.,
heating Oil in a refinery or mixing drinking soda. Control loops in
the Process Control industry operate at a very low rate, typically 4
times per second. Factory Automation, on the other hand, deal with
discrete goods such as individual automobile parts, and requires
faster loops, in the order of 10ms. Motion control that monitors
dynamic activities may require even faster rates in the order of a
few ms. Finally, some industries exhibit hybrid behaviors, like
canned soup that will start as a process industry while mixing the
food and then operate as a discrete manufacturing when putting the
final product in cans and shipping them.
Papadopoulos, et al. Expires September 26, 2019 [Page 6]
Internet-Draft SPAWN use cases scenarios March 2019
In all those cases, a packet must flow deterministically between the
sensor and the PLC, be processed by the PLC, and sent to the actuator
within the control loop period. In some particular use cases that
inherit from analog operations, jitter might also alter the operation
of the control loop. A rare packet loss is usually admissible, but
typically 4 losses in a row will cause an emergency halt of the
production and incur a high cost for the manufacturer.
3.2.2. Unmeasured Data
A secondary use case deals with monitoring and diagnostics. This so-
called unmeasured data is essential to improve the performances of a
production line, e.g., by optimizing real-time processing or
maintenance windows using Machine Learning predictions. For the lack
of wireless technologies, some specific industries such as Oil and
Gas have been using serial cables, literally by the millions, to
perform their process optimization over the previous decades. But
few industries would afford the associated cost and the Holy Grail of
the Industrial Internet of Things is to provide the same benefits to
all industries, including SmartGrid, Transportation, Building,
Commercial and Medical. This requires a cheap, available and
scalable IP-based access technology.
Inside the factory, wires may already be available to operate the
Control Network. But unmeasured data are not welcome in that network
for a number of reasons. On the one hand it is rich and
asynchronous, meaning that using they may influence the deterministic
nature of the control operations and impact the production. On the
other hand, this information must be reported to the carpeted floor
over IP, which means the potential for a security breach via the
interconnection of the Operational Technology (OT) network with the
Internet technology (IT) network and possibly enable a rogue access.
3.3. The Need for Wireless
Ethernet cables used on a robot arm are prone to breakage after a few
thousands flexions, a lot faster than a power cable that is wider inn
diameter, and more resilient. In general, wired networking and
mobile parts are not a good match, mostly in the case of fast and
recurrent activities, as well as rotation.
When refurbishing older premises that were built before the Internet
age, power is usually available everywhere, but data is not. It is
often impractical, time consuming and expensive to deploy an Ethernet
fabric across walls and between buildings. Deploying a wire may take
months and cost tens of thousands of US Dollars.
Papadopoulos, et al. Expires September 26, 2019 [Page 7]
Internet-Draft SPAWN use cases scenarios March 2019
Even when wiring exists, e.g., in an existing control network,
asynchronous IP packets such as diagnostics may not be welcome for
operational and security reasons (see Section 3.2.1). An alternate
network that can scale with the many sensors and actuators that equip
every robot, every valve and fan that are deployed on the factory
floor and may help detect and prevent a failure that could impact the
production. IEEE Std. 802.15.4 Time-Slotted Channel Hopping (TSCH)
[RFC7554] is a promising technology for that purpose, mostly if the
scheduled operations enable to use the same network by asynchronous
and deterministic flows in parallel.
3.4. Asks for SPAWN
As stated by the "Deterministic Networking Problem Statement"
[I-D.ietf-detnet-problem-statement], a Deterministic Network is
backwards compatible with (capable of transporting) statistically
multiplexed traffic while preserving the properties of the accepted
deterministic flows. While the [I-D.ietf-6tisch-architecture] serves
that requirement, the work at 6TiSCH was focused on best-effort IPv6
packet flows. SPAWN should be able to lock so-called hard cells for
use by a centralized scheduler, and program so-called end-to-end
Tracks over those cells.
Over the course of the recent years, major Industrial Protocols,
e.g., [ODVA] with EtherNet/IP [EIP] and [Profinet], have been
migrating towards Ethernet and IP. In order to unleash the full
power of the IP hourglass model, it should be possible to deploy any
application over any network that has the physical capacity to
transport the industrial flow, regardless of the MAC/PHY technology,
wired or wireless, and across technologies. SPAWN should be able to
setup a Track over a wireless access segment such as TSCH and a
backbone segment such as Ethernet or WI-Fi, to report a sensor data
or a critical monitoring within a bounded latency.
4. Pro Audio and Video
4.1. Use Case Description
The professional audio and video industry ("ProAV") includes:
o Public address, media and emergency systems at large venues
(airports, stadiums, train stations, churches, theme parks).
Today the ProAV applications are moving towards packet-based
technology to introduce routing features and to reduce costs.
Papadopoulos, et al. Expires September 26, 2019 [Page 8]
Internet-Draft SPAWN use cases scenarios March 2019
4.2. Specificities
Considering the uninterrupted audio or video stream, a potential
packet losses during the transmission of audio or video flows cannot
be tackled by re-trying the transmission, as it is done with file
transfer, because by the time the packet lost has been identified it
is too late to proceed with packet re-transmission.
4.3. The Need for Wireless
4.4. Asks for SPAWN
TBD.
5. UAV control
5.1. Use Case Description
Unmanned Aerial Vehicles (UAVs) are becoming very popular for many
different applications, including military and civil use cases. The
term drone is commonly used to refer to a UAV.
UAVs can be used to perform aerial surveillance activities, traffic
monitoring (e.g., Spanish traffic control has recently introduced a
fleet of drones for quicker reactions upon traffic congestion related
events), support of emergency situations, and even transportation of
small goods.
UAVs typically have various forms of wireless connectivity:
o cellular: for communication with the control center, for remote
manuevering as well as monitoring of the drone;
o IEEE 802.11: for inter-drone communications (e.g., coordination of
actions, platooning) and providing connectivity to other devices
(e.g., acting as Access Point).
5.2. Specificities
Some of the use cases/tasks involving drones require coordination
among drones. Others involve complex compute tasks that might not be
performed using the limited computing resources that a drone
typically has. These two aspects require continuous connectivity
with the control center and among drones.
Remote maneuvering of a drone might be performed over a cellular
network in some cases, however, there are situations that need very
low latencies and deterministic behavior of the connectivity.
Papadopoulos, et al. Expires September 26, 2019 [Page 9]
Internet-Draft SPAWN use cases scenarios March 2019
Examples involve platooning of drones or sharing of computing
resources among drones (e.g., a drone offload some function to a
neighboring drone).
5.3. The Need for Wireless
UAVs cannot be connected through any type of wired media, so it is
obvious that wireless is needed.
5.4. Asks for SPAWN
The network infrastructure is actually composed by the UAVs
themselves, requiring self-configuration capabilities.
Heterogeneous types of traffic need to be supported, from extremely
critical ones requiring ultra low latency and high resiliency, to
traffic requiring low-medium latency.
When a given service is decomposed into functions -- hosted at
different drones -- chained, each link connecting two given functions
would have a well-defined set of requirements (latency, bandwith and
jitter) that have to be met.
6. Edge Robotics control
6.1. Use Case Description
The Edge Robotics scenario consists of several robots, deployed in a
given area (for example a shopping mall), inter-connected via an
access network to a network's edge device or a data center. The
robots are connected to the edge so complex computational activities
are not executed locally at the robots, but offloaded to the edge.
This brings additional flexibility in the type of tasks that the
robots do, as well as reducing the costs of robot manufacturing (due
to their lower complexity), and enabling complex tasks involving
coordination among robots (that can be more easily performed if
robots are centrally controlled).
A simple example of the use of multiples robots is cleaning,
delivering of goods from warehouses to shops or video surveillance.
Multiple robots are simultaneously instructed to perform individual
tasks by moving the robotic intelligence from the robots to the
network's edge (e.g., data center). That enables easy
synchronization, scalable solution and on-demand option to create
flexible fleet of robots.
Robots would have various forms of wireless connectivity:
Papadopoulos, et al. Expires September 26, 2019 [Page 10]
Internet-Draft SPAWN use cases scenarios March 2019
o IEEE 802.11: for connection to the edge and also inter-robot
communications (e.g., for coordinated actions);
o cellular: as an additional communication link to the edge, though
primarily as backup, since ultra low latencies are needed.
6.2. Specificities
Some of the use cases/tasks involving robots might benefit from
decomposition of a service in small functions that are distributed
and chained among robots and the edge. These require continuous
connectivity with the control center and among drones.
Robot control is an activity requiring very low latencies between the
robot and the location where the control intelligence resides (which
might be the edge or another robot).
6.3. The Need for Wireless
Deploying robots in scenarios such as shopping malls for the
aforementioned applications cannot be done via wired connectivity.
6.4. Asks for SPAWN
The network infrastructure needs to support heterogeneous types of
traffic, from robot control to video streaming.
When a given service is decomposed into functions -- hosted at
different robots -- chained, each link connecting two given functions
would have a well-defined set of requirements (latency, bandwith and
jitter) that have to be met.
7. IANA Considerations
TBD.
8. Security Considerations
TBD.
9. Informative References
[disney-VIP]
Wired, "Disney's $1 Billion Bet on a Magical Wristband",
March 2015,
<https://www.wired.com/2015/03/disney-magicband/>.
Papadopoulos, et al. Expires September 26, 2019 [Page 11]
Internet-Draft SPAWN use cases scenarios March 2019
[EIP] http://www.odva.org/, "EtherNet/IP provides users with the
network tools to deploy standard Ethernet technology (IEEE
802.3 combined with the TCP/IP Suite) for industrial
automation applications while enabling Internet and
enterprise connectivity data anytime, anywhere.",
<http://www.odva.org/Portals/0/Library/
Publications_Numbered/
PUB00138R3_CIP_Adv_Tech_Series_EtherNetIP.pdf>.
[I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-20 (work
in progress), March 2019.
[I-D.ietf-detnet-architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf-
detnet-architecture-12 (work in progress), March 2019.
[I-D.ietf-detnet-problem-statement]
Finn, N. and P. Thubert, "Deterministic Networking Problem
Statement", draft-ietf-detnet-problem-statement-09 (work
in progress), December 2018.
[I-D.ietf-detnet-use-cases]
Grossman, E., "Deterministic Networking Use Cases", draft-
ietf-detnet-use-cases-20 (work in progress), December
2018.
[IEEE802.1TSN]
IEEE standard for Information Technology, "IEEE
802.1AS-2011 - IEEE Standard for Local and Metropolitan
Area Networks - Timing and Synchronization for Time-
Sensitive Applications in Bridged Local Area Networks".
[ISA100] ISA/ANSI, "ISA100, Wireless Systems for Automation",
<https://www.isa.org/isa100/>.
[ODVA] http://www.odva.org/, "The organization that supports
network technologies built on the Common Industrial
Protocol (CIP) including EtherNet/IP.".
[Profinet]
http://us.profinet.com/technology/profinet/, "PROFINET is
a standard for industrial networking in automation.",
<http://us.profinet.com/technology/profinet/>.
Papadopoulos, et al. Expires September 26, 2019 [Page 12]
Internet-Draft SPAWN use cases scenarios March 2019
[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
Internet of Things (IoT): Problem Statement", RFC 7554,
DOI 10.17487/RFC7554, May 2015,
<https://www.rfc-editor.org/info/rfc7554>.
Authors' Addresses
Georgios Z. Papadopoulos
IMT Atlantique
Office B00 - 114A
2 Rue de la Chataigneraie
Cesson-Sevigne - Rennes 35510
FRANCE
Phone: +33 299 12 70 04
Email: georgios.papadopoulos@imt-atlantique.fr
Pascal Thubert
Cisco Systems, Inc
Building D
45 Allee des Ormes - BP1200
MOUGINS - Sophia Antipolis 06254
FRANCE
Phone: +33 497 23 26 34
Email: pthubert@cisco.com
Fabrice Theoleyre
CNRS
Office B-270
Boulevard Sebastien Brant
Illkirch 67400
FRANCE
Phone: +33 368 85 45 33
Email: theoleyre@unistra.fr
Papadopoulos, et al. Expires September 26, 2019 [Page 13]
Internet-Draft SPAWN use cases scenarios March 2019
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Papadopoulos, et al. Expires September 26, 2019 [Page 14]
