idnits 2.17.1 draft-bernardos-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 : ---------------------------------------------------------------------------- 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 (March 7, 2020) is 1503 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-28 == Outdated reference: A later version (-06) exists of draft-maeurer-raw-ldacs-01 == Outdated reference: A later version (-05) exists of draft-thubert-raw-technologies-04 Summary: 0 errors (**), 0 flaws (~~), 4 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: September 8, 2020 Cisco 6 F. Theoleyre 7 CNRS 8 CJ. Bernardos 9 UC3M 10 March 7, 2020 12 RAW use cases 13 draft-bernardos-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 September 8, 2020. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Aeronautical Communications . . . . . . . . . . . . . . . . . 5 60 2.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 5 61 2.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.3. Challenges . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.4. The Need for Wireless . . . . . . . . . . . . . . . . . . 7 64 2.5. Requirements for RAW . . . . . . . . . . . . . . . . . . 7 65 3. Amusement Parks . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.1. Use Case Description . . . . . . . . . . . . . . . . . . 7 67 3.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 8 68 3.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 9 69 3.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 9 70 4. Wireless for Industrial Applications . . . . . . . . . . . . 10 71 4.1. Use Case Description . . . . . . . . . . . . . . . . . . 10 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 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 100 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 101 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 102 12. Informative References . . . . . . . . . . . . . . . . . . . 17 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 105 1. Introduction 107 Based on time, resource reservation, and policy enforcement by 108 distributed shapers, Deterministic Networking provides the capability 109 to carry specified unicast or multicast data streams for real-time 110 applications with extremely low data loss rates and bounded latency, 111 so as to support time-sensitive and mission-critical applications on 112 a converged enterprise infrastructure. 114 Deterministic Networking in the IP world is an attempt to eliminate 115 packet loss for a committed bandwidth while ensuring a worst case 116 end-to-end latency, regardless of the network conditions and across 117 technologies. It can be seen as a set of new Quality of Service 118 (QoS) guarantees of worst-case delivery. IP networks become more 119 deterministic when the effects of statistical multiplexing (jitter 120 and collision loss) are mostly eliminated. This requires a tight 121 control of the physical resources to maintain the amount of traffic 122 within the physical capabilities of the underlying technology, e.g., 123 by the use of time-shared resources (bandwidth and buffers) per 124 circuit, and/or by shaping and/or scheduling the packets at every 125 hop. 127 Key attributes of Deterministic Networking include: 129 o time synchronization on all the nodes, 131 o centralized computation of network-wide deterministic paths, 133 o multi-technology path with co-channel interference minimization, 135 o frame preemption and guard time mechanisms to ensure a worst-case 136 delay, and 138 o new traffic shapers within and at the edge to protect the network. 140 Wireless operates on a shared medium, and transmissions cannot be 141 fully deterministic due to uncontrolled interferences, including 142 self-induced multipath fading. RAW (Reliable and Available Wireless) 143 is an effort to provide Deterministic Networking on across a path 144 that include a wireless physical layer. Making Wireless Reliable and 145 Available is even more challenging than it is with wires, due to the 146 numerous causes of loss in transmission that add up to the congestion 147 losses and the delays caused by overbooked shared resources. 149 The wireless and wired media are fundamentally different at the 150 physical level, and while the generic Problem Statement [RFC8557] for 151 DetNet applies to the wired as well as the wireless medium, the 152 methods to achieve RAW necessarily differ from those used to support 153 Time-Sensitive Networking over wires. 155 So far, Open Standards for Deterministic Networking have prevalently 156 been focused on wired media, with Audio/Video Bridging (AVB) and Time 157 Sensitive Networking (TSN) at the IEEE and DetNet [RFC8655] at the 158 IETF. But wires cannot be used in a number of cases, including 159 mobile or rotating devices, rehabilitated industrial buildings, 160 wearable or in-body sensory devices, vehicle automation and 161 multiplayer gaming. 163 Purpose-built wireless technologies such as [ISA100], which 164 incorporates IPv6, were developped and deployed to cope for the lack 165 of open standards, but they yield a high cost in OPEX and CAPEX and 166 are limited to very few industries, e.g., process control, concert 167 instruments or racing. 169 This is now changing [I-D.thubert-raw-technologies]: 171 o IMT-2020 has recognized Ultra-Reliable Low-Latency Communication 172 (URLLC) as a key functionality for the upcoming 5G. 174 o IEEE 802.11 has identified a set of real-applications 175 [ieee80211-rt-tig] which may use the IEEE802.11 standards. They 176 typically emphasize strict end-to-end delay requirements. 178 o The IETF has produced an IPv6 stack for IEEE Std. 802.15.4 179 TimeSlotted Channel Hopping (TSCH) and an architecture 180 [I-D.ietf-6tisch-architecture] that enables Reliable and Available 181 Wireless (RAW) on a shared MAC. 183 This draft extends the "Deterministic Networking Use Cases" document 184 [RFC8578] and describes a number of additional use cases which 185 require "reliable/predictable and available" flows over wireless 186 links and possibly complex multi-hop paths called Tracks. This is 187 covered mainly by the "Wireless for Industrial Applications" use 188 case, as the "Cellular Radio" is mostly dedicated to the (wired) 189 transport part of a Radio Access Network (RAN). Whereas the 190 "Wireless for Industrial Applications" use case certainly covers an 191 area of interest for RAW, it is limited to 6TiSCH, and thus its scope 192 is narrower than the use cases described next in this document. 194 2. Aeronautical Communications 196 Aircraft are currently connected to ATC (Air-Traffic Control) and AOC 197 (Airline Operational Control) via voice and data communications 198 systems through all phases of a flight. Within the airport terminal, 199 connectivity is focused on high bandwidth communications while during 200 en-route high reliability, robustness and range is the main focus. 202 2.1. Problem Statement 204 Worldwide civil air traffic is expected to grow by 84% until 2040 205 compared to 2017 [EURO20]. Thus, legacy systems in air traffic 206 management (ATM) are likely to reach their capacity limits and the 207 need for new aeronautical communication technologies becomes 208 apparent. Especially problematic is the saturation of VHF band in 209 high density areas in Europe, the US, and Asia [KEAV20] [FAA20] 210 calling for suitable new digital approaches such as AeroMACS for 211 airport communications, SatCOM for remote domains, and LDACS as long- 212 range terrestrial aeronautical communications system. Making the 213 frequency spectrum's usage more efficient a transition from analogue 214 voice to digital data communication [PLA14] is necessary to cope with 215 the expected growth of civil aviation and its supporting 216 infrastructure. A promising candidate for long range terrestrial 217 communications, already in the process of being standardized in the 218 International Civil Aviation Organization (ICAO), is the L-band 219 Digital Aeronautical Communications System (LDACS) [ICAO18] 220 [I-D.maeurer-raw-ldacs]. 222 2.2. Specifics 224 During the creation process of new communications system, analogue 225 voice is replaced by digital data communication. This sets a 226 paradigm shift from analogue to digital wireless communications and 227 supports the related trend towards increased autonomous data 228 processing that the Future Communications Infrastructure (FCI) in 229 civil aviation must provide. The FCI is depicted in Figure 1: 231 Satellite 232 # # 233 # # # 234 # # # 235 # # # 236 # # # 237 # # # 238 # # # 239 # Satellite-based # # 240 # Communications # # 241 # SatCOM (#) # # 242 # # Aircraft 243 # # % % 244 # # % % 245 # # % Air-Air % 246 # # % Communications % 247 # # % LDACS A/A (%) % 248 # # % % 249 # Aircraft % % % % % % % % % % Aircraft 250 # | Air-Ground | 251 # | Communications | 252 # | LDACS A/G (|) | 253 # Communications in | | 254 # and around airports | | 255 # AeroMACS (-) | | 256 # | | 257 # Aircraft-------------+ | | 258 # | | | 259 # | | | 260 # Ground network | | Ground network | 261 SatCOM <---------------------> Airport <----------------------> LDACS 262 transceiver based GS 263 transceiver 265 Figure 1: The Future Communication Infrastructure (FCI): AeroMACS for 266 APT/TMA domain, LDACS A/G for TMA/ENR domain, LDACS A/G for ENR/ORP 267 domain, SatCOM for ORP domain communications 269 2.3. Challenges 271 This paradigm change brings a lot of new challenges: 273 o Efficiency: It is necessary to keep latency, time and data 274 overhead (routing, security) of new aeronautical datalinks at a 275 minimum. 277 o Modularity: Systems in avionics usually operate up to 30 years, 278 thus solutions must be modular, easily adaptable and updatable. 280 o Interoperability: All 192 members of the international Civil 281 Aviation Organization (ICAO) must be able to use these solutions. 283 2.4. The Need for Wireless 285 In a high mobility environment such as aviation, the envisioned 286 solutions to provide worldwide coverage of data connections with in- 287 flight aircraft require a multi-system, multi-link, multi-hop 288 approach. Thus air, ground and space based datalink providing 289 technologies will have to operate seamlessly together to cope with 290 the increasing needs of data exchange between aircraft, air traffic 291 controller, airport infrastructure, airlines, air network service 292 providers (ANSPs) and so forth. Thus making use of wireless 293 technologies is a must in tackling this enormous need for a worldwide 294 digital aeronautical datalink infrastructure. 296 2.5. Requirements for RAW 298 Different safety levels need to be supported, from extremely safety 299 critical ones requiring low latency, such as a WAKE warning - a 300 warning that two aircraft come dangerously close to each other - and 301 high resiliency, to less safety critical ones requiring low-medium 302 latency for services such as WXGRAPH - graphical weather data. 304 Overhead needs to be kept at a minimum since aeronautical data links 305 provide comparatively small data rates in the order of kbit/s. 307 Policy needs to be supported when selecting data links. The focus of 308 RAW here should be on the selectors, responsible for the routing path 309 a packet takes to reach its end destination. This would minimize the 310 amount of routing information that has to travel inside the network 311 because of precomputed routing tables with the selector being 312 responsible for choosing the most appropriate option according to 313 policy and safety. 315 3. Amusement Parks 317 3.1. Use Case Description 319 The digitalization of Amusement Parks is expected to decrease 320 significantly the cost for maintaining the attractions. By 321 monitoring in real-time the machines, predictive maintenance will 322 help to reduce the repairing cost as well as the downtime. Besides, 323 the attractions may use wireless transmissions to interconnect 324 sensors and actuators, to privilege reconfigurability, and 325 standardization. 327 Attractions may rely on a large set of sensors and actuators, which 328 react in real time. Typical applications comprise: 330 o Emergency: safety has to be preserved, and must stop the 331 attraction when a failure is detected. 333 o Video: augmented and virtual realities are integrated in the 334 attraction. Wearable devices (e.g., glasses, virtual reality 335 headset) need to offload one part of the processing tasks. 337 o Real-time interactions: visitors may interact with an attraction, 338 like in a real-time video game. The visitors may virtually 339 interact with their environment, triggering actions in the real 340 world (through actuators) [robots]. 342 o Geolocation: visitors are tracked with a personal wireless tag so 343 that their user experience is improved. 345 o Predictive maintenance: statistics are collected to predict the 346 future failures, or to compute later more complex statistics about 347 the attraction's usage, the downtime, its popularity, etc. 349 3.2. Specifics 351 Amusement parks comprise a variable number of attractions, mostly 352 outdoor, over a large geographical area. The IT infrastructure is 353 typically multi-scale: 355 o Local area: the sensors and actuators controlling the attractions 356 are co-located. Control loops trigger only local traffic, with a 357 small end-to-end delay, typically inferior than 10 milliseconds, 358 like classical industrial systems [ieee80211-rt-tig]. 360 o Wearable devices are free to move in the park. They exchange 361 traffic locally (identification, personalization, multimedia) or 362 globally (billing, child tracking). 364 o Computationally intensive applications offload some tasks to a 365 cloud, and data analytics rely on a centralized infrastructure 366 (predictive maintenance, marketing). 368 3.3. The Need for Wireless 370 Amusement parks cover large areas and a global interconnection would 371 require a huge length of cables. Wireless also increases the 372 reconfigurability, enabling to update cheaply the attractions. The 373 frequent renewal helps to increase customer loyalty. 375 Some parts of the attraction are mobile, e.g., trucks of a roller- 376 coaster, robots. Since cables are prone to frequent failures in this 377 situation, wireless transmissions are recommended. 379 Wearable devices are extensively used for a user experience 380 personalization. They typically need to support wireless 381 transmissions. Personal tags may help to reduce the operating costs 382 [disney-VIP] and to increase the number of charged services provided 383 to the audience (VIP tickets, interactivity, etc.) Some applications 384 rely on more sophisticated wearable devices such as digital glasses 385 or Virtual Reality (VR) headsets for an immersive experience. 387 3.4. Requirements for RAW 389 The network infrastructure has to support heterogeneous traffic, with 390 very different critical requirements. Thus, flow isolation has to be 391 provided. 393 We have to schedule appropriately the transmissions, even in presence 394 of mobile devices. While the [I-D.ietf-6tisch-architecture] already 395 proposes an architecture for synchronized, IEEE Std. 802.15.4 Time- 396 Slotted Channel Hopping (TSCH) networks, 6TiSCH does not address 397 real-time IPv6 flows. RAW might provide mechanisms helping to 398 automatically adapt the network (i.e., schedule appropriately the 399 transmissions, across heterogeneous technologies, with strict SLA 400 requirements). 402 Nowadays, long-range wireless transmissions are used for best-effort 403 traffic, and [IEEE802.1TSN] is used for critical flows using Ethernet 404 devices. However, we need an IP enabled technology to interconnect 405 large areas, independent of the PHY and MAC layer to maximize the 406 compliancy. 408 We expect to deploy several different technologies (long vs. short 409 range) which have to cohabit in the same area. Thus, we need to 410 schedule appropriately the transmissions to limit the co-technology 411 interference, so that an end-to-end delay across multiple 412 technologies can be guaranteed. It is needed to understand which 413 technologies RAW will cover and how they can be used cohabitating in 414 the same area. 416 4. Wireless for Industrial Applications 418 4.1. Use Case Description 420 A major use case for networking in Industrial environments is the 421 control networks where periodic control loops operate between a 422 sensor that measures a physical property such as the temperature of a 423 fluid, a Programmable Logic Controller (PLC) that decides an action 424 such as warm up the mix, and an actuator that performs the required 425 action, e.g., inject power in a resistor. 427 4.2. Specifics 429 4.2.1. Control Loops 431 Process Control designates continuous processing operations, e.g., 432 heating Oil in a refinery or mixing drinking soda. Control loops in 433 the Process Control industry operate at a very low rate, typically 4 434 times per second. Factory Automation, on the other hand, deal with 435 discrete goods such as individual automobile parts, and requires 436 faster loops, in the order of 10ms. Motion control that monitors 437 dynamic activities may require even faster rates in the order of a 438 few ms. Finally, some industries exhibit hybrid behaviors, like 439 canned soup that will start as a process industry while mixing the 440 food and then operate as a discrete manufacturing when putting the 441 final product in cans and shipping them. 443 In all those cases, a packet must flow reliably between the sensor 444 and the PLC, be processed by the PLC, and sent to the actuator within 445 the control loop period. In some particular use cases that inherit 446 from analog operations, jitter might also alter the operation of the 447 control loop. A rare packet loss is usually admissible, but 448 typically 4 losses in a row will cause an emergency halt of the 449 production and incur a high cost for the manufacturer. 451 4.2.2. Unmeasured Data 453 A secondary use case deals with monitoring and diagnostics. This so- 454 called unmeasured data is essential to improve the performances of a 455 production line, e.g., by optimizing real-time processing or 456 maintenance windows using Machine Learning predictions. For the lack 457 of wireless technologies, some specific industries such as Oil and 458 Gas have been using serial cables, literally by the millions, to 459 perform their process optimization over the previous decades. But 460 few industries would afford the associated cost and the Holy Grail of 461 the Industrial Internet of Things is to provide the same benefits to 462 all industries, including SmartGrid, Transportation, Building, 463 Commercial and Medical. This requires a cheap, available and 464 scalable IP-based access technology. 466 Inside the factory, wires may already be available to operate the 467 Control Network. But unmeasured data are not welcome in that network 468 for a number of reasons. On the one hand it is rich and 469 asynchronous, meaning that using they may influence the deterministic 470 nature of the control operations and impact the production. On the 471 other hand, this information must be reported to the carpeted floor 472 over IP, which means the potential for a security breach via the 473 interconnection of the Operational Technology (OT) network with the 474 Internet technology (IT) network and possibly enable a rogue access. 476 4.3. The Need for Wireless 478 Ethernet cables used on a robot arm are prone to breakage after a few 479 thousands flexions, a lot faster than a power cable that is wider inn 480 diameter, and more resilient. In general, wired networking and 481 mobile parts are not a good match, mostly in the case of fast and 482 recurrent activities, as well as rotation. 484 When refurbishing older premises that were built before the Internet 485 age, power is usually available everywhere, but data is not. It is 486 often impractical, time consuming and expensive to deploy an Ethernet 487 fabric across walls and between buildings. Deploying a wire may take 488 months and cost tens of thousands of US Dollars. 490 Even when wiring exists, e.g., in an existing control network, 491 asynchronous IP packets such as diagnostics may not be welcome for 492 operational and security reasons (see Section 4.2.1). An alternate 493 network that can scale with the many sensors and actuators that equip 494 every robot, every valve and fan that are deployed on the factory 495 floor and may help detect and prevent a failure that could impact the 496 production. IEEE Std. 802.15.4 Time-Slotted Channel Hopping (TSCH) 497 [RFC7554] is a promising technology for that purpose, mostly if the 498 scheduled operations enable to use the same network by asynchronous 499 and deterministic flows in parallel. 501 4.4. Requirements for RAW 503 As stated by the "Deterministic Networking Problem Statement" 504 [RFC8557], a Deterministic Network is backwards compatible with 505 (capable of transporting) statistically multiplexed traffic while 506 preserving the properties of the accepted deterministic flows. While 507 the [I-D.ietf-6tisch-architecture] serves that requirement, the work 508 at 6TiSCH was focused on best-effort IPv6 packet flows. RAW should 509 be able to lock so-called hard cells for use by a centralized 510 scheduler, and program so-called end-to-end Tracks over those cells. 512 Over the course of the recent years, major Industrial Protocols, 513 e.g., [ODVA] with EtherNet/IP [EIP] and [Profinet], have been 514 migrating towards Ethernet and IP. In order to unleash the full 515 power of the IP hourglass model, it should be possible to deploy any 516 application over any network that has the physical capacity to 517 transport the industrial flow, regardless of the MAC/PHY technology, 518 wired or wireless, and across technologies. RAW mechanisms should be 519 able to setup a Track over a wireless access segment such as TSCH and 520 a backbone segment such as Ethernet or WI-Fi, to report a sensor data 521 or a critical monitoring within a bounded latency. 523 5. Pro Audio and Video 525 5.1. Use Case Description 527 Many devices support audio and video streaming by employing 802.11 528 wireless LAN. Some of these applications require low latency 529 capability. For instance, when the application provides interactive 530 play, or when the audio takes plays in real time (i.e. live) for 531 public addresses in train stations or in theme parks. 533 The professional audio and video industry ("ProAV") includes: 535 o Virtual Reality / Augmented Reality (VR/AR) 537 o Public address, media and emergency systems at large venues 538 (airports, train stations, stadiums, theme parks). 540 5.2. Specifics 542 5.2.1. Uninterrupted Stream Playback 544 Considering the uninterrupted audio or video stream, a potential 545 packet losses during the transmission of audio or video flows cannot 546 be tackled by re-trying the transmission, as it is done with file 547 transfer, because by the time the packet lost has been identified it 548 is too late to proceed with packet re-transmission. Buffering might 549 be employed to provide a certain delay which will allow for one or 550 more re-transmissions, however such approach is not efficient in 551 application where delays are not acceptable. 553 5.2.2. Synchronized Stream Playback 555 In the context of ProAV, latency is the time between the transmitted 556 signal over a stream and its reception. Thus, for sound to remain 557 synchronized to the movement in the video, the latency of both the 558 audio and video streams must be bounded and consistent. 560 5.3. The Need for Wireless 562 The devices need the wireless communication to support video 563 streaming via 802.11 wireless LAN for instance. 565 During the public address, the deployed announcement speakers, for 566 instance along the platforms of the train stations, need the wireless 567 communication to forward the audio traffic in real time. 569 5.4. Requirements for RAW 571 The network infrastructure needs to support heterogeneous types of 572 traffic (including QoS). 574 Content delivery with bounded (lowest possible) latency. 576 The deployed network topology should allow for multipath. This will 577 enable for multiple streams to have different (and multiple) paths 578 through the network to support redundancy. 580 6. Wireless Gaming 582 6.1. Use Case Description 584 The gaming industry includes [IEEE80211RTA] real-time mobile gaming, 585 wireless console gaming and cloud gaming. For RAW, wireless console 586 gaming is the most relevant one. We next summarize the three: 588 o Real-time Mobile Gaming: Different from traditional games, real 589 time mobile gaming is very sensitive to network latency and 590 stability. The mobile game can connect multiple players together 591 in a single game session and exchange data messages between game 592 server and connected players. Real-time means the feedback should 593 present on screen as users operate in game. For good game 594 experience, the end to end latency plus game servers processing 595 time should not be noticed by users as they play the game. 597 o Wireless Console Gaming: Playing online on a console has 2 types 598 of internet connectivity, which is either wired or Wi-Fi. Most of 599 the gaming consoles today support Wi-Fi 5. But Wi-Fi has an 600 especially bad reputation among the gaming community. The main 601 reasons are high latency, lag spikes and jitter. 603 o Cloud Gaming: The cloud gaming requires low latency capability as 604 the user commands in a game session need to be sent back to the 605 cloud server, the cloud server would update game context depending 606 on the received commands, and the cloud server would render the 607 picture/video to be displayed at user devices and stream the 608 picture/video content to the user devices. User devices might 609 very likely be connected wirelessly. 611 6.2. Specifics 613 While a lot of details can be found on [IEEE80211RTA], we next 614 summarize the main requirements in terms of latency, jitter and 615 packet loss: 617 o Intra BSS latency: less than 5 ms. 619 o Jitter variance: less than 2 ms. 621 o Packet loss: less than 0.1 percent. 623 6.3. The Need for Wireless 625 It is clear that gaming is evolving towards wireless, as players 626 demand being able to play anywhere. Besides, the industry is 627 changing towards playing from mobile phones, which are inherently 628 connected via wireless technologies. 630 6.4. Requirements for RAW 632 o Time sensitive networking extensions. Extensions, such as time- 633 aware shaping and redundancy (FRE) can be explored to address 634 congestion and reliability problems present in wireless networks. 636 o Priority tagging (Stream identification). One basic requirement 637 to provide better QoS for time-sensitive traffic is the capability 638 to identify and differentiate time-sensitive packets from other 639 (e.g. best-effort) traffic. 641 o Time-aware shaping. This capability (defined in IEEE 802.1Qbv) 642 consists of gates to control the opening/closing of queues that 643 share a common egress port within an Ethernet switch. A scheduler 644 defines the times when each queue opens or close, therefore 645 eliminating congestion and ensuring that frames are delivered 646 within the expected latency bounds. 648 o Dual/multiple link. Due to the competitions and interference are 649 common and hardly in control under wireless network, in order to 650 improve the latency stability, dual/multiple link proposal is 651 brought up to address this issue. Two modes are defined: 652 duplicate and joint. 654 o Admission Control. Congestion is a major cause of high/variable 655 latency and it is well known that if the traffic load exceeds the 656 capability of the link, QoS will be degraded. QoS degradation 657 maybe acceptable for many applications today, however emerging 658 time-sensitive applications are highly susceptible to increased 659 latency and jitter. In order to better control QoS, it is 660 important to control access to the network resources. 662 7. UAV platooning and control 664 7.1. Use Case Description 666 Unmanned Aerial Vehicles (UAVs) are becoming very popular for many 667 different applications, including military and civil use cases. The 668 term drone is commonly used to refer to a UAV. 670 UAVs can be used to perform aerial surveillance activities, traffic 671 monitoring (e.g., Spanish traffic control has recently introduced a 672 fleet of drones for quicker reactions upon traffic congestion related 673 events), support of emergency situations, and even transportation of 674 small goods. 676 UAVs typically have various forms of wireless connectivity: 678 o cellular: for communication with the control center, for remote 679 maneuvering as well as monitoring of the drone; 681 o IEEE 802.11: for inter-drone communications (e.g., platooning) and 682 providing connectivity to other devices (e.g., acting as Access 683 Point). 685 7.2. Specifics 687 Some of the use cases/tasks involving drones require coordination 688 among drones. Others involve complex compute tasks that might not be 689 performed using the limited computing resources that a drone 690 typically has. These two aspects require continuous connectivity 691 with the control center and among drones. 693 Remote maneuvering of a drone might be performed over a cellular 694 network in some cased, however, there are situations that need very 695 low latencies and deterministic behavior of the connectivity. 696 Examples involve platooning of drones or share of computing resources 697 among drones (e.g., a drone offload some function to a neighboring 698 drone). 700 7.3. The Need for Wireless 702 UAVs cannot be connected through any type of wired media, so it is 703 obvious that wireless is needed. 705 7.4. Requirements for RAW 707 The network infrastructure is actually composed by the UAVs 708 themselves, requiring self-configuration capabilities. 710 Heterogeneous types of traffic need to be supported, from extremely 711 critical ones requiring ultra low latency and high resiliency, to 712 traffic requiring low-medium latency. 714 When a given service is decomposed into functions -- hosted at 715 different drones -- chained, each link connecting two given functions 716 would have a well-defined set of requirements (latency, bandwidth and 717 jitter) that have to be met. 719 8. Edge Robotics control 721 8.1. Use Case Description 723 The Edge Robotics scenario consists of several robots, deployed in a 724 given area (for example a shopping mall), inter-connected via an 725 access network to a network's edge device or a data center. The 726 robots are connected to the edge so complex computational activities 727 are not executed locally at the robots, but offloaded to the edge. 728 This brings additional flexibility in the type of tasks that the 729 robots do, as well as reducing the costs of robot manufacturing (due 730 to their lower complexity), and enabling complex tasks involving 731 coordination among robots (that can be more easily performed if 732 robots are centrally controlled). 734 A simple example of the use of multiples robots is cleaning, 735 delivering of goods from warehouses to shops or video surveillance. 736 Multiple robots are simultaneously instructed to perform individual 737 tasks by moving the robotic intelligence from the robots to the 738 network's edge (e.g., data center). That enables easy 739 synchronization, scalable solution and on-demand option to create 740 flexible fleet of robots. 742 Robots would have various forms of wireless connectivity: 744 o IEEE 802.11: for connection to the edge and also inter-robot 745 communications (e.g., for coordinated actions). 747 o Cellular: as an additional communication link to the edge, though 748 primarily as backup, since ultra low latencies are needed. 750 8.2. Specifics 752 Some of the use cases/tasks involving robots might benefit from 753 decomposition of a service in small functions that are distributed 754 and chained among robots and the edge. These require continuous 755 connectivity with the control center and among drones. 757 Robot control is an activity requiring very low latencies between the 758 robot and the location where the control intelligence resides (which 759 might be the edge or another robot). 761 8.3. The Need for Wireless 763 Deploying robots in scenarios such as shopping malls for the 764 aforementioned applications cannot be done via wired connectivity. 766 8.4. Requirements for RAW 768 The network infrastructure needs to support heterogeneous types of 769 traffic, from robot control to video streaming. 771 When a given service is decomposed into functions -- hosted at 772 different robots -- chained, each link connecting two given functions 773 would have a well-defined set of requirements (latency, bandwidth and 774 jitter) that have to be met. 776 9. IANA Considerations 778 N/A. 780 10. Security Considerations 782 N/A. 784 11. Acknowledgments 786 The work of Carlos J. Bernardos in this draft has been partially 787 supported by the H2020 5Growth (Grant 856709) and 5G-DIVE projects 788 (Grant 859881). 790 12. Informative References 792 [disney-VIP] 793 Wired, "Disney's $1 Billion Bet on a Magical Wristband", 794 March 2015, 795 . 797 [EIP] http://www.odva.org/, "EtherNet/IP provides users with the 798 network tools to deploy standard Ethernet technology (IEEE 799 802.3 combined with the TCP/IP Suite) for industrial 800 automation applications while enabling Internet and 801 enterprise connectivity data anytime, anywhere.", 802 . 806 [EURO20] EUROCONTROL, "EUROCONTROL's Challenges of Growth 2018 807 Study Report", 2018, . 811 [FAA20] U.S. Department of Transportation Federal Aviation 812 Administration (FAA), "Next Generation Air Transportation 813 System", 2019, . 815 [I-D.ietf-6tisch-architecture] 816 Thubert, P., "An Architecture for IPv6 over the TSCH mode 817 of IEEE 802.15.4", draft-ietf-6tisch-architecture-28 (work 818 in progress), October 2019. 820 [I-D.maeurer-raw-ldacs] 821 Maeurer, N., Graeupl, T., and C. Schmitt, "L-band Digital 822 Aeronautical Communications System (LDACS)", draft- 823 maeurer-raw-ldacs-01 (work in progress), March 2020. 825 [I-D.thubert-raw-technologies] 826 Thubert, P., Cavalcanti, D., Vilajosana, X., and C. 827 Schmitt, "Reliable and Available Wireless Technologies", 828 draft-thubert-raw-technologies-04 (work in progress), 829 January 2020. 831 [ICAO18] International Civil Aviation Organization (ICAO), "L-Band 832 Digital Aeronautical Communication System (LDACS)", 833 International Standards and Recommended Practices Annex 10 834 - Aeronautical Telecommunications, Vol. III - 835 Communication Systems , 2018. 837 [IEEE802.1TSN] 838 IEEE standard for Information Technology, "IEEE 839 802.1AS-2011 - IEEE Standard for Local and Metropolitan 840 Area Networks - Timing and Synchronization for Time- 841 Sensitive Applications in Bridged Local Area Networks". 843 [ieee80211-rt-tig] 844 IEEE, "IEEE 802.11 Real Time Applications TIG Report", 845 Nov. 2018, 846 . 848 [IEEE80211RTA] 849 IEEE standard for Information Technology, "IEEE 802.11 850 Real Time Applications TIG Report", Nov 2018. 852 [ISA100] ISA/ANSI, "ISA100, Wireless Systems for Automation", 853 . 855 [KEAV20] T. Keaveney and C. Stewart, "Single European Sky ATM 856 Research Joint Undertaking", 2019, 857 . 859 [ODVA] http://www.odva.org/, "The organization that supports 860 network technologies built on the Common Industrial 861 Protocol (CIP) including EtherNet/IP.". 863 [PLA14] Plass, S., Hermenier, R., Luecke, O., Gomez Depoorter, D., 864 Tordjman, T., Chatterton, M., Amirfeiz, M., Scotti, S., 865 Cheng, Y., Pillai, P., Graeupl, T., Durand, F., Murphy, 866 K., Marriott, A., and A. Zaytsev, "Flight Trial 867 Demonstration of Seamless Aeronautical Networking", IEEE 868 Communications Magazine, vol. 52, no. 5 , May 2014. 870 [Profinet] 871 http://us.profinet.com/technology/profinet/, "PROFINET is 872 a standard for industrial networking in automation.", 873 . 875 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 876 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 877 Internet of Things (IoT): Problem Statement", RFC 7554, 878 DOI 10.17487/RFC7554, May 2015, 879 . 881 [RFC8557] Finn, N. and P. Thubert, "Deterministic Networking Problem 882 Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019, 883 . 885 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 886 RFC 8578, DOI 10.17487/RFC8578, May 2019, 887 . 889 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 890 "Deterministic Networking Architecture", RFC 8655, 891 DOI 10.17487/RFC8655, October 2019, 892 . 894 [robots] Kober, J., Glisson, M., and M. Mistry, "Playing catch and 895 juggling with a humanoid robot.", 2012, 896 . 898 Authors' Addresses 900 Georgios Z. Papadopoulos 901 IMT Atlantique 902 Office B00 - 114A 903 2 Rue de la Chataigneraie 904 Cesson-Sevigne - Rennes 35510 905 FRANCE 907 Phone: +33 299 12 70 04 908 Email: georgios.papadopoulos@imt-atlantique.fr 910 Pascal Thubert 911 Cisco Systems, Inc 912 Building D 913 45 Allee des Ormes - BP1200 914 MOUGINS - Sophia Antipolis 06254 915 FRANCE 917 Phone: +33 497 23 26 34 918 Email: pthubert@cisco.com 920 Fabrice Theoleyre 921 CNRS 922 ICube Lab, Pole API 923 300 boulevard Sebastien Brant - CS 10413 924 Illkirch 67400 925 FRANCE 927 Phone: +33 368 85 45 33 928 Email: theoleyre@unistra.fr 929 URI: http://www.theoleyre.eu 930 Carlos J. Bernardos 931 Universidad Carlos III de Madrid 932 Av. Universidad, 30 933 Leganes, Madrid 28911 934 Spain 936 Phone: +34 91624 6236 937 Email: cjbc@it.uc3m.es 938 URI: http://www.it.uc3m.es/cjbc/