Skip to main content

RAW use-cases
draft-ietf-raw-use-cases-05

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 9450.
Authors Carlos J. Bernardos , Georgios Z. Papadopoulos , Pascal Thubert , Fabrice Theoleyre
Last updated 2022-09-19 (Latest revision 2022-02-23)
Replaces draft-bernardos-raw-use-cases
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Associated WG milestones
Sep 2020
Working Group Adoption of Use Cases Document
Mar 2022
Use Cases Document submit to IESG
Document shepherd Corinna Schmitt
Shepherd write-up Show Last changed 2022-02-23
IESG IESG state Became RFC 9450 (Informational)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD John Scudder
Send notices to corinna.schmitt@unibw.de
draft-ietf-raw-use-cases-05
RAW                                                   CJ. Bernardos, Ed.
Internet-Draft                                                      UC3M
Intended status: Informational                         G.Z. Papadopoulos
Expires: 27 August 2022                                   IMT Atlantique
                                                              P. Thubert
                                                                   Cisco
                                                            F. Theoleyre
                                                                    CNRS
                                                        23 February 2022

                             RAW use-cases
                      draft-ietf-raw-use-cases-05

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, UAV and V2V control, edge robotics and emergency vehicles)
   demanding reliable and available behavior.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 27 August 2022.

Copyright Notice

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

Bernardos, et al.        Expires 27 August 2022                 [Page 1]
Internet-Draft           RAW use-cases scenarios           February 2022

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to 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 are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Aeronautical Communications . . . . . . . . . . . . . . . . .   5
     2.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   5
     2.2.  Specifics . . . . . . . . . . . . . . . . . . . . . . . .   6
     2.3.  Challenges  . . . . . . . . . . . . . . . . . . . . . . .   7
     2.4.  The Need for Wireless . . . . . . . . . . . . . . . . . .   8
     2.5.  Requirements for RAW  . . . . . . . . . . . . . . . . . .   8
       2.5.1.  Non-latency critical considerations . . . . . . . . .   9
   3.  Amusement Parks . . . . . . . . . . . . . . . . . . . . . . .   9
     3.1.  use-case Description  . . . . . . . . . . . . . . . . . .   9
     3.2.  Specifics . . . . . . . . . . . . . . . . . . . . . . . .   9
     3.3.  The Need for Wireless . . . . . . . . . . . . . . . . . .  10
     3.4.  Requirements for RAW  . . . . . . . . . . . . . . . . . .  10
       3.4.1.  Non-latency critical considerations . . . . . . . . .  11
   4.  Wireless for Industrial Applications  . . . . . . . . . . . .  11
     4.1.  use-case Description  . . . . . . . . . . . . . . . . . .  11
     4.2.  Specifics . . . . . . . . . . . . . . . . . . . . . . . .  11
       4.2.1.  Control Loops . . . . . . . . . . . . . . . . . . . .  11
       4.2.2.  Unmeasured Data . . . . . . . . . . . . . . . . . . .  12
     4.3.  The Need for Wireless . . . . . . . . . . . . . . . . . .  12
     4.4.  Requirements for RAW  . . . . . . . . . . . . . . . . . .  13
       4.4.1.  Non-latency critical considerations . . . . . . . . .  14
   5.  Pro Audio and Video . . . . . . . . . . . . . . . . . . . . .  14
     5.1.  use-case Description  . . . . . . . . . . . . . . . . . .  14
     5.2.  Specifics . . . . . . . . . . . . . . . . . . . . . . . .  14
       5.2.1.  Uninterrupted Stream Playback . . . . . . . . . . . .  14
       5.2.2.  Synchronized Stream Playback  . . . . . . . . . . . .  14
     5.3.  The Need for Wireless . . . . . . . . . . . . . . . . . .  15
     5.4.  Requirements for RAW  . . . . . . . . . . . . . . . . . .  15
       5.4.1.  Non-latency critical considerations . . . . . . . . .  15
   6.  Wireless Gaming . . . . . . . . . . . . . . . . . . . . . . .  15
     6.1.  use-case Description  . . . . . . . . . . . . . . . . . .  15
     6.2.  Specifics . . . . . . . . . . . . . . . . . . . . . . . .  16
     6.3.  The Need for Wireless . . . . . . . . . . . . . . . . . .  16
     6.4.  Requirements for RAW  . . . . . . . . . . . . . . . . . .  16
       6.4.1.  Non-latency critical considerations . . . . . . . . .  17

