RFC 9450 RAW Use Cases August 2023
Bernardos, et al. Informational [Page]
Stream:
Internet Engineering Task Force (IETF)
RFC:
9450
Category:
Informational
Published:
ISSN:
2070-1721
Authors:
CJ. Bernardos, Ed.
UC3M
G. Papadopoulos
IMT Atlantique
P. Thubert
Cisco
F. Theoleyre
CNRS

RFC 9450

Reliable and Available Wireless (RAW) Use Cases

Abstract

The wireless medium presents significant specific challenges to achieve properties similar to those of wired deterministic networks. At the same time, a number of use cases cannot be solved with wires and justify the extra effort of going wireless. This document presents wireless use cases (such as aeronautical communications, amusement parks, industrial applications, pro audio and video, gaming, Unmanned Aerial Vehicle (UAV) and vehicle-to-vehicle (V2V) control, edge robotics, and emergency vehicles), demanding reliable and available behavior.

Status of This Memo

This document is not an Internet Standards Track specification; it is published for informational purposes.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the 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.

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.

Table of Contents

1. Introduction

Based on time, resource reservation, and policy enforcement by distributed shapers [RFC2475], Deterministic Networking (DetNet) provides the capability to carry specified unicast or multicast data streams for real-time applications with extremely low data loss rates and bounded latency so as to support time-sensitive and mission-critical applications on a converged enterprise infrastructure.

DetNet aims at eliminating packet loss for a committed bandwidth, while ensuring a worst-case end-to-end latency, regardless of the network conditions and across technologies. By leveraging lower layer (Layer 2 (L2) and below) capabilities, Layer 3 (L3) can exploit the use of a service layer, steering over multiple technologies and using media independent signaling to provide high reliability, precise time delivery, and rate enforcement. DetNet can be seen as a set of new Quality of Service (QoS) guarantees of worst-case delivery. IP networks become more deterministic when the effects of statistical multiplexing (jitter and collision loss) are mostly eliminated. This requires a tight control of the physical resources to maintain the amount of traffic within the physical capabilities of the underlying technology, e.g., by using time-shared resources (bandwidth and buffers) per circuit, by shaping or scheduling the packets at every hop, or by using a combination of these techniques.

Key attributes of DetNet include:

Wireless operates on a shared medium, and transmissions cannot be guaranteed to be fully deterministic due to uncontrolled interferences, including self-induced multipath fading. The term RAW stands for "Reliable and Available Wireless" and refers to the mechanisms aimed for providing high reliability and availability for IP connectivity over a wireless medium. Making wireless reliable and available is even more challenging than it is with wires, due to the numerous causes of loss in transmission that add up to the congestion losses and due to the delays caused by overbooked shared resources.

The wireless and wired media are fundamentally different at the physical level. While the generic Problem Statement in [RFC8557] for DetNet applies to the wired as well as the wireless medium, the methods to achieve RAW necessarily differ from those used to support Time-Sensitive Networking over wires, e.g., due to the wireless radio channel specifics.

So far, open standards for DetNet have prevalently been focused on wired media, with Audio Video Bridging (AVB) and Time-Sensitive Networking (TSN) at the IEEE and DetNet [RFC8655] at the IETF. However, wires cannot be used in several cases, including mobile or rotating devices, rehabilitated industrial buildings, wearable or in-body sensory devices, vehicle automation, and multiplayer gaming.

Purpose-built wireless technologies such as [ISA100], which incorporates IPv6, were developed and deployed to cope with the lack of open standards, but they yield a high cost in Operational Expenditure (OPEX) and Capital Expenditure (CAPEX) and are limited to very few industries, e.g., process control, concert instruments, or racing.

This is now changing (as detailed in [RAW-TECHNOS]):

Experiments have already been conducted with IEEE802.1 TSN over IEEE802.11be [IEEE80211BE]. This mode enables time synchronization and time-aware scheduling (trigger based access mode) to support TSN flows.

This document extends the "Deterministic Networking Use Cases" document [RFC8578] and describes several additional use cases that require "reliable/predictable and available" flows over wireless links and possibly complex multi-hop paths called "Tracks". This is covered mainly by the "Wireless for Industrial Applications" (Section 5 of [RFC8578]) use case, as the "Cellular Radio" (Section 6 of [RFC8578]) is mostly dedicated to the (wired) link part of a Radio Access Network (RAN). Whereas, while the "Wireless for Industrial Applications" use case certainly covers an area of interest for RAW, it is limited to IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH), and thus, its scope is narrower than the use cases described next in this document.

