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