diff options
Diffstat (limited to 'doc/rfc/rfc9450.txt')
| -rw-r--r-- | doc/rfc/rfc9450.txt | 1340 |
1 files changed, 1340 insertions, 0 deletions
diff --git a/doc/rfc/rfc9450.txt b/doc/rfc/rfc9450.txt new file mode 100644 index 0000000..d1f0f1e --- /dev/null +++ b/doc/rfc/rfc9450.txt @@ -0,0 +1,1340 @@ + + + + +Internet Engineering Task Force (IETF) CJ. Bernardos, Ed. +Request for Comments: 9450 UC3M +Category: Informational G. Papadopoulos +ISSN: 2070-1721 IMT Atlantique + P. Thubert + Cisco + F. Theoleyre + CNRS + August 2023 + + + Reliable and Available Wireless (RAW) Use Cases + +Abstract + + The wireless medium presents significant specific challenges to + achieve properties similar to those of wired deterministic networks. + At the same time, a number of use cases cannot be solved with wires + and justify the extra effort of going wireless. This document + presents wireless use cases (such as aeronautical communications, + amusement parks, industrial applications, pro audio and video, + gaming, Unmanned Aerial Vehicle (UAV) and vehicle-to-vehicle (V2V) + control, edge robotics, and emergency vehicles), demanding reliable + and available behavior. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are candidates for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9450. + +Copyright Notice + + Copyright (c) 2023 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Revised BSD License text as described in Section 4.e of the + Trust Legal Provisions and are provided without warranty as described + in the Revised BSD License. + +Table of Contents + + 1. Introduction + 2. Aeronautical Communications + 2.1. Problem Statement + 2.2. Specifics + 2.3. Challenges + 2.4. The Need for Wireless + 2.5. Requirements for RAW + 2.5.1. Non-latency-critical Considerations + 3. Amusement Parks + 3.1. Use Case Description + 3.2. Specifics + 3.3. The Need for Wireless + 3.4. Requirements for RAW + 3.4.1. Non-latency-critical Considerations + 4. Wireless for Industrial Applications + 4.1. Use Case Description + 4.2. Specifics + 4.2.1. Control Loops + 4.2.2. Monitoring and Diagnostics + 4.3. The Need for Wireless + 4.4. Requirements for RAW + 4.4.1. Non-latency-critical Considerations + 5. Professional Audio and Video + 5.1. Use Case Description + 5.2. Specifics + 5.2.1. Uninterrupted Stream Playback + 5.2.2. Synchronized Stream Playback + 5.3. The Need for Wireless + 5.4. Requirements for RAW + 5.4.1. Non-latency-critical Considerations + 6. Wireless Gaming + 6.1. Use Case Description + 6.2. Specifics + 6.3. The Need for Wireless + 6.4. Requirements for RAW + 6.4.1. Non-latency-critical Considerations + 7. Unmanned Aerial Vehicles and Vehicle-to-Vehicle Platooning and + Control + 7.1. Use Case Description + 7.2. Specifics + 7.3. The Need for Wireless + 7.4. Requirements for RAW + 7.4.1. Non-latency-critical Considerations + 8. Edge Robotics Control + 8.1. Use Case Description + 8.2. Specifics + 8.3. The Need for Wireless + 8.4. Requirements for RAW + 8.4.1. Non-latency-critical Considerations + 9. Instrumented Emergency Medical Vehicles + 9.1. Use Case Description + 9.2. Specifics + 9.3. The Need for Wireless + 9.4. Requirements for RAW + 9.4.1. Non-latency-critical Considerations + 10. Summary + 11. IANA Considerations + 12. Security Considerations + 13. Informative References + Acknowledgments + Authors' Addresses + +1. Introduction + + Based on time, resource reservation, and policy enforcement by + distributed shapers [RFC2475], Deterministic Networking (DetNet) + provides the capability to carry specified unicast or multicast data + streams for real-time applications with extremely low data loss rates + and bounded latency so as to support time-sensitive and mission- + critical applications on a converged enterprise infrastructure. + + DetNet aims at eliminating packet loss for a committed bandwidth, + while ensuring a worst-case end-to-end latency, regardless of the + network conditions and across technologies. By leveraging lower + layer (Layer 2 (L2) and below) capabilities, Layer 3 (L3) can exploit + the use of a service layer, steering over multiple technologies and + using media independent signaling to provide high reliability, + precise time delivery, and rate enforcement. DetNet can be seen as a + set of new Quality of Service (QoS) guarantees of worst-case + delivery. IP networks become more deterministic when the effects of + statistical multiplexing (jitter and collision loss) are mostly + eliminated. This requires a tight control of the physical resources + to maintain the amount of traffic within the physical capabilities of + the underlying technology, e.g., by using time-shared resources + (bandwidth and buffers) per circuit, by shaping or scheduling the + packets at every hop, or by using a combination of these techniques. + + Key attributes of DetNet include: + + * time synchronization on all the nodes, + + * multi-technology path with co-channel interference minimization, + + * frame preemption and guard time mechanisms to ensure a worst-case + delay, and + + * new traffic shapers, both within and at the edge, to protect the + network. + + Wireless operates on a shared medium, and transmissions cannot be + guaranteed to be fully deterministic due to uncontrolled + interferences, including self-induced multipath fading. The term RAW + stands for "Reliable and Available Wireless" and refers to the + mechanisms aimed for providing high reliability and availability for + IP connectivity over a wireless medium. Making wireless reliable and + available is even more challenging than it is with wires, due to the + numerous causes of loss in transmission that add up to the congestion + losses and due to the delays caused by overbooked shared resources. + + The wireless and wired media are fundamentally different at the + physical level. While the generic Problem Statement in [RFC8557] for + DetNet applies to the wired as well as the wireless medium, the + methods to achieve RAW necessarily differ from those used to support + Time-Sensitive Networking over wires, e.g., due to the wireless radio + channel specifics. + + So far, open standards for DetNet have prevalently been focused on + wired media, with Audio Video Bridging (AVB) and Time-Sensitive + Networking (TSN) at the IEEE and DetNet [RFC8655] at the IETF. + However, wires cannot be used in several cases, including mobile or + rotating devices, rehabilitated industrial buildings, wearable or in- + body sensory devices, vehicle automation, and multiplayer gaming. + + Purpose-built wireless technologies such as [ISA100], which + incorporates IPv6, were developed and deployed to cope with the lack + of open standards, but they yield a high cost in Operational + Expenditure (OPEX) and Capital Expenditure (CAPEX) and are limited to + very few industries, e.g., process control, concert instruments, or + racing. + + This is now changing (as detailed in [RAW-TECHNOS]): + + * IMT-2020 has recognized Ultra-Reliable Low Latency Communication + (URLLC) as a key functionality for the upcoming 5G. + + * IEEE 802.11 has identified a set of real applications + [IEEE80211RTA], which may use the IEEE802.11 standards. They + typically emphasize strict end-to-end delay requirements. + + * The IETF has produced an IPv6 stack for IEEE Std. 802.15.4 Time- + Slotted Channel Hopping (TSCH) and an architecture [RFC9030] that + enables RAW on a shared MAC. + + Experiments have already been conducted with IEEE802.1 TSN over + IEEE802.11be [IEEE80211BE]. This mode enables time synchronization + and time-aware scheduling (trigger based access mode) to support TSN + flows. + + This document extends the "Deterministic Networking Use Cases" + document [RFC8578] and describes several additional use cases that + require "reliable/predictable and available" flows over wireless + links and possibly complex multi-hop paths called "Tracks". This is + covered mainly by the "Wireless for Industrial Applications" + (Section 5 of [RFC8578]) use case, as the "Cellular Radio" (Section 6 + of [RFC8578]) is mostly dedicated to the (wired) link part of a Radio + Access Network (RAN). Whereas, while the "Wireless for Industrial + Applications" use case certainly covers an area of interest for RAW, + it is limited to IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH), + and thus, its scope is narrower than the use cases described next in + this document. + +2. Aeronautical Communications + + Aircraft are currently connected to Air-Traffic Control (ATC) and + Airline Operational Control (AOC) via voice and data communication + systems through all phases of a flight. Within the airport terminal, + connectivity is focused on high-bandwidth communications, whereas en + route it's focused on high reliability, robustness, and range. + +2.1. Problem Statement + + Up to 2020, civil air traffic had been growing constantly at a + compound rate of 5.8% per year [ACI19], and despite the severe impact + of the COVID-19 pandemic, air-traffic growth is expected to resume + very quickly in post-pandemic times [IAT20] [IAC20]. Thus, legacy + systems in Air-Traffic Management (ATM) are likely to reach their + capacity limits, and the need for new aeronautical communication + technologies becomes apparent. Especially problematic is the + saturation of VHF band in high density areas in Europe, the US, and + Asia [SESAR] [FAA20], calling for suitable new digital approaches + such as the Aeronautical Mobile Airport Communications System + (AeroMACS) for airport communications, SatCOM for remote domains, and + the L-band Digital Aeronautical Communication System (LDACS) as the + long-range terrestrial aeronautical communication system. Making the + frequency spectrum's usage a more efficient transition from analog + voice to digital data communication [PLA14] is necessary to cope with + the expected growth of civil aviation and its supporting + infrastructure. A promising candidate for long-range terrestrial + communications, already in the process of being standardized in the + International Civil Aviation Organization (ICAO), is LDACS [ICAO2022] + [RFC9372]. + + Note that the large scale of the planned Low Earth Orbit (LEO) + constellations of satellites can provide fast end-to-end latency + rates and high data-rates at a reasonable cost, but they also pose + challenges, such as frequent handovers, high interference, and a + diverse range of system users, which can create security issues since + both safety-critical and not safety-critical communications can take + place on the same system. Some studies suggest that LEO + constellations could be a complete solution for aeronautical + communications, but they do not offer solutions for the critical + issues mentioned earlier. Additionally, of the three communication + domains defined by ICAO, only passenger entertainment services can + currently be provided using these constellations. Safety-critical + aeronautical communications require reliability levels above 99.999%, + which is higher than that required for regular commercial data links. + Therefore, addressing the issues with LEO-based SatCOM is necessary + before these solutions can reliably support safety-critical data + transmission [Maurer2022]. + +2.2. Specifics + + During the creation process of a new communication system, analog + voice is replaced by digital data communication. This sets a + paradigm shift from analog to digital wireless communications and + supports the related trend towards increased autonomous data + processing that the Future Communications Infrastructure (FCI) in + civil aviation must provide. The FCI is depicted in Figure 1: + + Satellite + # # + # # # + # # # + # # # + # # # + # # # + # # # + # Satellite-based # # + # Communications # # + # SatCOM (#) # # + # # Aircraft + # # % % + # # % % + # # % Air-Air % + # # % Communications % + # # % LDACS A/A (%) % + # # % % + # Aircraft % % % % % % % % % % Aircraft + # | Air-Ground | + # | Communications | + # | LDACS A/G (|) | + # Communications in | | + # and around airports | | + # AeroMACS (-) | | + # | | + # Aircraft-------------+ | | + # | | | + # | | | + # Ground network | | Ground network | + SatCOM <---------------------> Airport <----------------------> LDACS + ground ground ground + transceiver transceiver transceiver + + Figure 1: The Future Communication Infrastructure (FCI) + + FCI includes: + + * AeroMACS for airport and terminal maneuvering area domains, + * LDACS Air/Ground for terminal maneuvering area and en route + domains, + * LDACS Air/Ground for en route or oceanic, remote, and polar + regions, and + * SatCOM for oceanic, remote, and polar regions. + +2.3. Challenges + + This paradigm change brings a lot of new challenges: + + * Efficiency: It is necessary to keep latency, time, and data + overhead of new aeronautical data links to a minimum. + + * Modularity: Systems in avionics usually operate for up to 30 + years. Thus, solutions must be modular, easily adaptable, and + updatable. + + * Interoperability: All 192 members of the ICAO must be able to use + these solutions. + + * Dynamicity: The communication infrastructure needs to accommodate + mobile devices (airplanes) that move extremely fast. + +2.4. The Need for Wireless + + In a high-mobility environment, such as aviation, the envisioned + solutions to provide worldwide coverage of data connections with in- + flight aircraft require a multi-system, multi-link, multi-hop + approach. Thus, air, ground, and space-based data links that provide + these technologies will have to operate seamlessly together to cope + with the increasing needs of data exchange between aircraft, air- + traffic controller, airport infrastructure, airlines, air network + service providers (ANSPs), and so forth. Wireless technologies have + to be used to tackle this enormous need for a worldwide digital + aeronautical data link infrastructure. + +2.5. Requirements for RAW + + Different safety levels need to be supported. All network traffic + handled by the Airborne Internet Protocol Suite (IPS) System are not + equal, and the QoS requirements of each network traffic flow must be + considered n order to avoid having to support QoS requirements at the + granularity of data flows. These flows are grouped into classes that + have similar requirements, following the Diffserv approach + [ARINC858P1]. These classes are referred to as Classes of Service + (CoS), and the flows within a class are treated uniformly from a QoS + perspective. Currently, there are at least eight different priority + levels (CoS) that can be assigned to packets. For example, a high- + priority message requiring low latency and high resiliency could be a + "WAKE" warning indicating two aircraft are dangerously close to each + other, while a less safety-critical message with low-to-medium + latency requirements could be the "WXGRAPH" service providing + graphical weather data. + + Overhead needs to be kept to a minimum since aeronautical data links + provide comparatively small data rates on the order of kbit/s. + + Policy needs to be supported when selecting data links. The focus of + RAW here should be on the selectors that are responsible for the + track a packet takes to reach its end destination. This would + minimize the amount of routing information that must travel inside + the network because of precomputed routing tables, with the selector + being responsible for choosing the most appropriate option according + to policy and safety. + +2.5.1. Non-latency-critical Considerations + + Achieving low latency is a requirement for aeronautics + communications, though the expected latency is not extremely low, and + what is important is to keep the overall latency bounded under a + certain threshold. Low latency in LDACS communications [RFC9372] + translates to a latency in the Forward Link (FL - Ground -> Air) of + 30-90 ms and a latency in the Reverse Link (RL - Air -> Ground) of + 60-120 ms. This use case is not latency critical from that view + point. On the other hand, given the controlled environment, end-to- + end mechanisms can be applied to guarantee bounded latency where + needed. + +3. Amusement Parks + +3.1. Use Case Description + + The digitalization of amusement parks is expected to significantly + decrease the cost for maintaining the attractions. Such deployment + is a mix between multimedia (e.g., Virtual and Augmented Reality and + interactive video environments) and non-multimedia applications (e.g, + access control, industrial automation for a roller coaster). + + Attractions may rely on a large set of sensors and actuators, which + react in real time. Typical applications comprise: + + * Emergency: the safety of the operators and visitors has to be + preserved, and the attraction must be stopped appropriately when a + failure is detected. + + * Video: augmented and virtual realities are integrated in the + attraction. Wearable mobile devices (e.g., glasses and virtual + reality headsets) need to offload one part of the processing + tasks. + + * Real-time interactions: visitors may interact with an attraction, + like in a real-time video game. The visitors may virtually + interact with their environment, triggering actions in the real + world (through actuators) [KOB12]. + + * Geolocation: visitors are tracked with a personal wireless tag, so + that their user experience is improved. This requires special + care to ensure that visitors' privacy is not breached, and users + are anonymously tracked. + + * Predictive maintenance: statistics are collected to predict the + future failures or to compute later more complex statistics about + the attraction's usage, the downtime, etc. + + * Marketing: to improve the customer experience, owners may collect + a large amount of data to understand the behavior and the choices + of their clients. + +3.2. Specifics + + Amusement parks comprise a variable number of attractions, mostly + outdoor, over a large geographical area. The IT infrastructure is + typically multiscale: + + * Local area: The sensors and actuators controlling the attractions + are colocated. Control loops trigger only local traffic, with a + small end-to-end delay, typically less than 10 ms, like classical + industrial systems [IEEE80211RTA]. + + * Wearable devices: Wearable mobile devices are free to move in the + park. They exchange traffic locally (identification, + personalization, multimedia) or globally (billing, child- + tracking). + + * Edge computing: Computationally intensive applications offload + some tasks. Edge computing seems to be an efficient way to + implement real-time applications with offloading. Some non-time- + critical tasks may rather use the cloud (predictive maintenance, + marketing). + + +3.3. The Need for Wireless + + Removing cables helps to easily change the configuration of the + attractions or upgrade parts of them at a lower cost. The attraction + can be designed modularly and can upgrade or insert novel modules + later on in the life cycle of the attraction. Novelty of attractions + tends to increase the attractiveness of an amusement park, + encouraging previous visitors to regularly visit the park. + + Some parts of the attraction are mobile, like trucks of a roller- + coaster or robots. Since cables are prone to frequent failures in + this situation, wireless transmissions are recommended. + + Wearable devices are extensively used for a user experience + personalization. They typically need to support wireless + transmissions. Personal tags may help to reduce the operating costs + [DISNEY15] and increase the number of charged services provided to + the audience (e.g., VIP tickets or interactivity). Some applications + rely on more sophisticated wearable devices, such as digital glasses + or Virtual Reality (VR) headsets for an immersive experience. + +3.4. Requirements for RAW + + The network infrastructure must support heterogeneous traffic, with + very different critical requirements. Thus, flow isolation must be + provided. + + The transmissions must be scheduled appropriately, even in the + presence of mobile devices. While [RFC9030] already proposes an + architecture for synchronized, IEEE Std. 802.15.4 Time-Slotted + Channel Hopping (TSCH) networks, the industry requires a multi- + technology solution that is able to guarantee end-to-end requirements + across heterogeneous technologies with strict Service Level Agreement + (SLA) requirements. + + Nowadays, long-range wireless transmissions are used mostly for best- + effort traffic. On the contrary, [IEEE802.1AS] is used for critical + flows using Ethernet devices. However, we need an IP-enabled + technology to interconnect large areas, independent of the Physical + (PHY) and Medium Access Control (MAC) layers. + + It is expected that several different technologies (long vs. short + range) are deployed, which have to cohabit the same area. Thus, we + need to provide L3 mechanisms able to exploit multiple co-interfering + technologies (i.e., different radio technologies using overlapping + spectrum, and therefore, potentially interfering with each other). + + It is worth noting that low-priority flows (e.g., predictive + maintenance, marketing) are delay tolerant; a few minutes or even + hours would be acceptable. While classical unscheduled wireless + networks already accommodate best-effort traffic, this would force + several colocated and subefficient deployments. Unused resources + could rather be used for low-priority flows. Indeed, allocated + resources are consuming energy in most scheduled networks, even if no + traffic is transmitted. + +3.4.1. Non-latency-critical Considerations + + While some of the applications in this use case involve control loops + (e.g., sensors and actuators) that require bounded latencies below 10 + ms that can therefore be considered latency critical, there are other + applications as well that mostly demand reliability (e.g., safety- + related or maintenance). + +4. Wireless for Industrial Applications + +4.1. Use Case Description + + A major use case for networking in industrial environments is the + control networks where periodic control loops operate between a + collection of sensors that measure a physical property (such as the + temperature of a fluid), a Programmable Logic Controller (PLC) that + decides on an action (such as "warm up the mix"), and actuators that + perform the required action (such as the injection of power in a + resistor). + +4.2. Specifics + +4.2.1. Control Loops + + Process Control designates continuous processing operations, like + heating oil in a refinery or mixing up soda. Control loops in the + Process Control industry operate at a very low rate, typically four + times per second. Factory Automation, on the other hand, deals with + discrete goods, such as individual automobile parts, and requires + faster loops, to the rate of milliseconds. Motion control that + monitors dynamic activities may require even faster rates on the + order of and below the millisecond. + + In all those cases, a packet must flow reliably between the sensor + and the PLC, be processed by the PLC, and be sent to the actuator + within the control loop period. In some particular use cases that + inherit from analog operations, jitter might also alter the operation + of the control loop. A rare packet loss is usually admissible, but + typically, a loss of multiple packets in a row will cause an + emergency halt of the production and incur a high cost for the + manufacturer. + + Additional details and use cases related to industrial applications + and their RAW requirements can be found in [RAW-IND-REQS]. + +4.2.2. Monitoring and Diagnostics + + A secondary use case deals with monitoring and diagnostics. This + data is essential to improve the performance of a production line, + e.g., by optimizing real-time processing or by maintenance windows + using Machine Learning predictions. For the lack of wireless + technologies, some specific industries such as Oil and Gas have been + using serial cables, literally by the millions, to perform their + process optimization over the previous decades. However, few + industries would afford the associated cost. One of the goals of the + Industrial Internet of Things is to provide the same benefits to all + industries, including SmartGrid, transportation, building, + commercial, and medical. This requires a cheap, available, and + scalable IP-based access technology. + + Inside the factory, wires may already be available to operate the + control network. However, monitoring and diagnostics data are not + welcome in that network for several reasons. On the one hand, it is + rich and asynchronous, meaning that it may influence the + deterministic nature of the control operations and impact the + production. On the other hand, this information must be reported to + the operators over IP, which means the potential for a security + breach via the interconnection of the Operational Technology network + with the Internet Technology network and the potential of a rogue + access. + +4.3. The Need for Wireless + + Wires used on a robot arm are prone to breakage, after a few thousand + flexions, a lot faster than a power cable that is wider in diameter + and more resilient. In general, wired networking and mobile parts + are not a good match, mostly in the case of fast and recurrent + activities, as well as rotation. + + When refurbishing older premises that were built before the Internet + age, power is usually available everywhere, but data is not. It is + often impractical, time consuming and expensive to deploy an Ethernet + fabric across walls and between buildings. Deploying a wire may take + months and cost tens of thousands of US Dollars. + + Even when wiring exists, like in the case of an existing control + network, asynchronous IP packets, such as diagnostics, may not be + welcome for operational and security reasons. For those packets, the + option to create a parallel wireless network offers a credible + solution that can scale with the many sensors and actuators that + equip every robot, valve, and fan that are deployed on the factory + floor. It may also help detect and prevent a failure that could + impact the production, like the degradation (vibration) of a cooling + fan on the ceiling. IEEE Std. 802.15.4 TSCH [RFC7554] is a promising + technology for that purpose, mostly if the scheduled operations + enable the use of the same network by asynchronous and deterministic + flows in parallel. + +4.4. Requirements for RAW + + As stated by the "Deterministic Networking Problem Statement" + [RFC8557], a deterministic network is backwards compatible with + (capable of transporting) statistically multiplexed traffic while + preserving the properties of the accepted deterministic flows. While + the "6TiSCH Architecture" [RFC9030] serves that requirement, the work + at 6TiSCH was focused on best-effort IPv6 packet flows. RAW should + be able to lock so-called "hard cells" (i.e., scheduled cells + [6TiSCH-TERMS]) for use by a centralized scheduler and leverage time + and spatial diversity over a graph of end-to-end paths called a + "Track" that is based on those cells. + + Over recent years, major industrial protocols have been migrating + towards Ethernet and IP. (For example, [ODVA] with EtherNet/IP [EIP] + and [PROFINET], where ODVA is the organization that supports network + technologies built on the Common Industrial Protocol (CIP) including + EtherNet/IP.) In order to unleash the full power of the IP hourglass + model, it should be possible to deploy any application over any + network that has the physical capacity to transport the industrial + flow, regardless of the MAC/PHY technology, wired, or wireless, and + across technologies. RAW mechanisms should be able to set up a Track + over a wireless access segment and a wired or wireless backbone to + report both sensor data and critical monitoring within a bounded + latency and should be able to maintain the high reliability of the + flows over time. It is also important to ensure that RAW solutions + are interoperable with existing wireless solutions in place and with + legacy equipment whose capabilities can be extended using + retrofitting. Maintainability, as a broader concept than + reliability, is also important in industrial scenarios [MAR19]. + +4.4.1. Non-latency-critical Considerations + + Monitoring and diagnostics applications do not require latency- + critical communications but demand reliable and scalable + communications. On the other hand, process-control applications + involve control loops that require a bounded latency and, thus, are + latency critical. However, they can be managed end-to-end, and + therefore DetNet mechanisms can be applied in conjunction with RAW + mechanisms. + +5. Professional Audio and Video + +5.1. Use Case Description + + Many devices support audio and video streaming [RFC9317] by employing + 802.11 wireless LAN. Some of these applications require low latency + capability, for instance, when the application provides interactive + play or when the audio plays in real time -- meaning being live for + public addresses in train stations or in theme parks. + + The professional audio and video industry (ProAV) includes: + + * Virtual Reality / Augmented Reality (VR/AR) + + * Production and post-production systems, such as CD and Blu-ray + disk mastering. + + * Public address, media, and emergency systems at large venues + (e.g., airports, train stations, stadiums, and theme parks). + +5.2. Specifics + +5.2.1. Uninterrupted Stream Playback + + Considering the uninterrupted audio or video stream, a potential + packet loss during the transmission of audio or video flows cannot be + tackled by re-trying the transmission, as it is done with file + transfer, because by the time the lost packet has been identified, it + is too late to proceed with packet re-transmission. Buffering might + be employed to provide a certain delay that will allow for one or + more re-transmissions. However, such an approach is not viable in + applications where delays are not acceptable. + +5.2.2. Synchronized Stream Playback + + In the context of ProAV over packet networks, latency is the time + between the transmitted signal over a stream and its reception. + Thus, for sound to remain synchronized to the movement in the video, + the latency of both the audio and video streams must be bounded and + consistent. + +5.3. The Need for Wireless + + Audio and video devices need the wireless communication to support + video streaming via IEEE 802.11 wireless LAN, for instance. Wireless + communications provide huge advantages in terms of simpler + deployments in many scenarios where the use of a wired alternative + would not be feasible. Similarly, in live events, mobility support + makes wireless communications the only viable approach. + + Deployed announcement speakers, for instance, along the platforms of + the train stations, need the wireless communication to forward the + audio traffic in real time. Most train stations are already built, + and deploying novel cables for each novel service seems expensive. + +5.4. Requirements for RAW + + The network infrastructure needs to support heterogeneous types of + traffic (including QoS). + + Content delivery must have bounded latency (to the lowest possible + latency). + + The deployed network topology should allow for multipath. This will + enable for multiple streams to have different (and multiple) paths + (Tracks) through the network to support redundancy. + +5.4.1. Non-latency-critical Considerations + + For synchronized streaming, latency must be bounded. Therefore, + depending on the actual requirements, this can be considered as + "latency critical". However, the most critical requirement of this + use case is reliability, which can be achieved by the network + providing redundancy. Note that in many cases, wireless is only + present in the access where RAW mechanisms could be applied, but + other wired segments are also involved (like the Internet), and + therefore latency cannot be guaranteed. + +6. Wireless Gaming + +6.1. Use Case Description + + The gaming industry includes [IEEE80211RTA] real-time mobile gaming, + wireless console gaming, wireless gaming controllers, and cloud + gaming. Note that they are not mutually exclusive (e.g., a console + can connect wirelessly to the Internet to play a cloud game). For + RAW, wireless console gaming is the most relevant one. We next + summarize the four: + + * Real-time mobile gaming: + + Real-time mobile gaming is very sensitive to network latency and + stability. The mobile game can connect multiple players together + in a single game session and exchange data messages between game + server and connected players. Real-time means the feedback should + present on-screen as users operate in-game. For good game + experience, the end-to-end latency plus game servers processing + time must be the same for all players and should not be noticeable + as the game is played. RAW technologies might help in keeping + latencies low on the wireless segments of the communication. + + * Wireless console gaming: + + While gamers may use a physical console, interactions with a + remote server may be required for online games. Most of the + gaming consoles today support Wi-Fi 5 but may benefit from a + scheduled access with Wi-Fi 6 in the future. Previous Wi-Fi + versions have an especially bad reputation among the gaming + community, the main reasons being high latency, lag spikes, and + jitter. + + * Wireless Gaming controllers: + + Most controllers are now wireless for the freedom of movement. + Controllers may interact with consoles or directly with the gaming + server in the cloud. A low and stable end-to-end latency is here + of predominant importance. + + * Cloud Gaming: + + Cloud gaming requires low-latency capability as the user commands + in a game session are sent back to the cloud server. Then, the + cloud server updates the game context depending on the received + commands, renders the picture/video to be displayed on the user + devices, and streams the picture/video content to the user + devices. User devices might very likely be connected wirelessly. + +6.2. Specifics + + While a lot of details can be found at [IEEE80211RTA], we next + summarize the main requirements in terms of latency, jitter, and + packet loss: + + * Intra Basic Service Set (BSS) latency is less than 5 ms. + + * Jitter variance is less than 2 ms. + + * Packet loss is less than 0.1%. + +6.3. The Need for Wireless + + Gaming is evolving towards wireless, as players demand being able to + play anywhere, and the game requires a more immersive experience + including body movements. Besides, the industry is changing towards + playing from mobile phones, which are inherently connected via + wireless technologies. Wireless controllers are the rule in modern + gaming, with increasingly sophisticated interactions (e.g., haptic + feedback, augmented reality). + +6.4. Requirements for RAW + + Time-sensitive networking extensions: + Extensions, such as time-aware shaping and redundancy, can be + explored to address congestion and reliability problems present in + wireless networks. As an example, in haptics, it is very + important to minimize latency failures. + + Priority tagging (Stream identification): + One basic requirement to provide better QoS for time-sensitive + traffic is the capability to identify and differentiate time- + sensitive packets from other (like best-effort) traffic. + + Time-aware shaping: + This capability (defined in IEEE 802.1Qbv) consists of gates to + control the opening and closing of queues that share a common + egress port within an Ethernet switch. A scheduler defines the + times when each queue opens or closes, therefore, eliminating + congestion and ensuring that frames are delivered within the + expected latency bounds. Though, note that while this requirement + needs to be signaled by RAW mechanisms, it would actually be + served by the lower layer. + + Dual/multiple link: + Due to the fact that competitions and interference are common and + hardly in control under wireless network, to improve the latency + stability, dual/multiple link proposal is brought up to address + this issue. + + Admission Control: + Congestion is a major cause of high/variable latency, and it is + well known that if the traffic load exceeds the capability of the + link, QoS will be degraded. QoS degradation may be acceptable for + many applications today. However, emerging time-sensitive + applications are highly susceptible to increased latency and + jitter. To better control QoS, it is important to control access + to the network resources. + +6.4.1. Non-latency-critical Considerations + + Depending on the actual scenario, and on use of Internet to + interconnect different users, the communication requirements of this + use case might be considered as latency critical due to the need of + bounded latency. However, note that, in most of these scenarios, + part of the communication path is not wireless, and DetNet mechanisms + cannot be applied easily (e.g., when the public Internet is + involved), and therefore, reliability is the critical requirement. + +7. Unmanned Aerial Vehicles and Vehicle-to-Vehicle Platooning and + Control + +7.1. Use Case Description + + Unmanned Aerial Vehicles (UAVs) are becoming very popular for many + different applications, including military and civil use cases. The + term "drone" is commonly used to refer to a UAV. + + UAVs can be used to perform aerial surveillance activities, traffic + monitoring (i.e., the Spanish traffic control has recently introduced + a fleet of drones for quicker reactions upon traffic congestion + related events [DGT2021]), support of emergency situations, and even + transporting of small goods (e.g., medicine in rural areas). Note + that the surveillance and monitoring application would have to comply + with local regulations regarding location privacy of users. + Different considerations have to be applied when surveillance is + performed for traffic rules enforcement (e.g., generating fines), as + compared to when traffic load is being monitored. + + Many types of vehicles, including UAVs but also others, such as cars, + can travel in platoons, driving together with shorter distances + between vehicles to increase efficiency. Platooning imposes certain + vehicle-to-vehicle considerations, most of these are applicable to + both UAVs and other vehicle types. + + UAVs and other vehicles typically have various forms of wireless + connectivity: + + * Cellular: for communication with the control center, remote + maneuvering, and monitoring of the drone; + + * IEEE 802.11: for inter-drone communications (i.e., platooning) and + providing connectivity to other devices (i.e., acting as Access + Point). + + Note that autonomous cars share many of the characteristics of the + aforementioned UAV case. Therefore, it is of interest for RAW. + +7.2. Specifics + + Some of the use cases and tasks involving UAVs require coordination + among UAVs. Others involve complex computing tasks that might not be + performed using the limited computing resources that a drone + typically has. These two aspects require continuous connectivity + with the control center and among UAVs. + + Remote maneuvering of a drone might be performed over a cellular + network in some cases, but there are situations that need very low + latency and deterministic behavior of the connectivity. Examples + involve platooning of drones or sharing of computing resources among + drones (like a drone offloading some function to a neighboring + drone). + +7.3. The Need for Wireless + + UAVs cannot be connected through any type of wired media, so it is + obvious that wireless is needed. + +7.4. Requirements for RAW + + The network infrastructure is composed of the UAVs themselves, + requiring self-configuration capabilities. + + Heterogeneous types of traffic need to be supported, from extremely + critical traffic types requiring ultra-low latency and high + resiliency to traffic requiring low-to-medium latency. + + When a given service is decomposed into functions (which are hosted + at different UAVs and chained), each link connecting two given + functions would have a well-defined set of requirements (e.g., + latency, bandwidth, and jitter) that must be met. + +7.4.1. Non-latency-critical Considerations + + Today's solutions keep the processing operations that are critical + local (i.e., they are not offloaded). Therefore, in this use case, + the critical requirement is reliability, and, only for some + platooning and inter-drone communications, latency is critical. + +8. Edge Robotics Control + +8.1. Use Case Description + + The edge robotics scenario consists of several robots, deployed in a + given area (like a shopping mall) and inter-connected via an access + network to a network edge device or a data center. The robots are + connected to the edge so that complex computational activities are + not executed locally at the robots but offloaded to the edge. This + brings additional flexibility in the type of tasks that the robots + perform, reduces the costs of robot-manufacturing (due to their lower + complexity), and enables complex tasks involving coordination among + robots (that can be more easily performed if robots are centrally + controlled). + + Simple examples of the use of multiple robots are cleaning, video + surveillance (note that this have to comply with local regulations + regarding user privacy at the application level), search and rescue + operations, and delivering of goods from warehouses to shops. + Multiple robots are simultaneously instructed to perform individual + tasks by moving the robotic intelligence from the robots to the + network's edge. That enables easy synchronization, scalable + solution, and on-demand option to create flexible fleet of robots. + + Robots would have various forms of wireless connectivity: + + * Cellular: as an additional communication link to the edge, though + primarily as backup, since ultra-low latency is needed. + + * IEEE 802.11: for connection to the edge and also inter-robot + communications (i.e., for coordinated actions). + +8.2. Specifics + + Some of the use cases and tasks involving robots might benefit from + decomposition of a service into small functions that are distributed + and chained among robots and the edge. These require continuous + connectivity with the control center and among drones. + + Robot control is an activity requiring very low latency (0.5-20 ms + [Groshev2021]) between the robot and the location where the control + intelligence resides (which might be the edge or another robot). + +8.3. The Need for Wireless + + Deploying robots in scenarios such as shopping malls for the + applications mentioned cannot be done via wired connectivity. + +8.4. Requirements for RAW + + The network infrastructure needs to support heterogeneous types of + traffic, from robot control to video streaming. + + When a given service is decomposed into functions (which are hosted + at different UAVs and chained), each link connecting two given + functions would have a well-defined set of requirements (e.g., + latency, bandwidth, and jitter) that must be met. + +8.4.1. Non-latency-critical Considerations + + This use case might combine multiple communication flows, with some + of them being latency critical (like those related to robot-control + tasks). Note that there are still many communication flows (like + some offloading tasks) that only demand reliability and availability. + +9. Instrumented Emergency Medical Vehicles + +9.1. Use Case Description + + An instrumented ambulance would have one or multiple network segments + that are connected to end systems such as: + + * vital signs sensors attached to the casualty in the ambulance to + relay medical data to hospital emergency room, + + * a radio-navigation sensor to relay position data to various + destinations including dispatcher, + + * voice communication for ambulance attendant (likely to consult + with ER doctor), and + + * voice communication between driver and dispatcher. + + The LAN needs to be routed through radio-WANs (a radio network in the + interior of a network, i.e., it is terminated by routers) to complete + the network linkage. + +9.2. Specifics + + What we have today is multiple communication systems to reach the + vehicle via: + + * a dispatching system, + + * a cellphone for the attendant, + + * a special purpose telemetering system for medical data, + + * etc. + + This redundancy of systems does not contribute to availability. + + Most of the scenarios involving the use of an instrumented ambulance + are composed of many different flows, each of them with slightly + different requirements in terms of reliability and latency. + Destinations might be either the ambulance itself (local traffic), a + near edge cloud, or the general Internet/cloud. Special care (at + application level) have to be paid to ensure that sensitive data is + not disclosed to unauthorized parties by properly securing traffic + and authenticating the communication ends. + +9.3. The Need for Wireless + + Local traffic between the first responders and ambulance staff and + the ambulance equipment cannot be done via wired connectivity as the + responders perform initial treatment outside of the ambulance. The + communications from the ambulance to external services must be + wireless as well. + +9.4. Requirements for RAW + + We can derive some pertinent requirements from this scenario: + + * High availability of the internetwork is required. The exact + level of availability depends on the specific deployment scenario, + as not all emergency agencies share the same type of instrumented + emergency vehicles. + + * The internetwork needs to operate in damaged state (e.g., during + an earthquake aftermath, heavy weather, a wildfire, etc.). In + addition to continuity of operations, rapid restore is a needed + characteristic. + + * The radio-WAN has characteristics similar to the cellphone's -- + the vehicle will travel from one radio coverage area to another, + thus requiring some hand-off approach. + +9.4.1. Non-latency-critical Considerations + + In this case, all applications identified do not require latency- + critical communication but do need high reliability and availability. + +10. Summary + + This document enumerates several use cases and applications that need + RAW technologies, focusing on the requirements from reliability, + availability, and latency. While some use cases are latency + critical, there are also several applications that are not latency + critical but do pose strict reliability and availability + requirements. + +11. IANA Considerations + + This document has no IANA actions. + +12. Security Considerations + + This document covers several representative applications and network + scenarios that are expected to make use of RAW technologies. Each of + the potential RAW use cases will have security considerations from + both the use-specific perspective and the RAW technology perspective. + [RFC9055] provides a comprehensive discussion of security + considerations in the context of DetNet, which are generally also + applicable to RAW. + +13. Informative References + + [6TiSCH-TERMS] + Palattella, MR., Ed., Thubert, P., Watteyne, T., and Q. + Wang, "Terms Used in IPv6 over the TSCH mode of IEEE + 802.15.4e", Work in Progress, Internet-Draft, draft-ietf- + 6tisch-terminology-10, 2 March 2018, + <https://datatracker.ietf.org/doc/html/draft-ietf-6tisch- + terminology-10>. + + [ACI19] Airports Council International, "Annual World Airport + Traffic Report, 2019", 2019, + <https://store.aci.aero/product/annual-world-airport- + traffic-report-2019/>. + + [ARINC858P1] + SAE International, "Internet Protocol Suite (IPS) for + Aeronautical Safety Services Part 1 Airborne IPS System + Technical Requirements", ARINC858P1, June 2021, + <https://www.sae.org/standards/content/arinc858p1/>. + + [DGT2021] Menéndez, J., "Drones: así es la vigilancia" [Drones: this + is surveillance], January 2021, + <https://revista.dgt.es/es/reportajes/2021/01ENERO/0126- + Como-funciona-un-operativo-con-drones.shtml>. + + [DISNEY15] Kuang, C., "Disney's $1 Billion Bet on a Magical + Wristband", March 2015, + <https://www.wired.com/2015/03/disney-magicband/>. + + [EIP] ODVA, "EtherNet/IP | ODVA Technologies | Industrial + Automation", <https://www.odva.org/technology-standards/ + key-technologies/ethernet-ip/>. + + [FAA20] U.S. Department of Transportation: Federal Aviation + Administration (FAA), "Next Generation Air Transportation + System (NextGen)", <https://www.faa.gov/nextgen/>. + + [Groshev2021] + Groshev, M., Guimarães, C., de la Oliva, A., and R. Gazda, + "Dissecting the Impact of Information and Communication + Technologies on Digital Twins as a Service", IEEE Access, + Volume 9, DOI 10.1109/ACCESS.2021.3098109, July 2021, + <https://doi.org/10.1109/ACCESS.2021.3098109>. + + [IAC20] Iacus, S., Natale, F., Santamaria, C., Spyratos, S., and + M. Vespe, "Estimating and projecting air passenger traffic + during the COVID-19 coronavirus outbreak and its socio- + economic impact", Safety Science, Volume 129, + DOI 10.1016/j.ssci.2020.104791, September 2020, + <https://doi.org/10.1016/j.ssci.2020.104791>. + + [IAT20] IATA, "Economic Performance of the Airline Industry", + November 2020, <https://www.iata.org/en/iata- + repository/publications/economic-reports/airline-industry- + economic-performance---november-2020---report/>. + + [ICAO2022] International Civil Aviation Organization (ICAO), "CHAPTER + 13 L-Band Digital Aeronautical Communications System + (LDACS)", International Standards and Recommended + Practices, Annex 10 - Aeronautical Telecommunications, + Volume III, Communication Systems, 2022, + <https://www.ldacs.com/wp-content/uploads/2023/03/ + WP06.AppA-DCIWG-6-LDACS_SARPs.pdf>. + + [IEEE802.1AS] + IEEE, "IEEE Standard for Local and Metropolitan Area + Networks--Timing and Synchronization for Time-Sensitive + Applications", DOI 10.1109/IEEESTD.2020.9121845, IEEE + 802.1AS-2020, June 2020, + <https://doi.org/10.1109/IEEESTD.2020.9121845>. + + [IEEE80211BE] + Cavalcanti, D. and G. Venkatesan, "802.1 TSN over 802.11 + with updates from developments in 802.11be", IEEE plenary + meeting, November 2020, + <https://www.ieee802.org/1/files/public/docs2020/new- + Cavalcanti-802-1TSN-over-802-11-1120-v02.pdf>. + + [IEEE80211RTA] + IEEE standard for Information Technology, "IEEE 802.11 + Real Time Applications TIG Report", November 2018. + + [ISA100] ISA, "ISA100, Wireless Systems for Automation", + <https://www.isa.org/isa100/>. + + [KOB12] Kober, J., Glisson, M., and M. Mistry, "Playing catch and + juggling with a humanoid robot", + DOI 10.1109/HUMANOIDS.2012.6651623, November 2012, + <https://doi.org/10.1109/HUMANOIDS.2012.6651623>. + + [MAR19] Martinez, B., Cano, C., and X. Vilajosana, "A Square Peg + in a Round Hole: The Complex Path for Wireless in the + Manufacturing Industry", IEEE Communications Magazine, + Volume 57, Issue 4, DOI 10.1109/MCOM.2019.1800570, April + 2019, <https://doi.org/10.1109/MCOM.2019.1800570>. + + [Maurer2022] + Mäurer, N., Guggemos, T., Ewert, T., Gräupl, T., Schmitt, + C., and S. Grundner-Culemann, "Security in Digital + Aeronautical Communications A Comprehensive Gap Analysis", + International Journal of Critical Infrastructure + Protection, Volume 38, DOI 10.1016/j.ijcip.2022.100549, + September 2022, + <https://doi.org/10.1016/j.ijcip.2022.100549>. + + [ODVA] ODVA, "ODVA | Industrial Automation | Technologies and + Standards", <https://www.odva.org/>. + + [PLA14] Plass, S., Hermenier, R., Lücke, O., Gomez Depoorter, D., + Tordjman, T., Chatterton, M., Amirfeiz, M., Scotti, S., + Cheng, Y., Pillai, P., Gräupl, T., Durand, F., Murphy, K., + Marriott, A., and A. Zaytsev, "Flight Trial Demonstration + of Seamless Aeronautical Networking", IEEE Communications + Magazine, Volume 52, Issue 5, + DOI 10.1109/MCOM.2014.6815902, May 2014, + <https://doi.org/10.1109/MCOM.2014.6815902>. + + [PROFINET] PROFINET, "PROFINET Technology", + <https://us.profinet.com/technology/profinet/>. + + [RAW-IND-REQS] + Sofia, R. C., Kovatsch, M., and P. Mendes, "Requirements + for Reliable Wireless Industrial Services", Work in + Progress, Internet-Draft, draft-ietf-raw-industrial- + requirements-00, 10 December 2021, + <https://datatracker.ietf.org/doc/html/draft-ietf-raw- + industrial-requirements-00>. + + [RAW-TECHNOS] + Thubert, P., Ed., Cavalcanti, D., Vilajosana, X., Schmitt, + C., and J. Farkas, "Reliable and Available Wireless + Technologies", Work in Progress, Internet-Draft, draft- + ietf-raw-technologies-08, 10 July 2023, + <https://datatracker.ietf.org/doc/html/draft-ietf-raw- + technologies-08>. + + [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., + and W. Weiss, "An Architecture for Differentiated + Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, + <https://www.rfc-editor.org/info/rfc2475>. + + [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using + IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the + Internet of Things (IoT): Problem Statement", RFC 7554, + DOI 10.17487/RFC7554, May 2015, + <https://www.rfc-editor.org/info/rfc7554>. + + [RFC8557] Finn, N. and P. Thubert, "Deterministic Networking Problem + Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019, + <https://www.rfc-editor.org/info/rfc8557>. + + [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", + RFC 8578, DOI 10.17487/RFC8578, May 2019, + <https://www.rfc-editor.org/info/rfc8578>. + + [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, + "Deterministic Networking Architecture", RFC 8655, + DOI 10.17487/RFC8655, October 2019, + <https://www.rfc-editor.org/info/rfc8655>. + + [RFC9030] Thubert, P., Ed., "An Architecture for IPv6 over the Time- + Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", + RFC 9030, DOI 10.17487/RFC9030, May 2021, + <https://www.rfc-editor.org/info/rfc9030>. + + [RFC9055] Grossman, E., Ed., Mizrahi, T., and A. Hacker, + "Deterministic Networking (DetNet) Security + Considerations", RFC 9055, DOI 10.17487/RFC9055, June + 2021, <https://www.rfc-editor.org/info/rfc9055>. + + [RFC9317] Holland, J., Begen, A., and S. Dawkins, "Operational + Considerations for Streaming Media", RFC 9317, + DOI 10.17487/RFC9317, October 2022, + <https://www.rfc-editor.org/info/rfc9317>. + + [RFC9372] Mäurer, N., Ed., Gräupl, T., Ed., and C. Schmitt, Ed., + "L-Band Digital Aeronautical Communications System + (LDACS)", RFC 9372, DOI 10.17487/RFC9372, March 2023, + <https://www.rfc-editor.org/info/rfc9372>. + + [SESAR] SESAR, "SESAR Joint Undertaking", + <https://www.sesarju.eu/>. + +Acknowledgments + + Nils Mäurer, Thomas Gräupl, and Corinna Schmitt have contributed + significantly to this document, providing input for the Aeronautical + communication section. Rex Buddenberg has also contributed to the + document, providing input to the "Instrumented Emergency Medical + Vehicles" section. + + The authors would like to thank Toerless Eckert, Xavi Vilajosana + Guillen, Rute Sofia, Corinna Schmitt, Victoria Pritchard, John + Scudder, Joerg Ott, and Stewart Bryant for their valuable comments on + draft versions of this document. + + The work of Carlos J. Bernardos in this document has been partially + supported by the Horizon Europe PREDICT-6G (Grant 101095890) and + UNICO I+D 6G-DATADRIVEN-04 project. + +Authors' Addresses + + Carlos J. Bernardos (editor) + Universidad Carlos III de Madrid + Av. Universidad, 30 + 28911 Madrid + Spain + Phone: +34 91624 6236 + Email: cjbc@it.uc3m.es + URI: http://www.it.uc3m.es/cjbc/ + + + Georgios Papadopoulos + IMT Atlantique + Office B00 - 114A + 2 Rue de la Chataigneraie + 35510 Cesson-Sevigne - Rennes + France + Phone: +33 299 12 70 04 + Email: georgios.papadopoulos@imt-atlantique.fr + + + Pascal Thubert + Cisco Systems, Inc + Building D + 45 Allee des Ormes - BP1200 + 06254 MOUGINS - Sophia Antipolis + France + Phone: +33 497 23 26 34 + Email: pthubert@cisco.com + + + Fabrice Theoleyre + CNRS + ICube Lab, Pole API + 300 boulevard Sebastien Brant - CS 10413 + 67400 Illkirch + France + Phone: +33 368 85 45 33 + Email: fabrice.theoleyre@cnrs.fr + URI: https://fabrice.theoleyre.cnrs.fr/ |