rfc9450xml2.original.xml   rfc9450.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" 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"?>
<rfc category="info" ipr="trust200902" docName="draft-ietf-raw-use-cases-11">
<front> <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<title abbrev="RAW Use-Case Scenarios">RAW Use-Cases</title> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category=" info" consensus="true" ipr="trust200902" docName="draft-ietf-raw-use-cases-11" n umber="9450" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="3 " symRefs="true" sortRefs="true" version="3">
<author role="editor" fullname="Carlos J. Bernardos" <front>
initials="CJ." <title abbrev="RAW Use Cases">Reliable and Available Wireless (RAW) Use
surname="Bernardos"> Cases</title>
<organization abbrev="UC3M"> <seriesInfo name="RFC" value="9450"/>
<author role="editor" fullname="Carlos J. Bernardos" initials="CJ." surname=
"Bernardos">
<organization abbrev="UC3M">
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
</organization> </organization>
<address> <address>
<postal> <postal>
<street>Av. Universidad, 30</street> <street>Av. Universidad, 30</street>
<city>Leganes, Madrid</city> <city>Madrid</city>
<code>28911</code> <code>28911</code>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<phone>+34 91624 6236</phone> <phone>+34 91624 6236</phone>
<email>cjbc@it.uc3m.es</email> <email>cjbc@it.uc3m.es</email>
<uri>http://www.it.uc3m.es/cjbc/</uri> <uri>http://www.it.uc3m.es/cjbc/</uri>
</address> </address>
</author> </author>
<author initials="G." surname="Papadopoulos" fullname="Georgios Papadopoulos
<author initials="G.Z." surname="Papadopoulos" fullname="Georgios Z. Papa ">
dopoulos"> <organization>IMT Atlantique</organization>
<organization>IMT Atlantique</organization> <address>
<address> <postal>
<postal> <extaddr>Office B00 - 114A</extaddr>
<street>Office B00 - 114A</street> <street>2 Rue de la Chataigneraie</street>
<street>2 Rue de la Chataigneraie</street> <city>Cesson-Sevigne - Rennes</city>
<city>Cesson-Sevigne - Rennes</city> <code>35510</code>
<code>35510</code> <country>France</country>
<country>FRANCE</country> </postal>
</postal> <phone>+33 299 12 70 04</phone>
<phone>+33 299 12 70 04</phone> <email>georgios.papadopoulos@imt-atlantique.fr</email>
<email>georgios.papadopoulos@imt-atlantique.fr</email> </address>
</address> </author>
</author> <author initials="P" surname="Thubert" fullname="Pascal Thubert">
<organization abbrev="Cisco">Cisco Systems, Inc</organization>
<author initials="P" surname="Thubert" fullname="Pascal Thubert"> <address>
<organization abbrev="Cisco">Cisco Systems, Inc</organization> <postal>
<address> <extaddr>Building D</extaddr>
<postal> <street>45 Allee des Ormes - BP1200 </street>
<street>Building D</street> <city>MOUGINS - Sophia Antipolis</city>
<street>45 Allee des Ormes - BP1200 </street> <code>06254</code>
<city>MOUGINS - Sophia Antipolis</city> <country>France</country>
<code>06254</code> </postal>
<country>FRANCE</country> <phone>+33 497 23 26 34</phone>
</postal> <email>pthubert@cisco.com</email>
<phone>+33 497 23 26 34</phone> </address>
<email>pthubert@cisco.com</email> </author>
</address> <author initials="F." surname="Theoleyre" fullname="Fabrice Theoleyre">
</author> <organization>CNRS</organization>
<address>
<author initials="F." surname="Theoleyre" fullname="Fabrice Theoleyre"> <postal>
<organization>CNRS</organization> <extaddr>ICube Lab, Pole API</extaddr>
<address> <street>300 boulevard Sebastien Brant - CS 10413</street>
<postal> <city>Illkirch</city>
<street>ICube Lab, Pole API</street> <code>67400</code>
<street>300 boulevard Sebastien Brant - CS 10413</street> <country>France</country>
<city>Illkirch</city> </postal>
<code>67400</code> <phone>+33 368 85 45 33</phone>
<country>FRANCE</country> <email>fabrice.theoleyre@cnrs.fr</email>
</postal> <uri>https://fabrice.theoleyre.cnrs.fr/</uri>
<phone>+33 368 85 45 33</phone> </address>
<email>fabrice.theoleyre@cnrs.fr</email> </author>
<uri>https://fabrice.theoleyre.cnrs.fr/</uri> <date year="2023" month="August" />
</address> <area>rtg</area>
</author> <workgroup>raw</workgroup>
<keyword>determinism</keyword>
<date/> <keyword>availability</keyword>
<keyword>routing</keyword>
<workgroup>RAW</workgroup> <keyword>path</keyword>
<abstract>
<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 cannot be solved with wires and justify the extra effort of
going wireless. This document presents wireless use-cases (such as aeronautical
communications, amusement parks, industrial applications, pro audio and video,
gaming, UAV and V2V control, edge robotics and emergency vehicles) demanding
reliable and available behavior.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Based on time, resource reservation, and policy enforcement by distributed
shapers, deterministic networking (DetNet) provides the capability to carry spec
ified
unicast or multicast data streams for real-time applications with extremely low
data loss rates and bounded latency, so as to support time-sensitive and
mission-critical applications on a converged enterprise infrastructure.
</t>
<t>
Deterministic networking aims at eliminating packet loss
for a committed bandwidth while ensuring a worst case end-to-end latency,
regardless of the network conditions and across technologies. By leveraging
lower layer (Layer 2 and below) capabilities, L3 can exploit the use of a servic
e layer,
steering over multiple technologies, and using media independent signaling to
provide high reliability, precise time delivery, and rate enforcement.
Deterministic networking 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., using time-shared resources (bandwidth and buffers)
per circuit, and/or by shaping and/or scheduling the packets at every hop.
</t>
<t>
Key attributes of Deterministic networking include:
<list style="symbols">
<t>time synchronization on all the nodes,</t>
<t>multi-technology path with co-channel interference minimization,</t>
<t>frame preemption and guard time mechanisms to ensure a worst-case del
ay, and</t>
<t>new traffic shapers within and at the edge to protect the network.</t
>
</list>
</t>
<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 and Available Wireless, and r
efers to the mechanisms aimed for providing high reliability and availability fo
r IP connectivity over a wireless medium. Making Wireless Reliable and Available
is even more
challenging than it is with wires, due to the numerous causes of loss in
transmission that add up to the congestion losses and the delays caused by
overbooked shared resources.
</t>
<t>
The wireless and wired media are fundamentally different at the physical level,
and while the generic Problem Statement <xref target="RFC8557"/> for DetNet
applies to the wired as well as the wireless medium, the methods to achieve RAW
necessarily differ from those used to support Time-Sensitive Networking over
wires, e.g., due to the wireless radio channel specifics.
</t>
<t>
So far, open standards for deterministic networking have prevalently been
focused on wired media, with Audio/Video Bridging (AVB) and Time Sensitive
Networking (TSN) at the IEEE and DetNet <xref
target="RFC8655"/> at the IETF. But wires cannot be used in
several cases, including mobile or rotating devices, rehabilitated
industrial buildings, wearable or in-body sensory devices, vehicle automation
and multiplayer gaming.
</t>
<t>
Purpose-built wireless technologies such as <xref target="ISA100"/>, which
incorporates IPv6, were developed and deployed to cope with the lack of open
standards, but they yield a high cost in OPEX and CAPEX and are limited to
very few industries, e.g., process control, concert instruments or racing.
</t>
<t>
This is now changing <xref target="I-D.ietf-raw-technologies"/>:
<list style="symbols">
<t>
IMT-2020 has recognized Ultra-Reliable Low-Latency Communication (URLLC) as a
key functionality for the upcoming 5G.
</t>
<t>
IEEE 802.11 has identified a set of real-applications <xref
target="IEEE80211-RT-TIG"/> which may use the IEEE802.11 standards. They
typically emphasize strict end-to-end delay requirements.
</t>
<t>
The IETF has produced an IPv6 stack for IEEE Std. 802.15.4 TimeSlotted Channel
Hopping (TSCH) and an architecture <xref target="RFC9030"/>
that enables RAW on a shared MAC.
</t>
</list>
</t>
<!--FT: recent experiments with TSN + WiFi 7 --> <abstract>
<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 cannot be solved with wires and
justify the extra effort of going wireless. This document presents
wireless use cases (such as aeronautical communications, amusement
parks, industrial applications, pro audio and video, gaming, Unmanned Aeri
al Vehicle (UAV) and vehicle-to-vehicle (V2V)
control, edge robotics, and emergency vehicles), demanding reliable and
available behavior.
</t>
</abstract>
</front>
<middle>
<section numbered="true" toc="default">
<name>Introduction</name>
<t> <t>Based on time, resource reservation, and policy enforcement by
Experiments have already been conducted with IEEE802.1 TSN over IEEE802.11be <xr distributed shapers <xref target="RFC2475"/>, Deterministic Networking (De
ef tNet) provides the
target="IEEE80211BE"/>. capability to carry specified unicast or multicast data streams for
This mode enables time synchronization, and time-aware scheduling real-time applications with extremely low data loss rates and bounded
(trigger based access mode) to support TSN flows. latency so as to support time-sensitive and mission-critical
applications on a converged enterprise infrastructure.
</t>
<t>DetNet aims at eliminating packet loss for a committed bandwidth,
while ensuring a worst-case end-to-end latency, regardless of the
network conditions and across technologies. By leveraging lower layer
(Layer 2 (L2) and below) capabilities, Layer 3 (L3) can exploit the use
of a service layer, steering over multiple technologies and using media
independent signaling to provide high reliability, precise time
delivery, and rate enforcement. DetNet can be seen as
a set of new Quality of Service (QoS) guarantees of worst-case
delivery. IP networks become more deterministic when the effects of
statistical multiplexing (jitter and collision loss) are mostly
eliminated.
This requires a tight control of the physical resources
to maintain the amount of traffic within the physical capabilities of
the underlying technology, e.g., by using time-shared resources
(bandwidth and buffers) per circuit, by shaping or scheduling
the packets at every hop, or by using a combination of these
techniques.
</t>
<t>Key attributes of DetNet include:</t>
<ul spacing="normal">
<li>time synchronization on all the nodes,</li>
<li>multi-technology path with co-channel interference
minimization,</li>
<li>frame preemption and guard time mechanisms to ensure a worst-case
delay, and</li>
<li>new traffic shapers, both within and at the edge, to protect the
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 and Available Wireless" and refers to the mechanisms aimed for
providing high reliability and availability for IP connectivity over a
wireless medium. Making wireless reliable and available is even more
challenging than it is with wires, due to the numerous causes of loss in
transmission that add up to the congestion losses and due to the delays
caused by overbooked shared resources.</t>
<t>The wireless and wired media are fundamentally different at the
physical level. While the generic Problem Statement in <xref
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 far, open standards for DetNet have prevalently
been focused on wired media, with Audio Video Bridging (AVB) and
Time-Sensitive Networking (TSN) at the IEEE and DetNet <xref
target="RFC8655" format="default"/> at the IETF. However, wires cannot
be used in several cases, including mobile or rotating devices,
rehabilitated industrial buildings, wearable or in-body sensory devices,
vehicle automation, and multiplayer gaming.
</t>
<t>Purpose-built wireless technologies such as <xref 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
Operational Expenditure (OPEX) and Capital Expenditure (CAPEX) and are
limited to very few industries, e.g., process control, concert
instruments, or racing.
</t>
<t>This is now changing (as detailed in <xref target="I-D.ietf-raw-technol
ogies"
format="default"/>):</t>
<ul spacing="normal">
<li>IMT-2020 has recognized Ultra-Reliable Low Latency Communication
(URLLC) as a key functionality for the upcoming 5G.
</li>
<li>IEEE 802.11 has identified a set of real applications <xref
target="IEEE80211RTA" format="default"/>, which may use the
IEEE802.11 standards. They typically emphasize strict end-to-end delay
requirements.
</li>
<li>The IETF has produced an IPv6 stack for IEEE Std. 802.15.4
Time-Slotted Channel Hopping (TSCH) and an architecture <xref
target="RFC9030" format="default"/> that enables RAW on a shared MAC.
</li>
</ul>
<t>Experiments have already been conducted with IEEE802.1 TSN over
IEEE802.11be <xref target="IEEE80211BE" format="default"/>. This mode
enables time synchronization and time-aware scheduling (trigger based
access mode) to support TSN flows.</t>
<t>This document extends the "<xref target="RFC8578" format="title"/>"
document <xref target="RFC8578" format="default"/> and describes several
additional use cases that require "reliable/predictable and available"
flows over wireless links and possibly complex multi-hop paths called
"Tracks". This is covered mainly by the "Wireless for Industrial
Applications" (<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, while the "Wireless
for Industrial Applications" use case certainly covers an area of
interest for RAW, it is limited to IPv6 over the TSCH mode of IEEE
802.15.4e (6TiSCH), and thus, its scope is narrower than the use cases
described next in this document.
</t>
</section>
<section numbered="true" toc="default">
<name>Aeronautical Communications</name>
<t>Aircraft are currently connected to Air-Traffic Control (ATC) and
Airline Operational Control (AOC) via voice and data communication
systems through all phases of a flight. Within the airport terminal,
connectivity is focused on high-bandwidth communications, whereas en route
it's focused on high reliability, robustness, and range.
</t>
<section numbered="true" toc="default">
<name>Problem Statement</name>
<t>Up to 2020, civil air traffic had been growing constantly at a
compound rate of 5.8% per year <xref target="ACI19" format="default"/>,
and despite the severe impact of the COVID-19 pandemic, air-traffic
growth is expected to resume very quickly in post-pandemic times <xref
target="IAT20" format="default"/> <xref target="IAC20"
format="default"/>. Thus, legacy systems in Air-Traffic Management
(ATM) are likely to reach their capacity limits, and the need for new
aeronautical communication technologies becomes apparent. Especially
problematic is the saturation of VHF band in high density areas in
Europe, the US, and Asia <xref target="SESAR" format="default"/>
<xref target="FAA20" format="default"/>, calling for suitable new
digital approaches such as the Aeronautical Mobile Airport Communication
s System (AeroMACS) for airport communications,
SatCOM for remote domains, and the L-band Digital Aeronautical Communica
tion System (LDACS) as the long-range terrestrial
aeronautical communication system. Making the frequency spectrum's
usage a more efficient transition from analog voice to digital data
communication <xref 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 terrestrial
communications, already in the process of being standardized in the
International Civil Aviation Organization (ICAO), is LDACS <xref
target="ICAO2022" format="default"/> <xref target="RFC9372"
format="default"/>.
</t> </t>
<t>Note that the large scale of the planned Low Earth Orbit (LEO)
<t> constellations of satellites can provide fast end-to-end latency rates a
This document extends the "Deterministic Networking use-cases" document <xref nd high
target="RFC8578"/> and describes several additional use-cases which require data-rates at a reasonable cost, but they also pose challenges, such as
"reliable/predictable and available" flows over wireless links and possibly frequent handovers, high interference, and a diverse range of system
complex multi-hop paths called Tracks. This is covered mainly by the "Wireless users, which can create security issues since both safety-critical and
for Industrial Applications" use-case, as the "Cellular Radio" is mostly not safety-critical communications can take place on the same
dedicated to the (wired) link part of a Radio Access Network (RAN). Whereas system. Some studies suggest that LEO constellations could be a
the "Wireless for Industrial Applications" use-case certainly covers an area of complete solution for aeronautical communications, but they do not
interest for RAW, it is limited to 6TiSCH, and thus its scope is narrower than offer solutions for the critical issues mentioned
the use-cases described next in this document. earlier. Additionally, of the three communication domains defined by
</t> ICAO, only passenger entertainment services can currently be provided
using these constellations. Safety-critical aeronautical
</section> communications require reliability levels above 99.999%, which is
higher than that required for regular commercial data
<section title="Aeronautical Communications"> links. Therefore, addressing the issues with LEO-based SatCOM is
<t> necessary before these solutions can reliably support safety-critical
Aircraft are currently connected to ATC (Air-Traffic Control) and AOC (Airline data transmission <xref target="Maurer2022" format="default"/>.
Operational Control) 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 reliability, robustness and
range are the focus.
</t>
<section title="Problem Statement">
<t>
Up to 2020, civil air traffic has been growing constantly at a compound rate of
5.8% per year <xref target="ACI19"/> and despite the severe impact of the
COVID-19 pandemic, air traffic growth is expected to resume very quickly in
post-pandemic times <xref target="IAT20"/> <xref target="IAC20"/>. Thus, legacy
systems in air traffic management (ATM) are likely to reach their capacity
limits and the need for new aeronautical communication technologies becomes
apparent. Especially problematic is the saturation of VHF band in high density
areas in Europe, the US, and Asia <xref target="KEAV20"/> <xref target="FAA20"/>
calling for suitable new digital approaches such as AeroMACS for airport
communications, SatCOM for remote domains, and LDACS as long-range terrestrial
aeronautical communication system. Making the frequency spectrum's usage more
efficient a transition from analog voice to digital data communication <xref
target="PLA14"/> is necessary to cope with the expected growth of civil aviation
and its supporting infrastructure. A promising candidate for long range
terrestrial communications, already in the process of being standardized in the
International Civil Aviation Organization (ICAO), is the L-band Digital
Aeronautical Communication System (LDACS) <xref target="ICAO18"/> <xref
target="I-D.ietf-raw-ldacs" format="default"/>.
</t> </t>
</section>
<t> <section numbered="true" toc="default">
Note that the large scale of the planned low Earth orbit (LEO) constellations ca <name>Specifics</name>
n provide fast end-to-end latency rates and high data-rates at a reasonable cost
, but they also pose challenges such as frequent handovers, high-interference, a
nd a diverse range of system users, which can create security issues since both
safety-critical and non-safety-critical communications can take place on the sam
e system. Some studies suggest that LEO constellations could be a complete solut
ion for aeronautical communications, but they do not offer solutions for the cri
tical issues mentioned earlier. Additionally, of the three communication domains
defined by ICAO, only passenger entertainment services can currently be provide
d using these constellations. Safety-critical aeronautical communications requir
e reliability levels above 99.999%, which is higher than that required for regul
ar commercial data links. Therefore, addressing the issues with LEO-based SatCOM
is necessary before these solutions can reliably support safety-critical data t
ransmission <xref target="Maurer2022" />.
</t>
</section>
<section title="Specifics">
<t> <t>
During the creation process of new communication system, analog voice is During the creation process of a new communication system, analog voice is
replaced by digital data communication. This sets a paradigm shift from analog replaced by digital data communication. This sets a paradigm shift from analog
to digital wireless communications and supports the related trend towards to digital wireless communications and supports the related trend towards
increased autonomous data processing that the Future Communications increased autonomous data processing that the Future Communications
Infrastructure (FCI) in civil aviation must provide. The FCI is depicted in Infrastructure (FCI) in civil aviation must provide. The FCI is depicted in
<xref target="fig_LDACS"/>: <xref target="fig_LDACS" format="default"/>:
</t> </t>
<figure title="The Future Communication Infrastructure (FCI): AeroMACS f <figure anchor="fig_LDACS">
or Airport/Termina Maneuvering Area domain, LDACS A/G for Terminal Maneuvering/E <name>The Future Communication Infrastructure (FCI)</name>
n-Route domain, LDACS A/G for En-Route/Oceanic, Remote, Polar domain, SatCOM for
Oceanic, Remote, Polar domain domain communications" anchor="fig_LDACS"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>
<![CDATA[
Satellite Satellite
# # # #
# # # # # #
# # # # # #
# # # # # #
# # # # # #
# # # # # #
# # # # # #
# Satellite-based # # # Satellite-based # #
# Communications # # # Communications # #
skipping to change at line 307 skipping to change at line 298
# | LDACS A/G (|) | # | LDACS A/G (|) |
# Communications in | | # Communications in | |
# and around airports | | # and around airports | |
# AeroMACS (-) | | # AeroMACS (-) | |
# | | # | |
# Aircraft-------------+ | | # Aircraft-------------+ | |
# | | | # | | |
# | | | # | | |
# Ground network | | Ground network | # Ground network | | Ground network |
SatCOM <---------------------> Airport <----------------------> LDACS SatCOM <---------------------> Airport <----------------------> LDACS
ground ground ground ground ground ground
transceiver transceiver transceiver transceiver transceiver transceiver
]]> ]]></artwork>
</artwork> </figure>
</figure>
</section>
<section title="Challenges">
<t>
This paradigm change brings a lot of new challenges:
<list style="symbols">
<t>
Efficiency: It is necessary to keep latency, time and data overhead of new aeron
autical datalinks at a minimum.
</t>
<t>
Modularity: Systems in avionics usually operate up to 30 years, thus solutions
must be modular, easily adaptable and updatable.
</t>
<t>
Interoperability: All 192 members of the international Civil Aviation
Organization (ICAO) must be able to use these solutions.
</t>
<t>
<!-- FT: dynamic topology (very high mobility)-->
Dynamicity: the communication infrastructure needs to accommodate mobile devices
(airplanes)
that move extremely fast.
</t>
</list> <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:</t>
<ul spacing="normal">
<li>Efficiency: It is necessary to keep latency, time, and data
overhead of new aeronautical data links to a minimum.</li>
<li>Modularity: Systems in avionics usually operate for up to 30
years. Thus, solutions must be modular, easily adaptable, and
updatable.</li>
<li>Interoperability: All 192 members of the ICAO must be able to
use these solutions.</li>
<li>
Dynamicity: The communication infrastructure needs to accommodate
mobile devices (airplanes) that move extremely fast.</li>
</ul>
</section>
<section numbered="true" toc="default">
<name>The Need for Wireless</name>
<t>In a high-mobility environment, such as aviation, the envisioned
solutions to provide worldwide coverage of data connections with
in-flight aircraft require a multi-system, multi-link, multi-hop
approach. Thus, air, ground, and space-based data links that provide
these technologies will have to operate seamlessly together to cope
with the increasing needs of data exchange between aircraft,
air-traffic controller, airport infrastructure, airlines, air network
service providers (ANSPs), and so forth. Wireless technologies have to
be used to tackle this enormous need for a worldwide digital
aeronautical data link infrastructure.
</t>
</section>
<section numbered="true" toc="default">
<name>Requirements for RAW</name>
<t>Different safety levels need to be supported. All network traffic
handled by the Airborne Internet Protocol Suite (IPS) System are not
equal, and the QoS requirements of each network traffic flow must be
considered n order to avoid having to support QoS requirements at the
granularity of data flows. These flows are grouped into classes that
have similar requirements, following the Diffserv approach <xref
target="ARINC858P1" format="default"/>. These classes are referred to
as Classes of Service (CoS), and the flows within a class are treated
uniformly from a QoS perspective. Currently, there are at least eight
different priority levels (CoS) that can be assigned to packets. For
example, a high-priority message requiring low latency and high
resiliency could be a "WAKE" warning indicating two aircraft are
dangerously close to each other, while a less safety-critical message
with low-to-medium latency requirements could be the "WXGRAPH" service
providing graphical weather data.
</t>
<t>Overhead needs to be kept to a minimum since aeronautical data
links provide comparatively small data rates on the order of kbit/s.
</t>
<t>Policy needs to be supported when selecting data links. The focus
of RAW here should be on the selectors that are responsible for the
track a packet takes to reach its end destination. This would minimize
the amount of routing information that must travel inside the network
because of precomputed routing tables, with the selector being
responsible for choosing the most appropriate option according to
policy and safety.
</t> </t>
<!-- BEGIN Non-latency critical considerations -->
<section 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, 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
is not latency critical from that view point. On the other hand,
given the controlled environment, end-to-end mechanisms can be
applied to guarantee bounded latency where needed.
</t>
</section>
<!-- END Non-latency critical considerations -->
</section> </section>
<section title="The Need for Wireless">
<t>
In a high mobility environment such as aviation, the envisioned solutions to
provide worldwide coverage of data connections with in-flight aircraft require a
multi-system, multi-link, multi-hop approach. Thus air, ground and space-based
datalink providing technologies will have to operate seamlessly together to cope
with the increasing needs of data exchange between aircraft, air traffic
controller, airport infrastructure, airlines, air network service providers
(ANSPs) and so forth. Wireless technologies have to be used to tackle this enorm
ous need for a worldwide digital aeronautical datalink infrastructure.
</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Requirements for RAW"> <name>Amusement Parks</name>
<section numbered="true" toc="default">
<t> <name>Use Case Description</name>
Different safety levels need to be supported. All network traffic handled by the <t>The digitalization of amusement parks is expected to significantly
Airborne Internet Protocol Suite (IPS) System is not equal and the Quality of S decrease the cost for maintaining the attractions. Such deployment is
ervice (QoS) requirements of each network traffic flow must be considered n orde a mix between multimedia (e.g., Virtual and Augmented Reality and
r to avoid having to support QoS requirements at the granularity of data flows, interactive video environments) and non-multimedia applications (e.g,
these flows are grouped into classes that have similar requirements, following t access control, industrial automation for a roller coaster).
he DiffServ approach <xref target="ARINC858P1" />. These classes are referred to
as Classes of Service (CoS) and flows within a class are treated uniformly from
a QoS perspective. Currently, there are at least eight different priority level
s (CoS) that can be assigned to packets. For example, a high-priority message re
quiring low latency and high resiliency could be a "WAKE" warning indicating two
aircraft are dangerously close to each other, while a less safety-critical mess
age with low-medium latency requirements could be the "WXGRAPH" service providin
g graphical weather data.
</t> </t>
<t>Attractions may rely on a large set of sensors and actuators, which
<t> react in real time. Typical applications comprise:
Overhead needs to be kept at a minimum since aeronautical data links provide
comparatively small data rates on the order of kbit/s.
</t> </t>
<ul spacing="normal">
<li>Emergency: the safety of the operators and visitors has to be
preserved, and the attraction must be stopped appropriately when a
failure is detected.</li>
<li>Video: augmented and virtual realities are integrated in the
attraction. Wearable mobile devices (e.g., glasses and virtual
reality headsets) need to offload one part of the processing
tasks.</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"
format="default"/>.</li>
<li>Geolocation: visitors are tracked with a personal wireless tag,
so that their user experience is improved. This requires special
care to ensure that visitors' privacy is not breached, and users are
anonymously tracked.</li>
<li>Predictive maintenance: statistics are collected to predict the
future failures or to compute later more complex statistics about
the attraction's usage, the downtime, etc.</li>
<li>Marketing: to improve the customer experience, owners may
collect a large amount of data to understand the behavior and the
choices of their clients.</li>
</ul>
</section>
<section 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 multiscale:</t>
<ul spacing="normal">
<li>Local area: The sensors and actuators controlling the
attractions are colocated. Control loops trigger only local
traffic, with a small end-to-end delay, typically less than 10 ms,
like classical industrial systems <xref 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).</li>
<li>Edge computing: Computationally intensive applications offload som
e 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).</li>
</ul>
<t> <t>
Policy needs to be supported when selecting data links. The focus of RAW here
should be on the selectors, responsible for the track a packet takes to
reach its end destination. This would minimize the amount of routing information
that must travel inside the network because of precomputed routing tables with
the selector being responsible for choosing the most appropriate option
according to policy and safety.
</t>
<!-- BEGIN Non-latency critical considerations -->
<section title="Non-latency critical considerations">
<t>
Achieving low latency is a requirement for aeronautics communications, though
the expected latency is not extremely low and what is important is to keep
the overall latency bounded under a certain threshold. Low latency in LDACS comm
unications <xref target="RFC9372" /> translates to a latency in the Forward Link
(FL - Ground -> Air) of 30-90 ms and a latency in the Reverse Link (RL - Air ->
Ground) of 60-120 ms. This use-case is not
latency-critical from that view point. On the other hand, given the controlled
environment, end-to-end mechanisms can be applied to guarantee bounded latency
where needed.
</t>
</t>
</section> </section>
<!-- END Non-latency critical considerations --> <section numbered="true" toc="default">
<name>The Need for Wireless</name>
</section> <t>Removing cables helps to easily change the configuration of the
attractions or upgrade parts of them at a lower cost. The attraction
</section> can be designed modularly and can upgrade or insert novel modules
later on in the life cycle of the attraction. Novelty of attractions
<section title="Amusement Parks"> tends to increase the attractiveness of an amusement park, encouraging
previous visitors to regularly visit the park.
<section title="Use-Case Description"> </t>
<t>Some parts of the attraction are mobile, like trucks of a
<t> roller-coaster or robots. Since cables are prone to frequent failures
The digitalization of Amusement Parks is expected to decrease significantly the in this situation, wireless transmissions are recommended.
cost for maintaining the attractions. </t>
Such deployment is a mix between multimedia (e.g., Virtual and Augmented Reality <t>Wearable devices are extensively used for a user experience
, personalization. They typically need to support wireless
interactive video environments) and non-multimedia applications (e.g, industrial transmissions. Personal tags may help to reduce the operating costs
automation for a roller-coaster, access control). <xref target="DISNEY15" format="default"/> and increase the number
</t> of charged services provided to the audience (e.g., VIP tickets or
interactivity). Some applications rely on more sophisticated wearable
<t> devices, such as digital glasses or Virtual Reality (VR) headsets for
Attractions may rely on a large set of sensors and actuators, which react in an immersive experience.
real time. Typical applications comprise:
</t>
<t>
<list style="symbols">
<t>
Emergency: the safety of the operators / visitors has to be preserved and the
attraction must be stopped appropriately when a failure is detected.
</t>
<t>
Video: augmented and virtual realities are integrated in the attraction.
Wearable mobile devices (e.g., glasses, virtual reality headset) need to offload
one part of the processing tasks.
</t>
<t>
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: visitors are tracked with a personal wireless tag so that their use
r
experience is improved. This requires special care to ensure that visitors' priv
acy is not breached, and users are anonymously tracked.
</t>
<t>
Predictive maintenance: statistics are collected to predict the future failures,
or to compute later more complex statistics about the attraction's usage, the
downtime, etc.
</t>
<t>
Marketing: to improve the customer experience, owners may collect a large amount
of data to understand the behavior, and the choice of their clients.
</t>
</list>
</t>
</section>
<section title="Specifics">
<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 area: the sensors and actuators controlling the attractions are co-located
.
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>
Wearable mobile devices are free to move in the park. They exchange traffic loca
lly
(identification, personalization, multimedia) or globally (billing, child
tracking).
</t>
<t>
Computationally intensive applications offload some tasks. Edge computing seems
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>
<t>
</t> </t>
</section> </section>
<!-- title="The Need for Wireless" -->
<section title="The Need for Wireless"> <section numbered="true" toc="default">
<name>Requirements for RAW</name>
<t> <t>The network infrastructure must support heterogeneous traffic, with
Removing cables helps to change easily the configuration of the attractions, or very different critical requirements. Thus, flow isolation must be
to provided.
upgrade parts of them at a lower cost. The attraction can be designed modularly,
upgrade or insert novel modules later in the lifecycle of the attraction. Novelt
y
of attractions tends to increase the attractiveness of an amusement park,
encouraging previous visitors to visit regularly the park.
</t>
<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>
<t>The transmissions must be scheduled appropriately, even in the
<t> presence of mobile devices. While <xref target="RFC9030"
Wearable devices are extensively used for a user experience personalization. format="default"/> already proposes an architecture for synchronized,
They typically need to support wireless transmissions. Personal tags may help to IEEE Std. 802.15.4 Time-Slotted Channel Hopping (TSCH) networks, the
reduce the operating costs <xref target="DISNEY15"/> and to increase the number industry requires a multi-technology solution that is able to
of charged services provided to the audience (e.g., VIP tickets or guarantee end-to-end requirements across heterogeneous technologies
interactivity). Some applications rely on more sophisticated wearable devices with strict Service Level Agreement (SLA) requirements.
such as digital glasses or Virtual Reality (VR) headsets for an immersive
experience.
</t> </t>
<t>Nowadays, long-range wireless transmissions are used mostly for
</section> <!-- title="The Need for Wireless" --> best-effort traffic. On the contrary, <xref target="IEEE802.1AS"
format="default"/> is used for critical flows using Ethernet
<section title="Requirements for RAW"> devices. However, we need an IP-enabled technology to interconnect
<t> large areas, independent of the Physical (PHY) and Medium Access
The network infrastructure must support heterogeneous traffic, with very Control (MAC) layers.
different critical requirements. Thus, flow isolation must be provided.
</t> </t>
<t>It is expected that several different technologies (long vs. short
<t> range) are deployed, which have to cohabit the same area. Thus, we
The transmissions must be scheduled appropriately even in presence of mobile need to provide L3 mechanisms able to exploit multiple
devices. While the <xref target="RFC9030"/> already proposes an architecture for co-interfering technologies (i.e., different radio technologies using
synchronized, IEEE Std. 802.15.4 Time-Slotted Channel Hopping (TSCH) networks, overlapping spectrum, and therefore, potentially interfering with each
the industry requires a multi-technology solution, able to guarantee end-to-end other).
requirements across heterogeneous technologies, with strict SLA requirements. </t>
</t> <t>It is worth noting that low-priority flows (e.g., predictive
maintenance, marketing) are delay tolerant; a few minutes or even
<t> hours would be acceptable. While classical unscheduled wireless
Nowadays, long-range wireless transmissions are used mostly for best-effort networks already accommodate best-effort traffic, this would force
traffic. On the contrary, <xref target="IEEE802.1TSN"/> is used for critical several colocated and subefficient deployments. Unused resources could
flows using Ethernet devices. However, we need an IP enabled technology to inter rather be used for low-priority flows. Indeed, allocated resources are
connect large consuming energy in most scheduled networks, even if no traffic is
areas, independent of the PHY and MAC layers. transmitted.
</t> </t>
<!-- BEGIN Non-latency critical considerations -->
<t> <section numbered="true" toc="default">
It is expected that several different technologies (long vs. short range) are <name>Non-latency-critical Considerations</name>
deployed, which have to cohabit in the same area. Thus, we need to provide
layer-3 mechanisms able to exploit multiple co-interfering technologies (i.e., d
ifferent radio technologies using overlapping spectrum, and therefore, potential
ly interfering to each other).
</t>
<t>
It is worth noting that low-priority flows (e.g., predictive maintenance,
marketing) are delay tolerant: a few minutes or even hours would be acceptable.
While classical unscheduled wireless networks already accomodate best-effort
traffic, this would force several colocated and subefficient deployments. Unused
resources could rather be used for low-priority flows. Indeed, allocated resourc
es
are consuming energy in most scheduled networks, even if no traffic is transmitt
ed.
</t>
<!-- BEGIN Non-latency critical considerations -->
<section title="Non-latency critical considerations">
<t> <t>
While some of the applications in this use-case involve control loops (e.g., While some of the applications in this use case involve control loops (e.g.,
sensors and actuators) that require bounded latencies below 10 ms, that can sensors and actuators) that require bounded latencies below 10 ms that can
therefore be considered latency critical, there are other applications as well therefore be considered latency critical, there are other applications as well
that mostly demand reliability (e.g., safety related, or maintenance). that mostly demand reliability (e.g., safety-related or maintenance).
</t> </t>
</section>
</section> <!-- END Non-latency critical considerations -->
<!-- END Non-latency critical considerations -->
</section> </section>
</section>
<section numbered="true" toc="default">
<name>Wireless for Industrial Applications</name>
<section numbered="true" toc="default">
<name>Use Case Description</name>
</section> <t>
A major use case for networking in industrial environments is the control
<section title="Wireless for Industrial Applications">
<section title="Use-Case Description">
<t>
<!-- FT: several sensors may be attached to the PLC -->
A major use-case for networking in Industrial environments is the control
networks where periodic control loops operate between a collection of sensors networks where periodic control loops operate between a collection of sensors
that measure a physical property such as the temperature of a fluid, a that measure a physical property (such as the temperature of a fluid), a
Programmable Logic Controller (PLC) that decides an action such as warm up the Programmable Logic Controller (PLC) that decides on an action (such as "warm
mix, and actuators that perform the required action, such as the injection of up the mix"), and actuators that perform the required action (such as the
power in a resistor. injection of power in a resistor).
</t> </t>
</section>
<section anchor="indusspecif" title="Specifics">
<section anchor="indusloops" title="Control Loops">
<t>
Process Control designates continuous processing operations, like heating oil
in a refinery or mixing drinking soda. Control loops in the Process Control
industry operate at a very low rate, typically four times per second. Factory
Automation, on the other hand, deals with discrete goods such as individual
automobile parts, and requires faster loops, on the order of milliseconds.
Motion control that monitors dynamic activities may require even faster rates on
the order of and below the millisecond.
</t>
<t>
In all those cases, a packet must flow reliably between the sensor and the PLC,
be processed by the PLC, and sent to the actuator within the control loop
period. In some particular use-cases that inherit from analog operations, jitter
might also alter the operation of the control loop. A rare packet loss is
usually admissible, but typically a loss of multiple packets in a row will cause
an emergency halt
of the production and incur a high cost for the manufacturer.
</t>
<t>
Additional details and use-cases related to Industrial applications and their
RAW requirements can be found in
<xref target="I-D.ietf-raw-industrial-requirements" />.
</t>
</section><!--"Control Loops"-->
<section anchor="indusdiags" title="Monitoring and diagnostics">
<t>
A secondary use-case deals with monitoring and diagnostics. This data is essenti
al to improve the performance of a production line,
e.g., by optimizing real-time processing or 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
few industries would afford the associated cost. One of the goals of the Industr
ial Internet of Things is to provide the same benefits to all industries,
including SmartGrid, Transportation, Building, Commercial and Medical. This
requires a cheap, available and scalable IP-based access technology.
</t>
<t>
Inside the factory, wires may already be available to operate the Control
Network. But monitoring and diagnostics data are not welcome in that network for
several
reasons. On the one hand it is rich and asynchronous, meaning that it may
influence the deterministic nature of the control operations and impact the
production. On the other hand, this information must be reported to the operator
s over IP, which means the potential for a security breach via the
interconnection of the Operational Technology (OT) network with the Internet
technology (IT) network and possibly enable a rogue access.
</t>
</section><!-- "Monitoring and diagnostics" -->
</section> <!-- title="Speficicities -->
<section title="The Need for Wireless">
<t>
Wires used on a robot arm are prone to breakage after a few thousands
flexions, a lot faster than a power cable that is wider in diameter, and more
resilient. In general, wired networking and mobile parts are not a good match,
mostly in the case of fast and recurrent activities, as well as rotation.
</t>
<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 when wiring exists, like in the case of an existing control network,
asynchronous IP packets such as diagnostics may not be welcome for operational
and security reasons. For those packets, the option to create a parallel
wireless network offers a credible solution that can scale with the many sensors
and actuators that equip every robot, every 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) <xref
target="RFC7554"/> is a promising technology for that purpose, mostly if the
scheduled operations enable to use the same network by asynchronous and
deterministic flows in parallel.
</t>
</section> <!-- title="The Need for Wireless" -->
<section title="Requirements for RAW">
<t>
As stated by the <xref target="RFC8557"> "Deterministic Networking Problem
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> serves that requirement, the work at
6TiSCH was focused on best-effort IPv6 packet flows. RAW should be able to lock
so-called hard cells (i.e., scheduled cells <xref
target="I-D.ietf-6tisch-terminology"/>) for use by a centralized scheduler, and
leverage time and spatial diversity over a graph of end-to-end paths called a
Track that is based on those cells.
</t>
<t>
Over the course of the recent years, major Industrial Protocols (e.g., <xref
target="ODVA"/> with EtherNet/IP <xref target="EIP"/> and <xref
target="PROFINET"/>) have been migrating towards Ethernet and IP. In order to
unleash the full power of the IP hourglass model, it should be possible to
deploy any application over any network that has the physical capacity to
transport the industrial flow, regardless of the MAC/PHY technology, wired or
wireless, and across technologies. RAW mechanisms should be able to setup 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 maintain
the high reliability of the flows over time. It is also important to ensure that
RAW solutions are interoperable with existing wireless solutions in place, and
with legacy equipment whose capabilities can be extended using retrofitting.
Maintainability, as a broader concept than reliability is also important in
industrial scenarios <xref target="MAR19" />.
</t>
<!-- BEGIN Non-latency critical considerations -->
<section title="Non-latency critical considerations">
<t>
Monitoring and diagnostics applications do not require latency critical
communications, but demand reliable and scalable communications. On the other
hand, process control applications involve control loops that require a bounded
latency, thus are latency critical, but can be managed end-to-end, and therefore
DetNet mechanisms can be applied in conjunction with RAW mechanisms.
</t>
</section> </section>
<!-- END Non-latency critical considerations --> <section anchor="indusspecif" numbered="true" toc="default">
<name>Specifics</name>
</section> <section anchor="indusloops" numbered="true" toc="default">
<name>Control Loops</name>
</section> <t>Process Control designates continuous processing operations, like
heating oil in a refinery or mixing up soda. Control loops in
<section title="Pro Audio and Video"> the Process Control industry operate at a very low rate, typically
four times per second. Factory Automation, on the other hand, deals
with discrete goods, such as individual automobile parts, and
requires faster loops, to the rate of milliseconds. Motion control
that monitors dynamic activities may require even faster rates on
the order of and below the millisecond.
</t>
<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 that inherit from analog operations, jitter might also alter
the operation of the control loop. A rare packet loss is usually
admissible, but typically, a loss of multiple packets in a row will
cause an emergency halt of the production and incur a high cost for
the manufacturer.
</t>
<t>Additional details and use cases related to industrial
applications and their RAW requirements can be found in <xref
target="I-D.ietf-raw-industrial-requirements" format="default"/>.
</t>
</section>
<!--"Control Loops"-->
<section title="Use-Case Description"> <section anchor="indusdiags" numbered="true" toc="default">
<t> <name>Monitoring and Diagnostics</name>
Many devices support audio and video streaming <xref target="RFC9317" /> by empl <t>A secondary use case deals with monitoring and diagnostics. This
oying 802.11 wireless LAN. data is essential to improve the performance of a production line,
Some of these applications require low latency capability. For instance, when e.g., by optimizing real-time processing or by maintenance windows
the application provides interactive play, or when the audio plays in real using Machine Learning predictions. For the lack of wireless
time - meaning live for public addresses in train stations or in theme parks. technologies, some specific industries such as Oil and Gas have been
</t> using serial cables, literally by the millions, to perform their
process optimization over the previous decades. However, few
industries would afford the associated cost. One of the goals of the
Industrial Internet of Things is to provide the same benefits to all
industries, including SmartGrid, transportation, building,
commercial, and medical. This requires a cheap, available, and
scalable IP-based access technology.
</t>
<t>Inside the factory, wires may already be available to operate the
control network. However, monitoring and diagnostics data are not
welcome in that network for several reasons. On the one hand, it is
rich and asynchronous, meaning that it may influence the
deterministic nature of the control operations and impact the
production. On the other hand, this information must be reported to
the operators over IP, which means the potential for a security
breach via the interconnection of the Operational Technology
network with the Internet Technology network and the potential
of a rogue access.
</t>
</section>
<!-- "Monitoring and diagnostics" -->
<t> </section>
The professional audio and video industry ("ProAV") includes: <!-- title="Specifics -->
<list style="symbols">
<t> <section numbered="true" toc="default">
Virtual Reality / Augmented Reality (VR/AR) <name>The Need for Wireless</name>
<t>Wires used on a robot arm are prone to breakage, after a few
thousand flexions, a lot faster than a power cable that is wider in
diameter and more resilient. In general, wired networking and mobile
parts are not a good match, mostly in the case of fast and recurrent
activities, as well as rotation.
</t> </t>
<t> <t>When refurbishing older premises that were built before the
Production and post-production systems such as CD and Blu-ray disk mastering. 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>
<t>Even when wiring exists, like in the case of an existing control
<t> network, asynchronous IP packets, such as diagnostics, may not be
Public address, media and emergency systems at large venues (e.g., airports, welcome for operational and security reasons. For those packets, the
train stations, stadiums, and theme parks). option to create a parallel wireless network offers a credible
solution that can scale with the many sensors and actuators that equip
every robot, valve, and fan that are deployed on the factory floor. It
may also help detect and prevent a failure that could impact the
production, like the degradation (vibration) of a cooling fan on the
ceiling. IEEE Std. 802.15.4 TSCH <xref target="RFC7554"
format="default"/> is a promising technology for that purpose, mostly
if the scheduled operations enable the use of the same network by
asynchronous and deterministic flows in parallel.
</t> </t>
</section>
<!-- title="The Need for Wireless" -->
</list> <section numbered="true" toc="default">
<name>Requirements for RAW</name>
</t> <t>As stated by the <xref target="RFC8557" format="default">
"Deterministic Networking Problem Statement"</xref>, a deterministic
</section> network is backwards compatible with (capable of transporting)
statistically multiplexed traffic while preserving the properties of
<section title="Specifics"> the accepted deterministic flows. While the <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" (i.e., scheduled cells
<xref target="I-D.ietf-6tisch-terminology" format="default"/>) for use
by a centralized scheduler and leverage time and spatial diversity
over a graph of end-to-end paths called a "Track" that is based on
those cells.
</t>
<t>Over recent years, major industrial protocols
have been migrating towards Ethernet and IP. (For example, <xref target=
"ODVA"/> with
EtherNet/IP <xref target="EIP"/> and <xref target="PROFINET"/>, where OD
VA is the organization that
supports network technologies built on the Common Industrial Protocol
(CIP) including EtherNet/IP.) In order to unleash the full power of
the IP hourglass model, it should be possible to deploy any
application over any network that has the physical capacity to
transport the industrial flow, regardless of the MAC/PHY technology,
wired, or wireless, and across technologies. RAW mechanisms should be
able to set up a Track over a wireless access segment and a wired or
wireless backbone to report both sensor data and critical monitoring
within a bounded latency and should be able to maintain the high
reliability of the flows over time. It is also important to ensure
that RAW solutions are interoperable with existing wireless solutions
in place and with legacy equipment whose capabilities can be extended
using retrofitting. Maintainability, as a broader concept than
reliability, is also important in industrial scenarios <xref
target="MAR19" format="default"/>.
</t>
<!-- BEGIN Non-latency critical considerations -->
<section numbered="true" toc="default">
<name>Non-latency-critical Considerations</name>
<t>Monitoring and diagnostics applications do not require
latency-critical communications but demand reliable and scalable
communications. On the other hand, process-control applications
involve control loops that require a bounded latency and, thus, are
latency critical. However, they can be managed end-to-end, and
therefore DetNet mechanisms can be applied in conjunction with RAW
mechanisms.
</t>
</section>
<!-- END Non-latency critical considerations -->
<section title="Uninterrupted Stream Playback">
<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 has been identified it is too late to proceed with packet
re-transmission. Buffering might be employed to provide a certain delay which
will allow for one or more re-transmissions, however such approach is not
viable in application where delays are not acceptable.
</t>
</section> </section>
<section title="Synchronized Stream Playback">
<t>
In the context of ProAV over packet networks, latency is the time between the tr
ansmitted signal over a stream and its reception. Thus, for sound to remain sync
hronized to the movement in the video, the latency of both the audio and video s
treams must be bounded and consistent.
</t>
</section>
</section> </section>
<section numbered="true" toc="default">
<section title="The Need for Wireless"> <name>Professional Audio and Video</name>
<section numbered="true" toc="default">
<t> <name>Use Case Description</name>
The devices need the wireless communication to support video streaming via IEEE <t>Many devices support audio and video streaming <xref
802.11 wireless LAN for instance. Wireless communications provide huge target="RFC9317" format="default"/> by employing 802.11 wireless LAN.
advantages in terms of simpler deployments in many scenarios, where the use of a Some of these applications require low latency capability, for
wired alternative would not be feasible. Similarly, in live events, mobility instance, when the application provides interactive play or when the
support makes wireless communications the only viable approach. audio plays in real time -- meaning being live for public addresses in
</t> train stations or in theme parks.
</t>
<t> <t>The professional audio and video industry (ProAV) includes:
Deployed announcement speakers, for instance </t>
along the platforms of the train stations, need the wireless communication to <ul spacing="normal">
forward the audio traffic in real time. Most train stations are already built, a <li>Virtual Reality / Augmented Reality (VR/AR) </li>
nd <li>Production and post-production systems, such as CD and Blu-ray
deploying novel cables for each novel service seems expensive. disk mastering.</li>
</t> <li>Public address, media, and emergency systems at large venues
(e.g., airports, train stations, stadiums, and theme parks).</li>
</section> <!-- title="The Need for Wireless" --> </ul>
<section title="Requirements for RAW">
<t>
The network infrastructure needs to support heterogeneous types of traffic
(including QoS).
</t>
<t>
Content delivery with bounded (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) through the
network to support redundancy.
</t>
<!-- BEGIN Non-latency critical considerations -->
<section title="Non-latency critical considerations">
<t>
For synchronized streaming, latency must be bounded, and therefore, depending on
the actual requirements, this can be considered as latency critical. However,
the most critical requirement of this use-case is reliability, by the network
providing redundancy. Note that in many cases, wireless is only present in the
access, where RAW mechanisms could be applied, but other wired segments are also
involved (like the Internet), and therefore latency cannot be guaranteed.
</t>
</section> </section>
<!-- END Non-latency critical considerations --> <section numbered="true" toc="default">
<name>Specifics</name>
</section> <section numbered="true" toc="default">
<name>Uninterrupted Stream Playback</name>
</section> <t>Considering the uninterrupted audio or video stream, a potential
packet loss during the transmission of audio or video flows cannot
<section title="Wireless Gaming"> be tackled by re-trying the transmission, as it is done with file
transfer, because by the time the lost packet has been identified,
<section title="Use-Case Description"> it is too late to proceed with packet re-transmission. Buffering
might be employed to provide a certain delay that will allow for one
<t> or more re-transmissions. However, such an approach is not viable in
The gaming industry includes <xref target="IEEE80211RTA" /> real-time mobile applications where delays are not acceptable.
gaming, wireless console gaming, wireless gaming controllers and cloud gaming. N </t>
ote that they are not mutually exclusive (e.g., a console can connect wirelessly </section>
to the Internet to play a cloud game). For RAW, wireless console gaming is the <section numbered="true" toc="default">
most relevant one. We next summarize the four: <name>Synchronized Stream Playback</name>
<t>In the context of ProAV over packet networks, latency is the time
<list style="symbols"> between the transmitted signal over a stream and its
reception. Thus, for sound to remain synchronized to the movement in
<t> the video, the latency of both the audio and video streams must be
Real-time Mobile Gaming: Different from traditional games, real time mobile bounded and consistent.
gaming is very sensitive to network latency and stability. The mobile game can </t>
connect multiple players together in a single game session and exchange data </section>
messages between game server and connected players. Real-time means the feedback </section>
should present on screen as users operate in game. For good game experience, the <section numbered="true" toc="default">
end-to-end (E2E) latency plus game servers processing time must be the same for <name>The Need for Wireless</name>
all players and should not be noticeable as the game is played. RAW technologies <t>Audio and video devices need the wireless communication to support vi
might help in keeping latencies low on the wireless segments of the communicati deo
on. streaming via IEEE 802.11 wireless LAN, for instance. Wireless
communications provide huge advantages in terms of simpler deployments
in many scenarios where the use of a wired alternative would not be
feasible. Similarly, in live events, mobility support makes wireless
communications the only viable approach.
</t> </t>
<t>Deployed announcement speakers, for instance, along the platforms of
<t> the train stations, need the wireless communication to forward the
Wireless Console Gaming: while gamers may use a physical console, interactions w audio traffic in real time. Most train stations are already built, and
ith deploying novel cables for each novel service seems expensive.
a remote server may be required for online games. Most of the gaming consoles to
day
support Wi-Fi 5, but may benefit from a scheduled access with Wi-Fi 6 in the
future. Previous Wi-Fi versions have an especially bad reputation among the gami
ng
community. The main reasons are high latency, lag spikes, and jitter.
</t> </t>
</section>
<!-- title="The Need for Wireless" -->
<t> <section numbered="true" toc="default">
Wireless Gaming controllers: most controllers are now wireless for a freedom of <name>Requirements for RAW</name>
movement.Controllers may interact with consoles or directly with gaming server i <t>The network infrastructure needs to support heterogeneous types of
n traffic (including QoS).
the cloud. A low and stable end-to-end latency is here of predominant importance
.
</t> </t>
<t>Content delivery must have bounded latency (to the lowest possible lat
<t> ency).</t>
Cloud Gaming: The cloud gaming requires low latency capability as the user <t>The deployed network topology should allow for multipath. This will
commands in a game session need to be sent back to the cloud server, the cloud enable for multiple streams to have different (and multiple) paths
server would update game context depending on the received commands, and the (Tracks) through the network to support redundancy.
cloud server would render the picture/video to be displayed at user devices and
stream the picture/video content to the user devices. User devices might very
likely be connected wirelessly.
</t> </t>
<!-- BEGIN Non-latency critical considerations -->
<section numbered="true" toc="default">
<name>Non-latency-critical Considerations</name>
<t>For synchronized streaming, latency must be bounded.
Therefore, depending on the actual requirements, this can be
considered as "latency critical".
</list> However, the most critical
requirement of this use case is reliability, which can be achieved by
</t> the network
providing redundancy. Note that in many cases, wireless is only
</section> present in the access where RAW mechanisms could be applied, but
other wired segments are also involved (like the Internet), and
<section title="Specifics"> therefore latency cannot be guaranteed.
</t>
<t> </section>
While a lot of details can be found on <xref target="IEEE80211RTA" />, we next <!-- END Non-latency critical considerations -->
summarize the main requirements in terms of latency, jitter and packet loss:
<list style="symbols">
<t> </section>
Intra Basic Service Set (BSS) latency is less than 5 ms. </section>
<section 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, 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:</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 as
users operate in-game. For good game experience, the end-to-end
latency plus game servers processing time must be the same for
all players and should not be noticeable as the game is played. RAW
technologies might help in keeping latencies low on the wireless
segments of the communication.</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 but may benefit from a scheduled
access with Wi-Fi 6 in the future. Previous Wi-Fi versions have an
especially bad reputation among the gaming community, the main
reasons being high latency, lag spikes, and jitter.</t></li>
<li><t>Wireless Gaming controllers:</t>
<t>Most controllers are now wireless for the freedom of
movement. Controllers may interact with consoles or directly with
the gaming server in the cloud. A low and stable end-to-end latency
is here of predominant importance.</t></li>
<li><t>Cloud Gaming:</t>
<t>Cloud gaming requires low-latency capability as
the user commands in a game session are sent back to the
cloud server. Then, the cloud server updates the game context
depending on the received commands, renders the
picture/video to be displayed on the user devices, and streams the
picture/video content to the user devices. User devices might very likely
be connected
wirelessly.</t></li>
</ul>
</section>
<section numbered="true" toc="default">
<name>Specifics</name> <t>While a lot of details can be found at <xref
target="IEEE80211RTA" format="default"/>, we next summarize the main
requirements in terms of latency, jitter, and packet loss: </t>
<ul spacing="normal">
<li>Intra Basic Service Set (BSS) latency is less than 5 ms.</li>
<li>Jitter variance is less than 2 ms.</li>
<li>Packet loss is less than 0.1%.</li>
</ul>
</section>
<section numbered="true" toc="default">
<name>The Need for 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.
Wireless controllers are the rule in modern gaming, with increasingly
sophisticated interactions (e.g., haptic feedback, augmented reality).
</t> </t>
</section>
<section numbered="true" toc="default">
<name>Requirements for RAW</name>
<dl spacing="normal" newline="true">
<dt>Time-sensitive networking extensions:</dt>
<dd>Extensions, such as time-aware shaping and redundancy,
can be explored to address congestion and reliability problems
present in wireless networks. As an example, in haptics, it is very
important to minimize latency failures.</dd>
<dt>Priority tagging (Stream 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.</dd>
<dt>Time-aware shaping:</dt>
<dd>This capability (defined in IEEE 802.1Qbv) consists of gates to
control the opening and closing of queues that share a common egress
port within an Ethernet switch. A scheduler defines the times when
each queue opens or closes, therefore, eliminating congestion and
ensuring that frames are delivered within the expected latency
bounds. Though, note that while this requirement needs to be
signaled by RAW mechanisms, it would actually be served by the
lower layer.</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.</dd>
<dt>Admission Control:</dt>
<dd>Congestion is a major cause of high/variable latency, and it is
well known that if the traffic load exceeds the capability of the
link, QoS will be degraded. QoS degradation may be acceptable for
many applications today. However, emerging time-sensitive
applications are highly susceptible to increased latency and
jitter. To better control QoS, it is important to control access to
the network resources.</dd>
</dl>
<!-- BEGIN Non-latency critical considerations -->
<section 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 might be considered as latency critical due to the need of
bounded latency. However, note that, in most of these scenarios,
part of the communication path is not wireless, and DetNet
mechanisms cannot be applied easily (e.g., when the public Internet
is involved), and therefore, reliability is the critical
requirement.
</t>
</section>
<!-- END Non-latency critical considerations -->
<t> </section>
Jitter variance is less than 2 ms. </section>
<section numbered="true" toc="default">
<name>Unmanned Aerial Vehicles and Vehicle-to-Vehicle Platooning and
Control</name>
<section 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. The
term "drone" is commonly used to refer to a UAV.
</t> </t>
<t> <t>
Packet loss is less than 0.1 percent. 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 transporting of small goods (e.g., medicine in rural areas). Note that
the surveillance and monitoring application would have to comply with local
regulations regarding location privacy of users. Different considerations have
to be applied when surveillance is performed for traffic rules enforcement
(e.g., generating fines), as compared to when traffic load is being monitored.
</t> </t>
<t>Many types of vehicles, including UAVs but also others, such as
</list> cars, can travel in platoons, driving together with shorter distances
between vehicles to increase efficiency. Platooning imposes certain
</t> vehicle-to-vehicle considerations, most of these are applicable to
both UAVs and other vehicle types.</t>
</section> <t>UAVs and other vehicles typically have various forms of wireless
connectivity:
<section title="The Need for Wireless">
<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 sophistica
ted
interactions (e.g., haptic feedback, augmented reality).
</t>
</section>
<section title="Requirements for RAW">
<t>
<list style="symbols">
<t>
Time sensitive networking extensions: extensions, such as time-aware shaping and
redundancy can be explored to address congestion and reliability problems
present in wireless networks. As an example, in haptics it is very important to
minimize latency failures.
</t> </t>
<ul spacing="normal">
<t> <li>Cellular: for communication with the control center, remote
Priority tagging (Stream identification): one basic requirement to provide maneuvering, and monitoring of the drone;</li>
better QoS for time-sensitive traffic is the capability to identify and <li>IEEE 802.11: for inter-drone communications (i.e., platooning)
differentiate time-sensitive packets from other (like best-effort) traffic. and providing connectivity to other devices (i.e., acting as Access
Point).</li>
</ul>
<t>Note that autonomous cars share many of the characteristics of the
aforementioned UAV case. Therefore, it is of interest for RAW.
</t> </t>
</section>
<t> <section numbered="true" toc="default">
Time-aware shaping: this capability (defined in IEEE 802.1Qbv) consists of gates <name>Specifics</name>
to control the opening/closing of queues that share a common egress port within <t>Some of the use cases and tasks involving UAVs require coordination
an Ethernet switch. A scheduler defines the times when each queue opens or among UAVs. Others involve complex computing tasks that might not be
close, therefore eliminating congestion and ensuring that frames are delivered performed using the limited computing resources that a drone typically
within the expected latency bounds. Note though, that while this requirement has. These two aspects require continuous connectivity with the
needs to be signalled by RAW mechanisms, it would be actually served by the control center and among UAVs.
lower layer.
</t> </t>
<t>Remote maneuvering of a drone might be performed over a cellular
<t> network in some cases, but there are situations that need very
Dual/multiple link: due to the fact that competitions and interference are commo low latency and deterministic behavior of the connectivity. Examples
n and involve platooning of drones or sharing of computing resources among
hardly in control under wireless network, to improve the latency stability, drones (like a drone offloading some function to a neighboring drone).
dual/multiple link proposal is brought up to address this issue.
</t> </t>
</section>
<t> <section numbered="true" toc="default">
Admission Control: congestion is a major cause of high/variable latency and it <name>The Need for Wireless</name>
is well known that if the traffic load exceeds the capability of the link, QoS <t>UAVs cannot be connected through any type of wired media, so it is
will be degraded. QoS degradation may be acceptable for many applications today, obvious that wireless is needed.
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> </t>
</list>
</t>
<!-- BEGIN Non-latency critical considerations -->
<section title="Non-latency critical considerations">
<t>
Depending on the actual scenario, and on use of Internet to interconnect
different users, the communication requirements of this use-case might be
considered as latency critical due to the need of bounded latency. But note that
in most of these scenarios, part of the communication path is not wireless and
DetNet mechanisms cannot be applied easily (e.g., when the public Internet is
involved), and therefore in these cases, reliability is the critical
requirement.
</t>
</section> </section>
<!-- END Non-latency critical considerations --> <!-- title="The Need for Wireless" -->
</section>
</section>
<section title="Unmanned Aerial Vehicles and Vehicle-to-Vehicle platooning and c
ontrol">
<section title="Use-Case Description">
<t>
Unmanned Aerial Vehicles (UAVs) are becoming very popular for many different
applications, including military and civil use-cases. The term drone is commonly
used to refer to a UAV.
</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"
/>), support of emergency situations, and even transportation of small goods (e.
g., medicine in rural
areas). Note that the surveillance and monitoring application would have to comp
ly with local regulations regarding location privacy of users. Different conside
rations have to be applied when surveillance is performed for traffic rules enfo
rcement (e.g., generating fines) as compared to when traffic load is being monit
ored.
</t>
<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 typically have various forms of wireless connectivity:
</t>
<t>
<list style="symbols">
<t>Cellular: for communication with the control center, for remote
maneuvering as well as monitoring of the drone;
</t>
<t>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 that autonomous cars share many of the characteristics of the aforemention
UAV case, and therefore it is of interest for RAW.
</t>
</section>
<section title="Specifics">
<t>
Some of the use-cases/tasks involving UAVs require coordination among UAVs.
Others involve complex compute 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 maneuvering of a drone might be performed over a cellular network in some
cases, however, there are situations that need very low latency and
deterministic behavior of the connectivity. Examples involve platooning of
drones or sharing of computing resources among drones (like, a drone offload som
e
function to a neighboring drone).
</t>
</section>
<section title="The Need for Wireless">
<t> <section numbered="true" toc="default">
UAVs cannot be connected through any type of wired media, so it is obvious that <name>Requirements for RAW</name>
wireless is needed. <t>The network infrastructure is composed of the UAVs themselves,
requiring self-configuration capabilities.
</t> </t>
<t>Heterogeneous types of traffic need to be supported, from extremely
</section> <!-- title="The Need for Wireless" --> critical traffic types requiring ultra-low latency and high resiliency
to traffic requiring low-to-medium latency.
<section title="Requirements for RAW">
<t>
The network infrastructure is composed by the UAVs themselves, requiring
self-configuration capabilities.
</t> </t>
<t>When a given service is decomposed into functions (which are hosted a
<t> t
Heterogeneous types of traffic need to be supported, from extremely critical different UAVs and chained), each link connecting two given functions
ones requiring ultra-low latency and high resiliency, to traffic requiring would have a well-defined set of requirements (e.g., latency,
low-medium latency. bandwidth, and jitter) that must be met.
</t> </t>
<!-- BEGIN Non-latency critical considerations -->
<section 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, the critical requirement is reliability, and, only for some
platooning and inter-drone communications, latency is critical.
</t>
</section>
<!-- END Non-latency critical considerations -->
</section>
</section>
<section numbered="true" toc="default">
<name>Edge Robotics Control</name>
<section 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) and inter-connected via an access
network to a network edge device or a data center. The robots are
connected to the edge so that complex computational activities are not
executed locally at the robots but offloaded to the edge. This brings
additional flexibility in the type of tasks that the robots perform,
reduces the costs of robot-manufacturing (due to their lower
complexity), and enables complex tasks involving coordination among
robots (that can be more easily performed if robots are centrally
controlled).
</t>
<t> <t>
When a given service is decomposed into functions -- hosted at different UAVs -- Simple examples of the use of multiple robots are cleaning, video surveillance
chained, each link connecting two given functions would have a well-defined set (note that this have to comply with local regulations regarding user privacy
of requirements (e.g., latency, bandwidth and jitter) that must be met. 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>
<t>Robots would have various forms of wireless connectivity:
<!-- BEGIN Non-latency critical considerations --> </t>
<section title="Non-latency critical considerations"> <ul spacing="normal">
<li>Cellular: as an additional communication link to the edge,
<t> though primarily as backup, since ultra-low latency is needed.
Today's solutions keep the processing operations that are critical local (i.e., </li>
they are not offloaded). Therefore, in this use-case, the critical requirement <li>IEEE 802.11: for connection to the edge and also inter-robot
is reliability, and only for some platooning and inter-drone communications communications (i.e., for coordinated actions).</li>
latency is critical. </ul>
</t>
</section> </section>
<!-- END Non-latency critical considerations --> <section numbered="true" toc="default">
<name>Specifics</name>
</section> <t>Some of the use cases and tasks involving robots might benefit from
decomposition of a service into small functions that are distributed and
</section> chained among robots and the edge. These require continuous
connectivity with the control center and among drones.
<section title="Edge Robotics control">
<section title="Use-Case Description">
<t>
The Edge Robotics scenario consists of several robots, deployed in a given area
(like a shopping mall), inter-connected via an access network to a
network edge device or a data center. The robots are connected to the edge so
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 the costs of robot manufacturing (due to
their lower complexity), and enabling 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 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 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: as an additional communication link to the edge, though primarily as
backup, since ultra-low latency is needed.
</t>
</list>
</t>
</section>
<section title="Specifics">
<t>
Some of the use-cases/tasks involving robots might benefit from decomposition of
a service in 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 control is an activity requiring very low latency (0.5-20 ms <xref target=
"Groshev2021" />) between the robot and the location where the control intellige
nce resides (which might be the edge or another robot).
</t>
</section>
<section title="The Need for Wireless">
<t>
Deploying robots in scenarios such as shopping malls for the applications
mentioned cannot be done via wired connectivity.
</t> </t>
<t>Robot control is an activity requiring very low latency (0.5-20 ms
</section> <!-- title="The Need for Wireless" --> <xref target="Groshev2021" format="default"/>) between the robot and
the location where the control intelligence resides (which might be
<section title="Requirements for RAW"> the edge or another robot).
<t>
The network infrastructure needs to support heterogeneous types of traffic, from
robot control to video streaming.
</t> </t>
</section>
<t> <section numbered="true" toc="default">
When a given service is decomposed into functions -- hosted at different robots <name>The Need for Wireless</name>
set of requirements (latency, bandwidth and jitter) that must be met. <t>Deploying robots in scenarios such as shopping malls for the
applications mentioned cannot be done via wired connectivity.
</t> </t>
<!-- BEGIN Non-latency critical considerations -->
<section title="Non-latency critical considerations">
<t>
This use-case might combine multiple communication flows, with some of them
being latency critical (like those related to robot control tasks). Note that
there are still many communication flows (like some offloading tasks) that only
demand reliability and availability.
</t>
</section> </section>
<!-- END Non-latency critical considerations --> <!-- title="The Need for Wireless" -->
</section>
</section>
<!-- [2020-07-11] cjbc: text added -->
<section title="Instrumented emergency medical vehicles">
<section title="Use-Case Description">
<t>
An instrumented ambulance would be one that one or multiple network segments to
which are connected
these end systems such as:
<list style="symbols" >
<t>
vital signs sensors attached to the casualty in the ambulance. Relay medical
data to hospital emergency room,
</t>
<t>
radio-navigation sensor to relay position data to various destinations including
dispatcher,
</t>
<t>
voice communication for ambulance attendant (like to consult with ER doctor), an
d
</t>
<t>
voice communication between driver and dispatcher.
</t>
</list>
</t>
<t>
The LAN needs to be routed through radio-WANs (a radio network in the interior o
f a network, i.e., it is terminated by routers) to complete the network linkage.
</t>
</section>
<section title="Specifics">
<t>
What we have today is multiple communication systems to reach the vehicle via:
<list style="symbols" >
<t>
A dispatching system,
</t>
<t>
a cellphone for the attendant,
</t>
<t>
a special purpose telemetering system for medical data,
</t>
<t> <section numbered="true" toc="default">
etc. <name>Requirements for RAW</name>
<t>The network infrastructure needs to support heterogeneous types of
traffic, from robot control to video streaming.
</t>
<t>When a given service is decomposed into functions (which are hosted a
t
different UAVs and chained), each link connecting two given functions
would have a well-defined set of requirements (e.g., latency,
bandwidth, and jitter) that must be met.
</t>
<!-- BEGIN Non-latency critical considerations -->
<section 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 tasks). Note that there are still many communication
flows (like some offloading tasks) that only demand reliability and
availability.
</t> </t>
</section>
<!-- END Non-latency critical considerations -->
</list> </section>
</section>
</t> <section numbered="true" toc="default">
<name>Instrumented Emergency Medical Vehicles</name>
<t> <section numbered="true" toc="default">
This redundancy of systems does not contribute to availability. <name>Use Case Description</name>
</t>
<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 or at the general
Internet/cloud. Special care (at application level) have to be paid to ensuring
that sensitive data is not disclosed to unauthorized parties, by properly securi
ng traffic and authenticating the communication ends.
</t>
</section> <!--[rfced] To follow up, should "be" be "have"?
<section title="The Need for Wireless"> Current:
An instrumented ambulance would be one or multiple network segments
that are connected to end systems such as:
<t> Perhaps:
Local traffic between the first responders/ambulance staff and the ambulance An instrumented ambulance would have one or multiple network segments
equipment cannot be done via wired connectivity as the responders perform that are connected to end systems such as:
initial treatment outside of the ambulance. The communications from the -->
ambulance to external services must be wireless as well. <t> 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 to relay
medical data to hospital emergency room,</li>
<li>a radio-navigation sensor to relay position data to various
destinations including dispatcher,
</li>
<li>voice communication for ambulance attendant (likely to consult
with ER doctor), and
</li>
<li>voice communication between driver and dispatcher.
</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 netwo
rk linkage.
</t> </t>
</section>
<section numbered="true" toc="default">
<name>Specifics</name>
<t>What we have today is multiple communication systems to reach the
vehicle via: </t>
<ul spacing="normal">
<li>a dispatching system, </li>
<li>a cellphone for the attendant, </li>
<li>a special purpose telemetering system for medical data, </li>
<li>etc. </li>
</ul>
<t>This redundancy of systems does not contribute to availability.
</t>
<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 the ambulance itself (local
traffic), a near edge cloud, or the general Internet/cloud. Special
care (at application level) have to be paid to ensure that sensitive
data is not disclosed to unauthorized parties by properly securing
traffic and authenticating the communication ends.
</t>
</section>
<section numbered="true" toc="default">
<name>The Need for Wireless</name>
<t>Local traffic between the first responders and ambulance staff and
the ambulance equipment cannot be done via wired connectivity as the
responders perform initial treatment outside of the ambulance. The
communications from the ambulance to external services must be
wireless as well.
</t>
</section>
<!-- title="The Need for Wireless" -->
</section> <!-- title="The Need for Wireless" --> <section numbered="true" toc="default">
<name>Requirements for RAW</name>
<section title="Requirements for RAW"> <t>We can derive some pertinent requirements from this scenario: </t>
<ul spacing="normal">
<t> <li>High availability of the internetwork is required. The exact
We can derive some pertinent requirements from this scenario: level of availability depends on the specific deployment scenario,
as not all emergency agencies share the same type of instrumented
<list style="symbols" > emergency vehicles.
</li>
<t> <li>The internetwork needs to operate in damaged state (e.g.,
High availability of the inter-network is required. The exact level of availabil during an earthquake aftermath, heavy weather, a wildfire, etc.). In
ity depends on the specific deployment scenario, as not all emergency agencies s addition to continuity of operations, rapid restore is a needed
hare the same type of instrumented emergency vehicles. characteristic. </li>
</t>
<t>
The inter-network needs to operate in damaged state (e.g. during an earthquake
aftermath, heavy weather, 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> <li>The radio-WAN has characteristics similar to the cellphone's --
The radio-WAN has characteristics similar to cellphone -- the vehicle will the vehicle will travel from one radio coverage area to another,
travel from one radio coverage area to another, thus requiring some hand-off app thus requiring some hand-off approach.
roach. </li>
</ul>
<!-- BEGIN Non-latency critical considerations -->
<section numbered="true" toc="default">
<name>Non-latency-critical Considerations</name>
<t>In this case, all applications identified do not require
latency-critical communication but do need high reliability and
availability.
</t> </t>
</section>
</list> <!-- END Non-latency critical considerations -->
</t>
<!-- BEGIN Non-latency critical considerations -->
<section title="Non-latency critical considerations">
<t>
In this case, all applications identified do not require latency critical
communication, but do need high reliability and availability.
</t>
</section>
<!-- END Non-latency critical considerations -->
</section> </section>
</section>
<section anchor="sec:summary" title="Summary">
<t>
This document enumerates several use-cases and applications that need RAW
technologies, focusing on the requirements from reliability, availability and
latency. Whereas some use-cases are latency-critical, there are also several
applications that are non-latency critical, but that do pose strict reliability
and availability requirements.
</t>
</section> </section>
<section anchor="sec_summary" numbered="true" toc="default">
<section anchor="sec:iana" title="IANA Considerations"> <name>Summary</name>
<t>This document enumerates several use cases and applications that need
<t> RAW technologies, focusing on the requirements from reliability,
This document has no IANA actions. availability, and latency. While some use cases are latency critical,
there are also several applications that are not latency critical but
do pose strict reliability and availability requirements.
</t> </t>
</section> </section>
<section anchor="sec_iana" numbered="true" toc="default">
<section anchor="sec:security" title="Security Considerations"> <name>IANA Considerations</name>
<t>This document has no IANA actions. </t>
<t> </section>
This document covers several representative applications and network scenarios <section anchor="sec_security" numbered="true" toc="default">
that are expected to make use of RAW technologies. Each of the potential RAW <name>Security Considerations</name>
use-cases will have security considerations from both the use-specific <t>This document covers several representative applications and network
perspective and the RAW technology perspective. <xref target="RFC9055" /> scenarios that are expected to make use of RAW technologies. Each of the
provides a comprehensive discussion of security considerations in the context of potential RAW use cases will have security considerations from both the
deterministic networking, which are generally applicable also to RAW. use-specific perspective and the RAW technology perspective. <xref
target="RFC9055" format="default"/> provides a comprehensive discussion
of security considerations in the context of DetNet, which are generally
also applicable to RAW.
</t> </t>
</section> </section>
<section anchor="sec:acks" title="Acknowledgments"> </middle>
<back>
<t>
Nils M&auml;urer, Thomas Gr&auml;upl and Corinna Schmitt have contributed
significantly to this document, providing input for the Aeronautical
communication section. Rex Buddenberg has also contributed to the document,
providing input to the Emergency: instrumented emergency vehicle section.
</t>
<t> <displayreference target="I-D.ietf-raw-industrial-requirements" to="RAW-IND-REQS
The authors would like to thank Toerless Eckert, Xavi Vilajosana Guillen, Rute "/>
Sofia, Corinna Schmitt, Victoria Pritchard, John Scudder, Joerg Ott and <displayreference target="I-D.ietf-6tisch-terminology" to="6TiSCH-TERMS"/>
Stewart Bryant for their valuable comments on previous versions of this document <displayreference target="I-D.ietf-raw-technologies" to="RAW-TECHNOS"/>
.
</t>
<t> <references>
The work of Carlos J. Bernardos in this document has been partially supported by <name>Informative References</name>
the Horizon Europe PREDICT-6G (Grant 101095890) and UNICO I+D 6G-DATADRIVEN-04 p <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.247
roject. 5.xml"/>
</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.755
4.xml"/>
<!-- 6TiSCH TSCH -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.855
7.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.857
8.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.865
5.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.903
0.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.905
5.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.937
2.xml"/>
</section> <!-- [I-D.ietf-raw-industrial-requirements] IESG state Expired -->
</middle> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ie tf-raw-industrial-requirements.xml"/>
<back> <!-- [I-D.ietf-6tisch-terminology] IESG state Expired. Updated to long version b ecause missing editor role for Palattella -->
<!-- <reference anchor="I-D.ietf-6tisch-terminology" target="https://datatracker.ietf
<references title="Normative References"> .org/doc/html/draft-ietf-6tisch-terminology-10">
<front>
<title>Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e</title>
<author initials="MR." surname="Palattella" fullname="Maria Rita Palattella" rol
e="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 Sci. and Tech. Beijing</organization>
</author>
<date month="March" day="2" year="2018"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-6tisch-terminology-10"/>
</reference>
</references> <!-- [I-D.ietf-raw-technologies] IESG state I-D Exists. Updated to long version because missing editor role for Thubert -->
<references title="Informative References"> <reference anchor="I-D.ietf-raw-technologies" target="https://datatracker.ietf.o
rg/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>
<?rfc include="reference.RFC.7554"?> <!-- 6TiSCH TSCH --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.931
<?rfc include='reference.RFC.8557'?> 7.xml"/>
<?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="DISNEY15" target="https://www.wired.com/2015/03/disney <reference anchor="DISNEY15" target="https://www.wired.com/2015/03/disney-
-magicband/"> magicband/">
<front> <front>
<title>Disney's $1 Billion Bet on a Magical Wristband</title> <title>Disney's $1 Billion Bet on a Magical Wristband</title>
<author> <author surname="Kuang" initials="C.">
<organization>Wired</organization> <organization>Wired</organization>
</author> </author>
<date year="2015" month="March"/> <date year="2015" month="March"/>
</front> </front>
</reference> </reference>
<reference anchor="KEAV20" target="https://www.sesarju.eu/"> <!--LDACS--> <reference anchor="SESAR" target="https://www.sesarju.eu/">
<front> <front>
<title>Single European Sky ATM Research Joint Undertaking</title> <title>SESAR Joint Undertaking</title>
<author> <author>
<organization>T. Keaveney and C. Stewart</organization> <organization>SESAR</organization>
</author> </author>
<date year="2019"/> </front>
</front> </reference>
</reference>
<reference anchor="FAA20" target="https://www.faa.gov/nextgen/ "> <!--LDA <reference anchor="FAA20" target="https://www.faa.gov/nextgen/">
CS--> <!--LDACS-->
<front> <front>
<title>Next Generation Air Transportation System</title> <title>Next Generation Air Transportation System (NextGen)</title>
<author> <author>
<organization>U.S. Department of Transportation Federal Aviat <organization>U.S. Department of Transportation: Federal Aviation
ion Administration (FAA)</organization> Administration (FAA)</organization>
</author> </author>
<date year="2019"/> </front>
</front> </reference>
</reference>
<reference anchor="PLA14"> <!--LDACS--> <reference anchor="PLA14">
<!--LDACS-->
<front> <front>
<title>Flight Trial Demonstration of Seamless Aeronautical Networ <title>Flight Trial Demonstration of Seamless Aeronautical Networking<
king /title>
</title> <author initials="S." surname="Plass"/>
<author initials="S." surname="Plass"/> <author initials="R." surname="Hermenier"/>
<author initials="R." surname="Hermenier"/> <author initials="O." surname="Lücke"/>
<author initials="O." surname="Luecke"/> <author initials="D." surname="Gomez Depoorter"/>
<author initials="D." surname="Gomez Depoorter"/> <author initials="T." surname="Tordjman"/>
<author initials="T." surname="Tordjman"/> <author initials="M." surname="Chatterton"/>
<author initials="M." surname="Chatterton"/> <author initials="M." surname="Amirfeiz"/>
<author initials="M." surname="Amirfeiz"/> <author initials="S." surname="Scotti"/>
<author initials="S." surname="Scotti"/> <author initials="Y." surname="Cheng"/>
<author initials="Y.J." surname="Cheng"/> <author initials="P." surname="Pillai"/>
<author initials="P." surname="Pillai"/> <author initials="T." surname="Gräupl"/>
<author initials="T." surname="Graeupl"/> <author initials="F." surname="Durand"/>
<author initials="F." surname="Durand"/> <author initials="K." surname="Murphy"/>
<author initials="K." surname="Murphy"/> <author initials="A." surname="Marriott"/>
<author initials="A." surname="Marriott"/> <author initials="A." surname="Zaytsev"/>
<author initials="A." surname="Zaytsev"/> <date year="2014" month="May"/>
<date year="2014" month="May"/> </front>
</front> <seriesInfo name="DOI" value="10.1109/MCOM.2014.6815902"/>
<seriesInfo name='IEEE Communications Magazine, vol. 52, no. 5' value <refcontent>IEEE Communications Magazine, Volume 52, Issue 5</refcontent
=''/> >
</reference> </reference>
<reference anchor="ICAO18"> <!--LDACS--> <reference anchor="ICAO2022" target="https://www.ldacs.com/wp-content/uplo
<front> ads/2023/03/WP06.AppA-DCIWG-6-LDACS_SARPs.pdf">
<title>L-Band Digital Aeronautical Communication System (LDACS) <front>
</title> <title>CHAPTER 13 L-Band Digital Aeronautical Communications
<author initials="" surname="International Civil Aviation Organiz System (LDACS)</title>
ation (ICAO)"/> <author initials="" surname="">
<date year="2018"/> <organization>International Civil Aviation Organization
</front> (ICAO)</organization>
<seriesInfo name='International Standards and Recommended Practices A </author>
nnex 10 - Aeronautical Telecommunications, Vol. III - Communication Systems' val <date year="2022"/>
ue=''/> </front>
</reference> <refcontent>International Standards and Recommended Practices,
Annex 10 - Aeronautical Telecommunications, Volume III, Communication
Systems</refcontent>
</reference>
<reference anchor="IEEE80211-RT-TIG" target="http://www.ieee802.org/11/Rep <reference anchor="KOB12">
orts/rtatig_update.htm"> <front>
<front> <title>Playing catch and juggling with a humanoid robot</title>
<title>IEEE 802.11 Real Time Applications TIG Report</title> <author initials="J." surname="Kober"/>
<author> <author initials="M." surname="Glisson"/>
<organization>IEEE</organization> <author initials="M." surname="Mistry"/>
</author> <date month="November" year="2012"/>
<date year="2018" month="November"/> </front>
</front> <seriesInfo name="DOI" value="10.1109/HUMANOIDS.2012.6651623"/>
</reference> </reference>
<reference anchor="KOB12" target="https://doi.org/10.1109/HUMANOIDS.2012.6 <reference anchor="ODVA" target="https://www.odva.org/">
651623"> <front>
<front> <title>ODVA | Industrial Automation | Technologies and Standards</titl
<title>Playing catch and juggling with a humanoid robot.</title> e>
<author initials="J." surname="Kober" fullname="J. Kober"></author> <author>
<author initials="M." surname="Glisson" fullname="M. Glisson"></auth <organization>ODVA</organization>
or> </author>
<author initials="M." surname="Mistry" fullname="M. Mistry"></author <date/>
> </front>
<date year="2012"/>
</front>
</reference> </reference>
<reference anchor="ODVA"> <reference anchor="PROFINET" target="https://us.profinet.com/technology/pr
<front> ofinet/">
<title>The organization that supports network technologies built on <front>
the Common Industrial Protocol (CIP) including EtherNet/IP.</title> <title>PROFINET Technology</title>
<author> <author>
<organization>http://www.odva.org/</organization> <organization>PROFINET</organization>
</author> </author>
<date></date> <date/>
</front> </front>
</reference> </reference>
<reference anchor="PROFINET" target="http://us.profinet.com/technology/pr <reference anchor="EIP" target="https://www.odva.org/technology-standards/
ofinet/"> key-technologies/ethernet-ip/">
<front> <front>
<title>PROFINET is a standard for industrial networking in <title>EtherNet/IP | ODVA Technologies | Industrial Automation</title>
automation. </title> <author>
<author> <organization>ODVA</organization>
<organization>http://us.profinet.com/technology/profinet/</organi </author>
zation> <date/>
</author> </front>
<date></date>
</front>
</reference> </reference>
<reference anchor="EIP" target="http://www.odva.org/Portals/0/Library/Pub <reference anchor="ISA100" target="https://www.isa.org/isa100/">
lications_Numbered/PUB00138R3_CIP_Adv_Tech_Series_EtherNetIP.pdf"> <front>
<front> <title>ISA100, Wireless Systems for Automation</title>
<title> EtherNet/IP provides users with the network tools to deploy <author>
standard Ethernet technology (IEEE 802.3 combined with the TCP/IP <organization>ISA</organization>
Suite) for industrial automation applications while enabling Internet </author>
and enterprise connectivity data anytime, anywhere.</title> <date/>
<author> </front>
<organization>http://www.odva.org/</organization>
</author>
<date></date>
</front>
</reference> </reference>
<reference anchor="ISA100" target="https://www.isa.org/isa100/"> <reference anchor="ACI19" target="https://store.aci.aero/product/annual-wo
<front> rld-airport-traffic-report-2019/">
<title>ISA100, Wireless Systems for Automation</title> <front>
<author> <title>Annual World Airport Traffic Report, 2019</title>
<organization>ISA/ANSI</organization> <author>
</author> <organization>Airports Council International</organization>
<date/> </author>
</front> <date year="2019"/>
</front>
</reference> </reference>
<reference anchor="ACI19" target="https://store.aci.aero/product/annual-w <reference anchor="IAT20" target="https://www.iata.org/en/iata-repository/
orld-airport-traffic-report-2019/"> publications/economic-reports/airline-industry-economic-performance---november-2
<front> 020---report/">
<title>Annual World Aitport Traffic Report 2019</title> <front>
<author> <title>Economic Performance of the Airline Industry</title>
<organization>Airports Council International (ACI)</organizat <author>
ion> <organization>IATA</organization>
</author> </author>
<date year="2019" month="November"/> <date year="2020" month="November"/>
</front> </front>
</reference> </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>
</author>
<date year="2020" month="November"/>
</front>
</reference>
<reference anchor="IAC20"> <reference anchor="IAC20">
<front> <front>
<title>Estimating and projecting air passenger traffic <title>Estimating and projecting air passenger traffic during the
during the COVID-19 coronavirus outbreak and its socio- COVID-19 coronavirus outbreak and its socio-economic impact</title>
economic impact <author initials="S." surname="Iacus"/>
</title> <author initials="F." surname="Natale"/>
<author initials="S.M." surname="Iacus"/> <author initials="C." surname="Santamaria"/>
<author initials="F." surname="Natale"/> <author initials="S." surname="Spyratos"/>
<author initials="C." surname="Santamaria"/> <author initials="M." surname="Vespe"/>
<author initials="S." surname="Spyratos"/> <date month="September" year="2020"/>
<author initials="V." surname="Michele"/> </front>
<date year="2020" /> <seriesInfo name="DOI" value="10.1016/j.ssci.2020.104791"/>
</front> <refcontent>Safety Science, Volume 129</refcontent>
<seriesInfo name='Safety Science 129 (2020) 104791' value=''/> </reference>
</reference>
<reference anchor="IEEE802.1TSN"> <reference anchor="IEEE802.1AS">
<front> <front>
<title>IEEE 802.1AS-2011 - IEEE Standard for Local and Metropolitan A <title>IEEE Standard for Local and Metropolitan Area Networks--Timing
rea and Synchronization for Time-Sensitive Applications</title>
Networks - Timing and Synchronization for Time-Sensitive Applicati <author>
ons <organization>IEEE</organization>
in Bridged Local Area Networks </author>
</title> <date month="June" year="2020"/>
<author>
<organization>IEEE standard for Information Technology</organizati
on>
</author>
<date/>
</front> </front>
</reference> <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/pub lic/docs2020/new-Cavalcanti-802-1TSN-over-802-11-1120-v02.pdf"> <reference anchor="IEEE80211BE" target="https://www.ieee802.org/1/files/pu blic/docs2020/new-Cavalcanti-802-1TSN-over-802-11-1120-v02.pdf">
<front> <front>
<title>802.1 TSN over 802.11 with updates from developments in 802.11 <title>802.1 TSN over 802.11 with updates from developments in 802.11b
be e
</title> </title>
<author initials="D." surname="Cavalcanti" fullname="D. Cavalcanti">< <author initials="D." surname="Cavalcanti"/>
/author> <author initials="G." surname="Venkatesan"/>
<author initials="G." surname="Venkatesan" fullname="G. Venkatesan">< <date year="2020" month="November"/>
/author>
<date year="2020" month="November" />
</front> </front>
<seriesInfo name='IEEE plenary meeting' value=''/> <refcontent>IEEE plenary meeting</refcontent>
</reference> </reference>
<reference anchor="IEEE80211RTA"> <reference anchor="IEEE80211RTA">
<front> <front>
<title>IEEE 802.11 Real Time Applications TIG Report <title>IEEE 802.11 Real Time Applications TIG Report
</title> </title>
<author> <author>
<organization>IEEE standard for Information Technology</organizati <organization>IEEE standard for Information
on> Technology</organization>
</author> </author>
<date year="2018" month="November" /> <date year="2018" month="November"/>
</front> </front>
</reference> </reference>
<reference anchor="MAR19" target="https://ieeexplore.ieee.org/document/870 <reference anchor="MAR19">
3476"> <front>
<front> <title>A Square Peg in a Round Hole: The Complex Path for Wireless
<title>A Square Peg in a Round Hole: The Complex Path for Wireless i in the Manufacturing Industry</title>
n the Manufacturing Industry</title> <author initials="B." surname="Martinez"/>
<author initials="B." surname="Martinez" fullname="B. Martinez"></au <author initials="C." surname="Cano"/>
thor> <author initials="X." surname="Vilajosana"/>
<author initials="C." surname="Cano" fullname="C. Cano"></author> <date month="April" year="2019"/>
<author initials="X." surname="Vilajosana" fullname="X. Vilajosana"> </front>
</author> <seriesInfo name="DOI" value="10.1109/MCOM.2019.1800570"/>
<date year="2019"/> <refcontent>IEEE Communications Magazine, Volume 57, Issue
</front> 4</refcontent>
</reference> </reference>
<reference anchor="DGT2021" target="https://revista.dgt.es/es/reportajes/2 <reference quoteTitle="false" anchor="DGT2021" target="https://revista.dgt
021/01ENERO/0126-Como-funciona-un-operativo-con-drones.shtml"> .es/es/reportajes/2021/01ENERO/0126-Como-funciona-un-operativo-con-drones.shtml"
<front> >
<title>Drones: asi es la vigilancia</title> <front>
<author initials="J. M." surname="Menendez" fullname="J. M. Menendez <title>"Drones: así es la vigilancia" [Drones: this is surveillance]</
"></author> title>
<date year="2021"/> <author initials="J." surname="Menéndez"/>
</front> <date month="January" year="2021"/>
</front>
</reference> </reference>
<reference anchor="Groshev2021" target="https://doi.org/10.1109/ACCESS.202 <reference anchor="Groshev2021">
1.3098109"> <front>
<front> <title>Dissecting the Impact of Information and Communication
<title>Dissecting the Impact of Information and Communication Techno Technologies on Digital Twins as a Service</title>
logies on Digital Twins as a Service</title> <author initials="M." surname="Groshev"/>
<author initials="M." surname="Groshev" fullname="M. Groshev"></auth <author initials="C." surname="Guimarães"/>
or> <author initials="A." surname="de la Oliva"/>
<author initials="C." surname="Guimaraes" fullname="C. Guimaraes"></ <author initials="R." surname="Gazda"/>
author> <date month="July" year="2021"/>
<author initials="A." surname="de la Oliva" fullname="A. de la Oliva </front>
"></author> <seriesInfo name="DOI" value="10.1109/ACCESS.2021.3098109"/>
<author initials="B." surname="Gazda" fullname="B. Gazda"></author> <refcontent>IEEE Access, Volume 9</refcontent>
<date year="2021"/>
</front>
<seriesInfo name='IEEE Access, vol. 9' value=''/>
</reference> </reference>
<reference anchor="Maurer2022" target="https://doi.org/10.1016/j.ijcip.202 <reference anchor="Maurer2022">
2.100549"> <front>
<front> <title>Security in Digital Aeronautical Communications A
<title>Security in Digital Aeronautical Communications A Comprehensi Comprehensive Gap Analysis</title>
ve Gap Analysis</title> <author initials="N." surname="Mäurer"/>
<author initials="N." surname="Maurer" fullname="N. Maurer"></author <author initials="T." surname="Guggemos"/>
> <author initials="T." surname="Ewert"/>
<author initials="T." surname="Ewert" fullname="T. Ewert"></author> <author initials="T." surname="Gräupl"/>
<author initials="T." surname="Graupl" fullname="T. Graupl"></author <author initials="C." surname="Schmitt"/>
> <author initials="S." surname="Grundner-Culemann"/>
<author initials="C." surname="Schmitt" fullname="C. Schmitt"></auth <date month="September" year="2022"/>
or> </front>
<author initials="S." surname="Grundner-Culemann" fullname="S. Grund <seriesInfo name="DOI" value="10.1016/j.ijcip.2022.100549"/>
ner-Culemann"></author> <refcontent>International Journal of Critical Infrastructure
<date year="2022"/> Protection, Volume 38</refcontent>
</front>
<seriesInfo name='International Journal of Critical Infrastructure
Protection,
vol. 38' value=''/>
</reference> </reference>
<reference anchor="ARINC858P1" target="https://www.sae.org/standards/conte nt/arinc858p1/"> <reference anchor="ARINC858P1" target="https://www.sae.org/standards/conte nt/arinc858p1/">
<front> <front>
<title>INTERNET PROTOCOL SUITE (IPS) FOR AERONAUTICAL SAFETY SERVICE <title>Internet Protocol Suite (IPS) for Aeronautical Safety
S PART 1 AIRBORNE IPS SYSTEM TECHNICAL REQUIREMENTS</title> Services Part 1 Airborne IPS System Technical Requirements</title>
<author> <author>
<organization>ARINC</organization> <organization>SAE International</organization>
</author> </author>
<date year="2021"/> <date month="June" year="2021"/>
</front> </front>
<refcontent>ARINC858P1</refcontent>
</reference> </reference>
</references> </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>
</back>
</rfc> </rfc>
 End of changes. 135 change blocks. 
1650 lines changed or deleted 1397 lines changed or added

This html diff was produced by rfcdiff 1.48.