RFC 9450

Reliable and Available Wireless (RAW) Use Cases

📅 published August 2023, from ietf

Reliable and Available Wireless (RAW) Use Cases 🦋

okay so the title block is giving Informational 💅. This is RFC 9450, published for information and not as an Internet Standards Track spec (ISSN 2070-1721). The authors are CJ. Bernardos, Ed. (UC3M), G. Papadopoulos (IMT Atlantique), P. Thubert (Cisco), and F. Theoleyre (CNRS), and it's dated August 2023. The header has no Obsoletes or Updates line, so it doesn't replace or change any other RFC 🙈

Abstract ✨

The wireless medium comes with some seriously specific challenges if you want the same kinds of guarantees you get from wired deterministic networks 😭. But there's a whole bunch of use cases that just can't be done with wires, and those are totally worth the extra effort of going wireless 🌈. This document walks through wireless use cases that need reliable and available behavior, including 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 🚑.

Status of This Memo 📜

This document is not an Internet Standards Track specification. It's published for informational purposes 🎀.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, received public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 7841 for more on that 🧐.

For the current status of this document, any errata, and how to give feedback on it, check https://www.rfc-editor.org/info/rfc9450 🔗.

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they're in effect on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License 📝.

Table of Contents 🗂️

   1.  Introduction
   2.  Aeronautical Communications
     2.1.  Problem Statement
     2.2.  Specifics
     2.3.  Challenges
     2.4.  The Need for Wireless
     2.5.  Requirements for RAW
       2.5.1.  Non-latency-critical Considerations
   3.  Amusement Parks
     3.1.  Use Case Description
     3.2.  Specifics
     3.3.  The Need for Wireless
     3.4.  Requirements for RAW
       3.4.1.  Non-latency-critical Considerations
   4.  Wireless for Industrial Applications
     4.1.  Use Case Description
     4.2.  Specifics
       4.2.1.  Control Loops
       4.2.2.  Monitoring and Diagnostics
     4.3.  The Need for Wireless
     4.4.  Requirements for RAW
       4.4.1.  Non-latency-critical Considerations
   5.  Professional Audio and Video
     5.1.  Use Case Description
     5.2.  Specifics
       5.2.1.  Uninterrupted Stream Playback
       5.2.2.  Synchronized Stream Playback
     5.3.  The Need for Wireless
     5.4.  Requirements for RAW
       5.4.1.  Non-latency-critical Considerations
   6.  Wireless Gaming
     6.1.  Use Case Description
     6.2.  Specifics
     6.3.  The Need for Wireless
     6.4.  Requirements for RAW
       6.4.1.  Non-latency-critical Considerations
   7.  Unmanned Aerial Vehicles and Vehicle-to-Vehicle Platooning and
           Control
     7.1.  Use Case Description
     7.2.  Specifics
     7.3.  The Need for Wireless
     7.4.  Requirements for RAW
       7.4.1.  Non-latency-critical Considerations
   8.  Edge Robotics Control
     8.1.  Use Case Description
     8.2.  Specifics
     8.3.  The Need for Wireless
     8.4.  Requirements for RAW
       8.4.1.  Non-latency-critical Considerations
   9.  Instrumented Emergency Medical Vehicles
     9.1.  Use Case Description
     9.2.  Specifics
     9.3.  The Need for Wireless
     9.4.  Requirements for RAW
       9.4.1.  Non-latency-critical Considerations
   10. Summary
   11. IANA Considerations
   12. Security Considerations
   13. Informative References
   Acknowledgments
   Authors' Addresses

1. Introduction 🌸

Okay, so Deterministic Networking (DetNet) is the thing that gives you the capability to carry specified unicast or multicast data streams for real-time apps 🚀. It's built on time, resource reservation, and policy enforcement by distributed shapers [RFC2475]. The goal is extremely low data loss rates and bounded latency, so time-sensitive and mission-critical apps can run on a converged enterprise infrastructure 💼.

