<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="info" consensus="true" ipr="trust200902" docName="draft-ietf-raw-use-cases-11"> docName="draft-ietf-raw-use-cases-11" number="9450" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="RAW Use-Case Scenarios">RAW Use-Cases</title> Use Cases">Reliable and Available Wireless (RAW) Use
    Cases</title>
    <seriesInfo name="RFC" value="9450"/>
    <author role="editor" fullname="Carlos J. Bernardos" initials="CJ." surname="Bernardos">
      <organization abbrev="UC3M">
         Universidad Carlos III de Madrid
      </organization>
      <address>
        <postal>
          <street>Av. Universidad, 30</street>
             <city>Leganes, Madrid</city>
          <city>Madrid</city>
          <code>28911</code>
          <country>Spain</country>
        </postal>
        <phone>+34 91624 6236</phone>
        <email>cjbc@it.uc3m.es</email>
        <uri>http://www.it.uc3m.es/cjbc/</uri>
      </address>
    </author>
    <author initials="G.Z." initials="G." surname="Papadopoulos" fullname="Georgios Z. Papadopoulos">
      <organization>IMT Atlantique</organization>
      <address>
        <postal>
            	<street>Office
          <extaddr>Office B00 - 114A</street> 114A</extaddr>
          <street>2 Rue de la Chataigneraie</street>
          <city>Cesson-Sevigne - Rennes</city>
          <code>35510</code>
             <country>FRANCE</country>
          <country>France</country>
        </postal>
        <phone>+33 299 12 70 04</phone>
        <email>georgios.papadopoulos@imt-atlantique.fr</email>
      </address>
    </author>
    <author initials="P" surname="Thubert" fullname="Pascal Thubert">
      <organization abbrev="Cisco">Cisco Systems, Inc</organization>
      <address>
        <postal>
            	<street>Building D</street>
          <extaddr>Building D</extaddr>
          <street>45 Allee des Ormes - BP1200 </street>
          <city>MOUGINS - Sophia Antipolis</city>
          <code>06254</code>
            	<country>FRANCE</country>
          <country>France</country>
        </postal>
        <phone>+33 497 23 26 34</phone>
        <email>pthubert@cisco.com</email>
      </address>
    </author>
    <author initials="F." surname="Theoleyre" fullname="Fabrice Theoleyre">
      <organization>CNRS</organization>
      <address>
        <postal>
            	<street>ICube
          <extaddr>ICube Lab, Pole API</street> API</extaddr>
          <street>300 boulevard Sebastien Brant - CS 10413</street>
          <city>Illkirch</city>
          <code>67400</code>
             	<country>FRANCE</country>
          <country>France</country>
        </postal>
        <phone>+33 368 85 45 33</phone>
        <email>fabrice.theoleyre@cnrs.fr</email>
        <uri>https://fabrice.theoleyre.cnrs.fr/</uri>
      </address>
    </author>

   <date/>

   <workgroup>RAW</workgroup>
    <date year="2023" month="August" />
    <area>rtg</area>
    <workgroup>raw</workgroup>
    <keyword>determinism</keyword>
    <keyword>availability</keyword>
    <keyword>routing</keyword>
    <keyword>path</keyword>

    <abstract>
   <t>
The
      <t>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.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction">

    <t>
Based numbered="true" toc="default">
      <name>Introduction</name>

      <t>Based on time, resource reservation, and policy enforcement by
      distributed
shapers, deterministic networking shapers <xref target="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
      applications on a converged enterprise infrastructure.
      </t>

    <t>
Deterministic networking
      <t>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.
      </t>

    <t>
Key
      <t>Key attributes of Deterministic networking include:

      <list style="symbols">
        <t>time DetNet include:</t>
      <ul spacing="normal">
        <li>time synchronization on all the nodes,</t>
        <t>multi-technology nodes,</li>
        <li>multi-technology path with co-channel interference minimization,</t>
        <t>frame
        minimization,</li>
        <li>frame preemption and guard time mechanisms to ensure a worst-case
        delay, and</t>
        <t>new and</li>
        <li>new traffic shapers shapers, both within and at the edge edge, to protect the network.</t>
      </list>

    </t>

    <t>
Wireless
        network.</li>
      </ul>
      <t>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.
    </t>

    <t>
The resources.</t>
      <t>The wireless and wired media are fundamentally different at the
      physical level,
and while level. While the generic Problem Statement in <xref target="RFC8557"/>
      target="RFC8557" format="default"/> 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.
    </t>

    <t>
So specifics.</t>
      <t>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 <xref
target="RFC8655"/>
      target="RFC8655" format="default"/> 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.
      </t>

    <t>
Purpose-built
      <t>Purpose-built wireless technologies such as <xref target="ISA100"/>, target="ISA100"
      format="default"/>, 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.
      </t>

    <t>
This
      <t>This is now changing (as detailed in <xref target="I-D.ietf-raw-technologies"/>:

      <list style="symbols">
        <t>
IMT-2020 target="I-D.ietf-raw-technologies"
      format="default"/>):</t>
      <ul spacing="normal">
        <li>IMT-2020 has recognized Ultra-Reliable Low-Latency Low Latency Communication
        (URLLC) as a key functionality for the upcoming 5G.
        </t>

        <t>
IEEE
        </li>
        <li>IEEE 802.11 has identified a set of real-applications real applications <xref
target="IEEE80211-RT-TIG"/>
        target="IEEE80211RTA" format="default"/>, which may use the
        IEEE802.11 standards. They typically emphasize strict end-to-end delay
        requirements.
        </t>

        <t>
The
        </li>
        <li>The IETF has produced an IPv6 stack for IEEE Std. 802.15.4 TimeSlotted
        Time-Slotted Channel Hopping (TSCH) and an architecture <xref target="RFC9030"/>
        target="RFC9030" format="default"/> that enables RAW on a shared MAC.
        </t>
      </list>
    </t>

    <!--FT: recent experiments with TSN + WiFi 7 -->

        <t>
Experiments
        </li>
      </ul>

        <t>Experiments have already been conducted with IEEE802.1 TSN over
        IEEE802.11be <xref
target="IEEE80211BE"/>. target="IEEE80211BE" format="default"/>.  This mode
        enables time synchronization, synchronization and time-aware scheduling (trigger based
        access mode) to support TSN flows.

        </t>

    <t>
This flows.</t>
      <t>This document extends the "Deterministic Networking use-cases" "<xref target="RFC8578" format="title"/>"
      document <xref