2. Aeronautical Communications

Aircraft are currently connected to Air-Traffic Control (ATC) and Airline Operational Control (AOC) via voice and data communication systems through all phases of a flight. Within the airport terminal, connectivity is focused on high-bandwidth communications, whereas en route it's focused on high reliability, robustness, and range.

2.1. Problem Statement

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 of the COVID-19 pandemic, air-traffic growth is expected to resume very quickly in post-pandemic times [IAT20] [IAC20]. Thus, legacy systems in Air-Traffic Management (ATM) are likely to reach their capacity limits, and the need for new aeronautical communication technologies becomes apparent. Especially problematic is the saturation of VHF band in high density areas in Europe, the US, and Asia [SESAR] [FAA20], calling for suitable new digital approaches such as the Aeronautical Mobile Airport Communications System (AeroMACS) for airport communications, SatCOM for remote domains, and the L-band Digital Aeronautical Communication System (LDACS) as the long-range terrestrial aeronautical communication system. Making the frequency spectrum's usage a more efficient transition from analog voice to digital data communication [PLA14] is necessary to cope with the expected growth of civil aviation and its supporting infrastructure. A promising candidate for long-range terrestrial communications, already in the process of being standardized in the International Civil Aviation Organization (ICAO), is LDACS [ICAO2022] [RFC9372].

Note that the large scale of the planned Low Earth Orbit (LEO) constellations of satellites can provide fast end-to-end latency rates and high data-rates at a reasonable cost, but they also pose challenges, such as frequent handovers, high interference, and a diverse range of system users, which can create security issues since both safety-critical and not safety-critical communications can take place on the same system. Some studies suggest that LEO constellations could be a complete solution for aeronautical communications, but they do not offer solutions for the critical issues mentioned earlier. Additionally, of the three communication domains defined by ICAO, only passenger entertainment services can currently be provided using these constellations. Safety-critical aeronautical communications require reliability levels above 99.999%, which is higher than that required for regular commercial data links. Therefore, addressing the issues with LEO-based SatCOM is necessary before these solutions can reliably support safety-critical data transmission [Maurer2022].

2.2. Specifics

During the creation process of a new communication system, analog voice is replaced by digital data communication. This sets a paradigm shift from analog to digital wireless communications and supports the related trend towards increased autonomous data processing that the Future Communications Infrastructure (FCI) in civil aviation must provide. The FCI is depicted in Figure 1:

 Satellite
#         #
#          # #
#            #   #
#             #      #
#               #        #
#                #          #
#                  #            #
# Satellite-based   #              #
#   Communications   #                 #
#      SatCOM (#)     #                   #
#                      #                    Aircraft
#                       #                 %         %
#                        #              %             %
#                         #           %     Air-Air     %
#                          #        %     Communications   %
#                           #     %         LDACS A/A (%)    %
#                           #   %                              %
#                            Aircraft  % % % % % % % % % %  Aircraft
#                                 |           Air-Ground           |
#                                 |         Communications         |
#                                 |           LDACS A/G (|)        |
#      Communications in          |                                |
#    and around airports          |                                |
#         AeroMACS (-)            |                                |
#                                 |                                |
#         Aircraft-------------+  |                                |
#                              |  |                                |
#                              |  |                                |
#         Ground network       |  |         Ground network         |
SatCOM <---------------------> Airport <----------------------> LDACS
ground                          ground                         ground
transceiver                   transceiver                 transceiver
Figure 1: The Future Communication Infrastructure (FCI)

FCI includes:

2.3. Challenges

This paradigm change brings a lot of new challenges:

2.4. The Need for Wireless

In a high-mobility environment, such as aviation, the envisioned solutions to provide worldwide coverage of data connections with in-flight aircraft require a multi-system, multi-link, multi-hop approach. Thus, air, ground, and space-based data links that provide these technologies will have to operate seamlessly together to cope with the increasing needs of data exchange between aircraft, air-traffic controller, airport infrastructure, airlines, air network service providers (ANSPs), and so forth. Wireless technologies have to be used to tackle this enormous need for a worldwide digital aeronautical data link infrastructure.

2.5. Requirements for RAW