Bernardos, et al.        Expires 27 August 2022                 [Page 2]
Internet-Draft           RAW use-cases scenarios           February 2022

   7.  Unmanned Aerial Vehicles and Vehicle-to-Vehicle platooning and
           control . . . . . . . . . . . . . . . . . . . . . . . . .  17
     7.1.  use-case Description  . . . . . . . . . . . . . . . . . .  17
     7.2.  Specifics . . . . . . . . . . . . . . . . . . . . . . . .  18
     7.3.  The Need for Wireless . . . . . . . . . . . . . . . . . .  18
     7.4.  Requirements for RAW  . . . . . . . . . . . . . . . . . .  18
       7.4.1.  Non-latency critical considerations . . . . . . . . .  19
   8.  Edge Robotics control . . . . . . . . . . . . . . . . . . . .  19
     8.1.  use-case Description  . . . . . . . . . . . . . . . . . .  19
     8.2.  Specifics . . . . . . . . . . . . . . . . . . . . . . . .  20
     8.3.  The Need for Wireless . . . . . . . . . . . . . . . . . .  20
     8.4.  Requirements for RAW  . . . . . . . . . . . . . . . . . .  20
       8.4.1.  Non-latency critical considerations . . . . . . . . .  20
   9.  Emergencies: Instrumented emergency vehicle . . . . . . . . .  20
     9.1.  use-case Description  . . . . . . . . . . . . . . . . . .  20
     9.2.  Specifics . . . . . . . . . . . . . . . . . . . . . . . .  21
     9.3.  The Need for Wireless . . . . . . . . . . . . . . . . . .  21
     9.4.  Requirements for RAW  . . . . . . . . . . . . . . . . . .  21
       9.4.1.  Non-latency critical considerations . . . . . . . . .  22
   10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .  22
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  22
   13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  22
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  23
     14.2.  Informative References . . . . . . . . . . . . . . . . .  23
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  26

1.  Introduction

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

   Deterministic Networking in the IP world is an attempt to eliminate
   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 on lower (L2 and below) capabilities, 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.
   Deterministic networking can be seen as a set of new Quality of
   Service (QoS) guarantees of worst-case delivery.  IP networks become
   more deterministic when the effects of statistical multiplexing
   (jitter and collision loss) are mostly eliminated.  This requires a