DetNet is all about eliminating packet loss for a committed bandwidth while guaranteeing a worst-case end-to-end latency, no matter what the network conditions are and across technologies 🫶. It leans on lower layer (Layer 2 (L2) and below) capabilities so Layer 3 (L3) can use a service layer, steering across multiple technologies and using media independent signaling to get high reliability, precise time delivery, and rate enforcement ✨. You can think of DetNet as a set of new Quality of Service (QoS) guarantees for worst-case delivery 👑. IP networks get more deterministic once the effects of statistical multiplexing (jitter and collision loss) are mostly gone 💅. That takes tight control of the physical resources, keeping the traffic within what the underlying technology can physically handle, e.g., by using time-shared resources (bandwidth and buffers) per circuit, by shaping or scheduling the packets at every hop, or by mixing these techniques together 🧚.

Key attributes of DetNet include:

  • time synchronization on all the nodes,
  • multi-technology path with co-channel interference minimization,
  • frame preemption and guard time mechanisms to ensure a worst-case delay, and
  • new traffic shapers, both within and at the edge, to protect the network.

Wireless runs on a shared medium, and transmissions can't be guaranteed to be fully deterministic because of uncontrolled interferences, including self-induced multipath fading 🙈. The term RAW stands for "Reliable and Available Wireless" and refers to the mechanisms aimed at providing high reliability and availability for IP connectivity over a wireless medium 🦋. Making wireless reliable and available is even more of a challenge than it is with wires, because there are so many causes of transmission loss that add up to congestion losses, plus delays caused by overbooked shared resources 😭.

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

Open standards for DetNet have mostly focused on wired media so far, with Audio Video Bridging (AVB) and Time-Sensitive Networking (TSN) at the IEEE and DetNet [RFC8655] at the IETF 🎀. But wires just can't be used in a bunch of cases, like 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 🏭. The catch is that they come with a high cost in Operational Expenditure (OPEX) and Capital Expenditure (CAPEX), and they're limited to very few industries, e.g., process control, concert instruments, or racing 🏎️.

This is changing now, as detailed in [RAW-TECHNOS] 🌈:

  • IMT-2020 has recognized Ultra-Reliable Low Latency Communication (URLLC) as a key functionality for the upcoming 5G 📶.
  • IEEE 802.11 has identified a set of real applications [IEEE80211RTA], which may use the IEEE802.11 standards. They typically emphasize strict end-to-end delay requirements ⏱️.
  • The IETF has produced an IPv6 stack for IEEE Std. 802.15.4 Time-Slotted Channel Hopping (TSCH) and an architecture [RFC9030] that enables RAW on a shared MAC 💜.

Experiments have already been run 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 more use cases that need "reliable/predictable and available" flows over wireless links and, possibly, complex multi-hop paths called "Tracks" 🛤️. The closest existing one is the "Wireless for Industrial Applications" (Section 5 of [RFC8578]) use case, while the "Cellular Radio" (Section 6 of [RFC8578]) use case is mostly about the (wired) link part of a Radio Access Network (RAN) 📡. The "Wireless for Industrial Applications" use case definitely covers an area of interest for RAW, but it's limited to IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH), so its scope is narrower than the use cases coming up in this document 💅.

2. Aeronautical Communications ✈️

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

2.1. Problem Statement

okay so, up to 2020 civil air traffic was growing nonstop at a compound rate of 5.8% per year [ACI19] 📈✈️, and even with the COVID-19 pandemic being a total disaster 😭, air traffic is expected to bounce back super fast post-pandemic [IAT20] [IAC20]. That means legacy Air-Traffic Management (ATM) systems are likely to hit their capacity limits, so new aeronautical communication tech is becoming a must 💅. The VHF band is especially stressed in high-density areas in Europe, the US, and Asia [SESAR] [FAA20], which is calling for new digital approaches like 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 spectrum more efficient by moving from analog voice to digital data communication [PLA14] is necessary to handle all that growth in civil aviation and its supporting infrastructure 🫶. LDACS is a promising candidate for long-range terrestrial communications and is already being standardized in the International Civil Aviation Organization (ICAO) [ICAO2022] [RFC9372] ✨.

