Reliable and Available Wireless Technologies
draft-ietf-raw-technologies-05
| Document | Type | Active Internet-Draft (raw WG) | |
|---|---|---|---|
| Authors | Pascal Thubert , Dave Cavalcanti , Xavier Vilajosana , Corinna Schmitt , János Farkas | ||
| Last updated | 2022-05-03 (Latest revision 2022-02-02) | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | WG state | WG Consensus: Waiting for Write-Up | |
| Associated WG milestones |
|
||
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-raw-technologies-05
RAW P. Thubert, Ed.
Internet-Draft Cisco Systems
Intended status: Informational D. Cavalcanti
Expires: 6 August 2022 Intel
X. Vilajosana
Universitat Oberta de Catalunya
C. Schmitt
Research Institute CODE, UniBw M
J. Farkas
Ericsson
2 February 2022
Reliable and Available Wireless Technologies
draft-ietf-raw-technologies-05
Abstract
This document presents a series of recent technologies that are
capable of time synchronization and scheduling of transmission,
making them suitable to carry time-sensitive flows with high
reliability and availability.
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 6 August 2022.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Thubert, et al. Expires 6 August 2022 [Page 1]
Internet-Draft RAW Technologies February 2022
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Towards Reliable and Available Networks . . . . . . . . . . . 6
3.1. Scheduling for Reliability . . . . . . . . . . . . . . . 6
3.2. Diversity for Availability . . . . . . . . . . . . . . . 6
3.3. Benefits of Scheduling . . . . . . . . . . . . . . . . . 7
4. IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Provenance and Documents . . . . . . . . . . . . . . . . 8
4.2. 802.11ax High Efficiency (HE) . . . . . . . . . . . . . . 10
4.2.1. General Characteristics . . . . . . . . . . . . . . . 10
4.2.2. Applicability to deterministic flows . . . . . . . . 12
4.3. 802.11be Extreme High Throughput (EHT) . . . . . . . . . 13
4.3.1. General Characteristics . . . . . . . . . . . . . . . 14
4.3.2. Applicability to deterministic flows . . . . . . . . 14
4.4. 802.11ad and 802.11ay (mmWave operation) . . . . . . . . 16
4.4.1. General Characteristics . . . . . . . . . . . . . . . 16
4.4.2. Applicability to deterministic flows . . . . . . . . 16
5. IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Provenance and Documents . . . . . . . . . . . . . . . . 17
5.2. TimeSlotted Channel Hopping . . . . . . . . . . . . . . . 18
5.2.1. General Characteristics . . . . . . . . . . . . . . . 18
5.2.2. Applicability to Deterministic Flows . . . . . . . . 20
6. 5G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.1. Provenance and Documents . . . . . . . . . . . . . . . . 34
6.2. General Characteristics . . . . . . . . . . . . . . . . . 36
6.3. Deployment and Spectrum . . . . . . . . . . . . . . . . . 38
6.4. Applicability to Deterministic Flows . . . . . . . . . . 39
6.4.1. System Architecture . . . . . . . . . . . . . . . . . 39
6.4.2. Overview of The Radio Protocol Stack . . . . . . . . 41
6.4.3. Radio (PHY) . . . . . . . . . . . . . . . . . . . . . 42
6.4.4. Scheduling and QoS (MAC) . . . . . . . . . . . . . . 44
6.4.5. Time-Sensitive Communications (TSC) . . . . . . . . . 46
6.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 51
7. L-band Digital Aeronautical Communications System . . . . . . 52
7.1. Provenance and Documents . . . . . . . . . . . . . . . . 52
7.2. General Characteristics . . . . . . . . . . . . . . . . . 53
7.3. Deployment and Spectrum . . . . . . . . . . . . . . . . . 54
7.4. Applicability to Deterministic Flows . . . . . . . . . . 55
7.4.1. System Architecture . . . . . . . . . . . . . . . . . 55
7.4.2. Overview of The Radio Protocol Stack . . . . . . . . 55
Thubert, et al. Expires 6 August 2022 [Page 2]
Internet-Draft RAW Technologies February 2022
7.4.3. Radio (PHY) . . . . . . . . . . . . . . . . . . . . . 56
7.4.4. Scheduling, Frame Structure and QoS (MAC) . . . . . . 57
7.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 59
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60
9. Security Considerations . . . . . . . . . . . . . . . . . . . 60
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 60
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60
12. Normative References . . . . . . . . . . . . . . . . . . . . 60
13. Informative References . . . . . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 70
1. Introduction
When used in math or philosophy, the term "deterministic" generally
refers to a perfection where all aspect are understood and
predictable. A perfectly deterministic network would ensure that
every packet reach its destination following a predetermined path
along a predefined schedule to be delivered at the exact due time.
In a real and imperfect world, a deterministic network must highly
predictable, which is a combination of reliability and availability.
* On the one hand the network must be reliable, meaning that it will
perform as expected for all but very few packets and in particular
that it will deliver the packets at the destination within a pre-
defined time interval. .
* On the other hand, the network must be available, meaning that it
has to be resilient to any single outage, independently of the
cause of the failure, be it software, hardware, or a external,
e.g., a physical event impacting the transmission channel.
RAW (Reliable and Available Wireless) is an effort to provide
Deterministic Networking [RFC8557] in networking environments where
at least some segments of a path are wireless. 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. In order to maintain a similar quality of service along a
multihop path that is composed of wired and wireless hops, additional
methods that are specific to wireless must be leveraged to combat the
sources of loss that are also specific to wireless.
Thubert, et al. Expires 6 August 2022 [Page 3]
Internet-Draft RAW Technologies February 2022
Such wireless-specific methods include per-hop retransmissions (HARQ)
and P2MP overhearing whereby multiple receivers are scheduled to
receive the same transmission, which balances the adverse effects of
the transmission losses that are experienced when a radio is used as
pure P2P. Those methods are collectively referred to as Packet
(hybrid) ARQ, Replication, Elimination and Ordering (PAREO) functions
in the "Reliable and Available Wireless Architecture/Framework"
[I-D.ietf-raw-architecture].
2. Terminology
The terms Reliable and Available in the context of RAW require some
discussion; that discussion takes place are in the RAW architecture
[I-D.ietf-raw-architecture]. Summarized definitions are provided
below.
This specification uses several terms that are uncommon on protocols
that ensure best effort transmissions for stochastics flows, such as
found in the traditional Internet and other statistically multiplexed
packet networks.
ARQ: Automatic Repeat Request, enabling an acknowledged transmission
and retries. ARQ is a typical model at Layer-2 on a wireless
medium. It is typically avoided end-to-end on deterministic flows
because it introduces excessive indetermination in latency, but a
limited number of retries within a bounded time may be used over a
wireless link and yet respect end-to-end constraints.
Availability: Availability is a measure of the relative amount of
time where a path operates in stated condition, in other words
(uptime)/(uptime+downtime).
Available: That is exempt of unscheduled outage, the expectation for
a network being that the flow is maintained in the face of any
single breakage.
Deterministic Networking See section 2 of [RFC8557].
Deterministic Network See section 4.1.2 of [RFC8655].
Deterministic Flow Identifier (L2) : A tuple identified by a
stream_handle, and provided by a bridge, in accordance with IEEE
802.1CB. The tuple comprises at least src MAC, dst MAC, VLAN ID,
and L2 priority. Continuous streams are characterized by
bandwidth and max packet size; scheduled streams are characterized
by a repeating pattern of timed transmissions.
Deterministic Flow Identifier (L3): See section 3.3 of [RFC8938].
Thubert, et al. Expires 6 August 2022 [Page 4]
Internet-Draft RAW Technologies February 2022
The classical IP 5-tuple that identifies a flow comprises the src
IP, dst IP, src port, dest port, and the upper layer protocol
(ULP). DetNet uses a 6-tuple where the extra field is the DSCP
field in the packet. The IPv6 flow label is not used. for that
purpose.
Uplink: Connection from end-devices to a data communication
equipment. In the context of wireless, uplink refers to the
connection between a station (STA) and a controller (AP) or a User
Equipment (UE) to a Base Station (BS).
Downlink: The reverse direction.
Traffic type profile (IEEE): Corresponds to the traffic
classification identifier provided to a deterministic flow.
Traffic classes receive an identifier numbered from 0 to 8 (N-1),
where N is the number of outbound queues associated with a given
Bridge port. Each traffic class as a one-to-one correspondence
with a specific egress/outbound queue for a port.
FEC: Forward error correction, sending redundant coded data to help
the receiver recover transmission errors without the delays
incurred with ARQ.
HARQ: Hybrid ARQ, a combination of FEC and ARQ.
PCE: Path Computation Element.
PREOF : DetNet Packet Replication, Elimination and Ordering
Functions.
PAREO: Packet (hybrid) ARQ, Replication, Elimination and Ordering.
PAREO is a superset Of DetNet's PREOF that includes radio-specific
techniques such as short range broadcast, MUMIMO, constructive
interference and overhearing, which can be leveraged separately or
combined to increase the reliability.
Reliability: Reliability is a measure of the probability that an
item will perform its intended function for a specified interval
under stated conditions. For RAW, the service that is expected is
delivery within a bounded latency and a failure is when the packet
is either lost or delivered too late.
Track: A networking graph that can be used as a "path" to transport
RAW packets with equivalent treatment; a Track may fork and rejoin
to enable the PAREO operations.
Thubert, et al. Expires 6 August 2022 [Page 5]
Internet-Draft RAW Technologies February 2022
3. Towards Reliable and Available Networks
3.1. Scheduling for Reliability
A packet network is reliable for critical (e.g., time-sensitive)
packets when the undesirable statistical effects that affect the
transmission of those packets, e.g., delay or loss, are eliminated.
The reliability of a Deterministic Network [RFC8655] often relies on
precisely applying a tight schedule that controls the use of time-
shared resources such as CPUs and buffers, and maintains at all time
the amount of the critical packets within the physical capabilities
of the hardware and that of the transmission medium. The schedule
can also be used to shape the flows by controlling the time of
transmission of the packets that compose the flow at every hop.
To achieve this, there must be a shared sense of time throughout the
network. The sense of time is usually provided by the lower layer
and is not in scope for RAW. As an example, the Precision Time
Protocol, standardized as IEEE 1588 and IEC 61588, has mapping to
Ethernet but also to a number of industrial and Smartrid protocols
through profiles. Wi-Fi relies on IEEE Std 802.1AS, which
incorporates a PTP profile, for Fine Timing Measurement.
3.2. Diversity for Availability
Equipment failure, such as a switch or an access point rebooting, a
broken wire or radio adapter, or a fixed obstacle to the
transmission, can be the cause of multiple packets lost in a row
before the flows are rerouted or the system may recover.
This is not acceptable for critical applications such as related to
safety. A typical process control loop will tolerate an occasional
packet loss, but a loss of several packets in a row will cause an
emergency stop (e.g., after 4 packets lost, within a period of 1
second). In an amusement park, a continuous loss of packet for a few
100ms may trigger an automatic interruption of the ride and cause the
evacuation and the reboot of the game.
Network Availability is obtained by making the transmission resilient
against hardware failures and radio transmission losses due to
uncontrolled events such as co-channel interferers, multipath fading
or moving obstacles. The best results are typically achieved by
pseudo-randomly cumulating all forms of diversity, in the spatial
domain with replication and elimination, in the time domain with ARQ
and diverse scheduled transmissions, and in the frequency domain with
frequency hopping or channel hopping between frames.
Thubert, et al. Expires 6 August 2022 [Page 6]
Internet-Draft RAW Technologies February 2022
3.3. Benefits of Scheduling
Scheduling redundant transmissions of the critical packets of diverse
paths improves the resiliency against breakages and statistical
transmission loss, such as due to cosmic particles on wires, and
interferences on wireless.
When required, the worst case time of delivery can be guaranteed as
part of the end-to-end schedule, and the sense of time that must be
shared throughout the network can be exposed to and leveraged by
other applications.
In addition, scheduling provides specific value over the wireless
medium:
* Scheduling allows a time-sharing operation, where every
transmission is assigned its own time/frequency resource. IOW,
sender and receiver are synchronized and scheduled to talk on a
given frequency resource at a given time and for a given duration.
This way, scheduling can avoid collisions between scheduled
transmissions and enable a high ratio of critical traffic compared
to QoS-based priority.
* Scheduling can be used as a technoque for both time and frequency
diversity (e.g., between retries), allowing the next transmission
to happen on a different frequency as programmed in both sender
and receiver. This is useful to defeat co-channel interference
from un-controlled transmitters as well as multipath fading.
* Transmissions can be also scheduled on multiple channels in
parallel, which enables to use the full available spectrum while
avoiding the hidden terminal problem, e.g., when the next packet
in a same flow interferes on a same channel with the previous one
that progressed a few hops farther.
* On the other hand, scheduling optimizes the bandwidth usage:
compared to classical Collision Avoidance techniques, there is no
blank time related to inter-frame space (IFS) and exponential
back-off in scheduled operations. A minimal Clear Channel
Assessment may be needed to comply with the local regulations such
as ETSI 300-328, but that will not detect a collision when the
senders are synchronized.
Thubert, et al. Expires 6 August 2022 [Page 7]
Internet-Draft RAW Technologies February 2022
* Finally, scheduling plays a critical role to save energy. In IoT,
energy is the foremost concern, and synchronizing sender a nd
listener enables to always maintain them in deep sleep when there
is no scheduled transmission. This avoids idle listening and long
preambles and enables long sleep periods between traffic and
resynchronization, allowing battery-operated nodes to operate in a
mesh topology for multiple years.
4. IEEE 802.11
4.1. Provenance and Documents
With an active portfolio of nearly 1,300 standards and projects under
development, IEEE is a leading developer of industry standards in a
broad range of technologies that drive the functionality,
capabilities, and interoperability of products and services,
transforming how people live, work, and communicate.
The IEEE 802 LAN/MAN Standards Committee (SC) develops and maintains
networking standards and recommended practices for local,
metropolitan, and other area networks, using an open and accredited
process, and advocates them on a global basis. The most widely used
standards are for Ethernet, Bridging and Virtual Bridged LANs
Wireless LAN, Wireless PAN, Wireless MAN, Wireless Coexistence, Media
Independent Handover Services, and Wireless RAN. An individual
Working Group provides the focus for each area. Standards produced
by the IEEE 802 SC are freely available from the IEEE GET Program
after they have been published in PDF for six months.
The IEEE 802.11 Wireless LAN (WLAN) standards define the underlying
MAC and PHY layers for the Wi-Fi technology. Wi-Fi/802.11 is one of
the most successful wireless technologies, supporting many
application domains. While previous 802.11 generations, such as
802.11n and 802.11ac, have focused mainly on improving peak
throughput, more recent generations are also considering other
performance vectors, such as efficiency enhancements for dense
environments in 802.11ax, latency, reliability and enhancements
supporting Time-Sensitive Networking (TSN) [IEEE802.1TSN]
capabilities in P802.11be.
IEEE Std 802.11-2012 introduced support for TSN time synchronization
based on IEEE 802.1AS over 802.11 Timing Measurement protocol. IEEE
Std 802.11-2016 extended the 802.1AS operation over 802.11 Fine
Timing Measurement (FTM), as well as the Stream Reservation Protocol
(IEEE 802.1Qat). 802.11 WLANs can also be part of a 802.1Q bridged
networks with enhancements enabled by the 802.11ak amendment now
retroffitted in IEEE Std 802.11-2020. Traffic classification based
on 802.1Q VLAN tags is also supported in 802.11. Other 802.1 TSN
Thubert, et al. Expires 6 August 2022 [Page 8]
Internet-Draft RAW Technologies February 2022
capabilities such as 802.1Qbv and 802.1CB, which are media agnostic,
can already operate over 802.11. The IEEE Std 802.11ax-2021 adds new
scheduling capabilities that can enhance the timeliness performance
in the 802.11 MAC and achieve lower bounded latency. The IEEE
802.11be is undergoing efforts to enhance the support for 802.1 TSN
capabilities especially related to worst-case latency, reliability
and availability. The IEEE 802.11 working group has been working in
collaboration with the IEEE 802.1 working group for several years
extending some 802.1 features over 802.11. As with any wireless
media, 802.11 imposes new constraints and restrictions to TSN-grade
QoS, and tradeoffs between latency and reliability guarantees must be
considered as well as managed deployment requirements. An overview
of 802.1 TSN capabilities and challenges for their extensions to
802.11 are discussed in [Cavalcanti_2019].
Wi-Fi Alliance (WFA) is the worldwide network of companies that
drives global Wi-Fi adoption and evolution through thought
leadership, spectrum advocacy, and industry-wide collaboration. The
WFA work helps ensure that Wi-Fi devices and networks provide users
the interoperability, security, and reliability they have come to
expect.
Avnu Alliance is also a global industry forum developing
interoperability testing for TSN capable devices across multiple
media including Ethernet, Wi-Fi, and 5G.
The following [IEEE Std 802.11] specifications/certifications are
relevant in the context of reliable and available wireless services
and support for time-sensitive networking capabilities:
Time Synchronization: IEEE802.11-2016 with IEEE802.1AS; WFA TimeSync
Certification.
Congestion Control: IEEE Std 802.11-2016 Admission Control; WFA
Admission Control.
Security: WFA Wi-Fi Protected Access, WPA2 and WPA3.
Interoperating with IEEE802.1Q bridges: IEEE Std 802.11-2020
incorporating 802.11ak.
Stream Reservation Protocol (part of [IEEE Std 802.1Qat]): AIEEE802.
11-2016
Scheduled channel access: IEEE802.11ad Enhancements for very high
throughput in the 60 GHz band [IEEE Std 802.11ad].
802.11 Real-Time Applications: Topic Interest Group (TIG) ReportDoc
Thubert, et al. Expires 6 August 2022 [Page 9]
Internet-Draft RAW Technologies February 2022
[IEEE_doc_11-18-2009-06].
In addition, major amendments being developed by the IEEE802.11
Working Group include capabilities that can be used as the basis for
providing more reliable and predictable wireless connectivity and
support time-sensitive applications:
IEEE 802.11ax D4.0: Enhancements for High Efficiency (HE). [IEEE Std
802.11ax]
IEEE 802.11be Extreme High Throughput (EHT). [IEEE 802.11be WIP]
IEE 802.11ay Enhanced throughput for operation in license-exempt
bands above 45 GHz. [IEEE Std 802.11ay]
The main 802.11ax and 802.11be capabilities and their relevance to
RAW are discussed in the remainder of this document.
4.2. 802.11ax High Efficiency (HE)
4.2.1. General Characteristics
The next generation Wi-Fi (Wi-Fi 6) is based on the IEEE802.11ax
amendment [IEEE Std 802.11ax], which includes new capabilities to
increase efficiency, control and reduce latency. Some of the new
features include higher order 1024-QAM modulation, support for uplink
multiple user (MU) multiple input multiple output (MIMO), orthogonal
frequency-division multiple access (OFDMA), trigger-based access and
Target Wake time (TWT) for enhanced power savings. The OFDMA mode
and trigger-based access enable the AP, after reserving the channel
using the clear channel assessment procedure for a given duration, to
schedule multi-user transmissions, which is a key capability required
to increase latency predictability and reliability for time-sensitive
flows. 802.11ax can operate in up to 160 MHz channels and it includes
support for operation in the new 6 GHz band, which is expected to be
open to unlicensed use by the FCC and other regulatory agencies
worldwide.
4.2.1.1. Multi-User OFDMA and Trigger-based Scheduled Access
802.11ax introduced a new OFDMA mode in which multiple users can be
scheduled across the frequency domain. In this mode, the Access
Point (AP) can initiate multi-user (MU) Uplink (UL) transmissions in
the same PHY Protocol Data Unit (PPDU) by sending a trigger frame.
This centralized scheduling capability gives the AP much more control
of the channel in its Basic Service Set (BSS) and it can remove
Thubert, et al. Expires 6 August 2022 [Page 10]
Internet-Draft RAW Technologies February 2022
contention between associated stations for uplink transmissions,
therefore reducing the randomness caused by CSMA-based access between
stations within the same BSS. The AP can also transmit
simultaneously to multiple users in the downlink direction by using a
Downlink (DL) MU OFDMA PPDU. In order to initiate a contention free
Transmission Opportunity (TXOP) using the OFDMA mode, the AP still
follows the typical listen before talk procedure to acquire the
medium, which ensures interoperability and compliance with unlicensed
band access rules. However, 802.11ax also includes a multi-user
Enhanced Distributed Channel Access (MU-EDCA) capability, which
allows the AP to get higher channel access priority than other
devices in its BSS.
4.2.1.2. Traffic Isolation via OFDMA Resource Management and Resource
Unit Allocation
802.11ax relies on the notion of OFDMA Resource Unit (RU) to allocate
frequency chunks to different STAs over time. RUs provide a way to
allow for multiple stations to transmit simultaneously, starting and
ending at the same time. The way this is achieved is via padding,
where extra bits are transmitted with the same power level. The
current RU allocation algorithms provide a way to achieve traffic
isolation per station which while per se does not support time-aware
scheduling, is a key aspect to assist reliability, as it provides
traffic isolation in a shared medium. IEEE 802.11be (see
Section 4.3) is currently considering further and more flexible
approaches concerning RU allocation.
4.2.1.3. Improved PHY Robustness
The 802.11ax PHY can operate with 0.8, 1.6 or 3.2 microsecond guard
interval (GI). The larger GI options provide better protection
against multipath, which is expected to be a challenge in industrial
environments. The possibility to operate with smaller resource units
(e.g. 2 MHz) enabled by OFDMA also helps reduce noise power and
improve SNR, leading to better packet error rate (PER) performance.
802.11ax supports beamforming as in 802.11ac, but introduces UL MU
MIMO, which helps improve reliability. The UL MU MIMO capability is
also enabled by the trigger based access operation in 802.11ax.
4.2.1.4. Support for 6GHz band
The 802.11ax specification [IEEE Std 802.11ax] includes support for
operation in the new 6 GHz band. Given the amount of new spectrum
available as well as the fact that no legacy 802.11 device (prior
802.11ax) will be able to operate in this new band, 802.11ax
operation in this new band can be even more efficient.
Thubert, et al. Expires 6 August 2022 [Page 11]
Internet-Draft RAW Technologies February 2022
4.2.2. Applicability to deterministic flows
TSN capabilities, as defined by the IEEE 802.1 TSN standards, provide
the underlying mechanism for supporting deterministic flows in a
Local Area Network (LAN). The 802.11 working group has incorporated
support for absolute time synchronization to extend the TSN 802.1AS
protocol so that time-sensitive flow can experience precise time
synchronization when operating over 802.11 links. As IEEE 802.11 and
IEEE 802.1 TSN are both based on the IEEE 802 architecture, 802.11
devices can directly implement some TSN capabilities without the need
for a gateway/translation protocol. Basic features required for
operation in a 802.1Q LAN are already enabled for 802.11. Some TSN
capabilities, such as 802.1Qbv, can already operate over the existing
802.11 MAC SAP [Sudhakaran2021]. Implementation and experimental
results of TSN capabilities (802.1AS, 802.1Qbv, and 802.1CB) extended
over standard Ethernet and Wi-Fi devices have also been described in
[Fang_2021].Nevertheless, the IEEE 802.11 MAC/PHY could be extended
to improve the operation of IEEE 802.1 TSN features and achieve
better performance metrics [Cavalcanti1287].
TSN capabilities supported over 802.11 (which also extends to
802.11ax), include:
1. 802.1AS based Time Synchronization (other time synchronization
techniques may also be used)
2. Interoperating with IEEE802.1Q bridges
3. Time-sensitive Traffic Stream Classification
The existing 802.11 TSN capabilities listed above, and the 802.11ax
OFDMA and AP-controlled access within a BSS provide a new set of
tools to better serve time-sensitive flows. However, it is important
to understand the tradeoffs and constraints associated with such
capabilities, as well as redundancy and diversity mechanisms that can
be used to provide more predictable and reliable performance.
4.2.2.1. 802.11 Managed network operation and admission control
Time-sensitive applications and TSN standards are expected to operate
under a managed network (e.g. industrial/enterprise network). Thus,
the Wi-Fi operation must also be carefully managed and integrated
with the overall TSN management framework, as defined in the
[IEEE802.1Qcc] specification.
Some of the random-access latency and interference from legacy/
unmanaged devices can be reduced under a centralized management mode
as defined in [IEEE802.1Qcc].
Thubert, et al. Expires 6 August 2022 [Page 12]
Internet-Draft RAW Technologies February 2022
Existing traffic stream identification, configuration and admission
control procedures defined in [IEEE Std 802.11] QoS mechanism can be
re-used. However, given the high degree of determinism required by
many time-sensitive applications, additional capabilities to manage
interference and legacy devices within tight time-constraints need to
be explored.
4.2.2.2. Scheduling for bounded latency and diversity
As discussed earlier, the [IEEE Std 802.11ax] OFDMA mode introduces
the possibility of assigning different RUs (time/frequency resources)
to users within a PPDU. Several RU sizes are defined in the
specification (26, 52, 106, 242, 484, 996 subcarriers). In addition,
the AP can also decide on MCS and grouping of users within a given
OFMDA PPDU. Such flexibility can be leveraged to support time-
sensitive applications with bounded latency, especially in a managed
network where stations can be configured to operate under the control
of the AP, in a controlled environment (which contains only devices
operating on the unlicensed band installed by the facility owner and
where unexpected interference from other systems and/or radio access
technologies only sporadically happens), or in a deployment where
channel/link redundancy is used to reduce the impact of unmanaged
devices/interference.
When the network in lightly loaded, it is possible to achieve
latencies under 1 msec when Wi-Fi is operated in contention-based
(i.e., without OFDMA) mode. It is also has been shown that it is
possible to achieve 1 msec latencies in controlled environment with
higher efficiency when multi-user transmissions are used (enabled by
OFDMA operation) [Cavalcanti_2019]. Obviously, there are latency,
reliability and capacity tradeoffs to be considered. For instance,
smaller RUs result in longer transmission durations, which may impact
the minimal latency that can be achieved, but the contention latency
and randomness elimination in an interference-free environment due to
multi-user transmission is a major benefit of the OFDMA mode.
The flexibility to dynamically assign RUs to each transmission also
enables the AP to provide frequency diversity, which can help
increase reliability.
4.3. 802.11be Extreme High Throughput (EHT)
Thubert, et al. Expires 6 August 2022 [Page 13]
Internet-Draft RAW Technologies February 2022
4.3.1. General Characteristics
The ongoing [IEEE 802.11be WIP] project is the next major 802.11
amendment (after IEEE Std 802.11ax-2021) for operation in the 2.4, 5
and 6 GHz bands. 802.11be is expected to include new PHY and MAC
features and it is targeting extremely high throughput (at least 30
Gbps), as well as enhancements to worst case latency and jitter. It
is also expected to improve the integration with 802.1 TSN to support
time-sensitive applications over Ethernet and Wireless LANs.
The 802.11be Task Group started its operation in May 2019, therefore,
detailed information about specific features is not yet available.
Only high level candidate features have been discussed so far,
including:
1. 320MHz bandwidth and more efficient utilization of non-contiguous
spectrum.
2. Multi-link operation.
3. 16 spatial streams and related MIMO enhancements.
4. Multi-Access Point (AP) Coordination.
5. Enhanced link adaptation and retransmission protocol, e.g.
Hybrid Automatic Repeat Request (HARQ).
6. Any required adaptations to regulatory rules for the 6 GHz
spectrum.
4.3.2. Applicability to deterministic flows
The 802.11 Real-Time Applications (RTA) Topic Interest Group (TIG)
provided detailed information on use cases, issues and potential
solution directions to improve support for time-sensitive
applications in 802.11. The RTA TIG report [IEEE_doc_11-18-2009-06]
was used as input to the 802.11be project scope.
Improvements for worst-case latency, jitter and reliability were the
main topics identified in the RTA report, which were motivated by
applications in gaming, industrial automation, robotics, etc. The
RTA report also highlighted the need to support additional TSN
capabilities, such as time-aware (802.1Qbv) shaping and packet
replication and elimination as defined in 802.1CB.
Thubert, et al. Expires 6 August 2022 [Page 14]
Internet-Draft RAW Technologies February 2022
802.11be is expected to build on and enhance 802.11ax capabilities to
improve worst case latency and jitter. Some of the enhancement areas
are discussed next.
4.3.2.1. Enhanced scheduled operation for bounded latency
In addition to the throughput enhancements, 802.11be will leverage
the trigger-based scheduled operation enabled by 802.11ax to provide
efficient and more predictable medium access. 802.11be is expected to
include enhancements to reduce overhead and enable more efficient
operation in managed network deployments [IEEE_doc_11-19-0373-00].
4.3.2.2. Multi-AP coordination
Multi-AP coordination is one of the main new candidate features in
802.11be. It can provide benefits in throughput and capacity and has
the potential to address some of the issues that impact worst case
latency and reliability. Multi-AP coordination is expected to
address the contention due to overlapping Basic Service Sets (OBSS),
which is one of the main sources of random latency variations.
802.11be can define methods to enable better coordination between
APs, for instance, in a managed network scenario, in order to reduce
latency due to unmanaged contention.
Overall, multi-AP coordination algorithms consider three different
phases: setup (where APs handling overlapping BSSs are assigned roles
in a manual or automated way, e.g., coordinator and coordinated APs);
coordination (where APs establish links among themselves, e.g., from
a coordinating AP to coordinated APs; and then assign resources to
served stations); transmission (where the coordinating APs optimize
the distribution of the transmission opportunities).
Several multi-AP coordination approaches have been discussed with
different levels of complexities and benefits, but specific
coordination methods have not yet been defined. Out of the different
categories, MAC-driven examples include: coordinated OFDMA (Co-
OFDMA); Coordinated TDMA (Co-TDMA); HARQ; whereas PHY-driven examples
include: Coordinated Spatial Reuse (Co-SR) and Coordinated
Beamforming (Co-BF).
4.3.2.3. Multi-link operation
802.11be will introduce new features to improve operation over
multiple links and channels. By leveraging multiple links/channels,
802.11be can isolate time-sensitive traffic from network congestion,
one of the main causes of large latency variations. In a managed
802.11be network, it should be possible to steer traffic to certain
links/channels to isolate time-sensitive traffic from other traffic
Thubert, et al. Expires 6 August 2022 [Page 15]
Internet-Draft RAW Technologies February 2022
and help achieve bounded latency. The multi-link operation (MLO) has
been already introduced in the 802.be Draft and it can also enhance
latency and reliability by enabling data frames to be duplicated
across links.
4.4. 802.11ad and 802.11ay (mmWave operation)
4.4.1. General Characteristics
The IEEE 802.11ad amendment defines PHY and MAC capabilities to
enable multi-Gbps throughput in the 60 GHz millimeter wave (mmWave)
band. The standard addresses the adverse mmWave signal propagation
characteristics and provides directional communication capabilities
that take advantage of beamforming to cope with increased
attenuation. An overview of the 802.11ad standard can be found in
[Nitsche_2015] .
The IEEE 802.11ay is currently developing enhancements to the
802.11ad standard to enable the next generation mmWave operation
targeting 100 Gbps throughput. Some of the main enhancements in
802.11ay include MIMO, channel bonding, improved channel access and
beamforming training. An overview of the 802.11ay capabilities can
be found in [Ghasempour_2017]
4.4.2. Applicability to deterministic flows
The high data rates achievable with 802.11ad and 802.11ay can
significantly reduce latency down to microsecond levels. Limited
interference from legacy and other unlicensed devices in 60 GHz is
also a benefit. However, directionality and short range typical in
mmWave operation impose new challenges such as the overhead required
for beam training and blockage issues, which impact both latency and
reliability. Therefore, it is important to understand the use case
and deployment conditions in order to properly apply and configure
802.11ad/ay networks for time sensitive applications.
The 802.11ad standard includes a scheduled access mode in which the
central controller, after contending and reserving the channel for a
dedicated period, can allocate to stations contention-free service
periods. This scheduling capability is also available in 802.11ay,
and it is one of the mechanisms that can be used to provide bounded
latency to time-sensitive data flows in interference-free scenarios.
An analysis of the theoretical latency bounds that can be achieved
with 802.11ad service periods is provided in [Cavalcanti_2019].
Thubert, et al. Expires 6 August 2022 [Page 16]
Internet-Draft RAW Technologies February 2022
5. IEEE 802.15.4
5.1. Provenance and Documents
The IEEE802.15.4 Task Group has been driving the development of low-
power low-cost radio technology. The IEEE802.15.4 physical layer has
been designed to support demanding low-power scenarios targeting the
use of unlicensed bands, both the 2.4 GHz and sub GHz Industrial,
Scientific and Medical (ISM) bands. This has imposed requirements in
terms of frame size, data rate and bandwidth to achieve reduced
collision probability, reduced packet error rate, and acceptable
range with limited transmission power. The PHY layer supports frames
of up to 127 bytes. The Medium Access Control (MAC) sublayer
overhead is in the order of 10-20 bytes, leaving about 100 bytes to
the upper layers. IEEE802.15.4 uses spread spectrum modulation such
as the Direct Sequence Spread Spectrum (DSSS).
The Timeslotted Channel Hopping (TSCH) mode was added to the 2015
revision of the IEEE802.15.4 standard [IEEE Std 802.15.4]. TSCH is
targeted at the embedded and industrial world, where reliability,
energy consumption and cost drive the application space.
At the IETF, the 6TiSCH Working Group (WG) [TiSCH] deals with best
effort operation of IPv6 [RFC8200] over TSCH. 6TiSCH has enabled
distributed scheduling to exploit the deterministic access
capabilities provided by TSCH. The group designed the essential
mechanisms to enable the management plane operation while ensuring
IPv6 is supported. Yet the charter did not focus to providing a
solution to establish end to end Tracks while meeting quality of
service requirements. 6TiSCH, through the RFC8480 [RFC8480] defines
the 6P protocol which provides a pairwise negotiation mechanism to
the control plane operation. The protocol supports agreement on a
schedule between neighbors, enabling distributed scheduling. 6P goes
hand-in-hand with a Scheduling Function (SF), the policy that decides
how to maintain cells and trigger 6P transactions. The Minimal
Scheduling Function (MSF) [RFC9033] is the default SF defined by the
6TiSCH WG; other standardized SFs can be defined in the future. MSF
extends the minimal schedule configuration, and is used to add child-
parent links according to the traffic load.
Time sensitive networking on low power constrained wireless networks
have been partially addressed by ISA100.11a [ISA100.11a] and
WirelessHART [WirelessHART]. Both technologies involve a central
controller that computes redundant paths for industrial process
control traffic over a TSCH mesh. Moreover, ISA100.11a introduces
IPv6 capabilities with a Link-Local Address for the join process and
a global unicast addres for later exchanges, but the IPv6 traffic
typically ends at a local application gateway and the full power of
Thubert, et al. Expires 6 August 2022 [Page 17]
Internet-Draft RAW Technologies February 2022
IPv6 for end-to-end communication is not enabled. Compared to that
state of the art, work at the IETF and in particular at RAW could
provide additional techniques such as optimized P2P routing, PAREO
functions, and end-to-end secured IPv6/CoAP connectivity.
The 6TiSCH architecture [RFC9030] identifies different models to
schedule resources along so-called Tracks (see Section 5.2.2.2)
exploiting the TSCH schedule structure however the focus at 6TiSCH is
on best effort traffic and the group was never chartered to produce
standard work related to Tracks.
Useful References include:
1. IEEE Std 802.15.4: "IEEE Std 802.15.4, Part. 15.4: Wireless
Medium Access Control (MAC) and Physical Layer (PHY)
Specifications for Low-Rate Wireless Personal Area Networks"
[IEEE Std 802.15.4]. The latest version at the time of this
writing is dated year 2015.
2. Morell, A. , Vilajosana, X. , Vicario, J. L. and Watteyne, T.
(2013), Label switching over IEEE802.15.4e networks. Trans.
Emerging Tel. Tech., 24: 458-475. doi:10.1002/ett.2650"
[morell13].
3. De Armas, J., Tuset, P., Chang, T., Adelantado, F., Watteyne, T.,
Vilajosana, X. (2016, September). Determinism through path
diversity: Why packet replication makes sense. In 2016
International Conference on Intelligent Networking and
Collaborative Systems (INCoS) (pp. 150-154). IEEE. [dearmas16].
4. X. Vilajosana, T. Watteyne, M. Vucinic, T. Chang and K. S.
J. Pister, "6TiSCH: Industrial Performance for IPv6 Internet-of-
Things Networks," in Proceedings of the IEEE, vol. 107, no. 6,
pp. 1153-1165, June 2019. [vilajosana19].
5.2. TimeSlotted Channel Hopping
5.2.1. General Characteristics
As a core technique in IEEE802.15.4, TSCH splits time in multiple
time slots that repeat over time. A set of timeslots constructs a
Slotframe (see Section 5.2.2.1.4). For each timeslot, a set of
available frequencies can be used, resulting in a matrix-like
schedule (see Figure 1).
Thubert, et al. Expires 6 August 2022 [Page 18]
Internet-Draft RAW Technologies February 2022
timeslot offset
| 0 1 2 3 4 | 0 1 2 3 4 | Nodes
+------------------------+------------------------+ +-----+
| | | | | | | | | | | | C |
CH-1 | EB | | |C->B| | EB | | |C->B| | | |
| | | | | | | | | | | +-----+
+-------------------------------------------------+ |
| | | | | | | | | | | |
CH-2 | | |B->C| |B->A| | |B->C| |B->A| +-----+
| | | | | | | | | | | | B |
+-------------------------------------------------+ | |
... +-----+
|
+-------------------------------------------------+ |
| | | | | | | | | | | +-----+
CH-15| |A->B| | | | |A->B| | | | | A |
| | | | | | | | | | | | |
+-------------------------------------------------+ +-----+
ch.
offset
Figure 1: Slotframe example with scheduled cells between nodes A,
B and C
This schedule represents the possible communications of a node with
its neighbors, and is managed by a Scheduling Function such as the
Minimal Scheduling Function (MSF) [RFC9033]. Each cell in the
schedule is identified by its slotoffset and channeloffset
coordinates. A cell's timeslot offset indicates its position in
time, relative to the beginning of the slotframe. A cell's channel
offset is an index which maps to a frequency at each iteration of the
slotframe. Each packet exchanged between neighbors happens within
one cell. The size of a cell is a timeslot duration, between 10 to
15 milliseconds. An Absolute Slot Number (ASN) indicates the number
of slots elapsed since the network started. It increments at every
slot. This is a 5 byte counter that can support networks running for
more than 300 years without wrapping (assuming a 10 ms timeslot).
Channel hopping provides increased reliability to multi-path fading
and external interference. It is handled by TSCH through a channel
hopping sequence referred as macHopSeq in the IEEE802.15.4
specification.
The Time-Frequency Division Multiple Access provided by TSCH enables
the orchestration of traffic flows, spreading them in time and
frequency, and hence enabling an efficient management of the
bandwidth utilization. Such efficient bandwidth utilization can be
combined to OFDM modulations also supported by the IEEE802.15.4
standard [IEEE Std 802.15.4] since the 2015 version.
Thubert, et al. Expires 6 August 2022 [Page 19]
Internet-Draft RAW Technologies February 2022
TSCH networks operate in ISM bands in which the spectrum is shared by
different coexisting technologies. Regulations such as FCC, ETSI and
ARIB impose duty cycle regulations to limit the use of the bands but
yet interference may constraint the probability to deliver a packet.
Part of these reliability challenges are addressed at the MAC
introducing redundancy and diversity, thanks to channel hopping,
scheduling and ARQ policies. Yet, the MAC layer operates with a
1-hop vision, being limited to local actions to mitigate
underperforming links.
In the RAW context, low power reliable networks should address non-
critical control scenarios such as Class 2 and monitoring scenarios
such as Class 4 defined by the RFC5673 [RFC5673]. As a low power
technology targeting industrial scenarios radio transducers provide
low data rates (typically between 50kbps to 250kbps) and robust
modulations to trade-off performance to reliability. TSCH networks
are organized in mesh topologies and connected to a backbone.
Latency in the mesh network is mainly influenced by propagation
aspects such as interference. ARQ methods and redundancy techniques
such as replication and elimination should be studied to provide the
needed performance to address deterministic scenarios.
5.2.2. Applicability to Deterministic Flows
Nodes in a TSCH network are tightly synchronized. This enables to
build the slotted structure and ensure efficient utilization of
resources thanks to proper scheduling policies. Scheduling is a key
to orchestrate the resources that different nodes in a Track or a
path are using. Slotframes can be split in resource blocks reserving
the needed capacity to certain flows. Periodic and bursty traffic
can be handled independently in the schedule, using active and
reactive policies and taking advantage of overprovisionned cells to
measu reth excursion. Along a Track, resource blocks can be chained
so nodes in previous hops transmit their data before the next packet
comes. This provides a tight control to latency along a Track.
Collision loss is avoided for best effort traffic by
overprovisionning resources, giving time to the management plane of
the network to dedicate more resources if needed.
5.2.2.1. Centralized Path Computation
In a controlled environment, a 6TiSCH device usually does not place a
request for bandwidth between itself and another device in the
network. Rather, an Operation Control System (OCS) invoked through
an Human/Machine Interface (HMI) iprovides the Traffic Specification,
in particular in terms of latency and reliability, and the end nodes,
to a Path Computation element (PCE). With this, the PCE computes a
Track between the end nodes and provisions every hop in the Track
Thubert, et al. Expires 6 August 2022 [Page 20]
Internet-Draft RAW Technologies February 2022
with per-flow state that describes the per-hop operation for a given
packet, the corresponding timeSlots, and the flow identification to
recognize which packet is placed in which Track, sort out duplicates,
etc. In Figure 2, an example of Operational Control System and HMI
is depicted.
For a static configuration that serves a certain purpose for a long
period of time, it is expected that a node will be provisioned in one
shot with a full schedule, which incorporates the aggregation of its
behavior for multiple Tracks. The 6TiSCH Architecture expects that
the programing of the schedule is done over CoAP as discussed in
"6TiSCH Resource Management and Interaction using CoAP"
[I-D.ietf-6tisch-coap].
But an Hybrid mode may be required as well whereby a single Track is
added, modified, or removed, for instance if it appears that a Track
does not perform as expected for, say, Packet Delivery Ratio (PDR).
For that case, the expectation is that a protocol that flows along a
Track (to be), in a fashion similar to classical Traffic Engineering
(TE) [CCAMP], may be used to update the state in the devices. 6TiSCH
provides means for a device to negotiate a timeSlot with a neighbor,
but in general that flow was not designed and no protocol was
selected and it is expected that DetNet will determine the
appropriate end-to-end protocols to be used in that case.
Stream Management Entity
Operational Control System and HMI
-+-+-+-+-+-+-+ Northbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
PCE PCE PCE PCE
-+-+-+-+-+-+-+ Southbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
--- 6TiSCH------6TiSCH------6TiSCH------6TiSCH--
6TiSCH / Device Device Device Device \
Device- - 6TiSCH
\ 6TiSCH 6TiSCH 6TiSCH 6TiSCH / Device
----Device------Device------Device------Device--
Figure 2
5.2.2.1.1. Packet Marking and Handling
Section "Packet Marking and Handling" of [RFC9030] describes the
packet tagging and marking that is expected in 6TiSCH networks.
Thubert, et al. Expires 6 August 2022 [Page 21]
Internet-Draft RAW Technologies February 2022
5.2.2.1.1.1. Tagging Packets for Flow Identification
For packets that are routed by a PCE along a Track, the tuple formed
by the IPv6 source address and a local RPLInstanceID is tagged in the
packets to identify uniquely the Track and associated transmit bundle
of timeSlots.
It results that the tagging that is used for a DetNet flow outside
the 6TiSCH LLN MUST be swapped into 6TiSCH formats and back as the
packet enters and then leaves the 6TiSCH network.
Note: The method and format used for encoding the RPLInstanceID at
6lo is generalized to all 6TiSCH topological Instances, which
includes Tracks.
5.2.2.1.1.2. Replication, Retries and Elimination
The 6TiSCH Architecture [RFC9030] leverages the Packet Replication,
Retries and Elimination (PRE) functions (PREF), the precursor to what
the RAW Architecture [I-D.ietf-raw-architecture] calls PAREO
functions. PREF establishes several paths in a network to provide
redundancy and parallel transmissions to bound the end-to-end delay.
Considering the scenario shown in Figure 3, many different paths are
possible for S to reach R. A simple way to benefit from this
topology could be to use the two independent paths via nodes A, C, E
and via B, D, F. But more complex paths are possible as well.
(A) (C) (E)
source (S) (R) (destination)
(B) (D) (F)
Figure 3: A Typical Ladder Shape with Two Parallel Paths Toward
the Destination
By employing a Packet Replication function, each node forwards a copy
of each data packet over two different branches. For instance, in
Figure 4, the source node S transmits the data packet to nodes A and
B, in two different timeslots within the same TSCH slotframe.
===> (A) => (C) => (E) ===
// \\// \\// \\
source (S) //\\ //\\ (R) (destination)
\\ // \\ // \\ //
===> (B) => (D) => (F) ===
Thubert, et al. Expires 6 August 2022 [Page 22]
Internet-Draft RAW Technologies February 2022
Figure 4: Packet Replication: S transmits twice the same data
packet, to its DP (A) and to its AP (B).
By employing Packet Elimination function once a node receives the
first copy of a data packet, it discards the subsequent copies.
Because the first copy that reaches a node is the one that matters,
it is the only copy that will be forwarded upward.
Considering that the wireless medium is broadcast by nature, any
neighbor of a transmitter may overhear a transmission. By employing
the Promiscuous Overhearing function, nodes will have multiple
opportunities to receive a given data packet. For instance, in
Figure 4, when the source node S transmits the data packet to node A,
node B may overhear this transmission.
6TiSCH expects elimination and replication of packets along a complex
Track, but has no position about how the sequence numbers would be
tagged in the packet.
As it goes, 6TiSCH expects that timeSlots corresponding to copies of
a same packet along a Track are correlated by configuration, and does
not need to process the sequence numbers.
The semantics of the configuration MUST enable correlated timeSlots
to be grouped for transmit (and respectively receive) with
a'OR'relations, and then a'AND'relation MUST be configurable between
groups. The semantics is that if the transmit (and respectively
receive) operation succeeded in one timeSlot in a'OR'group, then all
the other timeSLots in the group are ignored. Now, if there are at
least two groups, the'AND'relation between the groups indicates that
one operation must succeed in each of the groups.
On the transmit side, timeSlots provisioned for retries along a same
branch of a Track are placed a same'OR'group. The'OR'relation
indicates that if a transmission is acknowledged, then further
transmissions SHOULD NOT be attempted for timeSlots in that group.
There are as many'OR'groups as there are branches of the Track
departing from this node. Different'OR'groups are programmed for the
purpose of replication, each group corresponding to one branch of the
Track. The'AND'relation between the groups indicates that
transmission over any of branches MUST be attempted regardless of
whether a transmission succeeded in another branch. It is also
possible to place cells to different next-hop routers in a
same'OR'group. This allows to route along multi-path Tracks, trying
one next-hop and then another only if sending to the first fails.
Thubert, et al. Expires 6 August 2022 [Page 23]
Internet-Draft RAW Technologies February 2022
On the receive side, all timeSlots are programmed in a same'OR'group.
Retries of a same copy as well as converging branches for elimination
are converged, meaning that the first successful reception is enough
and that all the other timeSlots can be ignored.
5.2.2.1.2. Topology and capabilities
6TiSCH nodes are usually IoT devices, characterized by very limited
amount of memory, just enough buffers to store one or a few IPv6
packets, and limited bandwidth between peers. It results that a node
will maintain only a small number of peering information, and will
not be able to store many packets waiting to be forwarded. Peers can
be identified through MAC or IPv6 addresses.
Neighbors can be discovered over the radio using mechanism such as
Enhanced Beacons, but, though the neighbor information is available
in the 6TiSCH interface data model, 6TiSCH does not describe a
protocol to pro-actively push the neighborhood information to a PCE.
This protocol should be described and should operate over CoAP. The
protocol should be able to carry multiple metrics, in particular the
same metrics as used for RPL operations [RFC6551].
The energy that the device consumes in sleep, transmit and receive
modes can be evaluated and reported. So can the amount of energy
that is stored in the device and the power that it can be scavenged
from the environment. The PCE SHOULD be able to compute Tracks that
will implement policies on how the energy is consumed, for instance
balance between nodes, ensure that the spent energy does not exceeded
the scavenged energy over a period of time, etc...
5.2.2.1.3. Schedule Management by a PCE
6TiSCH supports a mixed model of centralized routes and distributed
routes. Centralized routes can for example be computed by a entity
such as a PCE [PCE]. Distributed routes are computed by RPL
[RFC6550].
Both methods may inject routes in the Routing Tables of the 6TiSCH
routers. In either case, each route is associated with a 6TiSCH
topology that can be a RPL Instance topology or a Track. The 6TiSCH
topology is indexed by a Instance ID, in a format that reuses the
RPLInstanceID as defined in RPL.
Thubert, et al. Expires 6 August 2022 [Page 24]
Internet-Draft RAW Technologies February 2022
Both RPL and PCE rely on shared sources such as policies to define
Global and Local RPLInstanceIDs that can be used by either method.
It is possible for centralized and distributed routing to share a
same topology. Generally they will operate in different slotFrames,
and centralized routes will be used for scheduled traffic and will
have precedence over distributed routes in case of conflict between
the slotFrames.
5.2.2.1.4. SlotFrames and Priorities
A slotFrame is the base object that a PCE needs to manipulate to
program a schedule into an LLN node. Elaboration on that concept can
be fond in section "SlotFrames and Priorities" of [RFC9030]
IEEE802.15.4 TSCH avoids contention on the medium by formatting time
and frequencies in cells of transmission of equal duration. In order
to describe that formatting of time and frequencies, the 6TiSCH
architecture defines a global concept that is called a Channel
Distribution and Usage (CDU) matrix; a CDU matrix is a matrix of
cells with an height equal to the number of available channels
(indexed by ChannelOffsets) and a width (in timeSlots) that is the
period of the network scheduling operation (indexed by slotOffsets)
for that CDU matrix. The size of a cell is a timeSlot duration, and
values of 10 to 15 milliseconds are typical in 802.15.4 TSCH to
accommodate for the transmission of a frame and an acknowledgement,
including the security validation on the receive side which may take
up to a few milliseconds on some device architecture.
The frequency used by a cell in the matrix rotates in a pseudo-random
fashion, from an initial position at an epoch time, as the matrix
iterates over and over.
A CDU matrix is computed by the PCE, but unallocated timeSlots may be
used opportunistically by the nodes for classical best effort IP
traffic. The PCE has precedence in the allocation in case of a
conflict.
In a given network, there might be multiple CDU matrices that operate
with different width, so they have different durations and represent
different periodic operations. It is recommended that all CDU
matrices in a 6TiSCH domain operate with the same cell duration and
are aligned, so as to reduce the chances of interferences from
slotted-aloha operations. The PCE MUST compute the CDU matrices and
shared that knowledge with all the nodes. The matrices are used in
particular to define slotFrames.
Thubert, et al. Expires 6 August 2022 [Page 25]
Internet-Draft RAW Technologies February 2022
A slotFrame is a MAC-level abstraction that is common to all nodes
and contains a series of timeSlots of equal length and precedence.
It is characterized by a slotFrame_ID, and a slotFrame_size. A
slotFrame aligns to a CDU matrix for its parameters, such as number
and duration of timeSlots.
Multiple slotFrames can coexist in a node schedule, i.e., a node can
have multiple activities scheduled in different slotFrames, based on
the precedence of the 6TiSCH topologies. The slotFrames may be
aligned to different CDU matrices and thus have different width.
There is typically one slotFrame for scheduled traffic that has the
highest precedence and one or more slotFrame(s) for RPL traffic. The
timeSlots in the slotFrame are indexed by the SlotOffset; the first
cell is at SlotOffset 0.
The 6TiSCH architecture introduces the concept of chunks ([RFC9030])
to operate such spectrum distribution for a whole group of cells at a
time. The CDU matrix is formatted into a set of chunks, each of them
identified uniquely by a chunk-ID, see Figure 5. The PCE MUST
compute the partitioning of CDU matrices into chunks and shared that
knowledge with all the nodes in a 6TiSCH network.
+-----+-----+-----+-----+-----+-----+-----+ +-----+
chan.Off. 0 |chnkA|chnkP|chnk7|chnkO|chnk2|chnkK|chnk1| ... |chnkZ|
+-----+-----+-----+-----+-----+-----+-----+ +-----+
chan.Off. 1 |chnkB|chnkQ|chnkA|chnkP|chnk3|chnkL|chnk2| ... |chnk1|
+-----+-----+-----+-----+-----+-----+-----+ +-----+
...
+-----+-----+-----+-----+-----+-----+-----+ +-----+
chan.Off. 15 |chnkO|chnk6|chnkN|chnk1|chnkJ|chnkZ|chnkI| ... |chnkG|
+-----+-----+-----+-----+-----+-----+-----+ +-----+
0 1 2 3 4 5 6 M
Figure 5: CDU matrix Partitioning in Chunks
The appropriation of a chunk can be requested explicitly by the PCE
to any node. After a successful appropriation, the PCE owns the
cells in that chunk, and may use them as hard cells to set up Tracks.
Then again, 6TiSCH did not propose a method for chunk definition and
a protocol for appropriation. This is to be done at RAW.
Thubert, et al. Expires 6 August 2022 [Page 26]
Internet-Draft RAW Technologies February 2022
5.2.2.2. 6TiSCH Tracks
A Track at 6TiSCH is the application to wireless of the concept of a
path in the "Detnet architecture" [RFC8655]. A Track can follow a
simple sequence of relay nodes or can be structured as a more complex
Destination Oriented Directed Acyclic Graph (DODAG) to a unicast
destination. Along a Track, 6TiSCH nodes reserve the resources to
enable the efficient transmission of packets while aiming to optimize
certain properties such as reliability and ensure small jitter or
bounded latency. The Track structure enables Layer-2 forwarding
schemes, reducing the overhead of taking routing decisions at the
Layer-3.
Serial Tracks can be understood as the concatenation of cells or
bundles along a routing path from a source towards a destination.
The serial Track concept is analogous to the circuit concept where
resources are chained through the multi-hop topology. For example, A
bundle of Tx Cells in a particular node is paired to a bundle of Rx
Cells in the next hop node following a routing path.
Whereas scheduling ensures reliable delivery in bounded time along
any Track, high availability requires the application of PAREO
functions along a more complex DODAG Track structure. A DODAG has
forking and joining nodes where the concepts such as Replication and
Elimination can be exploited. Spatial redundancy increases the
oveall energy consumption in the network but improves significantly
the availability of the network as well as the packet delivery ratio.
A Track may also branch off and rejoin, for the purpose of the so-
called Packet Replication and Elimination (PRE), over non congruent
branches. PRE may be used to complement layer-2 Automatic Repeat
reQuest (ARQ) and receiver-end Ordering to form the PAREO functions.
PAREO functions enable to meet industrial expectations in PDR within
bounded delivery time over a Track that includes wireless links, even
when the Track extends beyond the 6TiSCH network.
The RAW Track described in the RAW Architecture
[I-D.ietf-raw-architecture] inherits directly from that model. RAW
extends the graph beyond a DODAG as long as a given packet cannot
loop within the Track.
Thubert, et al. Expires 6 August 2022 [Page 27]
Internet-Draft RAW Technologies February 2022
+-----+
| IoT |
| G/W |
+-----+
^ <---- Elimination
| |
Track branch | |
+-------+ +--------+ Subnet Backbone
| |
+--|--+ +--|--+
| | | Backbone | | | Backbone
o | | | router | | | router
+--/--+ +--|--+
o / o o---o----/ o
o o---o--/ o o o o o
o \ / o o LLN o
o v <---- Replication
o
Figure 6: End-to-End deterministic Track
In the example above (see Figure 6), a Track is laid out from a field
device in a 6TiSCH network to an IoT gateway that is located on a
IEEE802.1 TSN backbone.
The Replication function in the field device sends a copy of each
packet over two different branches, and a PCE schedules each hop of
both branches so that the two copies arrive in due time at the
gateway. In case of a loss on one branch, hopefully the other copy
of the packet still makes it in due time. If two copies make it to
the IoT gateway, the Elimination function in the gateway ignores the
extra packet and presents only one copy to upper layers.
At each 6TiSCH hop along the Track, the PCE may schedule more than
one timeSlot for a packet, so as to support Layer-2 retries (ARQ).
It is also possible that the field device only uses the second branch
if sending over the first branch fails.
In current deployments, a TSCH Track does not necessarily support PRE
but is systematically multi-path. This means that a Track is
scheduled so as to ensure that each hop has at least two forwarding
solutions, and the forwarding decision is to try the preferred one
and use the other in case of Layer-2 transmission failure as detected
by ARQ.
Thubert, et al. Expires 6 August 2022 [Page 28]
Internet-Draft RAW Technologies February 2022
Methods to implement complex Tracks are described in
[I-D.papadopoulos-paw-pre-reqs] and complemented by extensions to the
RPL routing protocol in [I-D.ietf-roll-nsa-extension] for best effort
traffic, but a centralized routing technique such as promoted in
DetNet is still missing.
5.2.2.2.1. Track Scheduling Protocol
Section "Schedule Management Mechanisms" of the 6TiSCH architecture
describes 4 paradigms to manage the TSCH schedule of the LLN nodes:
Static Scheduling, neighbor-to-neighbor Scheduling, remote monitoring
and scheduling management, and Hop-by-hop scheduling. The Track
operation for DetNet corresponds to a remote monitoring and
scheduling management by a PCE.
Early work at 6TiSCH on a data model and a protocol to program the
schedule in the 6TiSCH device was never concluded as the group
focussed on best effort traffic. This work would be revived by RAW:
The 6top interface document [RFC8480] (to be reopened at RAW) was
intended to specify the generic data model that can be used to
monitor and manage resources of the 6top sublayer. Abstract
methods were suggested for use by a management entity in the
device. The data model also enables remote control operations on
the 6top sublayer.
[I-D.ietf-6tisch-coap] (to be reopened at RAW) was intended to
define a mapping of the 6top set of commands, which is described
in RFC 8480, to CoAP resources. This allows an entity to interact
with the 6top layer of a node that is multiple hops away in a
RESTful fashion.
[I-D.ietf-6tisch-coap] also defined a basic set CoAP resources and
associated RESTful access methods (GET/PUT/POST/DELETE). The
payload (body) of the CoAP messages is encoded using the CBOR
format. The PCE commands are expected to be issued directly as
CoAP requests or to be mapped back and forth into CoAP by a
gateway function at the edge of the 6TiSCH network. For instance,
it is possible that a mapping entity on the backbone transforms a
non-CoAP protocol such as PCEP into the RESTful interfaces that
the 6TiSCH devices support.
Thubert, et al. Expires 6 August 2022 [Page 29]
Internet-Draft RAW Technologies February 2022
5.2.2.2.2. Track Forwarding
By forwarding, this specification means the per-packet operation that
allows to deliver a packet to a next hop or an upper layer in this
node. Forwarding is based on pre-existing state that was installed
as a result of the routing computation of a Track by a PCE. The
6TiSCH architecture supports three different forwarding model, G-MPLS
Track Forwarding (TF), 6LoWPAN Fragment Forwarding (FF) and IPv6
Forwarding (6F) which is the classical IP operation [RFC9030]. The
DetNet case relates to the Track Forwarding operation under the
control of a PCE.
A Track is a unidirectional path between a source and a destination.
In a Track cell, the normal operation of IEEE802.15.4 Automatic
Repeat-reQuest (ARQ) usually happens, though the acknowledgment may
be omitted in some cases, for instance if there is no scheduled cell
for a retry.
Track Forwarding is the simplest and fastest. A bundle of cells set
to receive (RX-cells) is uniquely paired to a bundle of cells that
are set to transmit (TX-cells), representing a layer-2 forwarding
state that can be used regardless of the network layer protocol.
This model can effectively be seen as a Generalized Multi-protocol
Label Switching (G-MPLS) operation in that the information used to
switch a frame is not an explicit label, but rather related to other
properties of the way the packet was received, a particular cell in
the case of 6TiSCH. As a result, as long as the TSCH MAC (and
Layer-2 security) accepts a frame, that frame can be switched
regardless of the protocol, whether this is an IPv6 packet, a 6LoWPAN
fragment, or a frame from an alternate protocol such as WirelessHART
or ISA100.11a.
A data frame that is forwarded along a Track normally has a
destination MAC address that is set to broadcast - or a multicast
address depending on MAC support. This way, the MAC layer in the
intermediate nodes accepts the incoming frame and 6top switches it
without incurring a change in the MAC header. In the case of
IEEE802.15.4, this means effectively broadcast, so that along the
Track the short address for the destination of the frame is set to
0xFFFF.
A Track is thus formed end-to-end as a succession of paired bundles,
a receive bundle from the previous hop and a transmit bundle to the
next hop along the Track, and a cell in such a bundle belongs to at
most one Track. For a given iteration of the device schedule, the
effective channel of the cell is obtained by adding a pseudo-random
number to the channelOffset of the cell, which results in a rotation
of the frequency that used for transmission. The bundles may be
Thubert, et al. Expires 6 August 2022 [Page 30]
Internet-Draft RAW Technologies February 2022
computed so as to accommodate both variable rates and
retransmissions, so they might not be fully used at a given iteration
of the schedule. The 6TiSCH architecture provides additional means
to avoid waste of cells as well as overflows in the transmit bundle,
as follows:
In one hand, a TX-cell that is not needed for the current iteration
may be reused opportunistically on a per-hop basis for routed
packets. When all of the frame that were received for a given Track
are effectively transmitted, any available TX-cell for that Track can
be reused for upper layer traffic for which the next-hop router
matches the next hop along the Track. In that case, the cell that is
being used is effectively a TX-cell from the Track, but the short
address for the destination is that of the next-hop router. It
results that a frame that is received in a RX-cell of a Track with a
destination MAC address set to this node as opposed to broadcast must
be extracted from the Track and delivered to the upper layer (a frame
with an unrecognized MAC address is dropped at the lower MAC layer
and thus is not received at the 6top sublayer).
On the other hand, it might happen that there are not enough TX-cells
in the transmit bundle to accommodate the Track traffic, for instance
if more retransmissions are needed than provisioned. In that case,
the frame can be placed for transmission in the bundle that is used
for layer-3 traffic towards the next hop along the Track as long as
it can be routed by the upper layer, that is, typically, if the frame
transports an IPv6 packet. The MAC address should be set to the
next-hop MAC address to avoid confusion. It results that a frame
that is received over a layer-3 bundle may be in fact associated to a
Track. In a classical IP link such as an Ethernet, off-Track traffic
is typically in excess over reservation to be routed along the non-
reserved path based on its QoS setting. But with 6TiSCH, since the
use of the layer-3 bundle may be due to transmission failures, it
makes sense for the receiver to recognize a frame that should be re-
Tracked, and to place it back on the appropriate bundle if possible.
A frame should be re-Tracked if the Per-Hop-Behavior group indicated
in the Differentiated Services Field in the IPv6 header is set to
Deterministic Forwarding, as discussed in Section 5.2.2.1.1. A frame
is re-Tracked by scheduling it for transmission over the transmit
bundle associated to the Track, with the destination MAC address set
to broadcast.
There are 2 modes for a Track, transport mode and tunnel mode.
Thubert, et al. Expires 6 August 2022 [Page 31]
Internet-Draft RAW Technologies February 2022
5.2.2.2.2.1. Transport Mode
In transport mode, the Protocol Data Unit (PDU) is associated with
flow-dependant meta-data that refers uniquely to the Track, so the
6top sublayer can place the frame in the appropriate cell without
ambiguity. In the case of IPv6 traffic, this flow identification is
transported in the Flow Label of the IPv6 header. Associated with
the source IPv6 address, the Flow Label forms a globally unique
identifier for that particular Track that is validated at egress
before restoring the destination MAC address (DMAC) and punting to
the upper layer.
| ^
+--------------+ | |
| IPv6 | | |
+--------------+ | |
| 6LoWPAN HC | | |
+--------------+ ingress egress
| 6top | sets +----+ +----+ restores
+--------------+ dmac to | | | | dmac to
| TSCH MAC | brdcst | | | | self
+--------------+ | | | | | |
| LLN PHY | +-------+ +--...-----+ +-------+
+--------------+
Figure 7: Track Forwarding, Transport Mode
5.2.2.2.2.2. Tunnel Mode
In tunnel mode, the frames originate from an arbitrary protocol over
a compatible MAC that may or may not be synchronized with the 6TiSCH
network. An example of this would be a router with a dual radio that
is capable of receiving and sending WirelessHART or ISA100.11a frames
with the second radio, by presenting itself as an Access Point or a
Backbone Router, respectively.
In that mode, some entity (e.g. PCE) can coordinate with a
WirelessHART Network Manager or an ISA100.11a System Manager to
specify the flows that are to be transported transparently over the
Track.
Thubert, et al. Expires 6 August 2022 [Page 32]
Internet-Draft RAW Technologies February 2022
+--------------+
| IPv6 |
+--------------+
| 6LoWPAN HC |
+--------------+ set restore
| 6top | +dmac+ +dmac+
+--------------+ to|brdcst to|nexthop
| TSCH MAC | | | | |
+--------------+ | | | |
| LLN PHY | +-------+ +--...-----+ +-------+
+--------------+ | ingress egress |
| |
+--------------+ | |
| LLN PHY | | |
+--------------+ | |
| TSCH MAC | | |
+--------------+ | dmac = | dmac =
|ISA100/WiHART | | nexthop v nexthop
+--------------+
Figure 8: Track Forwarding, Tunnel Mode
In that case, the flow information that identifies the Track at the
ingress 6TiSCH router is derived from the RX-cell. The dmac is set
to this node but the flow information indicates that the frame must
be tunneled over a particular Track so the frame is not passed to the
upper layer. Instead, the dmac is forced to broadcast and the frame
is passed to the 6top sublayer for switching.
At the egress 6TiSCH router, the reverse operation occurs. Based on
metadata associated to the Track, the frame is passed to the
appropriate link layer with the destination MAC restored.
5.2.2.2.2.3. Tunnel Metadata
Metadata coming with the Track configuration is expected to provide
the destination MAC address of the egress endpoint as well as the
tunnel mode and specific data depending on the mode, for instance a
service access point for frame delivery at egress. If the tunnel
egress point does not have a MAC address that matches the
configuration, the Track installation fails.
In transport mode, if the final layer-3 destination is the tunnel
termination, then it is possible that the IPv6 address of the
destination is compressed at the 6LoWPAN sublayer based on the MAC
address. It is thus mandatory at the ingress point to validate that
the MAC address that was used at the 6LoWPAN sublayer for compression
matches that of the tunnel egress point. For that reason, the node
Thubert, et al. Expires 6 August 2022 [Page 33]
Internet-Draft RAW Technologies February 2022
that injects a packet on a Track checks that the destination is
effectively that of the tunnel egress point before it overwrites it
to broadcast. The 6top sublayer at the tunnel egress point reverts
that operation to the MAC address obtained from the tunnel metadata.
5.2.2.2.2.4. OAM
An Overview of Operations, Administration, and Maintenance (OAM)
Tools [RFC7276] provides an overwiew of the existing tooling for OAM
[RFC6291]. Tracks are complex paths and new tooling is necessary to
manage them, with respect to load control, timing, and the Packet
Replication and Elimination Functions (PREF).
An example of such tooling can be found in the context of BIER
[RFC8279] and more specifically BIER Traffic Engineering
[I-D.ietf-bier-te-arch] (BIER-TE):
[I-D.thubert-bier-replication-elimination] leverages BIER-TE to
control the process of PREF, and to provide traceability of these
operations, in the deterministic dataplane, along a complex Track.
For the 6TiSCH type of constrained environment,
[I-D.thubert-6lo-bier-dispatch] enables an efficient encoding of the
BIER bitmap within the 6LoRH framework.
6. 5G
6.1. Provenance and Documents
The 3rd Generation Partnership Project (3GPP) incorporates many
companies whose business is related to cellular network operation as
well as network equipment and device manufacturing. All generations
of 3GPP technologies provide scheduled wireless segments, primarily
in licensed spectrum which is beneficial for reliability and
availability.
Thubert, et al. Expires 6 August 2022 [Page 34]
Internet-Draft RAW Technologies February 2022
In 2016, the 3GPP started to design New Radio (NR) technology
belonging to the fifth generation (5G) of cellular networks. NR has
been designed from the beginning to not only address enhanced Mobile
Broadband (eMBB) services for consumer devices such as smart phones
or tablets but is also tailored for future Internet of Things (IoT)
communication and connected cyber-physical systems. In addition to
eMBB, requirement categories have been defined on Massive Machine-
Type Communication (M-MTC) for a large number of connected devices/
sensors, and Ultra-Reliable Low-Latency Communication (URLLC) for
connected control systems and critical communication as illustrated
in Figure 9. It is the URLLC capabilities that make 5G a great
candidate for reliable low-latency communication. With these three
corner stones, NR is a complete solution supporting the connectivity
needs of consumers, enterprises, and public sector for both wide area
and local area, e.g. indoor deployments. A general overview of NR
can be found in [TS38300].
enhanced
Mobile Broadband
^
/ \
/ \
/ \
/ \
/ 5G \
/ \
/ \
/ \
+-----------------+
Massive Ultra-Reliable
Machine-Type Low-Latency
Communication Communication
Figure 9: 5G Application Areas
As a result of releasing the first NR specification in 2018 (Release
15), it has been proven by many companies that NR is a URLLC-capable
technology and can deliver data packets at 10^-5 packet error rate
within 1ms latency budget [TR37910]. Those evaluations were
consolidated and forwarded to ITU to be included in the [IMT2020]
work.
In order to understand communication requirements for automation in
vertical domains, 3GPP studied different use cases [TR22804] and
released technical specification with reliability, availability and
latency demands for a variety of applications [TS22104].
Thubert, et al. Expires 6 August 2022 [Page 35]
Internet-Draft RAW Technologies February 2022
As an evolution of NR, multiple studies have been conducted in scope
of 3GPP Release 16 including the following two, focusing on radio
aspects:
1. Study on physical layer enhancements for NR ultra-reliable and
low latency communication (URLLC) [TR38824].
2. Study on NR industrial Internet of Things (I-IoT) [TR38825].
Resulting of these studies, further enhancements to NR have been
standardized in 3GPP Release 16, hence, available in [TS38300], and
continued in 3GPP Release 17 standardization (according to
[RP210854]).
In addition, several enhancements have been done on system
architecture level which are reflected in System architecture for the
5G System (5GS) [TS23501]. These enhancements include multiple
features in support of Time-Sensitive Communications (TSC) by Release
16 and Release 17. Further improvements will be considered in the
3GPP Release 18 time frame, e.g., support for DetNet [SP211633].
The adoption and the use of 5G is facilitated by multiple
organizations. For instance, the 5G Alliance for Connected
Industries and Automation (5G-ACIA) brings together widely varying 5G
stakeholders including Information and Communication Technology (ICT)
players and Operational Technology (OT) companies, e.g.: industrial
automation enterprises, machine builders, and end users. Another
example is the 5G Automotive Association (5GAA), which bridges ICT
and automotive technology companies to develop end-to-end solutions
for future mobility and transportation services.
6.2. General Characteristics
The 5G Radio Access Network (5G RAN) with its NR interface includes
several features to achieve Quality of Service (QoS), such as a
guaranteeably low latency or tolerable packet error rates for
selected data flows. Determinism is achieved by centralized
admission control and scheduling of the wireless frequency resources,
which are typically licensed frequency bands assigned to a network
operator.
Thubert, et al. Expires 6 August 2022 [Page 36]
Internet-Draft RAW Technologies February 2022
NR enables short transmission slots in a radio subframe, which
benefits low-latency applications. NR also introduces mini-slots,
where prioritized transmissions can be started without waiting for
slot boundaries, further reducing latency. As part of giving
priority and faster radio access to URLLC traffic, NR introduces
preemption where URLLC data transmission can preempt ongoing non-
URLLC transmissions. Additionally, NR applies very fast processing,
enabling retransmissions even within short latency bounds.
NR defines extra-robust transmission modes for increased reliability
both for data and control radio channels. Reliability is further
improved by various techniques, such as multi-antenna transmission,
the use of multiple frequency carriers in parallel and packet
duplication over independent radio links. NR also provides full
mobility support, which is an important reliability aspect not only
for devices that are moving, but also for devices located in a
changing environment.
Network slicing is seen as one of the key features for 5G, allowing
vertical industries to take advantage of 5G networks and services.
Network slicing is about transforming a Public Land Mobile Network
(PLMN) from a single network to a network where logical partitions
are created, with appropriate network isolation, resources, optimized
topology and specific configuration to serve various service
requirements. An operator can configure and manage the mobile
network to support various types of services enabled by 5G, for
example eMBB and URLLC, depending on the different customers' needs.
Exposure of capabilities of 5G Systems to the network or applications
outside the 3GPP domain have been added to Release 16 [TS23501]. Via
exposure interfaces, applications can access 5G capabilities, e.g.,
communication service monitoring and network maintenance.
For several generations of mobile networks, 3GPP has considered how
the communication system should work on a global scale with billions
of users, taking into account resilience aspects, privacy regulation,
protection of data, encryption, access and core network security, as
well as interconnect. Security requirements evolve as demands on
trustworthiness increase. For example, this has led to the
introduction of enhanced privacy protection features in 5G. 5G also
employs strong security algorithms, encryption of traffic, protection
of signaling and protection of interfaces.
One particular strength of mobile networks is the authentication,
based on well-proven algorithms and tightly coupled with a global
identity management infrastructure. Since 3G, there is also mutual
authentication, allowing the network to authenticate the device and
the device to authenticate the network. Another strength is secure
Thubert, et al. Expires 6 August 2022 [Page 37]
Internet-Draft RAW Technologies February 2022
solutions for storage and distribution of keys fulfilling regulatory
requirements and allowing international roaming. When connecting to
5G, the user meets the entire communication system, where security is
the result of standardization, product security, deployment,
operations and management as well as incident handling capabilities.
The mobile networks approach the entirety in a rather coordinated
fashion which is beneficial for security.
6.3. Deployment and Spectrum
The 5G system allows deployment in a vast spectrum range, addressing
use-cases in both wide-area as well as local networks. Furthermore,
5G can be configured for public and non-public access.
When it comes to spectrum, NR allows combining the merits of many
frequency bands, such as the high bandwidths in millimeter Waves
(mmW) for extreme capacity locally, as well as the broad coverage
when using mid- and low frequency bands to address wide-area
scenarios. URLLC is achievable in all these bands. Spectrum can be
either licensed, which means that the license holder is the only
authorized user of that spectrum range, or unlicensed, which means
that anyone who wants to use the spectrum can do so.
A prerequisite for critical communication is performance
predictability, which can be achieved by the full control of the
access to the spectrum, which 5G provides. Licensed spectrum
guarantees control over spectrum usage by the system, making it a
preferable option for critical communication. However, unlicensed
spectrum can provide an additional resource for scaling non-critical
communications. While NR is initially developed for usage of
licensed spectrum, the functionality to access also unlicensed
spectrum was introduced in 3GPP Release 16. Moreover, URLLC features
are enhanced in Release 17 [RP210854] to be better applicable to
unlicensed spectrum.
Licensed spectrum dedicated to mobile communications has been
allocated to mobile service providers, i.e. issued as longer-term
licenses by national administrations around the world. These
licenses have often been associated with coverage requirements and
issued across whole countries, or in large regions. Besides this,
configured as a non-public network (NPN) deployment, 5G can provide
network services also to a non-operator defined organization and its
premises such as a factory deployment. By this isolation, quality of
service requirements, as well as security requirements can be
achieved. An integration with a public network, if required, is also
possible. The non-public (local) network can thus be interconnected
with a public network, allowing devices to roam between the networks.
Thubert, et al. Expires 6 August 2022 [Page 38]
Internet-Draft RAW Technologies February 2022
In an alternative model, some countries are now in the process of
allocating parts of the 5G spectrum for local use to industries.
These non-service providers then have a choice of applying for a
local license themselves and operating their own network or
cooperating with a public network operator or service provider.
6.4. Applicability to Deterministic Flows
6.4.1. System Architecture
The 5G system [TS23501] consists of the User Equipment (UE) at the
terminal side, and the Radio Access Network (RAN) with the gNB as
radio base station node, as well as the Core Network (CN). The core
network is based on a service-based architecture with the central
functions: Access and Mobility Management Function (AMF), Session
Management Function (SMF) and User Plane Function (UPF) as
illustrated in Figure 10.
The gNB's main responsibility is the radio resource management,
including admission control and scheduling, mobility control and
radio measurement handling. The AMF handles the UE's connection
status and security, while the SMF controls the UE's data sessions.
The UPF handles the user plane traffic.
The SMF can instantiate various Packet Data Unit (PDU) sessions for
the UE, each associated with a set of QoS flows, i.e., with different
QoS profiles. Segregation of those sessions is also possible, e.g.,
resource isolation in the RAN and in the CN can be defined (slicing).
Thubert, et al. Expires 6 August 2022 [Page 39]
Internet-Draft RAW Technologies February 2022
+----+ +---+ +---+ +---+ +---+ +---+
|NSSF| |NEF| |NRF| |PCF| |UDM| |AF |
+--+-+ +-+-+ +-+-+ +-+-+ +-+-+ +-+-+
| | | | | |
Nnssf| Nnef| Nnrf| Npcf| Nudm| Naf|
| | | | | |
---+------+-+-----+-+------------+--+-----+-+---
| | | |
Nausf| Nausf| Nsmf| |
| | | |
+--+-+ +-+-+ +-+-+ +-+-+
|AUSF| |AMF| |SMF| |SCP|
+----+ +++-+ +-+-+ +---+
/ | |
/ | |
/ | |
N1 N2 N4
/ | |
/ | |
/ | |
+--+-+ +--+--+ +--+---+ +----+
| UE +---+(R)AN+--N3--+ UPF +--N6--+ DN |
+----+ +-----+ ++----++ +----+
| |
+-N9-+
Figure 10: 5G System Architecture
Thubert, et al. Expires 6 August 2022 [Page 40]
Internet-Draft RAW Technologies February 2022
To allow UE mobility across cells/gNBs, handover mechanisms are
supported in NR. For an established connection, i.e., connected mode
mobility, a gNB can configure a UE to report measurements of received
signal strength and quality of its own and neighbouring cells,
periodically or event-based. Based on these measurement reports, the
gNB decides to handover a UE to another target cell/gNB. Before
triggering the handover, it is hand-shaked with the target gNB based
on network signalling. A handover command is then sent to the UE and
the UE switches its connection to the target cell/gNB. The Packet
Data Convergence Protocol (PDCP) of the UE can be configured to avoid
data loss in this procedure, i.e., handle retransmissions if needed.
Data forwarding is possible between source and target gNB as well.
To improve the mobility performance further, i.e., to avoid
connection failures, e.g., due to too-late handovers, the mechanism
of conditional handover is introduced in Release 16 specifications.
Therein a conditional handover command, defining a triggering point,
can be sent to the UE before UE enters a handover situation. A
further improvement that has been introduced in Release 16 is the
Dual Active Protocol Stack (DAPS), where the UE maintains the
connection to the source cell while connecting to the target cell.
This way, potential interruptions in packet delivery can be avoided
entirely.
6.4.2. Overview of The Radio Protocol Stack
The protocol architecture for NR consists of the L1 Physical layer
(PHY) and as part of the L2, the sublayers of Medium Access Control
(MAC), Radio Link Control (RLC), Packet Data Convergence Protocol
(PDCP), as well as the Service Data Adaption Protocol (SDAP).
The PHY layer handles signal processing related actions, such as
encoding/decoding of data and control bits, modulation, antenna
precoding and mapping.
The MAC sub-layer handles multiplexing and priority handling of
logical channels (associated with QoS flows) to transport blocks for
PHY transmission, as well as scheduling information reporting and
error correction through Hybrid Automated Repeat Request (HARQ).
The RLC sublayer handles sequence numbering of higher layer packets,
retransmissions through Automated Repeat Request (ARQ), if
configured, as well as segmentation and reassembly and duplicate
detection.
The PDCP sublayer consists of functionalities for ciphering/
deciphering, integrity protection/verification, re-ordering and in-
order delivery, duplication and duplicate handling for higher layer
packets, and acts as the anchor protocol to support handovers.
Thubert, et al. Expires 6 August 2022 [Page 41]
Internet-Draft RAW Technologies February 2022
The SDAP sublayer provides services to map QoS flows, as established
by the 5G core network, to data radio bearers (associated with
logical channels), as used in the 5G RAN.
Additionally, in RAN, the Radio Resource Control (RRC) protocol,
handles the access control and configuration signalling for the
aforementioned protocol layers. RRC messages are considered L3 and
thus transmitted also via those radio protocol layers.
To provide low latency and high reliability for one transmission
link, i.e., to transport data (or control signaling) of one radio
bearer via one carrier, several features have been introduced on the
user plane protocols for PHY and L2, as explained in the following.
6.4.3. Radio (PHY)
NR is designed with native support of antenna arrays utilizing
benefits from beamforming, transmissions over multiple MIMO layers
and advanced receiver algorithms allowing effective interference
cancellation. Those antenna techniques are the basis for high signal
quality and effectiveness of spectral usage. Spatial diversity with
up to 4 MIMO layers in UL and up to 8 MIMO layers in DL is supported.
Together with spatial-domain multiplexing, antenna arrays can focus
power in desired direction to form beams. NR supports beam
management mechanisms to find the best suitable beam for UE initially
and when it is moving. In addition, gNBs can coordinate their
respective DL and UL transmissions over the backhaul network keeping
interference reasonably low, and even make transmissions or
receptions from multiple points (multi-TRP). Multi-TRP can be used
for repetition of data packet in time, in frequency or over multiple
MIMO layers which can improve reliability even further.
Any downlink transmission to a UE starts from resource allocation
signaling over the Physical Downlink Control Channel (PDCCH). If it
is successfully received, the UE will know about the scheduled
transmission and may receive data over the Physical Downlink Shared
Channel (PDSCH). If retransmission is required according to the HARQ
scheme, a signaling of negative acknowledgement (NACK) on the
Physical Uplink Control Channel (PUCCH) is involved and PDCCH
together with PDSCH transmissions (possibly with additional
redundancy bits) are transmitted and soft-combined with previously
received bits. Otherwise, if no valid control signaling for
scheduling data is received, nothing is transmitted on PUCCH
(discontinuous transmission - DTX),and the base station upon
detecting DTX will retransmit the initial data.
Thubert, et al. Expires 6 August 2022 [Page 42]
Internet-Draft RAW Technologies February 2022
An uplink transmission normally starts from a Scheduling Request (SR)
- a signaling message from the UE to the base station sent via PUCCH.
Once the scheduler is informed about buffer data in UE, e.g., by SR,
the UE transmits a data packet on the Physical Uplink Shared Channel
(PUSCH). Pre-scheduling not relying on SR is also possible (see
following section).
Since transmission of data packets require usage of control and data
channels, there are several methods to maintain the needed
reliability. NR uses Low Density Parity Check (LDPC) codes for data
channels, Polar codes for PDCCH, as well as orthogonal sequences and
Polar codes for PUCCH. For ultra-reliability of data channels, very
robust (low spectral efficiency) Modulation and Coding Scheme (MCS)
tables are introduced containing very low (down to 1/20) LDPC code
rates using BPSK or QPSK. Also, PDCCH and PUCCH channels support
multiple code rates including very low ones for the channel
robustness.
A connected UE reports downlink (DL) quality to gNB by sending
Channel State Information (CSI) reports via PUCCH while uplink (UL)
quality is measured directly at gNB. For both uplink and downlink,
gNB selects the desired MCS number and signals it to the UE by
Downlink Control Information (DCI) via PDCCH channel. For URLLC
services, the UE can assist the gNB by advising that MCS targeting
10^-5 Block Error Rate (BLER) are used. Robust link adaptation
algorithms can maintain the needed level of reliability considering a
given latency bound.
Low latency on the physical layer is provided by short transmission
duration which is possible by using high Subcarrier Spacing (SCS) and
the allocation of only one or a few Orthogonal Frequency Division
Multiplexing (OFDM) symbols. For example, the shortest latency for
the worst case in DL can be 0.23ms and in UL can be 0.24ms according
to (section 5.7.1 in [TR37910]). Moreover, if the initial
transmission has failed, HARQ feedback can quickly be provided and an
HARQ retransmission is scheduled.
Thubert, et al. Expires 6 August 2022 [Page 43]
Internet-Draft RAW Technologies February 2022
Dynamic multiplexing of data associated with different services is
highly desirable for efficient use of system resources and to
maximize system capacity. Assignment of resources for eMBB is
usually done with regular (longer) transmission slots, which can lead
to blocking of low latency services. To overcome the blocking, eMBB
resources can be pre-empted and re-assigned to URLLC services. In
this way, spectrally efficient assignments for eMBB can be ensured
while providing flexibility required to ensure a bounded latency for
URLLC services. In downlink, the gNB can notify the eMBB UE about
pre-emption after it has happened, while in uplink there are two pre-
emption mechanisms: special signaling to cancel eMBB transmission and
URLLC dynamic power boost to suppress eMBB transmission.
6.4.4. Scheduling and QoS (MAC)
One integral part of the 5G system is the Quality of Service (QoS)
framework [TS23501]. QoS flows are setup by the 5G system for
certain IP or Ethernet packet flows, so that packets of each flow
receive the same forwarding treatment, i.e., in scheduling and
admission control. QoS flows can for example be associated with
different priority level, packet delay budgets and tolerable packet
error rates. Since radio resources are centrally scheduled in NR,
the admission control function can ensure that only those QoS flows
are admitted for which QoS targets can be reached.
NR transmissions in both UL and DL are scheduled by the gNB
[TS38300]. This ensures radio resource efficiency, fairness in
resource usage of the users and enables differentiated treatment of
the data flows of the users according to the QoS targets of the
flows. Those QoS flows are handled as data radio bearers or logical
channels in NR RAN scheduling.
The gNB can dynamically assign DL and UL radio resources to users,
indicating the resources as DL assignments or UL grants via control
channel to the UE. Radio resources are defined as blocks of OFDM
symbols in spectral domain and time domain. Different lengths are
supported in time domain, i.e., (multiple) slot or mini-slot lengths.
Resources of multiple frequency carriers can be aggregated and
jointly scheduled to the UE.
Scheduling decisions are based, e.g., on channel quality measured on
reference signals and reported by the UE (cf. periodical CSI reports
for DL channel quality). The transmission reliability can be chosen
in the scheduling algorithm, i.e., by link adaptation where an
appropriate transmission format (e.g., robustness of modulation and
coding scheme, controlled UL power) is selected for the radio channel
condition of the UE. Retransmissions, based on HARQ feedback, are
also controlled by the scheduler. The feedback transmission in HARQ
Thubert, et al. Expires 6 August 2022 [Page 44]
Internet-Draft RAW Technologies February 2022
loop introduces delays, but there are methods to minimize it by using
short transmission formats, sub-slot feedback reporting and PUCCH
carrier switching. If needed to avoid HARQ round-trip time delays,
repeated transmissions can be also scheduled beforehand, to the cost
of reduced spectral efficiency.
In dynamic DL scheduling, transmission can be initiated immediately
when DL data becomes available in the gNB. However, for dynamic UL
scheduling, when data becomes available but no UL resources are
available yet, the UE indicates the need for UL resources to the gNB
via a (single bit) scheduling request message in the UL control
channel. When thereupon UL resources are scheduled to the UE, the UE
can transmit its data and may include a buffer status report,
indicating the exact amount of data per logical channel still left to
be sent. More UL resources may be scheduled accordingly. To avoid
the latency introduced in the scheduling request loop, UL radio
resources can also be pre-scheduled.
In particular for periodical traffic patterns, the pre-scheduling can
rely on the scheduling features DL Semi-Persistent Scheduling (SPS)
and UL Configured Grant (CG). With these features, periodically
recurring resources can be assigned in DL and UL. Multiple parallels
of those configurations are supported, in order to serve multiple
parallel traffic flows of the same UE.
To support QoS enforcement in the case of mixed traffic with
different QoS requirements, several features have recently been
introduced. This way, e.g., different periodical critical QoS flows
can be served together with best effort transmissions, by the same
UE. Among others, these features (partly Release 16) are: 1) UL
logical channel transmission restrictions allowing to map logical
channels of certain QoS only to intended UL resources of a certain
frequency carrier, slot-length, or CG configuration, and 2) intra-UE
pre-emption and multiplexing, allowing critical UL transmissions to
either pre-empt non-critical transmissions or being multiplexed with
non-critical transmissions keeping different reliability targets.
When multiple frequency carriers are aggregated, duplicate parallel
transmissions can be employed (beside repeated transmissions on one
carrier). This is possible in the Carrier Aggregation (CA)
architecture where those carriers originate from the same gNB, or in
the Dual Connectivity (DC) architecture where the carriers originate
from different gNBs, i.e., the UE is connected to two gNBs in this
case. In both cases, transmission reliability is improved by this
means of providing frequency diversity.
Thubert, et al. Expires 6 August 2022 [Page 45]
Internet-Draft RAW Technologies February 2022
In addition to licensed spectrum, a 5G system can also utilize
unlicensed spectrum to offload non-critical traffic. This version of
NR is called NR-U, part of 3GPP Release 16. The central scheduling
approach applies also for unlicensed radio resources, but in addition
also the mandatory channel access mechanisms for unlicensed spectrum,
e.g., Listen Before Talk (LBT) are supported in NR-U. This way, by
using NR, operators have and can control access to both licensed and
unlicensed frequency resources.
6.4.5. Time-Sensitive Communications (TSC)
Recent 3GPP releases have introduced various features to support
multiple aspects of Time-Sensitive Communication ((TSC), which
includes Time- Sensitive Networking (TSN) and beyond as described in
this section.
The main objective of Time-Sensitive Networking (TSN) is to provide
guaranteed data delivery within a guaranteed time window, i.e.,
bounded low latency. IEEE 802.1 TSN [IEEE802.1TSN] is a set of open
standards that provide features to enable deterministic communication
on standard IEEE 802.3 Ethernet [IEEE802.3]. TSN standards can be
seen as a toolbox for traffic shaping, resource management, time
synchronization, and reliability.
A TSN stream is a data flow between one end station (Talker) to
another end station (Listener). In the centralized configuration
model, TSN bridges are configured by the Central Network Controller
(CNC) [IEEE802.1Qcc] to provide deterministic connectivity for the
TSN stream through the network. Time-based traffic shaping provided
by Scheduled Traffic [IEEE802.1Qbv] may be used to achieve bounded
low latency. The TSN tool for time synchronization is the
generalized Precision Time Protocol (gPTP) [IEEE802.1AS]), which
provides reliable time synchronization that can be used by end
stations and by other TSN tools, e.g., Scheduled Traffic
[IEEE802.1Qbv]. High availability, as a result of ultra-reliability,
is provided for data flows by the Frame Replication and Elimination
for Reliability (FRER) [IEEE802.1CB] mechanism.
3GPP Release 16 includes integration of 5G with TSN, i.e., specifies
functions for the 5G System (5GS) to deliver TSN streams such that
the meet their QoS requirements. A key aspect of the integration is
the 5GS appears from the rest of the network as a set of TSN bridges,
in particular, one virtual bridge per User Plane Function (UPF) on
the user plane. The 5GS includes TSN Translator (TT) functionality
for the adaptation of the 5GS to the TSN bridged network and for
hiding the 5GS internal procedures. The 5GS provides the following
components:
Thubert, et al. Expires 6 August 2022 [Page 46]
Internet-Draft RAW Technologies February 2022
1. interface to TSN controller, as per [IEEE802.1Qcc] for the fully
centralized configuration model
2. time synchronization via reception and transmission of gPTP PDUs
[IEEE802.1AS]
3. low latency, hence, can be integrated with Scheduled Traffic
[IEEE802.1Qbv]
4. reliability, hence, can be integrated with FRER [IEEE802.1CB]
3GPP Release 17 [TS23501] introduced enhancements to generalize
support for Time-Sensitive Communications (TSC) beyond TSN. This
includes IP communications to provide time-sensitive service to,
e.g., Video, Imaging and Audio for Professional Applications (VIAPA).
The system model of 5G acting as a "TSN bridge" in Release 16 has
been reused to enable the 5GS acting as a "TSC node" in a more
generic sense (which includes TSN bridge and IP node). In the case
of TSC that does not involve TSN, requirements are given via exposure
interface and the control plane provides the service based on QoS and
time synchronization requests from an Application Function (AF).
Figure 10 shows an illustration of 5G-TSN integration where an
industrial controller (Ind Ctrlr) is connected to industrial Input/
Output devices (I/O dev) via 5G. The 5GS can directly transport
Ethernet frames since Release 15, thus, end-to-end Ethernet
connectivity is provided. The 5GS implements the required interfaces
towards the TSN controller functions such as the CNC, thus adapts to
the settings of the TSN network. A 5G user plane virtual bridge
interconnects TSN bridges or connect end stations, e.g., I/O devices
to the network. Note that the introduction of 5G brings flexibility
in various aspects, e.g., more flexible network topology because a
wireless hop can replace several wireline hops thus significantly
reduce the number of hops end-to-end. [TSN5G] dives more into the
integration of 5G with TSN.
Thubert, et al. Expires 6 August 2022 [Page 47]
Internet-Draft RAW Technologies February 2022
+------------------------------+
| 5G System |
| +---+|
| +-+ +-+ +-+ +-+ +-+ |TSN||
| | | | | | | | | | | |AF |......+
| +++ +++ +++ +++ +++ +-+-+| .
| | | | | | | | .
| -+---+---++--+-+-+--+-+- | .
| | | | | | +--+--+
| +++ +++ +++ +++ | | TSN |
| | | | | | | | | | |Ctrlr+.......+
| +++ +++ +++ +++ | +--+--+ .
| | . .
| | . .
| +..........................+ | . .
| . Virtual Bridge . | . .
+---+ | . +--+--+ +---+ +---+--+ . | +--+---+ .
|I/O+----------------+DS|UE+---+RAN+-+UPF|NW+------+ TSN +----+ .
|dev| | . |TT| | | | | |TT| . | |bridge| | .
+---+ | . +--+--+ +---+ +---+--+ . | +------+ | .
| +..........................+ | . +-+-+-+
| | . | Ind |
| +..........................+ | . |Ctrlr|
| . Virtual Bridge . | . +-+---+
+---+ +------+ | . +--+--+ +---+ +---+--+ . | +--+---+ |
|I/O+--+ TSN +------+DS|UE+---+RAN+-+UPF|NW+------+ TSN +----+
|dev| |bridge| | . |TT| | | | | |TT| . | |bridge|
+---+ +------+ | . +--+--+ +---+ +---+--+ . | +------+
| +..........................+ |
+------------------------------+
<----------------- end-to-end Ethernet ------------------->
Figure 11: 5G - TSN Integration
NR supports accurate reference time synchronization in 1us accuracy
level. Since NR is a scheduled system, an NR UE and a gNB are
tightly synchronized to their OFDM symbol structures. A 5G internal
reference time can be provided to the UE via broadcast or unicast
signaling, associating a known OFDM symbol to this reference clock.
The 5G internal reference time can be shared within the 5G network,
i.e., radio and core network components. Release 16 has introduced
interworking with gPTP for multiple time domains, where the 5GS acts
as a virtual gPTP time-aware system and supports the forwarding of
gPTP time synchronization information between end stations and
bridges through the 5G user plane TTs. These account for the
residence time of the 5GS in the time synchronization procedure. One
special option is when the 5GS internal reference time in not only
Thubert, et al. Expires 6 August 2022 [Page 48]
Internet-Draft RAW Technologies February 2022
used within the 5GS, but also to the rest of the devices in the
deployment, including connected TSN bridges and end stations.
Release 17 includes further improvements, i.e., methods for
propagation delay compensation in RAN, further improving the accuracy
for time synchronization over-the-air, as well as the possibility for
the TSN grandmaster clock to reside on the UE side. More extensions
and flexibility were added to the time synchronization service making
it general for TSC with additional support of other types of clocks
and time distribution such as boundary clock, transparent clock peer-
to-peer, transparent clock end-to-end, aside from the time-aware
system used for TSN. Additionally, it is possible to use internal
access stratum signaling to distribute timing (and not the usual
(g)PTP messages), for which the required accuracy can be provided by
the AF [TS23501]. The same time synchronization service is expected
to be further extended and enhanced in Release 18 to support Timing
Resiliency (according to study item [SP211634]), where the 5G system
can provide a back-up or alternative timing source for the failure of
the local GNSS source (or other primary timing source) used by the
vertical.
IETF Deterministic Networking (DetNet) is the technology to support
time-sensitive communications at the IP layer. 3GPP Release 18
includes a study [SP211633] on whether and how to enable 3GPP support
for DetNet such that a mapping is provided between DetNet and 5G.
The support for DetNet is considered to be added via the TSC
framework introduced for Release 17. The study includes what
information needs to be exposed by the 5G System and the translation
of DetNet flow specification to 5G QoS parameters. Note that TSN is
the primary subnetwork technology for DetNet. Thus, the DetNet over
TSN work, e.g., [RFC9023], can be leveraged via the TSN support built
in 5G. As the standards are ready for such an approach, it is out of
scope for the 3GPP Release 18 study item [SP211633].
Thubert, et al. Expires 6 August 2022 [Page 49]
Internet-Draft RAW Technologies February 2022
Redundancy architectures were specified in order to provide
reliability against any kind of failure on the radio link or nodes in
the RAN and the core network, Redundant user plane paths can be
provided based on the dual connectivity architecture, where the UE
sets up two PDU sessions towards the same data network, and the 5G
system makes the paths of the two PDU sessions independent as
illustrated in Figure 13. There are two PDU sessions involved in the
solution: the first spans from the UE via gNB1 to UPF1, acting as the
first PDU session anchor, while the second spans from the UE via gNB2
to UPF2, acting as second the PDU session anchor. The independent
paths may continue beyond the 3GPP network. Redundancy Handling
Functions (RHFs) are deployed outside of the 5GS, i.e., in Host A
(the device) and in Host B (the network). RHF can implement
replication and elimination functions as per [IEEE802.1CB] or the
Packet Replication, Elimination, and Ordering Functions (PREOF) of
IETF Deterministic Networking (DetNet) [RFC8655].
+........+
. Device . +------+ +------+ +------+
. . + gNB1 +--N3--+ UPF1 |--N6--+ |
. ./+------+ +------+ | |
. +----+ / | |
. | |/. | |
. | UE + . | DN |
. | |\. | |
. +----+ \ | |
. .\+------+ +------+ | |
+........+ + gNB2 +--N3--+ UPF2 |--N6--+ |
+------+ +------+ +------+
Figure 12: Reliability with Single UE
An alternative solution is that multiple UEs per device are used for
user plane redundancy as illustrated in Figure 13. Each UE sets up a
PDU session. The 5GS ensures that those PDU sessions of the
different UEs are handled independently internal to the 5GS. There
is no single point of failure in this solution, which also includes
RHF outside of the 5G system, e.g., as per FRER or as PREOF
specifications.
Thubert, et al. Expires 6 August 2022 [Page 50]
Internet-Draft RAW Technologies February 2022
+.........+
. Device .
. .
. +----+ . +------+ +------+ +------+
. | UE +-----+ gNB1 +--N3--+ UPF1 |--N6--+ |
. +----+ . +------+ +------+ | |
. . | DN |
. +----+ . +------+ +------+ | |
. | UE +-----+ gNB2 +--N3--+ UPF2 |--N6--+ |
. +----+ . +------+ +------+ +------+
. .
+.........+
Figure 13: Reliability with Dual UE
Note that the abstraction provided by the RHF and the location of the
RHF being outside of the 5G system make 5G equally supporting
integration for reliability both with FRER of TSN and PREOF of DetNet
as they both rely on the same concept.
6.5. Summary
5G technology enables deterministic communication. Based on the
centralized admission control and the scheduling of the wireless
resources, licensed or unlicensed, quality of service such as latency
and reliability can be guaranteed. 5G contains several features to
achieve ultra-reliable and low latency performance, e.g., support for
different OFDM numerologies and slot-durations, as well as fast
processing capabilities and redundancy techniques that lead to
achievable latency numbers of below 1ms with 99.999% or higher
confidence.
5G also includes features to support Industrial IoT use cases, e.g.,
via the integration of 5G with TSN. This includes 5G capabilities
for each TSN component, latency, resource management, time
synchronization, and reliability. Furthermore, 5G support for TSN
can be leveraged when 5G is used as subnet technology for DetNet, in
combination with or instead of TSN, which is the primary subnet for
DetNet. In addition, the support for integration with TSN
reliability was added to 5G by making DetNet reliability also
applicable, thus making 5G DetNet ready. Moreover, providing IP
service is native to 5G and adding direct support for DetNet is in
scope of the upcoming 3GPP Release 18.
Overall, 5G provides scheduled wireless segments with high
reliability and availability. In addition, 5G includes capabilities
for integration to IP networks.
Thubert, et al. Expires 6 August 2022 [Page 51]
Internet-Draft RAW Technologies February 2022
7. L-band Digital Aeronautical Communications System
One of the main pillars of the modern Air Traffic Management (ATM)
system is the existence of a communication infrastructure that
enables efficient aircraft guidance and safe separation in all phases
of flight. Although current systems are technically mature, they are
suffering from the VHF band's increasing saturation in high-density
areas and the limitations posed by analogue radio. Therefore,
aviation globally and the European Union (EU) in particular, strives
for a sustainable modernization of the aeronautical communication
infrastructure.
In the long-term, ATM communication shall transition from analogue
VHF voice and VDL2 communication to more spectrum efficient digital
data communication. The European ATM Master Plan foresees this
transition to be realized for terrestrial communications by the
development and implementation of the L-band Digital Aeronautical
Communications System (LDACS). LDACS shall enable IPv6 based air-
ground communication related to the safety and regularity of the
flight. The particular challenge is that no new frequencies can be
made available for terrestrial aeronautical communication. It was
thus necessary to develop procedures to enable the operation of LDACS
in parallel with other services in the same frequency band.
7.1. Provenance and Documents
The development of LDACS has already made substantial progress in the
Single European Sky ATM Research (SESAR) framework, and is currently
being continued in the follow-up program, SESAR2020 [RIH18]. A key
objective of the SESAR activities is to develop, implement and
validate a modern aeronautical data link able to evolve with aviation
needs over long-term. To this end, an LDACS specification has been
produced [GRA19] and is continuously updated; transmitter
demonstrators were developed to test the spectrum compatibility of
LDACS with legacy systems operating in the L-band [SAJ14]; and the
overall system performance was analyzed by computer simulations,
indicating that LDACS can fulfill the identified requirements
[GRA11].
LDACS standardization within the framework of the International Civil
Aviation Organization (ICAO) started in December 2016. The ICAO
standardization group has produced an initial Standards and
Recommended Practices (SARPs) document [ICAO18]. The SARPs document
defines the general characteristics of LDACS. The ICAO
standardization group plans to produce an ICAO technical manual - the
ICAO equivalent to a technical standard - within the next years.
Generally, the group is open to input from all sources and develops
LDACS in the open.
Thubert, et al. Expires 6 August 2022 [Page 52]
Internet-Draft RAW Technologies February 2022
Up to now the LDACS standardization has been focused on the
development of the physical layer and the data link layer, only
recently have higher layers come into the focus of the LDACS
development activities. There is currently no "IPv6 over LDACS"
specification; however, SESAR2020 has started the testing of
IPv6-based LDACS testbeds. The IPv6 architecture for the
aeronautical telecommunication network is called the Future
Communications Infrastructure (FCI). FCI shall support quality of
service, diversity, and mobility under the umbrella of the "multi-
link concept". This work is conducted by ICAO working group WG-I.
In addition to standardization activities several industrial LDACS
prototypes have been built. One set of LDACS prototypes has been
evaluated in flight trials confirming the theoretical results
predicting the system performance [GRA18][SCH19].
7.2. General Characteristics
LDACS will become one of several wireless access networks connecting
aircraft to the Aeronautical Telecommunications Network (ATN). The
LDACS access network contains several ground stations, each of them
providing one LDACS radio cell. The LDACS air interface is a
cellular data link with a star-topology connecting aircraft to
ground-stations with a full duplex radio link. Each ground-station
is the centralized instance controlling all air-ground communications
within its radio cell.
The user data rate of LDACS is 315 kbit/s to 1428 kbit/s on the
forward link, and 294 kbit/s to 1390 kbit/s on the reverse link,
depending on coding and modulation. Due to strong interference from
legacy systems in the L-band, the most robust coding and modulation
SHOULD be expected for initial deployment i.e. 315/294 kbit/s on the
forward/reverse link, respectively.
In addition to the communications capability, LDACS also offers a
navigation capability. Ranging data, similar to DME (Distance
Measuring Equipment), is extracted from the LDACS communication links
between aircraft and LDACS ground stations. This results in LDACS
providing an APNT (Alternative Position, Navigation and Timing)
capability to supplement the existing on-board GNSS (Global
Navigation Satellite System) without the need for additional
bandwidth. Operationally, there will be no difference for pilots
whether the navigation data are provided by LDACS or DME. This
capability was flight tested and proven during the MICONAV flight
trials in 2019 [BAT19].
Thubert, et al. Expires 6 August 2022 [Page 53]
Internet-Draft RAW Technologies February 2022
In previous works and during the MICONAV flight campaign in 2019, it
was also shown, that LDACS can be used for surveillance capability.
Filip et al. [FIL19] shown passive radar capabilities of LDACS and
Automatic Dependence Surveillance - Contract (ADS-C) was demonstrated
via LDACS during the flight campaign 2019 [SCH19].
Since LDACS has been mainly designed for air traffic management
communication it supports mutual entity authentication, integrity and
confidentiality capabilities of user data messages and some control
channel protection capabilities [MAE18], [MAE191], [MAE192], [MAE20].
Overall this makes LDACS the world's first truly integrated CNS
system and is the worldwide most mature, secure, terrestrial long-
range CNS technology for civil aviation.
7.3. Deployment and Spectrum
LDACS has its origin in merging parts of the B-VHF [BRA06], B-AMC
[SCH08], TIA-902 (P34) [HAI09], and WiMAX IEEE 802.16e technologies
[EHA11]. In 2007 the spectrum for LDACS was allocated at the World
Radio Conference (WRC).
It was decided to allocate the spectrum next to Distance Measuring
Equipment (DME), resulting in an in-lay approach between the DME
channels for LDAC [SCH14].
LDACS is currently being standardized by ICAO and several roll-out
strategies are discussed:
The LDACS data link provides enhanced capabilities to existing
Aeronautical communications infrastructure enabling them to better
support user needs and new applications. The deployment scalability
of LDACS allows its implementation to start in areas where most
needed to Improve immediately the performance of already fielded
infrastructure. Later the deployment is extended based on
operational demand. An attractive scenario for upgrading the
existing VHF communication systems by adding an additional LDACS data
link is described below.
When considering the current VDL Mode 2 infrastructure and user base,
a very attractive win-win situation comes about, when the
technological advantages of LDACS are combined with the existing VDL
mode 2 infrastructure. LDACS provides at least 50 time more capacity
than VDL Mode 2 and is a natural enhancement to the existing VDL Mode
2 business model. The advantage of this approach is that the VDL
Mode 2 infrastructure can be fully reused. Beyond that, it opens the
way for further enhancements which can increase business efficiency
and minimize investment risk. [ICAO19]
Thubert, et al. Expires 6 August 2022 [Page 54]
Internet-Draft RAW Technologies February 2022
7.4. Applicability to Deterministic Flows
As LDACS is a ground-based digital communications system for flight
guidance and communications related to safety and regularity of
flight, time-bounded deterministic arrival times for safety critical
messages are a key feature for its successful deployment and roll-
out.
7.4.1. System Architecture
Up to 512 Aircraft Station (AS) communicate to an LDACS Ground
Station (GS) in the Reverse Link (RL). GS communicate to AS in the
Forward Link (FL). Via an Access-Router (AC-R) GSs connect the LDACS
sub-network to the global Aeronautical Telecommunications Network
(ATN) to which the corresponding Air Traffic Services (ATS) and
Aeronautical Operational Control (AOC) end systems are attached.
7.4.2. Overview of The Radio Protocol Stack
The protocol stack of LDACS is implemented in the AS and GS: It
consists of the Physical Layer (PHY) with five major functional
blocks above it. Four are placed in the Data Link Layer (DLL) of the
AS and GS: (1) Medium Access Layer (MAC), (2) Voice Interface (VI),
(3) Data Link Service (DLS), and (4) LDACS Management Entity (LME).
The last entity resides within the Sub-Network Layer: Sub-Network
Protocol (SNP). The LDACS network is externally connected to voice
units, radio control units, and the ATN Network Layer.
Figure 14 shows the protocol stack of LDACS as implemented in the AS
and GS.
Thubert, et al. Expires 6 August 2022 [Page 55]
Internet-Draft RAW Technologies February 2022
IPv6 Network Layer
|
|
+------------------+ +----+
| SNP |--| | Sub-Network
| | | | Layer
+------------------+ | |
| | LME|
+------------------+ | |
| DLS | | | Logical Link
| | | | Control Layer
+------------------+ +----+
| |
DCH DCCH/CCCH
| RACH/BCCH
| |
+--------------------------+
| MAC | Medium Access
| | Layer
+--------------------------+
|
+--------------------------+
| PHY | Physical Layer
+--------------------------+
|
|
((*))
FL/RL radio channels
separated by
Frequency Division Duplex
Figure 14: LDACS protocol stack in AS and GS
7.4.3. Radio (PHY)
The physical layer provides the means to transfer data over the radio
channel. The LDACS ground-station supports bi-directional links to
multiple aircraft under its control. The forward link direction (FL;
ground-to-air) and the reverse link direction (RL; air-to-ground) are
separated by frequency division duplex. Forward link and reverse
link use a 500 kHz channel each. The ground-station transmits a
continuous stream of OFDM symbols on the forward link. In the
reverse link different aircraft are separated in time and frequency
using a combination of Orthogonal Frequency-Division Multiple-Access
(OFDMA) and Time-Division Multiple-Access (TDMA). Aircraft thus
transmit discontinuously on the reverse link with radio bursts sent
Thubert, et al. Expires 6 August 2022 [Page 56]
Internet-Draft RAW Technologies February 2022
in precisely defined transmission opportunities allocated by the
ground-station. The most important service on the PHY layer of LDACS
is the PHY time framing service, which indicates that the PHY layer
is ready to transmit in a given slot and to indicate PHY layer
framing and timing to the MAC time framing service. LDACS does not
support beam-forming or Multiple Input Multiple Output (MIMO).
7.4.4. Scheduling, Frame Structure and QoS (MAC)
The data-link layer provides the necessary protocols to facilitate
concurrent and reliable data transfer for multiple users. The LDACS
data link layer is organized in two sub-layers: The medium access
sub-layer and the logical link control sub-layer. The medium access
sub-layer manages the organization of transmission opportunities in
slots of time and frequency. The logical link control sub-layer
provides acknowledged point-to-point logical channels between the
aircraft and the ground-station using an automatic repeat request
protocol. LDACS supports also unacknowledged point-to-point channels
and ground-to-air broadcast. Before going more into depth about the
LDACS medium access, the frame structure of LDACS is introduced:
The LDACS framing structure for FL and RL is based on Super-Frames
(SF) of 240 ms duration. Each SF corresponds to 2000 OFDM symbols.
The FL and RL SF boundaries are aligned in time (from the view of the
GS).
In the FL, an SF contains a Broadcast Frame of duration 6.72 ms (56
OFDM symbols) for the Broadcast Control Channel (BCCH), and four
Multi-Frames (MF), each of duration 58.32 ms (486 OFDM symbols).
In the RL, each SF starts with a Random Access (RA) slot of length
6.72 ms with two opportunities for sending RL random access frames
for the Random Access Channel (RACH), followed by four MFs. These
MFs have the same fixed duration of 58.32 ms as in the FL, but a
different internal structure
Figure 15 and Figure 16 illustrate the LDACS frame structure.
Thubert, et al. Expires 6 August 2022 [Page 57]
Internet-Draft RAW Technologies February 2022
^
| +------+------------+------------+------------+------------+
| FL | BCCH | MF | MF | MF | MF |
F +------+------------+------------+------------+------------+
r <---------------- Super-Frame (SF) - 240ms ---------------->
e
q +------+------------+------------+------------+------------+
u RL | RACH | MF | MF | MF | MF |
e +------+------------+------------+------------+------------+
n <---------------- Super-Frame (SF) - 240ms ---------------->
c
y
|
----------------------------- Time ------------------------------>
|
Figure 15: SF structure for LDACS
^
| +-------------+------+-------------+
| FL | DCH | CCCH | DCH |
F +-------------+------+-------------+
r <---- Multi-Frame (MF) - 58.32ms -->
e
q +------+---------------------------+
u RL | DCCH | DCH |
e +------+---------------------------+
n <---- Multi-Frame (MF) - 58.32ms -->
c
y
|
-------------------- Time ------------------>
|
Figure 16: MF structure for LDACS
This fixed frame structure allows for a reliable and dependable
transmission of data. Next, the LDACS medium access layer is
introduced:
LDACS medium access is always under the control of the ground-station
of a radio cell. Any medium access for the transmission of user data
has to be requested with a resource request message stating the
requested amount of resources and class of service. The ground-
station performs resource scheduling on the basis of these requests
Thubert, et al. Expires 6 August 2022 [Page 58]
Internet-Draft RAW Technologies February 2022
and grants resources with resource allocation messages. Resource
request and allocation messages are exchanged over dedicated
contention-free control channels.
LDACS has two mechanisms to request resources from the scheduler in
the ground-station. Resources can either be requested "on demand"
with a given class of service. On the forward link, this is done
locally in the ground-station, on the reverse link a dedicated
contention-free control channel is used (Dedicated Control Channel
(DCCH); roughly 83 bit every 60 ms). A resource allocation is always
announced in the control channel of the forward link (Common Control
Channel (CCCH); variable sized). Due to the spacing of the reverse
link control channels of every 60 ms, a medium access delay in the
same order of magnitude is to be expected.
Resources can also be requested "permanently". The permanent
resource request mechanism supports requesting recurring resources in
given time intervals. A permanent resource request has to be
canceled by the user (or by the ground-station, which is always in
control). User data transmissions over LDACS are therefore always
scheduled by the ground-station, while control data uses statically
(i.e. at net entry) allocated recurring resources (DCCH and CCCH).
The current specification documents specify no scheduling algorithm.
However performance evaluations so far have used strict priority
scheduling and round robin for equal priorities for simplicity. In
the current prototype implementations LDACS classes of service are
thus realized as priorities of medium access and not as flows. Note
that this can starve out low priority flows. However, this is not
seen as a big problem since safety related message always go first in
any case. Scheduling of reverse link resources is done in physical
Protocol Data Units (PDU) of 112 bit (or larger if more aggressive
coding and modulation is used). Scheduling on the forward link is
done Byte-wise since the forward link is transmitted continuously by
the ground-station.
In order to support diversity, LDACS supports handovers to other
ground-stations on different channels. Handovers may be initiated by
the aircraft (break-before-make) or by the ground-station (make-
before-break). Beyond this, FCI diversity shall be implemented by
the multi-link concept.
7.5. Summary
LDACS has been designed with applications related to the safety and
regularity of the flight in mind. It has therefore been designed as
a deterministic wireless data link (as far as possible).
Thubert, et al. Expires 6 August 2022 [Page 59]
Internet-Draft RAW Technologies February 2022
It is a secure, scalable and spectrum efficient data link with
embedded navigation capability and thus, is the first truly
integrated CNS system recognized by ICAO. During flight tests the
LDACS capabilities have been successfully demonstrated. A viable
roll-out scenario has been developed which allows gradual
introduction of LDACS with immediate use and revenues. Finally, ICAO
is developing LDACS standards to pave the way for a successful roll-
out in the near future.
8. IANA Considerations
This specification does not require IANA action.
9. Security Considerations
Most RAW technologies integrate some authentication or encryption
mechanisms that were defined outside the IETF.
10. Contributors
This document aggregates articles from authors specialized in each
technologies. Beyond the main authors listed in the front page, the
following contributors proposed additional text and refinement that
improved the documertn greatly!
Georgios Z. Papadopoulos: Contributed to the TSCH section.
Nils Maeurer: Contributed to the LDACS section.
Thomas Graeupl: Contributed to the LDACS section.
Torsten Dudda, Alexey Shapin, and Sara Sandberg: Contributed to the
5G section.
Rocco Di Taranto: Contributed to the Wi-Fi section
Rute Sofia: Contributed to the Introduction and Terminology sections
11. Acknowledgments
Many thanks to the participants of the RAW WG where a lot of the work
discussed here happened, and Malcolm Smith for his review of the
802.11 section.
12. Normative References
Thubert, et al. Expires 6 August 2022 [Page 60]
Internet-Draft RAW Technologies February 2022
[RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T.
Phinney, "Industrial Routing Requirements in Low-Power and
Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October
2009, <https://www.rfc-editor.org/info/rfc5673>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[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>.
[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>.
13. Informative References
[RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH
Operation Sublayer (6top) Protocol (6P)", RFC 8480,
DOI 10.17487/RFC8480, November 2018,
<https://www.rfc-editor.org/info/rfc8480>.
[RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
Bryant, "Deterministic Networking (DetNet) Data Plane
Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020,
<https://www.rfc-editor.org/info/rfc8938>.
[RFC9033] Chang, T., Ed., Vučinić, M., Vilajosana, X., Duquennoy,
S., and D. Dujovne, "6TiSCH Minimal Scheduling Function
(MSF)", RFC 9033, DOI 10.17487/RFC9033, May 2021,
<https://www.rfc-editor.org/info/rfc9033>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>.
Thubert, et al. Expires 6 August 2022 [Page 61]
Internet-Draft RAW Technologies February 2022
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
and D. Barthel, "Routing Metrics Used for Path Calculation
in Low-Power and Lossy Networks", RFC 6551,
DOI 10.17487/RFC6551, March 2012,
<https://www.rfc-editor.org/info/rfc6551>.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291,
DOI 10.17487/RFC6291, June 2011,
<https://www.rfc-editor.org/info/rfc6291>.
[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
Weingarten, "An Overview of Operations, Administration,
and Maintenance (OAM) Tools", RFC 7276,
DOI 10.17487/RFC7276, June 2014,
<https://www.rfc-editor.org/info/rfc7276>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
[RFC9023] Varga, B., Ed., Farkas, J., Malis, A., and S. Bryant,
"Deterministic Networking (DetNet) Data Plane: IP over
IEEE 802.1 Time-Sensitive Networking (TSN)", RFC 9023,
DOI 10.17487/RFC9023, June 2021,
<https://www.rfc-editor.org/info/rfc9023>.
[I-D.ietf-raw-architecture]
Thubert, P. and G. Z. Papadopoulos, "Reliable and
Available Wireless Architecture", Work in Progress,
Internet-Draft, draft-ietf-raw-architecture-03, 14 January
2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
raw-architecture-03>.
[I-D.ietf-roll-nsa-extension]
Koutsiamanis, R., Papadopoulos, G., Montavont, N., and P.
Thubert, "Common Ancestor Objective Function and Parent
Set DAG Metric Container Extension", Work in Progress,
Internet-Draft, draft-ietf-roll-nsa-extension-10, 29
October 2020, <https://datatracker.ietf.org/doc/html/
draft-ietf-roll-nsa-extension-10>.
[I-D.papadopoulos-paw-pre-reqs]
Papadopoulos, G., Koutsiamanis, R., Montavont, N., and P.
Thubert, "Exploiting Packet Replication and Elimination in
Thubert, et al. Expires 6 August 2022 [Page 62]
Internet-Draft RAW Technologies February 2022
Complex Tracks in LLNs", Work in Progress, Internet-Draft,
draft-papadopoulos-paw-pre-reqs-01, 25 March 2019,
<https://datatracker.ietf.org/doc/html/draft-papadopoulos-
paw-pre-reqs-01>.
[I-D.thubert-bier-replication-elimination]
Thubert, P., Eckert, T., Brodard, Z., and H. Jiang, "BIER-
TE extensions for Packet Replication and Elimination
Function (PREF) and OAM", Work in Progress, Internet-
Draft, draft-thubert-bier-replication-elimination-03, 3
March 2018, <https://datatracker.ietf.org/doc/html/draft-
thubert-bier-replication-elimination-03>.
[I-D.thubert-6lo-bier-dispatch]
Thubert, P., Brodard, Z., Jiang, H., and G. Texier, "A
6loRH for BitStrings", Work in Progress, Internet-Draft,
draft-thubert-6lo-bier-dispatch-06, 28 January 2019,
<https://datatracker.ietf.org/doc/html/draft-thubert-6lo-
bier-dispatch-06>.
[I-D.ietf-bier-te-arch]
Eckert, T., Cauchie, G., and M. Menth, "Tree Engineering
for Bit Index Explicit Replication (BIER-TE)", Work in
Progress, Internet-Draft, draft-ietf-bier-te-arch-11, 15
November 2021, <https://datatracker.ietf.org/doc/html/
draft-ietf-bier-te-arch-11>.
[I-D.ietf-6tisch-coap]
Sudhaakar, R. S. and P. Zand, "6TiSCH Resource Management
and Interaction using CoAP", Work in Progress, Internet-
Draft, draft-ietf-6tisch-coap-03, 9 March 2015,
<https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-
coap-03>.
[IEEE Std 802.15.4]
IEEE standard for Information Technology, "IEEE Std
802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
and Physical Layer (PHY) Specifications for Low-Rate
Wireless Personal Area Networks".
[IEEE Std 802.11]
IEEE standard for Information Technology, "IEEE Standard
802.11 - IEEE Standard for Information Technology -
Telecommunications and information exchange between
systems Local and metropolitan area networks - Specific
requirements - Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications.",
<https://ieeexplore.ieee.org/document/9363693>.
Thubert, et al. Expires 6 August 2022 [Page 63]
Internet-Draft RAW Technologies February 2022
[IEEE Std 802.11ax]
IEEE standard for Information Technology, "802.11ax:
Enhancements for High Efficiency WLAN", 2021,
<https://ieeexplore.ieee.org/document/9442429>.
[IEEE Std 802.11ay]
IEEE standard for Information Technology, "802.11ay:
Enhanced throughput for operation in license-exempt bands
above 45 GHz", 2021,
<https://ieeexplore.ieee.org/document/9502046/>.
[IEEE Std 802.11ad]
"802.11ad: Enhancements for very high throughput in the 60
GHz band", 2012,
<https://ieeexplore.ieee.org/document/6392842/>.
[IEEE 802.11be WIP]
IEEE standard for Information Technology, "802.11be:
Extreme High Throughput PAR",
<https://mentor.ieee.org/802.11/dcn/18/11-18-1231-04-0eht-
eht-draft-proposed-par.docx>.
[IEEE Std 802.1Qat]
"802.1Qat: Stream Reservation Protocol".
[Cavalcanti_2019]
Dave Cavalcanti et al., "Extending Time Distribution and
Timeliness Capabilities over the Air to Enable Future
Wireless Industrial Automation Systems, the Proceedings of
IEEE", June 2019.
[Nitsche_2015]
Thomas Nitsche et al., "IEEE 802.11ad: directional 60 GHz
communication for multi-Gigabit-per-second Wi-Fi",
December 2014.
[Ghasempour_2017]
Yasaman Ghasempour et al., "802.11ay: Next-Generation 60
GHz Communications for 100 Gb/s Wi-Fi", December 2017.
[IEEE_doc_11-18-2009-06]
IEEE standard for Information Technology, "802.11 Real-
Time Applications (RTA) Topic Interest Group (TIG)
Report", November 2018.
[IEEE_doc_11-19-0373-00]
Kevin Stanton et Al., "Time-Sensitive Applications Support
in EHT", March 2019.
Thubert, et al. Expires 6 August 2022 [Page 64]
Internet-Draft RAW Technologies February 2022
[morell13] Antoni Morell et al., "Label switching over IEEE802.15.4e
networks", April 2013.
[dearmas16]
Jesica de Armas et al., "Determinism through path
diversity: Why packet replication makes sense", September
2016.
[vilajosana19]
Xavier Vilajosana et al., "6TiSCH: Industrial Performance
for IPv6 Internet-of-Things Networks", June 2019.
[ISA100.11a]
ISA/IEC, "ISA100.11a, Wireless Systems for Automation,
also IEC 62734", 2011, <http://www.isa100wci.org/en-
US/Documents/PDF/3405-ISA100-WirelessSystems-Future-broch-
WEB-ETSI.aspx>.
[WirelessHART]
www.hartcomm.org, "Industrial Communication Networks -
Wireless Communication Network and Communication Profiles
- WirelessHART - IEC 62591", 2010.
[PCE] IETF, "Path Computation Element",
<https://dataTracker.ietf.org/doc/charter-ietf-pce/>.
[CCAMP] IETF, "Common Control and Measurement Plane",
<https://dataTracker.ietf.org/doc/charter-ietf-ccamp/>.
[TiSCH] IETF, "IPv6 over the TSCH mode over 802.15.4",
<https://dataTracker.ietf.org/doc/charter-ietf-6tisch/>.
[RIH18] Rihacek, C., Haindl, B., Fantappie, P., Pierattelli, S.,
Gräupl, T., Schnell, M., and N. Fistas, "L-band Digital
Aeronautical Communications System (LDACS) Activities in
SESAR2020", Proceedings of the Integrated Communications
Navigation and Surveillance Conference (ICNS) Herndon, VA,
USA, April 2018.
[GRA19] Gräupl, T., Rihacek, C., and B. Haindl, "LDACS A/G
Specification", SESAR2020 PJ14-02-01 D3.3.010, February
2019.
[SAJ14] Sajatovic, M., Günzel, H., and S. Müller, "WA04 D22 Test
Report for Assessing LDACS1 Transmitter Impact upon DME/
TACAN Receivers", April 2014.
Thubert, et al. Expires 6 August 2022 [Page 65]
Internet-Draft RAW Technologies February 2022
[GRA11] Gräupl, T. and M. Ehammer, "L-DACS1 Data Link Layer
Evolution of ATN/IPS", Proceedings of the 30th IEEE/AIAA
Digital Avionics Systems Conference (DASC) Seattle, WA,
USA, October 2011.
[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, July 2018.
[GRA18] al., T. G. E., "L-band Digital Aeronautical Communications
System (LDACS) flight trials in the national German
project MICONAV", Proceedings of the Integrated
Communications, Navigation, Surveillance Conference
(ICNS) Herndon, VA, USA, April 2018.
[SCH19] Schnell, M., "DLR tests digital communications
technologies combined with additional navigation functions
for the first time", 3 March 2019,
<https://www.dlr.de/dlr/en/desktopdefault.aspx/tabid-
10081/151_read-32951/#/gallery/33877>.
[TR37910] 3GPP, "Study on self evaluation towards IMT-2020
submission", 3GPP TR 37.910,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3190>.
[TR38824] 3GPP, "Study on physical layer enhancements for NR ultra-
reliable and low latency case (URLLC)", 3GPP TR 38.824,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3498>.
[TR38825] 3GPP, "Study on NR industrial Internet of Things (IoT)",
3GPP TR 38.825,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3492>.
[TS22104] 3GPP, "Service requirements for cyber-physical control
applications in vertical domains", 3GPP TS 22.104,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3528>.
[TR22804] 3GPP, "Study on Communication for Automation in Vertical
domains (CAV)", 3GPP TS 22.804,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3187>.
Thubert, et al. Expires 6 August 2022 [Page 66]
Internet-Draft RAW Technologies February 2022
[TS23501] 3GPP, "System architecture for the 5G System (5GS)",
3GPP TS 23.501,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3144>.
[TS38300] 3GPP, "NR Overall description", 3GPP TS 38.300,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3191>.
[RP210854] 3GPP, "Revised WID: Enhanced Industrial Internet of Things
(IoT) and ultra-reliable and low latency communication
(URLLC) support for NR", 3GPP RP-210854, March 2021,
<https://www.3gpp.org/ftp/tsg_ran/TSG_RAN/TSGR_91e/Docs/
RP-210854.zip>.
[SP211633] 3GPP, "New SID: Extensions to the TSC Framework to support
DetNet", 3GPP SP-211633, December 2021,
<https://www.3gpp.org/ftp/tsg_sa/TSG_SA/
TSGS_94E_Electronic_2021_12/Docs/SP-211633.zip>.
[SP211634] 3GPP, "Study on 5G Timing Resiliency, TSC, and URLLC
enhancements", 3GPP SP-211634, December 2021,
<https://www.3gpp.org/ftp/tsg_sa/TSG_SA/
TSGS_94E_Electronic_2021_12/Docs/SP-211634.zip>.
[IMT2020] "ITU towards IMT for 2020 and beyond",
<https://www.itu.int/en/ITU-R/study-groups/rsg5/rwp5d/imt-
2020/Pages/default.aspx>.
[IEEE802.1TSN]
IEEE 802.1, "Time-Sensitive Networking (TSN) Task Group",
<http://www.ieee802.org/1/pages/tsn.html>.
[IEEE802.1AS]
IEEE, "IEEE Standard for Local and metropolitan area
networks -- Timing and Synchronization for Time-Sensitive
Applications", IEEE 802.1AS-2020,
<https://standards.ieee.org/content/ieee-standards/en/
standard/802_1AS-2020.html>.
[IEEE802.1CB]
IEEE, "IEEE Standard for Local and metropolitan area
networks -- Frame Replication and Elimination for
Reliability", DOI 10.1109/IEEEStd2017.8091139, IEEE
802.1CB-2017,
<https://ieeexplore.ieee.org/document/8091139>.
Thubert, et al. Expires 6 August 2022 [Page 67]
Internet-Draft RAW Technologies February 2022
[IEEE802.1Qbv]
IEEE, "IEEE Standard for Local and metropolitan area
networks -- Bridges and Bridged Networks -- Amendment 25:
Enhancements for Scheduled Traffic", IEEE 802.1Qbv-2015,
<https://ieeexplore.ieee.org/document/7440741>.
[IEEE802.1Qcc]
IEEE, "IEEE Standard for Local and metropolitan area
networks -- Bridges and Bridged Networks -- Amendment 31:
Stream Reservation Protocol (SRP) Enhancements and
Performance Improvements", IEEE 802.1Qcc-2018,
<https://ieeexplore.ieee.org/document/8514112>.
[IEEE802.3]
IEEE, "IEEE Standard for Ethernet", IEEE 802.3-2018,
<https://ieeexplore.ieee.org/document/8457469>.
[TSN5G] 5G-ACIA, "Integration of 5G with Time-Sensitive Networking
for Industrial Communications", 5G-ACIA whitepaper,
<https://5g-acia.org/whitepapers/integration-of-5g-with-
time-sensitive-networking-for-industrial-communications>.
[MAE18] Maeurer, N. and A. Bilzhause, "A Cybersecurity
Architecture for the L-band Digital Aeronautical
Communications System (LDACS)", IEEE 37th Digital Avionics
Systems Conference (DASC), pp. 1-10, London, UK , 2017.
[MAE191] Maeurer, N. and C. Schmitt, "Towards Successful
Realization of the LDACS Cybersecurity Architecture: An
Updated Datalink Security Threat- and Risk Analysis", IEEE
Integrated Communications, Navigation and Surveillance
Conference (ICNS), pp. 1-13, Herndon, VA, USA , 2019.
[ICAO19] International Civil Aviation Organization (ICAO), "TLDACS
White Paper–A Roll-out Scenario", Working Paper
COMMUNICATIONS PANEL-DATA COMMUNICATIONS INFRASTRUCTURE
WORKING GROUP, Montreal, Canada , October 2019.
[MAE192] Maeurer, N., Graeupl, T., and C. Schmitt, "Evaluation of
the LDACS Cybersecurity Implementation", IEEE 38th Digital
Avionics Systems Conference (DACS), pp. 1-10, San Diego,
CA, USA , September 2019.
[MAE20] Maeurer, N., Graeupl, T., and C. Schmitt, "Comparing
Different Diffie-Hellman Key Exchange Flavors for LDACS",
IEEE 39th Digital Avionics Systems Conference (DACS), pp.
1-10, San Diego, CA, USA , October 2019.
Thubert, et al. Expires 6 August 2022 [Page 68]
Internet-Draft RAW Technologies February 2022
[FIL19] Filip-Dhaubhadel, A. and D. Shutin, "LDACS- Based Non-
Cooperative Surveillance Multistatic Radar Design and
Detection Coverage Assessment", IEEE 38th Digital Avionics
Systems Conference (DACS), pp. 1-10, San Diego, CA, USA ,
September 2019.
[BAT19] Battista, G., Osechas, O., Narayanan, S., Crespillo, O.G.,
Gerbeth, D., Maeurer, N., Mielke, D., and T. Graeupl,
"Real-Time Demonstration of Integrated Communication and
Navigation Services Using LDACS", IEEE Integrated
Communications, Navigation and Surveillance Conference
(ICNS), pp. 1-12, Herndon, VA, USA , 2019.
[BRA06] Brandes, S., Schnell, M., Rokitansky, C.H., Ehammer, M.,
Graeupl, T., Steendam, H., Guenach, M., Rihacek, C., and
B. Haindl, "B-VHF -Selected Simulation Results and Final
Assessment", IEEE 25th Digital Avionics Systems Conference
(DACS), pp. 1-12, New York, NY, USA , September 2019.
[SCH08] Schnell, M., Brandes, S., Gligorevic, S., Rokitansky,
C.H., Ehammer, M., Graeupl, T., Rihacek, C., and M.
Sajatovic, "B-AMC - Broadband Aeronautical Multi-carrier
Communications", IEEE 8th Integrated Communications,
Navigation and Surveillance Conference (ICNS), pp. 1-13,
New York, NY, USA , April 2008.
[HAI09] Haindl, B., Rihacek, C., Sajatovic, M., Phillips, B.,
Budinger, J., Schnell, M., Kamiano, D., and W. Wilson,
"Improvement of L-DACS1 Design by Combining B-AMC with P34
and WiMAX Technologies", IEEE 9th Integrated
Communications, Navigation and Surveillance Conference
(ICNS), pp. 1-8, New York, NY, USA , May 2009.
[EHA11] Ehammer, M. and T. Graeupl, "AeroMACS - An Airport
Communications System", IEEE 30th Digital Avionics Systems
Conference (DACS), pp. 1-16, New York, NY, USA , September
2011.
[SCH14] Schnell, M., Epple, U., Shutin, D., and N.
Schneckenburger, "LDACS: Future Aeronautical
Communications for Air- Traffic Management", IEEE
Communications Magazine, 52(5), 104-110 , 2017.
[Cavalcanti1287]
Cavalcanti, D., Venkatesan, G., Cariou, L., and C.
Cordeiro, "TSN support in 802.11 and potential extensions
for TGbe", 2019,
<https://mentor.ieee.org/802.11/dcn/19/11-19-1287>.
Thubert, et al. Expires 6 August 2022 [Page 69]
Internet-Draft RAW Technologies February 2022
[Sudhakaran2021]
Sudhakaran, S., Montgomery, K., Kashef, M., Cavalcanti,
D., and R. Candell, "Wireless Time Sensitive Networking
for Industrial Collaborative Robotic Workcells", 17th IEEE
International Conference on Factory Communication Systems
(WFCS) , 2021,
<https://ieeexplore.ieee.org/abstract/document/9483447>.
[Fang_2021]
Fang, J., Cavalcanti, D., Cordeiro, C., and C. Cheng,
"Wireless TSN with Multi-Radio Wi-Fi", IEEE International
Conference on Standards for Communications and Networking,
December 2021. , 2021.
Authors' Addresses
Pascal Thubert (editor)
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
Dave Cavalcanti
Intel Corporation
2111 NE 25th Ave
Hillsboro, OR, 97124
United States of America
Phone: 503 712 5566
Email: dave.cavalcanti@intel.com
Xavier Vilajosana
Universitat Oberta de Catalunya
156 Rambla Poblenou
08018 Barcelona Catalonia
Spain
Email: xvilajosana@uoc.edu
Thubert, et al. Expires 6 August 2022 [Page 70]
Internet-Draft RAW Technologies February 2022
Corinna Schmitt
Research Institute CODE, UniBw M
Werner-Heisenberg-Weg 39
85577 Neubiberg
Germany
Email: corinna.schmitt@unibw.de
Janos Farkas
Ericsson
Budapest
Magyar tudosok korutja 11
1117
Hungary
Email: janos.farkas@ericsson.com
Thubert, et al. Expires 6 August 2022 [Page 71]