RAW

Internet Engineering Task Force (IETF)                CJ. Bernardos, Ed.
Internet-Draft
Request for Comments: 9450                                          UC3M
Intended status:
Category: Informational                         G.Z.                                  G. Papadopoulos
Expires: 19 October 2023
ISSN: 2070-1721                                           IMT Atlantique
                                                              P. Thubert
                                                                   Cisco
                                                            F. Theoleyre
                                                                    CNRS
                                                           17 April
                                                             August 2023

                             RAW Use-Cases
                      draft-ietf-raw-use-cases-11

            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 use cases cannot be solved with wires
   and justify the extra effort of going wireless.  This document
   presents wireless use-cases use cases (such as aeronautical communications,
   amusement parks, industrial applications, pro audio and video,
   gaming, UAV Unmanned Aerial Vehicle (UAV) and V2V vehicle-to-vehicle (V2V)
   control, edge robotics robotics, and emergency vehicles) vehicles), demanding reliable
   and available behavior.

Status of This Memo

   This Internet-Draft document is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents valid
   approved by the IESG are candidates for a maximum any level of six months 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 updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 19 October 2023.
   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)
   (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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Aeronautical Communications . . . . . . . . . . . . . . . . .   5
     2.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   5
     2.2.  Specifics . . . . . . . . . . . . . . . . . . . . . . . .   6
     2.3.  Challenges  . . . . . . . . . . . . . . . . . . . . . . .   7
     2.4.  The Need for Wireless . . . . . . . . . . . . . . . . . .   8
     2.5.  Requirements for RAW  . . . . . . . . . . . . . . . . . .   8
       2.5.1.  Non-latency critical considerations . . . . . . . . .   9  Non-latency-critical Considerations
   3.  Amusement Parks . . . . . . . . . . . . . . . . . . . . . . .   9
     3.1.  Use-Case  Use Case Description  . . . . . . . . . . . . . . . . . .   9
     3.2.  Specifics . . . . . . . . . . . . . . . . . . . . . . . .  10
     3.3.  The Need for Wireless . . . . . . . . . . . . . . . . . .  10
     3.4.  Requirements for RAW  . . . . . . . . . . . . . . . . . .  11
       3.4.1.  Non-latency critical considerations . . . . . . . . .  12  Non-latency-critical Considerations
   4.  Wireless for Industrial Applications  . . . . . . . . . . . .  12
     4.1.  Use-Case  Use Case Description  . . . . . . . . . . . . . . . . . .  12
     4.2.  Specifics . . . . . . . . . . . . . . . . . . . . . . . .  12
       4.2.1.  Control Loops . . . . . . . . . . . . . . . . . . . .  12
       4.2.2.  Monitoring and diagnostics  . . . . . . . . . . . . .  13 Diagnostics
     4.3.  The Need for Wireless . . . . . . . . . . . . . . . . . .  13
     4.4.  Requirements for RAW  . . . . . . . . . . . . . . . . . .  14
       4.4.1.  Non-latency critical considerations . . . . . . . . .  14  Non-latency-critical Considerations
   5.  Pro  Professional Audio and Video . . . . . . . . . . . . . . . . . . . . .  14
     5.1.  Use-Case  Use Case Description  . . . . . . . . . . . . . . . . . .  15
     5.2.  Specifics . . . . . . . . . . . . . . . . . . . . . . . .  15
       5.2.1.  Uninterrupted Stream Playback . . . . . . . . . . . .  15
       5.2.2.  Synchronized Stream Playback  . . . . . . . . . . . .  15
     5.3.  The Need for Wireless . . . . . . . . . . . . . . . . . .  15
     5.4.  Requirements for RAW  . . . . . . . . . . . . . . . . . .  16
       5.4.1.  Non-latency critical considerations . . . . . . . . .  16  Non-latency-critical Considerations
   6.  Wireless Gaming . . . . . . . . . . . . . . . . . . . . . . .  16
     6.1.  Use-Case  Use Case Description  . . . . . . . . . . . . . . . . . .  16
     6.2.  Specifics . . . . . . . . . . . . . . . . . . . . . . . .  17
     6.3.  The Need for Wireless . . . . . . . . . . . . . . . . . .  18
     6.4.  Requirements for RAW  . . . . . . . . . . . . . . . . . .  18
       6.4.1.  Non-latency critical considerations . . . . . . . . .  19  Non-latency-critical Considerations
   7.  Unmanned Aerial Vehicles and Vehicle-to-Vehicle platooning Platooning and
           control . . . . . . . . . . . . . . . . . . . . . . . . .  19
           Control
     7.1.  Use-Case  Use Case Description  . . . . . . . . . . . . . . . . . .  19
     7.2.  Specifics . . . . . . . . . . . . . . . . . . . . . . . .  20
     7.3.  The Need for Wireless . . . . . . . . . . . . . . . . . .  20
     7.4.  Requirements for RAW  . . . . . . . . . . . . . . . . . .  20
       7.4.1.  Non-latency critical considerations . . . . . . . . .  20  Non-latency-critical Considerations
   8.  Edge Robotics control . . . . . . . . . . . . . . . . . . . .  20 Control
     8.1.  Use-Case  Use Case Description  . . . . . . . . . . . . . . . . . .  21
     8.2.  Specifics . . . . . . . . . . . . . . . . . . . . . . . .  21
     8.3.  The Need for Wireless . . . . . . . . . . . . . . . . . .  21
     8.4.  Requirements for RAW  . . . . . . . . . . . . . . . . . .  22
       8.4.1.  Non-latency critical considerations . . . . . . . . .  22  Non-latency-critical Considerations
   9.  Instrumented emergency medical vehicles . . . . . . . . . . .  22 Emergency Medical Vehicles
     9.1.  Use-Case  Use Case Description  . . . . . . . . . . . . . . . . . .  22
     9.2.  Specifics . . . . . . . . . . . . . . . . . . . . . . . .  22
     9.3.  The Need for Wireless . . . . . . . . . . . . . . . . . .  23
     9.4.  Requirements for RAW  . . . . . . . . . . . . . . . . . .  23
       9.4.1.  Non-latency critical considerations . . . . . . . . .  23  Non-latency-critical Considerations
   10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .  24
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  24
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  24
   13. Informative References  . . . . . . . . . . . . . . . . . . .  24
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  29
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  29

1.  Introduction

   Based on time, resource reservation, and policy enforcement by
   distributed shapers, deterministic networking 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, latency so as to support time-sensitive and mission-critical mission-
   critical applications on a converged enterprise infrastructure.

   Deterministic networking

   DetNet aims at eliminating packet loss for a committed bandwidth bandwidth,
   while ensuring a worst case worst-case end-to-end latency, regardless of the
   network conditions and across technologies.  By leveraging lower
   layer (Layer 2 (L2) and below) capabilities, L3 Layer 3 (L3) can exploit
   the use of a service layer, steering over multiple
   technologies, technologies and
   using media independent signaling to provide high reliability,
   precise time delivery, and rate enforcement.
   Deterministic networking  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, and/or by shaping and/or or scheduling the
   packets at every
   hop. hop, or by using a combination of these techniques.

   Key attributes of Deterministic networking 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 shapers, both within and at the edge 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 "Reliable and Available Wireless, Wireless" and refers to the
   mechanisms aimed for providing high reliability and availability for
   IP connectivity over a wireless medium.  Making Wireless Reliable wireless reliable and
   Available
   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, and while 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 deterministic networking DetNet have prevalently been focused on
   wired media, with Audio/Video Audio Video Bridging (AVB) and Time
   Sensitive Time-Sensitive
   Networking (TSN) at the IEEE and DetNet [RFC8655] at the IETF.  But
   However, wires cannot be used in several cases, including mobile or
   rotating devices, rehabilitated industrial buildings, wearable or in-
   body sensory devices, vehicle automation 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 OPEX Operational
   Expenditure (OPEX) and CAPEX Capital Expenditure (CAPEX) and are limited to
   very few industries, e.g., process control, concert
   instruments instruments, or
   racing.

   This is now changing [I-D.ietf-raw-technologies]: (as detailed in [RAW-TECHNOS]):

   *  IMT-2020 has recognized Ultra-Reliable Low-Latency Low Latency Communication
      (URLLC) as a key functionality for the upcoming 5G.

   *  IEEE 802.11 has identified a set of real-applications
      [IEEE80211-RT-TIG] 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
      TimeSlotted 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, synchronization
   and time-aware scheduling (trigger based access mode) to support TSN
   flows.

   This document extends the "Deterministic Networking use-cases" Use Cases"
   document [RFC8578] and describes several additional use-cases which use cases that
   require "reliable/predictable and available" flows over wireless
   links and possibly complex multi-hop paths called Tracks. "Tracks".  This is
   covered mainly by the "Wireless for Industrial Applications" use-
   (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  Whereas, while the "Wireless for Industrial
   Applications" use-case use case certainly covers an area of interest for RAW,
   it is limited to 6TiSCH, IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH),
   and thus thus, its scope is narrower than the use-cases use cases described next in
   this document.

2.  Aeronautical Communications

   Aircraft are currently connected to ATC (Air-Traffic Control) Air-Traffic Control (ATC) and AOC
   (Airline
   Airline Operational Control) 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 while en- high-bandwidth communications, whereas en
   route it's focused on high reliability, robustness robustness, and range are the focus. range.

2.1.  Problem Statement

   Up to 2020, civil air traffic has had been growing constantly at a
   compound rate of 5.8% per year [ACI19] [ACI19], and despite the severe impact
   of the COVID-19 pandemic, air traffic air-traffic growth is expected to resume
   very quickly in post-pandemic times [IAT20] [IAC20].  Thus, legacy
   systems in air traffic management Air-Traffic Management (ATM) are likely to reach their
   capacity limits 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 [KEAV20] [FAA20] [SESAR] [FAA20], calling for suitable new digital approaches
   such as AeroMACS the Aeronautical Mobile Airport Communications System
   (AeroMACS) for airport communications, SatCOM for remote domains, and LDACS
   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 a 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 long-range terrestrial
   communications, already in the process of being standardized in the
   International Civil Aviation Organization (ICAO), is the L-band Digital Aeronautical Communication
   System (LDACS) [ICAO18] [I-D.ietf-raw-ldacs]. LDACS [ICAO2022]
   [RFC9372].

   Note that the large scale of the planned low Low Earth orbit 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
   challenges, such as frequent handovers, high-interference, high interference, and a
   diverse range of system users, which can create security issues since
   both safety-
   critical safety-critical and non-safety-critical 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)

   FCI includes:

   *  AeroMACS for Airport/ Termina Maneuvering Area domain, airport and terminal maneuvering area domains,
   *  LDACS A/G Air/Ground for
    Terminal Maneuvering/ En-Route domain, terminal maneuvering area and en route
      domains,
   *  LDACS A/G Air/Ground for En-Route/
   Oceanic, Remote, Polar domain, en route or oceanic, remote, and polar
      regions, and
   *  SatCOM for Oceanic, Remote, Polar
                     domain domain communications 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 time, and data
      overhead of new aeronautical datalinks at data links to a minimum.

   *  Modularity: Systems in avionics usually operate for up to 30 years,
      thus
      years.  Thus, solutions must be modular, easily adaptable adaptable, and
      updatable.

   *  Interoperability: All 192 members of the international Civil
      Aviation Organization (ICAO) ICAO must be able to use
      these solutions.

   *  Dynamicity: the The communication infrastructure needs to accommodate
      mobile devices (airplanes) that move extremely fast.