target="RFC8578"/> target="RFC8578" format="default"/> 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-case, (<xref target="RFC8578" sectionFormat="of" section="5"/>)
      use case, as the "Cellular Radio" (<xref target="RFC8578"
      sectionFormat="of" section="6"/>) 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.
      </t>
    </section>
    <section title="Aeronautical Communications">
    <t>
Aircraft numbered="true" toc="default">
      <name>Aeronautical Communications</name>
      <t>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-route high-bandwidth communications, whereas en route
      it's focused on high reliability, robustness robustness, and
range are the focus. range.
      </t>
      <section title="Problem Statement">
        <t>
Up numbered="true" toc="default">
        <name>Problem Statement</name>
        <t>Up to 2020, civil air traffic has had been growing constantly at a
        compound rate of 5.8% per year <xref target="ACI19"/> target="ACI19" format="default"/>,
        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 <xref target="IAT20"/>
        target="IAT20" format="default"/> <xref target="IAC20"/>. target="IAC20"
        format="default"/>. 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 <xref target="KEAV20"/> target="SESAR" format="default"/>
        <xref target="FAA20"/> target="FAA20" format="default"/>, 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 <xref
target="PLA14"/> target="PLA14" format="default"/> 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) LDACS <xref target="ICAO18"/>
        target="ICAO2022" format="default"/> <xref
target="I-D.ietf-raw-ldacs" target="RFC9372"
        format="default"/>.
        </t>

    <t>
Note
        <t>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 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 <xref target="Maurer2022" />. format="default"/>.
        </t>
      </section>
      <section title="Specifics"> numbered="true" toc="default">
        <name>Specifics</name>
        <t>
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
<xref target="fig_LDACS"/>: target="fig_LDACS" format="default"/>:
        </t>

        <figure title="The anchor="fig_LDACS">
          <name>The Future Communication Infrastructure (FCI): AeroMACS for Airport/Termina Maneuvering Area domain, LDACS A/G for Terminal Maneuvering/En-Route domain, LDACS A/G for En-Route/Oceanic, Remote, Polar domain, SatCOM for Oceanic, Remote, Polar domain domain communications"  anchor="fig_LDACS">
            <artwork>
                <![CDATA[ (FCI)</name>

<artwork name="" type="" align="left" alt=""><![CDATA[
 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
                ]]>
            </artwork>
]]></artwork>
</figure>

    </section>

    <section title="Challenges">
        <t>
This

<t>FCI includes:</t>
<ul spacing="compact">
  <li>AeroMACS for airport and terminal maneuvering area domains,</li>
  <li>LDACS Air/Ground for terminal maneuvering area and en route
  domains,</li>
  <li>LDACS Air/Ground for en route or oceanic, remote, and polar
  regions, and</li>
  <li>SatCOM for oceanic, remote, and polar regions.</li>
</ul>
      </section>
      <section numbered="true" toc="default">
        <name>Challenges</name>
        <t>This paradigm change brings a lot of new challenges:

          <list style="symbols">

            <t>
Efficiency: challenges:</t>
        <ul spacing="normal">
          <li>Efficiency: It is necessary to keep latency, time time, and data
          overhead of new aeronautical datalinks at data links to a minimum.
            </t>

            <t>
Modularity: minimum.</li>
          <li>Modularity: Systems in avionics usually operate for up to 30 years, thus
          years. Thus, solutions must be modular, easily adaptable adaptable, and updatable.
            </t>

            <t>
Interoperability:
          updatable.</li>
          <li>Interoperability: All 192 members of the international Civil Aviation
Organization (ICAO) ICAO must be able to
          use these solutions.
            </t>

            <t>
<!-- FT: dynamic topology (very high mobility)--> solutions.</li>
          <li>
	    Dynamicity: the The communication infrastructure needs to accommodate
	    mobile devices (airplanes) that move extremely fast.
            </t>

          </list>

        </t> fast.</li>
        </ul>

      </section>
      <section title="The numbered="true" toc="default">
        <name>The Need for Wireless">
        <t>
In Wireless</name>
        <t>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 traffic
        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.
        </t>
      </section>
      <section title="Requirements numbered="true" toc="default">
        <name>Requirements for RAW">

        <t>
Different RAW</name>
        <t>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 <xref
        target="ARINC858P1" />. format="default"/>. 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 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.
        </t>

        <t>
Overhead
        <t>Overhead needs to be kept at to a minimum since aeronautical data
        links provide comparatively small data rates on the order of kbit/s.
        </t>

        <t>
Policy
        <t>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.
        </t>
        <!-- BEGIN Non-latency critical considerations -->
      <section title="Non-latency critical considerations">

          <t>
Achieving numbered="true" toc="default">
          <name>Non-latency-critical Considerations</name>
          <t>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 <xref
          target="RFC9372" /> format="default"/> translates to a latency in the
          Forward Link (FL - Ground -> -&gt; Air) of 30-90 ms and a latency in
          the Reverse Link (RL - Air -> -&gt; 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.
          </t>
        </section>
        <!-- END Non-latency critical considerations -->

    </section>
    </section>
    <section title="Amusement Parks">

   <section title="Use-Case Description">

      <t>
The numbered="true" toc="default">
      <name>Amusement Parks</name>
      <section numbered="true" toc="default">
        <name>Use Case Description</name>
        <t>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).
        </t>

      <t>
Attractions
        <t>Attractions may rely on a large set of sensors and actuators, which
        react in real time. Typical applications comprise:
        </t>

      <t>
         <list style="symbols">
            <t>
Emergency:
        <ul spacing="normal">
          <li>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.
            </t>

            <t>
Video: detected.</li>
          <li>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.
            </t>

            <t>
Real-time
          tasks.</li>
          <li>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) <xref target="KOB12"/>.
            </t>

            <t>
Geolocation: target="KOB12"
          format="default"/>.</li>
          <li>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.
            </t>

            <t>
Predictive tracked.</li>
          <li>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.
            </t>
            <t>
Marketing: etc.</li>
          <li>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.
            </t>
         </list>

      </t> clients.</li>
        </ul>
      </section>
      <section title="Specifics">

      <t>
Amusement numbered="true" toc="default">
        <name>Specifics</name>
        <t>Amusement parks comprise a variable number of attractions, mostly
        outdoor, over a large geographical area. The IT infrastructure is
        typically multi-scale:

         <list style="symbols">

            <t>
Local multiscale:</t>

        <ul spacing="normal">
          <li>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 <xref
