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