< draft-ietf-raw-use-cases-03.txt   draft-ietf-raw-use-cases-04.txt >
RAW G. Papadopoulos RAW CJ. Bernardos, Ed.
Internet-Draft IMT Atlantique Internet-Draft UC3M
Intended status: Standards Track P. Thubert Intended status: Standards Track G.Z. Papadopoulos
Expires: April 23, 2022 Cisco Expires: 8 August 2022 IMT Atlantique
P. Thubert
Cisco
F. Theoleyre F. Theoleyre
CNRS CNRS
CJ. Bernardos, Ed. 4 February 2022
UC3M
October 20, 2021
RAW use cases RAW use-cases
draft-ietf-raw-use-cases-03 draft-ietf-raw-use-cases-04
Abstract Abstract
The wireless medium presents significant specific challenges to The wireless medium presents significant specific challenges to
achieve properties similar to those of wired deterministic networks. achieve properties similar to those of wired deterministic networks.
At the same time, a number of use cases cannot be solved with wires At the same time, a number of use-cases cannot be solved with wires
and justify the extra effort of going wireless. This document and justify the extra effort of going wireless. This document
presents wireless use cases demanding reliable and available presents wireless use-cases (such as aeronautical communications,
behavior. amusement parks, industrial applications, pro audio and video,
gaming, UAV and V2V control, edge robotics and emergency vehicles)
demanding reliable and available behavior.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 23, 2022. This Internet-Draft will expire on 8 August 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Revised BSD License text as
include Simplified BSD License text as described in Section 4.e of described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Revised BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Aeronautical Communications . . . . . . . . . . . . . . . . . 5 2. Aeronautical Communications . . . . . . . . . . . . . . . . . 5
2.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 5 2.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 5
2.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Challenges . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Challenges . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. The Need for Wireless . . . . . . . . . . . . . . . . . . 7 2.4. The Need for Wireless . . . . . . . . . . . . . . . . . . 8
2.5. Requirements for RAW . . . . . . . . . . . . . . . . . . 7 2.5. Requirements for RAW . . . . . . . . . . . . . . . . . . 8
2.5.1. Non-latency critical considerations . . . . . . . . . 8 2.5.1. Non-latency critical considerations . . . . . . . . . 9
3. Amusement Parks . . . . . . . . . . . . . . . . . . . . . . . 8 3. Amusement Parks . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Use Case Description . . . . . . . . . . . . . . . . . . 8 3.1. use-case Description . . . . . . . . . . . . . . . . . . 9
3.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 9 3.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 10
3.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 9 3.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 10
3.4.1. Non-latency critical considerations . . . . . . . . . 10 3.4.1. Non-latency critical considerations . . . . . . . . . 11
4. Wireless for Industrial Applications . . . . . . . . . . . . 10 4. Wireless for Industrial Applications . . . . . . . . . . . . 11
4.1. Use Case Description . . . . . . . . . . . . . . . . . . 10 4.1. use-case Description . . . . . . . . . . . . . . . . . . 11
4.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.1. Control Loops . . . . . . . . . . . . . . . . . . . . 10 4.2.1. Control Loops . . . . . . . . . . . . . . . . . . . . 11
4.2.2. Unmeasured Data . . . . . . . . . . . . . . . . . . . 11 4.2.2. Unmeasured Data . . . . . . . . . . . . . . . . . . . 12
4.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 11 4.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 12
4.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 12 4.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 13
4.4.1. Non-latency critical considerations . . . . . . . . . 12 4.4.1. Non-latency critical considerations . . . . . . . . . 14
5. Pro Audio and Video . . . . . . . . . . . . . . . . . . . . . 13 5. Pro Audio and Video . . . . . . . . . . . . . . . . . . . . . 14
5.1. Use Case Description . . . . . . . . . . . . . . . . . . 13 5.1. use-case Description . . . . . . . . . . . . . . . . . . 14
5.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2.1. Uninterrupted Stream Playback . . . . . . . . . . . . 13 5.2.1. Uninterrupted Stream Playback . . . . . . . . . . . . 14
5.2.2. Synchronized Stream Playback . . . . . . . . . . . . 13 5.2.2. Synchronized Stream Playback . . . . . . . . . . . . 14
5.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 13 5.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 15
5.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 14 5.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 15
5.4.1. Non-latency critical considerations . . . . . . . . . 14 5.4.1. Non-latency critical considerations . . . . . . . . . 15
6. Wireless Gaming . . . . . . . . . . . . . . . . . . . . . . . 14 6. Wireless Gaming . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Use Case Description . . . . . . . . . . . . . . . . . . 14 6.1. use-case Description . . . . . . . . . . . . . . . . . . 15
6.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 16
6.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 15 6.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 16
6.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 15 6.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 16
6.4.1. Non-latency critical considerations . . . . . . . . . 16 6.4.1. Non-latency critical considerations . . . . . . . . . 17
7. UAV and V2V platooning and control . . . . . . . . . . . . . 16
7.1. Use Case Description . . . . . . . . . . . . . . . . . . 16 7. Unmanned Aerial Vehicles and Vehicle-to-Vehicle platooning and
7.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 17 control . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 17 7.1. use-case Description . . . . . . . . . . . . . . . . . . 17
7.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 17 7.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 18
7.4.1. Non-latency critical considerations . . . . . . . . . 17 7.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 18
8. Edge Robotics control . . . . . . . . . . . . . . . . . . . . 17 7.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 18
8.1. Use Case Description . . . . . . . . . . . . . . . . . . 17 7.4.1. Non-latency critical considerations . . . . . . . . . 19
8.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Edge Robotics control . . . . . . . . . . . . . . . . . . . . 19
8.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 18 8.1. use-case Description . . . . . . . . . . . . . . . . . . 19
8.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 18 8.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 20
8.4.1. Non-latency critical considerations . . . . . . . . . 19 8.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 20
9. Emergencies: Instrumented emergency vehicle . . . . . . . . . 19 8.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 20
9.1. Use Case Description . . . . . . . . . . . . . . . . . . 19 8.4.1. Non-latency critical considerations . . . . . . . . . 20
9.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 19 9. Emergencies: Instrumented emergency vehicle . . . . . . . . . 20
9.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 20 9.1. use-case Description . . . . . . . . . . . . . . . . . . 20
9.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 20 9.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 21
9.4.1. Non-latency critical considerations . . . . . . . . . 20 9.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 21
10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 21
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9.4.1. Non-latency critical considerations . . . . . . . . . 22
12. Security Considerations . . . . . . . . . . . . . . . . . . . 21 10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
14. Informative References . . . . . . . . . . . . . . . . . . . 21 12. Security Considerations . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
14.1. Normative References . . . . . . . . . . . . . . . . . . 23
14.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
Based on time, resource reservation, and policy enforcement by Based on time, resource reservation, and policy enforcement by
distributed shapers, Deterministic Networking provides the capability distributed shapers, Deterministic Networking provides the capability
to carry specified unicast or multicast data streams for real-time to carry specified unicast or multicast data streams for real-time
applications with extremely low data loss rates and bounded latency, applications with extremely low data loss rates and bounded latency,
so as to support time-sensitive and mission-critical applications on to support time-sensitive and mission-critical applications on a
a converged enterprise infrastructure. converged enterprise infrastructure.
Deterministic Networking in the IP world is an attempt to eliminate Deterministic Networking in the IP world is an attempt to eliminate
packet loss for a committed bandwidth while ensuring a worst case packet loss for a committed bandwidth while ensuring a worst case
end-to-end latency, regardless of the network conditions and across end-to-end latency, regardless of the network conditions and across
technologies. It can be seen as a set of new Quality of Service technologies. By leveraging on lower (L2 and below) capabilities, L3
(QoS) guarantees of worst-case delivery. IP networks become more can exploit the use of a service layer, steering over multiple
deterministic when the effects of statistical multiplexing (jitter technologies, and using media independent signaling to provide high
and collision loss) are mostly eliminated. This requires a tight reliability, precise time delivery, and rate enforcement.
control of the physical resources to maintain the amount of traffic Deterministic networking can be seen as a set of new Quality of
within the physical capabilities of the underlying technology, e.g., Service (QoS) guarantees of worst-case delivery. IP networks become
by the use of time-shared resources (bandwidth and buffers) per more deterministic when the effects of statistical multiplexing
circuit, and/or by shaping and/or scheduling the packets at every (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. hop.
Key attributes of Deterministic Networking include: Key attributes of Deterministic Networking include:
o time synchronization on all the nodes, * time synchronization on all the nodes,
o centralized computation of network-wide deterministic paths,
o multi-technology path with co-channel interference minimization, * centralized computation of network-wide deterministic paths,
o frame preemption and guard time mechanisms to ensure a worst-case * multi-technology path with co-channel interference minimization,
* frame preemption and guard time mechanisms to ensure a worst-case
delay, and delay, and
o new traffic shapers within and at the edge to protect the network. * new traffic shapers within and at the edge to protect the network.
Wireless operates on a shared medium, and transmissions cannot be Wireless operates on a shared medium, and transmissions cannot be
fully deterministic due to uncontrolled interferences, including guaranteed to be fully deterministic due to uncontrolled
self-induced multipath fading. RAW (Reliable and Available Wireless) interferences, including self-induced multipath fading. Reliable and
is an effort to provide Deterministic Networking Mechanisms on across Available Wireless (RAW) is an effort to provide Deterministic
a multi-hop path that include a wireless physical layer. Making Networking Mechanisms on across a multi-hop path that includes a
Wireless Reliable and Available is even more challenging than it is wireless physical layer. Making Wireless Reliable and Available is
with wires, due to the numerous causes of loss in transmission that even more challenging than it is with wires, due to the numerous
add up to the congestion losses and the delays caused by overbooked causes of loss in transmission that add up to the congestion losses
shared resources. and the delays caused by overbooked shared resources.
The wireless and wired media are fundamentally different at the The wireless and wired media are fundamentally different at the
physical level, and while the generic Problem Statement [RFC8557] for physical level, and while the generic Problem Statement [RFC8557] for
DetNet applies to the wired as well as the wireless medium, the DetNet applies to the wired as well as the wireless medium, the
methods to achieve RAW necessarily differ from those used to support methods to achieve RAW necessarily differ from those used to support
Time-Sensitive Networking over wires. Time-Sensitive Networking over wires, e.g., due to the wireless radio
channel specifics.
So far, Open Standards for Deterministic Networking have prevalently So far, Open Standards for Deterministic Networking have prevalently
been focused on wired media, with Audio/Video Bridging (AVB) and Time been focused on wired media, with Audio/Video Bridging (AVB) and Time
Sensitive Networking (TSN) at the IEEE and DetNet [RFC8655] at the Sensitive Networking (TSN) at the IEEE and DetNet [RFC8655] at the
IETF. But wires cannot be used in a number of cases, including IETF. But wires cannot be used in several cases, including mobile or
mobile or rotating devices, rehabilitated industrial buildings, rotating devices, rehabilitated industrial buildings, wearable or in-
wearable or in-body sensory devices, vehicle automation and body sensory devices, vehicle automation and multiplayer gaming.
multiplayer gaming.
Purpose-built wireless technologies such as [ISA100], which Purpose-built wireless technologies such as [ISA100], which
incorporates IPv6, were developed and deployed to cope for the lack incorporates IPv6, were developed and deployed to cope for the lack
of open standards, but they yield a high cost in OPEX and CAPEX and of open standards, but they yield a high cost in OPEX and CAPEX and
are limited to very few industries, e.g., process control, concert are limited to very few industries, e.g., process control, concert
instruments or racing. instruments or racing.
This is now changing [I-D.thubert-raw-technologies]: This is now changing [I-D.ietf-raw-technologies]:
o IMT-2020 has recognized Ultra-Reliable Low-Latency Communication * IMT-2020 has recognized Ultra-Reliable Low-Latency Communication
(URLLC) as a key functionality for the upcoming 5G. (URLLC) as a key functionality for the upcoming 5G.
o IEEE 802.11 has identified a set of real-applications * IEEE 802.11 has identified a set of real-applications
[ieee80211-rt-tig] which may use the IEEE802.11 standards. They [IEEE80211-RT-TIG] which may use the IEEE802.11 standards. They
typically emphasize strict end-to-end delay requirements. typically emphasize strict end-to-end delay requirements.
o The IETF has produced an IPv6 stack for IEEE Std. 802.15.4 * The IETF has produced an IPv6 stack for IEEE Std. 802.15.4
TimeSlotted Channel Hopping (TSCH) and an architecture [RFC9030] TimeSlotted Channel Hopping (TSCH) and an architecture [RFC9030]
that enables Reliable and Available Wireless (RAW) on a shared that enables RAW on a shared MAC.
MAC.
This draft extends the "Deterministic Networking Use Cases" document Experiments have already been conducted with IEEE802.1 TSN over
[RFC8578] and describes a number of additional use cases which IEEE802.11be [IEEE80211BE]. This mode enables time synchronization,
require "reliable/predictable and available" flows over wireless and time-aware scheduling (trigger based access mode) to support TSN
links and possibly complex multi-hop paths called Tracks. This is flows.
covered mainly by the "Wireless for Industrial Applications" use
case, as the "Cellular Radio" is mostly dedicated to the (wired) This draft extends the "Deterministic Networking use-cases" document
transport part of a Radio Access Network (RAN). Whereas the [RFC8578] and describes several additional use-cases which require
"Wireless for Industrial Applications" use case certainly covers an "reliable/predictable and available" flows over wireless links and
area of interest for RAW, it is limited to 6TiSCH, and thus its scope possibly complex multi-hop paths called Tracks. This is covered
is narrower than the use cases described next in this document. mainly by the "Wireless for Industrial Applications" use-case, as the
"Cellular Radio" is mostly dedicated to the (wired) transport part of
a Radio Access Network (RAN). Whereas the "Wireless for Industrial
Applications" use-case certainly covers an area of interest for RAW,
it is limited to 6TiSCH, and thus its scope is narrower than the use-
cases described next in this document.
2. Aeronautical Communications 2. Aeronautical Communications
Aircraft are currently connected to ATC (Air-Traffic Control) and AOC Aircraft are currently connected to ATC (Air-Traffic Control) and AOC
(Airline Operational Control) via voice and data communications (Airline Operational Control) via voice and data communications
systems through all phases of a flight. Within the airport terminal, systems through all phases of a flight. Within the airport terminal,
connectivity is focused on high bandwidth communications while during connectivity is focused on high bandwidth communications while during
en-route high reliability, robustness and range is the main focus. en-route high reliability, robustness and range are the focus.
2.1. Problem Statement 2.1. Problem Statement
Up to 2020 civil air traffic has been growing constantly at a Up to 2020, civil air traffic has been growing constantly at a
compound rate of 5.8% per year [ACI19] and despite the severe impact compound rate of 5.8% per year [ACI19] and despite the severe impact
of the COVID-19 pandemic, air traffic growth is expected to resume of the COVID-19 pandemic, air traffic growth is expected to resume
very quickly in post-pandemic times [IAT20] [IAC20]. Thus, legacy very quickly in post-pandemic times [IAT20] [IAC20]. Thus, legacy
systems in air traffic management (ATM) are likely to reach their systems in air traffic management (ATM) are likely to reach their
capacity limits and the need for new aeronautical communication capacity limits and the need for new aeronautical communication
technologies becomes apparent. Especially problematic is the technologies becomes apparent. Especially problematic is the
saturation of VHF band in high density areas in Europe, the US, and saturation of VHF band in high density areas in Europe, the US, and
Asia [KEAV20] [FAA20] calling for suitable new digital approaches Asia [KEAV20] [FAA20] calling for suitable new digital approaches
such as AeroMACS for airport communications, SatCOM for remote such as AeroMACS for airport communications, SatCOM for remote
domains, and LDACS as long-range terrestrial aeronautical domains, and LDACS as long-range terrestrial aeronautical
communications system. Making the frequency spectrum's usage more communications system. Making the frequency spectrum's usage more
efficient a transition from analogue voice to digital data efficient a transition from analog voice to digital data
communication [PLA14] is necessary to cope with the expected growth communication [PLA14] is necessary to cope with the expected growth
of civil aviation and its supporting infrastructure. A promising of civil aviation and its supporting infrastructure. A promising
candidate for long range terrestrial communications, already in the candidate for long range terrestrial communications, already in the
process of being standardized in the International Civil Aviation process of being standardized in the International Civil Aviation
Organization (ICAO), is the L-band Digital Aeronautical Organization (ICAO), is the L-band Digital Aeronautical
Communications System (LDACS) [ICAO18] [I-D.ietf-raw-ldacs]. Communications System (LDACS) [ICAO18] [I-D.ietf-raw-ldacs].
2.2. Specifics 2.2. Specifics
During the creation process of new communications system, analogue During the creation process of new communications system, analog
voice is replaced by digital data communication. This sets a voice is replaced by digital data communication. This sets a
paradigm shift from analogue to digital wireless communications and paradigm shift from analog to digital wireless communications and
supports the related trend towards increased autonomous data supports the related trend towards increased autonomous data
processing that the Future Communications Infrastructure (FCI) in processing that the Future Communications Infrastructure (FCI) in
civil aviation must provide. The FCI is depicted in Figure 1: civil aviation must provide. The FCI is depicted in Figure 1:
Satellite Satellite
# # # #
# # # # # #
# # # # # #
# # # # # #
# # # # # #
skipping to change at page 6, line 48 skipping to change at page 7, line 39
# AeroMACS (-) | | # AeroMACS (-) | |
# | | # | |
# Aircraft-------------+ | | # Aircraft-------------+ | |
# | | | # | | |
# | | | # | | |
# Ground network | | Ground network | # Ground network | | Ground network |
SatCOM <---------------------> Airport <----------------------> LDACS SatCOM <---------------------> Airport <----------------------> LDACS
transceiver based GS transceiver based GS
transceiver transceiver
Figure 1: The Future Communication Infrastructure (FCI): AeroMACS for Figure 1: The Future Communication Infrastructure (FCI): AeroMACS
APT/TMA domain, LDACS A/G for TMA/ENR domain, LDACS A/G for ENR/ORP for APT/TMA domain, LDACS A/G for TMA/ENR domain, LDACS A/G for
domain, SatCOM for ORP domain communications ENR/ORP domain, SatCOM for ORP domain communications
2.3. Challenges 2.3. Challenges
This paradigm change brings a lot of new challenges: This paradigm change brings a lot of new challenges:
o Efficiency: It is necessary to keep latency, time and data * Efficiency: It is necessary to keep latency, time and data
overhead (routing, security) of new aeronautical datalinks at a overhead (routing, security) of new aeronautical datalinks at a
minimum. minimum.
o Modularity: Systems in avionics usually operate up to 30 years, * Modularity: Systems in avionics usually operate up to 30 years,
thus solutions must be modular, easily adaptable and updatable. thus solutions must be modular, easily adaptable and updatable.
o Interoperability: All 192 members of the international Civil * Interoperability: All 192 members of the international Civil
Aviation Organization (ICAO) must be able to use these solutions. Aviation Organization (ICAO) must be able to use these solutions.
* Dynamicity: the communication infrastructure needs to accomodate
mobile devices (airplanes) that move extremely fast.
2.4. The Need for Wireless 2.4. The Need for Wireless
In a high mobility environment such as aviation, the envisioned In a high mobility environment such as aviation, the envisioned
solutions to provide worldwide coverage of data connections with in- solutions to provide worldwide coverage of data connections with in-
flight aircraft require a multi-system, multi-link, multi-hop flight aircraft require a multi-system, multi-link, multi-hop
approach. Thus air, ground and space-based datalink providing approach. Thus air, ground and space-based datalink providing
technologies will have to operate seamlessly together to cope with technologies will have to operate seamlessly together to cope with
the increasing needs of data exchange between aircraft, air traffic the increasing needs of data exchange between aircraft, air traffic
controller, airport infrastructure, airlines, air network service controller, airport infrastructure, airlines, air network service
providers (ANSPs) and so forth. Thus, making use of wireless providers (ANSPs) and so forth. Thus, making use of wireless
skipping to change at page 7, line 46 skipping to change at page 8, line 41
warning that two aircraft come dangerously close to each other - and warning that two aircraft come dangerously close to each other - and
high resiliency, to less safety critical ones requiring low-medium high resiliency, to less safety critical ones requiring low-medium
latency for services such as WXGRAPH - graphical weather data. latency for services such as WXGRAPH - graphical weather data.
Overhead needs to be kept at a minimum since aeronautical data links Overhead needs to be kept at a minimum since aeronautical data links
provide comparatively small data rates in the order of kbit/s. provide comparatively small data rates in the order of kbit/s.
Policy needs to be supported when selecting data links. The focus of Policy needs to be supported when selecting data links. The focus of
RAW here should be on the selectors, responsible for the track a RAW here should be on the selectors, responsible for the track a
packet takes to reach its end destination. This would minimize the packet takes to reach its end destination. This would minimize the
amount of routing information that has to travel inside the network amount of routing information that must travel inside the network
because of precomputed routing tables with the selector being because of precomputed routing tables with the selector being
responsible for choosing the most appropriate option according to responsible for choosing the most appropriate option according to
policy and safety. policy and safety.
2.5.1. Non-latency critical considerations 2.5.1. Non-latency critical considerations
Achieving low latency is a requirement for aeronautics Achieving low latency is a requirement for aeronautics
communications, though the expected latency is not extremely low and communications, though the expected latency is not extremely low and
what it is important is to keep the overall latency bounded under a what it is important is to keep the overall latency bounded under a
certain threshold. This use case is not latency critical from that certain threshold. This use-case is not latency-critical from that
view point. On the other hand, given the controlled environment, view point. On the other hand, given the controlled environment,
end-to-end mechanisms can be applied to guarantee bounded latency end-to-end mechanisms can be applied to guarantee bounded latency
where needed. where needed.
3. Amusement Parks 3. Amusement Parks
3.1. Use Case Description 3.1. use-case Description
The digitalization of Amusement Parks is expected to decrease The digitalization of Amusement Parks is expected to decrease
significantly the cost for maintaining the attractions. Such significantly the cost for maintaining the attractions. Such
deployment is a mix between industrial automation (aka. Smart deployment is a mix between industrial automation (i.e., Smart
Factories) and multimedia entertainment applications. Factories) and multimedia entertainment applications.
Attractions may rely on a large set of sensors and actuators, which Attractions may rely on a large set of sensors and actuators, which
react in real time. Typical applications comprise: react in real time. Typical applications comprise:
o Emergency: safety has to be preserved, and must stop the * Emergency: safety has to be preserved, and must stop the
attraction when a failure is detected. attraction when a failure is detected.
o Video: augmented and virtual realities are integrated in the * Video: augmented and virtual realities are integrated in the
attraction. Wearable mobile devices (e.g., glasses, virtual attraction. Wearable mobile devices (e.g., glasses, virtual
reality headset) need to offload one part of the processing tasks. reality headset) need to offload one part of the processing tasks.
o Real-time interactions: visitors may interact with an attraction, * Real-time interactions: visitors may interact with an attraction,
like in a real-time video game. The visitors may virtually like in a real-time video game. The visitors may virtually
interact with their environment, triggering actions in the real interact with their environment, triggering actions in the real
world (through actuators) [robots]. world (through actuators) [KOB12].
o Geolocation: visitors are tracked with a personal wireless tag so * Geolocation: visitors are tracked with a personal wireless tag so
that their user experience is improved. that their user experience is improved.
o Predictive maintenance: statistics are collected to predict the * Predictive maintenance: statistics are collected to predict the
future failures, or to compute later more complex statistics about future failures, or to compute later more complex statistics about
the attraction's usage, the downtime, its popularity, etc. the attraction's usage, the downtime or its popularity for
example.
3.2. Specifics 3.2. Specifics
Amusement parks comprise a variable number of attractions, mostly Amusement parks comprise a variable number of attractions, mostly
outdoor, over a large geographical area. The IT infrastructure is outdoor, over a large geographical area. The IT infrastructure is
typically multi-scale: typically multi-scale:
o Local area: the sensors and actuators controlling the attractions * Local area: the sensors and actuators controlling the attractions
are co-located. Control loops trigger only local traffic, with a are co-located. Control loops trigger only local traffic, with a
small end-to-end delay, typically inferior than 10 milliseconds, small end-to-end delay, typically inferior to 10 ms, like
like classical industrial systems [ieee80211-rt-tig]. classical industrial systems [IEEE80211-RT-TIG].
o Wearable mobile devices are free to move in the park. They * Wearable mobile devices are free to move in the park. They
exchange traffic locally (identification, personalization, exchange traffic locally (identification, personalization,
multimedia) or globally (billing, child tracking). multimedia) or globally (billing, child tracking).
o Computationally intensive applications offload some tasks. Edge * Computationally intensive applications offload some tasks. Edge
computing seems an efficient way to implement real-time computing seems an efficient way to implement real-time
applications with offloading. Some non time-critical tasks may applications with offloading. Some non-time-critical tasks may
rather use the cloud (predictive maintenance, marketing). rather use the cloud (predictive maintenance, marketing).
3.3. The Need for Wireless 3.3. The Need for Wireless
Amusement parks cover large areas and a global interconnection would Amusement parks cover large areas, and a global interconnection would
require a huge length of cables. Wireless also increases the require a huge length of cables. Wireless also increases the
reconfigurability, enabling to update cheaply the attractions. The reconfigurability, enabling to update an attraction at a lower cost.
frequent renewal helps to increase customer loyalty. The frequent renewal helps to increase the customer loyalty.
Some parts of the attraction are mobile, e.g., trucks of a roller- Some parts of the attraction are mobile, like trucks of a roller-
coaster, robots. Since cables are prone to frequent failures in this coaster or robots. Since cables are prone to frequent failures in
situation, wireless transmissions are recommended. this situation, wireless transmissions are recommended.
Wearable devices are extensively used for a user experience Wearable devices are extensively used for a user experience
personalization. They typically need to support wireless personalization. They typically need to support wireless
transmissions. Personal tags may help to reduce the operating costs transmissions. Personal tags may help to reduce the operating costs
[disney-VIP] and to increase the number of charged services provided [DISNEY15] and to increase the number of charged services provided to
to the audience (VIP tickets, interactivity, etc.) Some applications the audience (e.g., VIP tickets or interactivity). Some applications
rely on more sophisticated wearable devices such as digital glasses rely on more sophisticated wearable devices such as digital glasses
or Virtual Reality (VR) headsets for an immersive experience. or Virtual Reality (VR) headsets for an immersive experience.
3.4. Requirements for RAW 3.4. Requirements for RAW
The network infrastructure has to support heterogeneous traffic, with The network infrastructure must support heterogeneous traffic, with
very different critical requirements. Thus, flow isolation has to be very different critical requirements. Thus, flow isolation must be
provided. provided.
We have to schedule appropriately the transmissions, even in presence The transmissions must be scheduled appropriately even in presence of
of mobile devices. While the [RFC9030] already proposes an mobile devices. While the [RFC9030] already proposes an architecture
architecture for synchronized, IEEE Std. 802.15.4 Time-Slotted for synchronized, IEEE Std. 802.15.4 Time-Slotted Channel Hopping
Channel Hopping (TSCH) networks, we still need multi-technology (TSCH) networks, the industry requires a multi-technology solution,
solutions, able to guarantee end-to-end requirements across able to guarantee end-to-end requirements across heterogeneous
heterogeneous technologies, with strict SLA requirements. technologies, with strict SLA requirements.
Nowadays, long-range wireless transmissions are used mostly for best- Nowadays, long-range wireless transmissions are used mostly for best-
effort traffic. On the contrary, [IEEE802.1TSN] is used for critical effort traffic. On the contrary, [IEEE802.1TSN] is used for critical
flows using Ethernet devices. However, we need an IP enabled flows using Ethernet devices. However, IP enabled technology is
technology to interconnect large areas, independent of the PHY and required to interconnect large areas, independent of the PHY and MAC
MAC layers. layers.
We expect to deploy several different technologies (long vs. short It is expected that several different technologies (long vs. short
range) which have to cohabit in the same area. Thus, we need to range) are deployed, which have to cohabit in the same area. Thus,
provide layer-3 mechanisms able to exploit multiple co-interfering we need to provide layer-3 mechanisms able to exploit multiple co-
technologies. interfering technologies.
3.4.1. Non-latency critical considerations 3.4.1. Non-latency critical considerations
While some of the applications in this use case involve control loops While some of the applications in this use-case involve control loops
(sensors and actuators) that require bounded latencies below 10 ms, (e.g., sensors and actuators) that require bounded latencies below 10
that can therefore be considered latency critical, there are other ms, that can therefore be considered latency critical, there are
applications as well that mostly demand reliability (e.g., safety other applications as well that mostly demand reliability (e.g.,
related, or maintenance). safety related, or maintenance).
4. Wireless for Industrial Applications 4. Wireless for Industrial Applications
4.1. Use Case Description 4.1. use-case Description
A major use case for networking in Industrial environments is the A major use-case for networking in Industrial environments is the
control networks where periodic control loops operate between a control networks where periodic control loops operate between a
sensor that measures a physical property such as the temperature of a collection of sensors that measure a physical property such as the
fluid, a Programmable Logic Controller (PLC) that decides an action temperature of a fluid, a Programmable Logic Controller (PLC) that
such as warm up the mix, and an actuator that performs the required decides an action such as warm up the mix, and actuators that perform
action, e.g., inject power in a resistor. the required action, such as the injection of power in a resistor.
4.2. Specifics 4.2. Specifics
4.2.1. Control Loops 4.2.1. Control Loops
Process Control designates continuous processing operations, e.g., Process Control designates continuous processing operations, like
heating Oil in a refinery or mixing drinking soda. Control loops in heating Oil in a refinery or mixing drinking soda. Control loops in
the Process Control industry operate at a very low rate, typically 4 the Process Control industry operate at a very low rate, typically
times per second. Factory Automation, on the other hand, deal with four times per second. Factory Automation, on the other hand, deals
discrete goods such as individual automobile parts, and requires with discrete goods such as individual automobile parts, and requires
faster loops, in the order of 10ms. Motion control that monitors faster loops, in the order of milliseconds. Motion control that
dynamic activities may require even faster rates in the order of a monitors dynamic activities may require even faster rates in the
few ms. Finally, some industries exhibit hybrid behaviors, like order of and below the millisecond. Finally, some industries exhibit
canned soup that will start as a process industry while mixing the hybrid behaviors, like canned soup that will start as a process
food and then operate as a discrete manufacturing when putting the industry while mixing the food and then operate as a discrete
final product in cans and shipping them. manufacturing when putting the final product in cans and shipping
them.
In all those cases, a packet must flow reliably between the sensor In all those cases, a packet must flow reliably between the sensor
and the PLC, be processed by the PLC, and sent to the actuator within and the PLC, be processed by the PLC, and sent to the actuator within
the control loop period. In some particular use cases that inherit the control loop period. In some particular use-cases that inherit
from analog operations, jitter might also alter the operation of the from analog operations, jitter might also alter the operation of the
control loop. A rare packet loss is usually admissible, but control loop. A rare packet loss is usually admissible, but
typically 4 losses in a row will cause an emergency halt of the typically 4 losses in a row will cause an emergency halt of the
production and incur a high cost for the manufacturer. production and incur a high cost for the manufacturer.
Additional use cases related to Industrial applications and their RAW Additional details and use-cases related to Industrial applications
requirements can be found at [I-D.sofia-raw-industrialreq]. and their RAW requirements can be found in
[I-D.ietf-raw-industrial-requirements].
4.2.2. Unmeasured Data 4.2.2. Unmeasured Data
A secondary use case deals with monitoring and diagnostics. This so- A secondary use-case deals with monitoring and diagnostics. This so-
called unmeasured data is essential to improve the performances of a called unmeasured data is essential to improve the performances of a
production line, e.g., by optimizing real-time processing or production line, e.g., by optimizing real-time processing or
maintenance windows using Machine Learning predictions. For the lack maintenance windows using Machine Learning predictions. For the lack
of wireless technologies, some specific industries such as Oil and of wireless technologies, some specific industries such as Oil and
Gas have been using serial cables, literally by the millions, to Gas have been using serial cables, literally by the millions, to
perform their process optimization over the previous decades. But perform their process optimization over the previous decades. But
few industries would afford the associated cost and the Holy Grail of few industries would afford the associated cost and the Holy Grail of
the Industrial Internet of Things is to provide the same benefits to the Industrial Internet of Things is to provide the same benefits to
all industries, including SmartGrid, Transportation, Building, all industries, including SmartGrid, Transportation, Building,
Commercial and Medical. This requires a cheap, available and Commercial and Medical. This requires a cheap, available and
scalable IP-based access technology. scalable IP-based access technology.
Inside the factory, wires may already be available to operate the Inside the factory, wires may already be available to operate the
Control Network. But unmeasured data are not welcome in that network Control Network. But unmeasured data are not welcome in that network
for a number of reasons. On the one hand it is rich and for several reasons. On the one hand it is rich and asynchronous,
asynchronous, meaning that using they may influence the deterministic meaning that it may influence the deterministic nature of the control
nature of the control operations and impact the production. On the operations and impact the production. On the other hand, this
other hand, this information must be reported to the carpeted floor information must be reported to the carpeted floor over IP, which
over IP, which means the potential for a security breach via the means the potential for a security breach via the interconnection of
interconnection of the Operational Technology (OT) network with the the Operational Technology (OT) network with the Internet technology
Internet technology (IT) network and possibly enable a rogue access. (IT) network and possibly enable a rogue access.
4.3. The Need for Wireless 4.3. The Need for Wireless
Ethernet cables used on a robot arm are prone to breakage after a few Ethernet cables used on a robot arm are prone to breakage after a few
thousands flexions, a lot faster than a power cable that is wider inn thousands of flexions, a lot faster than a power cable that is wider
diameter, and more resilient. In general, wired networking and in diameter, and more resilient. In general, wired networking and
mobile parts are not a good match, mostly in the case of fast and mobile parts are not a good match, mostly in the case of fast and
recurrent activities, as well as rotation. recurrent activities, as well as rotation.
When refurbishing older premises that were built before the Internet When refurbishing older premises that were built before the Internet
age, power is usually available everywhere, but data is not. It is age, power is usually available everywhere, but data is not. It is
often impractical, time consuming and expensive to deploy an Ethernet often impractical, time consuming and expensive to deploy an Ethernet
fabric across walls and between buildings. Deploying a wire may take fabric across walls and between buildings. Deploying a wire may take
months and cost tens of thousands of US Dollars. months and cost tens of thousands of US Dollars.
Even when wiring exists, e.g., in an existing control network, Even when wiring exists, like in the case of an existing control
asynchronous IP packets such as diagnostics may not be welcome for network, asynchronous IP packets such as diagnostics may not be
operational and security reasons (see Section 4.2.1). An alternate welcome for operational and security reasons. For those packets, the
network that can scale with the many sensors and actuators that equip option to create a parallel wireless network offers a credible
every robot, every valve and fan that are deployed on the factory solution that can scale with the many sensors and actuators that
floor and may help detect and prevent a failure that could impact the equip every robot, every valve and fan that are deployed on the
production. IEEE Std. 802.15.4 Time-Slotted Channel Hopping (TSCH) factory floor. It may also help detect and prevent a failure that
[RFC7554] is a promising technology for that purpose, mostly if the could impact the production, like the degradation (vibration) of a
scheduled operations enable to use the same network by asynchronous cooling fan on the ceiling. IEEE Std. 802.15.4 Time-Slotted Channel
and deterministic flows in parallel. Hopping (TSCH) [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.
4.4. Requirements for RAW 4.4. Requirements for RAW
As stated by the "Deterministic Networking Problem Statement" As stated by the "Deterministic Networking Problem Statement"
[RFC8557], a Deterministic Network is backwards compatible with [RFC8557], a Deterministic Network is backwards compatible with
(capable of transporting) statistically multiplexed traffic while (capable of transporting) statistically multiplexed traffic while
preserving the properties of the accepted deterministic flows. While preserving the properties of the accepted deterministic flows. While
the [RFC9030] serves that requirement, the work at 6TiSCH was focused the 6TiSCH Architecture [RFC9030] serves that requirement, the work
on best-effort IPv6 packet flows. RAW should be able to lock so- at 6TiSCH was focused on best-effort IPv6 packet flows. RAW should
called hard cells for use by a centralized scheduler, and program so- be able to lock so-called hard cells for use by a centralized
called end-to-end Tracks over those cells. scheduler, and leverage time and spatial diversity over a graph of
end-to-end paths called a Track that is based on those cells.
Over the course of the recent years, major Industrial Protocols, Over the course of the recent years, major Industrial Protocols
e.g., [ODVA] with EtherNet/IP [EIP] and [Profinet], have been (e.g., [ODVA] with EtherNet/IP [EIP] and [PROFINET]) have been
migrating towards Ethernet and IP. In order to unleash the full migrating towards Ethernet and IP. In order to unleash the full
power of the IP hourglass model, it should be possible to deploy any power of the IP hourglass model, it should be possible to deploy any
application over any network that has the physical capacity to application over any network that has the physical capacity to
transport the industrial flow, regardless of the MAC/PHY technology, transport the industrial flow, regardless of the MAC/PHY technology,
wired or wireless, and across technologies. RAW mechanisms should be wired or wireless, and across technologies. RAW mechanisms should be
able to setup a Track over a wireless access segment such as TSCH and able to setup a Track over a wireless access segment and a wired or
a backbone segment such as Ethernet or WI-Fi, to report a sensor data wireless backbone to report both sensor data and critical monitoring
or a critical monitoring within a bounded latency. It is also within a bounded latency and maintain the high reliability of teh
important to ensure that RAW solutions are interoperable with flows over time. It is also important to ensure that RAW solutions
existing wireless solutions in place, and with legacy equipment which are interoperable with existing wireless solutions in place, and with
capabilities can be extended using retrofitting. Maintainability, as legacy equipment which capabilities can be extended using
a broader concept than reliability is also important in industrial retrofitting. Maintainability, as a broader concept than reliability
scenarios [square-peg]. is also important in industrial scenarios [MAR19].
4.4.1. Non-latency critical considerations 4.4.1. Non-latency critical considerations
Monitoring and diagnostics applications do not require latency Monitoring and diagnostics applications do not require latency
critical communications, but demand reliable and scalable critical communications, but demand reliable and scalable
communications. On the other hand, process control applications communications. On the other hand, process control applications
involve control loops that require a bounded latency, thus are involve control loops that require a bounded latency, thus are
latency critical, but can be managed end-to-end, and therefore DetNet latency critical, but can be managed end-to-end, and therefore DetNet
mechanisms can be applied in conjunction with RAW mechanisms. mechanisms can be applied in conjunction with RAW mechanisms.
5. Pro Audio and Video 5. Pro Audio and Video
5.1. Use Case Description 5.1. use-case Description
Many devices support audio and video streaming by employing 802.11 Many devices support audio and video streaming by employing 802.11
wireless LAN. Some of these applications require low latency wireless LAN. Some of these applications require low latency
capability. For instance, when the application provides interactive capability. For instance, when the application provides interactive
play, or when the audio takes plays in real time (i.e. live) for play, or when the audio plays in real time - meaning live for public
public addresses in train stations or in theme parks. addresses in train stations or in theme parks.
The professional audio and video industry ("ProAV") includes: The professional audio and video industry ("ProAV") includes:
o Virtual Reality / Augmented Reality (VR/AR) * Virtual Reality / Augmented Reality (VR/AR)
o Public address, media and emergency systems at large venues * Production and post-production systems such as CD and Blue-Ray
(airports, train stations, stadiums, theme parks). disk mastering.
* Public address, media and emergency systems at large venues (e.g.,
airports, train stations, stadiums, and theme parks).
5.2. Specifics 5.2. Specifics
5.2.1. Uninterrupted Stream Playback 5.2.1. Uninterrupted Stream Playback
Considering the uninterrupted audio or video stream, a potential Considering the uninterrupted audio or video stream, a potential
packet losses during the transmission of audio or video flows cannot packet loss during the transmission of audio or video flows cannot be
be tackled by re-trying the transmission, as it is done with file tackled by re-trying the transmission, as it is done with file
transfer, because by the time the packet lost has been identified it transfer, because by the time the packet lost has been identified it
is too late to proceed with packet re-transmission. Buffering might is too late to proceed with packet re-transmission. Buffering might
be employed to provide a certain delay which will allow for one or be employed to provide a certain delay which will allow for one or
more re-transmissions, however such approach is not efficient in more re-transmissions, however such approach is not efficient in
application where delays are not acceptable. application where delays are not acceptable.
5.2.2. Synchronized Stream Playback 5.2.2. Synchronized Stream Playback
In the context of ProAV, latency is the time between the transmitted In the context of ProAV, latency is the time between the transmitted
signal over a stream and its reception. Thus, for sound to remain signal over a stream and its reception. Thus, for sound to remain
synchronized to the movement in the video, the latency of both the synchronized to the movement in the video, the latency of both the
audio and video streams must be bounded and consistent. audio and video streams must be bounded and consistent.
5.3. The Need for Wireless 5.3. The Need for Wireless
The devices need the wireless communication to support video The devices need the wireless communication to support video
streaming via 802.11 wireless LAN for instance. 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.
During the public address, the deployed announcement speakers, for Deployed announcement speakers, for instance along the platforms of
instance along the platforms of the train stations, need the wireless the train stations, need the wireless communication to forward the
communication to forward the audio traffic in real time. audio traffic in real time.
5.4. Requirements for RAW 5.4. Requirements for RAW
The network infrastructure needs to support heterogeneous types of The network infrastructure needs to support heterogeneous types of
traffic (including QoS). traffic (including QoS).
Content delivery with bounded (lowest possible) latency. Content delivery with bounded (lowest possible) latency.
The deployed network topology should allow for multipath. This will The deployed network topology should allow for multipath. This will
enable for multiple streams to have different (and multiple) paths enable for multiple streams to have different (and multiple) paths
(tracks) through the network to support redundancy. (tracks) through the network to support redundancy.
5.4.1. Non-latency critical considerations 5.4.1. Non-latency critical considerations
For synchronized streaming, latency must be bounded, and therefore, For synchronized streaming, latency must be bounded, and therefore,
depending on the actual requirements, this can be considered as depending on the actual requirements, this can be considered as
latency critical. However, the most critical requirement of this use latency critical. However, the most critical requirement of this
case is reliability, by the network providing redundancy. Note that use-case is reliability, by the network providing redundancy. Note
in many cases, wireless is only present in the access, where RAW that in many cases, wireless is only present in the access, where RAW
mechanisms could be applied, but other wired segments are also mechanisms could be applied, but other wired segments are also
involved (e.g., the Internet), and therefore latency cannot be involved (like the Internet), and therefore latency cannot be
guaranteed. guaranteed.
6. Wireless Gaming 6. Wireless Gaming
6.1. Use Case Description 6.1. use-case Description
The gaming industry includes [IEEE80211RTA] real-time mobile gaming, The gaming industry includes [IEEE80211RTA] real-time mobile gaming,
wireless console gaming and cloud gaming. For RAW, wireless console wireless console gaming and cloud gaming. For RAW, wireless console
gaming is the most relevant one. We next summarize the three: gaming is the most relevant one. We next summarize the three:
o Real-time Mobile Gaming: Different from traditional games, real * Real-time Mobile Gaming: Different from traditional games, real
time mobile gaming is very sensitive to network latency and time mobile gaming is very sensitive to network latency and
stability. The mobile game can connect multiple players together stability. The mobile game can connect multiple players together
in a single game session and exchange data messages between game in a single game session and exchange data messages between game
server and connected players. Real-time means the feedback should server and connected players. Real-time means the feedback should
present on screen as users operate in game. For good game present on screen as users operate in game. For good game
experience, the end to end latency plus game servers processing experience, the end-to-end (E2E) latency plus game servers
time should not be noticed by users as they play the game. processing time must be the same for all players and should not be
noticeable as the game is played.
o Wireless Console Gaming: Playing online on a console has 2 types * Wireless Console Gaming: Playing online on a console has 2 types
of internet connectivity, which is either wired or Wi-Fi. Most of of internet connectivity, which is either wired or Wi-Fi. Most of
the gaming consoles today support Wi-Fi 5. But Wi-Fi has an the gaming consoles today support Wi-Fi 5. But Wi-Fi has an
especially bad reputation among the gaming community. The main especially bad reputation among the gaming community. The main
reasons are high latency, lag spikes and jitter. reasons are high latency, lag spikes, and jitter.
o Cloud Gaming: The cloud gaming requires low latency capability as * Cloud Gaming: The cloud gaming requires low latency capability as
the user commands in a game session need to be sent back to the the user commands in a game session need to be sent back to the
cloud server, the cloud server would update game context depending cloud server, the cloud server would update game context depending
on the received commands, and the cloud server would render the on the received commands, and the cloud server would render the
picture/video to be displayed at user devices and stream the picture/video to be displayed at user devices and stream the
picture/video content to the user devices. User devices might picture/video content to the user devices. User devices might
very likely be connected wirelessly. very likely be connected wirelessly.
6.2. Specifics 6.2. Specifics
While a lot of details can be found on [IEEE80211RTA], we next While a lot of details can be found on [IEEE80211RTA], we next
summarize the main requirements in terms of latency, jitter and summarize the main requirements in terms of latency, jitter and
packet loss: packet loss:
o Intra BSS latency: less than 5 ms. * Intra BSS latency is less than 5 ms.
o Jitter variance: less than 2 ms. * Jitter variance is less than 2 ms.
o Packet loss: less than 0.1 percent. * Packet loss is less than 0.1 percent.
6.3. The Need for Wireless 6.3. The Need for Wireless
It is clear that gaming is evolving towards wireless, as players Gaming is evolving towards wireless, as players demand being able to
demand being able to play anywhere. Besides, the industry is play anywhere, and the game requires a more immersive experience
changing towards playing from mobile phones, which are inherently including body movements. Besides, the industry is changing towards
connected via wireless technologies. playing from mobile phones, which are inherently connected via
wireless technologies. Wireless controllers are the rule in modern
gaming, with increasingly sophisticated interactions (e.g., haptic
feedback, augmented reality).
6.4. Requirements for RAW 6.4. Requirements for RAW
o Time sensitive networking extensions. Extensions, such as time- * Time sensitive networking extensions: extensions, such as time-
aware shaping and redundancy (FRE) can be explored to address aware shaping and redundancy (FRE) can be explored to address
congestion and reliability problems present in wireless networks. congestion and reliability problems present in wireless networks.
o Priority tagging (Stream identification). One basic requirement * Priority tagging (Stream identification): one basic requirement to
to provide better QoS for time-sensitive traffic is the capability provide better QoS for time-sensitive traffic is the capability to
to identify and differentiate time-sensitive packets from other identify and differentiate time-sensitive packets from other (like
(e.g. best-effort) traffic. best-effort) traffic.
o Time-aware shaping. This capability (defined in IEEE 802.1Qbv) * Time-aware shaping: this capability (defined in IEEE 802.1Qbv)
consists of gates to control the opening/closing of queues that consists of gates to control the opening/closing of queues that
share a common egress port within an Ethernet switch. A scheduler share a common egress port within an Ethernet switch. A scheduler
defines the times when each queue opens or close, therefore defines the times when each queue opens or close, therefore
eliminating congestion and ensuring that frames are delivered eliminating congestion and ensuring that frames are delivered
within the expected latency bounds. within the expected latency bounds. Note thought, that while this
requirement needs to be signalled by RAW mechanisms, it would be
actually served by the lower layer.
o Dual/multiple link. Due to the competitions and interference are * Dual/multiple link: due to the competitions and interference are
common and hardly in control under wireless network, in order to common and hardly in control under wireless network, to improve
improve the latency stability, dual/multiple link proposal is the latency stability, dual/multiple link proposal is brought up
brought up to address this issue. Two modes are defined: to address this issue.
duplicate and joint.
o Admission Control. Congestion is a major cause of high/variable * Admission Control: congestion is a major cause of high/variable
latency and it is well known that if the traffic load exceeds the latency and it is well known that if the traffic load exceeds the
capability of the link, QoS will be degraded. QoS degradation capability of the link, QoS will be degraded. QoS degradation
maybe acceptable for many applications today, however emerging maybe acceptable for many applications today, however emerging
time-sensitive applications are highly susceptible to increased time-sensitive applications are highly susceptible to increased
latency and jitter. In order to better control QoS, it is latency and jitter. To better control QoS, it is important to
important to control access to the network resources. control access to the network resources.
6.4.1. Non-latency critical considerations 6.4.1. Non-latency critical considerations
Depending on the actual scenario, and on use of Internet to Depending on the actual scenario, and on use of Internet to
interconnect different users, the communication's requirements of interconnect different users, the communication's requirements of
this use case might be considered as latency critical due to the need 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 bounded latency. But note that in most of these scenarios, part
of the communication path is not wireless and DetNet mechanisms of the communication path is not wireless and DetNet mechanisms
cannot be applied easily (e.g., when the public Internet is cannot be applied easily (e.g., when the public Internet is
involved), and therefore in these cases, reliability is the critical involved), and therefore in these cases, reliability is the critical
requirement. requirement.
7. UAV and V2V platooning and control 7. Unmanned Aerial Vehicles and Vehicle-to-Vehicle platooning and
control
7.1. Use Case Description 7.1. use-case Description
Unmanned Aerial Vehicles (UAVs) are becoming very popular for many Unmanned Aerial Vehicles (UAVs) are becoming very popular for many
different applications, including military and civil use cases. The different applications, including military and civil use-cases. The
term drone is commonly used to refer to a UAV. term drone is commonly used to refer to a UAV.
UAVs can be used to perform aerial surveillance activities, traffic UAVs can be used to perform aerial surveillance activities, traffic
monitoring (e.g., Spanish traffic control has recently introduced a monitoring (i.e., the Spanish traffic control has recently introduced
fleet of drones for quicker reactions upon traffic congestion related a fleet of drones for quicker reactions upon traffic congestion
events), support of emergency situations, and even transportation of related events), support of emergency situations, and even
small goods. transportation of small goods (e.g., medicine in rural areas).
Similarly to UAVs/drones, other time of vehicles (such as cars) can Similarly to UAVs, other time of vehicles (such as cars) can also
also travel in platoons. Most of the considerations made for UAVs in travel in platoons. Most of the considerations made for UAVs in this
this section apply to V2V scenarios. section apply to vehicle-to-vehicle (V2V) scenarios.
UAVs/vehicles typically have various forms of wireless connectivity: UAVs/vehicles typically have various forms of wireless connectivity:
o cellular: for communication with the control center, for remote * Cellular: for communication with the control center, for remote
maneuvering as well as monitoring of the drone; maneuvering as well as monitoring of the drone;
o IEEE 802.11: for inter-drone communications (e.g., platooning) and * IEEE 802.11: for inter-drone communications (i.e., platooning) and
providing connectivity to other devices (e.g., acting as Access providing connectivity to other devices (i.e., acting as Access
Point). Point).
Note that autonomous cars share many of the characteristics of the
aforemention UAV case, and therefore it is of interest for RAW.
7.2. Specifics 7.2. Specifics
Some of the use cases/tasks involving drones require coordination Some of the use-cases/tasks involving UAVs require coordination among
among drones. Others involve complex compute tasks that might not be UAVs. Others involve complex compute tasks that might not be
performed using the limited computing resources that a drone performed using the limited computing resources that a drone
typically has. These two aspects require continuous connectivity typically has. These two aspects require continuous connectivity
with the control center and among drones. with the control center and among UAVs.
Remote maneuvering of a drone might be performed over a cellular Remote maneuvering of a drone might be performed over a cellular
network in some cased, however, there are situations that need very network in some cases, however, there are situations that need very
low latency and deterministic behavior of the connectivity. Examples low latency and deterministic behavior of the connectivity. Examples
involve platooning of drones or share of computing resources among involve platooning of drones or share of computing resources among
drones (e.g., a drone offload some function to a neighboring drone). drones (like, a drone offload some function to a neighboring drone).
7.3. The Need for Wireless 7.3. The Need for Wireless
UAVs cannot be connected through any type of wired media, so it is UAVs cannot be connected through any type of wired media, so it is
obvious that wireless is needed. obvious that wireless is needed.
7.4. Requirements for RAW 7.4. Requirements for RAW
The network infrastructure is actually composed by the UAVs The network infrastructure is composed by the UAVs themselves,
themselves, requiring self-configuration capabilities. requiring self-configuration capabilities.
Heterogeneous types of traffic need to be supported, from extremely Heterogeneous types of traffic need to be supported, from extremely
critical ones requiring ultra low latency and high resiliency, to critical ones requiring ultra-low latency and high resiliency, to
traffic requiring low-medium latency. traffic requiring low-medium latency.
When a given service is decomposed into functions -- hosted at When a given service is decomposed into functions -- hosted at
different drones -- chained, each link connecting two given functions different UAVs -- chained, each link connecting two given functions
would have a well-defined set of requirements (latency, bandwidth and would have a well-defined set of requirements (e.g., latency,
jitter) that have to be met. bandwidth and jitter) that must be met.
7.4.1. Non-latency critical considerations 7.4.1. Non-latency critical considerations
Today's solutions keep local the processing operations that are Today's solutions keep local the processing operations that are
critical and would demand an ultra low latency communication to be critical and would demand an ultra-low latency communication to be
offloaded. Therefore, in this use case, the critical requirement is offloaded. Therefore, in this use-case, the critical requirement is
reliability, and only for some platooning and inter-drone reliability, and only for some platooning and inter-drone
communications latency is critical. communications latency is critical.
8. Edge Robotics control 8. Edge Robotics control
8.1. Use Case Description 8.1. use-case Description
The Edge Robotics scenario consists of several robots, deployed in a The Edge Robotics scenario consists of several robots, deployed in a
given area (for example a shopping mall), inter-connected via an given area (like a shopping mall), inter-connected via an access
access network to a network's edge device or a data center. The network to a network's edge device or a data center. The robots are
robots are connected to the edge so complex computational activities connected to the edge so complex computational activities are not
are not executed locally at the robots, but offloaded to the edge. executed locally at the robots but offloaded to the edge. This
This brings additional flexibility in the type of tasks that the brings additional flexibility in the type of tasks that the robots
robots do, as well as reducing the costs of robot manufacturing (due do, as well as reducing the costs of robot manufacturing (due to
to their lower complexity), and enabling complex tasks involving their lower complexity), and enabling complex tasks involving
coordination among robots (that can be more easily performed if coordination among robots (that can be more easily performed if
robots are centrally controlled). robots are centrally controlled).
A simple example of the use of multiples robots is cleaning, Simple examples of the use of multiples robots are cleaning, video
delivering of goods from warehouses to shops or video surveillance. surveillance, search and rescue operations, and delivering of goods
Multiple robots are simultaneously instructed to perform individual from warehouses to shops. Multiple robots are simultaneously
tasks by moving the robotic intelligence from the robots to the instructed to perform individual tasks by moving the robotic
network's edge (e.g., data center). That enables easy intelligence from the robots to the network's edge (like a data
synchronization, scalable solution and on-demand option to create center). That enables easy synchronization, scalable solution, and
flexible fleet of robots. on-demand option to create flexible fleet of robots.
Robots would have various forms of wireless connectivity: Robots would have various forms of wireless connectivity:
o IEEE 802.11: for connection to the edge and also inter-robot * IEEE 802.11: for connection to the edge and also inter-robot
communications (e.g., for coordinated actions). communications (i.e., for coordinated actions).
o Cellular: as an additional communication link to the edge, though * Cellular: as an additional communication link to the edge, though
primarily as backup, since ultra low latency is needed. primarily as backup, since ultra-low latency is needed.
8.2. Specifics 8.2. Specifics
Some of the use cases/tasks involving robots might benefit from Some of the use-cases/tasks involving robots might benefit from
decomposition of a service in small functions that are distributed decomposition of a service in small functions that are distributed
and chained among robots and the edge. These require continuous and chained among robots and the edge. These require continuous
connectivity with the control center and among drones. connectivity with the control center and among drones.
Robot control is an activity requiring very low latency between the Robot control is an activity requiring very low latency between the
robot and the location where the control intelligence resides (which robot and the location where the control intelligence resides (which
might be the edge or another robot). might be the edge or another robot).
8.3. The Need for Wireless 8.3. The Need for Wireless
Deploying robots in scenarios such as shopping malls for the Deploying robots in scenarios such as shopping malls for the
aforementioned applications cannot be done via wired connectivity. applications mentioned cannot be done via wired connectivity.
8.4. Requirements for RAW 8.4. Requirements for RAW
The network infrastructure needs to support heterogeneous types of The network infrastructure needs to support heterogeneous types of
traffic, from robot control to video streaming. traffic, from robot control to video streaming.
When a given service is decomposed into functions -- hosted at When a given service is decomposed into functions -- hosted at
different robots -- chained, each link connecting two given functions different robots -- chained, each link connecting two given functions
would have a well-defined set of requirements (latency, bandwidth and would have a well-defined set of requirements (latency, bandwidth and
jitter) that have to be met. jitter) that must be met.
8.4.1. Non-latency critical considerations 8.4.1. Non-latency critical considerations
This use case might combine multiple communication flows, with some This use-case might combine multiple communication flows, with some
of them being latency critical (e.g., those related to robot control of them being latency critical (like those related to robot control
tasks). Note that there are still many communication flows (e.g., tasks). Note that there are still many communication flows (like
some offloading tasks) that only demand reliability and availability. some offloading tasks) that only demand reliability and availability.
9. Emergencies: Instrumented emergency vehicle 9. Emergencies: Instrumented emergency vehicle
9.1. Use Case Description 9.1. use-case Description
An instrumented ambulance would be one that has a LAN to which are An instrumented ambulance would be one that has a LAN to which are
connected these end systems: connected these end systems such as:
o vital signs sensors attached to the casualty in the ambulance. * vital signs sensors attached to the casualty in the ambulance.
Relay medical data to hospital emergency room, Relay medical data to hospital emergency room,
o radio-navigation sensor to relay position data to various * radio-navigation sensor to relay position data to various
destinations including dispatcher, destinations including dispatcher,
o voice communication for ambulance attendant (e.g. consult with ER * voice communication for ambulance attendant (like to consult with
doctor), ER doctor), and
o voice communication between driver and dispatcher,
o etc. * voice communication between driver and dispatcher.
The LAN needs to be routed through radio-WANs to complete the inter- The LAN needs to be routed through radio-WANs to complete the inter-
network linkage. network linkage.
9.2. Specifics 9.2. Specifics
What we have today is multiple communications systems to reach the What we have today is multiple communications systems to reach the
vehicle: vehicle via:
o A dispatching system, * A dispatching system,
o a cellphone for the attendant, * a cellphone for the attendant,
o a special purpose telemetering system for medical data, * a special purpose telemetering system for medical data,
o etc. * etc.
This redundancy of systems, because of its stove-piping, does not This redundancy of systems, because of its stove-piping, does not
contribute to availability as a whole. contribute to availability.
Most of the scenarios involving the use of an instrumented ambulance Most of the scenarios involving the use of an instrumented ambulance
are composed of many different flows, each of them with slightly are composed of many different flows, each of them with slightly
different requirements in terms of reliability and latency. different requirements in terms of reliability and latency.
Destinations might be either at the ambulance itself (local traffic), Destinations might be either at the ambulance itself (local traffic),
at a near edge cloud or at the general Internet/cloud. at a near edge cloud or at the general Internet/cloud.
9.3. The Need for Wireless 9.3. The Need for Wireless
Local traffic between the first responders/ambulance staff and the Local traffic between the first responders/ambulance staff and the
ambulance equipment cannot be done via wired connectivity as the ambulance equipment cannot be done via wired connectivity as the
responders perform initial treatment outside of the ambulance. The responders perform initial treatment outside of the ambulance. The
communications from the ambulance to external services has to be communications from the ambulance to external services must be
wireless as well. wireless as well.
9.4. Requirements for RAW 9.4. Requirements for RAW
We can derive some pertinent requirements from this scenario: We can derive some pertinent requirements from this scenario:
o High availability of the inter-network is required. * High availability of the inter-network is required.
o The inter-network needs to operate in damaged state (e.g. during * The inter-network needs to operate in damaged state (e.g. during
an earthquake aftermath, heavy weather, wildfire, etc.). In an earthquake aftermath, heavy weather, wildfire, etc.). In
addition to continuity of operations, rapid restore is a needed addition to continuity of operations, rapid restore is a needed
characteristic. characteristic.
o End-to-end security, both authenticity and confidentiality, is * E2E security, both authenticity and confidentiality, is required
required of traffic. All data needs to be authenticated; some of traffic. All data needs to be authenticated; some like medical
(such as medical) needs to be confidential. needs to be confidential.
o The radio-WAN has characteristics similar to cellphone -- the * The radio-WAN has characteristics similar to cellphone -- the
vehicle will travel from one radio footprint to another. vehicle will travel from one radio footprint to another.
9.4.1. Non-latency critical considerations 9.4.1. Non-latency critical considerations
In this case, all applications identified do not require latency In this case, all applications identified do not require latency
critical communication, but do need of high reliability and critical communication, but do need of high reliability and
availability. availability.
10. Summary 10. Summary
This document enumerates several use cases and applications that need This document enumerates several use-cases and applications that need
RAW technologies, focusing on the requirements from reliability, RAW technologies, focusing on the requirements from reliability,
availability and latency. Whereas some use cases are latency- availability and latency. Whereas some use-cases are latency-
critical, there are also a number of applications that are non- critical, there are also several applications that are non-latency
latency critical, but that do pose strict reliability and critical, but that do pose strict reliability and availability
availability requirements. Future revisions of this document will requirements. Future revisions of this document will include
include specific text devoted to highlight this non-latency critical specific text devoted to highlight this non-latency critical
requirements. requirements.
11. IANA Considerations 11. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
12. Security Considerations 12. Security Considerations
This document covers a number of representative applications and This document covers several representative applications and network
network scenarios that are expected to make use of RAW technologies. scenarios that are expected to make use of RAW technologies. Each of
Each of the potential RAW use cases will have security considerations the potential RAW use-cases will have security considerations from
from both the use-specific perspective and the RAW technology both the use-specific perspective and the RAW technology perspective.
perspective. [RFC9055] provides a comprehensive discussion of [RFC9055] provides a comprehensive discussion of security
security considerations in the context of Deterministic Networking, considerations in the context of Deterministic Networking, which are
which are generally applicable also to RAW. generally applicable also to RAW.
13. Acknowledgments 13. Acknowledgments
Nils Maeurer, Thomas Graeupl and Corinna Schmitt have contributed Nils Maeurer, Thomas Graeupl and Corinna Schmitt have contributed
significantly to this document, providing input for the Aeronautical significantly to this document, providing input for the Aeronautical
communications section. Rex Buddenberg has also contributed to the communications section. Rex Buddenberg has also contributed to the
document, providing input to the Emergency: instrumented emergency document, providing input to the Emergency: instrumented emergency
vehicle section. vehicle section.
The authors would like to thank Toerless Eckert, Xavi Vilajosana The authors would like to thank Toerless Eckert, Xavi Vilajosana
Guillen and Rute Sofia for their valuable comments on previous Guillen, Rute Sofia and Corinna Schmitt for their valuable comments
versions of this document. on previous versions of this document.
The work of Carlos J. Bernardos in this draft has been partially The work of Carlos J. Bernardos in this draft has been partially
supported by the H2020 5Growth (Grant 856709) and 5G-DIVE projects supported by the H2020 5Growth (Grant 856709) and 5G-DIVE projects
(Grant 859881). (Grant 859881), and UNICO 5G I+D 6G-DATADRIVEN-04 project.
14. Informative References 14. References
14.1. Normative References
[I-D.ietf-raw-technologies]
Thubert, P., Cavalcanti, D., Vilajosana, X., Schmitt, C.,
and J. Farkas, "Reliable and Available Wireless
Technologies", Work in Progress, Internet-Draft, draft-
ietf-raw-technologies-05, 2 February 2022,
<https://www.ietf.org/archive/id/draft-ietf-raw-
technologies-05.txt>.
14.2. Informative References
[ACI19] Airports Council International (ACI), "Annual World [ACI19] Airports Council International (ACI), "Annual World
Aitport Traffic Report 2019", November 2019, Aitport Traffic Report 2019", November 2019,
<https://store.aci.aero/product/annual-world-airport- <https://store.aci.aero/product/annual-world-airport-
traffic-report-2019/>. traffic-report-2019/>.
[disney-VIP] [DISNEY15] Wired, "Disney's $1 Billion Bet on a Magical Wristband",
Wired, "Disney's $1 Billion Bet on a Magical Wristband",
March 2015, March 2015,
<https://www.wired.com/2015/03/disney-magicband/>. <https://www.wired.com/2015/03/disney-magicband/>.
[EIP] http://www.odva.org/, "EtherNet/IP provides users with the [EIP] http://www.odva.org/, "EtherNet/IP provides users with the
network tools to deploy standard Ethernet technology (IEEE network tools to deploy standard Ethernet technology (IEEE
802.3 combined with the TCP/IP Suite) for industrial 802.3 combined with the TCP/IP Suite) for industrial
automation applications while enabling Internet and automation applications while enabling Internet and
enterprise connectivity data anytime, anywhere.", enterprise connectivity data anytime, anywhere.",
<http://www.odva.org/Portals/0/Library/ <http://www.odva.org/Portals/0/Library/
Publications_Numbered/ Publications_Numbered/
PUB00138R3_CIP_Adv_Tech_Series_EtherNetIP.pdf>. PUB00138R3_CIP_Adv_Tech_Series_EtherNetIP.pdf>.
[FAA20] U.S. Department of Transportation Federal Aviation [FAA20] U.S. Department of Transportation Federal Aviation
Administration (FAA), "Next Generation Air Transportation Administration (FAA), "Next Generation Air Transportation
System", 2019, <https://www.faa.gov/nextgen/ >. System", 2019, <https://www.faa.gov/nextgen/>.
[I-D.ietf-raw-ldacs]
Maeurer, N., Graeupl, T., and C. Schmitt, "L-band Digital
Aeronautical Communications System (LDACS)", draft-ietf-
raw-ldacs-08 (work in progress), May 2021.
[I-D.sofia-raw-industrialreq] [I-D.ietf-raw-industrial-requirements]
Sofia, R. C., Kovatsch, M., and P. M. Mendes, Sofia, R. C., Kovatsch, M., and P. M. Mendes,
"Requirements for Reliable Wireless Industrial Services", "Requirements for Reliable Wireless Industrial Services",
draft-sofia-raw-industrialreq-00 (work in progress), March Work in Progress, Internet-Draft, draft-ietf-raw-
2021. industrial-requirements-00, 10 December 2021,
<https://www.ietf.org/archive/id/draft-ietf-raw-
industrial-requirements-00.txt>.
[I-D.thubert-raw-technologies] [I-D.ietf-raw-ldacs]
Thubert, P., Cavalcanti, D., Vilajosana, X., Schmitt, C., Maeurer, N., Graeupl, T., and C. Schmitt, "L-band Digital
and J. Farkas, "Reliable and Available Wireless Aeronautical Communications System (LDACS)", Work in
Technologies", draft-thubert-raw-technologies-05 (work in Progress, Internet-Draft, draft-ietf-raw-ldacs-09, 22
progress), May 2020. October 2021, <https://www.ietf.org/archive/id/draft-ietf-
raw-ldacs-09.txt>.
[IAC20] Iacus, S., Natale, F., Santamaria, C., Spyratos, S., and [IAC20] Iacus, S.M., Natale, F., Santamaria, C., Spyratos, S., and
V. Michele, "Estimating and projecting air passenger V. Michele, "Estimating and projecting air passenger
traffic during the COVID-19 coronavirus outbreak and its traffic during the COVID-19 coronavirus outbreak and its
socio- economic impact", Safety Science 129 (2020) socio- economic impact", Safety Science 129 (2020)
104791 , 2020. 104791 , 2020.
[IAT20] International Air Transport Association (IATA), "Economic [IAT20] International Air Transport Association (IATA), "Economic
Performance of the Airline Industry", November 2020, Performance of the Airline Industry", November 2020,
<https://www.iata.org/en/iata-repository/publications/ <https://www.iata.org/en/iata-repository/publications/
economic-reports/airline-industry-economic-performance--- economic-reports/airline-industry-economic-performance---
november-2020---report/>. november-2020---report/>.
skipping to change at page 23, line 11 skipping to change at page 24, line 39
International Standards and Recommended Practices Annex 10 International Standards and Recommended Practices Annex 10
- Aeronautical Telecommunications, Vol. III - - Aeronautical Telecommunications, Vol. III -
Communication Systems , 2018. Communication Systems , 2018.
[IEEE802.1TSN] [IEEE802.1TSN]
IEEE standard for Information Technology, "IEEE IEEE standard for Information Technology, "IEEE
802.1AS-2011 - IEEE Standard for Local and Metropolitan 802.1AS-2011 - IEEE Standard for Local and Metropolitan
Area Networks - Timing and Synchronization for Time- Area Networks - Timing and Synchronization for Time-
Sensitive Applications in Bridged Local Area Networks". Sensitive Applications in Bridged Local Area Networks".
[ieee80211-rt-tig] [IEEE80211-RT-TIG]
IEEE, "IEEE 802.11 Real Time Applications TIG Report", IEEE, "IEEE 802.11 Real Time Applications TIG Report",
Nov. 2018, November 2018,
<http://www.ieee802.org/11/Reports/rtatig_update.htm>. <http://www.ieee802.org/11/Reports/rtatig_update.htm>.
[IEEE80211BE]
Cavalcanti, D. and G. Venkatesan, "802.1 TSN over 802.11
with updates from developments in 802.11be", IEEE plenary
meeting , November 2020,
<https://www.ieee802.org/1/files/public/docs2020/new-
Cavalcanti-802-1TSN-over-802-11-1120-v02.pdf>.
[IEEE80211RTA] [IEEE80211RTA]
IEEE standard for Information Technology, "IEEE 802.11 IEEE standard for Information Technology, "IEEE 802.11
Real Time Applications TIG Report", Nov 2018. Real Time Applications TIG Report", November 2018.
[ISA100] ISA/ANSI, "ISA100, Wireless Systems for Automation", [ISA100] ISA/ANSI, "ISA100, Wireless Systems for Automation",
<https://www.isa.org/isa100/>. <https://www.isa.org/isa100/>.
[KEAV20] T. Keaveney and C. Stewart, "Single European Sky ATM [KEAV20] T. Keaveney and C. Stewart, "Single European Sky ATM
Research Joint Undertaking", 2019, Research Joint Undertaking", 2019,
<https://www.sesarju.eu/>. <https://www.sesarju.eu/>.
[KOB12] Kober, J., Glisson, M., and M. Mistry, "Playing catch and
juggling with a humanoid robot.", 2012,
<https://doi.org/10.1109/HUMANOIDS.2012.6651623>.
[MAR19] Martinez, B., Cano, C., and X. Vilajosana, "A Square Peg
in a Round Hole: The Complex Path for Wireless in the
Manufacturing Industry", 2019,
<https://ieeexplore.ieee.org/document/8703476>.
[ODVA] http://www.odva.org/, "The organization that supports [ODVA] http://www.odva.org/, "The organization that supports
network technologies built on the Common Industrial network technologies built on the Common Industrial
Protocol (CIP) including EtherNet/IP.". Protocol (CIP) including EtherNet/IP.".
[PLA14] Plass, S., Hermenier, R., Luecke, O., Gomez Depoorter, D., [PLA14] Plass, S., Hermenier, R., Luecke, O., Gomez Depoorter, D.,
Tordjman, T., Chatterton, M., Amirfeiz, M., Scotti, S., Tordjman, T., Chatterton, M., Amirfeiz, M., Scotti, S.,
Cheng, Y., Pillai, P., Graeupl, T., Durand, F., Murphy, Cheng, Y.J., Pillai, P., Graeupl, T., Durand, F., Murphy,
K., Marriott, A., and A. Zaytsev, "Flight Trial K., Marriott, A., and A. Zaytsev, "Flight Trial
Demonstration of Seamless Aeronautical Networking", IEEE Demonstration of Seamless Aeronautical Networking", IEEE
Communications Magazine, vol. 52, no. 5 , May 2014. Communications Magazine, vol. 52, no. 5 , May 2014.
[Profinet] [PROFINET] http://us.profinet.com/technology/profinet/, "PROFINET is
http://us.profinet.com/technology/profinet/, "PROFINET is
a standard for industrial networking in automation.", a standard for industrial networking in automation.",
<http://us.profinet.com/technology/profinet/>. <http://us.profinet.com/technology/profinet/>.
[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
Internet of Things (IoT): Problem Statement", RFC 7554, Internet of Things (IoT): Problem Statement", RFC 7554,
DOI 10.17487/RFC7554, May 2015, DOI 10.17487/RFC7554, May 2015,
<https://www.rfc-editor.org/info/rfc7554>. <https://www.rfc-editor.org/info/rfc7554>.
[RFC8557] Finn, N. and P. Thubert, "Deterministic Networking Problem [RFC8557] Finn, N. and P. Thubert, "Deterministic Networking Problem
skipping to change at page 24, line 24 skipping to change at page 26, line 20
[RFC9030] Thubert, P., Ed., "An Architecture for IPv6 over the Time- [RFC9030] Thubert, P., Ed., "An Architecture for IPv6 over the Time-
Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)",
RFC 9030, DOI 10.17487/RFC9030, May 2021, RFC 9030, DOI 10.17487/RFC9030, May 2021,
<https://www.rfc-editor.org/info/rfc9030>. <https://www.rfc-editor.org/info/rfc9030>.
[RFC9055] Grossman, E., Ed., Mizrahi, T., and A. Hacker, [RFC9055] Grossman, E., Ed., Mizrahi, T., and A. Hacker,
"Deterministic Networking (DetNet) Security "Deterministic Networking (DetNet) Security
Considerations", RFC 9055, DOI 10.17487/RFC9055, June Considerations", RFC 9055, DOI 10.17487/RFC9055, June
2021, <https://www.rfc-editor.org/info/rfc9055>. 2021, <https://www.rfc-editor.org/info/rfc9055>.
[robots] Kober, J., Glisson, M., and M. Mistry, "Playing catch and Authors' Addresses
juggling with a humanoid robot.", 2012,
<https://doi.org/10.1109/HUMANOIDS.2012.6651623>.
[square-peg] Carlos J. Bernardos (editor)
Martinez, B., Cano, C., and X. Vilajosana, "A Square Peg Universidad Carlos III de Madrid
in a Round Hole: The Complex Path for Wireless in the Av. Universidad, 30
Manufacturing Industry", 2019, 28911 Leganes, Madrid
<https://ieeexplore.ieee.org/document/8703476>. Spain
Authors' Addresses Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Georgios Z. Papadopoulos Georgios Z. Papadopoulos
IMT Atlantique IMT Atlantique
Office B00 - 114A Office B00 - 114A
2 Rue de la Chataigneraie 2 Rue de la Chataigneraie
Cesson-Sevigne - Rennes 35510 35510 Cesson-Sevigne - Rennes
FRANCE France
Phone: +33 299 12 70 04 Phone: +33 299 12 70 04
Email: georgios.papadopoulos@imt-atlantique.fr Email: georgios.papadopoulos@imt-atlantique.fr
Pascal Thubert Pascal Thubert
Cisco Systems, Inc Cisco Systems, Inc
Building D Building D
45 Allee des Ormes - BP1200 45 Allee des Ormes - BP1200
MOUGINS - Sophia Antipolis 06254 06254 MOUGINS - Sophia Antipolis
FRANCE France
Phone: +33 497 23 26 34 Phone: +33 497 23 26 34
Email: pthubert@cisco.com Email: pthubert@cisco.com
Fabrice Theoleyre Fabrice Theoleyre
CNRS CNRS
ICube Lab, Pole API ICube Lab, Pole API
300 boulevard Sebastien Brant - CS 10413 300 boulevard Sebastien Brant - CS 10413
Illkirch 67400 67400 Illkirch
FRANCE France
Phone: +33 368 85 45 33 Phone: +33 368 85 45 33
Email: theoleyre@unistra.fr Email: theoleyre@unistra.fr
URI: http://www.theoleyre.eu URI: http://www.theoleyre.eu
Carlos J. Bernardos (editor)
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
 End of changes. 170 change blocks. 
406 lines changed or deleted 467 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/