target="IEEE80211-RT-TIG"/>.
               </t>

            <t> target="IEEE80211RTA"
          format="default"/>.</li>
          <li>Wearable devices: Wearable mobile devices are free to move in the park. They
          exchange traffic locally (identification, personalization,
          multimedia) or globally (billing, child
tracking).
               </t>

            <t> child-tracking).</li>
          <li>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).
               </t>

         </list>

      </t> marketing).</li>
        </ul>
        <t>

        </t>
      </section>
      <section title="The numbered="true" toc="default">
        <name>The Need for Wireless">

        <t>
Removing Wireless</name>
        <t>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.
        </t>

        <t>
Some
        <t>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.
        </t>

        <t>
Wearable
        <t>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
        <xref target="DISNEY15"/> target="DISNEY15" format="default"/> 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.
        </t>
      </section>
      <!-- title="The Need for Wireless" -->

    <section title="Requirements numbered="true" toc="default">
        <name>Requirements for RAW">
        <t>
The RAW</name>
        <t>The network infrastructure must support heterogeneous traffic, with
        very different critical requirements. Thus, flow isolation must be
        provided.
        </t>

        <t>
The
        <t>The transmissions must be scheduled appropriately appropriately, even in the
        presence of mobile devices. While the <xref target="RFC9030"/> target="RFC9030"
        format="default"/> already proposes an architecture for synchronized,
        IEEE Std. 802.15.4 Time-Slotted Channel Hopping (TSCH) networks, the
        industry requires a multi-technology solution, solution that is able to
        guarantee end-to-end requirements across heterogeneous technologies, technologies
        with strict SLA Service Level Agreement (SLA) requirements.
        </t>

        <t>
Nowadays,
        <t>Nowadays, long-range wireless transmissions are used mostly for
        best-effort traffic. On the contrary, <xref target="IEEE802.1TSN"/> target="IEEE802.1AS"
        format="default"/> 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.
        </t>

        <t>
It
        <t>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 technologies (i.e., different radio technologies using
        overlapping spectrum, and therefore, potentially interfering to with each
        other).
        </t>
        <t>
It
        <t>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.
        </t>
        <!-- BEGIN Non-latency critical considerations -->
      <section title="Non-latency critical considerations"> numbered="true" toc="default">
          <name>Non-latency-critical Considerations</name>
          <t>
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).
          </t>
        </section>
        <!-- END Non-latency critical considerations -->

    </section>
    </section>
    <section title="Wireless numbered="true" toc="default">
      <name>Wireless for Industrial Applications"> Applications</name>
      <section title="Use-Case Description"> numbered="true" toc="default">
        <name>Use Case Description</name>

        <t>
        <!-- FT: several sensors may be attached to the PLC -->
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).
        </t>
      </section>
      <section anchor="indusspecif" title="Specifics"> numbered="true" toc="default">
        <name>Specifics</name>
        <section anchor="indusloops" title="Control Loops">

    <t>
Process numbered="true" toc="default">
          <name>Control Loops</name>
          <t>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.
          </t>

    <t>
In
          <t>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.
          </t>

    <t>
Additional
          <t>Additional details and use-cases use cases related to Industrial industrial
          applications and their RAW requirements can be found in <xref
          target="I-D.ietf-raw-industrial-requirements" />. format="default"/>.
          </t>

    </section><!--"Control
        </section>
        <!--"Control Loops"-->

   <section anchor="indusdiags" title="Monitoring numbered="true" toc="default">
          <name>Monitoring and diagnostics">
   <t>
A Diagnostics</name>
          <t>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.
          </t>

   <t>
Inside
          <t>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.
          </t>

   </section><!--
        </section>
        <!-- "Monitoring and diagnostics" -->

   </section>
      <!-- title="Speficicities title="Specifics -->

   <section title="The numbered="true" toc="default">
        <name>The Need for Wireless">

   <t>
Wires Wireless</name>
        <t>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.
        </t>

   <t>
When
        <t>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.
        </t>

   <t>
Even
        <t>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 <xref
target="RFC7554"/> target="RFC7554"
        format="default"/> 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.
        </t>
      </section>
      <!-- title="The Need for Wireless" -->

   <section title="Requirements numbered="true" toc="default">
        <name>Requirements for RAW">

    <t>
As RAW</name>
        <t>As stated by the <xref target="RFC8557"> target="RFC8557" format="default">
        "Deterministic Networking Problem
Statement" </xref>, Statement"</xref>, a deterministic
        network is backwards compatible with (capable of transporting)
        statistically multiplexed traffic while preserving the properties of
        the accepted deterministic flows. While the <xref
target="RFC9030">6TiSCH Architecture</xref> target="RFC9030"
        format="default">"6TiSCH Architecture"</xref> 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
        <xref
target="I-D.ietf-6tisch-terminology"/>) target="I-D.ietf-6tisch-terminology" format="default"/>) 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.
        </t>

    <t>
Over the course of the
        <t>Over recent years, major Industrial Protocols (e.g., industrial protocols
        have been migrating towards Ethernet and IP. (For example, <xref target="ODVA"/> with
        EtherNet/IP <xref target="EIP"/> and <xref
target="PROFINET"/>) have been migrating towards Ethernet and IP. target="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 <xref
        target="MAR19" />. format="default"/>.
        </t>
        <!-- BEGIN Non-latency critical considerations -->
      <section title="Non-latency critical considerations">

          <t>
Monitoring numbered="true" toc="default">
          <name>Non-latency-critical Considerations</name>
          <t>Monitoring and diagnostics applications do not require latency critical
communications,
          latency-critical 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.
          </t>
        </section>
        <!-- END Non-latency critical considerations -->

    </section>
    </section>
    <section title="Pro numbered="true" toc="default">
      <name>Professional Audio and Video"> Video</name>
      <section title="Use-Case Description">
    <t>
Many numbered="true" toc="default">
        <name>Use Case Description</name>
        <t>Many devices support audio and video streaming <xref
        target="RFC9317" /> format="default"/> 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.
        </t>

    <t>
The
        <t>The professional audio and video industry ("ProAV") (ProAV) includes:
      <list style="symbols">

        <t>
Virtual
        </t>
        <ul spacing="normal">
          <li>Virtual Reality / Augmented Reality (VR/AR)
        </t>
        <t>
Production </li>
          <li>Production and post-production systems systems, such as CD and Blu-ray
          disk mastering.
        </t>

        <t>
Public mastering.</li>
          <li>Public address, media media, and emergency systems at large venues
          (e.g., airports, train stations, stadiums, and theme parks).
        </t>

      </list>

    </t> parks).</li>
        </ul>
      </section>
      <section title="Specifics"> numbered="true" toc="default">
        <name>Specifics</name>
        <section title="Uninterrupted numbered="true" toc="default">
          <name>Uninterrupted Stream Playback">
      <t>