2.4.  The Need for Wireless

   In a high mobility environment 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  Thus, air, ground ground, and space-based datalink providing data links that provide
   these technologies will have to operate seamlessly together to cope
   with the increasing needs of data exchange between aircraft, air air-
   traffic controller, airport infrastructure, airlines, air network
   service providers (ANSPs) (ANSPs), and so forth.  Wireless technologies have
   to be used to tackle this enormous need for a worldwide digital
   aeronautical datalink 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 is are not
   equal
   equal, and the Quality of Service (QoS) 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.  These flows are grouped into classes that
   have similar requirements, following the
   DiffServ Diffserv approach
   [ARINC858P1].  These classes are referred to as Classes of Service (CoS)
   (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 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-medium low-to-medium
   latency requirements could be the "WXGRAPH" service providing
   graphical weather data.

   Overhead needs to be kept at 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, 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 tables, with the selector
   being responsible for choosing the most appropriate option according
   to policy and safety.

2.5.1.  Non-latency critical considerations  Non-latency-critical Considerations

   Achieving low latency is a requirement for aeronautics
   communications, though the expected latency is not extremely low 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 use case is not latency-critical 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  Use Case Description

   The digitalization of Amusement Parks amusement parks is expected to decrease significantly
   decrease the cost for maintaining the attractions.  Such deployment
   is a mix between multimedia (e.g., Virtual and Augmented
   Reality, Reality and
   interactive video environments) and non-multimedia applications (e.g,
   access control, industrial automation for a roller-coaster, access
   control). 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
      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, glasses and virtual
      reality headset) 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 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, 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, behavior and the choice 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 multi-scale: multiscale:

   *  Local area: the The sensors and actuators controlling the attractions
      are co-located. colocated.  Control loops trigger only local traffic, with a
      small end-to-end delay, typically less than 10 ms, like classical
      industrial systems [IEEE80211-RT-TIG]. [IEEE80211RTA].

   *  Wearable devices: Wearable mobile devices are free to move in the
      park.  They exchange traffic locally (identification,
      personalization, multimedia) or globally (billing, child 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 non-time-
      critical tasks may rather use the cloud (predictive maintenance,
      marketing).

3.3.  The Need for Wireless

   Removing cables helps to change easily change the configuration of the
   attractions,
   attractions or to upgrade parts of them at a lower cost.  The attraction
   can be designed modularly, modularly and can upgrade or insert novel modules
   later on in the lifecycle life cycle of the attraction.  Novelty of attractions
   tends to increase the attractiveness of an amusement park,
   encouraging previous visitors to visit 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 to increase the number of charged services provided to
   the audience (e.g., VIP tickets or interactivity).  Some applications
   rely on more sophisticated wearable devices 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 appropriately, even in the
   presence of mobile devices.  While the [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, multi-
   technology solution that is able to guarantee end-to-end requirements
   across heterogeneous
   technologies, technologies with strict SLA Service Level Agreement
   (SLA) requirements.

   Nowadays, long-range wireless transmissions are used mostly for best-
   effort traffic.  On the contrary, [IEEE802.1TSN] [IEEE802.1AS] is used for critical
   flows using Ethernet devices.  However, we need an IP enabled IP-enabled
   technology to interconnect large areas, independent of the PHY Physical
   (PHY) and
   MAC Medium Access Control (MAC) layers.

   It is expected that several different technologies (long vs. short
   range) are deployed, which have to cohabit in the same area.  Thus, we
   need to provide layer-3 L3 mechanisms able to exploit multiple co-
   interfering co-interfering
   technologies (i.e., different radio technologies using overlapping
   spectrum, and therefore, potentially interfering to with each other).

   It is worth noting that low-priority flows (e.g., predictive
   maintenance, marketing) are delay tolerant: tolerant; a few minutes or even
   hours would be acceptable.  While classical unscheduled wireless
   networks already accomodate 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  Non-latency-critical Considerations

   While some of the applications in this use-case use case involve control loops
   (e.g., sensors and actuators) that require bounded latencies below 10
   ms,
   ms that can therefore be considered latency critical, there are other
   applications as well that mostly demand reliability (e.g.,
   safety related, safety-
   related or maintenance).

4.  Wireless for Industrial Applications

4.1.  Use-Case  Use Case Description

   A major use-case use case for networking in Industrial industrial environments is the
   control networks where periodic control loops operate between a
   collection of sensors that measure a physical property such (such as the
   temperature of a fluid, fluid), a Programmable Logic Controller (PLC) that
   decides on an action such (such as warm "warm up the mix, mix"), and actuators that
   perform the required action, such action (such as the injection of power in a resistor.
   resistor).

4.2.  Specifics

4.2.1.  Control Loops

   Process Control designates continuous processing operations, like
   heating oil in a refinery or mixing drinking 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 goods, such as individual automobile parts, and requires
   faster loops, on to the order 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 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
   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 use cases related to Industrial industrial applications
   and their RAW requirements can be found in
   [I-D.ietf-raw-industrial-requirements]. [RAW-IND-REQS].

4.2.2.  Monitoring and diagnostics Diagnostics

   A secondary use-case 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.  But  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 transportation, building,
   commercial, and
   Medical. medical.  This requires a cheap, available available, and
   scalable IP-based access technology.

   Inside the factory, wires may already be available to operate the
   Control Network.  But
   control network.  However, monitoring and diagnostics data are not
   welcome in that network for several reasons.  On the one hand 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 (OT) network
   with the Internet technology (IT) Technology network and possibly enable the potential of a rogue
   access.

4.3.  The Need for Wireless

   Wires used on a robot arm are prone to breakage breakage, after a few thousands thousand
   flexions, a lot faster than a power cable that is wider in diameter, 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 packets, such as diagnostics 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, every valve 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 Time-Slotted Channel
   Hopping (TSCH) TSCH [RFC7554] is a promising
   technology for that purpose, mostly if the scheduled operations
   enable to 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 "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 "hard cells" (i.e., scheduled cells
   [I-D.ietf-6tisch-terminology])
   [6TiSCH-TERMS]) for use by a centralized scheduler, scheduler and leverage time
   and spatial diversity over a graph of end-to-end paths called a Track
   "Track" that is based on those cells.

   Over the course of the recent years, major Industrial Protocols
   (e.g., [ODVA] with EtherNet/IP [EIP] and [PROFINET]) 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 wired, or wireless, and
   across technologies.  RAW mechanisms should be able to setup 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, place and with
   legacy equipment whose capabilities can be extended using
   retrofitting.  Maintainability, as a broader concept than reliability
   reliability, is also important in industrial scenarios [MAR19].

