idnits 2.17.1 draft-bernardos-raw-use-cases-00.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 (July 5, 2019) is 1750 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-24 Summary: 0 errors (**), 0 flaws (~~), 2 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: January 6, 2020 Cisco 6 F. Theoleyre 7 CNRS 8 CJ. Bernardos 9 UC3M 10 July 5, 2019 12 RAW use cases 13 draft-bernardos-raw-use-cases-00 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 deterministic wireless use cases, in continuation to the 22 DetNet Use Cases document. 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 January 6, 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 . . . . . . . . . . . . . . . . . . 4 61 2.2. Specificities . . . . . . . . . . . . . . . . . . . . . . 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. Specificities . . . . . . . . . . . . . . . . . . . . . . 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. Specificities . . . . . . . . . . . . . . . . . . . . . . 9 74 4.2.1. Uninterrupted Stream Playback . . . . . . . . . . . . 9 75 4.2.2. Synchronized Stream Playback . . . . . . . . . . . . 9 76 4.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 10 77 4.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 10 78 5. Gaming . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 5.1. Use Case Description . . . . . . . . . . . . . . . . . . 10 80 5.2. Specificities . . . . . . . . . . . . . . . . . . . . . . 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. Specificities . . . . . . . . . . . . . . . . . . . . . . 12 86 6.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 12 87 6.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 13 88 7. Edge Robotics control . . . . . . . . . . . . . . . . . . . . 13 89 7.1. Use Case Description . . . . . . . . . . . . . . . . . . 13 90 7.2. Specificities . . . . . . . . . . . . . . . . . . . . . . 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. Scheduling transmissions enables to 136 alleviate those effects by leveraging diversity in the spatial, time 137 and frequency domains, enabling Reliable and Available Wireless 138 (RAW). 140 The wireless and wired media are fundamentally different at the 141 physical level, and while the generic Problem Statement [RFC8557] for 142 DetNet applies to the wired as well as the wireless medium, the 143 methods to achieve RAW necessarily differ from those used to support 144 Time-Sensitive Networking over wires. 146 So far, Open Standards for Deterministic Networking have prevalently 147 been focused on wired media, with Audio/Video Bridging (AVB) and Time 148 Sensitive Networking (TSN) at the IEEE and DetNet 149 [I-D.ietf-detnet-architecture] at the IETF. But wires cannot be used 150 in a number of cases, including mobile or rotating devices, 151 rehabilitated industrial buildings, wearable or in-body sensory 152 devices, vehicle automation and multiplayer gaming. 154 Purpose-built wireless technologies such as [ISA100], which 155 incorporates IPv6, were developped and deployed to cope for the lack 156 of open standards, but they yield a high cost in OPEX and CAPEX and 157 are limited to very few industries, e.g., process control, concert 158 instruments or racing. 160 This is now changing: 162 o IMT-2020 has recognized Ultra-Reliable Low-Latency Communication 163 (URLLC) as a key functionality for the upcoming 5G, 165 o IEEE 802.11 has identified a set of real-applications 166 [ieee80211-rt-tig] which may use the IEEE802.11 standards. They 167 typically emphasize strict end-to-end delay requirements. 169 o the IETF has produced an IPv6 stack for IEEE Std. 802.15.4 170 TimeSlotted Channel Hopping (TSCH) and an architecture 171 [I-D.ietf-6tisch-architecture] that enables Reliable and Available 172 Wireless (RAW) on a shared MAC. 174 This draft extends the "Deterministic Networking Use Cases" [RFC8578] 175 and describes a number of additional use cases which require 176 deterministic flows over wireless links and possibly complex multi- 177 hop paths called Tracks. This is covered mainly by the "Wireless for 178 Industrial Applications" use case, as the "Cellular Radio" is mostly 179 dedicated to the (wired) transport part of a Radio Access Network 180 (RAN). Whereas the "Wireless for Industrial Applications" use case 181 certainly covers an area of interest for RAW, it is limited to 182 6TiSCH, and thus its scope is narrower than the use cases described 183 next in this document. 185 2. Amusement Parks 187 2.1. Use Case Description 189 The digitalization of Amusement Parks is expected to decrease 190 significantly the cost for maintaining the attractions. By 191 monitoring in real-time the machines, predictive maintenance will 192 help to reduce the repairing cost as well as the downtime. Besides, 193 the attractions may use wireless transmissions to interconnect 194 sensors and actuators, to privilege reconfigurability, and 195 standardization. 197 Attractions may rely on a large set of sensors and actuators, which 198 react in real time. Typical applications comprise: 200 o emergency: safety has to be preserved, and must stop the 201 attraction when a failure is detected; 203 o video: augmented and virtual realities are integrated in the 204 attraction. Wearable devices (e.g. glasses, virtual reality 205 headset) need to offload one part of the processing tasks. 207 o real-time interactions: visitors may interact with an attraction, 208 like in a real-time video game. The vistors may virtually 209 interact with their environment, triggering actions in the real 210 world (through actuators) [robots] 212 o geolocation: vistors are tracked with a personal wireless tag so 213 that their user experience is improved. 215 o predictive maintenance: statistics are collected to predict the 216 future failures, or to compute later more complex statistics about 217 the attraction's usage, the downtime, its popularity, etc. 219 2.2. Specificities 221 Amusement parks comprise a variable number of attractions, mostly 222 outdoor, over a large geographical area. The IT infrastructure is 223 typically multi-scale: 225 o local area: the sensors and actuators controling the attractions 226 are co-located. Control loops trigger only local traffic, with a 227 small end-to-end delay, typically inferior than 10 milliseconds, 228 like classical industrial systems [ieee80211-rt-tig] 230 o wearable devices are free to move in the park. They exchange 231 traffic locally (identification, personalization, multimedia) or 232 globally (billing, child tracking); 234 o computationally intensive applications offload some tasks to a 235 cloud, and data analytics rely on a centralized infrastructure 236 (predictive maintenance, marketing). 238 2.3. The Need for Wireless 240 Amusement parks cover large areas and a global interconnection would 241 require a huge length of cables. Wireless also increases the 242 reconfigurability, enabling to update cheaply the attractions. The 243 frequent renewal helps to increase customer loyalty. 245 Some parts of the attraction are mobile, e.g. trucks of a 246 rollercoaster, robots. Since cables are prone to frequent failures 247 in this situation, wireless transmissions are recommended. 249 Wearable devices are extensively used for a user experience 250 personalisation. They typically need to support wireless 251 transmissions. Personal tags may help to reduce the operating costs 252 [disney-VIP] and to increase the number of charged services provided 253 to the audience (VIP tickets, interactivity, etc.) Some applications 254 rely on more sophisticated wearable devices such as digital glasses 255 or VR headests for an immersive experience. 257 2.4. Requirements for RAW 259 The network infrastructure has to support heterogenous traffic, with 260 very different criticalities. Thus, flow isolation has to be 261 provided. 263 We have to schedule appropriately the transmissions, even in presence 264 of mobile devices. While the [I-D.ietf-6tisch-architecture] already 265 proposes an architecture for synchronized, IEEE Std. 802.15.4 Time- 266 Slotted Channel Hopping (TSCH) networks, 6TiSCH doesn't address real- 267 time IPv6 flows. RAW might provide mechanisms helping to 268 automatically adapt the network (i.e., schedule appropriately the 269 transmissions, accross hetereogeneous technologies, with strict SLA 270 requirements). 272 Nowadays, long-range wireless transmissions are used for best-effort 273 traffic, and [IEEE802.1TSN] is used for critical flows using Ethernet 274 devices. However, we need an IP enabled technology to interconnect 275 large areas, independent of the PHY and MAC layer to maximize the 276 compliancy. 278 We expect to deploy several different technologies (long vs. short 279 range) which have to cohabit in the same area. Thus, we need to 280 schedule appropriately the transmissions to limit the co-technology 281 interference, so that an end-to-end delay accross multiple 282 technologies can be guaranteed. It is needed to understand which 283 technologies RAW will cover and how they can be used cohabitating in 284 the same area. 286 3. Wireless for Industrial Applications 288 3.1. Use Case Description 290 A major use case for networking in Industrial is the control networks 291 where periodic control loops operate between a sensor that measures a 292 physical property such as the temperature of a fluid, a Programmable 293 Logic Controller that decides an action such as warm up the mix, and 294 an actuator that performs the required action, e.g., inject power in 295 a resistor. 297 3.2. Specificities 299 3.2.1. Control Loops 301 Process Control designates continous processing operations, e.g., 302 heating Oil in a refinery or mixing drinking soda. Control loops in 303 the Process Control industry operate at a very low rate, typically 4 304 times per second. Factory Automation, on the other hand, deal with 305 discrete goods such as individual automobile parts, and requires 306 faster loops, in the order of 10ms. Motion control that monitors 307 dynamic activities may require even faster rates in the order of a 308 few ms. Finally, some industries exhibit hybrid behaviours, like 309 canned soup that will start as a process industry while mixing the 310 food and then operate as a discrete manufacturing when putting the 311 final product in cans and shipping them. 313 In all those cases, a packet must flow deterministically between the 314 sensor and the PLC, be processed by the PLC, and sent to the actuator 315 within the control loop period. In some particular use cases that 316 inherit from analog operations, jitter might also alter the operation 317 of the control loop. A rare packet loss is usually admissible, but 318 typically 4 losses in a row will cause an emergency halt of the 319 production and incur a high cost for the manufacturer. 321 3.2.2. Unmeasured Data 323 A secondary use case deals with monitoring and diagnostics. This so- 324 called unmeasured data is essential to improve the performances of a 325 production line, e.g., by optimizing real-time processing or 326 maintenance windows using Machine Learning predictions. For the lack 327 of wireless technologies, some specific industries such as Oil and 328 Gas have been using serial cables, literally by the millions, to 329 perform their process optimization over the previous decades. But 330 few industries would afford the associated cost and the Holy Grail of 331 the Industrial Internet of Things is to provide the same benefits to 332 all industries, including SmartGrid, Transportation, Building, 333 Commercial and Medical. This requires a cheap, available and 334 scalable IP-based access technology. 336 Inside the factory, wires may already be available to operate the 337 Control Network. But unmeasured data are not welcome in that network 338 for a number of reasons. On the one hand it is rich and 339 asynchronous, meaning that using they may influence the deterministic 340 nature of the control operations and impact the production. On the 341 other hand, this information must be reported to the carpeted floor 342 over IP, which means the potential for a security breach via the 343 interconnection of the Operational Technology (OT) network with the 344 Internet technology (IT) network and possibly enable a rogue access. 346 3.3. The Need for Wireless 348 Ethernet cables used on a robot arm are prone to breakage after a few 349 thousands flexions, a lot faster than a power cable that is wider inn 350 diameter, and more resilient. In general, wired networking and 351 mobile parts are not a good match, mostly in the case of fast and 352 recurrent activities, as well as rotation. 354 When refurbishing older premises that were built before the Internet 355 age, power is usually available everywhere, but data is not. It is 356 often impractical, time consuming and expensive to deploy an Ethernet 357 fabric across walls and between buildings. Deploying a wire may take 358 months and cost tens of thousands of US Dollars. 360 Even when wiring exists, e.g., in an existing control network, 361 asynchronous IP packets such as diagnostics may not be welcome for 362 operational and security reasons (see Section 3.2.1). An alternate 363 network that can scale with the many sensors and actuators that equip 364 every robot, every valve and fan that are deployed on the factory 365 floor and may help detect and prevent a failure that could impact the 366 production. IEEE Std. 802.15.4 Time-Slotted Channel Hopping (TSCH) 367 [RFC7554] is a promising technology for that purpose, mostly if the 368 scheduled operations enable to use the same network by asynchronous 369 and deterministic flows in parallel. 371 3.4. Requirements for RAW 373 As stated by the "Deterministic Networking Problem Statement" 374 [RFC8557], a Deterministic Network is backwards compatible with 375 (capable of transporting) statistically multiplexed traffic while 376 preserving the properties of the accepted deterministic flows. While 377 the [I-D.ietf-6tisch-architecture] serves that requirement, the work 378 at 6TiSCH was focused on best-effort IPv6 packet flows. RAW should 379 be able to lock so-called hard cells for use by a centralized 380 scheduler, and program so-called end-to-end Tracks over those cells. 382 Over the course of the recent years, major Industrial Protocols, 383 e.g., [ODVA] with EtherNet/IP [EIP] and [Profinet], have been 384 migrating towards Ethernet and IP. In order to unleash the full 385 power of the IP hourglass model, it should be possible to deploy any 386 application over any network that has the physical capacity to 387 transport the industrial flow, regardless of the MAC/PHY technology, 388 wired or wireless, and across technologies. RAW mechanisms should be 389 able to setup a Track over a wireless access segment such as TSCH and 390 a backbone segment such as Ethernet or WI-Fi, to report a sensor data 391 or a critical monitoring within a bouded latency. 393 4. Pro Audio and Video 395 4.1. Use Case Description 397 Many devices support audio and video streaming by employing 802.11 398 wireless LAN. Some of these applications require low latency 399 capability. For instance, when the application provides interactive 400 play, or when the audio takes plays in real time (i.e. live) for 401 public addresses in train stations or in theme parks. 403 The professional audio and video industry ("ProAV") includes: 405 o Virtual Reality / Augmented Reality (VR/AR) 407 o Public address, media and emergency systems at large venues 408 (airports, train stations, stadiums, theme parks). 410 4.2. Specificities 412 4.2.1. Uninterrupted Stream Playback 414 Considering the uninterrupted audio or video stream, a potential 415 packet losses during the transmission of audio or video flows cannot 416 be tackled by re-trying the transmission, as it is done with file 417 transfer, because by the time the packet lost has been identified it 418 is too late to proceed with packet re-transmission. Buffering might 419 be employed to provide a certain delay which will allow for one or 420 more re-transmissions, however such approach is not efficient in 421 application where delays are not acceptable. 423 4.2.2. Synchronized Stream Playback 425 In the context of ProAV, latency is the time between the transmitted 426 signal over a stream and its reception. Thus, for sound to remain 427 synchronized to the movement in the video, the latency of both the 428 audio and video streams must be bounded and consistent. 430 4.3. The Need for Wireless 432 The devices need the wireless communication to support video 433 streaming via 802.11 wireless LAN for instance. 435 During the public address, the deployed announcement speakers, for 436 instance along the platforms of the train stations, need the wireless 437 communication to forward the audio traffic in real time. 439 4.4. Requirements for RAW 441 The network infrastructure needs to support heterogeneous types of 442 traffic (including QoS). 444 Content delivery with bounded (lowest possible) latency. 446 The deployed network topology should allow for multipath. This will 447 enable for multiple streams to have different (and multiple) paths 448 through the network to support redundancy. 450 5. Gaming 452 5.1. Use Case Description 454 The gaming industry includes [IEEE80211RTA]: 456 o Real-time Mobile Gaming: Different from traditional games, real 457 time mobile gaming is very sensitive to network latency and 458 stability. The mobile game can connect multiple players together 459 in a single game session and exchange data messages between game 460 server and connected players. Real-time means the feedback should 461 present on screen as users operate in game. For good game 462 experience, the end to end latency plus game servers processing 463 time should not be noticed by users as they play the game. 465 o Wireless Console Gaming: Playing online on a console has 2 types 466 of internet connectivity, which is either wired or Wi-Fi. Most of 467 the gaming consoles today support Wi-Fi 5. But Wi-Fi has an 468 especially bad reputation among the gaming community. The main 469 reasons are high latency, lag spikes and jitter. 471 o Cloud Gaming: The cloud gaming requires low latency capability as 472 the user commands in a game session need to be sent back to the 473 cloud server, the cloud server would update game context depending 474 on the received commands, and the cloud server would render the 475 picture/video to be displayed at user devices and stream the 476 picture/video content to the user devices. User devices might 477 very likely be connected wirelessly. 479 5.2. Specificities 481 While a lot of details can be found on [IEEE80211RTA], we next 482 summarize the main requirements in terms of latency, jitter and 483 packet loss: 485 o Intra BSS latency: less than 5 ms. 487 o Jitter variance: less than 2 ms. 489 o Packet loss: less than 0.1 percent. 491 5.3. The Need for Wireless 493 It is clear that gaming is evolving towards wireless, as players 494 demand being able to play anywhere. Besides, the industry is 495 changing towards playing from mobile phones, which are inherently 496 connected via wireless technologies. 498 5.4. Requirements for RAW 500 o Time sensitive networking extensions. Extensions, such as time- 501 aware shaping and redundancy (FRE) can be explored to address 502 congestion and reliability problems present in wireless networks. 504 o Priority tagging (Stream identification). One basic requirement 505 to provide better QoS for time-sensitive traffic is the capability 506 to identify and differentiate time-sensitive packets from other 507 (e.g. best-effort) traffic. 509 o Time-aware shaping. This capability (defined in IEEE 802.1Qbv) 510 consists of gates to control the opening/closing of queues that 511 share a common egress port within an Ethernet switch. A scheduler 512 defines the times when each queue opens or close, therefore 513 eliminating congestion and ensuring that frames are delivered 514 within the expected latency bounds. 516 o Dual/multiple link. Due to the competitions and interference are 517 common and hardly in control under wireless network, in order to 518 improve the latency stability, dual/multiple link proposal is 519 brought up to address this issue. Two modes are defined: 520 duplicate and joint. 522 o Admission Control. Congestion is a major cause of high/variable 523 latency and it is well known that if the traffic load exceeds the 524 capability of the link, QoS will be degraded. QoS degradation 525 maybe acceptable for many applications today, however emerging 526 time-sensitive applications are highly susceptible to increased 527 latency and jitter. In order to better control QoS, it is 528 important to control access to the network resources. 530 6. UAV platooning and control 532 6.1. Use Case Description 534 Unmanned Aerial Vehicles (UAVs) are becoming very popular for many 535 different applications, including military and civil use cases. The 536 term drone is commonly used to refer to a UAV. 538 UAVs can be used to perform aerial surveillance activities, traffic 539 monitoring (e.g., Spanish traffic control has recently introduced a 540 fleet of drones for quicker reactions upon traffic congestion related 541 events), support of emergency situations, and even transportation of 542 small goods. 544 UAVs typically have various forms of wireless connectivity: 546 o cellular: for communication with the control center, for remote 547 manuevering as well as monitoring of the drone; 549 o IEEE 802.11: for inter-drone communications (e.g., platooning) and 550 providing connectivity to other devices (e.g., acting as Access 551 Point). 553 6.2. Specificities 555 Some of the use cases/tasks involving drones require coordination 556 among drones. Others involve complex compute tasks that might not be 557 performed using the limited computing resources that a drone 558 typically has. These two aspects require continuous connectivity 559 with the control center and among drones. 561 Remote manouvering of a drone might be performed over a cellular 562 network in some cased, however, there are situations that need very 563 low latencies and deterministic behaviour of the connectivity. 564 Examples involve platooning of drones or share of computing resources 565 among drones (e.g., a drone offload some function to a neighbouring 566 drone). 568 6.3. The Need for Wireless 570 UAVs cannot be connected through any type of wired media, so it is 571 obvious that wireless is needed. 573 6.4. Requirements for RAW 575 The network infrastructure is actually composed by the UAVs 576 themselves, requiring self-configuration capabilities. 578 Heterogeneous types of traffic need to be supported, from extremely 579 critical ones requiring ultra low latency and high resiliency, to 580 traffic requiring low-medium latency. 582 When a given service is decomposed into functions -- hosted at 583 different drones -- chained, each link connecting two given functions 584 would have a well-defined set of requirements (latency, bandwith and 585 jitter) that have to be met. 587 7. Edge Robotics control 589 7.1. Use Case Description 591 The Edge Robotics scenario consists of several robots, deployed in a 592 given area (for example a shopping mall), inter-connected via an 593 access network to a network's edge device or a data center. The 594 robots are connected to the edge so complex computational activities 595 are not executed locally at the robots, but offloaded to the edge. 596 This brings additional flexibility in the type of tasks that the 597 robots do, as well as reducing the costs of robot manufacturing (due 598 to their lower complexity), and enabling complex tasks involving 599 coordination among robots (that can be more easily performed if 600 robots are centrally controlled). 602 A simple example of the use of multiples robots is cleaning, 603 delivering of goods from warehouses to shops or video surveillance. 604 Multiple robots are simultaneously instructed to perform individual 605 tasks by moving the robotic intelligence from the robots to the 606 network's edge (e.g., data center). That enables easy 607 synchronization, scalable solution and on-demand option to create 608 flexible fleet of robots. 610 Robots would have various forms of wireless connectivity: 612 o IEEE 802.11: for connection to the edge and also inter-robot 613 communications (e.g., for coordinated actions); 615 o cellular: as an additional communication link to the edge, though 616 primarily as backup, since ultra low latencies are needed. 618 7.2. Specificities 620 Some of the use cases/tasks involving robots might benefit from 621 decomposition of a service in small functions that are distributed 622 and chained among robots and the edge. These require continuous 623 connectivity with the control center and among drones. 625 Robot control is an activity requiring very low latencies between the 626 robot and the location where the control intelligence resides (which 627 might be the edge or another robot). 629 7.3. The Need for Wireless 631 Deploying robots in scenarios such as shopping malls for the 632 aforementioned applications cannot be done via wired connectivity. 634 7.4. Requirements for RAW 636 The network infrastructure needs to support heterogeneous types of 637 traffic, from robot control to video streaming. 639 When a given service is decomposed into functions -- hosted at 640 different robots -- chained, each link connecting two given functions 641 would have a well-defined set of requirements (latency, bandwith and 642 jitter) that have to be met. 644 8. IANA Considerations 646 N/A. 648 9. Security Considerations 650 N/A. 652 10. Informative References 654 [disney-VIP] 655 Wired, "Disney's $1 Billion Bet on a Magical Wristband", 656 March 2015, 657 . 659 [EIP] http://www.odva.org/, "EtherNet/IP provides users with the 660 network tools to deploy standard Ethernet technology (IEEE 661 802.3 combined with the TCP/IP Suite) for industrial 662 automation applications while enabling Internet and 663 enterprise connectivity data anytime, anywhere.", 664 . 668 [I-D.ietf-6tisch-architecture] 669 Thubert, P., "An Architecture for IPv6 over the TSCH mode 670 of IEEE 802.15.4", draft-ietf-6tisch-architecture-24 (work 671 in progress), July 2019. 673 [I-D.ietf-detnet-architecture] 674 Finn, N., Thubert, P., Varga, B., and J. Farkas, 675 "Deterministic Networking Architecture", draft-ietf- 676 detnet-architecture-13 (work in progress), May 2019. 678 [IEEE802.1TSN] 679 IEEE standard for Information Technology, "IEEE 680 802.1AS-2011 - IEEE Standard for Local and Metropolitan 681 Area Networks - Timing and Synchronization for Time- 682 Sensitive Applications in Bridged Local Area Networks". 684 [ieee80211-rt-tig] 685 IEEE, "IEEE 802.11 Real Time Applications TIG Report", 686 Nov. 2018, 687 . 689 [IEEE80211RTA] 690 IEEE standard for Information Technology, "IEEE 802.11 691 Real Time Applications TIG Report", Nov 2018. 693 [ISA100] ISA/ANSI, "ISA100, Wireless Systems for Automation", 694 . 696 [ODVA] http://www.odva.org/, "The organization that supports 697 network technologies built on the Common Industrial 698 Protocol (CIP) including EtherNet/IP.". 700 [Profinet] 701 http://us.profinet.com/technology/profinet/, "PROFINET is 702 a standard for industrial networking in automation.", 703 . 705 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 706 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 707 Internet of Things (IoT): Problem Statement", RFC 7554, 708 DOI 10.17487/RFC7554, May 2015, 709 . 711 [RFC8557] Finn, N. and P. Thubert, "Deterministic Networking Problem 712 Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019, 713 . 715 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 716 RFC 8578, DOI 10.17487/RFC8578, May 2019, 717 . 719 [robots] Kober, J., Glisson, M., and M. Mistry, "Playing catch and 720 juggling with a humanoid robot.", 2012, 721 . 723 Authors' Addresses 725 Georgios Z. Papadopoulos 726 IMT Atlantique 727 Office B00 - 114A 728 2 Rue de la Chataigneraie 729 Cesson-Sevigne - Rennes 35510 730 FRANCE 732 Phone: +33 299 12 70 04 733 Email: georgios.papadopoulos@imt-atlantique.fr 735 Pascal Thubert 736 Cisco Systems, Inc 737 Building D 738 45 Allee des Ormes - BP1200 739 MOUGINS - Sophia Antipolis 06254 740 FRANCE 742 Phone: +33 497 23 26 34 743 Email: pthubert@cisco.com 744 Fabrice Theoleyre 745 CNRS 746 ICube Lab, Pole API 747 300 boulevard Sebastien Brant - CS 10413 748 Illkirch 67400 749 FRANCE 751 Phone: +33 368 85 45 33 752 Email: theoleyre@unistra.fr 753 URI: http://www.theoleyre.eu 755 Carlos J. Bernardos 756 Universidad Carlos III de Madrid 757 Av. Universidad, 30 758 Leganes, Madrid 28911 759 Spain 761 Phone: +34 91624 6236 762 Email: cjbc@it.uc3m.es 763 URI: http://www.it.uc3m.es/cjbc/