Different safety levels need to be supported. All network traffic handled by the Airborne Internet Protocol Suite (IPS) System are not equal, and the QoS requirements of each network traffic flow must be considered n order to avoid having to support QoS requirements at the granularity of data flows. These flows are grouped into classes that have similar requirements, following the Diffserv approach [ARINC858P1]. These classes are referred to as Classes of Service (CoS), and the flows within a class are treated uniformly from a QoS perspective. Currently, there are at least eight different priority levels (CoS) that can be assigned to packets. For example, a high-priority message requiring low latency and high resiliency could be a "WAKE" warning indicating two aircraft are dangerously close to each other, while a less safety-critical message with low-to-medium latency requirements could be the "WXGRAPH" service providing graphical weather data.

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

Policy needs to be supported when selecting data links. The focus of RAW here should be on the selectors that are responsible for the track a packet takes to reach its end destination. This would minimize the amount of routing information that must travel inside the network because of precomputed routing tables, with the selector being responsible for choosing the most appropriate option according to policy and safety.

2.5.1. Non-latency-critical Considerations

Achieving low latency is a requirement for aeronautics communications, though the expected latency is not extremely low, and what is important is to keep the overall latency bounded under a certain threshold. Low latency in LDACS communications [RFC9372] translates to a latency in the Forward Link (FL - Ground -> Air) of 30-90 ms and a latency in the Reverse Link (RL - Air -> Ground) of 60-120 ms. This use case is not latency critical from that view point. On the other hand, given the controlled environment, end-to-end mechanisms can be applied to guarantee bounded latency where needed.

3. Amusement Parks

3.1. Use Case Description

The digitalization of amusement parks is expected to significantly decrease the cost for maintaining the attractions. Such deployment is a mix between multimedia (e.g., Virtual and Augmented Reality and interactive video environments) and non-multimedia applications (e.g, access control, industrial automation for a roller coaster).

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

3.2. Specifics

Amusement parks comprise a variable number of attractions, mostly outdoor, over a large geographical area. The IT infrastructure is typically multiscale:

3.3. The Need for Wireless

Removing cables helps to easily change the configuration of the attractions or upgrade parts of them at a lower cost. The attraction can be designed modularly and can upgrade or insert novel modules later on in the life cycle of the attraction. Novelty of attractions tends to increase the attractiveness of an amusement park, encouraging previous visitors to regularly visit the park.

Some parts of the attraction are mobile, like trucks of a roller-coaster or robots. Since cables are prone to frequent failures in this situation, wireless transmissions are recommended.

Wearable devices are extensively used for a user experience personalization. They typically need to support wireless transmissions. Personal tags may help to reduce the operating costs [DISNEY15] and increase the number of charged services provided to the audience (e.g., VIP tickets or interactivity). Some applications rely on more sophisticated wearable devices, such as digital glasses or Virtual Reality (VR) headsets for an immersive experience.

3.4. Requirements for RAW

The network infrastructure must support heterogeneous traffic, with very different critical requirements. Thus, flow isolation must be provided.

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

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

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

It is worth noting that low-priority flows (e.g., predictive maintenance, marketing) are delay tolerant; a few minutes or even hours would be acceptable. While classical unscheduled wireless networks already accommodate best-effort traffic, this would force several colocated and subefficient deployments. Unused resources could rather be used for low-priority flows. Indeed, allocated resources are consuming energy in most scheduled networks, even if no traffic is transmitted.

3.4.1. Non-latency-critical Considerations

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

4. Wireless for Industrial Applications

4.1. Use Case Description

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

4.2. Specifics

4.2.1. Control Loops

Process Control designates continuous processing operations, like heating oil in a refinery or mixing up soda. Control loops in the Process Control industry operate at a very low rate, typically four times per second. Factory Automation, on the other hand, deals with discrete goods, such as individual automobile parts, and requires faster loops, to the rate of milliseconds. Motion control that monitors dynamic activities may require even faster rates on the order of and below the millisecond.

In all those cases, a packet must flow reliably between the sensor and the PLC, be processed by the PLC, and be sent to the actuator within the control loop period. In some particular use cases that inherit from analog operations, jitter might also alter the operation of the control loop. A rare packet loss is usually admissible, but typically, a loss of multiple packets in a row will cause an emergency halt of the production and incur a high cost for the manufacturer.

Additional details and use cases related to industrial applications and their RAW requirements can be found in [RAW-IND-REQS].

