idnits 2.17.1 draft-ietf-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 (October 23, 2020) is 1274 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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-29 == Outdated reference: A later version (-16) exists of draft-ietf-detnet-security-12 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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: April 26, 2021 Cisco 6 F. Theoleyre 7 CNRS 8 CJ. Bernardos 9 UC3M 10 October 23, 2020 12 RAW use cases 13 draft-ietf-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 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 April 26, 2021. 41 Copyright Notice 43 Copyright (c) 2020 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. Aeronautical Communications . . . . . . . . . . . . . . . . . 5 60 2.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 5 61 2.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.3. Challenges . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.4. The Need for Wireless . . . . . . . . . . . . . . . . . . 7 64 2.5. Requirements for RAW . . . . . . . . . . . . . . . . . . 7 65 3. Amusement Parks . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.1. Use Case Description . . . . . . . . . . . . . . . . . . 7 67 3.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 8 68 3.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 8 69 3.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 9 70 4. Wireless for Industrial Applications . . . . . . . . . . . . 9 71 4.1. Use Case Description . . . . . . . . . . . . . . . . . . 9 72 4.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 10 73 4.2.1. Control Loops . . . . . . . . . . . . . . . . . . . . 10 74 4.2.2. Unmeasured Data . . . . . . . . . . . . . . . . . . . 10 75 4.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 11 76 4.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 11 77 5. Pro Audio and Video . . . . . . . . . . . . . . . . . . . . . 12 78 5.1. Use Case Description . . . . . . . . . . . . . . . . . . 12 79 5.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 12 80 5.2.1. Uninterrupted Stream Playback . . . . . . . . . . . . 12 81 5.2.2. Synchronized Stream Playback . . . . . . . . . . . . 12 82 5.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 12 83 5.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 13 84 6. Wireless Gaming . . . . . . . . . . . . . . . . . . . . . . . 13 85 6.1. Use Case Description . . . . . . . . . . . . . . . . . . 13 86 6.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 14 87 6.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 14 88 6.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 14 89 7. UAV platooning and control . . . . . . . . . . . . . . . . . 15 90 7.1. Use Case Description . . . . . . . . . . . . . . . . . . 15 91 7.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 15 92 7.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 15 93 7.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 16 94 8. Edge Robotics control . . . . . . . . . . . . . . . . . . . . 16 95 8.1. Use Case Description . . . . . . . . . . . . . . . . . . 16 96 8.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 17 97 8.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 17 98 8.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 17 99 9. Emergencies: Instrumented emergency vehicle . . . . . . . . . 17 100 9.1. Use Case Description . . . . . . . . . . . . . . . . . . 17 101 9.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 18 102 9.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 18 103 9.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 18 104 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 105 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 106 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 107 13. Informative References . . . . . . . . . . . . . . . . . . . 19 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 110 1. Introduction 112 Based on time, resource reservation, and policy enforcement by 113 distributed shapers, Deterministic Networking provides the capability 114 to carry specified unicast or multicast data streams for real-time 115 applications with extremely low data loss rates and bounded latency, 116 so as to support time-sensitive and mission-critical applications on 117 a converged enterprise infrastructure. 119 Deterministic Networking in the IP world is an attempt to eliminate 120 packet loss for a committed bandwidth while ensuring a worst case 121 end-to-end latency, regardless of the network conditions and across 122 technologies. It can be seen as a set of new Quality of Service 123 (QoS) guarantees of worst-case delivery. IP networks become more 124 deterministic when the effects of statistical multiplexing (jitter 125 and collision loss) are mostly eliminated. This requires a tight 126 control of the physical resources to maintain the amount of traffic 127 within the physical capabilities of the underlying technology, e.g., 128 by the use of time-shared resources (bandwidth and buffers) per 129 circuit, and/or by shaping and/or scheduling the packets at every 130 hop. 132 Key attributes of Deterministic Networking include: 134 o time synchronization on all the nodes, 136 o centralized computation of network-wide deterministic paths, 138 o multi-technology path with co-channel interference minimization, 140 o frame preemption and guard time mechanisms to ensure a worst-case 141 delay, and 143 o new traffic shapers within and at the edge to protect the network. 145 Wireless operates on a shared medium, and transmissions cannot be 146 fully deterministic due to uncontrolled interferences, including 147 self-induced multipath fading. RAW (Reliable and Available Wireless) 148 is an effort to provide Deterministic Networking Mechanisms on across 149 a path that include a wireless physical layer. Making Wireless 150 Reliable and Available is even more challenging than it is with 151 wires, due to the numerous causes of loss in transmission that add up 152 to the congestion losses and the delays caused by overbooked shared 153 resources. 155 The wireless and wired media are fundamentally different at the 156 physical level, and while the generic Problem Statement [RFC8557] for 157 DetNet applies to the wired as well as the wireless medium, the 158 methods to achieve RAW necessarily differ from those used to support 159 Time-Sensitive Networking over wires. 161 So far, Open Standards for Deterministic Networking have prevalently 162 been focused on wired media, with Audio/Video Bridging (AVB) and Time 163 Sensitive Networking (TSN) at the IEEE and DetNet [RFC8655] at the 164 IETF. But wires cannot be used in a number of cases, including 165 mobile or rotating devices, rehabilitated industrial buildings, 166 wearable or in-body sensory devices, vehicle automation and 167 multiplayer gaming. 169 Purpose-built wireless technologies such as [ISA100], which 170 incorporates IPv6, were developped and deployed to cope for the lack 171 of open standards, but they yield a high cost in OPEX and CAPEX and 172 are limited to very few industries, e.g., process control, concert 173 instruments or racing. 175 This is now changing [I-D.thubert-raw-technologies]: 177 o IMT-2020 has recognized Ultra-Reliable Low-Latency Communication 178 (URLLC) as a key functionality for the upcoming 5G. 180 o IEEE 802.11 has identified a set of real-applications 181 [ieee80211-rt-tig] which may use the IEEE802.11 standards. They 182 typically emphasize strict end-to-end delay requirements. 184 o The IETF has produced an IPv6 stack for IEEE Std. 802.15.4 185 TimeSlotted Channel Hopping (TSCH) and an architecture 186 [I-D.ietf-6tisch-architecture] that enables Reliable and Available 187 Wireless (RAW) on a shared MAC. 189 This draft extends the "Deterministic Networking Use Cases" document 190 [RFC8578] and describes a number of additional use cases which 191 require "reliable/predictable and available" flows over wireless 192 links and possibly complex multi-hop paths called Tracks. This is 193 covered mainly by the "Wireless for Industrial Applications" use 194 case, as the "Cellular Radio" is mostly dedicated to the (wired) 195 transport part of a Radio Access Network (RAN). Whereas the 196 "Wireless for Industrial Applications" use case certainly covers an 197 area of interest for RAW, it is limited to 6TiSCH, and thus its scope 198 is narrower than the use cases described next in this document. 200 2. Aeronautical Communications 202 Aircraft are currently connected to ATC (Air-Traffic Control) and AOC 203 (Airline Operational Control) via voice and data communications 204 systems through all phases of a flight. Within the airport terminal, 205 connectivity is focused on high bandwidth communications while during 206 en-route high reliability, robustness and range is the main focus. 208 2.1. Problem Statement 210 Worldwide civil air traffic is expected to grow by 84% until 2040 211 compared to 2017 [EURO20]. Thus, legacy systems in air traffic 212 management (ATM) are likely to reach their capacity limits and the 213 need for new aeronautical communication technologies becomes 214 apparent. Especially problematic is the saturation of VHF band in 215 high density areas in Europe, the US, and Asia [KEAV20] [FAA20] 216 calling for suitable new digital approaches such as AeroMACS for 217 airport communications, SatCOM for remote domains, and LDACS as long- 218 range terrestrial aeronautical communications system. Making the 219 frequency spectrum's usage more efficient a transition from analogue 220 voice to digital data communication [PLA14] is necessary to cope with 221 the expected growth of civil aviation and its supporting 222 infrastructure. A promising candidate for long range terrestrial 223 communications, already in the process of being standardized in the 224 International Civil Aviation Organization (ICAO), is the L-band 225 Digital Aeronautical Communications System (LDACS) [ICAO18] 226 [I-D.maeurer-raw-ldacs]. 228 2.2. Specifics 230 During the creation process of new communications system, analogue 231 voice is replaced by digital data communication. This sets a 232 paradigm shift from analogue to digital wireless communications and 233 supports the related trend towards increased autonomous data 234 processing that the Future Communications Infrastructure (FCI) in 235 civil aviation must provide. The FCI is depicted in Figure 1: 237 Satellite 238 # # 239 # # # 240 # # # 241 # # # 242 # # # 243 # # # 244 # # # 245 # Satellite-based # # 246 # Communications # # 247 # SatCOM (#) # # 248 # # Aircraft 249 # # % % 250 # # % % 251 # # % Air-Air % 252 # # % Communications % 253 # # % LDACS A/A (%) % 254 # # % % 255 # Aircraft % % % % % % % % % % Aircraft 256 # | Air-Ground | 257 # | Communications | 258 # | LDACS A/G (|) | 259 # Communications in | | 260 # and around airports | | 261 # AeroMACS (-) | | 262 # | | 263 # Aircraft-------------+ | | 264 # | | | 265 # | | | 266 # Ground network | | Ground network | 267 SatCOM <---------------------> Airport <----------------------> LDACS 268 transceiver based GS 269 transceiver 271 Figure 1: The Future Communication Infrastructure (FCI): AeroMACS for 272 APT/TMA domain, LDACS A/G for TMA/ENR domain, LDACS A/G for ENR/ORP 273 domain, SatCOM for ORP domain communications 275 2.3. Challenges 277 This paradigm change brings a lot of new challenges: 279 o Efficiency: It is necessary to keep latency, time and data 280 overhead (routing, security) of new aeronautical datalinks at a 281 minimum. 283 o Modularity: Systems in avionics usually operate up to 30 years, 284 thus solutions must be modular, easily adaptable and updatable. 286 o Interoperability: All 192 members of the international Civil 287 Aviation Organization (ICAO) must be able to use these solutions. 289 2.4. The Need for Wireless 291 In a high mobility environment such as aviation, the envisioned 292 solutions to provide worldwide coverage of data connections with in- 293 flight aircraft require a multi-system, multi-link, multi-hop 294 approach. Thus air, ground and space based datalink providing 295 technologies will have to operate seamlessly together to cope with 296 the increasing needs of data exchange between aircraft, air traffic 297 controller, airport infrastructure, airlines, air network service 298 providers (ANSPs) and so forth. Thus making use of wireless 299 technologies is a must in tackling this enormous need for a worldwide 300 digital aeronautical datalink infrastructure. 302 2.5. Requirements for RAW 304 Different safety levels need to be supported, from extremely safety 305 critical ones requiring low latency, such as a WAKE warning - a 306 warning that two aircraft come dangerously close to each other - and 307 high resiliency, to less safety critical ones requiring low-medium 308 latency for services such as WXGRAPH - graphical weather data. 310 Overhead needs to be kept at a minimum since aeronautical data links 311 provide comparatively small data rates in the order of kbit/s. 313 Policy needs to be supported when selecting data links. The focus of 314 RAW here should be on the selectors, responsible for the routing path 315 a packet takes to reach its end destination. This would minimize the 316 amount of routing information that has to travel inside the network 317 because of precomputed routing tables with the selector being 318 responsible for choosing the most appropriate option according to 319 policy and safety. 321 3. Amusement Parks 323 3.1. Use Case Description 325 The digitalization of Amusement Parks is expected to decrease 326 significantly the cost for maintaining the attractions. Such 327 deployment is a mix between industrial automation (aka. Smart 328 Factories) and multimedia entertainment applications. 330 Attractions may rely on a large set of sensors and actuators, which 331 react in real time. Typical applications comprise: 333 o Emergency: safety has to be preserved, and must stop the 334 attraction when a failure is detected. 336 o Video: augmented and virtual realities are integrated in the 337 attraction. Wearable mobile devices (e.g., glasses, virtual 338 reality headset) need to offload one part of the processing tasks. 340 o Real-time interactions: visitors may interact with an attraction, 341 like in a real-time video game. The visitors may virtually 342 interact with their environment, triggering actions in the real 343 world (through actuators) [robots]. 345 o Geolocation: visitors are tracked with a personal wireless tag so 346 that their user experience is improved. 348 o Predictive maintenance: statistics are collected to predict the 349 future failures, or to compute later more complex statistics about 350 the attraction's usage, the downtime, its popularity, etc. 352 3.2. Specifics 354 Amusement parks comprise a variable number of attractions, mostly 355 outdoor, over a large geographical area. The IT infrastructure is 356 typically multi-scale: 358 o Local area: the sensors and actuators controlling the attractions 359 are co-located. Control loops trigger only local traffic, with a 360 small end-to-end delay, typically inferior than 10 milliseconds, 361 like classical industrial systems [ieee80211-rt-tig]. 363 o Wearable mobile devices are free to move in the park. They 364 exchange traffic locally (identification, personalization, 365 multimedia) or globally (billing, child tracking). 367 o Computationally intensive applications offload some tasks. Edge 368 computing seems an efficient way to implement real-time 369 applications with offloading. Some non time-critical tasks may 370 rather use the cloud (predictive maintenance, marketing). 372 3.3. The Need for Wireless 374 Amusement parks cover large areas and a global interconnection would 375 require a huge length of cables. Wireless also increases the 376 reconfigurability, enabling to update cheaply the attractions. The 377 frequent renewal helps to increase customer loyalty. 379 Some parts of the attraction are mobile, e.g., trucks of a roller- 380 coaster, robots. Since cables are prone to frequent failures in this 381 situation, wireless transmissions are recommended. 383 Wearable devices are extensively used for a user experience 384 personalization. They typically need to support wireless 385 transmissions. Personal tags may help to reduce the operating costs 386 [disney-VIP] and to increase the number of charged services provided 387 to the audience (VIP tickets, interactivity, etc.) Some applications 388 rely on more sophisticated wearable devices such as digital glasses 389 or Virtual Reality (VR) headsets for an immersive experience. 391 3.4. Requirements for RAW 393 The network infrastructure has to support heterogeneous traffic, with 394 very different critical requirements. Thus, flow isolation has to be 395 provided. 397 We have to schedule appropriately the transmissions, even in presence 398 of mobile devices. While the [I-D.ietf-6tisch-architecture] already 399 proposes an architecture for synchronized, IEEE Std. 802.15.4 Time- 400 Slotted Channel Hopping (TSCH) networks, we still need multi- 401 technology solutions, able to guarantee end-to-end requirements 402 across heterogeneous technologies, with strict SLA requirements. 404 Nowadays, long-range wireless transmissions are used mostly for best- 405 effort traffic. On the contrary, [IEEE802.1TSN] is used for critical 406 flows using Ethernet devices. However, we need an IP enabled 407 technology to interconnect large areas, independent of the PHY and 408 MAC layers. 410 We expect to deploy several different technologies (long vs. short 411 range) which have to cohabit in the same area. Thus, we need to 412 provide layer-3 mechanisms able to exploit multiple co-interfering 413 technologies. 415 4. Wireless for Industrial Applications 417 4.1. Use Case Description 419 A major use case for networking in Industrial environments is the 420 control networks where periodic control loops operate between a 421 sensor that measures a physical property such as the temperature of a 422 fluid, a Programmable Logic Controller (PLC) that decides an action 423 such as warm up the mix, and an actuator that performs the required 424 action, e.g., inject power in a resistor. 426 4.2. Specifics 428 4.2.1. Control Loops 430 Process Control designates continuous processing operations, e.g., 431 heating Oil in a refinery or mixing drinking soda. Control loops in 432 the Process Control industry operate at a very low rate, typically 4 433 times per second. Factory Automation, on the other hand, deal with 434 discrete goods such as individual automobile parts, and requires 435 faster loops, in the order of 10ms. Motion control that monitors 436 dynamic activities may require even faster rates in the order of a 437 few ms. Finally, some industries exhibit hybrid behaviors, like 438 canned soup that will start as a process industry while mixing the 439 food and then operate as a discrete manufacturing when putting the 440 final product in cans and shipping them. 442 In all those cases, a packet must flow reliably between the sensor 443 and the PLC, be processed by the PLC, and sent to the actuator within 444 the control loop period. In some particular use cases that inherit 445 from analog operations, jitter might also alter the operation of the 446 control loop. A rare packet loss is usually admissible, but 447 typically 4 losses in a row will cause an emergency halt of the 448 production and incur a high cost for the manufacturer. 450 4.2.2. Unmeasured Data 452 A secondary use case deals with monitoring and diagnostics. This so- 453 called unmeasured data is essential to improve the performances of a 454 production line, e.g., by optimizing real-time processing or 455 maintenance windows using Machine Learning predictions. For the lack 456 of wireless technologies, some specific industries such as Oil and 457 Gas have been using serial cables, literally by the millions, to 458 perform their process optimization over the previous decades. But 459 few industries would afford the associated cost and the Holy Grail of 460 the Industrial Internet of Things is to provide the same benefits to 461 all industries, including SmartGrid, Transportation, Building, 462 Commercial and Medical. This requires a cheap, available and 463 scalable IP-based access technology. 465 Inside the factory, wires may already be available to operate the 466 Control Network. But unmeasured data are not welcome in that network 467 for a number of reasons. On the one hand it is rich and 468 asynchronous, meaning that using they may influence the deterministic 469 nature of the control operations and impact the production. On the 470 other hand, this information must be reported to the carpeted floor 471 over IP, which means the potential for a security breach via the 472 interconnection of the Operational Technology (OT) network with the 473 Internet technology (IT) network and possibly enable a rogue access. 475 4.3. The Need for Wireless 477 Ethernet cables used on a robot arm are prone to breakage after a few 478 thousands flexions, a lot faster than a power cable that is wider inn 479 diameter, and more resilient. In general, wired networking and 480 mobile parts are not a good match, mostly in the case of fast and 481 recurrent activities, as well as rotation. 483 When refurbishing older premises that were built before the Internet 484 age, power is usually available everywhere, but data is not. It is 485 often impractical, time consuming and expensive to deploy an Ethernet 486 fabric across walls and between buildings. Deploying a wire may take 487 months and cost tens of thousands of US Dollars. 489 Even when wiring exists, e.g., in an existing control network, 490 asynchronous IP packets such as diagnostics may not be welcome for 491 operational and security reasons (see Section 4.2.1). An alternate 492 network that can scale with the many sensors and actuators that equip 493 every robot, every valve and fan that are deployed on the factory 494 floor and may help detect and prevent a failure that could impact the 495 production. IEEE Std. 802.15.4 Time-Slotted Channel Hopping (TSCH) 496 [RFC7554] is a promising technology for that purpose, mostly if the 497 scheduled operations enable to use the same network by asynchronous 498 and deterministic flows in parallel. 500 4.4. Requirements for RAW 502 As stated by the "Deterministic Networking Problem Statement" 503 [RFC8557], a Deterministic Network is backwards compatible with 504 (capable of transporting) statistically multiplexed traffic while 505 preserving the properties of the accepted deterministic flows. While 506 the [I-D.ietf-6tisch-architecture] serves that requirement, the work 507 at 6TiSCH was focused on best-effort IPv6 packet flows. RAW should 508 be able to lock so-called hard cells for use by a centralized 509 scheduler, and program so-called end-to-end Tracks over those cells. 511 Over the course of the recent years, major Industrial Protocols, 512 e.g., [ODVA] with EtherNet/IP [EIP] and [Profinet], have been 513 migrating towards Ethernet and IP. In order to unleash the full 514 power of the IP hourglass model, it should be possible to deploy any 515 application over any network that has the physical capacity to 516 transport the industrial flow, regardless of the MAC/PHY technology, 517 wired or wireless, and across technologies. RAW mechanisms should be 518 able to setup a Track over a wireless access segment such as TSCH and 519 a backbone segment such as Ethernet or WI-Fi, to report a sensor data 520 or a critical monitoring within a bounded latency. It is also 521 important to ensure that RAW solutions are interoperable with 522 existing wireless solutions in place, and with legacy equipment which 523 capabilities can be extended using retrofitting. Maintanability, as 524 a broader concept than reliability is also important in industrial 525 scenarios [square-peg]. 527 5. Pro Audio and Video 529 5.1. Use Case Description 531 Many devices support audio and video streaming by employing 802.11 532 wireless LAN. Some of these applications require low latency 533 capability. For instance, when the application provides interactive 534 play, or when the audio takes plays in real time (i.e. live) for 535 public addresses in train stations or in theme parks. 537 The professional audio and video industry ("ProAV") includes: 539 o Virtual Reality / Augmented Reality (VR/AR) 541 o Public address, media and emergency systems at large venues 542 (airports, train stations, stadiums, theme parks). 544 5.2. Specifics 546 5.2.1. Uninterrupted Stream Playback 548 Considering the uninterrupted audio or video stream, a potential 549 packet losses during the transmission of audio or video flows cannot 550 be tackled by re-trying the transmission, as it is done with file 551 transfer, because by the time the packet lost has been identified it 552 is too late to proceed with packet re-transmission. Buffering might 553 be employed to provide a certain delay which will allow for one or 554 more re-transmissions, however such approach is not efficient in 555 application where delays are not acceptable. 557 5.2.2. Synchronized Stream Playback 559 In the context of ProAV, latency is the time between the transmitted 560 signal over a stream and its reception. Thus, for sound to remain 561 synchronized to the movement in the video, the latency of both the 562 audio and video streams must be bounded and consistent. 564 5.3. The Need for Wireless 566 The devices need the wireless communication to support video 567 streaming via 802.11 wireless LAN for instance. 569 During the public address, the deployed announcement speakers, for 570 instance along the platforms of the train stations, need the wireless 571 communication to forward the audio traffic in real time. 573 5.4. Requirements for RAW 575 The network infrastructure needs to support heterogeneous types of 576 traffic (including QoS). 578 Content delivery with bounded (lowest possible) latency. 580 The deployed network topology should allow for multipath. This will 581 enable for multiple streams to have different (and multiple) paths 582 through the network to support redundancy. 584 6. Wireless Gaming 586 6.1. Use Case Description 588 The gaming industry includes [IEEE80211RTA] real-time mobile gaming, 589 wireless console gaming and cloud gaming. For RAW, wireless console 590 gaming is the most relevant one. We next summarize the three: 592 o Real-time Mobile Gaming: Different from traditional games, real 593 time mobile gaming is very sensitive to network latency and 594 stability. The mobile game can connect multiple players together 595 in a single game session and exchange data messages between game 596 server and connected players. Real-time means the feedback should 597 present on screen as users operate in game. For good game 598 experience, the end to end latency plus game servers processing 599 time should not be noticed by users as they play the game. 601 o Wireless Console Gaming: Playing online on a console has 2 types 602 of internet connectivity, which is either wired or Wi-Fi. Most of 603 the gaming consoles today support Wi-Fi 5. But Wi-Fi has an 604 especially bad reputation among the gaming community. The main 605 reasons are high latency, lag spikes and jitter. 607 o Cloud Gaming: The cloud gaming requires low latency capability as 608 the user commands in a game session need to be sent back to the 609 cloud server, the cloud server would update game context depending 610 on the received commands, and the cloud server would render the 611 picture/video to be displayed at user devices and stream the 612 picture/video content to the user devices. User devices might 613 very likely be connected wirelessly. 615 6.2. Specifics 617 While a lot of details can be found on [IEEE80211RTA], we next 618 summarize the main requirements in terms of latency, jitter and 619 packet loss: 621 o Intra BSS latency: less than 5 ms. 623 o Jitter variance: less than 2 ms. 625 o Packet loss: less than 0.1 percent. 627 6.3. The Need for Wireless 629 It is clear that gaming is evolving towards wireless, as players 630 demand being able to play anywhere. Besides, the industry is 631 changing towards playing from mobile phones, which are inherently 632 connected via wireless technologies. 634 6.4. Requirements for RAW 636 o Time sensitive networking extensions. Extensions, such as time- 637 aware shaping and redundancy (FRE) can be explored to address 638 congestion and reliability problems present in wireless networks. 640 o Priority tagging (Stream identification). One basic requirement 641 to provide better QoS for time-sensitive traffic is the capability 642 to identify and differentiate time-sensitive packets from other 643 (e.g. best-effort) traffic. 645 o Time-aware shaping. This capability (defined in IEEE 802.1Qbv) 646 consists of gates to control the opening/closing of queues that 647 share a common egress port within an Ethernet switch. A scheduler 648 defines the times when each queue opens or close, therefore 649 eliminating congestion and ensuring that frames are delivered 650 within the expected latency bounds. 652 o Dual/multiple link. Due to the competitions and interference are 653 common and hardly in control under wireless network, in order to 654 improve the latency stability, dual/multiple link proposal is 655 brought up to address this issue. Two modes are defined: 656 duplicate and joint. 658 o Admission Control. Congestion is a major cause of high/variable 659 latency and it is well known that if the traffic load exceeds the 660 capability of the link, QoS will be degraded. QoS degradation 661 maybe acceptable for many applications today, however emerging 662 time-sensitive applications are highly susceptible to increased 663 latency and jitter. In order to better control QoS, it is 664 important to control access to the network resources. 666 7. UAV platooning and control 668 7.1. Use Case Description 670 Unmanned Aerial Vehicles (UAVs) are becoming very popular for many 671 different applications, including military and civil use cases. The 672 term drone is commonly used to refer to a UAV. 674 UAVs can be used to perform aerial surveillance activities, traffic 675 monitoring (e.g., Spanish traffic control has recently introduced a 676 fleet of drones for quicker reactions upon traffic congestion related 677 events), support of emergency situations, and even transportation of 678 small goods. 680 UAVs typically have various forms of wireless connectivity: 682 o cellular: for communication with the control center, for remote 683 maneuvering as well as monitoring of the drone; 685 o IEEE 802.11: for inter-drone communications (e.g., platooning) and 686 providing connectivity to other devices (e.g., acting as Access 687 Point). 689 7.2. Specifics 691 Some of the use cases/tasks involving drones require coordination 692 among drones. Others involve complex compute tasks that might not be 693 performed using the limited computing resources that a drone 694 typically has. These two aspects require continuous connectivity 695 with the control center and among drones. 697 Remote maneuvering of a drone might be performed over a cellular 698 network in some cased, however, there are situations that need very 699 low latencies and deterministic behavior of the connectivity. 700 Examples involve platooning of drones or share of computing resources 701 among drones (e.g., a drone offload some function to a neighboring 702 drone). 704 7.3. The Need for Wireless 706 UAVs cannot be connected through any type of wired media, so it is 707 obvious that wireless is needed. 709 7.4. Requirements for RAW 711 The network infrastructure is actually composed by the UAVs 712 themselves, requiring self-configuration capabilities. 714 Heterogeneous types of traffic need to be supported, from extremely 715 critical ones requiring ultra low latency and high resiliency, to 716 traffic requiring low-medium latency. 718 When a given service is decomposed into functions -- hosted at 719 different drones -- chained, each link connecting two given functions 720 would have a well-defined set of requirements (latency, bandwidth and 721 jitter) that have to be met. 723 8. Edge Robotics control 725 8.1. Use Case Description 727 The Edge Robotics scenario consists of several robots, deployed in a 728 given area (for example a shopping mall), inter-connected via an 729 access network to a network's edge device or a data center. The 730 robots are connected to the edge so complex computational activities 731 are not executed locally at the robots, but offloaded to the edge. 732 This brings additional flexibility in the type of tasks that the 733 robots do, as well as reducing the costs of robot manufacturing (due 734 to their lower complexity), and enabling complex tasks involving 735 coordination among robots (that can be more easily performed if 736 robots are centrally controlled). 738 A simple example of the use of multiples robots is cleaning, 739 delivering of goods from warehouses to shops or video surveillance. 740 Multiple robots are simultaneously instructed to perform individual 741 tasks by moving the robotic intelligence from the robots to the 742 network's edge (e.g., data center). That enables easy 743 synchronization, scalable solution and on-demand option to create 744 flexible fleet of robots. 746 Robots would have various forms of wireless connectivity: 748 o IEEE 802.11: for connection to the edge and also inter-robot 749 communications (e.g., for coordinated actions). 751 o Cellular: as an additional communication link to the edge, though 752 primarily as backup, since ultra low latencies are needed. 754 8.2. Specifics 756 Some of the use cases/tasks involving robots might benefit from 757 decomposition of a service in small functions that are distributed 758 and chained among robots and the edge. These require continuous 759 connectivity with the control center and among drones. 761 Robot control is an activity requiring very low latencies between the 762 robot and the location where the control intelligence resides (which 763 might be the edge or another robot). 765 8.3. The Need for Wireless 767 Deploying robots in scenarios such as shopping malls for the 768 aforementioned applications cannot be done via wired connectivity. 770 8.4. Requirements for RAW 772 The network infrastructure needs to support heterogeneous types of 773 traffic, from robot control to video streaming. 775 When a given service is decomposed into functions -- hosted at 776 different robots -- chained, each link connecting two given functions 777 would have a well-defined set of requirements (latency, bandwidth and 778 jitter) that have to be met. 780 9. Emergencies: Instrumented emergency vehicle 782 9.1. Use Case Description 784 An instrumented ambulance would be one that has a LAN to which are 785 connected these end systems: 787 o vital signs sensors attached to the casualty in the ambulance. 788 Relay medical data to hospital emergency room, 790 o radionavigation sensor to relay position data to various 791 destinations including dispatcher, 793 o voice communication for ambulance attendant (e.g. consult with ER 794 doctor), 796 o voice communication between driver and dispatcher, 798 o etc. 800 The LAN needs to be routed through radio-WANs to complete the 801 internetwork linkage. 803 9.2. Specifics 805 What we have today is multiple communications systems to reach the 806 vehicle: 808 o A dispatching system, 810 o a cellphone for the attendant, 812 o a special purpose telemetering system for medical data, 814 o etc. 816 This redundancy of systems, because of its stovepiping, does not 817 contribute to availability as a whole. 819 Most of the scenarios involving the use of an instrumented ambulance 820 are composed of many different flows, each of them with slightly 821 different requirements in terms of reliability and latency. 822 Destinations might be either at the ambulance itself (local traffic), 823 at a near edge cloud or at the general Internet/cloud. 825 9.3. The Need for Wireless 827 Local traffic between the first responders/ambulance staff and the 828 ambulance equipment cannot be doine via wireled connectivity as the 829 responders perform initial treatment outside of the ambulance. The 830 communications from the ambulance to external services has to be 831 wireless as well. 833 9.4. Requirements for RAW 835 We can derive some pertinent requirements from this scenario: 837 o High availability of the internetwork is required. 839 o The internetwork needs to operate in damaged state (e.g. during an 840 earthquake aftermath, heavy weather, wildfire, etc.). In addition 841 to continuity of operations, rapid restoral is a needed 842 characteristic. 844 o End-to-end security, both authenticity and confidentiality, is 845 required of traffic. All data needs to be authenticated; some 846 (such as medical) needs to be confidential. 848 o The radio-WAN has characteristics similar to cellphone -- the 849 vehicle will travel from one radio footprint to another. 851 10. IANA Considerations 853 This document has no IANA actions. 855 11. Security Considerations 857 This document covers a number of representative applications and 858 network scenarios that are expected to make use of RAW technologies. 859 Each of the potential RAW use cases will have security considerations 860 from both the use-specific perspective and the RAW technology 861 perspective. [I-D.ietf-detnet-security] provides a comprehensive 862 discussion of security considerations in the context of Deterministic 863 Networking, which are generally applicable also to RAW. 865 12. Acknowledgments 867 Nils Maeurer, Thomas Graeupl and Corinna Schmitt have contributed 868 significantly to this document, providing input for the Aeronautical 869 communications section. Rex Buddenberg has also contributed to the 870 document, providing input to the Emergency: instrumented emergency 871 vehicle section. 873 The authors would like to thank Toerless Eckert, Xavi Vilajosana 874 Guillen and Rute Sofia for their valuable comments on previous 875 versions of this document. 877 The work of Carlos J. Bernardos in this draft has been partially 878 supported by the H2020 5Growth (Grant 856709) and 5G-DIVE projects 879 (Grant 859881). 881 13. Informative References 883 [disney-VIP] 884 Wired, "Disney's $1 Billion Bet on a Magical Wristband", 885 March 2015, 886 . 888 [EIP] http://www.odva.org/, "EtherNet/IP provides users with the 889 network tools to deploy standard Ethernet technology (IEEE 890 802.3 combined with the TCP/IP Suite) for industrial 891 automation applications while enabling Internet and 892 enterprise connectivity data anytime, anywhere.", 893 . 897 [EURO20] EUROCONTROL, "EUROCONTROL's Challenges of Growth 2018 898 Study Report", 2018, . 902 [FAA20] U.S. Department of Transportation Federal Aviation 903 Administration (FAA), "Next Generation Air Transportation 904 System", 2019, . 906 [I-D.ietf-6tisch-architecture] 907 Thubert, P., "An Architecture for IPv6 over the TSCH mode 908 of IEEE 802.15.4", draft-ietf-6tisch-architecture-29 (work 909 in progress), August 2020. 911 [I-D.ietf-detnet-security] 912 Grossman, E., Mizrahi, T., and A. Hacker, "Deterministic 913 Networking (DetNet) Security Considerations", draft-ietf- 914 detnet-security-12 (work in progress), October 2020. 916 [I-D.maeurer-raw-ldacs] 917 Maeurer, N., Graeupl, T., and C. Schmitt, "L-band Digital 918 Aeronautical Communications System (LDACS)", draft- 919 maeurer-raw-ldacs-06 (work in progress), October 2020. 921 [I-D.thubert-raw-technologies] 922 Thubert, P., Cavalcanti, D., Vilajosana, X., Schmitt, C., 923 and J. Farkas, "Reliable and Available Wireless 924 Technologies", draft-thubert-raw-technologies-05 (work in 925 progress), May 2020. 927 [ICAO18] International Civil Aviation Organization (ICAO), "L-Band 928 Digital Aeronautical Communication System (LDACS)", 929 International Standards and Recommended Practices Annex 10 930 - Aeronautical Telecommunications, Vol. III - 931 Communication Systems , 2018. 933 [IEEE802.1TSN] 934 IEEE standard for Information Technology, "IEEE 935 802.1AS-2011 - IEEE Standard for Local and Metropolitan 936 Area Networks - Timing and Synchronization for Time- 937 Sensitive Applications in Bridged Local Area Networks". 939 [ieee80211-rt-tig] 940 IEEE, "IEEE 802.11 Real Time Applications TIG Report", 941 Nov. 2018, 942 . 944 [IEEE80211RTA] 945 IEEE standard for Information Technology, "IEEE 802.11 946 Real Time Applications TIG Report", Nov 2018. 948 [ISA100] ISA/ANSI, "ISA100, Wireless Systems for Automation", 949 . 951 [KEAV20] T. Keaveney and C. Stewart, "Single European Sky ATM 952 Research Joint Undertaking", 2019, 953 . 955 [ODVA] http://www.odva.org/, "The organization that supports 956 network technologies built on the Common Industrial 957 Protocol (CIP) including EtherNet/IP.". 959 [PLA14] Plass, S., Hermenier, R., Luecke, O., Gomez Depoorter, D., 960 Tordjman, T., Chatterton, M., Amirfeiz, M., Scotti, S., 961 Cheng, Y., Pillai, P., Graeupl, T., Durand, F., Murphy, 962 K., Marriott, A., and A. Zaytsev, "Flight Trial 963 Demonstration of Seamless Aeronautical Networking", IEEE 964 Communications Magazine, vol. 52, no. 5 , May 2014. 966 [Profinet] 967 http://us.profinet.com/technology/profinet/, "PROFINET is 968 a standard for industrial networking in automation.", 969 . 971 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 972 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 973 Internet of Things (IoT): Problem Statement", RFC 7554, 974 DOI 10.17487/RFC7554, May 2015, 975 . 977 [RFC8557] Finn, N. and P. Thubert, "Deterministic Networking Problem 978 Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019, 979 . 981 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 982 RFC 8578, DOI 10.17487/RFC8578, May 2019, 983 . 985 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 986 "Deterministic Networking Architecture", RFC 8655, 987 DOI 10.17487/RFC8655, October 2019, 988 . 990 [robots] Kober, J., Glisson, M., and M. Mistry, "Playing catch and 991 juggling with a humanoid robot.", 2012, 992 . 994 [square-peg] 995 Martinez, B., Cano, C., and X. Vilajosana, "A Square Peg 996 in a Round Hole: The Complex Path for Wireless in the 997 Manufacturing Industry", 2019, 998 . 1000 Authors' Addresses 1002 Georgios Z. Papadopoulos 1003 IMT Atlantique 1004 Office B00 - 114A 1005 2 Rue de la Chataigneraie 1006 Cesson-Sevigne - Rennes 35510 1007 FRANCE 1009 Phone: +33 299 12 70 04 1010 Email: georgios.papadopoulos@imt-atlantique.fr 1012 Pascal Thubert 1013 Cisco Systems, Inc 1014 Building D 1015 45 Allee des Ormes - BP1200 1016 MOUGINS - Sophia Antipolis 06254 1017 FRANCE 1019 Phone: +33 497 23 26 34 1020 Email: pthubert@cisco.com 1022 Fabrice Theoleyre 1023 CNRS 1024 ICube Lab, Pole API 1025 300 boulevard Sebastien Brant - CS 10413 1026 Illkirch 67400 1027 FRANCE 1029 Phone: +33 368 85 45 33 1030 Email: theoleyre@unistra.fr 1031 URI: http://www.theoleyre.eu 1032 Carlos J. Bernardos 1033 Universidad Carlos III de Madrid 1034 Av. Universidad, 30 1035 Leganes, Madrid 28911 1036 Spain 1038 Phone: +34 91624 6236 1039 Email: cjbc@it.uc3m.es 1040 URI: http://www.it.uc3m.es/cjbc/