4.4.1.  Non-latency critical considerations  Non-latency-critical Considerations

   Monitoring and diagnostics applications do not require latency latency-
   critical communications, communications but demand reliable and scalable
   communications.  On the other hand, process control process-control applications
   involve control loops that require a bounded latency, thus latency and, thus, are
   latency critical, but critical.  However, they can be managed end-to-end, and
   therefore DetNet mechanisms can be applied in conjunction with RAW
   mechanisms.

5.  Pro  Professional Audio and Video

5.1.  Use-Case  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
   capability, for instance, when the application provides interactive
   play,
   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") (ProAV) includes:

   *  Virtual Reality / Augmented Reality (VR/AR)

   *  Production and post-production systems systems, such as CD and Blu-ray
      disk mastering.

   *  Public address, media 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 packet lost packet has been identified identified, it
   is too late to proceed with packet re-transmission.  Buffering might
   be employed to provide a certain delay which that will allow for one or
   more re-transmissions, however re-transmissions.  However, such an approach is not viable in
   application
   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

   The

   Audio and video devices need the wireless communication to support
   video streaming via IEEE 802.11 wireless LAN LAN, for instance.  Wireless
   communications provide huge advantages in terms of simpler
   deployments in many scenarios, 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 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 with must have bounded (lowest possible) latency. 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)
   (Tracks) through the network to support redundancy.

