



Internet Engineering Task Force (IETF)                   P. Thubert, Ed.
Request for Comments: 9913                                   Independent
Category: Informational                                    D. Cavalcanti
ISSN: 2070-1721                                                    Intel
                                                           X. Vilajosana
                                         Universitat Oberta de Catalunya
                                                              C. Schmitt
                                        Research Institute CODE, UniBw M
                                                               J. Farkas
                                                                Ericsson
                                                              April 2026


           Reliable and Available Wireless (RAW) Technologies

Abstract

   This document surveys the short- and middle-range radio technologies
   over which providing Deterministic Networking (DetNet), and more
   specifically, Reliable and Available Wireless (RAW) service is
   suitable.  It also presents the characteristics that RAW may leverage
   and explores the applicability of the technologies to carry
   deterministic flows, as of the time of publication.  The studied
   technologies are Wi-Fi 6/7, Time-Slotted Channel Hopping (TSCH), 3GPP
   5G, and L-band Digital Aeronautical Communications System (LDACS).

Status of This Memo

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

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are candidates for any level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc9913.

Copyright Notice

   Copyright (c) 2026 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.  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
   2.  Terminology
   3.  Towards Reliable and Available Wireless Networks
     3.1.  Scheduling for Reliability
     3.2.  Diversity for Availability
     3.3.  Benefits of Scheduling
   4.  IEEE 802.11 Wireless Local Area Networks (WLAN)
     4.1.  Provenance and Documents
     4.2.  802.11ax High Efficiency (HE)
       4.2.1.  General Characteristics
       4.2.2.  Applicability to Deterministic Flows
     4.3.  802.11be Extreme High Throughput (EHT)
       4.3.1.  General Characteristics
       4.3.2.  Applicability to Deterministic Flows
     4.4.  802.11ad and 802.11ay (mmWave Operation)
       4.4.1.  General Characteristics
       4.4.2.  Applicability to Deterministic Flows
   5.  IEEE 802.15.4 Time-Slotted Channel Hopping (TSCH)
     5.1.  Provenance and Documents
     5.2.  General Characteristics
       5.2.1.  6TiSCH Tracks
     5.3.  Applicability to Deterministic Flows
       5.3.1.  Centralized Path Computation
   6.  5G
     6.1.  Provenance and Documents
     6.2.  General Characteristics
     6.3.  Deployment and Spectrum
     6.4.  Applicability to Deterministic Flows
       6.4.1.  System Architecture
       6.4.2.  Overview of the Radio Protocol Stack
       6.4.3.  Radio (PHY)
       6.4.4.  Scheduling and QoS (MAC)
       6.4.5.  Time-Sensitive Communications (TSC)
   7.  L-Band Digital Aeronautical Communications System (LDACS)
     7.1.  Provenance and Documents
     7.2.  General Characteristics
     7.3.  Deployment and Spectrum
     7.4.  Applicability to Deterministic Flows
       7.4.1.  System Architecture
       7.4.2.  Overview of the Radio Protocol Stack
       7.4.3.  Radio (PHY)
       7.4.4.  Scheduling, Frame Structure, and QoS (MAC)
   8.  IANA Considerations
   9.  Security Considerations
   10. References
     10.1.  Normative References
     10.2.  Informative References
   Acknowledgments
   Contributors
   Authors' Addresses

1.  Introduction

   Deterministic Networking (DetNet) [RFC8557] provides a capability to
   carry specified unicast or multicast data flows for real-time
   applications with extremely low data loss rates and bounded latency
   within a network domain.  Techniques that might be used include (1)
   reserving data plane resources for individual (or aggregated) DetNet
   flows in some or all of the intermediate nodes along the path of the
   flow, (2) providing explicit routes for DetNet flows that do not
   immediately change with the network topology, and (3) distributing
   data from DetNet flow packets over time and/or space (e.g., different
   frequencies or non-shared risk links) to ensure delivery of each
   packet in spite of the unavailability of a path.

   DetNet operates at the IP layer and typically delivers service over
   wired lower-layer technologies such as Time-Sensitive Networking
   (TSN) as defined by IEEE 802.1 and IEEE 802.3.

   The Reliable and Available Wireless (RAW) architecture [RFC9912]
   extends the DetNet architecture [RFC8655] to adapt to the specific
   challenges of the wireless medium, in particular, intermittently
   lossy connectivity, by optimizing the use of diversity and
   multipathing.  [RFC9912] defines the concepts of reliability and
   availability that are used in this document.  In turn, this document
   presents wireless technologies with capabilities, such as time
   synchronization and scheduling of transmission, that would make RAW
   operations possible over such media.  The technologies studied in
   this document were identified in the charter during the RAW Working
   Group (WG) formation and inherited by DetNet (when the WG picked up
   the work on RAW).

   Making wireless reliable and available is even more challenging than
   it is with wires, due to the numerous causes of radio transmission
   losses that add up to the congestion losses and the delays caused by
   overbooked shared resources.

   RAW, like DetNet, needs and leverages lower-layer capabilities such
   as time synchronization and traffic shapers.  To balance the adverse
   effects of the radio transmission losses, RAW leverages additional
   lower-layer capabilities, some of which may be specific or at least
   more typically applied to wireless.  Such lower-layer techniques
   include:

   *  per-hop retransmissions (also known as Automatic Repeat Request
      (ARQ)),

   *  variation of the Modulation and Coding Scheme (MCS),

   *  short-range broadcast,

   *  Multi-User - Multiple Input Multiple Output (MU-MIMO),

   *  constructive interference, and

   *  overhearing whereby multiple receivers are scheduled to receive
      the same transmission, which saves both energy on the sender and
      spectrum.

   These capabilities may be offered by the lower layer and may be
   controlled by RAW, separately or in combination.

   RAW defines a network-layer control loop that optimizes the use of
   links with constrained spectrum and energy while maintaining the
   expected connectivity properties, typically reliability and latency.
   The control loop involves communication monitoring through
   Operations, Administration, and Maintenance (OAM); path control
   through a Path Computation Element (PCE) and a runtime distributed
   Path Selection Engine (PSE); and extended Packet Replication,
   Elimination, and Ordering Functions (PREOF).

   This document surveys the short- and middle-range radio technologies
   over which providing a RAW service is suitable, presents the
   characteristics that RAW may leverage, and explores the applicability
   of the technologies to carry deterministic flows.  The studied
   technologies are Wi-Fi 6/7, Time-Slotted Channel Hopping (TSCH), 3GPP
   5G, and L-band Digital Aeronautical Communications System (LDACS).
   The purpose of this document is to support and enable work on the
   these (and possibly other similar compatible technologies) at the
   IETF, specifically in the DetNet Working Group working on RAW.

   This document surveys existing networking technology; it does not
   define protocol behaviors or operational practices.  The IETF
   specifications referenced herein each provide their own security
   considerations, and lower-layer technologies provide their own
   security at Layer 2; a security study of the technologies is
   explicitly not in scope.

2.  Terminology

   This document uses the terminology and acronyms defined in Section 2
   of [RFC8655] and Section 3 of [RFC9912].

3.  Towards Reliable and Available Wireless 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 times
   the number of the critical packets within the available resources of
   the communication hardware (e.g., buffers) and the transmission
   medium (e.g., bandwidth, transmission slots).  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 (PTP), standardized as IEEE 1588 and IEC 61588, has mapping
   through profiles to Ethernet, industrial and SmartGrid protocols, and
   Wi-Fi with IEEE Std 802.1AS.

3.2.  Diversity for Availability

   Equipment (e.g., node) failure can be the cause of multiple packets
   being lost in a row before the flows are rerouted or the system
   recovers.  Examples of equipment failure include a broken switch, an
   access point rebooting, a broken wire or radio adapter, or a fixed
   obstacle to the transmission.

   Equipment failure is not acceptable for critical applications such as
   those 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.  In an amusement ride (e.g., at
   Disneyland, Universal Studios, or MGM Studios parks), a continuous
   loss of packets for a few 100 ms may trigger an automatic
   interruption of the ride and cause the evacuation of the attraction
   floor to restart it.

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

