< draft-ietf-raw-use-cases-02.txt   draft-ietf-raw-use-cases-03.txt >
RAW G. Papadopoulos RAW G. Papadopoulos
Internet-Draft IMT Atlantique Internet-Draft IMT Atlantique
Intended status: Standards Track P. Thubert Intended status: Standards Track P. Thubert
Expires: January 13, 2022 Cisco Expires: April 23, 2022 Cisco
F. Theoleyre F. Theoleyre
CNRS CNRS
CJ. Bernardos CJ. Bernardos, Ed.
UC3M UC3M
July 12, 2021 October 20, 2021
RAW use cases RAW use cases
draft-ietf-raw-use-cases-02 draft-ietf-raw-use-cases-03
Abstract Abstract
The wireless medium presents significant specific challenges to The wireless medium presents significant specific challenges to
achieve properties similar to those of wired deterministic networks. achieve properties similar to those of wired deterministic networks.
At the same time, a number of use cases cannot be solved with wires At the same time, a number of use cases cannot be solved with wires
and justify the extra effort of going wireless. This document and justify the extra effort of going wireless. This document
presents wireless use cases demanding reliable and available presents wireless use cases demanding reliable and available
behavior. behavior.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 13, 2022. This Internet-Draft will expire on April 23, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 16
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Aeronautical Communications . . . . . . . . . . . . . . . . . 5 2. Aeronautical Communications . . . . . . . . . . . . . . . . . 5
2.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 5 2.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 5
2.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Challenges . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Challenges . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. The Need for Wireless . . . . . . . . . . . . . . . . . . 7 2.4. The Need for Wireless . . . . . . . . . . . . . . . . . . 7
2.5. Requirements for RAW . . . . . . . . . . . . . . . . . . 7 2.5. Requirements for RAW . . . . . . . . . . . . . . . . . . 7
3. Amusement Parks . . . . . . . . . . . . . . . . . . . . . . . 7 2.5.1. Non-latency critical considerations . . . . . . . . . 8
3.1. Use Case Description . . . . . . . . . . . . . . . . . . 7 3. Amusement Parks . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Use Case Description . . . . . . . . . . . . . . . . . . 8
3.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 8 3.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 9
3.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 9 3.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 9
4. Wireless for Industrial Applications . . . . . . . . . . . . 9 3.4.1. Non-latency critical considerations . . . . . . . . . 10
4.1. Use Case Description . . . . . . . . . . . . . . . . . . 9 4. Wireless for Industrial Applications . . . . . . . . . . . . 10
4.1. Use Case Description . . . . . . . . . . . . . . . . . . 10
4.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Control Loops . . . . . . . . . . . . . . . . . . . . 10 4.2.1. Control Loops . . . . . . . . . . . . . . . . . . . . 10
4.2.2. Unmeasured Data . . . . . . . . . . . . . . . . . . . 10 4.2.2. Unmeasured Data . . . . . . . . . . . . . . . . . . . 11
4.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 11 4.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 11
4.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 11 4.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 12
5. Pro Audio and Video . . . . . . . . . . . . . . . . . . . . . 12 4.4.1. Non-latency critical considerations . . . . . . . . . 12
5.1. Use Case Description . . . . . . . . . . . . . . . . . . 12 5. Pro Audio and Video . . . . . . . . . . . . . . . . . . . . . 13
5.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Use Case Description . . . . . . . . . . . . . . . . . . 13
5.2.1. Uninterrupted Stream Playback . . . . . . . . . . . . 12 5.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2.2. Synchronized Stream Playback . . . . . . . . . . . . 12 5.2.1. Uninterrupted Stream Playback . . . . . . . . . . . . 13
5.2.2. Synchronized Stream Playback . . . . . . . . . . . . 13
5.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 13 5.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 13
5.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 13 5.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 14
6. Wireless Gaming . . . . . . . . . . . . . . . . . . . . . . . 13 5.4.1. Non-latency critical considerations . . . . . . . . . 14
6.1. Use Case Description . . . . . . . . . . . . . . . . . . 13 6. Wireless Gaming . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Use Case Description . . . . . . . . . . . . . . . . . . 14
6.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 14 6.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 15
6.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 14 6.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 15
7. UAV and V2V platooning and control . . . . . . . . . . . . . 15 6.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 15
7.1. Use Case Description . . . . . . . . . . . . . . . . . . 15 6.4.1. Non-latency critical considerations . . . . . . . . . 16
7.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 15 7. UAV and V2V platooning and control . . . . . . . . . . . . . 16
7.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 16 7.1. Use Case Description . . . . . . . . . . . . . . . . . . 16
7.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 16 7.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Edge Robotics control . . . . . . . . . . . . . . . . . . . . 16 7.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 17
8.1. Use Case Description . . . . . . . . . . . . . . . . . . 16 7.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 17
8.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 17 7.4.1. Non-latency critical considerations . . . . . . . . . 17
8.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 17 8. Edge Robotics control . . . . . . . . . . . . . . . . . . . . 17
8.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 17 8.1. Use Case Description . . . . . . . . . . . . . . . . . . 17
9. Emergencies: Instrumented emergency vehicle . . . . . . . . . 17 8.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Use Case Description . . . . . . . . . . . . . . . . . . 17 8.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 18
9.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 18 8.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 18
9.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 18 8.4.1. Non-latency critical considerations . . . . . . . . . 19
9.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 18 9. Emergencies: Instrumented emergency vehicle . . . . . . . . . 19
10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Use Case Description . . . . . . . . . . . . . . . . . . 19
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9.2. Specifics . . . . . . . . . . . . . . . . . . . . . . . . 19
12. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9.3. The Need for Wireless . . . . . . . . . . . . . . . . . . 20
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 9.4. Requirements for RAW . . . . . . . . . . . . . . . . . . 20
14. Informative References . . . . . . . . . . . . . . . . . . . 20 9.4.1. Non-latency critical considerations . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
12. Security Considerations . . . . . . . . . . . . . . . . . . . 21
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
14. Informative References . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
Based on time, resource reservation, and policy enforcement by Based on time, resource reservation, and policy enforcement by
distributed shapers, Deterministic Networking provides the capability distributed shapers, Deterministic Networking provides the capability
to carry specified unicast or multicast data streams for real-time to carry specified unicast or multicast data streams for real-time
applications with extremely low data loss rates and bounded latency, applications with extremely low data loss rates and bounded latency,
so as to support time-sensitive and mission-critical applications on so as to support time-sensitive and mission-critical applications on
a converged enterprise infrastructure. a converged enterprise infrastructure.
skipping to change at page 4, line 30 skipping to change at page 4, line 38
So far, Open Standards for Deterministic Networking have prevalently So far, Open Standards for Deterministic Networking have prevalently
been focused on wired media, with Audio/Video Bridging (AVB) and Time been focused on wired media, with Audio/Video Bridging (AVB) and Time
Sensitive Networking (TSN) at the IEEE and DetNet [RFC8655] at the Sensitive Networking (TSN) at the IEEE and DetNet [RFC8655] at the
IETF. But wires cannot be used in a number of cases, including IETF. But wires cannot be used in a number of cases, including
mobile or rotating devices, rehabilitated industrial buildings, mobile or rotating devices, rehabilitated industrial buildings,
wearable or in-body sensory devices, vehicle automation and wearable or in-body sensory devices, vehicle automation and
multiplayer gaming. multiplayer gaming.
Purpose-built wireless technologies such as [ISA100], which Purpose-built wireless technologies such as [ISA100], which
incorporates IPv6, were developped and deployed to cope for the lack incorporates IPv6, were developed and deployed to cope for the lack
of open standards, but they yield a high cost in OPEX and CAPEX and of open standards, but they yield a high cost in OPEX and CAPEX and
are limited to very few industries, e.g., process control, concert are limited to very few industries, e.g., process control, concert
instruments or racing. instruments or racing.
This is now changing [I-D.thubert-raw-technologies]: This is now changing [I-D.thubert-raw-technologies]:
o IMT-2020 has recognized Ultra-Reliable Low-Latency Communication o IMT-2020 has recognized Ultra-Reliable Low-Latency Communication
(URLLC) as a key functionality for the upcoming 5G. (URLLC) as a key functionality for the upcoming 5G.
o IEEE 802.11 has identified a set of real-applications o IEEE 802.11 has identified a set of real-applications
skipping to change at page 7, line 21 skipping to change at page 7, line 29
2.4. The Need for Wireless 2.4. The Need for Wireless
In a high mobility environment such as aviation, the envisioned In a high mobility environment such as aviation, the envisioned
solutions to provide worldwide coverage of data connections with in- solutions to provide worldwide coverage of data connections with in-
flight aircraft require a multi-system, multi-link, multi-hop flight aircraft require a multi-system, multi-link, multi-hop
approach. Thus air, ground and space-based datalink providing approach. Thus air, ground and space-based datalink providing
technologies will have to operate seamlessly together to cope with technologies will have to operate seamlessly together to cope with
the increasing needs of data exchange between aircraft, air traffic the increasing needs of data exchange between aircraft, air traffic
controller, airport infrastructure, airlines, air network service controller, airport infrastructure, airlines, air network service
providers (ANSPs) and so forth. Thus, making use of wireless providers (ANSPs) and so forth. Thus, making use of wireless
technologies is a MUST in tackling this enormous need for a worldwide technologies is a must in tackling this enormous need for a worldwide
digital aeronautical datalink infrastructure. digital aeronautical datalink infrastructure.
2.5. Requirements for RAW 2.5. Requirements for RAW
Different safety levels need to be supported, from extremely safety Different safety levels need to be supported, from extremely safety
critical ones requiring low latency, such as a WAKE warning - a critical ones requiring low latency, such as a WAKE warning - a
warning that two aircraft come dangerously close to each other - and warning that two aircraft come dangerously close to each other - and
high resiliency, to less safety critical ones requiring low-medium high resiliency, to less safety critical ones requiring low-medium
latency for services such as WXGRAPH - graphical weather data. latency for services such as WXGRAPH - graphical weather data.
skipping to change at page 7, line 43 skipping to change at page 8, line 5
provide comparatively small data rates in the order of kbit/s. provide comparatively small data rates in the order of kbit/s.
Policy needs to be supported when selecting data links. The focus of Policy needs to be supported when selecting data links. The focus of
RAW here should be on the selectors, responsible for the track a RAW here should be on the selectors, responsible for the track a
packet takes to reach its end destination. This would minimize the packet takes to reach its end destination. This would minimize the
amount of routing information that has to travel inside the network amount of routing information that has to travel inside the network
because of precomputed routing tables with the selector being because of precomputed routing tables with the selector being
responsible for choosing the most appropriate option according to responsible for choosing the most appropriate option according to
policy and safety. policy and safety.
2.5.1. Non-latency critical considerations
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. Amusement Parks
3.1. Use Case Description 3.1. Use Case Description
The digitalization of Amusement Parks is expected to decrease The digitalization of Amusement Parks is expected to decrease
significantly the cost for maintaining the attractions. Such significantly the cost for maintaining the attractions. Such
deployment is a mix between industrial automation (aka. Smart deployment is a mix between industrial automation (aka. Smart
Factories) and multimedia entertainment applications. Factories) and multimedia entertainment applications.
Attractions may rely on a large set of sensors and actuators, which Attractions may rely on a large set of sensors and actuators, which
skipping to change at page 9, line 41 skipping to change at page 10, line 13
effort traffic. On the contrary, [IEEE802.1TSN] is used for critical effort traffic. On the contrary, [IEEE802.1TSN] is used for critical
flows using Ethernet devices. However, we need an IP enabled flows using Ethernet devices. However, we need an IP enabled
technology to interconnect large areas, independent of the PHY and technology to interconnect large areas, independent of the PHY and
MAC layers. MAC layers.
We expect to deploy several different technologies (long vs. short We expect to deploy several different technologies (long vs. short
range) which have to cohabit in the same area. Thus, we need to range) which have to cohabit in the same area. Thus, we need to
provide layer-3 mechanisms able to exploit multiple co-interfering provide layer-3 mechanisms able to exploit multiple co-interfering
technologies. technologies.
3.4.1. Non-latency critical considerations
While some of the applications in this use case involve control loops
(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. Wireless for Industrial Applications
4.1. Use Case Description 4.1. Use Case Description
A major use case for networking in Industrial environments is the A major use case for networking in Industrial environments is the
control networks where periodic control loops operate between a control networks where periodic control loops operate between a
sensor that measures a physical property such as the temperature of a sensor that measures a physical property such as the temperature of a
fluid, a Programmable Logic Controller (PLC) that decides an action fluid, a Programmable Logic Controller (PLC) that decides an action
such as warm up the mix, and an actuator that performs the required such as warm up the mix, and an actuator that performs the required
action, e.g., inject power in a resistor. action, e.g., inject power in a resistor.
skipping to change at page 12, line 8 skipping to change at page 12, line 36
migrating towards Ethernet and IP. In order to unleash the full migrating towards Ethernet and IP. In order to unleash the full
power of the IP hourglass model, it should be possible to deploy any power of the IP hourglass model, it should be possible to deploy any
application over any network that has the physical capacity to application over any network that has the physical capacity to
transport the industrial flow, regardless of the MAC/PHY technology, transport the industrial flow, regardless of the MAC/PHY technology,
wired or wireless, and across technologies. RAW mechanisms should be wired or wireless, and across technologies. RAW mechanisms should be
able to setup a Track over a wireless access segment such as TSCH and able to setup a Track over a wireless access segment such as TSCH and
a backbone segment such as Ethernet or WI-Fi, to report a sensor data a backbone segment such as Ethernet or WI-Fi, to report a sensor data
or a critical monitoring within a bounded latency. It is also or a critical monitoring within a bounded latency. It is also
important to ensure that RAW solutions are interoperable with important to ensure that RAW solutions are interoperable with
existing wireless solutions in place, and with legacy equipment which existing wireless solutions in place, and with legacy equipment which
capabilities can be extended using retrofitting. Maintanability, as capabilities can be extended using retrofitting. Maintainability, as
a broader concept than reliability is also important in industrial a broader concept than reliability is also important in industrial
scenarios [square-peg]. scenarios [square-peg].
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. Pro Audio and Video
5.1. Use Case Description 5.1. Use Case Description
Many devices support audio and video streaming by employing 802.11 Many devices support audio and video streaming by employing 802.11
wireless LAN. Some of these applications require low latency wireless LAN. Some of these applications require low latency
capability. For instance, when the application provides interactive capability. For instance, when the application provides interactive
play, or when the audio takes plays in real time (i.e. live) for play, or when the audio takes plays in real time (i.e. live) for
public addresses in train stations or in theme parks. public addresses in train stations or in theme parks.
skipping to change at page 13, line 25 skipping to change at page 14, line 16
The network infrastructure needs to support heterogeneous types of The network infrastructure needs to support heterogeneous types of
traffic (including QoS). traffic (including QoS).
Content delivery with bounded (lowest possible) latency. Content delivery with bounded (lowest possible) latency.
The deployed network topology should allow for multipath. This will The deployed network topology should allow for multipath. This will
enable for multiple streams to have different (and multiple) paths enable for multiple streams to have different (and multiple) paths
(tracks) through the network to support redundancy. (tracks) through the network to support redundancy.
5.4.1. Non-latency critical considerations
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 (e.g., the Internet), and therefore latency cannot be
guaranteed.
6. Wireless Gaming 6. Wireless Gaming
6.1. Use Case Description 6.1. Use Case Description
The gaming industry includes [IEEE80211RTA] real-time mobile gaming, The gaming industry includes [IEEE80211RTA] real-time mobile gaming,
wireless console gaming and cloud gaming. For RAW, wireless console wireless console gaming and cloud gaming. For RAW, wireless console
gaming is the most relevant one. We next summarize the three: gaming is the most relevant one. We next summarize the three:
o Real-time Mobile Gaming: Different from traditional games, real o Real-time Mobile Gaming: Different from traditional games, real
time mobile gaming is very sensitive to network latency and time mobile gaming is very sensitive to network latency and
skipping to change at page 15, line 10 skipping to change at page 16, line 13
duplicate and joint. duplicate and joint.
o Admission Control. Congestion is a major cause of high/variable o Admission Control. Congestion is a major cause of high/variable
latency and it is well known that if the traffic load exceeds the latency and it is well known that if the traffic load exceeds the
capability of the link, QoS will be degraded. QoS degradation capability of the link, QoS will be degraded. QoS degradation
maybe acceptable for many applications today, however emerging maybe acceptable for many applications today, however emerging
time-sensitive applications are highly susceptible to increased time-sensitive applications are highly susceptible to increased
latency and jitter. In order to better control QoS, it is latency and jitter. In order to better control QoS, it is
important to control access to the network resources. 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. UAV and V2V platooning and control 7. UAV and V2V platooning and control
7.1. Use Case Description 7.1. Use Case Description
Unmanned Aerial Vehicles (UAVs) are becoming very popular for many Unmanned Aerial Vehicles (UAVs) are becoming very popular for many
different applications, including military and civil use cases. The different applications, including military and civil use cases. The
term drone is commonly used to refer to a UAV. term drone is commonly used to refer to a UAV.
UAVs can be used to perform aerial surveillance activities, traffic UAVs can be used to perform aerial surveillance activities, traffic
monitoring (e.g., Spanish traffic control has recently introduced a monitoring (e.g., Spanish traffic control has recently introduced a
skipping to change at page 15, line 47 skipping to change at page 17, line 15
7.2. Specifics 7.2. Specifics
Some of the use cases/tasks involving drones require coordination Some of the use cases/tasks involving drones require coordination
among drones. Others involve complex compute tasks that might not be among drones. Others involve complex compute tasks that might not be
performed using the limited computing resources that a drone performed using the limited computing resources that a drone
typically has. These two aspects require continuous connectivity typically has. These two aspects require continuous connectivity
with the control center and among drones. with the control center and among drones.
Remote maneuvering of a drone might be performed over a cellular Remote maneuvering of a drone might be performed over a cellular
network in some cased, however, there are situations that need very network in some cased, however, there are situations that need very
low latencies and deterministic behavior of the connectivity. low latency and deterministic behavior of the connectivity. Examples
Examples involve platooning of drones or share of computing resources involve platooning of drones or share of computing resources among
among drones (e.g., a drone offload some function to a neighboring drones (e.g., a drone offload some function to a neighboring drone).
drone).
7.3. The Need for Wireless 7.3. The Need for Wireless
UAVs cannot be connected through any type of wired media, so it is UAVs cannot be connected through any type of wired media, so it is
obvious that wireless is needed. obvious that wireless is needed.
7.4. Requirements for RAW 7.4. Requirements for RAW
The network infrastructure is actually composed by the UAVs The network infrastructure is actually composed by the UAVs
themselves, requiring self-configuration capabilities. themselves, requiring self-configuration capabilities.
Heterogeneous types of traffic need to be supported, from extremely Heterogeneous types of traffic need to be supported, from extremely
critical ones requiring ultra low latency and high resiliency, to critical ones requiring ultra low latency and high resiliency, to
traffic requiring low-medium latency. traffic requiring low-medium latency.
When a given service is decomposed into functions -- hosted at When a given service is decomposed into functions -- hosted at
different drones -- chained, each link connecting two given functions different drones -- chained, each link connecting two given functions
would have a well-defined set of requirements (latency, bandwidth and would have a well-defined set of requirements (latency, bandwidth and
jitter) that have to be met. jitter) that have to 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. Edge Robotics control
8.1. Use Case Description 8.1. Use Case Description
The Edge Robotics scenario consists of several robots, deployed in a The Edge Robotics scenario consists of several robots, deployed in a
given area (for example a shopping mall), inter-connected via an given area (for example a shopping mall), inter-connected via an
access network to a network's edge device or a data center. The access network to a network's edge device or a data center. The
robots are connected to the edge so complex computational activities robots are connected to the edge so complex computational activities
are not executed locally at the robots, but offloaded to the edge. are not executed locally at the robots, but offloaded to the edge.
This brings additional flexibility in the type of tasks that the This brings additional flexibility in the type of tasks that the
skipping to change at page 17, line 6 skipping to change at page 18, line 26
network's edge (e.g., data center). That enables easy network's edge (e.g., data center). That enables easy
synchronization, scalable solution and on-demand option to create synchronization, scalable solution and on-demand option to create
flexible fleet of robots. flexible fleet of robots.
Robots would have various forms of wireless connectivity: Robots would have various forms of wireless connectivity:
o IEEE 802.11: for connection to the edge and also inter-robot o IEEE 802.11: for connection to the edge and also inter-robot
communications (e.g., for coordinated actions). communications (e.g., for coordinated actions).
o Cellular: as an additional communication link to the edge, though o Cellular: as an additional communication link to the edge, though
primarily as backup, since ultra low latencies are needed. primarily as backup, since ultra low latency is needed.
8.2. Specifics 8.2. Specifics
Some of the use cases/tasks involving robots might benefit from Some of the use cases/tasks involving robots might benefit from
decomposition of a service in small functions that are distributed decomposition of a service in small functions that are distributed
and chained among robots and the edge. These require continuous and chained among robots and the edge. These require continuous
connectivity with the control center and among drones. connectivity with the control center and among drones.
Robot control is an activity requiring very low latencies between the Robot control is an activity requiring very low latency between the
robot and the location where the control intelligence resides (which robot and the location where the control intelligence resides (which
might be the edge or another robot). might be the edge or another robot).
8.3. The Need for Wireless 8.3. The Need for Wireless
Deploying robots in scenarios such as shopping malls for the Deploying robots in scenarios such as shopping malls for the
aforementioned applications cannot be done via wired connectivity. aforementioned applications cannot be done via wired connectivity.
8.4. Requirements for RAW 8.4. Requirements for RAW
The network infrastructure needs to support heterogeneous types of The network infrastructure needs to support heterogeneous types of
traffic, from robot control to video streaming. traffic, from robot control to video streaming.
When a given service is decomposed into functions -- hosted at When a given service is decomposed into functions -- hosted at
different robots -- chained, each link connecting two given functions different robots -- chained, each link connecting two given functions
would have a well-defined set of requirements (latency, bandwidth and would have a well-defined set of requirements (latency, bandwidth and
jitter) that have to be met. jitter) that have to be met.
8.4.1. Non-latency critical considerations
This use case might combine multiple communication flows, with some
of them being latency critical (e.g., those related to robot control
tasks). Note that there are still many communication flows (e.g.,
some offloading tasks) that only demand reliability and availability.
9. Emergencies: Instrumented emergency vehicle 9. Emergencies: Instrumented emergency vehicle
9.1. Use Case Description 9.1. Use Case Description
An instrumented ambulance would be one that has a LAN to which are An instrumented ambulance would be one that has a LAN to which are
connected these end systems: connected these end systems:
o vital signs sensors attached to the casualty in the ambulance. o vital signs sensors attached to the casualty in the ambulance.
Relay medical data to hospital emergency room, Relay medical data to hospital emergency room,
o radionavigation sensor to relay position data to various o radio-navigation sensor to relay position data to various
destinations including dispatcher, destinations including dispatcher,
o voice communication for ambulance attendant (e.g. consult with ER o voice communication for ambulance attendant (e.g. consult with ER
doctor), doctor),
o voice communication between driver and dispatcher, o voice communication between driver and dispatcher,
o etc. o etc.
The LAN needs to be routed through radio-WANs to complete the The LAN needs to be routed through radio-WANs to complete the inter-
internetwork linkage. network linkage.
9.2. Specifics 9.2. Specifics
What we have today is multiple communications systems to reach the What we have today is multiple communications systems to reach the
vehicle: vehicle:
o A dispatching system, o A dispatching system,
o a cellphone for the attendant, o a cellphone for the attendant,
o a special purpose telemetering system for medical data, o a special purpose telemetering system for medical data,
o etc. o etc.
This redundancy of systems, because of its stovepiping, does not This redundancy of systems, because of its stove-piping, does not
contribute to availability as a whole. contribute to availability as a whole.
Most of the scenarios involving the use of an instrumented ambulance Most of the scenarios involving the use of an instrumented ambulance
are composed of many different flows, each of them with slightly are composed of many different flows, each of them with slightly
different requirements in terms of reliability and latency. different requirements in terms of reliability and latency.
Destinations might be either at the ambulance itself (local traffic), Destinations might be either at the ambulance itself (local traffic),
at a near edge cloud or at the general Internet/cloud. at a near edge cloud or at the general Internet/cloud.
9.3. The Need for Wireless 9.3. The Need for Wireless
Local traffic between the first responders/ambulance staff and the Local traffic between the first responders/ambulance staff and the
ambulance equipment cannot be doine via wireled connectivity as the ambulance equipment cannot be done via wired connectivity as the
responders perform initial treatment outside of the ambulance. The responders perform initial treatment outside of the ambulance. The
communications from the ambulance to external services has to be communications from the ambulance to external services has to be
wireless as well. wireless as well.
9.4. Requirements for RAW 9.4. Requirements for RAW
We can derive some pertinent requirements from this scenario: We can derive some pertinent requirements from this scenario:
o High availability of the internetwork is required. o High availability of the inter-network is required.
o The internetwork needs to operate in damaged state (e.g. during an o The inter-network needs to operate in damaged state (e.g. during
earthquake aftermath, heavy weather, wildfire, etc.). In addition an earthquake aftermath, heavy weather, wildfire, etc.). In
to continuity of operations, rapid restoral is a needed addition to continuity of operations, rapid restore is a needed
characteristic. characteristic.
o End-to-end security, both authenticity and confidentiality, is o End-to-end security, both authenticity and confidentiality, is
required of traffic. All data needs to be authenticated; some required of traffic. All data needs to be authenticated; some
(such as medical) needs to be confidential. (such as medical) needs to be confidential.
o The radio-WAN has characteristics similar to cellphone -- the o The radio-WAN has characteristics similar to cellphone -- the
vehicle will travel from one radio footprint to another. vehicle will travel from one radio footprint to another.
9.4.1. Non-latency critical considerations
In this case, all applications identified do not require latency
critical communication, but do need of high reliability and
availability.
10. Summary 10. Summary
This document enumarates several use cases and applications that need This document enumerates several use cases and applications that need
RAW technologies, focusing on the requirements from reliability, RAW technologies, focusing on the requirements from reliability,
availability and latency. Whereas some use cases are latency- availability and latency. Whereas some use cases are latency-
critical, there are also a number of applications that are non- critical, there are also a number of applications that are non-
latency critical, but that do pose strict reliability and latency critical, but that do pose strict reliability and
availability requirements. Future revisions of this document will availability requirements. Future revisions of this document will
include specific text devoted to highlight this non-latency critical include specific text devoted to highlight this non-latency critical
requirements. requirements.
11. IANA Considerations 11. IANA Considerations
skipping to change at page 20, line 33 skipping to change at page 22, line 21
Publications_Numbered/ Publications_Numbered/
PUB00138R3_CIP_Adv_Tech_Series_EtherNetIP.pdf>. PUB00138R3_CIP_Adv_Tech_Series_EtherNetIP.pdf>.
[FAA20] U.S. Department of Transportation Federal Aviation [FAA20] U.S. Department of Transportation Federal Aviation
Administration (FAA), "Next Generation Air Transportation Administration (FAA), "Next Generation Air Transportation
System", 2019, <https://www.faa.gov/nextgen/ >. System", 2019, <https://www.faa.gov/nextgen/ >.
[I-D.ietf-raw-ldacs] [I-D.ietf-raw-ldacs]
Maeurer, N., Graeupl, T., and C. Schmitt, "L-band Digital Maeurer, N., Graeupl, T., and C. Schmitt, "L-band Digital
Aeronautical Communications System (LDACS)", draft-ietf- Aeronautical Communications System (LDACS)", draft-ietf-
raw-ldacs-07 (work in progress), February 2021. raw-ldacs-08 (work in progress), May 2021.
[I-D.sofia-raw-industrialreq] [I-D.sofia-raw-industrialreq]
Sofia, R. C., Kovatsch, M., and P. M. Mendes, Sofia, R. C., Kovatsch, M., and P. M. Mendes,
"Requirements for Reliable Wireless Industrial Services", "Requirements for Reliable Wireless Industrial Services",
draft-sofia-raw-industrialreq-00 (work in progress), March draft-sofia-raw-industrialreq-00 (work in progress), March
2021. 2021.
[I-D.thubert-raw-technologies] [I-D.thubert-raw-technologies]
Thubert, P., Cavalcanti, D., Vilajosana, X., Schmitt, C., Thubert, P., Cavalcanti, D., Vilajosana, X., Schmitt, C.,
and J. Farkas, "Reliable and Available Wireless and J. Farkas, "Reliable and Available Wireless
skipping to change at page 23, line 38 skipping to change at page 25, line 25
CNRS CNRS
ICube Lab, Pole API ICube Lab, Pole API
300 boulevard Sebastien Brant - CS 10413 300 boulevard Sebastien Brant - CS 10413
Illkirch 67400 Illkirch 67400
FRANCE FRANCE
Phone: +33 368 85 45 33 Phone: +33 368 85 45 33
Email: theoleyre@unistra.fr Email: theoleyre@unistra.fr
URI: http://www.theoleyre.eu URI: http://www.theoleyre.eu
Carlos J. Bernardos Carlos J. Bernardos (editor)
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
Av. Universidad, 30 Av. Universidad, 30
Leganes, Madrid 28911 Leganes, Madrid 28911
Spain Spain
Phone: +34 91624 6236 Phone: +34 91624 6236
Email: cjbc@it.uc3m.es Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/ URI: http://www.it.uc3m.es/cjbc/
 End of changes. 35 change blocks. 
67 lines changed or deleted 144 lines changed or added

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