Note that the huge planned Low Earth Orbit (LEO) constellations of satellites can deliver fast end-to-end latency and high data rates at a reasonable cost 🌍, but they come with challenges too: frequent handovers, high interference, and a really diverse range of system users 😬. That last one can create security issues, since both safety-critical and not safety-critical communications can happen on the same system 🚨. Some studies suggest LEO constellations could be a complete solution for aeronautical communications, but they don't offer solutions for the critical issues mentioned earlier 🙈. Also, out of the three communication domains defined by ICAO, only passenger entertainment services can currently be provided using these constellations 🎬. Safety-critical aeronautical communications need reliability levels above 99.999%, which is higher than what regular commercial data links need 💀. So LEO-based SatCOM has to address these issues before it can reliably support safety-critical data transmission [Maurer2022] 🔐.

2.2. Specifics

okay so during the creation of a new communication system, analog voice gets replaced by digital data communication 💻. This is a full paradigm shift from analog to digital wireless communications, and it supports the bigger trend toward increased autonomous data processing that the Future Communications Infrastructure (FCI) in civil aviation must provide 🦋. Here's what the FCI looks like, 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)

So the FCI includes 🌈:

  • 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

this paradigm change brings a whole bunch of new challenges 😤:

  • Efficiency: It is necessary to keep latency, time, and data overhead of new aeronautical data links to a minimum. ⏱️
  • Modularity: Systems in avionics usually operate for up to 30 years. Thus, solutions must be modular, easily adaptable, and updatable. 🧩
  • Interoperability: All 192 members of the ICAO must be able to use these solutions. 🌏
  • Dynamicity: The communication infrastructure needs to accommodate mobile devices (airplanes) that move extremely fast. 🏎️💨

2.4. The Need for Wireless

in a high-mobility environment like aviation, the envisioned solutions for worldwide coverage of data connections with in-flight aircraft need a multi-system, multi-link, multi-hop approach 🌐. So air, ground, and space-based data links that provide these technologies will have to work together seamlessly to keep up with the growing need for data exchange between aircraft, air-traffic controllers, 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 🚦. Not all network traffic handled by the Airborne Internet Protocol Suite (IPS) System is equal, and the QoS requirements of each network traffic flow must be considered in order to avoid having to support QoS requirements at the granularity of data flows 🎀. These flows get grouped into classes with similar requirements, following the Diffserv approach [ARINC858P1]. These classes are called Classes of Service (CoS), and the flows within a class are treated uniformly from a QoS perspective 🍓. Right now there are at least eight different priority levels (CoS) that can be assigned to packets 👑. For example, a high-priority message needing low latency and high resiliency could be a "WAKE" warning saying 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 has to 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 isn't extremely low. What really matters is keeping 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. From that point of view this use case isn't latency critical 😌. 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 of maintaining the attractions 🎡. This deployment is a mix of 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 that react in real time ⚡. Typical applications include:

  • Emergency: the safety of the operators and visitors has to be preserved, and the attraction must be stopped appropriately when a failure is detected 🚨.
  • Video: augmented and virtual realities are integrated in the attraction. Wearable mobile devices (e.g., glasses and virtual reality headsets) need to offload one part of the processing tasks 🥽.
  • Real-time interactions: visitors may interact with an attraction, like in a real-time video game 🎮. Visitors may virtually interact with their environment, triggering actions in the real world (through actuators) [KOB12] 🤯.
  • Geolocation: visitors are tracked with a personal wireless tag, so that their user experience is improved. This requires special care to ensure that visitors' privacy is not breached, and users are anonymously tracked 🔒.
  • Predictive maintenance: statistics are collected to predict future failures or to compute later, more complex statistics about the attraction's usage, the downtime, etc. 📊
  • Marketing: to improve the customer experience, owners may collect a large amount of data to understand the behavior and the choices of their clients 🛍️.