3.3.  Benefits of Scheduling

   Scheduling redundant transmissions of the critical packets on diverse
   paths improves the resiliency against breakages and statistical
   transmission loss, such as those due to cosmic particles on wires and
   interferences on wireless.  While transmission losses are orders of
   magnitude more frequent on wireless, redundancy and diversity are
   needed in all cases for life- and mission-critical applications.

   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.  The
      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 (think
      60% or 70% of high-priority traffic with ultra low loss) compared
      to statistical priority-based schemes.

   *  Scheduling can be used as a technique for both time and frequency
      diversity (e.g., between transmission retries), allowing the next
      transmission to happen on a different frequency as programmed in
      both the sender and the receiver.  This is useful to defeat co-
      channel interference from uncontrolled transmitters as well as
      multipath fading.

   *  Transmissions can be also scheduled on multiple channels in
      parallel, which enables the use of 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.

   *  Scheduling optimizes the bandwidth usage.  Compared to classical
      collision avoidance techniques, there is no blank time related to
      Interframe 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.

   *  Scheduling plays a critical role in saving energy.  In the
      Internet of Things (IoT), energy is the foremost concern, and
      synchronizing the sender and listener enables always maintaining
      them in deep sleep when there is no scheduled transmission.  This
      avoids idle listening and long preambles, and it 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 Wireless Local Area Networks (WLAN)

   In recent years, the evolution of the IEEE Std 802.11 standard has
   taken a new direction, emphasizing improved reliability and reduced
   latency in addition to minor improvements in speed, to enable new
   fields of application such as industrial IoT and Virtual Reality
   (VR).

   Leveraging IEEE Std 802.11, the Wi-Fi Alliance [WFA] delivered Wi-Fi
   6, 7, and now 8 with more capabilities to schedule and deliver frames
   in due time at fast rates.  Still, as with any radio technology, Wi-
   Fi is sensitive to frame loss, which can only be combated with the
   maximum use of diversity in space, time, channel, and even
   technology.

   In parallel, the Avnu Alliance [Avnu], which focuses on applications
   of TSN for real-time data, formed a workgroup to investigate TSN
   capabilities over wireless, leveraging both 3GPP and IEEE Std 802.11
   standards.

   To achieve the latter, the reliability must be handled at an upper
   layer that can select Wi-Fi and other wired or wireless technologies
   for parallel transmissions.  This is where RAW comes into play.

   This section surveys the IEEE 802.11 features that are most relevant
   to RAW, noting that there are a great many more in the specification,
   some of which may also possibly be of interest for a RAW solution.
   For instance, frame fragmentation reduces the impact of a very
   transient transmission loss, both on latency and energy consumption.

