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