3.2. Specifics

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

  • Local area: The sensors and actuators controlling the attractions are colocated. Control loops trigger only local traffic, with a small end-to-end delay, typically less than 10 ms, like classical industrial systems [IEEE80211RTA] ⚙️.
  • Wearable devices: Wearable mobile devices are free to move in the park. They exchange traffic locally (identification, personalization, multimedia) or globally (billing, child-tracking) 👟.
  • Edge computing: Computationally intensive applications offload some tasks. Edge computing seems to be an efficient way to implement real-time applications with offloading. Some non-time-critical tasks may rather use the cloud (predictive maintenance, marketing) ☁️💜.

3.3. The Need for Wireless

Ngl, ditching the cables is such a glow-up 💖 It makes it way cheaper to reconfigure attractions or upgrade parts of them 🎢. The attraction can be built modularly, so new modules can be added or swapped in later on in its life cycle 🧩. Novelty is everything here too: new attractions get previous visitors coming back to the park again and again 🎀 (iykyk, repeat visits are the whole goal ✨).

Some parts of the attraction are mobile, like the trucks on a roller-coaster or robots 🤖. Cables break all the time in that situation, so wireless transmissions are recommended 🦋.

Wearable devices are everywhere for personalized user experiences 💅, and they typically need to support wireless transmissions 📡. Personal tags can help reduce operating costs [DISNEY15] and increase the number of charged services offered to the audience (e.g., VIP tickets or interactivity) 💸. Some applications go even bigger with more sophisticated wearables, like 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 🧁. So flow isolation must be provided 🔒.

The transmissions must be scheduled appropriately, even when mobile devices are around 🏃‍♀️. [RFC9030] already proposes an architecture for synchronized, IEEE Std. 802.15.4 Time-Slotted Channel Hopping (TSCH) networks ✨. But the industry needs a multi-technology solution that can guarantee end-to-end requirements across heterogeneous technologies, with strict Service Level Agreement (SLA) requirements 📋.

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

It's expected that several different technologies (long vs. short range) get deployed and have to cohabit the same area 🤝. So we need 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's worth noting that low-priority flows (e.g., predictive maintenance, marketing) are delay tolerant ⏳. A few minutes or even hours would be acceptable. Classical unscheduled wireless networks already accommodate best-effort traffic, but that would force several colocated and subefficient deployments 😩. Unused resources could rather be used for low-priority flows 💡. Honestly, allocated resources keep consuming energy in most scheduled networks, even when no traffic is transmitted 🔋.

3.4.1. Non-latency-critical Considerations

Some applications in this use case involve control loops (e.g., sensors and actuators) that require bounded latencies below 10 ms, so those can be considered latency critical 🚨. Other applications mostly demand reliability (e.g., safety-related or maintenance) 🛠️.

4. Wireless for Industrial Applications 🏭

4.1. Use Case Description

Okay, so a major use case for networking in industrial environments is control networks 🎛️. 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 is all about 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 of 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 scheduling 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 be able to 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 🚩.

Heads up, bestie: that last point is about security. Mixing the Operational Technology network with the Internet Technology network opens the door to a breach, and a rogue access is a real risk too. Take it seriously 🔐.

4.3. The Need for Wireless

Wires used on a robot arm are prone to breakage after a few thousand flexions 🦾, and they break 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 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.) 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 they 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:

  • Virtual Reality / Augmented Reality (VR/AR) 🥽
  • Production and post-production systems, such as CD and Blu-ray disk mastering 💿
  • Public address, media, and emergency systems at large venues (e.g., airports, train stations, stadiums, and theme parks) 🏟️

5.2. Specifics