5.4.1.  Non-latency critical considerations  Non-latency-critical Considerations

   For synchronized streaming, latency must be bounded, and therefore, bounded.  Therefore,
   depending on the actual requirements, this can be considered as
   latency critical.
   "latency critical".  However, the most critical requirement of this
   use-case
   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, 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  Use Case Description

   The gaming industry includes [IEEE80211RTA] real-time mobile gaming,
   wireless console gaming, wireless gaming controllers 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: Different from traditional games, 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 on-screen as users operate in game. in-game.  For good game
      experience, the end-to-end (E2E) 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 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, 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
      community, the main reasons are being high latency, lag spikes, and
      jitter.

   *  Wireless Gaming controllers: most

      Most controllers are now wireless for
      a the freedom of movement.Controllers movement.
      Controllers may interact with consoles or directly with the gaming
      server in the cloud.  A low and stable end-
      to-end end-to-end latency is here
      of predominant importance.

   *  Cloud Gaming: The cloud

      Cloud gaming requires low latency low-latency capability as the user commands
      in a game session need to be are sent back to the cloud server, server.  Then, the
      cloud server would update updates the game context depending on the received
      commands, and the cloud server would render renders the picture/video to be displayed at on the user devices
      devices, and stream 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 on at [IEEE80211RTA], we next
   summarize the main requirements in terms of latency, jitter 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 percent. 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

   Time-sensitive networking extensions: extensions,
      Extensions, such as time-
      aware time-aware shaping and redundancy redundancy, can be
      explored to address congestion and reliability problems present in
      wireless networks.  As an example, in haptics haptics, it is very
      important to minimize latency failures.

   *

   Priority tagging (Stream identification): one
      One basic requirement to provide better QoS for time-sensitive
      traffic is the capability to identify and differentiate time-sensitive time-
      sensitive packets from other (like best-effort) traffic.

   *

   Time-aware shaping: this
      This capability (defined in IEEE 802.1Qbv) consists of gates to
      control the opening/closing 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 close, therefore closes, therefore, eliminating
      congestion and ensuring that frames are delivered within the
      expected latency bounds.  Note though,  Though, note that while this requirement
      needs to be signalled signaled by RAW mechanisms, it would be actually be
      served by the lower layer.

   *

   Dual/multiple link: due
      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
      Congestion is a major cause of high/variable
      latency 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 today.  However, emerging time-
      sensitive 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  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
   use case might be considered as latency critical due to the need of
   bounded latency.  But  However, note that that, in most of these scenarios,
   part of the communication path is not wireless wireless, and DetNet mechanisms
   cannot be applied easily (e.g., when the public Internet is
   involved), and
   therefore in these cases, therefore, reliability is the critical requirement.