Bernardos, et al.        Expires 27 August 2022                 [Page 3]
Internet-Draft           RAW use-cases scenarios           February 2022

   tight control of the physical resources to maintain the amount of
   traffic within the physical capabilities of the underlying
   technology, e.g., using time-shared resources (bandwidth and buffers)
   per circuit, and/or by shaping and/or scheduling the packets at every
   hop.

   Key attributes of Deterministic Networking include:

   *  time synchronization on all the nodes,

   *  centralized computation of network-wide deterministic paths,

   *  multi-technology path with co-channel interference minimization,

   *  frame preemption and guard time mechanisms to ensure a worst-case
      delay, and

   *  new traffic shapers within and at the edge to protect the network.

   Wireless operates on a shared medium, and transmissions cannot be
   guaranteed to be fully deterministic due to uncontrolled
   interferences, including self-induced multipath fading.  Reliable and
   Available Wireless (RAW) is an effort to provide Deterministic
   Networking Mechanisms on across a multi-hop path that includes a
   wireless physical layer.  Making Wireless Reliable and Available is
   even more challenging than it is with wires, due to the numerous
   causes of loss in transmission that add up to the congestion losses
   and the delays caused by overbooked shared resources.

   The wireless and wired media are fundamentally different at the
   physical level, and while the generic Problem Statement [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 Deterministic Networking 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.  But wires cannot be used in several cases, including mobile or
   rotating devices, rehabilitated industrial buildings, wearable or in-
   body sensory devices, vehicle automation and multiplayer gaming.

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

Bernardos, et al.        Expires 27 August 2022                 [Page 4]
Internet-Draft           RAW use-cases scenarios           February 2022

   This is now changing [I-D.ietf-raw-technologies]:

   *  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
      [IEEE80211-RT-TIG] 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
      TimeSlotted Channel Hopping (TSCH) and an architecture [RFC9030]
      that enables RAW on a shared MAC.

   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 draft extends the "Deterministic Networking use-cases" document
   [RFC8578] and describes several additional use-cases which 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" use-case, as the
   "Cellular Radio" is mostly dedicated to the (wired) transport part of
   a Radio Access Network (RAN).  Whereas the "Wireless for Industrial
   Applications" use-case certainly covers an area of interest for RAW,
   it is limited to 6TiSCH, and thus its scope is narrower than the use-
   cases described next in this document.

2.  Aeronautical Communications

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

2.1.  Problem Statement

   Up to 2020, civil air traffic has been growing constantly at a
   compound rate of 5.8% per year [ACI19] and despite the severe impact
   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 [KEAV20] [FAA20] calling for suitable new digital approaches

Bernardos, et al.        Expires 27 August 2022                 [Page 5]
Internet-Draft           RAW use-cases scenarios           February 2022

   such as AeroMACS for airport communications, SatCOM for remote
   domains, and LDACS as long-range terrestrial aeronautical
   communications system.  Making the frequency spectrum's usage more
   efficient a 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 the L-band Digital Aeronautical
   Communications System (LDACS) [ICAO18] [I-D.ietf-raw-ldacs].

2.2.  Specifics

   During the creation process of new communications 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:

Bernardos, et al.        Expires 27 August 2022                 [Page 6]
Internet-Draft           RAW use-cases scenarios           February 2022

    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
   transceiver                     based                             GS
   transceiver

     Figure 1: The Future Communication Infrastructure (FCI): AeroMACS
      for APT/TMA domain, LDACS A/G for TMA/ENR domain, LDACS A/G for
            ENR/ORP domain, SatCOM for ORP domain communications

2.3.  Challenges

   This paradigm change brings a lot of new challenges:

   *  Efficiency: It is necessary to keep latency, time and data
      overhead (routing, security) of new aeronautical datalinks at a
      minimum.

Bernardos, et al.        Expires 27 August 2022                 [Page 7]
Internet-Draft           RAW use-cases scenarios           February 2022

   *  Modularity: Systems in avionics usually operate up to 30 years,
      thus solutions must be modular, easily adaptable and updatable.

   *  Interoperability: All 192 members of the international Civil
      Aviation Organization (ICAO) must be able to use these solutions.

   *  Dynamicity: the communication infrastructure needs to accomodate
      mobile devices (airplanes) that move extremely fast.

2.4.  The Need for Wireless

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

2.5.  Requirements for RAW

   Different safety levels need to be supported, from extremely safety
   critical ones requiring low latency, such as a WAKE warning - a
   warning that two aircraft come dangerously close to each other - and
   high resiliency, to less safety critical ones requiring low-medium
   latency for services such as WXGRAPH - graphical weather data.

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

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

Bernardos, et al.        Expires 27 August 2022                 [Page 8]
Internet-Draft           RAW use-cases scenarios           February 2022

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 it is important is to keep the overall latency bounded under a
   certain threshold.  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 decrease
   significantly the cost for maintaining the attractions.  Such
   deployment is a mix between industrial automation (i.e., Smart
   Factories) and multimedia entertainment applications.

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

   *  Emergency: safety has to be preserved, and must stop the
      attraction when a failure is detected.

   *  Video: augmented and virtual realities are integrated in the
      attraction.  Wearable mobile devices (e.g., glasses, virtual
      reality headset) need to offload one part of the processing tasks.

   *  Real-time interactions: visitors may interact with an attraction,
      like in a real-time video game.  The visitors may virtually
      interact with their environment, triggering actions in the real
      world (through actuators) [KOB12].

   *  Geolocation: visitors are tracked with a personal wireless tag so
      that their user experience is improved.

   *  Predictive maintenance: statistics are collected to predict the
      future failures, or to compute later more complex statistics about
      the attraction's usage, the downtime or its popularity for
      example.

3.2.  Specifics

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

Bernardos, et al.        Expires 27 August 2022                 [Page 9]
Internet-Draft           RAW use-cases scenarios           February 2022

   *  Local area: the sensors and actuators controlling the attractions
      are co-located.  Control loops trigger only local traffic, with a
      small end-to-end delay, typically inferior to 10 ms, like
      classical industrial systems [IEEE80211-RT-TIG].

   *  Wearable mobile devices are free to move in the park.  They
      exchange traffic locally (identification, personalization,
      multimedia) or globally (billing, child tracking).

   *  Computationally intensive applications offload some tasks.  Edge
      computing seems an efficient way to implement real-time
      applications with offloading.  Some non-time-critical tasks may
      rather use the cloud (predictive maintenance, marketing).

3.3.  The Need for Wireless

   Amusement parks cover large areas, and a global interconnection would
   require a huge length of cables.  Wireless also increases the
   reconfigurability, enabling to update an attraction at a lower cost.
   The frequent renewal helps to increase the customer loyalty.

   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 to 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 presence of
   mobile devices.  While the [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,
   able to guarantee end-to-end requirements across heterogeneous
   technologies, with strict SLA requirements.

Bernardos, et al.        Expires 27 August 2022                [Page 10]
Internet-Draft           RAW use-cases scenarios           February 2022

   Nowadays, long-range wireless transmissions are used mostly for best-
   effort traffic.  On the contrary, [IEEE802.1TSN] is used for critical
   flows using Ethernet devices.  However, IP enabled technology is
   required to interconnect large areas, independent of the PHY and MAC
   layers.

   It is expected that several different technologies (long vs. short
   range) are deployed, which have to cohabit in the same area.  Thus,
   we need to provide layer-3 mechanisms able to exploit multiple co-
   interfering technologies.

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 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 drinking soda.  Control loops in
   the Process Control industry operate at a very low rate, typically
   four times per second.  Factory Automation, on the other hand, deals
   with discrete goods such as individual automobile parts, and requires
   faster loops, in the order of milliseconds.  Motion control that
   monitors dynamic activities may require even faster rates in the
   order of and below the millisecond.  Finally, some industries exhibit
   hybrid behaviors, like canned soup that will start as a process
   industry while mixing the food and then operate as a discrete
   manufacturing when putting the final product in cans and shipping
   them.

Bernardos, et al.        Expires 27 August 2022                [Page 11]
Internet-Draft           RAW use-cases scenarios           February 2022

   In all those cases, a packet must flow reliably between the sensor
   and the PLC, be processed by the PLC, and sent to the actuator within
   the control loop period.  In some particular use-cases that inherit
   from analog operations, jitter might also alter the operation of the
   control loop.  A rare packet loss is usually admissible, but
   typically 4 losses 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
   [I-D.ietf-raw-industrial-requirements].

4.2.2.  Unmeasured Data

   A secondary use-case deals with monitoring and diagnostics.  This so-
   called unmeasured data is essential to improve the performances of a
   production line, e.g., by optimizing real-time processing or
   maintenance windows using Machine Learning predictions.  For the lack
   of wireless technologies, some specific industries such as Oil and
   Gas have been using serial cables, literally by the millions, to
   perform their process optimization over the previous decades.  But
   few industries would afford the associated cost and the Holy Grail 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.  But unmeasured 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 carpeted floor over IP, which
   means the potential for a security breach via the interconnection of
   the Operational Technology (OT) network with the Internet technology
   (IT) network and possibly enable a rogue access.

4.3.  The Need for Wireless

   Ethernet cables used on a robot arm are prone to breakage after a few
   thousands of 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.

Bernardos, et al.        Expires 27 August 2022                [Page 12]
Internet-Draft           RAW use-cases scenarios           February 2022

   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, every valve and fan that are deployed on the
   factory floor.  It may also help detect and prevent a failure that
   could impact the production, like the degradation (vibration) of a
   cooling fan on the ceiling.  IEEE Std. 802.15.4 Time-Slotted Channel
   Hopping (TSCH) [RFC7554] is a promising technology for that purpose,
   mostly if the scheduled operations enable to use the same network by
   asynchronous and deterministic flows in parallel.

4.4.  Requirements for RAW

   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 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 the course of the recent years, major Industrial Protocols
   (e.g., [ODVA] with EtherNet/IP [EIP] and [PROFINET]) have been
   migrating towards Ethernet and IP.  In order to unleash the full
   power of the IP hourglass model, it should be possible to deploy any
   application over any network that has the physical capacity to
   transport the industrial flow, regardless of the MAC/PHY technology,
   wired or wireless, and across technologies.  RAW mechanisms should be
   able to setup a Track over a wireless access segment and a wired or
   wireless backbone to report both sensor data and critical monitoring
   within a bounded latency and maintain the high reliability of teh
   flows over time.  It is also important to ensure that RAW solutions
   are interoperable with existing wireless solutions in place, and with
   legacy equipment which capabilities can be extended using
   retrofitting.  Maintainability, as a broader concept than reliability
   is also important in industrial scenarios [MAR19].

Bernardos, et al.        Expires 27 August 2022                [Page 13]
Internet-Draft           RAW use-cases scenarios           February 2022

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, thus are
   latency critical, but can be managed end-to-end, and therefore DetNet
   mechanisms can be applied in conjunction with RAW mechanisms.

5.  Pro Audio and Video

5.1.  use-case Description

   Many devices support audio and video streaming 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 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 Blue-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

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

5.2.2.  Synchronized Stream Playback

   In the context of ProAV, 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.

Bernardos, et al.        Expires 27 August 2022                [Page 14]
Internet-Draft           RAW use-cases scenarios           February 2022

5.3.  The Need for Wireless

   The 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.

5.4.  Requirements for RAW

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

   Content delivery with bounded (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, and therefore,
   depending on the actual requirements, this can be considered as
   latency critical.  However, the most critical requirement of this
   use-case is reliability, by the network providing redundancy.  Note
   that in many cases, wireless is only present in the access, where RAW
   mechanisms could be applied, but other wired segments are also
   involved (like the Internet), and therefore latency cannot be
   guaranteed.

6.  Wireless Gaming

6.1.  use-case Description

   The gaming industry includes [IEEE80211RTA] real-time mobile gaming,
   wireless console gaming and cloud gaming.  For RAW, wireless console
   gaming is the most relevant one.  We next summarize the three:

   *  Real-time Mobile Gaming: Different from traditional games, real
      time mobile gaming is very sensitive to network latency and
      stability.  The mobile game can connect multiple players together
      in a single game session and exchange data messages between game
      server and connected players.  Real-time means the feedback should

Bernardos, et al.        Expires 27 August 2022                [Page 15]
Internet-Draft           RAW use-cases scenarios           February 2022

      present on screen as users operate in game.  For good game
      experience, the end-to-end (E2E) latency plus game servers
      processing time must be the same for all players and should not be
      noticeable as the game is played.

   *  Wireless Console Gaming: Playing online on a console has 2 types
      of internet connectivity, which is either wired or Wi-Fi.  Most of
      the gaming consoles today support Wi-Fi 5.  But Wi-Fi has an
      especially bad reputation among the gaming community.  The main
      reasons are high latency, lag spikes, and jitter.

   *  Cloud Gaming: The cloud gaming requires low latency capability as
      the user commands in a game session need to be sent back to the
      cloud server, the cloud server would update game context depending
      on the received commands, and the cloud server would render the
      picture/video to be displayed at user devices and stream the
      picture/video content to the user devices.  User devices might
      very likely be connected wirelessly.

6.2.  Specifics

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

   *  Intra BSS latency is less than 5 ms.

   *  Jitter variance is less than 2 ms.

   *  Packet loss is less than 0.1 percent.

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 (FRE) can be explored to address
      congestion and reliability problems present in wireless networks.

Bernardos, et al.        Expires 27 August 2022                [Page 16]
Internet-Draft           RAW use-cases scenarios           February 2022

   *  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/closing of queues that
      share a common egress port within an Ethernet switch.  A scheduler
      defines the times when each queue opens or close, therefore
      eliminating congestion and ensuring that frames are delivered
      within the expected latency bounds.  Note thought, that while this
      requirement needs to be signalled by RAW mechanisms, it would be
      actually served by the lower layer.

   *  Dual/multiple link: due to the 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
      maybe 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's requirements of
   this use-case might be considered as latency critical due to the need
   of bounded latency.  But note that in most of these scenarios, part
   of the communication path is not wireless and DetNet mechanisms
   cannot be applied easily (e.g., when the public Internet is
   involved), and therefore in these cases, reliability is the critical
   requirement.

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.

Bernardos, et al.        Expires 27 August 2022                [Page 17]
Internet-Draft           RAW use-cases scenarios           February 2022

   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), support of emergency situations, and even
   transportation of small goods (e.g., medicine in rural areas).

   Similarly to UAVs, other time of vehicles (such as cars) can also
   travel in platoons.  Most of the considerations made for UAVs in this
   section apply to vehicle-to-vehicle (V2V) scenarios.

   UAVs/vehicles typically have various forms of wireless connectivity:

   *  Cellular: for communication with the control center, for remote
      maneuvering as well as monitoring of the drone;

   *  IEEE 802.11: for inter-drone communications (i.e., platooning) and
      providing connectivity to other devices (i.e., acting as Access
      Point).

   Note that autonomous cars share many of the characteristics of the
   aforemention UAV case, and therefore it is of interest for RAW.

7.2.  Specifics

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

   Remote maneuvering of a drone might be performed over a cellular
   network in some cases, however, there are situations that need very
   low latency and deterministic behavior of the connectivity.  Examples
   involve platooning of drones or share of computing resources among
   drones (like, a drone offload 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 by the UAVs themselves,
   requiring self-configuration capabilities.

Bernardos, et al.        Expires 27 August 2022                [Page 18]
Internet-Draft           RAW use-cases scenarios           February 2022

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

   When a given service is decomposed into functions -- hosted at
   different UAVs -- 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 local the processing operations that are
   critical and would demand an ultra-low latency communication to be
   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), inter-connected via an access
   network to a network's edge device or a data center.  The robots are
   connected to the edge so complex computational activities are not
   executed locally at the robots but offloaded to the edge.  This
   brings additional flexibility in the type of tasks that the robots
   do, as well as reducing the costs of robot manufacturing (due to
   their lower complexity), and enabling complex tasks involving
   coordination among robots (that can be more easily performed if
   robots are centrally controlled).

   Simple examples of the use of multiples robots are cleaning, video
   surveillance, 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 (like a data
   center).  That enables easy synchronization, scalable solution, and
   on-demand option to create flexible fleet of robots.

   Robots would have various forms of wireless connectivity:

   *  IEEE 802.11: for connection to the edge and also inter-robot
      communications (i.e., for coordinated actions).

   *  Cellular: as an additional communication link to the edge, though
      primarily as backup, since ultra-low latency is needed.

Bernardos, et al.        Expires 27 August 2022                [Page 19]
Internet-Draft           RAW use-cases scenarios           February 2022

8.2.  Specifics

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

   Robot control is an activity requiring very low latency 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 -- hosted at
   different robots -- chained, each link connecting two given functions
   would have a well-defined set of requirements (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.  Emergencies: Instrumented emergency vehicle

9.1.  use-case Description

   An instrumented ambulance would be one that has a LAN to which are
   connected these end systems such as:

   *  vital signs sensors attached to the casualty in the ambulance.
      Relay medical data to hospital emergency room,

   *  radio-navigation sensor to relay position data to various
      destinations including dispatcher,

   *  voice communication for ambulance attendant (like to consult with
      ER doctor), and

Bernardos, et al.        Expires 27 August 2022                [Page 20]
Internet-Draft           RAW use-cases scenarios           February 2022

   *  voice communication between driver and dispatcher.

   The LAN needs to be routed through radio-WANs to complete the inter-
   network linkage.

9.2.  Specifics

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

   *  A dispatching system,

   *  a cellphone for the attendant,

   *  a special purpose telemetering system for medical data,

   *  etc.

   This redundancy of systems, because of its stove-piping, 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 at the ambulance itself (local traffic),
   at a near edge cloud or at the general Internet/cloud.

9.3.  The Need for Wireless

   Local traffic between the first responders/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:

   *  High availability of the inter-network is required.

   *  The inter-network needs to operate in damaged state (e.g. during
      an earthquake aftermath, heavy weather, wildfire, etc.).  In
      addition to continuity of operations, rapid restore is a needed
      characteristic.

Bernardos, et al.        Expires 27 August 2022                [Page 21]
Internet-Draft           RAW use-cases scenarios           February 2022

   *  E2E security, both authenticity and confidentiality, is required
      of traffic.  All data needs to be authenticated; some like medical
      needs to be confidential.

   *  The radio-WAN has characteristics similar to cellphone -- the
      vehicle will travel from one radio footprint to another.

9.4.1.  Non-latency critical considerations

   In this case, all applications identified do not require latency
   critical communication, but do need of 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.  Whereas some use-cases are latency-
   critical, there are also several applications that are non-latency
   critical, but that do pose strict reliability and availability
   requirements.  Future revisions of this document will include
   specific text devoted to highlight this non-latency critical
   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 Deterministic Networking, which are
   generally applicable also to RAW.

13.  Acknowledgments

   Nils Maeurer, Thomas Graeupl and Corinna Schmitt have contributed
   significantly to this document, providing input for the Aeronautical
   communications section.  Rex Buddenberg has also contributed to the
   document, providing input to the Emergency: instrumented emergency
   vehicle section.

Bernardos, et al.        Expires 27 August 2022                [Page 22]
Internet-Draft           RAW use-cases scenarios           February 2022

   The authors would like to thank Toerless Eckert, Xavi Vilajosana
   Guillen, Rute Sofia and Corinna Schmitt for their valuable comments
   on previous versions of this document.

   The work of Carlos J.  Bernardos in this draft has been partially
   supported by the H2020 5Growth (Grant 856709) and 5G-DIVE projects
   (Grant 859881), and UNICO 5G I+D 6G-DATADRIVEN-04 project.

14.  References

14.1.  Normative References

   [I-D.ietf-raw-technologies]
              Thubert, P., Cavalcanti, D., Vilajosana, X., Schmitt, C.,
              and J. Farkas, "Reliable and Available Wireless
              Technologies", Work in Progress, Internet-Draft, draft-
              ietf-raw-technologies-05, 2 February 2022,
              <https://www.ietf.org/archive/id/draft-ietf-raw-
              technologies-05.txt>.

14.2.  Informative References

   [ACI19]    Airports Council International (ACI), "Annual World
              Aitport Traffic Report 2019", November 2019,
              <https://store.aci.aero/product/annual-world-airport-
              traffic-report-2019/>.

   [DISNEY15] Wired, "Disney's $1 Billion Bet on a Magical Wristband",
              March 2015,
              <https://www.wired.com/2015/03/disney-magicband/>.

   [EIP]      http://www.odva.org/, "EtherNet/IP provides users with the
              network tools to deploy standard Ethernet technology (IEEE
              802.3 combined with the TCP/IP Suite) for industrial
              automation applications while enabling Internet and
              enterprise connectivity data anytime, anywhere.",
              <http://www.odva.org/Portals/0/Library/
              Publications_Numbered/
              PUB00138R3_CIP_Adv_Tech_Series_EtherNetIP.pdf>.

   [FAA20]    U.S. Department of Transportation Federal Aviation
              Administration (FAA), "Next Generation Air Transportation
              System", 2019, <https://www.faa.gov/nextgen/>.

   [I-D.ietf-raw-industrial-requirements]
              Sofia, R. C., Kovatsch, M., and P. M. Mendes,
              "Requirements for Reliable Wireless Industrial Services",
              Work in Progress, Internet-Draft, draft-ietf-raw-

Bernardos, et al.        Expires 27 August 2022                [Page 23]
Internet-Draft           RAW use-cases scenarios           February 2022

              industrial-requirements-00, 10 December 2021,
              <https://www.ietf.org/archive/id/draft-ietf-raw-
              industrial-requirements-00.txt>.

   [I-D.ietf-raw-ldacs]
              Maeurer, N., Graeupl, T., and C. Schmitt, "L-band Digital
              Aeronautical Communications System (LDACS)", Work in
              Progress, Internet-Draft, draft-ietf-raw-ldacs-09, 22
              October 2021, <https://www.ietf.org/archive/id/draft-ietf-
              raw-ldacs-09.txt>.

   [IAC20]    Iacus, S.M., Natale, F., Santamaria, C., Spyratos, S., and
              V. Michele, "Estimating and projecting air passenger
              traffic during the COVID-19 coronavirus outbreak and its
              socio- economic impact", Safety Science 129 (2020)
              104791 , 2020.

   [IAT20]    International Air Transport Association (IATA), "Economic
              Performance of the Airline Industry", November 2020,
              <https://www.iata.org/en/iata-repository/publications/
              economic-reports/airline-industry-economic-performance---
              november-2020---report/>.

   [ICAO18]   International Civil Aviation Organization (ICAO), "L-Band
              Digital Aeronautical Communication System (LDACS)",
              International Standards and Recommended Practices Annex 10
              - Aeronautical Telecommunications, Vol. III -
              Communication Systems , 2018.

   [IEEE802.1TSN]
              IEEE standard for Information Technology, "IEEE
              802.1AS-2011 - IEEE Standard for Local and Metropolitan
              Area Networks - Timing and Synchronization for Time-
              Sensitive Applications in Bridged Local Area Networks".

   [IEEE80211-RT-TIG]
              IEEE, "IEEE 802.11 Real Time Applications TIG Report",
              November 2018,
              <http://www.ieee802.org/11/Reports/rtatig_update.htm>.

   [IEEE80211BE]
              Cavalcanti, D. and G. Venkatesan, "802.1 TSN over 802.11
              with updates from developments in 802.11be", IEEE plenary
              meeting , November 2020,
              <https://www.ieee802.org/1/files/public/docs2020/new-
              Cavalcanti-802-1TSN-over-802-11-1120-v02.pdf>.

Bernardos, et al.        Expires 27 August 2022                [Page 24]
Internet-Draft           RAW use-cases scenarios           February 2022

   [IEEE80211RTA]
              IEEE standard for Information Technology, "IEEE 802.11
              Real Time Applications TIG Report", November 2018.

   [ISA100]   ISA/ANSI, "ISA100, Wireless Systems for Automation",
              <https://www.isa.org/isa100/>.

   [KEAV20]   T. Keaveney and C. Stewart, "Single European Sky ATM
              Research Joint Undertaking", 2019,
              <https://www.sesarju.eu/>.

   [KOB12]    Kober, J., Glisson, M., and M. Mistry, "Playing catch and
              juggling with a humanoid robot.", 2012,
              <https://doi.org/10.1109/HUMANOIDS.2012.6651623>.

   [MAR19]    Martinez, B., Cano, C., and X. Vilajosana, "A Square Peg
              in a Round Hole: The Complex Path for Wireless in the
              Manufacturing Industry", 2019,
              <https://ieeexplore.ieee.org/document/8703476>.

   [ODVA]     http://www.odva.org/, "The organization that supports
              network technologies built on the Common Industrial
              Protocol (CIP) including EtherNet/IP.".

   [PLA14]    Plass, S., Hermenier, R., Luecke, O., Gomez Depoorter, D.,
              Tordjman, T., Chatterton, M., Amirfeiz, M., Scotti, S.,
              Cheng, Y.J., Pillai, P., Graeupl, T., Durand, F., Murphy,
              K., Marriott, A., and A. Zaytsev, "Flight Trial
              Demonstration of Seamless Aeronautical Networking", IEEE
              Communications Magazine, vol. 52, no. 5 , May 2014.

   [PROFINET] http://us.profinet.com/technology/profinet/, "PROFINET is
              a standard for industrial networking in automation.",
              <http://us.profinet.com/technology/profinet/>.

   [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, May 2015,
              <https://www.rfc-editor.org/info/rfc7554>.

   [RFC8557]  Finn, N. and P. Thubert, "Deterministic Networking Problem
              Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019,
              <https://www.rfc-editor.org/info/rfc8557>.

   [RFC8578]  Grossman, E., Ed., "Deterministic Networking Use Cases",
              RFC 8578, DOI 10.17487/RFC8578, May 2019,
              <https://www.rfc-editor.org/info/rfc8578>.

Bernardos, et al.        Expires 27 August 2022                [Page 25]
Internet-Draft           RAW use-cases scenarios           February 2022

   [RFC8655]  Finn, N., Thubert, P., Varga, B., and J. Farkas,
              "Deterministic Networking Architecture", RFC 8655,
              DOI 10.17487/RFC8655, October 2019,
              <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, May 2021,
              <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, June
              2021, <https://www.rfc-editor.org/info/rfc9055>.

Authors' Addresses

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

   Georgios Z. 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

Bernardos, et al.        Expires 27 August 2022                [Page 26]
Internet-Draft           RAW use-cases scenarios           February 2022

   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/

Bernardos, et al.        Expires 27 August 2022                [Page 27]