4.2.2. Monitoring and Diagnostics

A secondary use case deals with monitoring and diagnostics. This data is essential to improve the performance of a production line, e.g., by optimizing real-time processing or by maintenance windows using Machine Learning predictions. For the lack of wireless technologies, some specific industries such as Oil and Gas have been using serial cables, literally by the millions, to perform their process optimization over the previous decades. However, few industries would afford the associated cost. One of the goals of the Industrial Internet of Things is to provide the same benefits to all industries, including SmartGrid, transportation, building, commercial, and medical. This requires a cheap, available, and scalable IP-based access technology.

Inside the factory, wires may already be available to operate the control network. However, monitoring and diagnostics data are not welcome in that network for several reasons. On the one hand, it is rich and asynchronous, meaning that it may influence the deterministic nature of the control operations and impact the production. On the other hand, this information must be reported to the operators over IP, which means the potential for a security breach via the interconnection of the Operational Technology network with the Internet Technology network and the potential of a rogue access.

4.3. The Need for Wireless

Wires used on a robot arm are prone to breakage, after a few thousand flexions, a lot faster than a power cable that is wider in diameter and more resilient. In general, wired networking and mobile parts are not a good match, mostly in the case of fast and recurrent activities, as well as rotation.

When refurbishing older premises that were built before the Internet age, power is usually available everywhere, but data is not. It is often impractical, time consuming and expensive to deploy an Ethernet fabric across walls and between buildings. Deploying a wire may take months and cost tens of thousands of US Dollars.

Even when wiring exists, like in the case of an existing control network, asynchronous IP packets, such as diagnostics, may not be welcome for operational and security reasons. For those packets, the option to create a parallel wireless network offers a credible solution that can scale with the many sensors and actuators that equip every robot, valve, and fan that are deployed on the factory floor. It may also help detect and prevent a failure that could impact the production, like the degradation (vibration) of a cooling fan on the ceiling. IEEE Std. 802.15.4 TSCH [RFC7554] is a promising technology for that purpose, mostly if the scheduled operations enable the use of the same network by asynchronous and deterministic flows in parallel.

4.4. Requirements for RAW

As stated by the "Deterministic Networking Problem Statement" [RFC8557], a deterministic network is backwards compatible with (capable of transporting) statistically multiplexed traffic while preserving the properties of the accepted deterministic flows. While the "6TiSCH Architecture" [RFC9030] serves that requirement, the work at 6TiSCH was focused on best-effort IPv6 packet flows. RAW should be able to lock so-called "hard cells" (i.e., scheduled cells [6TiSCH-TERMS]) for use by a centralized scheduler and leverage time and spatial diversity over a graph of end-to-end paths called a "Track" that is based on those cells.

Over recent years, major industrial protocols have been migrating towards Ethernet and IP. (For example, [ODVA] with EtherNet/IP [EIP] and [PROFINET], where ODVA is the organization that supports network technologies built on the Common Industrial Protocol (CIP) including EtherNet/IP.) In order to unleash the full power of the IP hourglass model, it should be possible to deploy any application over any network that has the physical capacity to transport the industrial flow, regardless of the MAC/PHY technology, wired, or wireless, and across technologies. RAW mechanisms should be able to set up a Track over a wireless access segment and a wired or wireless backbone to report both sensor data and critical monitoring within a bounded latency and should be able to maintain the high reliability of the flows over time. It is also important to ensure that RAW solutions are interoperable with existing wireless solutions in place and with legacy equipment whose capabilities can be extended using retrofitting. Maintainability, as a broader concept than reliability, is also important in industrial scenarios [MAR19].

4.4.1. Non-latency-critical Considerations

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

5. Professional Audio and Video

5.1. Use Case Description

Many devices support audio and video streaming [RFC9317] by employing 802.11 wireless LAN. Some of these applications require low latency capability, for instance, when the application provides interactive play or when the audio plays in real time -- meaning being live for public addresses in train stations or in theme parks.

The professional audio and video industry (ProAV) includes:

5.2. Specifics

5.2.1. Uninterrupted Stream Playback

Considering the uninterrupted audio or video stream, a potential packet loss during the transmission of audio or video flows cannot be tackled by re-trying the transmission, as it is done with file transfer, because by the time the lost packet has been identified, it is too late to proceed with packet re-transmission. Buffering might be employed to provide a certain delay that will allow for one or more re-transmissions. However, such an approach is not viable in applications where delays are not acceptable.