Considering Playback</name>
          <t>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.
          </t>
        </section>
        <section title="Synchronized numbered="true" toc="default">
          <name>Synchronized Stream Playback">

      <t>
In Playback</name>
          <t>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.
          </t>
        </section>
      </section>
      <section title="The numbered="true" toc="default">
        <name>The Need for Wireless">

    <t>
The Wireless</name>
        <t>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.
        </t>

    <t>
Deployed
        <t>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.
        </t>
      </section>
      <!-- title="The Need for Wireless" -->

   <section title="Requirements numbered="true" toc="default">
        <name>Requirements for RAW">

     <t>
The RAW</name>
        <t>The network infrastructure needs to support heterogeneous types of
        traffic (including QoS).
        </t>

     <t>
Content
	<t>Content delivery with must have bounded (lowest possible) latency.
     </t>

     <t>
The latency (to the lowest possible latency).</t>
        <t>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.
        </t>
        <!-- BEGIN Non-latency critical considerations -->
      <section title="Non-latency critical considerations">

          <t>
For numbered="true" toc="default">
          <name>Non-latency-critical Considerations</name>
          <t>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.
          </t>
        </section>
        <!-- END Non-latency critical considerations -->

    </section>
    </section>
    <section title="Wireless Gaming">

   <section title="Use-Case Description">

    <t>
The numbered="true" toc="default">
      <name>Wireless Gaming</name>
      <section numbered="true" toc="default">
        <name>Use Case Description</name>
        <t>The gaming industry includes <xref target="IEEE80211RTA" />
        format="default"/> 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:

      <list style="symbols">

        <t>
Real-time Mobile Gaming: Different from traditional games, real time four:</t>
        <ul spacing="normal">
          <li><t>Real-time mobile gaming:</t>
	  <t>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.
        </t>

        <t>
Wireless Console Gaming: while communication.</t></li>
          <li><t>Wireless console gaming:</t>
	  <t>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.
        </t>

        <t>
Wireless jitter.</t></li>
          <li><t>Wireless Gaming controllers: most controllers:</t>
	  <t>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 latency
	  is here of predominant importance.
        </t>

        <t>
Cloud Gaming: The cloud importance.</t></li>
          <li><t>Cloud Gaming:</t>
      <t>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.
        </t>

      </list>

    </t>
	  wirelessly.</t></li>
        </ul>
      </section>
      <section title="Specifics">

    <t>
While numbered="true" toc="default">
        <name>Specifics</name> <t>While a lot of details can be found on at <xref
        target="IEEE80211RTA" />, format="default"/>, we next summarize the main
        requirements in terms of latency, jitter jitter, and packet loss:

      <list style="symbols">

        <t>
Intra </t>
        <ul spacing="normal">
          <li>Intra Basic Service Set (BSS) latency is less than 5 ms.
        </t>

        <t>
Jitter ms.</li>
          <li>Jitter variance is less than 2 ms.
        </t>

        <t>
Packet ms.</li>
          <li>Packet loss is less than 0.1 percent.
        </t>

      </list>

    </t> 0.1%.</li>
        </ul>
      </section>
      <section title="The numbered="true" toc="default">
        <name>The Need for Wireless">

    <t>
Gaming Wireless</name>
        <t>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.
<!-- FT=: wireless controllers (haptic, etc.) -->
Wireless controllers are the rule in modern gaming, with increasingly
sophisticated interactions (e.g., haptic feedback, augmented reality).
        </t>
      </section>
      <section title="Requirements for RAW">

    <t>

      <list style="symbols">

        <t>
Time sensitive numbered="true" toc="default">
        <name>Requirements for RAW</name>
        <dl spacing="normal" newline="true">
          <dt>Time-sensitive networking extensions: extensions, extensions:</dt>
	  <dd>Extensions, such as 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.
        </t>

        <t>
Priority failures.</dd>
          <dt>Priority tagging (Stream identification): one identification):</dt>
	  <dd>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.
        </t>

        <t>
Time-aware shaping: this traffic.</dd>
          <dt>Time-aware shaping:</dt>
	  <dd>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.
        </t>

        <t>
Dual/multiple link: due layer.</dd>
          <dt>Dual/multiple link:</dt>
	  <dd>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.
        </t>

        <t>
Admission Control: congestion
	  issue.</dd>
          <dt>Admission Control:</dt>
	  <dd>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
	  applications are highly susceptible to increased latency and
	  jitter. To better control QoS, it is important to control access to
	  the network resources.
        </t>

      </list>

    </t> resources.</dd>
        </dl>
        <!-- BEGIN Non-latency critical considerations -->
      <section title="Non-latency critical considerations">

          <t>
Depending numbered="true" toc="default">
          <name>Non-latency-critical Considerations</name>
          <t>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.
          </t>
        </section>
        <!-- END Non-latency critical considerations -->

    </section>
    </section>
    <section title="Unmanned numbered="true" toc="default">
      <name>Unmanned Aerial Vehicles and Vehicle-to-Vehicle platooning Platooning and control">
      Control</name>
      <section title="Use-Case Description">

      <t>
Unmanned numbered="true" toc="default">
        <name>Use Case Description</name>
        <t>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.
        </t>
        <t>
          <!-- FT: ref for ths spanish app?  (I also inserted the medicine app, quite popular in Africa) -->
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 <xref
target="DGT2021" />), format="default"/>), 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.
        </t>

      <t>
Many
        <t>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.
      </t>

      <t>
UAVs/vehicles types.</t>
        <t>UAVs and other vehicles typically have various forms of wireless
        connectivity:
        </t>

      <t>

         <list style="symbols">

            <t>Cellular:
        <ul spacing="normal">
          <li>Cellular: for communication with the control center, for remote
maneuvering as well as
          maneuvering, and monitoring of the drone;
            </t>

            <t>IEEE drone;</li>
          <li>IEEE 802.11: for inter-drone communications (i.e., platooning)
          and providing connectivity to other devices (i.e., acting as Access Point).
            </t>

         </list>

      </t>

      <t>
Note
          Point).</li>
        </ul>
        <t>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.
        </t>
      </section>
      <section title="Specifics">

      <t>
