idnits 2.17.1
draft-bernardos-raw-use-cases-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (November 4, 2019) is 1634 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Outdated reference: A later version (-30) exists of
draft-ietf-6tisch-architecture-28
== Outdated reference: A later version (-05) exists of
draft-thubert-raw-technologies-03
Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 RAW G. Papadopoulos
3 Internet-Draft IMT Atlantique
4 Intended status: Standards Track P. Thubert
5 Expires: May 7, 2020 Cisco
6 F. Theoleyre
7 CNRS
8 CJ. Bernardos
9 UC3M
10 November 4, 2019
12 RAW use cases
13 draft-bernardos-raw-use-cases-01
15 Abstract
17 The wireless medium presents significant specific challenges to
18 achieve properties similar to those of wired deterministic networks.
19 At the same time, a number of use cases cannot be solved with wires
20 and justify the extra effort of going wireless. This document
21 presents wireless use cases demanding reliable and available
22 behavior.
24 Status of This Memo
26 This Internet-Draft is submitted in full conformance with the
27 provisions of BCP 78 and BCP 79.
29 Internet-Drafts are working documents of the Internet Engineering
30 Task Force (IETF). Note that other groups may also distribute
31 working documents as Internet-Drafts. The list of current Internet-
32 Drafts is at https://datatracker.ietf.org/drafts/current/.
34 Internet-Drafts are draft documents valid for a maximum of six months
35 and may be updated, replaced, or obsoleted by other documents at any
36 time. It is inappropriate to use Internet-Drafts as reference
37 material or to cite them other than as "work in progress."
39 This Internet-Draft will expire on May 7, 2020.
41 Copyright Notice
43 Copyright (c) 2019 IETF Trust and the persons identified as the
44 document authors. All rights reserved.
46 This document is subject to BCP 78 and the IETF Trust's Legal
47 Provisions Relating to IETF Documents
48 (https://trustee.ietf.org/license-info) in effect on the date of
49 publication of this document. Please review these documents
50 carefully, as they describe your rights and restrictions with respect
51 to this document. Code Components extracted from this document must
52 include Simplified BSD License text as described in Section 4.e of
53 the Trust Legal Provisions and are provided without warranty as
54 described in the Simplified BSD License.
56 Table of Contents
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
59 2. Amusement Parks . . . . . . . . . . . . . . . . . . . . . . . 4
60 2.1. Use Case Description . . . . . . . . . . . . . . . . . . 5
61 2.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 5
62 2.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 6
63 2.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 6
64 3. Wireless for Industrial Applications . . . . . . . . . . . . 7
65 3.1. Use Case Description . . . . . . . . . . . . . . . . . . 7
66 3.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 7
67 3.2.1. Control Loops . . . . . . . . . . . . . . . . . . . . 7
68 3.2.2. Unmeasured Data . . . . . . . . . . . . . . . . . . . 7
69 3.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 8
70 3.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 8
71 4. Pro Audio and Video . . . . . . . . . . . . . . . . . . . . . 9
72 4.1. Use Case Description . . . . . . . . . . . . . . . . . . 9
73 4.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 9
74 4.2.1. Uninterrupted Stream Playback . . . . . . . . . . . . 9
75 4.2.2. Synchronized Stream Playback . . . . . . . . . . . . 10
76 4.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 10
77 4.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 10
78 5. Wireless Gaming . . . . . . . . . . . . . . . . . . . . . . . 10
79 5.1. Use Case Description . . . . . . . . . . . . . . . . . . 10
80 5.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 11
81 5.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 11
82 5.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 11
83 6. UAV platooning and control . . . . . . . . . . . . . . . . . 12
84 6.1. Use Case Description . . . . . . . . . . . . . . . . . . 12
85 6.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 12
86 6.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 13
87 6.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 13
88 7. Edge Robotics control . . . . . . . . . . . . . . . . . . . . 13
89 7.1. Use Case Description . . . . . . . . . . . . . . . . . . 13
90 7.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 14
91 7.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 14
92 7.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 14
93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
94 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
95 10. Informative References . . . . . . . . . . . . . . . . . . . 14
96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
98 1. Introduction
100 Based on time, resource reservation, and policy enforcement by
101 distributed shapers, Deterministic Networking provides the capability
102 to carry specified unicast or multicast data streams for real-time
103 applications with extremely low data loss rates and bounded latency,
104 so as to support time-sensitive and mission-critical applications on
105 a converged enterprise infrastructure.
107 Deterministic Networking in the IP world is an attempt to eliminate
108 packet loss for a committed bandwidth while ensuring a worst case
109 end-to-end latency, regardless of the network conditions and across
110 technologies. It can be seen as a set of new Quality of Service
111 (QoS) guarantees of worst-case delivery. IP networks become more
112 deterministic when the effects of statistical multiplexing (jitter
113 and collision loss) are mostly eliminated. This requires a tight
114 control of the physical resources to maintain the amount of traffic
115 within the physical capabilities of the underlying technology, e.g.,
116 by the use of time-shared resources (bandwidth and buffers) per
117 circuit, and/or by shaping and/or scheduling the packets at every
118 hop.
120 Key attributes of Deterministic Networking include:
122 o time synchronization on all the nodes,
124 o centralized computation of network-wide deterministic paths,
126 o multi-technology path with co-channel interference minimzation,
128 o frame preemption and guard time mechanisms to ensure a worst-case
129 delay, and
131 o new traffic shapers within and at the edge to protect the network.
133 Wireless operates on a shared medium, and transmissions cannot be
134 fully deterministic due to uncontrolled interferences, including
135 self-induced multipath fading. RAW (Reliable and Available Wireless)
136 is an effort to provide Deterministic Networking on across a path
137 that include a wireless physical layer. Making Wireless Reliable and
138 Available is even more challenging than it is with wires, due to the
139 numerous causes of loss in transmission that add up to the congestion
140 losses and the delays caused by overbooked shared resources.
142 The wireless and wired media are fundamentally different at the
143 physical level, and while the generic Problem Statement [RFC8557] for
144 DetNet applies to the wired as well as the wireless medium, the
145 methods to achieve RAW necessarily differ from those used to support
146 Time-Sensitive Networking over wires.
148 So far, Open Standards for Deterministic Networking have prevalently
149 been focused on wired media, with Audio/Video Bridging (AVB) and Time
150 Sensitive Networking (TSN) at the IEEE and DetNet [RFC8655] at the
151 IETF. But wires cannot be used in a number of cases, including
152 mobile or rotating devices, rehabilitated industrial buildings,
153 wearable or in-body sensory devices, vehicle automation and
154 multiplayer gaming.
156 Purpose-built wireless technologies such as [ISA100], which
157 incorporates IPv6, were developped and deployed to cope for the lack
158 of open standards, but they yield a high cost in OPEX and CAPEX and
159 are limited to very few industries, e.g., process control, concert
160 instruments or racing.
162 This is now changing [I-D.thubert-raw-technologies]:
164 o IMT-2020 has recognized Ultra-Reliable Low-Latency Communication
165 (URLLC) as a key functionality for the upcoming 5G.
167 o IEEE 802.11 has identified a set of real-applications
168 [ieee80211-rt-tig] which may use the IEEE802.11 standards. They
169 typically emphasize strict end-to-end delay requirements.
171 o The IETF has produced an IPv6 stack for IEEE Std. 802.15.4
172 TimeSlotted Channel Hopping (TSCH) and an architecture
173 [I-D.ietf-6tisch-architecture] that enables Reliable and Available
174 Wireless (RAW) on a shared MAC.
176 This draft extends the "Deterministic Networking Use Cases" document
177 [RFC8578] and describes a number of additional use cases which
178 require "reliable/predictable and available" flows over wireless
179 links and possibly complex multi-hop paths called Tracks. This is
180 covered mainly by the "Wireless for Industrial Applications" use
181 case, as the "Cellular Radio" is mostly dedicated to the (wired)
182 transport part of a Radio Access Network (RAN). Whereas the
183 "Wireless for Industrial Applications" use case certainly covers an
184 area of interest for RAW, it is limited to 6TiSCH, and thus its scope
185 is narrower than the use cases described next in this document.
187 2. Amusement Parks
188 2.1. Use Case Description
190 The digitalization of Amusement Parks is expected to decrease
191 significantly the cost for maintaining the attractions. By
192 monitoring in real-time the machines, predictive maintenance will
193 help to reduce the repairing cost as well as the downtime. Besides,
194 the attractions may use wireless transmissions to interconnect
195 sensors and actuators, to privilege reconfigurability, and
196 standardization.
198 Attractions may rely on a large set of sensors and actuators, which
199 react in real time. Typical applications comprise:
201 o Emergency: safety has to be preserved, and must stop the
202 attraction when a failure is detected.
204 o Video: augmented and virtual realities are integrated in the
205 attraction. Wearable devices (e.g., glasses, virtual reality
206 headset) need to offload one part of the processing tasks.
208 o Real-time interactions: visitors may interact with an attraction,
209 like in a real-time video game. The visitors may virtually
210 interact with their environment, triggering actions in the real
211 world (through actuators) [robots].
213 o Geolocation: visitors are tracked with a personal wireless tag so
214 that their user experience is improved.
216 o Predictive maintenance: statistics are collected to predict the
217 future failures, or to compute later more complex statistics about
218 the attraction's usage, the downtime, its popularity, etc.
220 2.2. Specifics
222 Amusement parks comprise a variable number of attractions, mostly
223 outdoor, over a large geographical area. The IT infrastructure is
224 typically multi-scale:
226 o Local area: the sensors and actuators controlling the attractions
227 are co-located. Control loops trigger only local traffic, with a
228 small end-to-end delay, typically inferior than 10 milliseconds,
229 like classical industrial systems [ieee80211-rt-tig].
231 o Wearable devices are free to move in the park. They exchange
232 traffic locally (identification, personalization, multimedia) or
233 globally (billing, child tracking).
235 o Computationally intensive applications offload some tasks to a
236 cloud, and data analytics rely on a centralized infrastructure
237 (predictive maintenance, marketing).
239 2.3. The Need for Wireless
241 Amusement parks cover large areas and a global interconnection would
242 require a huge length of cables. Wireless also increases the
243 reconfigurability, enabling to update cheaply the attractions. The
244 frequent renewal helps to increase customer loyalty.
246 Some parts of the attraction are mobile, e.g., trucks of a roller-
247 coaster, robots. Since cables are prone to frequent failures in this
248 situation, wireless transmissions are recommended.
250 Wearable devices are extensively used for a user experience
251 personalization. They typically need to support wireless
252 transmissions. Personal tags may help to reduce the operating costs
253 [disney-VIP] and to increase the number of charged services provided
254 to the audience (VIP tickets, interactivity, etc.) Some applications
255 rely on more sophisticated wearable devices such as digital glasses
256 or Virtual Reality (VR) headsets for an immersive experience.
258 2.4. Requirements for RAW
260 The network infrastructure has to support heterogeneous traffic, with
261 very different critical requirements. Thus, flow isolation has to be
262 provided.
264 We have to schedule appropriately the transmissions, even in presence
265 of mobile devices. While the [I-D.ietf-6tisch-architecture] already
266 proposes an architecture for synchronized, IEEE Std. 802.15.4 Time-
267 Slotted Channel Hopping (TSCH) networks, 6TiSCH does not address
268 real-time IPv6 flows. RAW might provide mechanisms helping to
269 automatically adapt the network (i.e., schedule appropriately the
270 transmissions, across heterogeneous technologies, with strict SLA
271 requirements).
273 Nowadays, long-range wireless transmissions are used for best-effort
274 traffic, and [IEEE802.1TSN] is used for critical flows using Ethernet
275 devices. However, we need an IP enabled technology to interconnect
276 large areas, independent of the PHY and MAC layer to maximize the
277 compliancy.
279 We expect to deploy several different technologies (long vs. short
280 range) which have to cohabit in the same area. Thus, we need to
281 schedule appropriately the transmissions to limit the co-technology
282 interference, so that an end-to-end delay across multiple
283 technologies can be guaranteed. It is needed to understand which
284 technologies RAW will cover and how they can be used cohabitating in
285 the same area.
287 3. Wireless for Industrial Applications
289 3.1. Use Case Description
291 A major use case for networking in Industrial environments is the
292 control networks where periodic control loops operate between a
293 sensor that measures a physical property such as the temperature of a
294 fluid, a Programmable Logic Controller (PLC) that decides an action
295 such as warm up the mix, and an actuator that performs the required
296 action, e.g., inject power in a resistor.
298 3.2. Specifics
300 3.2.1. Control Loops
302 Process Control designates continuous processing operations, e.g.,
303 heating Oil in a refinery or mixing drinking soda. Control loops in
304 the Process Control industry operate at a very low rate, typically 4
305 times per second. Factory Automation, on the other hand, deal with
306 discrete goods such as individual automobile parts, and requires
307 faster loops, in the order of 10ms. Motion control that monitors
308 dynamic activities may require even faster rates in the order of a
309 few ms. Finally, some industries exhibit hybrid behaviours, like
310 canned soup that will start as a process industry while mixing the
311 food and then operate as a discrete manufacturing when putting the
312 final product in cans and shipping them.
314 In all those cases, a packet must flow reliably between the sensor
315 and the PLC, be processed by the PLC, and sent to the actuator within
316 the control loop period. In some particular use cases that inherit
317 from analog operations, jitter might also alter the operation of the
318 control loop. A rare packet loss is usually admissible, but
319 typically 4 losses in a row will cause an emergency halt of the
320 production and incur a high cost for the manufacturer.
322 3.2.2. Unmeasured Data
324 A secondary use case deals with monitoring and diagnostics. This so-
325 called unmeasured data is essential to improve the performances of a
326 production line, e.g., by optimizing real-time processing or
327 maintenance windows using Machine Learning predictions. For the lack
328 of wireless technologies, some specific industries such as Oil and
329 Gas have been using serial cables, literally by the millions, to
330 perform their process optimization over the previous decades. But
331 few industries would afford the associated cost and the Holy Grail of
332 the Industrial Internet of Things is to provide the same benefits to
333 all industries, including SmartGrid, Transportation, Building,
334 Commercial and Medical. This requires a cheap, available and
335 scalable IP-based access technology.
337 Inside the factory, wires may already be available to operate the
338 Control Network. But unmeasured data are not welcome in that network
339 for a number of reasons. On the one hand it is rich and
340 asynchronous, meaning that using they may influence the deterministic
341 nature of the control operations and impact the production. On the
342 other hand, this information must be reported to the carpeted floor
343 over IP, which means the potential for a security breach via the
344 interconnection of the Operational Technology (OT) network with the
345 Internet technology (IT) network and possibly enable a rogue access.
347 3.3. The Need for Wireless
349 Ethernet cables used on a robot arm are prone to breakage after a few
350 thousands flexions, a lot faster than a power cable that is wider inn
351 diameter, and more resilient. In general, wired networking and
352 mobile parts are not a good match, mostly in the case of fast and
353 recurrent activities, as well as rotation.
355 When refurbishing older premises that were built before the Internet
356 age, power is usually available everywhere, but data is not. It is
357 often impractical, time consuming and expensive to deploy an Ethernet
358 fabric across walls and between buildings. Deploying a wire may take
359 months and cost tens of thousands of US Dollars.
361 Even when wiring exists, e.g., in an existing control network,
362 asynchronous IP packets such as diagnostics may not be welcome for
363 operational and security reasons (see Section 3.2.1). An alternate
364 network that can scale with the many sensors and actuators that equip
365 every robot, every valve and fan that are deployed on the factory
366 floor and may help detect and prevent a failure that could impact the
367 production. IEEE Std. 802.15.4 Time-Slotted Channel Hopping (TSCH)
368 [RFC7554] is a promising technology for that purpose, mostly if the
369 scheduled operations enable to use the same network by asynchronous
370 and deterministic flows in parallel.
372 3.4. Requirements for RAW
374 As stated by the "Deterministic Networking Problem Statement"
375 [RFC8557], a Deterministic Network is backwards compatible with
376 (capable of transporting) statistically multiplexed traffic while
377 preserving the properties of the accepted deterministic flows. While
378 the [I-D.ietf-6tisch-architecture] serves that requirement, the work
379 at 6TiSCH was focused on best-effort IPv6 packet flows. RAW should
380 be able to lock so-called hard cells for use by a centralized
381 scheduler, and program so-called end-to-end Tracks over those cells.
383 Over the course of the recent years, major Industrial Protocols,
384 e.g., [ODVA] with EtherNet/IP [EIP] and [Profinet], have been
385 migrating towards Ethernet and IP. In order to unleash the full
386 power of the IP hourglass model, it should be possible to deploy any
387 application over any network that has the physical capacity to
388 transport the industrial flow, regardless of the MAC/PHY technology,
389 wired or wireless, and across technologies. RAW mechanisms should be
390 able to setup a Track over a wireless access segment such as TSCH and
391 a backbone segment such as Ethernet or WI-Fi, to report a sensor data
392 or a critical monitoring within a bounded latency.
394 4. Pro Audio and Video
396 4.1. Use Case Description
398 Many devices support audio and video streaming by employing 802.11
399 wireless LAN. Some of these applications require low latency
400 capability. For instance, when the application provides interactive
401 play, or when the audio takes plays in real time (i.e. live) for
402 public addresses in train stations or in theme parks.
404 The professional audio and video industry ("ProAV") includes:
406 o Virtual Reality / Augmented Reality (VR/AR)
408 o Public address, media and emergency systems at large venues
409 (airports, train stations, stadiums, theme parks).
411 4.2. Specifics
413 4.2.1. Uninterrupted Stream Playback
415 Considering the uninterrupted audio or video stream, a potential
416 packet losses during the transmission of audio or video flows cannot
417 be tackled by re-trying the transmission, as it is done with file
418 transfer, because by the time the packet lost has been identified it
419 is too late to proceed with packet re-transmission. Buffering might
420 be employed to provide a certain delay which will allow for one or
421 more re-transmissions, however such approach is not efficient in
422 application where delays are not acceptable.
424 4.2.2. Synchronized Stream Playback
426 In the context of ProAV, latency is the time between the transmitted
427 signal over a stream and its reception. Thus, for sound to remain
428 synchronized to the movement in the video, the latency of both the
429 audio and video streams must be bounded and consistent.
431 4.3. The Need for Wireless
433 The devices need the wireless communication to support video
434 streaming via 802.11 wireless LAN for instance.
436 During the public address, the deployed announcement speakers, for
437 instance along the platforms of the train stations, need the wireless
438 communication to forward the audio traffic in real time.
440 4.4. Requirements for RAW
442 The network infrastructure needs to support heterogeneous types of
443 traffic (including QoS).
445 Content delivery with bounded (lowest possible) latency.
447 The deployed network topology should allow for multipath. This will
448 enable for multiple streams to have different (and multiple) paths
449 through the network to support redundancy.
451 5. Wireless Gaming
453 5.1. Use Case Description
455 The gaming industry includes [IEEE80211RTA] real-time mobile gaming,
456 wireless console gaming and cloud gaming. For RAW, wireless console
457 gaming is the most relevant one. We next summarize the three:
459 o Real-time Mobile Gaming: Different from traditional games, real
460 time mobile gaming is very sensitive to network latency and
461 stability. The mobile game can connect multiple players together
462 in a single game session and exchange data messages between game
463 server and connected players. Real-time means the feedback should
464 present on screen as users operate in game. For good game
465 experience, the end to end latency plus game servers processing
466 time should not be noticed by users as they play the game.
468 o Wireless Console Gaming: Playing online on a console has 2 types
469 of internet connectivity, which is either wired or Wi-Fi. Most of
470 the gaming consoles today support Wi-Fi 5. But Wi-Fi has an
471 especially bad reputation among the gaming community. The main
472 reasons are high latency, lag spikes and jitter.
474 o Cloud Gaming: The cloud gaming requires low latency capability as
475 the user commands in a game session need to be sent back to the
476 cloud server, the cloud server would update game context depending
477 on the received commands, and the cloud server would render the
478 picture/video to be displayed at user devices and stream the
479 picture/video content to the user devices. User devices might
480 very likely be connected wirelessly.
482 5.2. Specifics
484 While a lot of details can be found on [IEEE80211RTA], we next
485 summarize the main requirements in terms of latency, jitter and
486 packet loss:
488 o Intra BSS latency: less than 5 ms.
490 o Jitter variance: less than 2 ms.
492 o Packet loss: less than 0.1 percent.
494 5.3. The Need for Wireless
496 It is clear that gaming is evolving towards wireless, as players
497 demand being able to play anywhere. Besides, the industry is
498 changing towards playing from mobile phones, which are inherently
499 connected via wireless technologies.
501 5.4. Requirements for RAW
503 o Time sensitive networking extensions. Extensions, such as time-
504 aware shaping and redundancy (FRE) can be explored to address
505 congestion and reliability problems present in wireless networks.
507 o Priority tagging (Stream identification). One basic requirement
508 to provide better QoS for time-sensitive traffic is the capability
509 to identify and differentiate time-sensitive packets from other
510 (e.g. best-effort) traffic.
512 o Time-aware shaping. This capability (defined in IEEE 802.1Qbv)
513 consists of gates to control the opening/closing of queues that
514 share a common egress port within an Ethernet switch. A scheduler
515 defines the times when each queue opens or close, therefore
516 eliminating congestion and ensuring that frames are delivered
517 within the expected latency bounds.
519 o Dual/multiple link. Due to the competitions and interference are
520 common and hardly in control under wireless network, in order to
521 improve the latency stability, dual/multiple link proposal is
522 brought up to address this issue. Two modes are defined:
523 duplicate and joint.
525 o Admission Control. Congestion is a major cause of high/variable
526 latency and it is well known that if the traffic load exceeds the
527 capability of the link, QoS will be degraded. QoS degradation
528 maybe acceptable for many applications today, however emerging
529 time-sensitive applications are highly susceptible to increased
530 latency and jitter. In order to better control QoS, it is
531 important to control access to the network resources.
533 6. UAV platooning and control
535 6.1. Use Case Description
537 Unmanned Aerial Vehicles (UAVs) are becoming very popular for many
538 different applications, including military and civil use cases. The
539 term drone is commonly used to refer to a UAV.
541 UAVs can be used to perform aerial surveillance activities, traffic
542 monitoring (e.g., Spanish traffic control has recently introduced a
543 fleet of drones for quicker reactions upon traffic congestion related
544 events), support of emergency situations, and even transportation of
545 small goods.
547 UAVs typically have various forms of wireless connectivity:
549 o cellular: for communication with the control center, for remote
550 manuevering as well as monitoring of the drone;
552 o IEEE 802.11: for inter-drone communications (e.g., platooning) and
553 providing connectivity to other devices (e.g., acting as Access
554 Point).
556 6.2. Specifics
558 Some of the use cases/tasks involving drones require coordination
559 among drones. Others involve complex compute tasks that might not be
560 performed using the limited computing resources that a drone
561 typically has. These two aspects require continuous connectivity
562 with the control center and among drones.
564 Remote maneuvering of a drone might be performed over a cellular
565 network in some cased, however, there are situations that need very
566 low latencies and deterministic behavior of the connectivity.
568 Examples involve platooning of drones or share of computing resources
569 among drones (e.g., a drone offload some function to a neighboring
570 drone).
572 6.3. The Need for Wireless
574 UAVs cannot be connected through any type of wired media, so it is
575 obvious that wireless is needed.
577 6.4. Requirements for RAW
579 The network infrastructure is actually composed by the UAVs
580 themselves, requiring self-configuration capabilities.
582 Heterogeneous types of traffic need to be supported, from extremely
583 critical ones requiring ultra low latency and high resiliency, to
584 traffic requiring low-medium latency.
586 When a given service is decomposed into functions -- hosted at
587 different drones -- chained, each link connecting two given functions
588 would have a well-defined set of requirements (latency, bandwith and
589 jitter) that have to be met.
591 7. Edge Robotics control
593 7.1. Use Case Description
595 The Edge Robotics scenario consists of several robots, deployed in a
596 given area (for example a shopping mall), inter-connected via an
597 access network to a network's edge device or a data center. The
598 robots are connected to the edge so complex computational activities
599 are not executed locally at the robots, but offloaded to the edge.
600 This brings additional flexibility in the type of tasks that the
601 robots do, as well as reducing the costs of robot manufacturing (due
602 to their lower complexity), and enabling complex tasks involving
603 coordination among robots (that can be more easily performed if
604 robots are centrally controlled).
606 A simple example of the use of multiples robots is cleaning,
607 delivering of goods from warehouses to shops or video surveillance.
608 Multiple robots are simultaneously instructed to perform individual
609 tasks by moving the robotic intelligence from the robots to the
610 network's edge (e.g., data center). That enables easy
611 synchronization, scalable solution and on-demand option to create
612 flexible fleet of robots.
614 Robots would have various forms of wireless connectivity:
616 o IEEE 802.11: for connection to the edge and also inter-robot
617 communications (e.g., for coordinated actions).
619 o Cellular: as an additional communication link to the edge, though
620 primarily as backup, since ultra low latencies are needed.
622 7.2. Specifics
624 Some of the use cases/tasks involving robots might benefit from
625 decomposition of a service in small functions that are distributed
626 and chained among robots and the edge. These require continuous
627 connectivity with the control center and among drones.
629 Robot control is an activity requiring very low latencies between the
630 robot and the location where the control intelligence resides (which
631 might be the edge or another robot).
633 7.3. The Need for Wireless
635 Deploying robots in scenarios such as shopping malls for the
636 aforementioned applications cannot be done via wired connectivity.
638 7.4. Requirements for RAW
640 The network infrastructure needs to support heterogeneous types of
641 traffic, from robot control to video streaming.
643 When a given service is decomposed into functions -- hosted at
644 different robots -- chained, each link connecting two given functions
645 would have a well-defined set of requirements (latency, bandwidth and
646 jitter) that have to be met.
648 8. IANA Considerations
650 N/A.
652 9. Security Considerations
654 N/A.
656 10. Informative References
658 [disney-VIP]
659 Wired, "Disney's $1 Billion Bet on a Magical Wristband",
660 March 2015,
661 .
663 [EIP] http://www.odva.org/, "EtherNet/IP provides users with the
664 network tools to deploy standard Ethernet technology (IEEE
665 802.3 combined with the TCP/IP Suite) for industrial
666 automation applications while enabling Internet and
667 enterprise connectivity data anytime, anywhere.",
668 .
672 [I-D.ietf-6tisch-architecture]
673 Thubert, P., "An Architecture for IPv6 over the TSCH mode
674 of IEEE 802.15.4", draft-ietf-6tisch-architecture-28 (work
675 in progress), October 2019.
677 [I-D.thubert-raw-technologies]
678 Thubert, P., Cavalcanti, D., Vilajosana, X., and C.
679 Schmitt, "Reliable and Available Wireless Technologies",
680 draft-thubert-raw-technologies-03 (work in progress), July
681 2019.
683 [IEEE802.1TSN]
684 IEEE standard for Information Technology, "IEEE
685 802.1AS-2011 - IEEE Standard for Local and Metropolitan
686 Area Networks - Timing and Synchronization for Time-
687 Sensitive Applications in Bridged Local Area Networks".
689 [ieee80211-rt-tig]
690 IEEE, "IEEE 802.11 Real Time Applications TIG Report",
691 Nov. 2018,
692 .
694 [IEEE80211RTA]
695 IEEE standard for Information Technology, "IEEE 802.11
696 Real Time Applications TIG Report", Nov 2018.
698 [ISA100] ISA/ANSI, "ISA100, Wireless Systems for Automation",
699 .
701 [ODVA] http://www.odva.org/, "The organization that supports
702 network technologies built on the Common Industrial
703 Protocol (CIP) including EtherNet/IP.".
705 [Profinet]
706 http://us.profinet.com/technology/profinet/, "PROFINET is
707 a standard for industrial networking in automation.",
708 .
710 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
711 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
712 Internet of Things (IoT): Problem Statement", RFC 7554,
713 DOI 10.17487/RFC7554, May 2015,
714 .
716 [RFC8557] Finn, N. and P. Thubert, "Deterministic Networking Problem
717 Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019,
718 .
720 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases",
721 RFC 8578, DOI 10.17487/RFC8578, May 2019,
722 .
724 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
725 "Deterministic Networking Architecture", RFC 8655,
726 DOI 10.17487/RFC8655, October 2019,
727 .
729 [robots] Kober, J., Glisson, M., and M. Mistry, "Playing catch and
730 juggling with a humanoid robot.", 2012,
731 .
733 Authors' Addresses
735 Georgios Z. Papadopoulos
736 IMT Atlantique
737 Office B00 - 114A
738 2 Rue de la Chataigneraie
739 Cesson-Sevigne - Rennes 35510
740 FRANCE
742 Phone: +33 299 12 70 04
743 Email: georgios.papadopoulos@imt-atlantique.fr
745 Pascal Thubert
746 Cisco Systems, Inc
747 Building D
748 45 Allee des Ormes - BP1200
749 MOUGINS - Sophia Antipolis 06254
750 FRANCE
752 Phone: +33 497 23 26 34
753 Email: pthubert@cisco.com
754 Fabrice Theoleyre
755 CNRS
756 ICube Lab, Pole API
757 300 boulevard Sebastien Brant - CS 10413
758 Illkirch 67400
759 FRANCE
761 Phone: +33 368 85 45 33
762 Email: theoleyre@unistra.fr
763 URI: http://www.theoleyre.eu
765 Carlos J. Bernardos
766 Universidad Carlos III de Madrid
767 Av. Universidad, 30
768 Leganes, Madrid 28911
769 Spain
771 Phone: +34 91624 6236
772 Email: cjbc@it.uc3m.es
773 URI: http://www.it.uc3m.es/cjbc/