4.1.  Provenance and Documents

   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 it advocates them on a global basis.  The most widely
   used standards are for Ethernet, Bridging and Virtual Bridged LAN,
   Wireless LAN, Wireless Personal Area Network (PAN), Wireless MAN,
   Wireless Coexistence, Media Independent Handover Services, and
   Wireless Radio Access Network (RAN).  An individual working group
   provides the focus for each area.

   The IEEE 802.11 Wireless LAN (WLAN) standards define the underlying
   Medium Access Control (MAC) and Physical (PHY) layers for the Wi-Fi
   technology.  While previous 802.11 generations, such as 802.11n and
   802.11ac, focused mainly on improving peak throughput, more recent
   generations are also considering other performance vectors, such as
   efficiency enhancements for dense environments in IEEE Std 802.11ax
   [IEEE802.11ax] (approved in 2021) and throughput, latency, and
   reliability enhancements in IEEE Std 802.11be [IEEE802.11be]
   (approved in 2024).

   IEEE Std 802.11-2012 includes support for TSN time synchronization
   based on IEEE 802.1AS over the 802.11 Timing Measurement protocol.
   IEEE Std 802.11-2016 additionally includes an extension to the
   802.1AS operation over 802.11 for Fine Timing Measurement (FTM), as
   well as the Stream Reservation Protocol (IEEE 802.1Qat). 802.11 WLANs
   can also be part of 802.1Q bridged networks with enhancements enabled
   by the 802.11ak amendment retrofitted in IEEE Std 802.11-2020.
   Traffic classification based on 802.1Q VLAN tags is also supported in
   802.11.  Other 802.1 TSN capabilities such as 802.1Qbv and 802.1CB,
   which are media agnostic, can already operate over 802.11.  The IEEE
   Std 802.11ax-2021 (which has been incorporated into IEEE Std
   802.11-2024) defines additional scheduling capabilities that can
   enhance the timeliness performance in the 802.11 MAC and achieve
   lower-bounded latency.  IEEE 802.11be introduces features to enhance
   the support for 802.1 TSN capabilities, especially those 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 trade-offs 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].

   The Wi-Fi Alliance 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.

   The 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
   [IEEE802.11] are relevant in the context of reliable and available
   wireless services and support for TSN capabilities:

   *  Time synchronization: IEEE Std 802.11-2016 with IEEE Std 802.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 IEEE 802.1Q bridges: IEEE Std 802.11-2020
      incorporating 802.11ak

   *  Stream Reservation Protocol (part of [IEEE802.1Qat]):
      IEEE802.11-2016

   *  Scheduled channel access: IEEE 802.11ad enhancements for very high
      throughput in the 60 GHz band [IEEE802.11ad]

   *  802.11 Real-Time Applications: Topic Interest Group (TIG)
      ReportDoc [IEEE_doc_11-18-2009-06]

   In addition, major amendments being developed by the IEEE 802.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:

   *  [IEEE802.11ax]: Enhancements for High Efficiency (HE)

   *  [IEEE802.11be]: Extreme High Throughput (EHT)

   *  [IEEE802.11ay]: Enhanced throughput for operation in license-
      exempt bands above 45 GHz

   The main 802.11ax, 802.11be, 802.11ad, and 802.11ay capabilities and
   their relevance to RAW are discussed in the remainder of this
   section.  As P802.11bn is still in early stages of development, its
   capabilities are not included in 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 [IEEE802.11ax], which includes specific capabilities to
   increase efficiency and control and to reduce latency.  Some of these
   features include higher-order 1024-QAM modulation, support for uplink
   (UL) Multi-User - Multiple Input Multiple Output (MU-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 Access Point (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 has been open to unlicensed use by the Federal
   Communications Commission (FCC) and other regulatory agencies
   worldwide.

4.2.1.1.  Multi-User OFDMA and Trigger-Based Scheduled Access

   802.11ax introduced an OFDMA mode in which multiple users can be
   scheduled across the frequency domain.  In this mode, the Access
   Point (AP) can initiate multi-user 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
   contention between associated stations for UL transmissions,
   therefore reducing the randomness caused by access based on Carrier
   Sense Multiple Access (CSMA) between stations within the same BSS.
   The AP can also transmit simultaneously to multiple users in the
   downlink (DL) direction by using a 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 an OFDMA Resource Unit (RU) to
   allocate frequency chunks to different stations over time.  RUs
   provide a way to allow 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.  While this does not support time-
   aware scheduling per se, it is a key aspect to assist reliability, as
   it provides traffic isolation in a shared medium.

4.2.1.3.  Improved PHY Robustness

   The 802.11ax PHY can operate with a 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 of operating with smaller RUs (e.g., 2
   MHz) enabled by OFDMA also helps reduce noise power and improve
   Signal-to-Noise Ratio (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 6 GHz Band

   The 802.11ax specification [IEEE802.11ax] includes support for
   operation in the 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 band, 802.11ax operation in
   this new band can be even more efficient.

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 IEEE 802.11 Working Group has
   incorporated support for absolute time synchronization to extend the
   TSN 802.1AS protocol so that time-sensitive flows 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 Service Access Point
   (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 IEEE 802.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 trade-offs 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
   in a managed network (e.g., an industrial/enterprise network).  This
   enables careful management and integration of the Wi-Fi operation
   with the overall TSN management framework, as defined in
   [IEEE802.1Qcc].

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

   Existing traffic stream identification, configuration, and admission
   control procedures defined in the QoS mechanism in [IEEE802.11] can
   be reused.  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 OFDMA mode in [IEEE802.11ax] 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, and 996 subcarriers).  In
   addition, the AP can also decide on a Modulation and Coding Scheme
   (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 and link redundancy is used to
      reduce the impact of unmanaged devices and interference.

   When the network is lightly loaded, it is possible to achieve
   latencies under 1 ms when Wi-Fi is operated in a contention-based
   mode (i.e., without OFDMA).  It also has been shown that it is
   possible to achieve 1 ms latencies in a controlled environment with
   higher efficiency when multi-user transmissions are used (enabled by
   OFDMA operation) [Cavalcanti_2019].  Obviously, there are latency,
   reliability, and capacity trade-offs 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)

4.3.1.  General Characteristics

   [IEEE802.11be] was 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
   includes 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 main features of 802.11be that are relevant to this document
   include:

   1.  320 MHz bandwidth and more efficient utilization of non-
       contiguous spectrum

   2.  Multi-Link Operation (MLO)

   3.  QoS enhancements to reduce latency and increase reliability

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

   IEEE Std 802.11be builds on and enhances 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 leverages the
   trigger-based scheduled operation enabled by 802.11ax to provide
   efficient and more predictable medium access.

   802.11be introduced QoS signaling enhancements, such as an additional
   QoS characteristics element, that enables stations to provide
   detailed information about deterministic traffic stream to the AP.
   This capability helps AP implementations to better support scheduling
   for deterministic flows.

4.3.2.2.  Multi-Link Operation

   802.11be introduces new features to improve operation over multiple
   links and channels.  By leveraging multiple links and 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 and channels to isolate time-sensitive traffic from other
   traffic and help achieve bounded latency.  The Multi-Link Operation
   (MLO) is a major feature in the 802.11be amendment that can 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, the 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].

5.  IEEE 802.15.4 Time-Slotted Channel Hopping (TSCH)

   IEEE Std 802.15.4 TSCH was the first IEEE radio specification aimed
   directly at industrial IoT applications, for use in process control
   loops and monitoring.  It was used as a base for the major industrial
   wireless process control standards, Wireless Highway Addressable
   Remote Transducer Protocol (HART) and ISA100.11a.

   While the MAC/PHY standards enable the relatively slow rates used in
   process control (typically in the order of 4-5 per second), the
   technology is not suited for the faster periods used in factory
   automation and motion control (1 to 10 ms).

5.1.  Provenance and Documents

   The IEEE 802.15.4 Task Group has been driving the development of low-
   power, low-cost radio technology.  The IEEE 802.15.4 Physical (PHY)
   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.  IEEE 802.15.4 uses spread spectrum
   modulation such as the Direct Sequence Spread Spectrum (DSSS).

   The Time-Slotted Channel Hopping (TSCH) mode was added to the 2015
   revision of the IEEE 802.15.4 standard [IEEE802.15.4].  TSCH is
   targeted at the embedded and industrial world, where reliability,
   energy consumption, and cost drive the application space.

   Building on IEEE 802.15.4, TSN on low-power constrained wireless
   networks has 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 [RFC8200] with a link-local address for the join
   process and a global unicast address for later exchanges, but the
   IPv6 traffic typically ends at a local application gateway and the
   full power of IPv6 for end-to-end communication is not enabled.

   At the IETF, the 6TiSCH Working Group [TiSCH] has enabled distributed
   routing and scheduling to exploit the deterministic access
   capabilities provided by TSCH for IPv6.  The group designed the
   essential mechanisms, the 6TiSCH Operation (6top) sublayer and the
   Scheduling Functions (SFs), to enable the management plane operation
   while ensuring IPv6 is supported.

   *  The 6top Protocol (6P) is defined in [RFC8480] and 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 an 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.

   *  With these mechanisms, 6TiSCH can establish Layer 2 links between
      neighboring nodes and support best-effort traffic.  The Routing
      Protocol for Low-Power and Lossy Networks (RPL) [RFC6550] provides
      the routing structure, enabling the 6TiSCH devices to establish
      the links with well-connected neighbors, thus forming the acyclic
      network graphs.

   In 6TiSCH, a Track is the concept of a recovery graph in the RAW
   architecture applied to wireless.  A Track can follow a simple
   sequence of relay nodes, or it 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 making routing decisions at Layer
   3.

   The 6TiSCH architecture [RFC9030] identifies different models to
   schedule resources along so-called Tracks (see Section 5.2.1),
   exploiting the TSCH schedule structure; however, the focus in 6TiSCH
   is on best-effort traffic, and the group was never chartered to
   produce standards work related to Tracks.

   There are several works that can be used to complement the overview
   provided in this document.  For example, [vilajosana21] provides a
   detailed description of the 6TiSCH protocols, how they are linked
   together, and how they are integrated with other standards like RPL
   and 6Lo.

5.2.  General Characteristics

   As a core technique in IEEE 802.15.4, TSCH splits time in multiple
   time slots that repeat over time.  Each device has its own
   perspective of when the send or receive occurs and on which channel
   the transmission happens.  This constitutes the device's slotframe,
   where the channel and destination of a transmission by this device
   are a function of time.  The overall aggregation of all the
   slotframes of all the devices constitutes a time/frequency matrix
   with at most one transmission in each cell of the matrix (see more in
   Section 5.3.1.4).

   The IEEE 802.15.4 TSCH standard does not define any scheduling
   mechanism but only provides the architecture that establishes a
   slotted structure that can be managed by a proper schedule.  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].  In MSF, 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 that 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 multipath fading
   and external interference.  It is handled by TSCH through a channel-
   hopping sequence referred to as macHopSeq in the IEEE 802.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 with OFDM modulations also supported by the IEEE 802.15.4
   standard [IEEE802.15.4] since the 2015 version.

   TSCH networks operate in ISM bands in which the spectrum is shared by
   different coexisting technologies.  Regulations such as the FCC,
   ETSI, and ARIB impose duty cycle regulations to limit the use of the
   bands, but interference may still constrain the probability of
   delivering a packet.  Part of these reliability challenges are
   addressed at the MAC layer by 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.

5.2.1.  6TiSCH Tracks

   In the 6TiSCH architecture [RFC9030], a Track is the concept of a
   DetNet architecture protection path applied to 6TiSCH networks.  A
   Track can be structured as a Destination-Oriented Directed Acyclic
   Graph (DODAG) to a destination for unicast traffic.  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 making routing decisions at 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 into a multi-hop topology; see more in
   Section 5.2.1.2 on how that is used in the data plane to forward
   packets.

   Whereas scheduling ensures reliable delivery in bounded time along
   any Track, high availability requires the application of PREOF
   functions along a more complex DODAG Track structure.  A DODAG has
   forking and joining nodes where concepts like replication and
   elimination can be exploited.  Spatial redundancy increases the
   overall energy consumption in the network but significantly improves
   the availability of the network as well as the packet delivery ratio.
   A Track may also branch off and rejoin, for the purpose of so-called
   Packet Replication and Elimination (PRE), over non-congruent
   branches.  PRE may be used to complement Layer 2 ARQ and receiver-end
   ordering to complete/extend the PREOF functions.  This enables
   meeting industrial expectations of packet delivery within bounded
   delay over a Track that includes wireless links, even when the Track
   extends beyond the 6TiSCH network.

   The RAW recovery graph described in the RAW architecture [RFC9912]
   inherits directly from that model.  RAW extends the graph beyond a
   DODAG as long as a given packet cannot loop within the Track.

                     +-----+
                     | 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 1: End-to-End Deterministic Track

   In Figure 1, a Track is laid out from a field device in a 6TiSCH
   network to an IoT gateway that is located on an IEEE 802.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 for the field device to only use the second
   branch if sending over the first branch fails.

   In current deployments, a TSCH Track does not necessarily support PRE
   but is systematically multipath.  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.

   Methods to implement complex Tracks are described in [RFC9914] and
   complemented by extensions to the RPL routing protocol in [NSA-EXT]
   for best-effort traffic, but a centralized routing technique such as
   one promoted in DetNet is still missing.

5.2.1.1.  Track Scheduling Protocol

   Section 4.4 of the 6TiSCH architecture [RFC9030] describes four
   approaches to manage the TSCH schedule of the Low-Power and Lossy
   Network (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.

5.2.1.2.  Track Forwarding

   In the 6TiSCH architecture [RFC9030], forwarding is the per-packet
   operation that allows a packet to be delivered to a next hop or an
   upper layer in a node.  Forwarding is based on preexisting state that
   was installed as a result of the routing computation of a Track by a
   PCE.  The 6TiSCH architecture supports three different forwarding
   models: GMPLS 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.
   Time and frequency resources called cells (see Section 5.3.1.4) are
   allocated to enable the forwarding operation along the Track.  In a
   Track cell, the normal operation of IEEE 802.15.4 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 operation.  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
   Multiprotocol Label Switching (GMPLS) operation in that the
   information used to switch a frame is not an explicit label but is
   rather related to other properties about 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 IEEE
   802.15.4, this effectively means that the address is broadcast, so
   that the short address for the destination of the frame is set to
   0xFFFF along the Track.

   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.  A cell in such a bundle belongs to one
   Track at most.  For a given iteration of the device schedule, the
   effective channel of the cell is obtained by adding a pseudorandom
   number to the channelOffset of the cell, which results in a rotation
   of the frequency that was used for transmission.  The bundles may be
   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 described in the following paragraphs.

   On 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 frames 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.  As a
   result, a frame that is received in an 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.  As a result, a
   frame that is received over a Layer 3 bundle may be in fact
   associated with 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.
   However, 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.3.1.1.  A frame is re-Tracked by scheduling it
   for transmission over the transmit bundle associated with the Track,
   with the destination MAC address set to broadcast.

5.2.1.2.1.  OAM

   "An Overview of Operations, Administration, and Maintenance (OAM)
   Tools" [RFC7276] provides an overview 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 Bit Index
   Explicit Replication (BIER) [RFC8279] and, more specifically, BIER
   Traffic Engineering (BIER-TE) [RFC9262].

5.3.  Applicability to Deterministic Flows

   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, as defined by [RFC5673].  As a low-power technology
   targeting industrial scenarios, radio transducers provide low data
   rates (typically between 50 kbps to 250 kbps) and robust modulations
   to trade off performance for 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.

   Nodes in a TSCH network are tightly synchronized.  This enables
   building the slotted structure and ensures efficient utilization of
   resources thanks to proper scheduling policies.  Scheduling is 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 overprovisioned cells.  Along a
   Track (see Section 5.2.1), resource blocks can be chained so nodes in
   previous hops transmit their data before the next packet comes.  This
   provides a tight control of latency along a Track.  Collision loss is
   avoided for best-effort traffic by overprovisioning resources, giving
   time to the management plane of the network to dedicate more
   resources if needed.

5.3.1.  Centralized Path Computation

   When considering end-to-end communication over TSCH, 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 a Human/Machine Interface (HMI) provides the
   traffic specification (in particular, in terms of latency,
   reliability, and the end nodes) to a PCE.  With this, the PCE
   computes a Track between the end nodes and provisions every hop in
   the Track 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.  An example of an OCS and HMI is depicted
   in Figure 2.

   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 programming of the schedule is done over the Constrained
   Application Protocol (CoAP) as discussed in [CoAP-6TiSCH].

   However, a 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 that case, the
   expectation is that a protocol that flows along a Track, in a fashion
   similar to classical Traffic Engineering (TE) [CCAMP], may be used to
   update the state in the devices.  In general, that flow was not
   designed, and it is expected that DetNet will determine the
   appropriate end-to-end protocols to be used in that case.

                         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: Architectural Layers

5.3.1.1.  Packet Marking and Handling

   Section 4.7.1 of [RFC9030] describes the packet tagging and marking
   that is expected in 6TiSCH networks.

5.3.1.1.1.  Tagging Packets for Flow Identification

   Packets that are routed by a PCE along a Track are tagged to uniquely
   identify the Track and associated transmit bundle of timeSlots.

   As a result, the tagging that is used for a DetNet flow outside the
   6TiSCH Low-Power and Lossy Network (LLN) must be swapped into 6TiSCH
   formats and back as the packet enters and then leaves the 6TiSCH
   network.

5.3.1.1.2.  Replication, Retries, and Elimination

   The 6TiSCH architecture [RFC9030] leverages PREOF over several
   alternate 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.  In the
   figure below, S transmits the same data packet twice: once to its
   Destination Parent (DP) (A) and once to its Alternate Parent (AP)
   (B).

                      ===> (A) => (C) => (E) ===
                    //        \\//   \\//       \\
          source (S)          //\\   //\\         (R) (destination)
                    \\       //  \\ //  \\      //
                      ===> (B) => (D) => (F) ===

                        Figure 4: Packet Replication


   By employing a packet elimination function once it receives the first
   copy of a data packet, a node 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 the 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
   the same packet along a Track are correlated by configuration, so
   processing the sequence numbers is not needed.

   The semantics of the configuration must enable correlated timeSlots
   to be grouped for transmit (and receive, respectively) with 'OR'
   relations, and then an 'AND' relation must be configurable between
   groups.  The semantics are such that if the transmit (and receive,
   respectively) operation succeeded in one timeSlot in an '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.
   Further details can be found in the 6TiSCH architecture document
   [RFC9030].

5.3.1.2.  Topology and Capabilities

   6TiSCH nodes are usually IoT devices, characterized by a very limited
   amount of memory, just enough buffers to store one or a few IPv6
   packets, and limited bandwidth between peers.  As a result, a node
   will maintain only a small amount 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 mechanisms such as
   enhanced beacons, but although the neighbor information is available
   in the 6TiSCH interface data model, 6TiSCH does not describe a
   protocol to proactively 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 that are used for RPL operations [RFC6551].

   The energy that the device consumes in sleep, transmit, and receive
   modes can be evaluated and reported, and so can the amount of energy
   that is stored in the device and the power that 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,
   policies that balance between nodes and ensure that the spent energy
   does not exceed the scavenged energy over a period of time.

5.3.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 an
   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 an Instance ID, in a format that reuses the
   RPLInstanceID as defined in RPL.

   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 the
   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.3.1.4.  Slotframes and Priorities

   IEEE 802.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 a 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 CDU matrix is used by the PCE as the map of all the channel
   utilization.  This organization depends on the time in the future.
   The frequency used by a cell in the matrix rotates in a pseudorandom
   fashion, from an initial position at an epoch time, as the CDU matrix
   iterates over and over.

   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 architectures.  The matrix represents the
   overall utilization of the spectrum over time by a scheduled network
   operation.

   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.  Multiple schedules may coexist, in which case the schedule
   adds a dimension to the matrix, and the dimensions are ordered by
   priority.

   A slotframe is the base object that a PCE needs to manipulate to
   program a schedule into one device.  The slotframe is a device's
   perspective of a transmission schedule; there can be more than one
   with different priorities so in case of a contention the highest
   priority applies.  In other words, a slotframe is the projection of a
   schedule from the CDU matrix onto one device.  Elaboration on that
   concept can be found in Section 4.3.5 of [RFC9030], and Figures 17
   and 18 of [RFC9030] illustrate that projection.

6.  5G

   5G technology enables deterministic communication.  Based on the
   centralized admission control and the scheduling of the wireless
   resources, licensed or unlicensed, Quality of Service (QoS) 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 1 ms 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 the 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, due to the commonalities between TSN and DetNet
   reliability.  Moreover, providing IP service is native to 5G, and
   3GPP Release 18 adds direct support for DetNet to 5G.

   Overall, 5G provides scheduled wireless segments with high
   reliability and availability.  In addition, 5G includes capabilities
   for integration to IP networks.  This makes 5G a suitable technology
   upon which to apply RAW.

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.

   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 it is also tailored for future 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 on Ultra-
   Reliable Low-Latency Communications (URLLC) for connected control
   systems and critical communication as illustrated in Figure 5.  It is
   the URLLC capabilities that make 5G a great candidate for reliable
   low-latency communication.  With these three cornerstones, NR is a
   complete solution supporting the connectivity needs of consumers,
   enterprises, and the 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 5: 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 a 1 ms latency budget [TR37910].  Those evaluations were
   consolidated and forwarded to ITU to be included in the work on
   [IMT2020].

   In order to understand communication requirements for automation in
   vertical domains, 3GPP studied different use cases [TR22804] and
   released a technical specification with reliability, availability,
   and latency demands for a variety of applications [TS22104].

   As an evolution of NR, multiple studies that focus on radio aspects
   have been conducted in scope of 3GPP Release 16, including the
   following two:

   1.  "Study on physical layer enhancements for NR ultra-reliable and
       low latency case (URLLC)" [TR38824]

   2.  "Study on NR industrial Internet of Things (IoT)" [TR38825]

   As a result of these studies, further enhancements to NR have been
   standardized in 3GPP Release 16 and are available in [TS38300] and
   continued in 3GPP Release 17 standardization (according to
   [RP210854]).

   In addition, several enhancements have been made on the 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, such as support for DetNet
   [TR2370046], are provided in Release 18.

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

   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
   for both 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 configurations to serve various service
   requirements.  An operator can configure and manage the mobile
   network to support various types of services enabled by 5G (e.g.,
   eMBB and URLLC), depending on the different needs of customers.

   Exposure of capabilities of 5G systems to the network or applications
   outside the 3GPP domain have been added to Release 16 [TS23501].
   Applications can access 5G capabilities like communication service
   monitoring and network maintenance via exposure interfaces.

   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
   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 and local-area 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
   (mmWaves) for extreme capacity locally and 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 full control of 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 was initially developed for usage of
   licensed spectrum, the functionality to also access 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 large regions.  Besides this,
   configured as a non-public network (NPN) deployment, 5G can also
   provide network services to a non-operator defined organization and
   its premises such as a factory deployment.  With this isolation, QoS
   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.

   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 the choice to apply for a local
   license themselves and operate their own network or to cooperate 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, the Radio Access Network (RAN) with the gNodeB (gNB)
   as radio base station node, and the Core Network (CN), which is
   connected to the external Data Network (DN).  The CN is based on a
   service-based architecture with the following central functions:
   Access and Mobility Management Function (AMF), Session Management
   Function (SMF), and User Plane Function (UPF) as illustrated in
   Figure 6.  (Note that this document only explains key functions;
   however, Figure 6 provides a more detailed view, and [SYSTOVER5G]
   summarizes the functions and provides the full definitions of the
   acronyms used in the figure.)

   The gNB's main responsibility is 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; for
   example, resource isolation in the RAN and CN can be defined
   (slicing).

             +----+  +---+   +---+    +---+    +---+   +---+
             |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 6: 5G System Architecture

   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 neighboring
   cells, periodically or based on events.  Based on these measurement
   reports, the gNB decides to hand over a UE to another target cell/
   gNB.  Before triggering the handover, it is handshaked with the
   target gNB based on network signaling.  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., to 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 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 the 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 Layer 1 Physical
   (PHY) layer and, as part of Layer 2, the sublayers of Medium Access
   Control (MAC), Radio Link Control (RLC), Packet Data Convergence
   Protocol (PDCP), and Service Data Adaption Protocol (SDAP).

   The PHY layer handles actions related to signal processing, such as
   encoding/decoding of data and control bits, modulation, antenna
   precoding, and mapping.

   The MAC sublayer 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, reordering and in-
   order delivery, and duplication and duplicate handling for higher-
   layer packets.  This sublayer also acts as the anchor protocol to
   support handovers.

   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 signaling for the
   aforementioned protocol layers.  RRC messages are considered Layer 3
   and are thus also transmitted 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 Layer 2, as explained below.

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 the effectiveness of spectral usage.  Spatial diversity
   with up to four MIMO layers in UL and up to eight MIMO layers in DL
   is supported.  Together with spatial-domain multiplexing, antenna
   arrays can focus power in the 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 downlink (DL) and uplink (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
   a data packet in time, in frequency, or over multiple MIMO layers,
   which can improve reliability even further.

   Any DL 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 upon detecting DTX, the base
   station will retransmit the initial data.

   An UL 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 the 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 Section 6.4.4).

   Since transmission of data packets requires 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 Binary Phase-Shift Keying (BPSK) or Quadrature Phase-
   Shift Keying (QPSK).  Also, PDCCH and PUCCH channels support multiple
   code rates including very low ones for the channel robustness.

   A connected UE reports DL quality to gNB by sending Channel State
   Information (CSI) reports via PUCCH while UL quality is measured
   directly at gNB.  For both UL and DL, 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 a 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 PHY 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 is 0.23 ms in DL and 0.24 ms in UL (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 scheduled.

   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 preempted and reassigned to URLLC services.  In this
   way, spectrally efficient assignments for eMBB can be ensured while
   providing the flexibility required to ensure a bounded latency for
   URLLC services.  In DL, the gNB can notify the eMBB UE about
   preemption after it has happened, while in UL there are two
   preemption 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 set up 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).  For example, QoS flows can be associated with
   different priority levels, packet delay budgets, and tolerable packet
   error rates.  Since radio resources are centrally scheduled in NR,
   the admission control function can ensure that only QoS flows for
   which QoS targets can be reached are admitted.

   NR transmissions in both UL and DL are scheduled by the gNB
   [TS38300].  This ensures radio resource efficiency and fairness in
   resource usage of the users, and it 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., chosen 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
   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 UL resources are scheduled, the UE can transmit its
   data and may include a buffer status report that indicates 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.  These features allow different periodical critical QoS
   flows to be served, together with best-effort transmissions, by the
   same UE.  These features include the following:

   *  UL logical channel transmission restrictions, allowing logical
      channels of certain QoS to only be mapped to intended UL resources
      of a certain frequency carrier, slot length, or CG configuration.

   *  intra-UE preemption and multiplexing, allowing critical UL
      transmissions to either preempt non-critical transmissions or be
      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.

   In addition to licensed spectrum, a 5G system can also utilize
   unlicensed spectrum to offload non-critical traffic.  This version of
   NR, called NR-U, is part of 3GPP Release 16.  The central scheduling
   approach also applies for unlicensed radio resources and the
   mandatory channel access mechanisms for unlicensed spectrum (e.g.,
   Listen Before Talk (LBT) is 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 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) mechanism [IEEE802.1CB].

   3GPP Release 16 includes integration of 5G with TSN, i.e., specifies
   functions for the 5G System (5GS) to deliver TSN streams so that
   their QoS requirements are met.  A key aspect of the integration is
   that, from the rest of the network, the 5GS appears 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:

   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, which allows integration with scheduled traffic
       [IEEE802.1Qbv]

   4.  reliability, which allows integration with FRER [IEEE802.1CB]

   3GPP Release 17 [TS23501] introduced enhancements to generalize
   support for TSC beyond TSN.  This includes IP communications to
   provide time-sensitive services (e.g., to 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 interfaces, and the control
   plane provides the service based on QoS and time synchronization
   requests from an Application Function (AF).

   Figure 7 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 adapting
   to the settings of the TSN network.  A 5G user plane virtual bridge
   interconnects TSN bridges or connects end stations (e.g., I/O devices
   to the TSN network).  TTs, i.e., the Device-Side TSN Translator (DS-
   TT) at the UE and the Network-Side TSN Translator (NW-TT) at the UPF,
   have a key role in the interconnection.  Note that the introduction
   of 5G brings flexibility in various aspects, e.g., a more flexible
   network topology because a wireless hop can replace several wireline
   hops, thus significantly reducing the number of hops end to end.
   [TSN5G] dives more into the integration of 5G with TSN.

                    +------------------------------+
                    | 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 7: 5G - TSN Integration

   NR supports accurate reference time synchronization in 1 µs 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 is not only
   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 and providing
   additional support for other types of clocks and time distribution
   such as boundary clocks and transparent clocks (both peer-to-peer and
   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 backup or
   alternative timing source for the failure of the local GNSS source
   (or other primary timing source) used by the vertical.

   IETF DetNet is the technology to support time-sensitive
   communications at the IP layer. 3GPP Release 18 includes a study
   [TR2370046] on interworking between 5G and DetNet.  Along the TSC
   framework introduced for Release 17, the 5GS acts as a DetNet node
   for the support of DetNet; see Figure 7.1-1 in [TR2370046].  The
   study provides details on how the 5GS is exposed by the Time
   Sensitive Communication and Time Synchronization Function (TSCTSF) to
   the DetNet controller as a router on a per-UPF granularity (similarly
   to the per-UPF Virtual TSN Bridge granularity shown in Figure 7).  In
   particular, it lists the parameters that are provided by the TSCTSF
   to the DetNet controller.  The study also includes how the TSCTSF
   maps DetNet flow parameters to 5G QoS parameters.  Note that TSN is
   the primary subnetwork technology for DetNet.  Thus, the work on
   DetNet over TSN, e.g., [RFC9023], can be leveraged via the TSN
   support built in 5G.

   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 8.  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 DetNet [RFC8655].

              +........+
              . Device . +------+      +------+      +------+
              .        . + gNB1 +--N3--+ UPF1 |--N6--+      |
              .        ./+------+      +------+      |      |
              . +----+ /                             |      |
              . |    |/.                             |      |
              . | UE + .                             |  DN  |
              . |    |\.                             |      |
              . +----+ \                             |      |
              .        .\+------+      +------+      |      |
              +........+ + gNB2 +--N3--+ UPF2 |--N6--+      |
                         +------+      +------+      +------+

                    Figure 8: Reliability with Single UE

   An alternative solution is that multiple UEs per device are used for
   user plane redundancy as illustrated in Figure 9.  Each UE sets up a
   PDU session.  The 5GS ensures that the 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 [IEEE802.1CB] or PREOF
   [RFC8655] specifications.

             +.........+
             .  Device .
             .         .
             . +----+  .  +------+      +------+      +------+
             . | UE +-----+ gNB1 +--N3--+ UPF1 |--N6--+      |
             . +----+  .  +------+      +------+      |      |
             .         .                              |  DN  |
             . +----+  .  +------+      +------+      |      |
             . | UE +-----+ gNB2 +--N3--+ UPF2 |--N6--+      |
             . +----+  .  +------+      +------+      +------+
             .         .
             +.........+

                     Figure 9: Reliability with Dual UE

   Note that the abstraction provided by the RHF and the location of the
   RHF outside of the 5G system allow 5G to support integration for
   reliability with both TSN FRER [IEEE802.1CB] and DetNet PREOF
   [RFC8655], as they both rely on the same concept.

7.  L-Band Digital Aeronautical Communications System (LDACS)

   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
   suffer from the VHF band's increasing saturation in high-density
   areas and the limitations posed by analog radio.  Therefore, aviation
   (globally and in 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 analog VHF
   voice and VHF Digital Link (VDL) Mode 2 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 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).

   It is a secure, scalable, and spectrum-efficient data link with
   embedded navigation capability; thus, it is the first truly
   integrated Communications, Navigation, and Surveillance (CNS) system
   recognized by the International Civil Aviation Organization (ICAO).
   During flight tests, the LDACS capabilities have been successfully
   demonstrated.  A viable rollout 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 the
   future.

   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; see [RFC9372] for more
   information.

7.1.  Provenance and Documents

   The development of LDACS has already made substantial progress in the
   Single European Sky ATM Research (SESAR) framework, and it 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 the 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 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.

   Up to now, the LDACS standardization has been focused on the
   development of the Physical (PHY) 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 QoS,
   diversity, and mobility under the umbrella of the "multi-link
   concept".  This work is conducted by the ICAO WG-I Working Group.

   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] [BEL22] [GRA23].

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 which
   provides 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 (FL) and 294 kbit/s to 1390 kbit/s on the reverse link
   (RL), 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 kbit/
   s on the FL and 294 kbit/s on the RL.

   In addition to the communications capability, LDACS also offers a
   navigation capability.  Ranging data, similar to Distance Measuring
   Equipment (DME), is extracted from the LDACS communication links
   between aircraft and LDACS ground stations.  This results in LDACS
   providing an Alternative Position, Navigation, and Timing (APNT)
   capability to supplement the existing on-board Global Navigation
   Satellite System (GNSS) 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].

   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] have shown the 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 most mature, secure, and terrestrial long-range CNS
   technology for civil aviation worldwide.

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 [EHA11]
   technologies.  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 rollout
   strategies are discussed.

   The LDACS data link provides enhanced capabilities to existing
   aeronautical communications infrastructures, enabling them to better
   support user needs and new applications.  The deployment scalability
   of LDACS allows its implementation to start in areas where it is most
   needed to immediately improve the performance of and 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 times 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 [ICAO19].

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

7.4.1.  System Architecture

   Up to 512 Aircraft Stations (ASes) communicate to an LDACS Ground
   Station (GS) in the reverse link (RL).  A GS communicates to an AS in
   the forward link (FL).  Via an Access-Router (AC-R), GSs connect the
   LDACS subnetwork 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 (PHY) layer 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 subnetwork layer: the Subnetwork
   Protocol (SNP).  The LDACS network is externally connected to voice
   units, radio control units, and the ATN network layer.

   Communications between the MAC and LME layers is split into four
   distinct control channels:

   1.  the Broadcast Control Channel (BCCH), where LDACS ground stations
       announce their specific LDACS cell, including physical parameters
       and cell identification;

   2.  the Random Access Channel (RACH), where LDACS airborne radios can
       request access to an LDACS cell;

   3.  the Common Control Channel (CCCH), where LDACS ground stations
       allocate resources to aircraft radios, enabling the airborne side
       to transmit the user payload; and

   4.  the Dedicated Control Channel (DCCH), where LDACS airborne radios
       can request user data resources from the LDACS ground station so
       the airborne side can transmit the user payload.

   Communications between the MAC and DLS layers is handled by the Data
   Channel (DCH) where the user payload is handled.

   Figure 10 shows the protocol stack of LDACS as implemented in the AS
   and GS.

            IPv6                   Network Layer
              |
              |
   +------------------+  +----+
   |        SNP       |--|    |   Subnetwork
   |                  |  |    |   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 10: LDACS Protocol Stack in AS and GS

7.4.3.  Radio (PHY)

   The PHY layer provides the means to transfer data over the radio
   channel.  The LDACS ground station supports bidirectional links to
   multiple aircraft under its control.  The FL direction (which is
   ground to air) and the RL direction (which is air to ground) are
   separated by frequency division duplex.  FL and RL use a 500 kHz
   channel each.  The ground station transmits a continuous stream of
   OFDM symbols on the FL.  In the RL, different aircrafts are separated
   in time and frequency using a combination of Orthogonal Frequency-
   Division Multiple Access (OFDMA) and Time-Division Multiple-Access
   (TDMA).  Thus, aircraft transmit discontinuously on the RL with radio
   bursts sent 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 indicates 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 sublayers: the medium access
   sublayer and the logical link control sublayer.  The medium access
   sublayer manages the organization of transmission opportunities in
   slots of time and frequency.  The logical link control sublayer
   provides acknowledged point-to-point logical channels between the
   aircraft and the ground station using an automatic repeat request
   protocol.  LDACS also supports unacknowledged point-to-point channels
   and ground-to-air broadcast.

   Next, the frame structure of LDACS is introduced, followed by a more
   in-depth discussion of the LDACS medium access.

   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 with a duration of 6.72
   ms (56 OFDM symbols) for the Broadcast Control Channel (BCCH) and
   four Multi-Frames (MF), each with a duration of 58.32 ms (486 OFDM
   symbols).

   In the RL, each SF starts with a Random Access (RA) slot with a
   length of 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.

   Figures 11 and 12 illustrate the LDACS frame structure.  This fixed
   frame structure allows for the reliable and dependable transmission
   of data.

   ^
   |     +------+------------+------------+------------+------------+
   |  FL | BCCH |     MF     |     MF     |     MF     |     MF     |
   F     +------+------------+------------+------------+------------+
   r     <---------------- Super-Frame (SF) - 240 ms --------------->
   e
   q     +------+------------+------------+------------+------------+
   u  RL | RACH |     MF     |     MF     |     MF     |     MF     |
   e     +------+------------+------------+------------+------------+
   n     <---------------- Super-Frame (SF) - 240 ms --------------->
   c
   y
   |
   ----------------------------- Time ------------------------------>
   |

                     Figure 11: SF Structure for LDACS

   ^
   |     +-------------+------+-------------+
   |  FL |     DCH     | CCCH |     DCH     |
   F     +-------------+------+-------------+
   r     <--- Multi-Frame (MF) - 58.32 ms -->
   e
   q     +------+---------------------------+
   u  RL | DCCH |             DCH           |
   e     +------+---------------------------+
   n     <--- Multi-Frame (MF) - 58.32 ms -->
   c
   y
   |
   -------------------- Time ------------------>
   |

                     Figure 12: MF Structure for LDACS

   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
   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" or
   permanently allocated by a LDACS ground station with a given class of
   service.  On the FL, this is done locally in the ground station; on
   the RL, a dedicated contention-free control channel is used (the
   Dedicated Control Channel (DCCH); roughly 83 bits every 60 ms).  A
   resource allocation is always announced in the control channel of the
   FL (Common Control Channel (CCCH); variable sized).  Due to the
   spacing of the RL 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 at
   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 messages always go first
   in any case.  Scheduling of RL resources is done in physical Protocol
   Data Units (PDU) of 112 bits (or larger if more aggressive coding and
   modulation is used).  Scheduling on the FL is done byte wise since
   the FL 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.

8.  IANA Considerations

   This document has no IANA actions.

9.  Security Considerations

   Most RAW technologies integrate some authentication or encryption
   mechanisms that are defined outside the IETF.  The IETF
   specifications referenced herein each provide their own security
   considerations, and the lower-layer technologies used provide their
   own security at Layer 2.

10.  References

10.1.  Normative References

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

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

   [RFC9912]  Thubert, P., Ed., "Reliable and Available Wireless (RAW)
              Architecture", RFC 9912, DOI 10.17487/RFC9912, April 2026,
              <https://www.rfc-editor.org/info/rfc9912>.

10.2.  Informative References

   [Avnu]     "Avnu Alliance", <https://www.avnu.org>.

   [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", Integrated
              Communications, Navigation and Surveillance Conference
              (ICNS), pp. i-xii, DOI 10.1109/ICNSURV.2019.8735195, 2019,
              <https://elib.dlr.de/134475/1/08735195.pdf>.

   [BEL22]    Bellido-Manganell, M. A., Gräupl, T., Heirich, O., Mäurer,
              N., Filip-Dhaubhadel, A., Mielke, D. M., Schalk, L. M.,
              Becker, D., Schneckenburger, N., and M. Schnell, "LDACS
              Flight Trials: Demonstration and Performance Analysis of
              the Future Aeronautical Communications System", IEEE
              Transactions on Aerospace and Electronic Systems, vol. 58,
              no. 1, pp. 615-634, DOI 10.1109/TAES.2021.3111722,
              February 2022,
              <https://doi.org/10.1109/TAES.2021.3111722>.

   [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, DOI 10.1109/DASC.2006.313670, 2006,
              <https://doi.org/10.1109/DASC.2006.313670>.

   [Cavalcanti1287]
              Cavalcanti, D., Venkatesan, G., Cariou, L., and C.
              Cordeiro, "TSN support in 802.11 and potential extensions
              for TGbe", 10 September 2019,
              <https://mentor.ieee.org/802.11/dcn/19/11-19-1287>.

   [Cavalcanti_2019]
              Cavalcanti, D., Perez-Ramirez, J., Rashid, M. M., Fang,
              J., Galeev, M., and K. B. Stanton, "Extending Accurate
              Time Distribution and Timeliness Capabilities Over the Air
              to Enable Future Wireless Industrial Automation Systems",
              Proceedings of the IEEE, vol. 107, no. 6, pp. 1132-1152,
              DOI 10.1109/JPROC.2019.2903414, June 2019,
              <https://doi.org/10.1109/JPROC.2019.2903414>.

   [CCAMP]    IETF, "Common Control and Measurement Plane",
              <https://datatracker.ietf.org/doc/charter-ietf-ccamp/>.

   [CoAP-6TiSCH]
              Sudhaakar, R. S., Ed. 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>.

   [EHA11]    Ehammer, M., Pschernig, E., and T. Graeupl, "AeroMACS - An
              Airport Communications System", 2011 IEEE/AIAA 30th
              Digital Avionics Systems Conference, pp. 4C1-1-4C1-16,
              DOI 10.1109/DASC.2011.6095903, 2011,
              <https://doi.org/10.1109/DASC.2011.6095903>.

   [Fang_2021]
              Fang, J., Sudhakaran, S., Cavalcanti, D., Cordeiro, C.,
              and C. Chen, "Wireless TSN with Multi-Radio Wi-Fi", 2021
              IEEE Conference on Standards for Communications and
              Networking (CSCN), pp. 105-110,
              DOI 10.1109/CSCN53733.2021.9686180, 2021,
              <https://doi.org/10.1109/CSCN53733.2021.9686180>.

   [FIL19]    Filip-Dhaubhadel, A. and D. Shutin, "LDACS- Based Non-
              Cooperative Surveillance Multistatic Radar Design and
              Detection Coverage Assessment", IEEE/AIAA 38th Digital
              Avionics Systems Conference (DASC), pp. 1-10,
              DOI 10.1109/DASC43569.2019.9081714, 2019,
              <https://doi.org/10.1109/DASC43569.2019.9081714>.

   [Ghasempour_2017]
              Ghasempour, Y., Silva, C. R. C. M. D., Cordeiro, C., and
              E. W. Knightly, "802.11ay: Next-Generation 60 GHz
              Communications for 100 Gb/s Wi-Fi", IEEE Communications
              Magazine, vol. 55, no. 12, pp. 186-192,
              DOI 10.1109/MCOM.2017.1700393, December 2017,
              <https://doi.org/10.1109/MCOM.2017.1700393>.

   [GRA11]    Gräupl, T., "LDACS1 Data Link Layer Evolution of ATN/IPS",
              IEEE/AIAA 30th Digital Avionics Systems Conference, pp.
              1-28, DOI 10.1109/DASC.2011.6096230, October 2011,
              <https://doi.org/10.1109/DASC.2011.6096230>.

   [GRA18]    Gräupl, T., Schneckenburger, N., Jost, T., Schnell, M.,
              Filip, A., Bellido-Manganell, M. A., Mielke, D. M.,
              Mäurer, N., Kumar, R., Osechas, O., and G. Battista,
              "L-band Digital Aeronautical Communications System (LDACS)
              flight trials in the national German project MICONAV",
              2018 Integrated Communications, Navigation, Surveillance
              Conference (ICNS), pp. 4A2-1-4A2-7,
              DOI 10.1109/ICNSURV.2018.8384881, April 2018,
              <https://doi.org/10.1109/ICNSURV.2018.8384881>.

   [GRA19]    Gräupl, T., Rihacek, C., Haindl, B., and Q. Parrod,
              "SESAR2020 - PJ14-02-01 - LDACS A/G SPECIFICATION",
              EDITION 00.02.02, 16 August 2019, <https://www.ldacs.com/
              wp-content/uploads/2013/12/SESAR2020_PJ14_D3_3_030_LDACS_A
              G_Specification_00_02_02-1_0.pdf>.

   [GRA23]    Gräupl, T., Mielke, D. M., Bellido-Manganell, M. A.,
              Jansen, L. J., Mäurer, N., Gürbüz, A., Filip-Dhaubhadel,
              A., Schalk, L., Becker, D., Skorepa, M., Wrobel, F.,
              Morioka, K., Kurz, S., and J. Meser, "LDACS Flight Trials:
              Demonstration of ATS-B2, IPS, and Seamless Mobility", 2023
              Integrated Communication, Navigation and Surveillance
              Conference (ICNS), pp. 1-13,
              DOI 10.1109/ICNS58246.2023.10124329, 2023,
              <https://doi.org/10.1109/ICNS58246.2023.10124329>.

   [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", 2009 Integrated Communications,
              Navigation and Surveillance Conference, pp. 1-8,
              DOI 10.1109/ICNSURV.2009.5172873, May 2009,
              <https://doi.org/10.1109/ICNSURV.2009.5172873>.

   [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,
              <https://elibrary.icao.int/product/279816>.

   [ICAO19]   International Civil Aviation Organization (ICAO), "TLDACS
              White Paper - A Roll-out Scenario", Communications Panel -
              Data Communications Infrastructure Working Group, October
              2019, <https://www.ldacs.com/wp-content/uploads/2013/12/
              ACP-DCIWG-IP01-LDACS-White-Paper.pdf>.

   [IEEE802.11]
              IEEE, "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", IEEE
              Std 802.11-2024, DOI 10.1109/IEEESTD.2025.10979691, 2024,
              <https://ieeexplore.ieee.org/document/10979691>.

   [IEEE802.11ad]
              IEEE, "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
              Amendment 3: Enhancements for Very High Throughput in the
              60 GHz Band", IEEE Std 802.11ad-2012,
              DOI 10.1109/IEEESTD.2012.6392842, 2012,
              <https://ieeexplore.ieee.org/document/6392842/>.

   [IEEE802.11ax]
              IEEE, "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 Amendment 1:
              Enhancements for High-Efficiency WLAN", IEEE Std 802.11ax-
              2021, DOI 10.1109/IEEESTD.2021.9442429, 2021,
              <https://ieeexplore.ieee.org/document/9442429>.

   [IEEE802.11ay]
              IEEE, "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 Amendment 2:
              Enhanced Throughput for Operation in License-exempt Bands
              above 45 GHz", IEEE Std 802.11ay-2021,
              DOI 10.1109/IEEESTD.2021.9502046, 2021,
              <https://ieeexplore.ieee.org/document/9502046/>.

   [IEEE802.11be]
              IEEE, "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 Amendment 2:
              Enhancements for Extremely High Throughput (EHT)", IEEE
              Std 802.11be-2024, DOI 10.1109/IEEESTD.2024.11090080,
              <https://ieeexplore.ieee.org/document/11090080>.

   [IEEE802.15.4]
              IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE
              Std 802.15.4-2015, DOI 10.1109/IEEESTD.2016.7460875,
              <https://doi.org/10.1109/IEEESTD.2016.7460875>.

   [IEEE802.1AS]
              IEEE, "IEEE Standard for Local and Metropolitan Area
              Networks -- Timing and Synchronization for Time-Sensitive
              Applications", IEEE Std 802.1AS-2020,
              DOI 10.1109/IEEESTD.2020.9121845,
              <https://doi.org/10.1109/IEEESTD.2020.9121845>.

   [IEEE802.1CB]
              IEEE, "IEEE Standard for Local and metropolitan area
              networks -- Frame Replication and Elimination for
              Reliability", IEEE Std 802.1CB-2017,
              DOI 10.1109/IEEEStd2017.8091139, 2017,
              <https://ieeexplore.ieee.org/document/8091139>.

   [IEEE802.1Qat]
              IEEE, "IEEE Standard for Local and metropolitan area
              networks -- Virtual Bridged Local Area Networks Amendment
              14: Stream Reservation Protocol (SRP)", IEEE Std 802.1Qat-
              2010, DOI 10.1109/IEEESTD.2010.5594972,
              <https://doi.org/10.1109/IEEESTD.2010.5594972>.

   [IEEE802.1Qbv]
              IEEE, "IEEE Standard for Local and metropolitan area
              networks -- Bridges and Bridged Networks - Amendment 25:
              Enhancements for Scheduled Traffic", IEEE Std 802.1Qbv-
              2015, DOI 10.1109/IEEESTD.2016.8613095, 2016,
              <https://doi.org/10.1109/IEEESTD.2016.8613095>.

   [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 Std 802.1Qcc-2018,
              DOI 10.1109/IEEESTD.2018.8514112,
              <https://ieeexplore.ieee.org/document/8514112>.

   [IEEE802.1TSN]
              IEEE 802.1 Working Group, "Time-Sensitive Networking Task
              Group", <http://www.ieee802.org/1/pages/tsn.html>.

   [IEEE802.3]
              IEEE, "IEEE Standard for Ethernet", IEEE Std 802.3-2022,
              DOI 10.1109/IEEESTD.2022.9844436,
              <https://ieeexplore.ieee.org/document/9844436>.

   [IEEE_doc_11-18-2009-06]
              IEEE, "802.11 Real-Time Applications (RTA) Topic Interest
              Group (TIG) Report", November 2018,
              <https://mentor.ieee.org/802.11/dcn/18/11-18-2009-06-0rta-
              rta-report-draft.docx>.

   [IMT2020]  ITU, "IMT-2020 (a.k.a. "5G")", <https://www.itu.int/en/
              ITU-R/study-groups/rsg5/rwp5d/imt-2020/Pages/
              default.aspx>.

   [ISA100.11a]
              ISA, "ISA100 Wireless", ANSI/ISA-100.11a-2011 (IEC 26743),
              <https://isa100wci.org/about-isa100-wireless?_gl=1*19xrxgo
              *_up*MQ..*_ga*NDczNjkxOTQ1LjE3NjI0NjQ2NDk.*_ga_L2KSW4EHCS*
              czE3NjI0NjQ2NDkkbzEkZzEkdDE3NjI0NjQ3MzQkajYwJGwwJGgw>.

   [MAE18]    Maeurer, N. and A. Bilzhause, "A Cybersecurity
              Architecture for the L-band Digital Aeronautical
              Communications System (LDACS)", 2018 IEEE/AIAA 37th
              Digital Avionics Systems Conference (DASC), pp. 1-10,
              DOI 10.1109/DASC.2018.8569878, 2018,
              <https://doi.org/10.1109/DASC.2018.8569878>.

   [MAE191]   Maeurer, N. and C. Schmitt, "Towards Successful
              Realization of the LDACS Cybersecurity Architecture: An
              Updated Datalink Security Threat- and Risk Analysis",
              Integrated Communications, Navigation and Surveillance
              Conference (ICNS), pp. 1-13,
              DOI 10.1109/ICNSURV.2019.8735139, 2019,
              <https://doi.org/10.1109/ICNSURV.2019.8735139>.

   [MAE192]   Maeurer, N., Graeupl, T., and C. Schmitt, "Evaluation of
              the LDACS Cybersecurity Implementation", IEEE/AIAA 38th
              Digital Avionics Systems Conference (DASC), pp. 1-10,
              DOI 10.1109/DASC43569.2019.9081786, September 2019,
              <https://doi.org/10.1109/DASC43569.2019.9081786>.

   [MAE20]    Maeurer, N., Graeupl, T., Gentsch, C., and C. Schmitt,
              "Comparing Different Diffie-Hellman Key Exchange Flavors
              for LDACS", AIAA/IEEE 39th Digital Avionics Systems
              Conference (DASC), pp. 1-10,
              DOI 10.1109/DASC50938.2020.9256746, 2020,
              <https://doi.org/10.1109/DASC50938.2020.9256746>.

   [Nitsche_2015]
              Nitsche, T., Cordeiro, C., Flores, A. B., Knightly, E. W.,
              Perahia, E., and J. C. Widmer, "IEEE 802.11ad: directional
              60 GHz communication for multi-Gigabit-per-second Wi-Fi",
              IEEE Communications Magazine, vol. 52, no. 12, pp.
              132-141, DOI 10.1109/MCOM.2014.6979964, December 2014,
              <https://doi.org/10.1109/MCOM.2014.6979964>.

   [NSA-EXT]  Koutsiamanis, R., Ed., Papadopoulos, G. Z., 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-
              13, 7 July 2025, <https://datatracker.ietf.org/doc/html/
              draft-ietf-roll-nsa-extension-13>.

   [PCE]      IETF, "Path Computation Element",
              <https://datatracker.ietf.org/doc/charter-ietf-pce/>.

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

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

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

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

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

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

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

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

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

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

   [RFC9262]  Eckert, T., Ed., Menth, M., and G. Cauchie, "Tree
              Engineering for Bit Index Explicit Replication (BIER-TE)",
              RFC 9262, DOI 10.17487/RFC9262, October 2022,
              <https://www.rfc-editor.org/info/rfc9262>.

   [RFC9372]  Mäurer, N., Ed., Gräupl, T., Ed., and C. Schmitt, Ed.,
              "L-Band Digital Aeronautical Communications System
              (LDACS)", RFC 9372, DOI 10.17487/RFC9372, March 2023,
              <https://www.rfc-editor.org/info/rfc9372>.

   [RFC9914]  Thubert, P., Ed., Jadhav, R.A., and M. Richardson, "Root-
              Initiated Routing State in the Routing Protocol for Low-
              Power and Lossy Networks (RPL)", RFC 9914,
              DOI 10.17487/RFC9914, April 2026,
              <https://www.rfc-editor.org/info/rfc9914>.

   [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", 2018 Integrated Communications, Navigation,
              Surveillance Conference (ICNS), pp. 4A1-1-4A1-8,
              DOI 10.1109/ICNSURV.2018.8384880, April 2018,
              <https://doi.org/10.1109/ICNSURV.2018.8384880>.

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

   [SAJ14]    Haindl, B., Meser, J., Sajatovic, M., Muller, S.,
              Arthaber, H., Faseth, T., and M. Zaisberger, "LDACS1
              conformance and compatibility assessment", 2014 IEEE/AIAA
              33rd Digital Avionics Systems Conference (DASC), pp.
              3B3-1-3B3-11, DOI 10.1109/DASC.2014.6979447, October 2014,
              <https://doi.org/10.1109/DASC.2014.6979447>.

   [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", 2008 Integrated Communications,
              Navigation and Surveillance Conference, pp. 1-12,
              DOI 10.1109/ICNSURV.2008.4559173, 2008,
              <https://doi.org/10.1109/ICNSURV.2008.4559173>.

   [SCH14]    Schnell, M., Epple, U., Shutin, D., and N.
              Schneckenburger, "LDACS: Future Aeronautical
              Communications for Air- Traffic Management", IEEE
              Communications Magazine, vol. 52, no. 5, pp. 104-110,
              DOI 10.1109/MCOM.2014.6815900, May 2014,
              <https://doi.org/10.1109/MCOM.2014.6815900>.

   [SCH19]    German Aerospace Center (DLR), "DLR tests digital
              communications technologies combined with additional
              navigation functions for the first time", 27 March 2019,
              <https://www.dlr.de/en/latest/
              news/2019/01/20190327_modern-technology-for-the-flight-
              deck>.

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

   [Sudhakaran2021]
              Sudhakaran, S., Montgomery, K., Kashef, M., Cavalcanti,
              D., and R. Candell, "Wireless Time Sensitive Networking
              for Industrial Collaborative Robotic Workcells", 2021 17th
              IEEE International Conference on Factory Communication
              Systems (WFCS), pp. 91-94,
              DOI 10.1109/WFCS46889.2021.9483447, 2021,
              <https://ieeexplore.ieee.org/abstract/document/9483447>.

   [SYSTOVER5G]
              3GPP, "5G System Overview", 8 August 2022,
              <https://www.3gpp.org/technologies/5g-system-overview>.

   [TiSCH]    IETF, "IPv6 over the TSCH mode over 802.15.4e",
              <https://datatracker.ietf.org/doc/charter-ietf-6tisch/>.

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

   [TR2370046]
              3GPP, "Study on 5GS Deterministic Networking (DetNet)
              interworking", 3GPP TR 23.700-46,
              <https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=3994>.

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

   [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; NR and NG-RAN Overall description; Stage-2",
              3GPP TS 38.300,
              <https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=3191>.

   [TSN5G]    5G-ACIA, "Integration of 5G with Time-Sensitive Networking
              for Industrial Communications", 5G-ACIA White Paper,
              <https://5g-acia.org/whitepapers/integration-of-5g-with-
              time-sensitive-networking-for-industrial-communications>.

   [vilajosana21]
              Vilajosana, X., Watteyne, T., Chang, T., Vucinic, M.,
              Duquennoy, S., and P. Thubert, "IETF 6TiSCH: A Tutorial",
              Communications Surveys and Tutorials, IEEE Communications
              Society, HAL ID: hal-02420974,
              DOI 10.1109/COMST.2019.2939407, December 2019,
              <https://inria.hal.science/hal-02420974/file/
              IETF_6TiSCH__A_Tutorial__17099609gkvsxdpffdvc_%20(1).pdf>.

   [WFA]      "Wi-Fi Alliance", <https://www.wi-fi.org>.

   [WirelessHART]
              FieldComm Group, "WirelessHART",
              <https://www.fieldcommgroup.org/technologies/
              wirelesshart>.

Acknowledgments

   Many thanks to the participants of the RAW WG, where a lot of the
   work discussed in this document happened, and to Malcolm Smith for
   his review of the section on IEEE 802.11.  Special thanks for post
   directorate and IESG reviewers Roman Danyliw, Victoria Pritchard,
   Donald Eastlake, Mohamed Boucadair, Jiankang Yao, Shivan Kaul Sahib,
   Mallory Knodel, Ron Bonica, Ketan Talaulikar, Éric Vyncke, and Carlos
   J. Bernardos.

Contributors

   This document aggregates articles from authors specialized in each
   technology.  Beyond the main authors listed on the front page, the
   following contributors proposed additional text and refinements that
   improved the document.

   *  Georgios Z. Papadopoulos contributed to Section 5 ("IEEE 802.15.4
      Time-Slotted Channel Hopping (TSCH)").

   *  Nils Maeurer and Thomas Graeupl contributed to Section 7 ("L-Band
      Digital Aeronautical Communications System (LDACS)").

   *  Torsten Dudda, Alexey Shapin, and Sara Sandberg contributed to
      Section 6 ("5G").

   *  Rocco Di Taranto contributed to Section 4 ("IEEE 802.11").

   *  Rute Sofia contributed to Section 1 ("Introduction") and Section 2
      ("Terminology").

Authors' Addresses

   Pascal Thubert (editor)
   Independent
   06330 Roquefort-les-Pins
   France
   Email: pascal.thubert@gmail.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


   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