Some numbered="true" toc="default">
        <name>Specifics</name>
        <t>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.
        </t>

      <t>
Remote
        <t>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).
        </t>
      </section>
      <section title="The numbered="true" toc="default">
        <name>The Need for Wireless">

        <t>
UAVs Wireless</name>
        <t>UAVs cannot be connected through any type of wired media, so it is
        obvious that wireless is needed.
        </t>
      </section>
      <!-- title="The Need for Wireless" -->

   <section title="Requirements numbered="true" toc="default">
        <name>Requirements for RAW">

        <t>
The RAW</name>
        <t>The network infrastructure is composed by of the UAVs themselves,
        requiring self-configuration capabilities.
        </t>

        <t>
Heterogeneous
        <t>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.
        </t>

        <t>
When
        <t>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.
        </t>
        <!-- BEGIN Non-latency critical considerations -->
      <section title="Non-latency critical considerations">

          <t>
Today's numbered="true" toc="default">
          <name>Non-latency-critical Considerations</name>
          <t>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.
          </t>
        </section>
        <!-- END Non-latency critical considerations -->

   </section>
    </section>
    <section title="Edge numbered="true" toc="default">
      <name>Edge Robotics control"> Control</name>
      <section title="Use-Case Description">

      <t>
The Edge Robotics numbered="true" toc="default">
        <name>Use Case Description</name>
        <t>The 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).
        </t>
        <t>
          <!-- FT: search and rescue app -->
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.
        </t>

      <t>
Robots
        <t>Robots would have various forms of wireless connectivity:
        </t>

      <t>
         <list style="symbols">

            <t>
IEEE 802.11: for connection to the edge and also inter-robot communications
(i.e., for coordinated actions).
            </t>

            <t>
Cellular:
        <ul spacing="normal">
          <li>Cellular: as an additional communication link to the edge,
          though primarily as backup, since ultra-low latency is needed.
            </t>

         </list>

      </t>
          </li>
          <li>IEEE 802.11: for connection to the edge and also inter-robot
          communications (i.e., for coordinated actions).</li>
        </ul>
      </section>
      <section title="Specifics">

      <t>
Some numbered="true" toc="default">
        <name>Specifics</name>
        <t>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.
        </t>

      <t>
Robot
        <t>Robot control is an activity requiring very low latency (0.5-20 ms
        <xref target="Groshev2021" />) format="default"/>) between the robot and
        the location where the control intelligence resides (which might be
        the edge or another robot).
        </t>
      </section>
      <section title="The numbered="true" toc="default">
        <name>The Need for Wireless">

        <t>
Deploying Wireless</name>
        <t>Deploying robots in scenarios such as shopping malls for the
        applications mentioned cannot be done via wired connectivity.
        </t>
      </section>
      <!-- title="The Need for Wireless" -->

    <section title="Requirements numbered="true" toc="default">
        <name>Requirements for RAW">

        <t>
The RAW</name>
        <t>The network infrastructure needs to support heterogeneous types of
        traffic, from robot control to video streaming.
        </t>

        <t>
When
        <t>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.
        </t>
        <!-- BEGIN Non-latency critical considerations -->
      <section title="Non-latency critical considerations">

          <t>
This use-case numbered="true" toc="default">
          <name>Non-latency-critical Considerations</name>
          <t>This 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.
          </t>
        </section>
        <!-- END Non-latency critical considerations -->

    </section>
    </section>

<!-- [2020-07-11] cjbc: text added -->
<section title="Instrumented emergency medical vehicles">

    <section title="Use-Case Description">

      <t> numbered="true" toc="default">
      <name>Instrumented Emergency Medical Vehicles</name>
      <section numbered="true" toc="default">
        <name>Use Case Description</name>

<!--[rfced] To follow up, should "be" be "have"?

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

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

        <list style="symbols" >
-->
        <t>
vital An instrumented ambulance would be one or multiple network
        segments that are connected to end systems such as:</t>
<ul spacing="normal">
  <li>vital signs sensors attached to the casualty in the ambulance. Relay ambulance to relay
  medical data to hospital emergency room,
          </t>

          <t> room,</li>
          <li>a radio-navigation sensor to relay position data to various
          destinations including dispatcher,
          </t>

          <t>