7.  Unmanned Aerial Vehicles and Vehicle-to-Vehicle platooning Platooning and
    control
    Control

7.1.  Use-Case  Use Case Description

   Unmanned Aerial Vehicles (UAVs) are becoming very popular for many
   different applications, including military and civil use-cases. use cases.  The
   term drone "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
   transportation
   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) 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/vehicles

   UAVs and other vehicles typically have various forms of wireless
   connectivity:

   *  Cellular: for communication with the control center, for remote
      maneuvering as well as
      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
   aforemention
   aforementioned UAV case, and therefore case.  Therefore, it is of interest for RAW.

7.2.  Specifics

   Some of the use-cases/tasks use cases and tasks involving UAVs require coordination
   among UAVs.  Others involve complex compute 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, however, 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, (like a drone offload 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 by of the UAVs themselves,
   requiring self-configuration capabilities.

   Heterogeneous types of traffic need to be supported, from extremely
   critical ones traffic types requiring ultra-low latency and high resiliency,
   resiliency to traffic requiring low-medium low-to-medium latency.

   When a given service is decomposed into functions -- (which are hosted
   at different UAVs -- chained, and chained), each link connecting two given
   functions would have a well-defined set of requirements (e.g.,
   latency,
   bandwidth bandwidth, and jitter) that must be met.

7.4.1.  Non-latency critical considerations  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, use case,
   the critical requirement is reliability, and and, only for some
   platooning and inter-drone communications communications, latency is critical.

8.  Edge Robotics control Control

8.1.  Use-Case  Use Case Description

   The Edge Robotics edge robotics scenario consists of several robots, deployed in a
   given area (like a shopping mall), 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
   do, as well as reducing
   perform, reduces the costs of robot manufacturing robot-manufacturing (due to their lower
   complexity), and enabling 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's 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:

   *  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
      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/tasks use cases and tasks involving robots might benefit from
   decomposition of a service in 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 robots -- chained, UAVs and chained), each link connecting two given
   functions would have a well-defined set of requirements (latency, bandwidth (e.g.,
   latency, bandwidth, and jitter) that must be met.

8.4.1.  Non-latency critical considerations  Non-latency-critical Considerations

   This use-case use case might combine multiple communication flows, with some
   of them being latency critical (like those related to robot control 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 Emergency Medical Vehicles

9.1.  Use-Case  Use Case Description

   An instrumented ambulance would be one that one or multiple network segments to which
   that are connected these to end systems such as:

   *  vital signs sensors attached to the casualty in the ambulance.
      Relay 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 (like (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  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 at the ambulance itself (local traffic),
   at a
   near edge cloud cloud, or at the general Internet/cloud.  Special care (at
   application level) have to be paid to ensuring ensure that sensitive data is
   not disclosed to unauthorized parties, parties by properly securing traffic
   and authenticating the communication ends.

9.3.  The Need for Wireless

   Local traffic between the first responders/ambulance 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 inter-network 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 inter-network internetwork needs to operate in damaged state (e.g. (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 cellphone 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  Non-latency-critical Considerations

   In this case, all applications identified do not require latency latency-
   critical communication, communication but do need high reliability and availability.

10.  Summary

   This document enumerates several use-cases use cases and applications that need
   RAW technologies, focusing on the requirements from reliability,
   availability
   availability, and latency.  Whereas  While some use-cases use cases are latency- latency
   critical, there are also several applications that are non-latency
   critical, not latency
   critical but that 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 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 deterministic networking, DetNet, which are generally applicable 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 (ACI), International, "Annual World
              Aitport Airport
              Traffic Report Report, 2019", November 2019,
              <https://store.aci.aero/product/annual-world-airport-
              traffic-report-2019/>.

   [ARINC858P1]
              ARINC, "INTERNET PROTOCOL SUITE
              SAE International, "Internet Protocol Suite (IPS) FOR AERONAUTICAL
              SAFETY SERVICES PART for
              Aeronautical Safety Services Part 1 AIRBORNE Airborne IPS SYSTEM TECHNICAL
              REQUIREMENTS", System
              Technical Requirements", ARINC858P1, June 2021,
              <https://www.sae.org/standards/content/arinc858p1/>.

   [DGT2021]  Menendez, J. M.,  Menéndez, J., "Drones: asi así es la vigilancia", vigilancia" [Drones: this
              is surveillance], January 2021,
              <https://revista.dgt.es/es/reportajes/2021/01ENERO/0126-
              Como-funciona-un-operativo-con-drones.shtml>.

   [DISNEY15] Wired, Kuang, C., "Disney's $1 Billion Bet on a Magical
              Wristband", March 2015,
              <https://www.wired.com/2015/03/disney-magicband/>.

   [EIP]      http://www.odva.org/,      ODVA, "EtherNet/IP provides users with the
              network tools to deploy standard Ethernet technology (IEEE
              802.3 combined with the TCP/IP Suite) for industrial
              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>. | ODVA Technologies | Industrial
              Automation", <https://www.odva.org/technology-standards/
              key-technologies/ethernet-ip/>.

   [FAA20]    U.S. Department of Transportation Transportation: Federal Aviation
              Administration (FAA), "Next Generation Air Transportation
              System", 2019,
              System (NextGen)", <https://www.faa.gov/nextgen/>.

   [Groshev2021]
              Groshev, M., Guimaraes, Guimarães, C., de la Oliva, A., and B. R. Gazda,
              "Dissecting the Impact of Information and Communication
              Technologies on Digital Twins as a Service", IEEE Access,
              vol. 9 ,
              Volume 9, DOI 10.1109/ACCESS.2021.3098109, July 2021,
              <https://doi.org/10.1109/ACCESS.2021.3098109>.

   [I-D.ietf-6tisch-terminology]
              Palattella, M. R., 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>.

   [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., S., Natale, F., Santamaria, C., Spyratos, S., and
              V. Michele,
              M. Vespe, "Estimating and projecting air passenger traffic
              during the COVID-19 coronavirus outbreak and its socio-
              economic impact", Safety Science 129 (2020)
              104791 , 2020. Science, Volume 129,
              DOI 10.1016/j.ssci.2020.104791, September 2020,
              <https://doi.org/10.1016/j.ssci.2020.104791>.

   [IAT20]    International Air Transport Association (IATA),    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] <https://www.iata.org/en/iata-
              repository/publications/economic-reports/airline-industry-
              economic-performance---november-2020---report/>.

   [ICAO2022] International Civil Aviation Organization (ICAO), "L-Band "CHAPTER
              13 L-Band Digital Aeronautical Communication Communications System
              (LDACS)", International Standards and Recommended Practices
              Practices, Annex 10 - Aeronautical Telecommunications, Vol. III -
              Volume III, Communication Systems , 2018.

   [IEEE802.1TSN]
              IEEE standard for Information Technology, Systems, 2022,
              <https://www.ldacs.com/wp-content/uploads/2023/03/
              WP06.AppA-DCIWG-6-LDACS_SARPs.pdf>.

   [IEEE802.1AS]
              IEEE, "IEEE
              802.1AS-2011 - IEEE Standard for Local and Metropolitan Area Networks - Timing
              Networks--Timing and Synchronization for Time-
              Sensitive Applications in Bridged Local Area Networks".

   [IEEE80211-RT-TIG]
              IEEE, "IEEE 802.11 Real Time Applications TIG Report",
              November 2018,
              <http://www.ieee802.org/11/Reports/rtatig_update.htm>. 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 ,
              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/ANSI,   ISA, "ISA100, Wireless Systems for Automation",
              <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
              juggling with a humanoid robot.", 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://ieeexplore.ieee.org/document/8703476>. <https://doi.org/10.1109/MCOM.2019.1800570>.

   [Maurer2022]
              Maurer,
              Mäurer, N., Guggemos, T., Ewert, T., Graupl, Gräupl, T., Schmitt,
              C., and S. Grundner-Culemann, "Security in Digital
              Aeronautical Communications A Comprehensive Gap Analysis",
              International Journal of Critical Infrastructure
              Protection, vol. 38 , Volume 38, DOI 10.1016/j.ijcip.2022.100549,
              September 2022,
              <https://doi.org/10.1016/j.ijcip.2022.100549>.

   [ODVA]     http://www.odva.org/, "The organization that supports
              network technologies built on the Common     ODVA, "ODVA | Industrial
              Protocol (CIP) including EtherNet/IP.". Automation | Technologies and
              Standards", <https://www.odva.org/>.

   [PLA14]    Plass, S., Hermenier, R., Luecke, Lücke, O., Gomez Depoorter, D.,
              Tordjman, T., Chatterton, M., Amirfeiz, M., Scotti, S.,
              Cheng, Y.J., Y., Pillai, P., Graeupl, Gräupl, T., Durand, F., Murphy, K.,
              Marriott, A., and A. Zaytsev, "Flight Trial Demonstration
              of Seamless Aeronautical Networking", IEEE Communications
              Magazine, vol. Volume 52, no. 5 , Issue 5,
              DOI 10.1109/MCOM.2014.6815902, May 2014. 2014,
              <https://doi.org/10.1109/MCOM.2014.6815902>.

   [PROFINET] http://us.profinet.com/technology/profinet/, PROFINET, "PROFINET is
              a standard Technology",
              <https://us.profinet.com/technology/profinet/>.

   [RAW-IND-REQS]
              Sofia, R. C., Kovatsch, M., and P. Mendes, "Requirements
              for industrial networking 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 automation.",
              <http://us.profinet.com/technology/profinet/>. 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
              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 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 "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 Ott, and Stewart Bryant for their valuable comments on
   previous
   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 Leganes, Madrid
   Spain
   Phone: +34 91624 6236
   Email: cjbc@it.uc3m.es
   URI:   http://www.it.uc3m.es/cjbc/

   Georgios Z. 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/