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