5.2.1. Uninterrupted Stream Playback

Okay, so with an uninterrupted audio or video stream, a potential packet loss can't be fixed by re-trying the transmission, the way it is done with file transfer 😱. 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 allows 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 ⏱️. So, for sound to stay 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

Okay, so audio and video devices need wireless to do video streaming over IEEE 802.11 wireless LAN, for instance 📡💖 Wireless is honestly a huge win for simpler deployments in lots of places where going wired wouldn't be feasible 🦋 And for live events? Mobility support makes wireless the only viable approach 🎤✨

Deployed announcement speakers, for instance, along the platforms of the train stations, need wireless to forward the audio traffic in real time 🚉🎀 Most train stations are already built, and laying novel cables for every novel service seems super expensive 💸 (not it, bestie 🙅‍♀️)

5.4. Requirements for RAW

Okay, so 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 lets multiple streams have different (and multiple) paths (Tracks) through the network, which supports redundancy 🛤️🌈

5.4.1. Non-latency-critical Considerations

For synchronized streaming, latency must be bounded. So, 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). That's why 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. These aren't mutually exclusive, though (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. Here's the quick rundown of the four 👑

  • Real-time mobile gaming: Real-time mobile gaming is very sensitive to network latency and stability 📱 The mobile game can connect multiple players together in a single game session and exchange data messages between the game server and connected players. Real-time means the feedback should show up on-screen as users operate in-game ⚡ For a good game experience, the end-to-end latency plus game servers processing time must be the same for all players, and it should not be noticeable as the game is played 🙈 RAW technologies might help keep latencies low on the wireless segments of the communication 💜
  • Wireless console gaming: While gamers may use a physical console, interactions with a remote server may be required for online games 🎧 Most gaming consoles today support Wi-Fi 5, but they 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, mainly because of high latency, lag spikes, and jitter 💀
  • Wireless gaming controllers: Most controllers are wireless now, for the freedom of movement 🙌 Controllers may interact with consoles or directly with the gaming server in the cloud. A low and stable end-to-end latency is of predominant importance here 💅
  • Cloud gaming: Cloud gaming requires low-latency capability, because the user's commands in a game session are sent back to the cloud server ☁️ Then, the cloud server updates the game context based on the received commands, renders the picture/video to be displayed on the user devices, and streams the picture/video content to those devices. User devices very likely are connected wirelessly 🌸

6.2. Specifics

While a lot of details can be found in [IEEE80211RTA], here's the main stuff we need to know about latency, jitter, and packet loss 🤓

  • Intra Basic Service Set (BSS) latency is less than 5 ms. ⏱️
  • Jitter variance is less than 2 ms. 🎯
  • Packet loss is less than 0.1%. 🧐

6.3. The Need for Wireless

Gaming is evolving towards wireless, because players want to be able to play anywhere, and games need a more immersive experience that includes body movements 🕺 Plus, the industry is shifting toward 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, for haptics, it is super important to minimize latency failures 🫨

Priority tagging (Stream identification): One basic requirement for better QoS for time-sensitive traffic is the ability 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 that control the opening and closing of queues sharing a common egress port within an Ethernet switch. A scheduler defines when each queue opens or closes, which eliminates congestion and ensures 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: Competition and interference are common and hardly in anyone's control under wireless networks, so to improve latency stability, a dual/multiple link proposal has been brought up 🦋

Admission Control: Congestion is a major cause of high or variable latency, and it's 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's important to control access to network resources 👑

6.4.1. Non-latency-critical Considerations

Depending on the actual scenario, and on the use of the Internet to interconnect different users, the communication requirements of this use case might be considered latency critical, because of the need for bounded latency. However, note that in most of these scenarios, part of the communication path is not wireless, and DetNet mechanisms cannot easily be applied (e.g., when the public Internet is involved). So 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 for aerial surveillance, traffic monitoring (e.g., Spanish traffic control has recently introduced a fleet of drones for quicker reactions to traffic congestion events [DGT2021]), support in emergency situations, and even transporting small goods (e.g., medicine in rural areas) 💊 Note that surveillance and monitoring applications have to comply with local regulations regarding the location privacy of users 🔐 Different considerations apply when surveillance is performed for traffic rules enforcement (e.g., generating fines), 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 brings certain vehicle-to-vehicle considerations, and most of these apply to both UAVs and other vehicle types 🫶

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

  • Cellular: for communication with the control center, remote maneuvering, and monitoring of the drone;
  • IEEE 802.11: for inter-drone communications (i.e., platooning) and for providing connectivity to other devices (i.e., acting as an Access Point) 📶

Note that autonomous cars share many of the characteristics of the UAV case above, so they're of interest for RAW too 🚘🌈

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 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 include platooning of drones, or sharing 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's obvious that wireless is needed 🙃

7.4. Requirements for RAW

The network infrastructure is composed of the UAVs themselves, which requires 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 (hosted at different UAVs and chained together), 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). So in this use case, the critical requirement is reliability, and latency is only critical for some platooning and inter-drone communications 🥹