5.2.2. Synchronized Stream Playback

In the context of ProAV over packet networks, latency is the time between the transmitted signal over a stream and its reception. Thus, for sound to remain synchronized to the movement in the video, the latency of both the audio and video streams must be bounded and consistent.

5.3. The Need for Wireless

Audio and video devices need the wireless communication to support video streaming via IEEE 802.11 wireless LAN, for instance. Wireless communications provide huge advantages in terms of simpler deployments in many scenarios where the use of a wired alternative would not be feasible. Similarly, in live events, mobility support makes wireless communications the only viable approach.

Deployed announcement speakers, for instance, along the platforms of the train stations, need the wireless communication to forward the audio traffic in real time. Most train stations are already built, and deploying novel cables for each novel service seems expensive.

5.4. Requirements for RAW

The network infrastructure needs to support heterogeneous types of traffic (including QoS).

Content delivery must have bounded latency (to the lowest possible latency).

The deployed network topology should allow for multipath. This will enable for multiple streams to have different (and multiple) paths (Tracks) through the network to support redundancy.

5.4.1. Non-latency-critical Considerations

For synchronized streaming, latency must be bounded. Therefore, depending on the actual requirements, this can be considered as "latency critical". However, the most critical requirement of this use case is reliability, which can be achieved by the network providing redundancy. Note that in many cases, wireless is only present in the access where RAW mechanisms could be applied, but other wired segments are also involved (like the Internet), and therefore latency cannot be guaranteed.

6. Wireless Gaming

6.1. Use Case Description

The gaming industry includes [IEEE80211RTA] real-time mobile gaming, wireless console gaming, wireless gaming controllers, and cloud gaming. Note that they are not mutually exclusive (e.g., a console can connect wirelessly to the Internet to play a cloud game). For RAW, wireless console gaming is the most relevant one. We next summarize the four:

6.2. Specifics

While a lot of details can be found at [IEEE80211RTA], we next summarize the main requirements in terms of latency, jitter, and packet loss:

6.3. The Need for Wireless

Gaming is evolving towards wireless, as players demand being able to play anywhere, and the game requires a more immersive experience including body movements. Besides, the industry is changing towards playing from mobile phones, which are inherently connected via wireless technologies. Wireless controllers are the rule in modern gaming, with increasingly sophisticated interactions (e.g., haptic feedback, augmented reality).

6.4. Requirements for RAW

Time-sensitive networking extensions:
Extensions, such as time-aware shaping and redundancy, can be explored to address congestion and reliability problems present in wireless networks. As an example, in haptics, it is very important to minimize latency failures.
Priority tagging (Stream identification):
One basic requirement to provide better QoS for time-sensitive traffic is the capability to identify and differentiate time-sensitive packets from other (like best-effort) traffic.
Time-aware shaping:
This capability (defined in IEEE 802.1Qbv) consists of gates to control the opening and closing of queues that share a common egress port within an Ethernet switch. A scheduler defines the times when each queue opens or closes, therefore, eliminating congestion and ensuring that frames are delivered within the expected latency bounds. Though, note that while this requirement needs to be signaled by RAW mechanisms, it would actually be served by the lower layer.
Dual/multiple link:
Due to the fact that competitions and interference are common and hardly in control under wireless network, to improve the latency stability, dual/multiple link proposal is brought up to address this issue.
Admission Control:
Congestion is a major cause of high/variable latency, and it is well known that if the traffic load exceeds the capability of the link, QoS will be degraded. QoS degradation may be acceptable for many applications today. However, emerging time-sensitive applications are highly susceptible to increased latency and jitter. To better control QoS, it is important to control access to the network resources.

6.4.1. Non-latency-critical Considerations

Depending on the actual scenario, and on use of Internet to interconnect different users, the communication requirements of this use case might be considered as latency critical due to the need of bounded latency. However, note that, in most of these scenarios, part of the communication path is not wireless, and DetNet mechanisms cannot be applied easily (e.g., when the public Internet is involved), and therefore, reliability is the critical requirement.

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

7.1. Use Case Description

Unmanned Aerial Vehicles (UAVs) are becoming very popular for many different applications, including military and civil use cases. The term "drone" is commonly used to refer to a UAV.