voice
          </li>
          <li>voice communication for ambulance attendant (like (likely to consult
          with ER doctor), and
          </t>

          <t>
voice
          </li>
          <li>voice communication between driver and dispatcher.
          </t>

        </list>

      </t>

      <t>
The
          </li>
        </ul>
        <t>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.
        </t>
      </section>
      <section title="Specifics">

      <t>
What numbered="true" toc="default">
        <name>Specifics</name>
        <t>What we have today is multiple communication systems to reach the
        vehicle via:

        <list style="symbols" >

          <t>
A </t>
        <ul spacing="normal">
          <li>a dispatching system,
          </t>

          <t>
a </li>
          <li>a cellphone for the attendant,
          </t>

          <t>
a </li>
          <li>a special purpose telemetering system for medical data,
          </t>

          <t>
etc.
          </t>

        </list>

      </t>

      <t>
This </li>
          <li>etc.  </li>
        </ul>
        <t>This redundancy of systems does not contribute to availability.
        </t>

      <t>
Most
        <t>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.
        </t>
      </section>
      <section title="The numbered="true" toc="default">
        <name>The Need for Wireless">

        <t>
Local Wireless</name>
        <t>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.
        </t>
      </section>
      <!-- title="The Need for Wireless" -->

    <section title="Requirements numbered="true" toc="default">
        <name>Requirements for RAW">

      <t>
We RAW</name>
        <t>We can derive some pertinent requirements from this scenario:

        <list style="symbols" >

          <t>
High </t>
        <ul spacing="normal">
          <li>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.
          </t>

          <t>
The inter-network
          </li>
          <li>The 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.

          </t>

<!--
          <t>
E2E security, both authenticity and confidentiality, is required of
traffic. All data needs to be authenticated; some like medical needs to be
confidential.
          </t>
-->

          <t>
The  </li>

          <li>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.
          </t>

        </list>

      </t>
          </li>
        </ul>
        <!-- BEGIN Non-latency critical considerations -->
      <section title="Non-latency critical considerations">

          <t>
In numbered="true" toc="default">
          <name>Non-latency-critical Considerations</name>
          <t>In this case, all applications identified do not require latency critical
communication,
          latency-critical communication but do need high reliability and
          availability.
          </t>
        </section>
        <!-- END Non-latency critical considerations -->

    </section>
    </section>
    <section anchor="sec:summary" title="Summary">

      <t>
This anchor="sec_summary" numbered="true" toc="default">
      <name>Summary</name>
      <t>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-critical, latency critical,
      there are also several applications that are non-latency critical, not latency critical but that
      do pose strict reliability and availability requirements.
      </t>
    </section>
    <section anchor="sec:iana" title="IANA Considerations">

      <t>
This anchor="sec_iana" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.  </t>
    </section>
    <section anchor="sec:security" title="Security Considerations">

      <t>
This anchor="sec_security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>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. <xref
      target="RFC9055" /> format="default"/> provides a comprehensive discussion
      of security considerations in the context of
deterministic networking, DetNet, which are generally applicable
      also applicable to RAW.
      </t>
    </section>

    <section anchor="sec:acks" title="Acknowledgments">

      <t>
Nils M&auml;urer, Thomas Gr&auml;upl and Corinna Schmitt have contributed
significantly

  </middle>
  <back>

<displayreference target="I-D.ietf-raw-industrial-requirements" to="RAW-IND-REQS"/>
<displayreference target="I-D.ietf-6tisch-terminology" to="6TiSCH-TERMS"/>
<displayreference target="I-D.ietf-raw-technologies" to="RAW-TECHNOS"/>

 <references>
      <name>Informative References</name>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2475.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7554.xml"/>
      <!-- 6TiSCH TSCH -->
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8557.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8578.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9030.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9055.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9372.xml"/>

<!-- [I-D.ietf-raw-industrial-requirements] IESG state Expired -->

      <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-raw-industrial-requirements.xml"/>

<!-- [I-D.ietf-6tisch-terminology] IESG state Expired. Updated to this document, providing input long version because missing editor role for Palattella -->

<reference anchor="I-D.ietf-6tisch-terminology" target="https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-terminology-10">
<front>
<title>Terms Used in IPv6 over the Aeronautical
communication section. Rex Buddenberg has also contributed to the document,
providing input to the Emergency: instrumented emergency vehicle section.
      </t>

      <t>
The authors would like to thank Toerless Eckert, Xavi Vilajosana Guillen, Rute
Sofia, Corinna Schmitt, Victoria Pritchard, John Scudder, Joerg Ott and
Stewart Bryant for their valuable comments on previous versions TSCH mode of this document.
      </t>

      <t>
The work IEEE 802.15.4e</title>
<author initials="MR." surname="Palattella" fullname="Maria Rita Palattella" role="editor">
<organization>LIST</organization>
</author>
<author initials="P." surname="Thubert" fullname="Pascal Thubert">
<organization>cisco</organization>
</author>
<author initials="T." surname="Watteyne" fullname="Thomas Watteyne">
<organization>Analog Devices</organization>
</author>
<author initials="Q." surname="Wang" fullname="Qin Wang">
<organization>Univ. of Carlos J. Bernardos in this document has been partially supported by
the Horizon Europe PREDICT-6G (Grant 101095890) Sci. and UNICO I+D 6G-DATADRIVEN-04 project.
      </t>

    </section>

</middle>

<back>

<!--
   <references title="Normative References">

   </references>
-->

 <references title="Informative References">

      <?rfc include="reference.RFC.7554"?> Tech. Beijing</organization>
</author>
<date month="March" day="2" year="2018"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-6tisch-terminology-10"/>
</reference>

<!-- 6TiSCH TSCH [I-D.ietf-raw-technologies] IESG state I-D Exists. Updated to long version because missing editor role for Thubert -->
      <?rfc include='reference.RFC.8557'?>
      <?rfc include='reference.RFC.8578'?>
      <?rfc include='reference.RFC.8655'?>
      <?rfc include='reference.RFC.9030'?>
      <?rfc include='reference.RFC.9055'?>
      <?rfc include='reference.I-D.ietf-raw-ldacs'?>
      <?rfc include='reference.I-D.ietf-raw-industrial-requirements'?>
      <?rfc include='reference.I-D.ietf-6tisch-terminology'?>
      <?rfc include='reference.I-D.ietf-raw-technologies'?>
      <?rfc include='reference.RFC.9317'?>
      <?rfc include='reference.RFC.9372'?>

<reference anchor="I-D.ietf-raw-technologies" target="https://datatracker.ietf.org/doc/html/draft-ietf-raw-technologies-06">
<front>
<title>Reliable and Available Wireless Technologies</title>
<author initials="P." surname="Thubert" fullname="Pascal Thubert" role="editor">
<organization>Cisco Systems, Inc</organization>
</author>
<author initials="D." surname="Cavalcanti" fullname="Dave Cavalcanti">
<organization>Intel Corporation</organization>
</author>
<author initials="X." surname="Vilajosana" fullname="Xavier Vilajosana">
<organization>Universitat Oberta de Catalunya</organization>
</author>
<author initials="C." surname="Schmitt" fullname="Corinna Schmitt">
<organization>Research Institute CODE, UniBw M</organization>
</author>
<author initials="J." surname="Farkas" fullname="János Farkas">
<organization>Ericsson</organization>
</author>
<date month="November" day="30" year="2022"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-raw-technologies-06"/>
</reference>

      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9317.xml"/>

      <reference anchor="DISNEY15" target="https://www.wired.com/2015/03/disney-magicband/">
        <front>
          <title>Disney's $1 Billion Bet on a Magical Wristband</title>
               <author>
          <author surname="Kuang" initials="C.">
            <organization>Wired</organization>
          </author>
          <date year="2015" month="March"/>
        </front>
      </reference>

<reference anchor="KEAV20" anchor="SESAR" target="https://www.sesarju.eu/"> <!--LDACS-->
           <front>
               <title>Single European Sky ATM Research
          <title>SESAR Joint Undertaking</title>
          <author>
                   <organization>T. Keaveney and C. Stewart</organization>
            <organization>SESAR</organization>
          </author>
               <date year="2019"/>
        </front>
      </reference>

      <reference anchor="FAA20" target="https://www.faa.gov/nextgen/ "> target="https://www.faa.gov/nextgen/">
        <!--LDACS-->
           <front>
          <title>Next Generation Air Transportation System</title> System (NextGen)</title>
          <author>
            <organization>U.S. Department of Transportation Transportation: Federal Aviation
            Administration (FAA)</organization>
          </author>
               <date year="2019"/>
        </front>
      </reference>

      <reference anchor="PLA14">
        <!--LDACS-->
           <front>
          <title>Flight Trial Demonstration of Seamless Aeronautical Networking
               </title> Networking</title>
          <author initials="S." surname="Plass"/>
          <author initials="R." surname="Hermenier"/>
          <author initials="O." surname="Luecke"/> surname="Lücke"/>
          <author initials="D." surname="Gomez Depoorter"/>
          <author initials="T." surname="Tordjman"/>
          <author initials="M." surname="Chatterton"/>
          <author initials="M." surname="Amirfeiz"/>
          <author initials="S." surname="Scotti"/>
          <author initials="Y.J." initials="Y." surname="Cheng"/>
          <author initials="P." surname="Pillai"/>
          <author initials="T." surname="Graeupl"/> surname="Gräupl"/>
          <author initials="F." surname="Durand"/>
          <author initials="K." surname="Murphy"/>
          <author initials="A." surname="Marriott"/>
          <author initials="A." surname="Zaytsev"/>
          <date year="2014" month="May"/>
        </front>
	<seriesInfo name='IEEE name="DOI" value="10.1109/MCOM.2014.6815902"/>
        <refcontent>IEEE Communications Magazine, vol. Volume 52, no. 5' value=''/> Issue 5</refcontent>
      </reference>

      <reference anchor="ICAO18"> <!--LDACS--> anchor="ICAO2022" target="https://www.ldacs.com/wp-content/uploads/2023/03/WP06.AppA-DCIWG-6-LDACS_SARPs.pdf">
        <front>
               <title>L-Band
          <title>CHAPTER 13 L-Band Digital Aeronautical Communication Communications
	  System (LDACS)
               </title> (LDACS)</title>
          <author initials="" surname="International surname="">
            <organization>International Civil Aviation Organization (ICAO)"/>
	    (ICAO)</organization>
          </author>
          <date year="2018"/> year="2022"/>
        </front>
           <seriesInfo name='International
        <refcontent>International Standards and Recommended Practices Practices,
	Annex 10 - Aeronautical Telecommunications, Vol. III - Volume III, Communication Systems' value=''/>
       </reference>

      <reference anchor="IEEE80211-RT-TIG" target="http://www.ieee802.org/11/Reports/rtatig_update.htm">
         <front>
            <title>IEEE 802.11 Real Time Applications TIG Report</title>
            <author>
               <organization>IEEE</organization>
            </author>
            <date year="2018" month="November"/>
         </front>
	Systems</refcontent>
        </reference>

      <reference anchor="KOB12" target="https://doi.org/10.1109/HUMANOIDS.2012.6651623"> anchor="KOB12">
        <front>
          <title>Playing catch and juggling with a humanoid robot.</title> robot</title>
          <author initials="J." surname="Kober" fullname="J. Kober"></author> surname="Kober"/>
          <author initials="M." surname="Glisson" fullname="M. Glisson"></author> surname="Glisson"/>
          <author initials="M." surname="Mistry" fullname="M. Mistry"></author> surname="Mistry"/>
          <date month="November" year="2012"/>
        </front>
	<seriesInfo name="DOI" value="10.1109/HUMANOIDS.2012.6651623"/>
      </reference>

      <reference anchor="ODVA"> anchor="ODVA" target="https://www.odva.org/">
        <front>
            <title>The organization that supports network technologies built on
            the Common
          <title>ODVA | Industrial Protocol (CIP) including EtherNet/IP.</title> Automation | Technologies and Standards</title>
          <author>
               <organization>http://www.odva.org/</organization>
            <organization>ODVA</organization>
          </author>
            <date></date>
          <date/>
        </front>
      </reference>

      <reference anchor="PROFINET"  target="http://us.profinet.com/technology/profinet/"> target="https://us.profinet.com/technology/profinet/">
        <front>
          <title>PROFINET is a standard for industrial networking in
            automation. </title> Technology</title>
          <author>
               <organization>http://us.profinet.com/technology/profinet/</organization>
            <organization>PROFINET</organization>
          </author>
            <date></date>
          <date/>
        </front>
      </reference>

      <reference anchor="EIP"  target="http://www.odva.org/Portals/0/Library/Publications_Numbered/PUB00138R3_CIP_Adv_Tech_Series_EtherNetIP.pdf"> target="https://www.odva.org/technology-standards/key-technologies/ethernet-ip/">
        <front>
          <title> 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.</title>
          <title>EtherNet/IP | ODVA Technologies | Industrial Automation</title>
          <author>
               <organization>http://www.odva.org/</organization>
            <organization>ODVA</organization>
          </author>
            <date></date>
          <date/>
        </front>
      </reference>

      <reference anchor="ISA100" target="https://www.isa.org/isa100/">
        <front>
          <title>ISA100, Wireless Systems for Automation</title>
          <author>
               <organization>ISA/ANSI</organization>
            <organization>ISA</organization>
          </author>
          <date/>
        </front>
      </reference>

      <reference anchor="ACI19" target="https://store.aci.aero/product/annual-world-airport-traffic-report-2019/">
        <front>
          <title>Annual World Aitport Airport Traffic Report Report, 2019</title>
          <author>
            <organization>Airports Council International (ACI)</organization> International</organization>
          </author>
          <date year="2019" month="November"/> year="2019"/>
        </front>
      </reference>

      <reference anchor="IAT20" target="https://www.iata.org/en/iata-repository/publications/economic-reports/airline-industry-economic-performance---november-2020---report/">
        <front>
          <title>Economic Performance of the Airline Industry</title>
          <author>
                   <organization>International Air Transport Association (IATA)</organization>
            <organization>IATA</organization>
          </author>
          <date year="2020" month="November"/>
        </front>
      </reference>

      <reference anchor="IAC20">
        <front>
          <title>Estimating and projecting air passenger traffic during the
          COVID-19 coronavirus outbreak and its socio-
                   economic impact
               </title> socio-economic impact</title>
          <author initials="S.M." initials="S." surname="Iacus"/>
          <author initials="F." surname="Natale"/>
          <author initials="C." surname="Santamaria"/>
          <author initials="S." surname="Spyratos"/>
          <author initials="V." surname="Michele"/> initials="M." surname="Vespe"/>
          <date year="2020" /> month="September" year="2020"/>
        </front>
	<seriesInfo name='Safety Science 129 (2020) 104791' value=''/> name="DOI" value="10.1016/j.ssci.2020.104791"/>
        <refcontent>Safety Science, Volume 129</refcontent>
      </reference>

      <reference anchor="IEEE802.1TSN"> anchor="IEEE802.1AS">
        <front>
          <title>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
           </title> Applications</title>
          <author>
              <organization>IEEE standard for Information Technology</organization>
            <organization>IEEE</organization>
          </author>
           <date/>
          <date month="June" year="2020"/>
        </front>
	<seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9121845"/>
	<seriesInfo name="IEEE" value="802.1AS-2020"/>
      </reference>

      <reference anchor="IEEE80211BE" target="https://www.ieee802.org/1/files/public/docs2020/new-Cavalcanti-802-1TSN-over-802-11-1120-v02.pdf">
        <front>
          <title>802.1 TSN over 802.11 with updates from developments in 802.11be
          </title>
          <author initials="D." surname="Cavalcanti" fullname="D. Cavalcanti"></author> surname="Cavalcanti"/>
          <author initials="G." surname="Venkatesan" fullname="G. Venkatesan"></author> surname="Venkatesan"/>
          <date year="2020" month="November" /> month="November"/>
        </front>
        <seriesInfo name='IEEE
        <refcontent>IEEE plenary meeting' value=''/> meeting</refcontent>
      </reference>

      <reference anchor="IEEE80211RTA">
        <front>
          <title>IEEE 802.11 Real Time Applications TIG Report
          </title>
          <author>
            <organization>IEEE standard for Information
            Technology</organization>
          </author>
          <date year="2018" month="November" /> month="November"/>
        </front>
      </reference>

      <reference anchor="MAR19" target="https://ieeexplore.ieee.org/document/8703476"> anchor="MAR19">
        <front>
          <title>A Square Peg in a Round Hole: The Complex Path for Wireless
          in the Manufacturing Industry</title>
          <author initials="B." surname="Martinez" fullname="B. Martinez"></author> surname="Martinez"/>
          <author initials="C." surname="Cano" fullname="C. Cano"></author> surname="Cano"/>
          <author initials="X." surname="Vilajosana" fullname="X. Vilajosana"></author> surname="Vilajosana"/>
          <date month="April" year="2019"/>
        </front>
	<seriesInfo name="DOI" value="10.1109/MCOM.2019.1800570"/>
	<refcontent>IEEE Communications Magazine, Volume 57, Issue
	4</refcontent>
      </reference>

      <reference quoteTitle="false" anchor="DGT2021" target="https://revista.dgt.es/es/reportajes/2021/01ENERO/0126-Como-funciona-un-operativo-con-drones.shtml">
        <front>
            <title>Drones: asi
          <title>"Drones: así es la vigilancia</title> vigilancia" [Drones: this is surveillance]</title>
          <author initials="J. M." surname="Menendez" fullname="J. M. Menendez"></author> initials="J." surname="Menéndez"/>
          <date month="January" year="2021"/>
        </front>
      </reference>

      <reference anchor="Groshev2021" target="https://doi.org/10.1109/ACCESS.2021.3098109"> anchor="Groshev2021">
        <front>
          <title>Dissecting the Impact of Information and Communication
          Technologies on Digital Twins as a Service</title>
          <author initials="M." surname="Groshev" fullname="M. Groshev"></author> surname="Groshev"/>
          <author initials="C." surname="Guimaraes" fullname="C. Guimaraes"></author> surname="Guimarães"/>
          <author initials="A." surname="de la Oliva" fullname="A. de la Oliva"></author> Oliva"/>
          <author initials="B." surname="Gazda" fullname="B. Gazda"></author> initials="R." surname="Gazda"/>
          <date month="July" year="2021"/>
        </front>
	<seriesInfo name='IEEE name="DOI" value="10.1109/ACCESS.2021.3098109"/>
        <refcontent>IEEE Access, vol. 9' value=''/> Volume 9</refcontent>
      </reference>

      <reference anchor="Maurer2022" target="https://doi.org/10.1016/j.ijcip.2022.100549"> anchor="Maurer2022">
        <front>
          <title>Security in Digital Aeronautical Communications A
          Comprehensive Gap Analysis</title>
          <author initials="N." surname="Maurer" fullname="N. Maurer"></author> surname="Mäurer"/>
	  <author initials="T." surname="Ewert" fullname="T. Ewert"></author> surname="Guggemos"/>
          <author initials="T." surname="Graupl" fullname="T. Graupl"></author> surname="Ewert"/>
          <author initials="T." surname="Gräupl"/>
          <author initials="C." surname="Schmitt" fullname="C. Schmitt"></author> surname="Schmitt"/>
          <author initials="S." surname="Grundner-Culemann" fullname="S. Grundner-Culemann"></author> surname="Grundner-Culemann"/>
          <date month="September" year="2022"/>
        </front>
	<seriesInfo name='International name="DOI" value="10.1016/j.ijcip.2022.100549"/>
        <refcontent>International Journal of Critical Infrastructure
        Protection,
vol. 38' value=''/> Volume 38</refcontent>
      </reference>

      <reference anchor="ARINC858P1" target="https://www.sae.org/standards/content/arinc858p1/">
        <front>
            <title>INTERNET PROTOCOL SUITE
          <title>Internet Protocol Suite (IPS) FOR AERONAUTICAL SAFETY SERVICES PART for Aeronautical Safety
          Services Part 1 AIRBORNE Airborne IPS SYSTEM TECHNICAL REQUIREMENTS</title> System Technical Requirements</title>
          <author>
              <organization>ARINC</organization>
            <organization>SAE International</organization>
          </author>
          <date month="June" year="2021"/>
        </front>
	<refcontent>ARINC858P1</refcontent>
      </reference>

    </references>

    <section anchor="sec_acks" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t><contact fullname="Nils Mäurer"/>, <contact fullname="Thomas
      Gräupl"/>, and <contact fullname="Corinna Schmitt"/> have contributed
      significantly to this document, providing input for the Aeronautical
      communication section. <contact fullname="Rex Buddenberg"/> has also
      contributed to the document, providing input to the "Instrumented
      Emergency Medical Vehicles" section.</t>

      <t>The authors would like to thank <contact fullname="Toerless
      Eckert"/>, <contact fullname="Xavi Vilajosana Guillen"/>, <contact
      fullname="Rute Sofia"/>, <contact fullname="Corinna Schmitt"/>, <contact
      fullname="Victoria Pritchard"/>, <contact fullname="John Scudder"/>,
      <contact fullname="Joerg Ott"/>, and <contact fullname="Stewart Bryant"/>
      for their valuable comments on draft versions of this document.</t>
      <t>The work of <contact fullname="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.</t>
    </section>

  </back>

</rfc>