idnits 2.17.1 draft-ietf-raw-use-cases-05.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 (23 February 2022) is 786 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: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-raw-technologies-05 == Outdated reference: A later version (-14) exists of draft-ietf-raw-ldacs-09 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RAW CJ. Bernardos, Ed. 3 Internet-Draft UC3M 4 Intended status: Informational G.Z. Papadopoulos 5 Expires: 27 August 2022 IMT Atlantique 6 P. Thubert 7 Cisco 8 F. Theoleyre 9 CNRS 10 23 February 2022 12 RAW use-cases 13 draft-ietf-raw-use-cases-05 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 (such as aeronautical communications, 22 amusement parks, industrial applications, pro audio and video, 23 gaming, UAV and V2V control, edge robotics and emergency vehicles) 24 demanding reliable and available behavior. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 27 August 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Aeronautical Communications . . . . . . . . . . . . . . . . . 5 61 2.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 5 62 2.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.3. Challenges . . . . . . . . . . . . . . . . . . . . . . . 7 64 2.4. The Need for Wireless . . . . . . . . . . . . . . . . . . 8 65 2.5. Requirements for RAW . . . . . . . . . . . . . . . . . . 8 66 2.5.1. Non-latency critical considerations . . . . . . . . . 9 67 3. Amusement Parks . . . . . . . . . . . . . . . . . . . . . . . 9 68 3.1. use-case Description . . . . . . . . . . . . . . . . . . 9 69 3.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 9 70 3.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 10 71 3.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 10 72 3.4.1. Non-latency critical considerations . . . . . . . . . 11 73 4. Wireless for Industrial Applications . . . . . . . . . . . . 11 74 4.1. use-case Description . . . . . . . . . . . . . . . . . . 11 75 4.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 11 76 4.2.1. Control Loops . . . . . . . . . . . . . . . . . . . . 11 77 4.2.2. Unmeasured Data . . . . . . . . . . . . . . . . . . . 12 78 4.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 12 79 4.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 13 80 4.4.1. Non-latency critical considerations . . . . . . . . . 14 81 5. Pro Audio and Video . . . . . . . . . . . . . . . . . . . . . 14 82 5.1. use-case Description . . . . . . . . . . . . . . . . . . 14 83 5.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 14 84 5.2.1. Uninterrupted Stream Playback . . . . . . . . . . . . 14 85 5.2.2. Synchronized Stream Playback . . . . . . . . . . . . 14 86 5.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 15 87 5.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 15 88 5.4.1. Non-latency critical considerations . . . . . . . . . 15 89 6. Wireless Gaming . . . . . . . . . . . . . . . . . . . . . . . 15 90 6.1. use-case Description . . . . . . . . . . . . . . . . . . 15 91 6.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 16 92 6.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 16 93 6.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 16 94 6.4.1. Non-latency critical considerations . . . . . . . . . 17 96 7. Unmanned Aerial Vehicles and Vehicle-to-Vehicle platooning and 97 control . . . . . . . . . . . . . . . . . . . . . . . . . 17 98 7.1. use-case Description . . . . . . . . . . . . . . . . . . 17 99 7.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 18 100 7.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 18 101 7.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 18 102 7.4.1. Non-latency critical considerations . . . . . . . . . 19 103 8. Edge Robotics control . . . . . . . . . . . . . . . . . . . . 19 104 8.1. use-case Description . . . . . . . . . . . . . . . . . . 19 105 8.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 20 106 8.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 20 107 8.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 20 108 8.4.1. Non-latency critical considerations . . . . . . . . . 20 109 9. Emergencies: Instrumented emergency vehicle . . . . . . . . . 20 110 9.1. use-case Description . . . . . . . . . . . . . . . . . . 20 111 9.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 21 112 9.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 21 113 9.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 21 114 9.4.1. Non-latency critical considerations . . . . . . . . . 22 115 10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 116 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 117 12. Security Considerations . . . . . . . . . . . . . . . . . . . 22 118 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 119 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 120 14.1. Normative References . . . . . . . . . . . . . . . . . . 23 121 14.2. Informative References . . . . . . . . . . . . . . . . . 23 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 124 1. Introduction 126 Based on time, resource reservation, and policy enforcement by 127 distributed shapers, Deterministic Networking provides the capability 128 to carry specified unicast or multicast data streams for real-time 129 applications with extremely low data loss rates and bounded latency, 130 to support time-sensitive and mission-critical applications on a 131 converged enterprise infrastructure. 133 Deterministic Networking in the IP world is an attempt to eliminate 134 packet loss for a committed bandwidth while ensuring a worst case 135 end-to-end latency, regardless of the network conditions and across 136 technologies. By leveraging on lower (L2 and below) capabilities, L3 137 can exploit the use of a service layer, steering over multiple 138 technologies, and using media independent signaling to provide high 139 reliability, precise time delivery, and rate enforcement. 140 Deterministic networking can be seen as a set of new Quality of 141 Service (QoS) guarantees of worst-case delivery. IP networks become 142 more deterministic when the effects of statistical multiplexing 143 (jitter and collision loss) are mostly eliminated. This requires a 144 tight control of the physical resources to maintain the amount of 145 traffic within the physical capabilities of the underlying 146 technology, e.g., using time-shared resources (bandwidth and buffers) 147 per circuit, and/or by shaping and/or scheduling the packets at every 148 hop. 150 Key attributes of Deterministic Networking include: 152 * time synchronization on all the nodes, 154 * centralized computation of network-wide deterministic paths, 156 * multi-technology path with co-channel interference minimization, 158 * frame preemption and guard time mechanisms to ensure a worst-case 159 delay, and 161 * new traffic shapers within and at the edge to protect the network. 163 Wireless operates on a shared medium, and transmissions cannot be 164 guaranteed to be fully deterministic due to uncontrolled 165 interferences, including self-induced multipath fading. Reliable and 166 Available Wireless (RAW) is an effort to provide Deterministic 167 Networking Mechanisms on across a multi-hop path that includes a 168 wireless physical layer. Making Wireless Reliable and Available is 169 even more challenging than it is with wires, due to the numerous 170 causes of loss in transmission that add up to the congestion losses 171 and the delays caused by overbooked shared resources. 173 The wireless and wired media are fundamentally different at the 174 physical level, and while the generic Problem Statement [RFC8557] for 175 DetNet applies to the wired as well as the wireless medium, the 176 methods to achieve RAW necessarily differ from those used to support 177 Time-Sensitive Networking over wires, e.g., due to the wireless radio 178 channel specifics. 180 So far, Open Standards for Deterministic Networking have prevalently 181 been focused on wired media, with Audio/Video Bridging (AVB) and Time 182 Sensitive Networking (TSN) at the IEEE and DetNet [RFC8655] at the 183 IETF. But wires cannot be used in several cases, including mobile or 184 rotating devices, rehabilitated industrial buildings, wearable or in- 185 body sensory devices, vehicle automation and multiplayer gaming. 187 Purpose-built wireless technologies such as [ISA100], which 188 incorporates IPv6, were developed and deployed to cope for the lack 189 of open standards, but they yield a high cost in OPEX and CAPEX and 190 are limited to very few industries, e.g., process control, concert 191 instruments or racing. 193 This is now changing [I-D.ietf-raw-technologies]: 195 * IMT-2020 has recognized Ultra-Reliable Low-Latency Communication 196 (URLLC) as a key functionality for the upcoming 5G. 198 * IEEE 802.11 has identified a set of real-applications 199 [IEEE80211-RT-TIG] which may use the IEEE802.11 standards. They 200 typically emphasize strict end-to-end delay requirements. 202 * The IETF has produced an IPv6 stack for IEEE Std. 802.15.4 203 TimeSlotted Channel Hopping (TSCH) and an architecture [RFC9030] 204 that enables RAW on a shared MAC. 206 Experiments have already been conducted with IEEE802.1 TSN over 207 IEEE802.11be [IEEE80211BE]. This mode enables time synchronization, 208 and time-aware scheduling (trigger based access mode) to support TSN 209 flows. 211 This draft extends the "Deterministic Networking use-cases" document 212 [RFC8578] and describes several additional use-cases which require 213 "reliable/predictable and available" flows over wireless links and 214 possibly complex multi-hop paths called Tracks. This is covered 215 mainly by the "Wireless for Industrial Applications" use-case, as the 216 "Cellular Radio" is mostly dedicated to the (wired) transport part of 217 a Radio Access Network (RAN). Whereas the "Wireless for Industrial 218 Applications" use-case certainly covers an area of interest for RAW, 219 it is limited to 6TiSCH, and thus its scope is narrower than the use- 220 cases described next in this document. 222 2. Aeronautical Communications 224 Aircraft are currently connected to ATC (Air-Traffic Control) and AOC 225 (Airline Operational Control) via voice and data communications 226 systems through all phases of a flight. Within the airport terminal, 227 connectivity is focused on high bandwidth communications while during 228 en-route high reliability, robustness and range are the focus. 230 2.1. Problem Statement 232 Up to 2020, civil air traffic has been growing constantly at a 233 compound rate of 5.8% per year [ACI19] and despite the severe impact 234 of the COVID-19 pandemic, air traffic growth is expected to resume 235 very quickly in post-pandemic times [IAT20] [IAC20]. Thus, legacy 236 systems in air traffic management (ATM) are likely to reach their 237 capacity limits and the need for new aeronautical communication 238 technologies becomes apparent. Especially problematic is the 239 saturation of VHF band in high density areas in Europe, the US, and 240 Asia [KEAV20] [FAA20] calling for suitable new digital approaches 241 such as AeroMACS for airport communications, SatCOM for remote 242 domains, and LDACS as long-range terrestrial aeronautical 243 communications system. Making the frequency spectrum's usage more 244 efficient a transition from analog voice to digital data 245 communication [PLA14] is necessary to cope with the expected growth 246 of civil aviation and its supporting infrastructure. A promising 247 candidate for long range terrestrial communications, already in the 248 process of being standardized in the International Civil Aviation 249 Organization (ICAO), is the L-band Digital Aeronautical 250 Communications System (LDACS) [ICAO18] [I-D.ietf-raw-ldacs]. 252 2.2. Specifics 254 During the creation process of new communications system, analog 255 voice is replaced by digital data communication. This sets a 256 paradigm shift from analog to digital wireless communications and 257 supports the related trend towards increased autonomous data 258 processing that the Future Communications Infrastructure (FCI) in 259 civil aviation must provide. The FCI is depicted in Figure 1: 261 Satellite 262 # # 263 # # # 264 # # # 265 # # # 266 # # # 267 # # # 268 # # # 269 # Satellite-based # # 270 # Communications # # 271 # SatCOM (#) # # 272 # # Aircraft 273 # # % % 274 # # % % 275 # # % Air-Air % 276 # # % Communications % 277 # # % LDACS A/A (%) % 278 # # % % 279 # Aircraft % % % % % % % % % % Aircraft 280 # | Air-Ground | 281 # | Communications | 282 # | LDACS A/G (|) | 283 # Communications in | | 284 # and around airports | | 285 # AeroMACS (-) | | 286 # | | 287 # Aircraft-------------+ | | 288 # | | | 289 # | | | 290 # Ground network | | Ground network | 291 SatCOM <---------------------> Airport <----------------------> LDACS 292 transceiver based GS 293 transceiver 295 Figure 1: The Future Communication Infrastructure (FCI): AeroMACS 296 for APT/TMA domain, LDACS A/G for TMA/ENR domain, LDACS A/G for 297 ENR/ORP domain, SatCOM for ORP domain communications 299 2.3. Challenges 301 This paradigm change brings a lot of new challenges: 303 * Efficiency: It is necessary to keep latency, time and data 304 overhead (routing, security) of new aeronautical datalinks at a 305 minimum. 307 * Modularity: Systems in avionics usually operate up to 30 years, 308 thus solutions must be modular, easily adaptable and updatable. 310 * Interoperability: All 192 members of the international Civil 311 Aviation Organization (ICAO) must be able to use these solutions. 313 * Dynamicity: the communication infrastructure needs to accomodate 314 mobile devices (airplanes) that move extremely fast. 316 2.4. The Need for Wireless 318 In a high mobility environment such as aviation, the envisioned 319 solutions to provide worldwide coverage of data connections with in- 320 flight aircraft require a multi-system, multi-link, multi-hop 321 approach. Thus air, ground and space-based datalink providing 322 technologies will have to operate seamlessly together to cope with 323 the increasing needs of data exchange between aircraft, air traffic 324 controller, airport infrastructure, airlines, air network service 325 providers (ANSPs) and so forth. Thus, making use of wireless 326 technologies is a must in tackling this enormous need for a worldwide 327 digital aeronautical datalink infrastructure. 329 2.5. Requirements for RAW 331 Different safety levels need to be supported, from extremely safety 332 critical ones requiring low latency, such as a WAKE warning - a 333 warning that two aircraft come dangerously close to each other - and 334 high resiliency, to less safety critical ones requiring low-medium 335 latency for services such as WXGRAPH - graphical weather data. 337 Overhead needs to be kept at a minimum since aeronautical data links 338 provide comparatively small data rates in the order of kbit/s. 340 Policy needs to be supported when selecting data links. The focus of 341 RAW here should be on the selectors, responsible for the track a 342 packet takes to reach its end destination. This would minimize the 343 amount of routing information that must travel inside the network 344 because of precomputed routing tables with the selector being 345 responsible for choosing the most appropriate option according to 346 policy and safety. 348 2.5.1. Non-latency critical considerations 350 Achieving low latency is a requirement for aeronautics 351 communications, though the expected latency is not extremely low and 352 what it is important is to keep the overall latency bounded under a 353 certain threshold. This use-case is not latency-critical from that 354 view point. On the other hand, given the controlled environment, 355 end-to-end mechanisms can be applied to guarantee bounded latency 356 where needed. 358 3. Amusement Parks 360 3.1. use-case Description 362 The digitalization of Amusement Parks is expected to decrease 363 significantly the cost for maintaining the attractions. Such 364 deployment is a mix between industrial automation (i.e., Smart 365 Factories) and multimedia entertainment applications. 367 Attractions may rely on a large set of sensors and actuators, which 368 react in real time. Typical applications comprise: 370 * Emergency: safety has to be preserved, and must stop the 371 attraction when a failure is detected. 373 * Video: augmented and virtual realities are integrated in the 374 attraction. Wearable mobile devices (e.g., glasses, virtual 375 reality headset) need to offload one part of the processing tasks. 377 * Real-time interactions: visitors may interact with an attraction, 378 like in a real-time video game. The visitors may virtually 379 interact with their environment, triggering actions in the real 380 world (through actuators) [KOB12]. 382 * Geolocation: visitors are tracked with a personal wireless tag so 383 that their user experience is improved. 385 * Predictive maintenance: statistics are collected to predict the 386 future failures, or to compute later more complex statistics about 387 the attraction's usage, the downtime or its popularity for 388 example. 390 3.2. Specifics 392 Amusement parks comprise a variable number of attractions, mostly 393 outdoor, over a large geographical area. The IT infrastructure is 394 typically multi-scale: 396 * Local area: the sensors and actuators controlling the attractions 397 are co-located. Control loops trigger only local traffic, with a 398 small end-to-end delay, typically inferior to 10 ms, like 399 classical industrial systems [IEEE80211-RT-TIG]. 401 * Wearable mobile devices are free to move in the park. They 402 exchange traffic locally (identification, personalization, 403 multimedia) or globally (billing, child tracking). 405 * Computationally intensive applications offload some tasks. Edge 406 computing seems an efficient way to implement real-time 407 applications with offloading. Some non-time-critical tasks may 408 rather use the cloud (predictive maintenance, marketing). 410 3.3. The Need for Wireless 412 Amusement parks cover large areas, and a global interconnection would 413 require a huge length of cables. Wireless also increases the 414 reconfigurability, enabling to update an attraction at a lower cost. 415 The frequent renewal helps to increase the customer loyalty. 417 Some parts of the attraction are mobile, like trucks of a roller- 418 coaster or robots. Since cables are prone to frequent failures in 419 this situation, wireless transmissions are recommended. 421 Wearable devices are extensively used for a user experience 422 personalization. They typically need to support wireless 423 transmissions. Personal tags may help to reduce the operating costs 424 [DISNEY15] and to increase the number of charged services provided to 425 the audience (e.g., VIP tickets or interactivity). Some applications 426 rely on more sophisticated wearable devices such as digital glasses 427 or Virtual Reality (VR) headsets for an immersive experience. 429 3.4. Requirements for RAW 431 The network infrastructure must support heterogeneous traffic, with 432 very different critical requirements. Thus, flow isolation must be 433 provided. 435 The transmissions must be scheduled appropriately even in presence of 436 mobile devices. While the [RFC9030] already proposes an architecture 437 for synchronized, IEEE Std. 802.15.4 Time-Slotted Channel Hopping 438 (TSCH) networks, the industry requires a multi-technology solution, 439 able to guarantee end-to-end requirements across heterogeneous 440 technologies, with strict SLA requirements. 442 Nowadays, long-range wireless transmissions are used mostly for best- 443 effort traffic. On the contrary, [IEEE802.1TSN] is used for critical 444 flows using Ethernet devices. However, IP enabled technology is 445 required to interconnect large areas, independent of the PHY and MAC 446 layers. 448 It is expected that several different technologies (long vs. short 449 range) are deployed, which have to cohabit in the same area. Thus, 450 we need to provide layer-3 mechanisms able to exploit multiple co- 451 interfering technologies. 453 3.4.1. Non-latency critical considerations 455 While some of the applications in this use-case involve control loops 456 (e.g., sensors and actuators) that require bounded latencies below 10 457 ms, that can therefore be considered latency critical, there are 458 other applications as well that mostly demand reliability (e.g., 459 safety related, or maintenance). 461 4. Wireless for Industrial Applications 463 4.1. use-case Description 465 A major use-case for networking in Industrial environments is the 466 control networks where periodic control loops operate between a 467 collection of sensors that measure a physical property such as the 468 temperature of a fluid, a Programmable Logic Controller (PLC) that 469 decides an action such as warm up the mix, and actuators that perform 470 the required action, such as the injection of power in a resistor. 472 4.2. Specifics 474 4.2.1. Control Loops 476 Process Control designates continuous processing operations, like 477 heating Oil in a refinery or mixing drinking soda. Control loops in 478 the Process Control industry operate at a very low rate, typically 479 four times per second. Factory Automation, on the other hand, deals 480 with discrete goods such as individual automobile parts, and requires 481 faster loops, in the order of milliseconds. Motion control that 482 monitors dynamic activities may require even faster rates in the 483 order of and below the millisecond. Finally, some industries exhibit 484 hybrid behaviors, like canned soup that will start as a process 485 industry while mixing the food and then operate as a discrete 486 manufacturing when putting the final product in cans and shipping 487 them. 489 In all those cases, a packet must flow reliably between the sensor 490 and the PLC, be processed by the PLC, and sent to the actuator within 491 the control loop period. In some particular use-cases that inherit 492 from analog operations, jitter might also alter the operation of the 493 control loop. A rare packet loss is usually admissible, but 494 typically 4 losses in a row will cause an emergency halt of the 495 production and incur a high cost for the manufacturer. 497 Additional details and use-cases related to Industrial applications 498 and their RAW requirements can be found in 499 [I-D.ietf-raw-industrial-requirements]. 501 4.2.2. Unmeasured Data 503 A secondary use-case deals with monitoring and diagnostics. This so- 504 called unmeasured data is essential to improve the performances of a 505 production line, e.g., by optimizing real-time processing or 506 maintenance windows using Machine Learning predictions. For the lack 507 of wireless technologies, some specific industries such as Oil and 508 Gas have been using serial cables, literally by the millions, to 509 perform their process optimization over the previous decades. But 510 few industries would afford the associated cost and the Holy Grail of 511 the Industrial Internet of Things is to provide the same benefits to 512 all industries, including SmartGrid, Transportation, Building, 513 Commercial and Medical. This requires a cheap, available and 514 scalable IP-based access technology. 516 Inside the factory, wires may already be available to operate the 517 Control Network. But unmeasured data are not welcome in that network 518 for several reasons. On the one hand it is rich and asynchronous, 519 meaning that it may influence the deterministic nature of the control 520 operations and impact the production. On the other hand, this 521 information must be reported to the carpeted floor over IP, which 522 means the potential for a security breach via the interconnection of 523 the Operational Technology (OT) network with the Internet technology 524 (IT) network and possibly enable a rogue access. 526 4.3. The Need for Wireless 528 Ethernet cables used on a robot arm are prone to breakage after a few 529 thousands of flexions, a lot faster than a power cable that is wider 530 in diameter, and more resilient. In general, wired networking and 531 mobile parts are not a good match, mostly in the case of fast and 532 recurrent activities, as well as rotation. 534 When refurbishing older premises that were built before the Internet 535 age, power is usually available everywhere, but data is not. It is 536 often impractical, time consuming and expensive to deploy an Ethernet 537 fabric across walls and between buildings. Deploying a wire may take 538 months and cost tens of thousands of US Dollars. 540 Even when wiring exists, like in the case of an existing control 541 network, asynchronous IP packets such as diagnostics may not be 542 welcome for operational and security reasons. For those packets, the 543 option to create a parallel wireless network offers a credible 544 solution that can scale with the many sensors and actuators that 545 equip every robot, every valve and fan that are deployed on the 546 factory floor. It may also help detect and prevent a failure that 547 could impact the production, like the degradation (vibration) of a 548 cooling fan on the ceiling. IEEE Std. 802.15.4 Time-Slotted Channel 549 Hopping (TSCH) [RFC7554] is a promising technology for that purpose, 550 mostly if the scheduled operations enable to use the same network by 551 asynchronous and deterministic flows in parallel. 553 4.4. Requirements for RAW 555 As stated by the "Deterministic Networking Problem Statement" 556 [RFC8557], a Deterministic Network is backwards compatible with 557 (capable of transporting) statistically multiplexed traffic while 558 preserving the properties of the accepted deterministic flows. While 559 the 6TiSCH Architecture [RFC9030] serves that requirement, the work 560 at 6TiSCH was focused on best-effort IPv6 packet flows. RAW should 561 be able to lock so-called hard cells for use by a centralized 562 scheduler, and leverage time and spatial diversity over a graph of 563 end-to-end paths called a Track that is based on those cells. 565 Over the course of the recent years, major Industrial Protocols 566 (e.g., [ODVA] with EtherNet/IP [EIP] and [PROFINET]) have been 567 migrating towards Ethernet and IP. In order to unleash the full 568 power of the IP hourglass model, it should be possible to deploy any 569 application over any network that has the physical capacity to 570 transport the industrial flow, regardless of the MAC/PHY technology, 571 wired or wireless, and across technologies. RAW mechanisms should be 572 able to setup a Track over a wireless access segment and a wired or 573 wireless backbone to report both sensor data and critical monitoring 574 within a bounded latency and maintain the high reliability of teh 575 flows over time. It is also important to ensure that RAW solutions 576 are interoperable with existing wireless solutions in place, and with 577 legacy equipment which capabilities can be extended using 578 retrofitting. Maintainability, as a broader concept than reliability 579 is also important in industrial scenarios [MAR19]. 581 4.4.1. Non-latency critical considerations 583 Monitoring and diagnostics applications do not require latency 584 critical communications, but demand reliable and scalable 585 communications. On the other hand, process control applications 586 involve control loops that require a bounded latency, thus are 587 latency critical, but can be managed end-to-end, and therefore DetNet 588 mechanisms can be applied in conjunction with RAW mechanisms. 590 5. Pro Audio and Video 592 5.1. use-case Description 594 Many devices support audio and video streaming by employing 802.11 595 wireless LAN. Some of these applications require low latency 596 capability. For instance, when the application provides interactive 597 play, or when the audio plays in real time - meaning live for public 598 addresses in train stations or in theme parks. 600 The professional audio and video industry ("ProAV") includes: 602 * Virtual Reality / Augmented Reality (VR/AR) 604 * Production and post-production systems such as CD and Blue-Ray 605 disk mastering. 607 * Public address, media and emergency systems at large venues (e.g., 608 airports, train stations, stadiums, and theme parks). 610 5.2. Specifics 612 5.2.1. Uninterrupted Stream Playback 614 Considering the uninterrupted audio or video stream, a potential 615 packet loss during the transmission of audio or video flows cannot be 616 tackled by re-trying the transmission, as it is done with file 617 transfer, because by the time the packet lost has been identified it 618 is too late to proceed with packet re-transmission. Buffering might 619 be employed to provide a certain delay which will allow for one or 620 more re-transmissions, however such approach is not efficient in 621 application where delays are not acceptable. 623 5.2.2. Synchronized Stream Playback 625 In the context of ProAV, latency is the time between the transmitted 626 signal over a stream and its reception. Thus, for sound to remain 627 synchronized to the movement in the video, the latency of both the 628 audio and video streams must be bounded and consistent. 630 5.3. The Need for Wireless 632 The devices need the wireless communication to support video 633 streaming via IEEE 802.11 wireless LAN for instance. Wireless 634 communications provide huge advantages in terms of simpler 635 deployments in many scenarios, where the use of a wired alternative 636 would not be feasible. Similarly, in live events, mobility support 637 makes wireless communications the only viable approach. 639 Deployed announcement speakers, for instance along the platforms of 640 the train stations, need the wireless communication to forward the 641 audio traffic in real time. 643 5.4. Requirements for RAW 645 The network infrastructure needs to support heterogeneous types of 646 traffic (including QoS). 648 Content delivery with bounded (lowest possible) latency. 650 The deployed network topology should allow for multipath. This will 651 enable for multiple streams to have different (and multiple) paths 652 (tracks) through the network to support redundancy. 654 5.4.1. Non-latency critical considerations 656 For synchronized streaming, latency must be bounded, and therefore, 657 depending on the actual requirements, this can be considered as 658 latency critical. However, the most critical requirement of this 659 use-case is reliability, by the network providing redundancy. Note 660 that in many cases, wireless is only present in the access, where RAW 661 mechanisms could be applied, but other wired segments are also 662 involved (like the Internet), and therefore latency cannot be 663 guaranteed. 665 6. Wireless Gaming 667 6.1. use-case Description 669 The gaming industry includes [IEEE80211RTA] real-time mobile gaming, 670 wireless console gaming and cloud gaming. For RAW, wireless console 671 gaming is the most relevant one. We next summarize the three: 673 * Real-time Mobile Gaming: Different from traditional games, real 674 time mobile gaming is very sensitive to network latency and 675 stability. The mobile game can connect multiple players together 676 in a single game session and exchange data messages between game 677 server and connected players. Real-time means the feedback should 678 present on screen as users operate in game. For good game 679 experience, the end-to-end (E2E) latency plus game servers 680 processing time must be the same for all players and should not be 681 noticeable as the game is played. 683 * Wireless Console Gaming: Playing online on a console has 2 types 684 of internet connectivity, which is either wired or Wi-Fi. Most of 685 the gaming consoles today support Wi-Fi 5. But Wi-Fi has an 686 especially bad reputation among the gaming community. The main 687 reasons are high latency, lag spikes, and jitter. 689 * Cloud Gaming: The cloud gaming requires low latency capability as 690 the user commands in a game session need to be sent back to the 691 cloud server, the cloud server would update game context depending 692 on the received commands, and the cloud server would render the 693 picture/video to be displayed at user devices and stream the 694 picture/video content to the user devices. User devices might 695 very likely be connected wirelessly. 697 6.2. Specifics 699 While a lot of details can be found on [IEEE80211RTA], we next 700 summarize the main requirements in terms of latency, jitter and 701 packet loss: 703 * Intra BSS latency is less than 5 ms. 705 * Jitter variance is less than 2 ms. 707 * Packet loss is less than 0.1 percent. 709 6.3. The Need for Wireless 711 Gaming is evolving towards wireless, as players demand being able to 712 play anywhere, and the game requires a more immersive experience 713 including body movements. Besides, the industry is changing towards 714 playing from mobile phones, which are inherently connected via 715 wireless technologies. Wireless controllers are the rule in modern 716 gaming, with increasingly sophisticated interactions (e.g., haptic 717 feedback, augmented reality). 719 6.4. Requirements for RAW 721 * Time sensitive networking extensions: extensions, such as time- 722 aware shaping and redundancy (FRE) can be explored to address 723 congestion and reliability problems present in wireless networks. 725 * Priority tagging (Stream identification): one basic requirement to 726 provide better QoS for time-sensitive traffic is the capability to 727 identify and differentiate time-sensitive packets from other (like 728 best-effort) traffic. 730 * Time-aware shaping: this capability (defined in IEEE 802.1Qbv) 731 consists of gates to control the opening/closing of queues that 732 share a common egress port within an Ethernet switch. A scheduler 733 defines the times when each queue opens or close, therefore 734 eliminating congestion and ensuring that frames are delivered 735 within the expected latency bounds. Note thought, that while this 736 requirement needs to be signalled by RAW mechanisms, it would be 737 actually served by the lower layer. 739 * Dual/multiple link: due to the competitions and interference are 740 common and hardly in control under wireless network, to improve 741 the latency stability, dual/multiple link proposal is brought up 742 to address this issue. 744 * Admission Control: congestion is a major cause of high/variable 745 latency and it is well known that if the traffic load exceeds the 746 capability of the link, QoS will be degraded. QoS degradation 747 maybe acceptable for many applications today, however emerging 748 time-sensitive applications are highly susceptible to increased 749 latency and jitter. To better control QoS, it is important to 750 control access to the network resources. 752 6.4.1. Non-latency critical considerations 754 Depending on the actual scenario, and on use of Internet to 755 interconnect different users, the communication's requirements of 756 this use-case might be considered as latency critical due to the need 757 of bounded latency. But note that in most of these scenarios, part 758 of the communication path is not wireless and DetNet mechanisms 759 cannot be applied easily (e.g., when the public Internet is 760 involved), and therefore in these cases, reliability is the critical 761 requirement. 763 7. Unmanned Aerial Vehicles and Vehicle-to-Vehicle platooning and 764 control 766 7.1. use-case Description 768 Unmanned Aerial Vehicles (UAVs) are becoming very popular for many 769 different applications, including military and civil use-cases. The 770 term drone is commonly used to refer to a UAV. 772 UAVs can be used to perform aerial surveillance activities, traffic 773 monitoring (i.e., the Spanish traffic control has recently introduced 774 a fleet of drones for quicker reactions upon traffic congestion 775 related events), support of emergency situations, and even 776 transportation of small goods (e.g., medicine in rural areas). 778 Similarly to UAVs, other time of vehicles (such as cars) can also 779 travel in platoons. Most of the considerations made for UAVs in this 780 section apply to vehicle-to-vehicle (V2V) scenarios. 782 UAVs/vehicles typically have various forms of wireless connectivity: 784 * Cellular: for communication with the control center, for remote 785 maneuvering as well as monitoring of the drone; 787 * IEEE 802.11: for inter-drone communications (i.e., platooning) and 788 providing connectivity to other devices (i.e., acting as Access 789 Point). 791 Note that autonomous cars share many of the characteristics of the 792 aforemention UAV case, and therefore it is of interest for RAW. 794 7.2. Specifics 796 Some of the use-cases/tasks involving UAVs require coordination among 797 UAVs. Others involve complex compute tasks that might not be 798 performed using the limited computing resources that a drone 799 typically has. These two aspects require continuous connectivity 800 with the control center and among UAVs. 802 Remote maneuvering of a drone might be performed over a cellular 803 network in some cases, however, there are situations that need very 804 low latency and deterministic behavior of the connectivity. Examples 805 involve platooning of drones or share of computing resources among 806 drones (like, a drone offload some function to a neighboring drone). 808 7.3. The Need for Wireless 810 UAVs cannot be connected through any type of wired media, so it is 811 obvious that wireless is needed. 813 7.4. Requirements for RAW 815 The network infrastructure is composed by the UAVs themselves, 816 requiring self-configuration capabilities. 818 Heterogeneous types of traffic need to be supported, from extremely 819 critical ones requiring ultra-low latency and high resiliency, to 820 traffic requiring low-medium latency. 822 When a given service is decomposed into functions -- hosted at 823 different UAVs -- chained, each link connecting two given functions 824 would have a well-defined set of requirements (e.g., latency, 825 bandwidth and jitter) that must be met. 827 7.4.1. Non-latency critical considerations 829 Today's solutions keep local the processing operations that are 830 critical and would demand an ultra-low latency communication to be 831 offloaded. Therefore, in this use-case, the critical requirement is 832 reliability, and only for some platooning and inter-drone 833 communications latency is critical. 835 8. Edge Robotics control 837 8.1. use-case Description 839 The Edge Robotics scenario consists of several robots, deployed in a 840 given area (like a shopping mall), inter-connected via an access 841 network to a network's edge device or a data center. The robots are 842 connected to the edge so complex computational activities are not 843 executed locally at the robots but offloaded to the edge. This 844 brings additional flexibility in the type of tasks that the robots 845 do, as well as reducing the costs of robot manufacturing (due to 846 their lower complexity), and enabling complex tasks involving 847 coordination among robots (that can be more easily performed if 848 robots are centrally controlled). 850 Simple examples of the use of multiples robots are cleaning, video 851 surveillance, search and rescue operations, and delivering of goods 852 from warehouses to shops. Multiple robots are simultaneously 853 instructed to perform individual tasks by moving the robotic 854 intelligence from the robots to the network's edge (like a data 855 center). That enables easy synchronization, scalable solution, and 856 on-demand option to create flexible fleet of robots. 858 Robots would have various forms of wireless connectivity: 860 * IEEE 802.11: for connection to the edge and also inter-robot 861 communications (i.e., for coordinated actions). 863 * Cellular: as an additional communication link to the edge, though 864 primarily as backup, since ultra-low latency is needed. 866 8.2. Specifics 868 Some of the use-cases/tasks involving robots might benefit from 869 decomposition of a service in small functions that are distributed 870 and chained among robots and the edge. These require continuous 871 connectivity with the control center and among drones. 873 Robot control is an activity requiring very low latency between the 874 robot and the location where the control intelligence resides (which 875 might be the edge or another robot). 877 8.3. The Need for Wireless 879 Deploying robots in scenarios such as shopping malls for the 880 applications mentioned cannot be done via wired connectivity. 882 8.4. Requirements for RAW 884 The network infrastructure needs to support heterogeneous types of 885 traffic, from robot control to video streaming. 887 When a given service is decomposed into functions -- hosted at 888 different robots -- chained, each link connecting two given functions 889 would have a well-defined set of requirements (latency, bandwidth and 890 jitter) that must be met. 892 8.4.1. Non-latency critical considerations 894 This use-case might combine multiple communication flows, with some 895 of them being latency critical (like those related to robot control 896 tasks). Note that there are still many communication flows (like 897 some offloading tasks) that only demand reliability and availability. 899 9. Emergencies: Instrumented emergency vehicle 901 9.1. use-case Description 903 An instrumented ambulance would be one that has a LAN to which are 904 connected these end systems such as: 906 * vital signs sensors attached to the casualty in the ambulance. 907 Relay medical data to hospital emergency room, 909 * radio-navigation sensor to relay position data to various 910 destinations including dispatcher, 912 * voice communication for ambulance attendant (like to consult with 913 ER doctor), and 915 * voice communication between driver and dispatcher. 917 The LAN needs to be routed through radio-WANs to complete the inter- 918 network linkage. 920 9.2. Specifics 922 What we have today is multiple communications systems to reach the 923 vehicle via: 925 * A dispatching system, 927 * a cellphone for the attendant, 929 * a special purpose telemetering system for medical data, 931 * etc. 933 This redundancy of systems, because of its stove-piping, does not 934 contribute to availability. 936 Most of the scenarios involving the use of an instrumented ambulance 937 are composed of many different flows, each of them with slightly 938 different requirements in terms of reliability and latency. 939 Destinations might be either at the ambulance itself (local traffic), 940 at a near edge cloud or at the general Internet/cloud. 942 9.3. The Need for Wireless 944 Local traffic between the first responders/ambulance staff and the 945 ambulance equipment cannot be done via wired connectivity as the 946 responders perform initial treatment outside of the ambulance. The 947 communications from the ambulance to external services must be 948 wireless as well. 950 9.4. Requirements for RAW 952 We can derive some pertinent requirements from this scenario: 954 * High availability of the inter-network is required. 956 * The inter-network needs to operate in damaged state (e.g. during 957 an earthquake aftermath, heavy weather, wildfire, etc.). In 958 addition to continuity of operations, rapid restore is a needed 959 characteristic. 961 * E2E security, both authenticity and confidentiality, is required 962 of traffic. All data needs to be authenticated; some like medical 963 needs to be confidential. 965 * The radio-WAN has characteristics similar to cellphone -- the 966 vehicle will travel from one radio footprint to another. 968 9.4.1. Non-latency critical considerations 970 In this case, all applications identified do not require latency 971 critical communication, but do need of high reliability and 972 availability. 974 10. Summary 976 This document enumerates several use-cases and applications that need 977 RAW technologies, focusing on the requirements from reliability, 978 availability and latency. Whereas some use-cases are latency- 979 critical, there are also several applications that are non-latency 980 critical, but that do pose strict reliability and availability 981 requirements. Future revisions of this document will include 982 specific text devoted to highlight this non-latency critical 983 requirements. 985 11. IANA Considerations 987 This document has no IANA actions. 989 12. Security Considerations 991 This document covers several representative applications and network 992 scenarios that are expected to make use of RAW technologies. Each of 993 the potential RAW use-cases will have security considerations from 994 both the use-specific perspective and the RAW technology perspective. 995 [RFC9055] provides a comprehensive discussion of security 996 considerations in the context of Deterministic Networking, which are 997 generally applicable also to RAW. 999 13. Acknowledgments 1001 Nils Maeurer, Thomas Graeupl and Corinna Schmitt have contributed 1002 significantly to this document, providing input for the Aeronautical 1003 communications section. Rex Buddenberg has also contributed to the 1004 document, providing input to the Emergency: instrumented emergency 1005 vehicle section. 1007 The authors would like to thank Toerless Eckert, Xavi Vilajosana 1008 Guillen, Rute Sofia and Corinna Schmitt for their valuable comments 1009 on previous versions of this document. 1011 The work of Carlos J. Bernardos in this draft has been partially 1012 supported by the H2020 5Growth (Grant 856709) and 5G-DIVE projects 1013 (Grant 859881), and UNICO 5G I+D 6G-DATADRIVEN-04 project. 1015 14. References 1017 14.1. Normative References 1019 [I-D.ietf-raw-technologies] 1020 Thubert, P., Cavalcanti, D., Vilajosana, X., Schmitt, C., 1021 and J. Farkas, "Reliable and Available Wireless 1022 Technologies", Work in Progress, Internet-Draft, draft- 1023 ietf-raw-technologies-05, 2 February 2022, 1024 . 1027 14.2. Informative References 1029 [ACI19] Airports Council International (ACI), "Annual World 1030 Aitport Traffic Report 2019", November 2019, 1031 . 1034 [DISNEY15] Wired, "Disney's $1 Billion Bet on a Magical Wristband", 1035 March 2015, 1036 . 1038 [EIP] http://www.odva.org/, "EtherNet/IP provides users with the 1039 network tools to deploy standard Ethernet technology (IEEE 1040 802.3 combined with the TCP/IP Suite) for industrial 1041 automation applications while enabling Internet and 1042 enterprise connectivity data anytime, anywhere.", 1043 . 1047 [FAA20] U.S. Department of Transportation Federal Aviation 1048 Administration (FAA), "Next Generation Air Transportation 1049 System", 2019, . 1051 [I-D.ietf-raw-industrial-requirements] 1052 Sofia, R. C., Kovatsch, M., and P. M. Mendes, 1053 "Requirements for Reliable Wireless Industrial Services", 1054 Work in Progress, Internet-Draft, draft-ietf-raw- 1055 industrial-requirements-00, 10 December 2021, 1056 . 1059 [I-D.ietf-raw-ldacs] 1060 Maeurer, N., Graeupl, T., and C. Schmitt, "L-band Digital 1061 Aeronautical Communications System (LDACS)", Work in 1062 Progress, Internet-Draft, draft-ietf-raw-ldacs-09, 22 1063 October 2021, . 1066 [IAC20] Iacus, S.M., Natale, F., Santamaria, C., Spyratos, S., and 1067 V. Michele, "Estimating and projecting air passenger 1068 traffic during the COVID-19 coronavirus outbreak and its 1069 socio- economic impact", Safety Science 129 (2020) 1070 104791 , 2020. 1072 [IAT20] International Air Transport Association (IATA), "Economic 1073 Performance of the Airline Industry", November 2020, 1074 . 1078 [ICAO18] International Civil Aviation Organization (ICAO), "L-Band 1079 Digital Aeronautical Communication System (LDACS)", 1080 International Standards and Recommended Practices Annex 10 1081 - Aeronautical Telecommunications, Vol. III - 1082 Communication Systems , 2018. 1084 [IEEE802.1TSN] 1085 IEEE standard for Information Technology, "IEEE 1086 802.1AS-2011 - IEEE Standard for Local and Metropolitan 1087 Area Networks - Timing and Synchronization for Time- 1088 Sensitive Applications in Bridged Local Area Networks". 1090 [IEEE80211-RT-TIG] 1091 IEEE, "IEEE 802.11 Real Time Applications TIG Report", 1092 November 2018, 1093 . 1095 [IEEE80211BE] 1096 Cavalcanti, D. and G. Venkatesan, "802.1 TSN over 802.11 1097 with updates from developments in 802.11be", IEEE plenary 1098 meeting , November 2020, 1099 . 1102 [IEEE80211RTA] 1103 IEEE standard for Information Technology, "IEEE 802.11 1104 Real Time Applications TIG Report", November 2018. 1106 [ISA100] ISA/ANSI, "ISA100, Wireless Systems for Automation", 1107 . 1109 [KEAV20] T. Keaveney and C. Stewart, "Single European Sky ATM 1110 Research Joint Undertaking", 2019, 1111 . 1113 [KOB12] Kober, J., Glisson, M., and M. Mistry, "Playing catch and 1114 juggling with a humanoid robot.", 2012, 1115 . 1117 [MAR19] Martinez, B., Cano, C., and X. Vilajosana, "A Square Peg 1118 in a Round Hole: The Complex Path for Wireless in the 1119 Manufacturing Industry", 2019, 1120 . 1122 [ODVA] http://www.odva.org/, "The organization that supports 1123 network technologies built on the Common Industrial 1124 Protocol (CIP) including EtherNet/IP.". 1126 [PLA14] Plass, S., Hermenier, R., Luecke, O., Gomez Depoorter, D., 1127 Tordjman, T., Chatterton, M., Amirfeiz, M., Scotti, S., 1128 Cheng, Y.J., Pillai, P., Graeupl, T., Durand, F., Murphy, 1129 K., Marriott, A., and A. Zaytsev, "Flight Trial 1130 Demonstration of Seamless Aeronautical Networking", IEEE 1131 Communications Magazine, vol. 52, no. 5 , May 2014. 1133 [PROFINET] http://us.profinet.com/technology/profinet/, "PROFINET is 1134 a standard for industrial networking in automation.", 1135 . 1137 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 1138 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 1139 Internet of Things (IoT): Problem Statement", RFC 7554, 1140 DOI 10.17487/RFC7554, May 2015, 1141 . 1143 [RFC8557] Finn, N. and P. Thubert, "Deterministic Networking Problem 1144 Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019, 1145 . 1147 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 1148 RFC 8578, DOI 10.17487/RFC8578, May 2019, 1149 . 1151 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 1152 "Deterministic Networking Architecture", RFC 8655, 1153 DOI 10.17487/RFC8655, October 2019, 1154 . 1156 [RFC9030] Thubert, P., Ed., "An Architecture for IPv6 over the Time- 1157 Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", 1158 RFC 9030, DOI 10.17487/RFC9030, May 2021, 1159 . 1161 [RFC9055] Grossman, E., Ed., Mizrahi, T., and A. Hacker, 1162 "Deterministic Networking (DetNet) Security 1163 Considerations", RFC 9055, DOI 10.17487/RFC9055, June 1164 2021, . 1166 Authors' Addresses 1168 Carlos J. Bernardos (editor) 1169 Universidad Carlos III de Madrid 1170 Av. Universidad, 30 1171 28911 Leganes, Madrid 1172 Spain 1173 Phone: +34 91624 6236 1174 Email: cjbc@it.uc3m.es 1175 URI: http://www.it.uc3m.es/cjbc/ 1177 Georgios Z. Papadopoulos 1178 IMT Atlantique 1179 Office B00 - 114A 1180 2 Rue de la Chataigneraie 1181 35510 Cesson-Sevigne - Rennes 1182 France 1183 Phone: +33 299 12 70 04 1184 Email: georgios.papadopoulos@imt-atlantique.fr 1186 Pascal Thubert 1187 Cisco Systems, Inc 1188 Building D 1189 45 Allee des Ormes - BP1200 1190 06254 MOUGINS - Sophia Antipolis 1191 France 1192 Phone: +33 497 23 26 34 1193 Email: pthubert@cisco.com 1194 Fabrice Theoleyre 1195 CNRS 1196 ICube Lab, Pole API 1197 300 boulevard Sebastien Brant - CS 10413 1198 67400 Illkirch 1199 France 1200 Phone: +33 368 85 45 33 1201 Email: fabrice.theoleyre@cnrs.fr 1202 URI: https://fabrice.theoleyre.cnrs.fr/