UAVs can be used to perform aerial surveillance activities, traffic monitoring (i.e., the Spanish traffic control has recently introduced a fleet of drones for quicker reactions upon traffic congestion related events [DGT2021]), support of emergency situations, and even transporting of small goods (e.g., medicine in rural areas). Note that the surveillance and monitoring application would have to comply with local regulations regarding location privacy of users. Different considerations have to be applied when surveillance is performed for traffic rules enforcement (e.g., generating fines), as compared to when traffic load is being monitored.

Many types of vehicles, including UAVs but also others, such as cars, can travel in platoons, driving together with shorter distances between vehicles to increase efficiency. Platooning imposes certain vehicle-to-vehicle considerations, most of these are applicable to both UAVs and other vehicle types.

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

Note that autonomous cars share many of the characteristics of the aforementioned UAV case. Therefore, it is of interest for RAW.

7.2. Specifics

Some of the use cases and tasks involving UAVs require coordination among UAVs. Others involve complex computing tasks that might not be performed using the limited computing resources that a drone typically has. These two aspects require continuous connectivity with the control center and among UAVs.

Remote maneuvering of a drone might be performed over a cellular network in some cases, but there are situations that need very low latency and deterministic behavior of the connectivity. Examples involve platooning of drones or sharing of computing resources among drones (like a drone offloading some function to a neighboring drone).

7.3. The Need for Wireless

UAVs cannot be connected through any type of wired media, so it is obvious that wireless is needed.

7.4. Requirements for RAW

The network infrastructure is composed of the UAVs themselves, requiring self-configuration capabilities.

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

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

7.4.1. Non-latency-critical Considerations

Today's solutions keep the processing operations that are critical local (i.e., they are not offloaded). Therefore, in this use case, the critical requirement is reliability, and, only for some platooning and inter-drone communications, latency is critical.

8. Edge Robotics Control

8.1. Use Case Description

The edge robotics scenario consists of several robots, deployed in a given area (like a shopping mall) and inter-connected via an access network to a network edge device or a data center. The robots are connected to the edge so that complex computational activities are not executed locally at the robots but offloaded to the edge. This brings additional flexibility in the type of tasks that the robots perform, reduces the costs of robot-manufacturing (due to their lower complexity), and enables complex tasks involving coordination among robots (that can be more easily performed if robots are centrally controlled).

Simple examples of the use of multiple robots are cleaning, video surveillance (note that this have to comply with local regulations regarding user privacy at the application level), search and rescue operations, and delivering of goods from warehouses to shops. Multiple robots are simultaneously instructed to perform individual tasks by moving the robotic intelligence from the robots to the network's edge. That enables easy synchronization, scalable solution, and on-demand option to create flexible fleet of robots.

Robots would have various forms of wireless connectivity:

8.2. Specifics

Some of the use cases and tasks involving robots might benefit from decomposition of a service into small functions that are distributed and chained among robots and the edge. These require continuous connectivity with the control center and among drones.

Robot control is an activity requiring very low latency (0.5-20 ms [Groshev2021]) between the robot and the location where the control intelligence resides (which might be the edge or another robot).

8.3. The Need for Wireless

Deploying robots in scenarios such as shopping malls for the applications mentioned cannot be done via wired connectivity.

8.4. Requirements for RAW

The network infrastructure needs to support heterogeneous types of traffic, from robot control to video streaming.

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

8.4.1. Non-latency-critical Considerations

This use case might combine multiple communication flows, with some of them being latency critical (like those related to robot-control tasks). Note that there are still many communication flows (like some offloading tasks) that only demand reliability and availability.

9. Instrumented Emergency Medical Vehicles

9.1. Use Case Description

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

The LAN needs to be routed through radio-WANs (a radio network in the interior of a network, i.e., it is terminated by routers) to complete the network linkage.

9.2. Specifics

What we have today is multiple communication systems to reach the vehicle via:

This redundancy of systems does not contribute to availability.

Most of the scenarios involving the use of an instrumented ambulance are composed of many different flows, each of them with slightly different requirements in terms of reliability and latency. Destinations might be either the ambulance itself (local traffic), a near edge cloud, or the general Internet/cloud. Special care (at application level) have to be paid to ensure that sensitive data is not disclosed to unauthorized parties by properly securing traffic and authenticating the communication ends.

9.3. The Need for Wireless