8. Edge Robotics Control 🦾

8.1. Use Case Description 🤖

Okay so picture this, bestie 💅 a bunch of robots zooming around one area, like a shopping mall 🛍️, all connected through an access network to a network edge device or a data center. The move is that the robots don't do the complex computing themselves. They offload it to the edge ✨ That's giving flexibility: robots can take on more kinds of tasks, they're cheaper to manufacture because they're simpler, and they can team up on complicated jobs more easily when they're centrally controlled 👑

Simple examples are cleaning 🧹, video surveillance 📹 (note that this has to comply with local regulations about user privacy at the application level 🙈), search and rescue, and delivering goods from warehouses to shops 📦. Multiple robots get individual tasks at the same time because the robot brain moves from the robots over to the network's edge. That means easy synchronization, a scalable solution, and an on-demand, flexible fleet 🦋

Robots can have different kinds of wireless connectivity:

  • Cellular: an additional link to the edge, but mostly as a backup, since ultra-low latency is needed 📶
  • IEEE 802.11: for connecting to the edge and also for robot-to-robot talk (coordinated actions) 🤝

8.2. Specifics 🧩

Some use cases and tasks with robots might benefit from splitting a service into small functions that are spread out and chained across robots and the edge. These need continuous connectivity with the control center and among drones.

Robot control is an activity that needs very low latency (0.5-20 ms [Groshev2021]) between the robot and wherever the control intelligence lives, which might be the edge or another robot ⏱️

8.3. The Need for Wireless 📡

Deploying robots in scenarios like shopping malls for the applications mentioned just can't be done with wired connectivity 🚫🔌

8.4. Requirements for RAW 📋

The network infrastructure needs to support heterogeneous types of traffic, from robot control all the way to video streaming 🎥

When a service is decomposed into functions hosted at different UAVs and chained together, each link connecting two functions has its own 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 can mix multiple communication flows, with some being latency critical (like the ones tied to robot-control tasks). There are still plenty of flows (like some offloading tasks) that only demand reliability and availability 🌸

9. Instrumented Emergency Medical Vehicles 🚑

9.1. Use Case Description 🩺

