doc: Add RFC documents

1 files changed, 1340 insertions, 0 deletions

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