Local traffic between the first responders and ambulance staff and the ambulance equipment cannot be done via wired connectivity as the responders perform initial treatment outside of the ambulance. The communications from the ambulance to external services must be wireless as well.

9.4. Requirements for RAW

We can derive some pertinent requirements from this scenario:

9.4.1. Non-latency-critical Considerations

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

10. Summary

This document enumerates several use cases and applications that need RAW technologies, focusing on the requirements from reliability, availability, and latency. While some use cases are latency critical, there are also several applications that are not latency critical but do pose strict reliability and availability requirements.

11. IANA Considerations

This document has no IANA actions.

12. Security Considerations

This document covers several representative applications and network scenarios that are expected to make use of RAW technologies. Each of the potential RAW use cases will have security considerations from both the use-specific perspective and the RAW technology perspective. [RFC9055] provides a comprehensive discussion of security considerations in the context of DetNet, which are generally also applicable to RAW.

13. Informative References

[6TiSCH-TERMS]
Palattella, MR., Ed., Thubert, P., Watteyne, T., and Q. Wang, "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", Work in Progress, Internet-Draft, draft-ietf-6tisch-terminology-10, , <https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-terminology-10>.
[ACI19]
Airports Council International, "Annual World Airport Traffic Report, 2019", , <https://store.aci.aero/product/annual-world-airport-traffic-report-2019/>.
[ARINC858P1]
SAE International, "Internet Protocol Suite (IPS) for Aeronautical Safety Services Part 1 Airborne IPS System Technical Requirements", ARINC858P1, , <https://www.sae.org/standards/content/arinc858p1/>.
[DGT2021]
Menéndez, J., "Drones: así es la vigilancia" [Drones: this is surveillance], , <https://revista.dgt.es/es/reportajes/2021/01ENERO/0126-Como-funciona-un-operativo-con-drones.shtml>.
[DISNEY15]
Kuang, C., "Disney's $1 Billion Bet on a Magical Wristband", , <https://www.wired.com/2015/03/disney-magicband/>.
[EIP]
ODVA, "EtherNet/IP | ODVA Technologies | Industrial Automation", <https://www.odva.org/technology-standards/key-technologies/ethernet-ip/>.
[FAA20]
U.S. Department of Transportation: Federal Aviation Administration (FAA), "Next Generation Air Transportation System (NextGen)", <https://www.faa.gov/nextgen/>.
[Groshev2021]
Groshev, M., Guimarães, C., de la Oliva, A., and R. Gazda, "Dissecting the Impact of Information and Communication Technologies on Digital Twins as a Service", IEEE Access, Volume 9, DOI 10.1109/ACCESS.2021.3098109, , <https://doi.org/10.1109/ACCESS.2021.3098109>.
[IAC20]
Iacus, S., Natale, F., Santamaria, C., Spyratos, S., and M. Vespe, "Estimating and projecting air passenger traffic during the COVID-19 coronavirus outbreak and its socio-economic impact", Safety Science, Volume 129, DOI 10.1016/j.ssci.2020.104791, , <https://doi.org/10.1016/j.ssci.2020.104791>.
[IAT20]
IATA, "Economic Performance of the Airline Industry", , <https://www.iata.org/en/iata-repository/publications/economic-reports/airline-industry-economic-performance---november-2020---report/>.
[ICAO2022]
International Civil Aviation Organization (ICAO), "CHAPTER 13 L-Band Digital Aeronautical Communications System (LDACS)", International Standards and Recommended Practices, Annex 10 - Aeronautical Telecommunications, Volume III, Communication Systems, , <https://www.ldacs.com/wp-content/uploads/2023/03/WP06.AppA-DCIWG-6-LDACS_SARPs.pdf>.
[IEEE802.1AS]
IEEE, "IEEE Standard for Local and Metropolitan Area Networks--Timing and Synchronization for Time-Sensitive Applications", DOI 10.1109/IEEESTD.2020.9121845, IEEE 802.1AS-2020, , <https://doi.org/10.1109/IEEESTD.2020.9121845>.
[IEEE80211BE]
Cavalcanti, D. and G. Venkatesan, "802.1 TSN over 802.11 with updates from developments in 802.11be", IEEE plenary meeting, , <https://www.ieee802.org/1/files/public/docs2020/new-Cavalcanti-802-1TSN-over-802-11-1120-v02.pdf>.
[IEEE80211RTA]
IEEE standard for Information Technology, "IEEE 802.11 Real Time Applications TIG Report", .
[ISA100]
ISA, "ISA100, Wireless Systems for Automation", <https://www.isa.org/isa100/>.
[KOB12]
Kober, J., Glisson, M., and M. Mistry, "Playing catch and juggling with a humanoid robot", DOI 10.1109/HUMANOIDS.2012.6651623, , <https://doi.org/10.1109/HUMANOIDS.2012.6651623>.
[MAR19]
Martinez, B., Cano, C., and X. Vilajosana, "A Square Peg in a Round Hole: The Complex Path for Wireless in the Manufacturing Industry", IEEE Communications Magazine, Volume 57, Issue 4, DOI 10.1109/MCOM.2019.1800570, , <https://doi.org/10.1109/MCOM.2019.1800570>.
[Maurer2022]
Mäurer, N., Guggemos, T., Ewert, T., Gräupl, T., Schmitt, C., and S. Grundner-Culemann, "Security in Digital Aeronautical Communications A Comprehensive Gap Analysis", International Journal of Critical Infrastructure Protection, Volume 38, DOI 10.1016/j.ijcip.2022.100549, , <https://doi.org/10.1016/j.ijcip.2022.100549>.
[ODVA]
ODVA, "ODVA | Industrial Automation | Technologies and Standards", <https://www.odva.org/>.
[PLA14]
Plass, S., Hermenier, R., Lücke, O., Gomez Depoorter, D., Tordjman, T., Chatterton, M., Amirfeiz, M., Scotti, S., Cheng, Y., Pillai, P., Gräupl, T., Durand, F., Murphy, K., Marriott, A., and A. Zaytsev, "Flight Trial Demonstration of Seamless Aeronautical Networking", IEEE Communications Magazine, Volume 52, Issue 5, DOI 10.1109/MCOM.2014.6815902, , <https://doi.org/10.1109/MCOM.2014.6815902>.
[PROFINET]
PROFINET, "PROFINET Technology", <https://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, , <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-08, , <https://datatracker.ietf.org/doc/html/draft-ietf-raw-technologies-08>.
[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, , <https://www.rfc-editor.org/info/rfc2475>.
[RFC7554]
Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement", RFC 7554, DOI 10.17487/RFC7554, , <https://www.rfc-editor.org/info/rfc7554>.
[RFC8557]
Finn, N. and P. Thubert, "Deterministic Networking Problem Statement", RFC 8557, DOI 10.17487/RFC8557, , <https://www.rfc-editor.org/info/rfc8557>.
[RFC8578]
Grossman, E., Ed., "Deterministic Networking Use Cases", RFC 8578, DOI 10.17487/RFC8578, , <https://www.rfc-editor.org/info/rfc8578>.
[RFC8655]
Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, , <https://www.rfc-editor.org/info/rfc8655>.
[RFC9030]
Thubert, P., Ed., "An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", RFC 9030, DOI 10.17487/RFC9030, , <https://www.rfc-editor.org/info/rfc9030>.
[RFC9055]
Grossman, E., Ed., Mizrahi, T., and A. Hacker, "Deterministic Networking (DetNet) Security Considerations", RFC 9055, DOI 10.17487/RFC9055, , <https://www.rfc-editor.org/info/rfc9055>.
[RFC9317]
Holland, J., Begen, A., and S. Dawkins, "Operational Considerations for Streaming Media", RFC 9317, DOI 10.17487/RFC9317, , <https://www.rfc-editor.org/info/rfc9317>.
[RFC9372]
Mäurer, N., Ed., Gräupl, T., Ed., and C. Schmitt, Ed., "L-Band Digital Aeronautical Communications System (LDACS)", RFC 9372, DOI 10.17487/RFC9372, , <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

Carlos J. Bernardos (editor)
Universidad Carlos III de Madrid
Av. Universidad, 30
28911 Madrid
Spain
Georgios Papadopoulos
IMT Atlantique
Office B00 - 114A
2 Rue de la Chataigneraie
35510 Cesson-Sevigne - Rennes
France
Pascal Thubert
Cisco Systems, Inc
Building D
45 Allee des Ormes - BP1200
06254 MOUGINS - Sophia Antipolis
France
Fabrice Theoleyre
CNRS
ICube Lab, Pole API
300 boulevard Sebastien Brant - CS 10413
67400 Illkirch
France