An instrumented ambulance can have one or more network segments hooked up to end systems like:

  • vital signs sensors on the casualty in the ambulance, relaying medical data to the hospital emergency room 🏥
  • a radio-navigation sensor relaying position data to various destinations, including the dispatcher 🗺️
  • voice communication for the ambulance attendant (who'll likely be consulting with an ER doctor) 🎙️
  • voice communication between the driver and the dispatcher 📻

The LAN needs to be routed through radio-WANs (a radio network in the interior of a network, i.e., one that's terminated by routers) to complete the network linkage 🔗

9.2. Specifics 🔍

Right now, the setup is multiple communication systems to reach the vehicle, like:

  • a dispatching system
  • a cellphone for the attendant
  • a special purpose telemetering system for medical data
  • etc.

Honestly, all that redundancy doesn't help availability at all 🙃

Most instrumented ambulance scenarios are made of many different flows, each with slightly different requirements in terms of reliability and latency. Destinations can be the ambulance itself (local traffic), a near edge cloud, or the general Internet/cloud ☁️ Sensitive data needs special care at the application level, so it isn't disclosed to unauthorized parties. That means properly securing traffic and authenticating both communication ends 🔐

9.3. The Need for Wireless 📶

Local traffic between first responders, ambulance staff, and the ambulance equipment can't be wired, since the responders do initial treatment outside the ambulance 🧑‍⚕️ Communication from the ambulance to external services has to be wireless too 💫

9.4. Requirements for RAW ⭐

We can pull some pertinent requirements from this scenario:

  • High availability of the internetwork is required. The exact level depends on the deployment scenario, since not all emergency agencies share the same type of instrumented emergency vehicles 🚨
  • The internetwork needs to operate in a damaged state (e.g., during an earthquake aftermath, heavy weather, a wildfire, etc.). On top of continuity of operations, rapid restore is a needed characteristic 🛠️
  • The radio-WAN has characteristics similar to the cellphone's. The vehicle travels from one radio coverage area to another, so it needs some hand-off approach 🔄

9.4.1. Non-latency-critical Considerations 🍓

In this case, none of the identified applications require latency-critical communication, but they all do need high reliability and availability 💜

10. Summary 🌈

This document enumerates several use cases and applications that need RAW technologies, focusing on the requirements for reliability, availability, and latency. While some use cases are latency critical, there are also several applications that aren't latency critical but still pose strict reliability and availability requirements 💪

11. IANA Considerations 🎀

This document has no IANA actions. 🌸

12. Security Considerations 🔒

Okay, this one is serious, bestie, so no skipping! 😭 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 ✨

okay bestie, this is the reading list 📚🦋 these are the outside sources the doc leans on, and I'm keeping every title, author, DOI, and link exactly as it is so you can actually find them 💖

Acknowledgments 🫶

Nils Mäurer, Thomas Gräupl, and Corinna Schmitt were huge contributors here 🔥 They gave the input for the aeronautical communication section, so that whole part is lowkey their glow-up. Rex Buddenberg also helped out, giving input to the "Instrumented Emergency Medical Vehicles" section 🚑💜

The authors wanted 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. Literally the whole squad 🌈✨

The work of Carlos J. Bernardos in this document was partially supported by the Horizon Europe PREDICT-6G (Grant 101095890) and UNICO I+D 6G-DATADRIVEN-04 project 🎀

Authors' Addresses 🧚

Here are the contact details for the authors, kept exactly as written so you can reach them 💌

Carlos J. Bernardos (editor)
Universidad Carlos III de Madrid
Av. Universidad, 30
28911 Madrid
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI:   http://www.it.uc3m.es/cjbc/


Georgios Papadopoulos
IMT Atlantique
Office B00 - 114A
2 Rue de la Chataigneraie
35510 Cesson-Sevigne - Rennes
France
Phone: +33 299 12 70 04
Email: georgios.papadopoulos@imt-atlantique.fr


Pascal Thubert
Cisco Systems, Inc
Building D
45 Allee des Ormes - BP1200
06254 MOUGINS - Sophia Antipolis
France
Phone: +33 497 23 26 34
Email: pthubert@cisco.com


Fabrice Theoleyre
CNRS
ICube Lab, Pole API
300 boulevard Sebastien Brant - CS 10413
67400 Illkirch
France
Phone: +33 368 85 45 33
Email: fabrice.theoleyre@cnrs.fr
URI:   https://fabrice.theoleyre.cnrs.fr/

And that's the whole doc, bestie! 🌈💅 The end 🦋

📦 where this page comes from