Skip to main content

Reliable and Available Wireless Technologies
draft-ietf-raw-technologies-10

Document Type Active Internet-Draft (detnet WG)
Authors Pascal Thubert , Dave Cavalcanti , Xavier Vilajosana , Corinna Schmitt , János Farkas
Last updated 2024-09-18 (Latest revision 2024-09-03)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Informational
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Associated WG milestones
Sep 2020
Working Group Adoption of Technologies Document
Feb 2022
Technologies Document submit to IESG
Document shepherd Carlos J. Bernardos
Shepherd write-up Show Last changed 2023-07-25
IESG IESG state Waiting for AD Go-Ahead::Revised I-D Needed
Action Holders
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Roman Danyliw
Send notices to cjbc@it.uc3m.es
IANA IANA review state IANA OK - No Actions Needed
draft-ietf-raw-technologies-10
RAW                                                      P. Thubert, Ed.
Internet-Draft                                                          
Intended status: Informational                             D. Cavalcanti
Expires: 7 March 2025                                              Intel
                                                           X. Vilajosana
                                         Universitat Oberta de Catalunya
                                                              C. Schmitt
                                        Research Institute CODE, UniBw M
                                                               J. Farkas
                                                                Ericsson
                                                        3 September 2024

              Reliable and Available Wireless Technologies
                     draft-ietf-raw-technologies-10

Abstract

   This document presents a series of recent technology evolutions that
   appeared in the last 10-15 years and are capable of time
   synchronization and scheduling of transmission, making them suitable
   to carry time-sensitive flows with high reliability and availability.

Status of This Memo

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

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

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

   This Internet-Draft will expire on 7 March 2025.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.

Thubert, et al.           Expires 7 March 2025                  [Page 1]
Internet-Draft              RAW Technologies              September 2024

   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Towards Reliable and Available Networks . . . . . . . . . . .   5
     3.1.  Scheduling for Reliability  . . . . . . . . . . . . . . .   5
     3.2.  Diversity for Availability  . . . . . . . . . . . . . . .   5
     3.3.  Benefits of Scheduling  . . . . . . . . . . . . . . . . .   6
   4.  IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  Provenance and Documents  . . . . . . . . . . . . . . . .   7
     4.2.  802.11ax High Efficiency (HE) . . . . . . . . . . . . . .   9
       4.2.1.  General Characteristics . . . . . . . . . . . . . . .   9
       4.2.2.  Applicability to deterministic flows  . . . . . . . .  11
     4.3.  802.11be Extreme High Throughput (EHT)  . . . . . . . . .  13
       4.3.1.  General Characteristics . . . . . . . . . . . . . . .  13
       4.3.2.  Applicability to deterministic flows  . . . . . . . .  13
     4.4.  802.11ad and 802.11ay (mmWave operation)  . . . . . . . .  15
       4.4.1.  General Characteristics . . . . . . . . . . . . . . .  15
       4.4.2.  Applicability to deterministic flows  . . . . . . . .  15
     4.5.  Summary . . . . . . . . . . . . . . . . . . . . . . . . .  16
   5.  IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . .  16
     5.1.  Provenance and Documents  . . . . . . . . . . . . . . . .  16
     5.2.  TimeSlotted Channel Hopping . . . . . . . . . . . . . . .  18
       5.2.1.  General Characteristics . . . . . . . . . . . . . . .  18
       5.2.2.  Applicability to Deterministic Flows  . . . . . . . .  23
     5.3.  Summary . . . . . . . . . . . . . . . . . . . . . . . . .  29
   6.  5G  . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  29
     6.1.  Provenance and Documents  . . . . . . . . . . . . . . . .  29
     6.2.  General Characteristics . . . . . . . . . . . . . . . . .  31
     6.3.  Deployment and Spectrum . . . . . . . . . . . . . . . . .  33
     6.4.  Applicability to Deterministic Flows  . . . . . . . . . .  34
       6.4.1.  System Architecture . . . . . . . . . . . . . . . . .  34
       6.4.2.  Overview of The Radio Protocol Stack  . . . . . . . .  36
       6.4.3.  Radio (PHY) . . . . . . . . . . . . . . . . . . . . .  37
       6.4.4.  Scheduling and QoS (MAC)  . . . . . . . . . . . . . .  39
       6.4.5.  Time-Sensitive Communications (TSC) . . . . . . . . .  41
     6.5.  Summary . . . . . . . . . . . . . . . . . . . . . . . . .  46
   7.  L-band Digital Aeronautical Communications System . . . . . .  46
     7.1.  Provenance and Documents  . . . . . . . . . . . . . . . .  47
     7.2.  General Characteristics . . . . . . . . . . . . . . . . .  48
     7.3.  Deployment and Spectrum . . . . . . . . . . . . . . . . .  49
     7.4.  Applicability to Deterministic Flows  . . . . . . . . . .  49

Thubert, et al.           Expires 7 March 2025                  [Page 2]
Internet-Draft              RAW Technologies              September 2024

       7.4.1.  System Architecture . . . . . . . . . . . . . . . . .  50
       7.4.2.  Overview of The Radio Protocol Stack  . . . . . . . .  50
       7.4.3.  Radio (PHY) . . . . . . . . . . . . . . . . . . . . .  51
       7.4.4.  Scheduling, Frame Structure and QoS (MAC) . . . . . .  52
     7.5.  Summary . . . . . . . . . . . . . . . . . . . . . . . . .  54
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  55
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  55
   10. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  55
   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  56
   12. Normative References  . . . . . . . . . . . . . . . . . . . .  56
   13. Informative References  . . . . . . . . . . . . . . . . . . .  56
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  65

1.  Introduction

   When used in math or philosophy, the term "deterministic" generally
   refers to a perfection where all aspects are understood and
   predictable.  A perfectly deterministic network would ensure that
   every packet reaches its destination following a predetermined path
   along a predefined schedule to be delivered at the exact due time.
   In a real and imperfect world, a deterministic network must be highly
   predictable, which is a combination of reliability and availability.

   *  On the one hand the network must be reliable, meaning that it will
      perform as expected for all but very few packets and in particular
      that it will deliver the packets at the destination within a pre-
      defined time interval.

   *  On the other hand, the network must be available, meaning that it
      has to be resilient to any single outage, independently of the
      cause of the failure, be it software, hardware, or external, e.g.,
      a physical event impacting the transmission channel.

   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 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 to ensure delivery of each
   packet's data in spite of the loss 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.

Thubert, et al.           Expires 7 March 2025                  [Page 3]
Internet-Draft              RAW Technologies              September 2024

   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.  The Reliable and Available Wireless
   (RAW) Architecture [I-D.ietf-raw-architecture] extends the DetNet
   Architecture [RFC8655] and other standard IETF concepts and
   mechanisms to adapt to the specific challenges of the wireless
   medium, in particular intermittently lossy connectivity, by extending
   and optimizing the use of diversity and multipathing.

   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 (aka Automatic Repeat request or ARQ),

   *  variation of the modulation and coding scheme (MCS),

   *  short range broadcast,

   *  Multiple 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 Operations, Administration and Maintenance
   (OAM), a Path computation Element (PCE), A runtime distributed Path
   Selection Engine (PSE) and the PAREO functions.

   This document browses the short and middle range radio technologies
   that are suitable to provide a DetNet/RAW service over, 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, TimeSlotted Channel Hopping (TSCH), 3GPP
   5G, and L-band Digital Aeronautical Communications System (LDACS).

Thubert, et al.           Expires 7 March 2025                  [Page 4]
Internet-Draft              RAW Technologies              September 2024

2.  Terminology

   This document uses the terminology and acronyms defined in section 2
   of [RFC8655] and section 2 of [I-D.ietf-raw-architecture].

3.  Towards Reliable and Available Networks

3.1.  Scheduling for Reliability

   A packet network is reliable for critical (e.g., time-sensitive)
   packets when the undesirable statistical effects that affect the
   transmission of those packets, e.g., delay or loss, are eliminated.

   The reliability of a Deterministic Network [RFC8655] often relies on
   precisely applying a tight schedule that controls the use of time-
   shared resources such as CPUs and buffers, and maintains at all time
   the amount of the critical packets within the physical capabilities
   of the hardware and that of the transmission medium.  The schedule
   can also be used to shape the flows by controlling the time of
   transmission of the packets that compose the flow at every hop.

   To achieve this, there must be a shared sense of time throughout the
   network.  The sense of time is usually provided by the lower layer
   and is not in scope for RAW.  As an example, the Precision Time
   Protocol, standardized as IEEE 1588 and IEC 61588, has mapping
   through profiles to Ethernet, industrial and SmartGrid protocols, and
   Wi-Fi with IEEE Std 802.1AS.

3.2.  Diversity for Availability

   Equipment failure, such as a switch or an access point rebooting, a
   broken wire or radio adapter, or a fixed obstacle to the
   transmission, can be the cause of multiple packets lost in a row
   before the flows are rerouted or the system may recover.

   This is not acceptable for critical applications such as related to
   safety.  A typical process control loop will tolerate an occasional
   packet loss, but a loss of several packets in a row will cause an
   emergency stop.  In an amusement park, a continuous loss of packet
   for a few 100ms may trigger an automatic interruption of the ride and
   cause the evacuation and the reboot of the game.

Thubert, et al.           Expires 7 March 2025                  [Page 5]
Internet-Draft              RAW Technologies              September 2024

   Network Availability is obtained by making the transmission resilient
   against hardware failures and radio transmission losses due to
   uncontrolled events such as co-channel interferers, multipath fading
   or moving obstacles.  The best results are typically achieved by
   pseudo-randomly cumulating all forms of diversity, in the spatial
   domain with replication and elimination, in the time domain with ARQ
   and diverse scheduled transmissions, and in the frequency domain with
   frequency hopping or channel hopping between frames.

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 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.  Sender
      and receiver are synchronized and scheduled to talk on a given
      frequency resource at a given time and for a given duration.  This
      way, scheduling can avoid collisions between scheduled
      transmissions and enable a high ratio of critical traffic compared
      to QoS-based priority.

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

   *  Transmissions can be also scheduled on multiple channels in
      parallel, which enables to use the full available spectrum while
      avoiding the hidden terminal problem, e.g., when the next packet
      in a same flow interferes on a same channel with the previous one
      that progressed a few hops farther.

Thubert, et al.           Expires 7 March 2025                  [Page 6]
Internet-Draft              RAW Technologies              September 2024

   *  On the other hand, scheduling optimizes the bandwidth usage:
      compared to classical Collision Avoidance techniques, there is no
      blank time related to inter-frame space (IFS) and exponential
      back-off in scheduled operations.  A minimal Clear Channel
      Assessment may be needed to comply with the local regulations such
      as ETSI 300-328, but that will not detect a collision when the
      senders are synchronized.

   *  Finally, scheduling plays a critical role to save energy.  In IoT,
      energy is the foremost concern, and synchronizing sender and
      listener enables to always maintain them in deep sleep when there
      is no scheduled transmission.  This avoids idle listening and long
      preambles and enables long sleep periods between traffic and
      resynchronization, allowing battery-operated nodes to operate in a
      mesh topology for multiple years.

4.  IEEE 802.11

4.1.  Provenance and Documents

   With an active portfolio of nearly 1,300 standards and projects under
   development, IEEE is a leading developer of industry standards in a
   broad range of technologies that drive the functionality,
   capabilities, and interoperability of products and services,
   transforming how people live, work, and communicate.

   The IEEE 802 LAN/MAN Standards Committee (SC) develops and maintains
   networking standards and recommended practices for local,
   metropolitan, and other area networks, using an open and accredited
   process, and advocates them on a global basis.  The most widely used
   standards are for Ethernet, Bridging and Virtual Bridged LANs
   Wireless LAN, Wireless PAN, Wireless MAN, Wireless Coexistence, Media
   Independent Handover Services, and Wireless RAN.  An individual
   Working Group provides the focus for each area.  Standards produced
   by the IEEE 802 SC are freely available from the IEEE GET Program
   after they have been published in PDF for six months.

   The IEEE 802.11 Wireless LAN (WLAN) standards define the underlying
   MAC and PHY layers for the Wi-Fi technology.  Wi-Fi/802.11 is one of
   the most successful wireless technologies, supporting many
   application domains.  While previous 802.11 generations, such as
   802.11n and 802.11ac, have focused mainly on improving peak
   throughput, more recent generations are also considering other
   performance vectors, such as efficiency enhancements for dense
   environments in IEEEE Std 802.11ax [IEEE Std 802.11ax], throughput,
   latency, and reliability enhancements in P802.11be [IEEE 802.11be
   WIP].

Thubert, et al.           Expires 7 March 2025                  [Page 7]
Internet-Draft              RAW Technologies              September 2024

   IEEE Std 802.11-2012 introduced support for TSN time synchronization
   based on IEEE 802.1AS over 802.11 Timing Measurement protocol.  IEEE
   Std 802.11-2016 extended the 802.1AS operation over 802.11 Fine
   Timing Measurement (FTM), as well as the Stream Reservation Protocol
   (IEEE 802.1Qat). 802.11 WLANs can also be part of a 802.1Q bridged
   networks with enhancements enabled by the 802.11ak amendment now
   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 adds new
   scheduling capabilities that can enhance the timeliness performance
   in the 802.11 MAC and achieve lower bounded latency.  The IEEE
   802.11be is undergoing efforts to enhance the support for 802.1 TSN
   capabilities especially related to worst-case latency, reliability
   and availability.

   The IEEE 802.11 working group has been working in collaboration with
   the IEEE 802.1 working group for several years extending some 802.1
   features over 802.11.  As with any wireless media, 802.11 imposes new
   constraints and restrictions to TSN-grade QoS, and tradeoffs between
   latency and reliability guarantees must be considered as well as
   managed deployment requirements.  An overview of 802.1 TSN
   capabilities and challenges for their extensions to 802.11 are
   discussed in [Cavalcanti_2019].

   Wi-Fi Alliance (WFA) is the worldwide network of companies that
   drives global Wi-Fi adoption and evolution through thought
   leadership, spectrum advocacy, and industry-wide collaboration.  The
   WFA work helps ensure that Wi-Fi devices and networks provide users
   the interoperability, security, and reliability they have come to
   expect.

   Avnu Alliance is also a global industry forum developing
   interoperability testing for TSN capable devices across multiple
   media including Ethernet, Wi-Fi, and 5G.

   The following [IEEE Std 802.11] specifications/certifications are
   relevant in the context of reliable and available wireless services
   and support for time-sensitive networking capabilities:

   Time Synchronization:  IEEE802.11-2016 with IEEE802.1AS; WFA TimeSync
      Certification.

   Congestion Control:  IEEE Std 802.11-2016 Admission Control; WFA
      Admission Control.

   Security:  WFA Wi-Fi Protected Access, WPA2 and WPA3.

Thubert, et al.           Expires 7 March 2025                  [Page 8]
Internet-Draft              RAW Technologies              September 2024

   Interoperating with IEEE802.1Q bridges:  IEEE Std 802.11-2020
      incorporating 802.11ak.

   Stream Reservation Protocol (part of [IEEE Std 802.1Qat]):
      AIEEE802.11-2016

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

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

   In addition, major amendments being developed by the IEEE802.11
   Working Group include capabilities that can be used as the basis for
   providing more reliable and predictable wireless connectivity and
   support time-sensitive applications:

   IEEE 802.11ax D4.0: Enhancements for High Efficiency (HE).  [IEEE Std
      802.11ax]

   IEEE 802.11be Extreme High Throughput (EHT).  [IEEE 802.11be WIP]

   IEE 802.11ay Enhanced throughput for operation in license-exempt
   bands above 45 GHz.  [IEEE Std 802.11ay]

   The main 802.11ax, 802.11be, 802.11ad, and 802.11ay capabilities and
   their relevance to RAW are discussed in the remainder of this
   section.

4.2.  802.11ax High Efficiency (HE)

4.2.1.  General Characteristics

   The next generation Wi-Fi (Wi-Fi 6) is based on the IEEE802.11ax
   amendment [IEEE Std 802.11ax], which includes new capabilities to
   increase efficiency, control and reduce latency.  Some of the new
   features include higher order 1024-QAM modulation, support for uplink
   multiple user (MU) multiple input multiple output (MIMO), orthogonal
   frequency-division multiple access (OFDMA), trigger-based access and
   Target Wake time (TWT) for enhanced power savings.  The OFDMA mode
   and trigger-based access enable the AP, after reserving the channel
   using the clear channel assessment procedure for a given duration, to
   schedule multi-user transmissions, which is a key capability required
   to increase latency predictability and reliability for time-sensitive
   flows. 802.11ax can operate in up to 160 MHz channels and it includes
   support for operation in the new 6 GHz band, which is expected to be

Thubert, et al.           Expires 7 March 2025                  [Page 9]
Internet-Draft              RAW Technologies              September 2024

   open to unlicensed use by the FCC and other regulatory agencies
   worldwide.

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

   802.11ax introduced a new OFDMA mode in which multiple users can be
   scheduled across the frequency domain.  In this mode, the Access
   Point (AP) can initiate multi-user (MU) Uplink (UL) transmissions in
   the same PHY Protocol Data Unit (PPDU) by sending a trigger frame.
   This centralized scheduling capability gives the AP much more control
   of the channel in its Basic Service Set (BSS) and it can remove
   contention between associated stations for uplink transmissions,
   therefore reducing the randomness caused by CSMA-based access between
   stations within the same BSS.  The AP can also transmit
   simultaneously to multiple users in the downlink direction by using a
   Downlink (DL) MU OFDMA PPDU.  In order to initiate a contention free
   Transmission Opportunity (TXOP) using the OFDMA mode, the AP still
   follows the typical listen before talk procedure to acquire the
   medium, which ensures interoperability and compliance with unlicensed
   band access rules.  However, 802.11ax also includes a multi-user
   Enhanced Distributed Channel Access (MU-EDCA) capability, which
   allows the AP to get higher channel access priority than other
   devices in its BSS.

4.2.1.2.  Traffic Isolation via OFDMA Resource Management and Resource
          Unit Allocation

   802.11ax relies on the notion of OFDMA Resource Unit (RU) to allocate
   frequency chunks to different STAs over time.  RUs provide a way to
   allow for multiple stations to transmit simultaneously, starting and
   ending at the same time.  The way this is achieved is via padding,
   where extra bits are transmitted with the same power level.  The
   current RU allocation algorithms provide a way to achieve traffic
   isolation per station which while per se does not support time-aware
   scheduling, is a key aspect to assist reliability, as it provides
   traffic isolation in a shared medium.  IEEE 802.11be (see
   Section 4.3) is currently considering further and more flexible
   approaches concerning RU allocation.

4.2.1.3.  Improved PHY Robustness

   The 802.11ax PHY can operate with 0.8, 1.6 or 3.2 microsecond guard
   interval (GI).  The larger GI options provide better protection
   against multipath, which is expected to be a challenge in industrial
   environments.  The possibility to operate with smaller resource units
   (e.g. 2 MHz) enabled by OFDMA also helps reduce noise power and
   improve SNR, leading to better packet error rate (PER) performance.

Thubert, et al.           Expires 7 March 2025                 [Page 10]
Internet-Draft              RAW Technologies              September 2024

   802.11ax supports beamforming as in 802.11ac, but introduces UL MU
   MIMO, which helps improve reliability.  The UL MU MIMO capability is
   also enabled by the trigger based access operation in 802.11ax.

4.2.1.4.  Support for 6GHz band

   The 802.11ax specification [IEEE Std 802.11ax] includes support for
   operation in the new 6 GHz band.  Given the amount of new spectrum
   available as well as the fact that no legacy 802.11 device (prior
   802.11ax) will be able to operate in this new band, 802.11ax
   operation in this new band can be even more efficient.

4.2.2.  Applicability to deterministic flows

   TSN capabilities, as defined by the IEEE 802.1 TSN standards, provide
   the underlying mechanism for supporting deterministic flows in a
   Local Area Network (LAN).  The 802.11 working group has incorporated
   support for absolute time synchronization to extend the TSN 802.1AS
   protocol so that time-sensitive flow can experience precise time
   synchronization when operating over 802.11 links.  As IEEE 802.11 and
   IEEE 802.1 TSN are both based on the IEEE 802 architecture, 802.11
   devices can directly implement some TSN capabilities without the need
   for a gateway/translation protocol.  Basic features required for
   operation in a 802.1Q LAN are already enabled for 802.11.  Some TSN
   capabilities, such as 802.1Qbv, can already operate over the existing
   802.11 MAC SAP [Sudhakaran2021].  Implementation and experimental
   results of TSN capabilities (802.1AS, 802.1Qbv, and 802.1CB) extended
   over standard Ethernet and Wi-Fi devices have also been described in
   [Fang_2021].  Nevertheless, the IEEE 802.11 MAC/PHY could be extended
   to improve the operation of IEEE 802.1 TSN features and achieve
   better performance metrics [Cavalcanti1287].

   TSN capabilities supported over 802.11 (which also extends to
   802.11ax), include:

   1.  802.1AS based Time Synchronization (other time synchronization
       techniques may also be used)

   2.  Interoperating with IEEE802.1Q bridges

   3.  Time-sensitive Traffic Stream Classification

   The existing 802.11 TSN capabilities listed above, and the 802.11ax
   OFDMA and AP-controlled access within a BSS provide a new set of
   tools to better serve time-sensitive flows.  However, it is important
   to understand the tradeoffs and constraints associated with such
   capabilities, as well as redundancy and diversity mechanisms that can
   be used to provide more predictable and reliable performance.

Thubert, et al.           Expires 7 March 2025                 [Page 11]
Internet-Draft              RAW Technologies              September 2024

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. industrial/enterprise network).  This
   enables to carefully manage and integrate the Wi-Fi operation with
   the overall TSN management framework, as defined in the
   [IEEE802.1Qcc] specification.

   Some of the random-access latency and interference from legacy/
   unmanaged devices can be reduced under a centralized management mode
   as defined in [IEEE802.1Qcc].

   Existing traffic stream identification, configuration and admission
   control procedures defined in [IEEE Std 802.11] QoS mechanism can be
   re-used.  However, given the high degree of determinism required by
   many time-sensitive applications, additional capabilities to manage
   interference and legacy devices within tight time-constraints need to
   be explored.

4.2.2.2.  Scheduling for bounded latency and diversity

   As discussed earlier, the [IEEE Std 802.11ax] OFDMA mode introduces
   the possibility of assigning different RUs (time/frequency resources)
   to users within a PPDU.  Several RU sizes are defined in the
   specification (26, 52, 106, 242, 484, 996 subcarriers).  In addition,
   the AP can also decide on MCS (Modulation and Coding Scheme) and
   grouping of users within a given OFMDA PPDU.  Such flexibility can be
   leveraged to support time-sensitive applications with bounded
   latency, especially in a managed network where stations can be
   configured to operate under the control of the AP, in a controlled
   environment (which contains only devices operating on the unlicensed
   band installed by the facility owner and where unexpected
   interference from other systems and/or radio access technologies only
   sporadically happens), or in a deployment where channel/link
   redundancy is used to reduce the impact of unmanaged devices/
   interference.

   When the network is lightly loaded, it is possible to achieve
   latencies under 1 msec when Wi-Fi is operated in contention-based
   (i.e., without OFDMA) mode.  It is also has been shown that it is
   possible to achieve 1 msec latencies in controlled environment with
   higher efficiency when multi-user transmissions are used (enabled by
   OFDMA operation) [Cavalcanti_2019].  Obviously, there are latency,
   reliability and capacity tradeoffs to be considered.  For instance,
   smaller RUs result in longer transmission durations, which may impact
   the minimal latency that can be achieved, but the contention latency
   and randomness elimination in an interference-free environment due to
   multi-user transmission is a major benefit of the OFDMA mode.

Thubert, et al.           Expires 7 March 2025                 [Page 12]
Internet-Draft              RAW Technologies              September 2024

   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

   The ongoing [IEEE 802.11be WIP] project is the next major 802.11
   amendment (after IEEE Std 802.11ax-2021) for operation in the 2.4, 5
   and 6 GHz bands. 802.11be is expected to include new PHY and MAC
   features and it is targeting extremely high throughput (at least 30
   Gbps), as well as enhancements to worst case latency and jitter.  It
   is also expected to improve the integration with 802.1 TSN to support
   time-sensitive applications over Ethernet and Wireless LANs.

   The 802.11be Task Group started its operation in May 2019, therefore,
   detailed information about specific features is not yet available.
   Only high level candidate features have been discussed so far,
   including:

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

   2.  Multi-link operation.

   3.  16 spatial streams and related MIMO enhancements.

   4.  Multi-Access Point (AP) Coordination.

   5.  Enhanced link adaptation and retransmission protocol, e.g.
       Hybrid Automatic Repeat Request (HARQ).

   6.  Any required adaptations to regulatory rules for the 6 GHz
       spectrum.

4.3.2.  Applicability to deterministic flows

   The 802.11 Real-Time Applications (RTA) Topic Interest Group (TIG)
   provided detailed information on use cases, issues and potential
   solution directions to improve support for time-sensitive
   applications in 802.11.  The RTA TIG report [IEEE_doc_11-18-2009-06]
   was used as input to the 802.11be project scope.

   Improvements for worst-case latency, jitter and reliability were the
   main topics identified in the RTA report, which were motivated by
   applications in gaming, industrial automation, robotics, etc.  The

Thubert, et al.           Expires 7 March 2025                 [Page 13]
Internet-Draft              RAW Technologies              September 2024

   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.

   802.11be is expected to build on and enhance 802.11ax capabilities to
   improve worst case latency and jitter.  Some of the enhancement areas
   are discussed next.

4.3.2.1.  Enhanced scheduled operation for bounded latency

   In addition to the throughput enhancements, 802.11be will leverage
   the trigger-based scheduled operation enabled by 802.11ax to provide
   efficient and more predictable medium access. 802.11be is expected to
   include enhancements to reduce overhead and enable more efficient
   operation in managed network deployments [IEEE_doc_11-19-0373-00].

4.3.2.2.  Multi-AP coordination

   Multi-AP coordination is one of the main new candidate features in
   802.11be.  It can provide benefits in throughput and capacity and has
   the potential to address some of the issues that impact worst case
   latency and reliability.  Multi-AP coordination is expected to
   address the contention due to overlapping Basic Service Sets (OBSS),
   which is one of the main sources of random latency variations.

   Overall, multi-AP coordination algorithms consider three different
   phases: setup (where APs handling overlapping BSSs are assigned roles
   in a manual or automated way, e.g., coordinator and coordinated APs);
   coordination (where APs establish links among themselves, e.g., from
   a coordinating AP to coordinated APs; and then assign resources to
   served stations); transmission (where the coordinating APs optimize
   the distribution of the transmission opportunities).

   Several multi-AP coordination approaches have been discussed with
   different levels of complexities and benefits, but specific
   coordination methods have not yet been defined.  Out of the different
   categories, MAC-driven examples include: coordinated OFDMA (Co-
   OFDMA); Coordinated TDMA (Co-TDMA); HARQ; whereas PHY-driven examples
   include: Coordinated Spatial Reuse (Co-SR) and Coordinated
   Beamforming (Co-BF).

Thubert, et al.           Expires 7 March 2025                 [Page 14]
Internet-Draft              RAW Technologies              September 2024

4.3.2.3.  Multi-link operation

   802.11be will introduce new features to improve operation over
   multiple links and channels.  By leveraging multiple links/channels,
   802.11be can isolate time-sensitive traffic from network congestion,
   one of the main causes of large latency variations.  In a managed
   802.11be network, it should be possible to steer traffic to certain
   links/channels to isolate time-sensitive traffic from other traffic
   and help achieve bounded latency.  The multi-link operation (MLO) has
   been already introduced in the 802.11be Draft and it can also enhance
   latency and reliability by enabling data frames to be duplicated
   across links.

4.4.  802.11ad and 802.11ay (mmWave operation)

4.4.1.  General Characteristics

   The IEEE 802.11ad amendment defines PHY and MAC capabilities to
   enable multi-Gbps throughput in the 60 GHz millimeter wave (mmWave)
   band.  The standard addresses the adverse mmWave signal propagation
   characteristics and provides directional communication capabilities
   that take advantage of beamforming to cope with increased
   attenuation.  An overview of the 802.11ad standard can be found in
   [Nitsche_2015].

   The IEEE 802.11ay is currently developing enhancements to the
   802.11ad standard to enable the next generation mmWave operation
   targeting 100 Gbps throughput.  Some of the main enhancements in
   802.11ay include MIMO, channel bonding, improved channel access and
   beamforming training.  An overview of the 802.11ay capabilities can
   be found in [Ghasempour_2017].

4.4.2.  Applicability to deterministic flows

   The high data rates achievable with 802.11ad and 802.11ay can
   significantly reduce latency down to microsecond levels.  Limited
   interference from legacy and other unlicensed devices in 60 GHz is
   also a benefit.  However, directionality and short range typical in
   mmWave operation impose new challenges such as the overhead required
   for beam training and blockage issues, which impact both latency and
   reliability.  Therefore, it is important to understand the use case
   and deployment conditions in order to properly apply and configure
   802.11ad/ay networks for time sensitive applications.

   The 802.11ad standard includes a scheduled access mode in which the
   central controller, after contending and reserving the channel for a
   dedicated period, can allocate to stations contention-free service
   periods.  This scheduling capability is also available in 802.11ay,

Thubert, et al.           Expires 7 March 2025                 [Page 15]
Internet-Draft              RAW Technologies              September 2024

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

4.5.  Summary

   Since Wi-Fi 6, the evolution of the IEEE Std 802.11 standard is
   taking a new direction, looking not any more for more speed, but also
   for reliability, to enable new fields of application such as
   Industrial IoT and Virtual Reality.

   One step at a time, Wi-Fi 6, 7, and now 8 include more capabilities
   to schedule and deliver frames in due time at fast rates.  Still, as
   any radio technology, Wi-Fi is sensitive to frame loss, which can
   only be combatted with the maximum use of diversity, in space, time,
   channel, and even technology.

   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.

5.  IEEE 802.15.4

5.1.  Provenance and Documents

   The IEEE802.15.4 Task Group has been driving the development of low-
   power low-cost radio technology.  The IEEE802.15.4 physical layer has
   been designed to support demanding low-power scenarios targeting the
   use of unlicensed bands, both the 2.4 GHz and sub GHz Industrial,
   Scientific and Medical (ISM) bands.  This has imposed requirements in
   terms of frame size, data rate and bandwidth to achieve reduced
   collision probability, reduced packet error rate, and acceptable
   range with limited transmission power.  The PHY layer supports frames
   of up to 127 bytes.  The Medium Access Control (MAC) sublayer
   overhead is in the order of 10-20 bytes, leaving about 100 bytes to
   the upper layers.  IEEE802.15.4 uses spread spectrum modulation such
   as the Direct Sequence Spread Spectrum (DSSS).

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

   Time sensitive networking on low power constrained wireless networks,
   building on IEEE802.15.4, have been partially addressed by ISA100.11a
   [ISA100.11a] and WirelessHART [WirelessHART].  Both technologies
   involve a central controller that computes redundant paths for

Thubert, et al.           Expires 7 March 2025                 [Page 16]
Internet-Draft              RAW Technologies              September 2024

   industrial process control traffic over a TSCH mesh.  Moreover,
   ISA100.11a introduces IPv6 [RFC8200] capabilities with a Link-Local
   Address for the join process and a global unicast addres for later
   exchanges, but the IPv6 traffic typically ends at a local application
   gateway and the full power of IPv6 for end-to-end communication is
   not enabled.

   At the IETF, the 6TiSCH working group [TiSCH] has enabled distributed
   scheduling to exploit the deterministic access capabilities provided
   by TSCH for IPv6.  The group designed the essential mechanisms to
   enable the management plane operation while ensuring IPv6 is
   supported.

   6TiSCH defines the 6top layer, composed of one or more Scheduling
   Functions (SFs) and the 6top Protocol (6P Protocol) defined in
   RFC8480 [RFC8480].  The 6P Protocol provides a pairwise negotiation
   mechanism to the control plane operation.  The protocol supports
   agreement on a schedule between neighbors, enabling distributed
   scheduling.  6P goes hand-in-hand with a Scheduling Function (SF),
   the policy that decides how to maintain cells and trigger 6P
   transactions.  The Minimal Scheduling Function (MSF) [RFC9033] is the
   default SF defined by the 6TiSCH WG.  With these mechanisms 6TiSCH
   can establish layer 2 links between neighbouring nodes and support
   best effort traffic.  RPL [RFC8480] provides the routing structure,
   enabling the 6TiSCH devices to establish the links with well
   connected neighbours and thus forming the acyclic network graphs.

   A Track at 6TiSCH is the application to wireless of the concept of a
   Recovery Graph in the RAW architecture.  A Track can follow a simple
   sequence of relay nodes or can be structured as a more complex
   Destination Oriented Directed Acyclic Graph (DODAG) to a unicast
   destination.  Along a Track, 6TiSCH nodes reserve the resources to
   enable the efficient transmission of packets while aiming to optimize
   certain properties such as reliability and ensure small jitter or
   bounded latency.  The Track structure enables Layer-2 forwarding
   schemes, reducing the overhead of taking routing decisions at the
   Layer-3.

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

Thubert, et al.           Expires 7 March 2025                 [Page 17]
Internet-Draft              RAW Technologies              September 2024

   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 to other standards like RPL and
   6Lo.

5.2.  TimeSlotted Channel Hopping

5.2.1.  General Characteristics

   As a core technique in IEEE802.15.4, TSCH splits time in multiple
   time slots that repeat over time.  Each device has its own
   perspective of when the send or receive 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 (more in Section 5.2.2.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 which maps to a frequency at each iteration of the
   slotframe.  Each packet exchanged between neighbors happens within
   one cell.  The size of a cell is a timeslot duration, between 10 to
   15 milliseconds.  An Absolute Slot Number (ASN) indicates the number
   of slots elapsed since the network started.  It increments at every
   slot.  This is a 5 byte counter that can support networks running for
   more than 300 years without wrapping (assuming a 10 ms timeslot).
   Channel hopping provides increased reliability to multi-path fading
   and external interference.  It is handled by TSCH through a channel
   hopping sequence referred as macHopSeq in the IEEE802.15.4
   specification.

   The Time-Frequency Division Multiple Access provided by TSCH enables
   the orchestration of traffic flows, spreading them in time and
   frequency, and hence enabling an efficient management of the
   bandwidth utilization.  Such efficient bandwidth utilization can be
   combined to OFDM modulations also supported by the IEEE802.15.4
   standard [IEEE Std 802.15.4] since the 2015 version.

Thubert, et al.           Expires 7 March 2025                 [Page 18]
Internet-Draft              RAW Technologies              September 2024

   TSCH networks operate in ISM bands in which the spectrum is shared by
   different coexisting technologies.  Regulations such as FCC, ETSI and
   ARIB impose duty cycle regulations to limit the use of the bands but
   yet interference may constraint the probability to deliver a packet.
   Part of these reliability challenges are addressed at the MAC
   introducing redundancy and diversity, thanks to channel hopping,
   scheduling and ARQ policies.  Yet, the MAC layer operates with a
   1-hop vision, being limited to local actions to mitigate
   underperforming links.

5.2.1.1.  6TiSCH Tracks

   A Track in the 6TiSCH Architecture [RFC9030] is the application to
   wireless of the concept of a protection path in the "Detnet
   architecture" [RFC8655].  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 taking routing decisions at the
   Layer-3.

   Serial Tracks can be understood as the concatenation of cells or
   bundles along a routing path from a source towards a destination.
   The serial Track concept is analogous to the circuit concept where
   resources are chained into a multi-hop topology, more in
   Section 5.2.1.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 PAREO
   functions along a more complex DODAG Track structure.  A DODAG has
   forking and joining nodes where the concepts such as Replication and
   Elimination can be exploited.  Spatial redundancy increases the
   overall energy consumption in the network but improves significantly
   the availability of the network as well as the packet delivery ratio.
   A Track may also branch off and rejoin, for the purpose of the so-
   called Packet Replication and Elimination (PRE), over non congruent
   branches.  PRE may be used to complement layer-2 Automatic Repeat
   reQuest (ARQ) and receiver-end Ordering to form the PAREO functions.
   PAREO functions enable to meet industrial expectations of packet
   delivery within bounded delay over a Track that includes wireless
   links, even when the Track extends beyond the 6TiSCH network.

Thubert, et al.           Expires 7 March 2025                 [Page 19]
Internet-Draft              RAW Technologies              September 2024

   The RAW Track described in the RAW Architecture
   [I-D.ietf-raw-architecture] inherits directly from that model.  RAW
   extends the graph beyond a DODAG as long as a given packet cannot
   loop within the Track.

                     +-----+
                     | 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 the example above (see Figure 1), a Track is laid out from a field
   device in a 6TiSCH network to an IoT gateway that is located on a
   IEEE802.1 TSN backbone.

   The Replication function in the field device sends a copy of each
   packet over two different branches, and a PCE schedules each hop of
   both branches so that the two copies arrive in due time at the
   gateway.  In case of a loss on one branch, hopefully the other copy
   of the packet still makes it in due time.  If two copies make it to
   the IoT gateway, the Elimination function in the gateway ignores the
   extra packet and presents only one copy to upper layers.

   At each 6TiSCH hop along the Track, the PCE may schedule more than
   one timeSlot for a packet, so as to support Layer-2 retries (ARQ).
   It is also possible that the field device only uses the second branch
   if sending over the first branch fails.

Thubert, et al.           Expires 7 March 2025                 [Page 20]
Internet-Draft              RAW Technologies              September 2024

   In current deployments, a TSCH Track does not necessarily support PRE
   but is systematically multi-path.  This means that a Track is
   scheduled so as to ensure that each hop has at least two forwarding
   solutions, and the forwarding decision is to try the preferred one
   and use the other in case of Layer-2 transmission failure as detected
   by ARQ.

   Methods to implement complex Tracks are described in
   [I-D.ietf-roll-dao-projection] and complemented by extensions to the
   RPL routing protocol in [I-D.ietf-roll-nsa-extension] for best effort
   traffic, but a centralized routing technique such as promoted in
   DetNet is still missing.

5.2.1.1.1.  Track Scheduling Protocol

   Section "Schedule Management Mechanisms" of the 6TiSCH architecture
   describes 4 paradigms to manage the TSCH schedule of the LLN nodes:
   Static Scheduling, neighbor-to-neighbor Scheduling, remote monitoring
   and scheduling management, and Hop-by-hop scheduling.  The Track
   operation for DetNet corresponds to a remote monitoring and
   scheduling management by a PCE.

5.2.1.1.2.  Track Forwarding

   By forwarding, The 6TiSCH Architecture [RFC9030] means the per-packet
   operation that allows to deliver a packet to a next hop or an upper
   layer in this node.  Forwarding is based on pre-existing state that
   was installed as a result of the routing computation of a Track by a
   PCE.  The 6TiSCH architecture supports three different forwarding
   model, G-MPLS Track Forwarding (TF), 6LoWPAN Fragment Forwarding (FF)
   and IPv6 Forwarding (6F) which is the classical IP operation
   [RFC9030].  The DetNet case relates to the Track Forwarding operation
   under the control of a PCE.

   A Track is a unidirectional path between a source and a destination.
   Time/Frequency resources called cells (see Section 5.2.2.1.4) are
   allocated to enable the forwarding operation along the Track.  In a
   Track cell, the normal operation of IEEE802.15.4 Automatic Repeat-
   reQuest (ARQ) usually happens, though the acknowledgment may be
   omitted in some cases, for instance if there is no scheduled cell for
   a retry.

   Track Forwarding is the simplest and fastest.  A bundle of cells set
   to receive (RX-cells) is uniquely paired to a bundle of cells that
   are set to transmit (TX-cells), representing a layer-2 forwarding
   state that can be used regardless of the network layer protocol.
   This model can effectively be seen as a Generalized Multi-protocol
   Label Switching (G-MPLS) operation in that the information used to

Thubert, et al.           Expires 7 March 2025                 [Page 21]
Internet-Draft              RAW Technologies              September 2024

   switch a frame is not an explicit label, but rather related to other
   properties of the way the packet was received, a particular cell in
   the case of 6TiSCH.  As a result, as long as the TSCH MAC (and
   Layer-2 security) accepts a frame, that frame can be switched
   regardless of the protocol, whether this is an IPv6 packet, a 6LoWPAN
   fragment, or a frame from an alternate protocol such as WirelessHART
   or ISA100.11a.

   A data frame that is forwarded along a Track normally has a
   destination MAC address that is set to broadcast - or a multicast
   address depending on MAC support.  This way, the MAC layer in the
   intermediate nodes accepts the incoming frame and 6top switches it
   without incurring a change in the MAC header.  In the case of
   IEEE802.15.4, this means effectively broadcast, so that along the
   Track the short address for the destination of the frame is set to
   0xFFFF.

   A Track is thus formed end-to-end as a succession of paired bundles,
   a receive bundle from the previous hop and a transmit bundle to the
   next hop along the Track, and a cell in such a bundle belongs to at
   most one Track.  For a given iteration of the device schedule, the
   effective channel of the cell is obtained by adding a pseudo-random
   number to the channelOffset of the cell, which results in a rotation
   of the frequency that used for transmission.  The bundles may be
   computed so as to accommodate both variable rates and
   retransmissions, so they might not be fully used at a given iteration
   of the schedule.  The 6TiSCH architecture provides additional means
   to avoid waste of cells as well as overflows in the transmit bundle,
   as follows:

   In one hand, a TX-cell that is not needed for the current iteration
   may be reused opportunistically on a per-hop basis for routed
   packets.  When all of the frame that were received for a given Track
   are effectively transmitted, any available TX-cell for that Track can
   be reused for upper layer traffic for which the next-hop router
   matches the next hop along the Track.  In that case, the cell that is
   being used is effectively a TX-cell from the Track, but the short
   address for the destination is that of the next-hop router.  It
   results that a frame that is received in a RX-cell of a Track with a
   destination MAC address set to this node as opposed to broadcast must
   be extracted from the Track and delivered to the upper layer (a frame
   with an unrecognized MAC address is dropped at the lower MAC layer
   and thus is not received at the 6top sublayer).

   On the other hand, it might happen that there are not enough TX-cells
   in the transmit bundle to accommodate the Track traffic, for instance
   if more retransmissions are needed than provisioned.  In that case,
   the frame can be placed for transmission in the bundle that is used

Thubert, et al.           Expires 7 March 2025                 [Page 22]
Internet-Draft              RAW Technologies              September 2024

   for layer-3 traffic towards the next hop along the Track as long as
   it can be routed by the upper layer, that is, typically, if the frame
   transports an IPv6 packet.  The MAC address should be set to the
   next-hop MAC address to avoid confusion.  It results that a frame
   that is received over a layer-3 bundle may be in fact associated to a
   Track.  In a classical IP link such as an Ethernet, off-Track traffic
   is typically in excess over reservation to be routed along the non-
   reserved path based on its QoS setting.  But with 6TiSCH, since the
   use of the layer-3 bundle may be due to transmission failures, it
   makes sense for the receiver to recognize a frame that should be re-
   Tracked, and to place it back on the appropriate bundle if possible.
   A frame should be re-Tracked if the Per-Hop-Behavior group indicated
   in the Differentiated Services Field in the IPv6 header is set to
   Deterministic Forwarding, as discussed in Section 5.2.2.1.1.  A frame
   is re-Tracked by scheduling it for transmission over the transmit
   bundle associated to the Track, with the destination MAC address set
   to broadcast.

5.2.1.1.2.1.  OAM

   An Overview of Operations, Administration, and Maintenance (OAM)
   Tools [RFC7276] provides an overwiew of the existing tooling for OAM
   [RFC6291].  Tracks are complex paths and new tooling is necessary to
   manage them, with respect to load control, timing, and the Packet
   Replication and Elimination Functions (PREF).

   An example of such tooling can be found in the context of BIER
   [RFC8279] and more specifically BIER Traffic Engineering [RFC9262]
   (BIER-TE): [I-D.thubert-bier-replication-elimination] leverages BIER-
   TE to control the process of PREF, and to provide traceability of
   these operations, in the deterministic dataplane, along a complex
   Track.

5.2.2.  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 defined by the RFC5673 [RFC5673].  As a low power
   technology targeting industrial scenarios radio transducers provide
   low data rates (typically between 50kbps to 250kbps) and robust
   modulations to trade-off performance to reliability.  TSCH networks
   are organized in mesh topologies and connected to a backbone.
   Latency in the mesh network is mainly influenced by propagation
   aspects such as interference.  ARQ methods and redundancy techniques
   such as replication and elimination should be studied to provide the
   needed performance to address deterministic scenarios.

Thubert, et al.           Expires 7 March 2025                 [Page 23]
Internet-Draft              RAW Technologies              September 2024

   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 overprovisionned cells.  Along a
   Track Section 5.2.1.1, resource blocks can be chained so nodes in
   previous hops transmit their data before the next packet comes.  This
   provides a tight control to latency along a Track.  Collision loss is
   avoided for best effort traffic by overprovisionning resources,
   giving time to the management plane of the network to dedicate more
   resources if needed.

5.2.2.1.  Centralized Path Computation

   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 an Human/Machine Interface (HMI) provides the
   Traffic Specification, in particular in terms of latency and
   reliability, and the end nodes, to a Path Computation element (PCE).
   With this, the PCE computes a Track between the end nodes and
   provisions every hop in the Track with per-flow state that describes
   the per-hop operation for a given packet, the corresponding
   timeSlots, and the flow identification to recognize which packet is
   placed in which Track, sort out duplicates, etc.  In Figure 2, an
   example of Operational Control System and HMI is depicted.

   For a static configuration that serves a certain purpose for a long
   period of time, it is expected that a node will be provisioned in one
   shot with a full schedule, which incorporates the aggregation of its
   behavior for multiple Tracks.  The 6TiSCH Architecture expects that
   the programing of the schedule is done over the Constrained
   Application Protocol (CoAP) as discussed in "6TiSCH Resource
   Management and Interaction using CoAP" [I-D.ietf-6tisch-coap].

   But an Hybrid mode may be required as well whereby a single Track is
   added, modified, or removed, for instance if it appears that a Track
   does not perform as expected.  For that case, the expectation is that
   a protocol that flows along a Track (to be), in a fashion similar to
   classical Traffic Engineering (TE) [CCAMP], may be used to update the
   state in the devices.  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.

   Stream Management Entity

Thubert, et al.           Expires 7 March 2025                 [Page 24]
Internet-Draft              RAW Technologies              September 2024

                         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.2.2.1.1.  Packet Marking and Handling

   Section "Packet Marking and Handling" of [RFC9030] describes the
   packet tagging and marking that is expected in 6TiSCH networks.

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

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

5.2.2.1.1.2.  Replication, Retries and Elimination

   The 6TiSCH Architecture [RFC9030] leverages the Packet Replication,
   Retries, Elimination (PRE) and Ordering functions (PREOF), the
   precursor the PAREO functions in the RAW Architecture.  PREF
   establishes several paths in a network to provide redundancy and
   parallel transmissions to bound the end-to-end delay.  Considering
   the scenario shown in Figure 3, many different paths are possible for
   S to reach R.  A simple way to benefit from this topology could be to
   use the two independent paths via nodes A, C, E and via B, D, F.  But
   more complex paths are possible as well.

Thubert, et al.           Expires 7 March 2025                 [Page 25]
Internet-Draft              RAW Technologies              September 2024

                            (A)   (C)   (E)

              source (S)                       (R) (destination)

                            (B)   (D)   (F)

      Figure 3: A Typical Ladder Shape with Two Parallel Paths Toward
                              the Destination

   By employing a Packet Replication function, each node forwards a copy
   of each data packet over two different branches.  For instance, in
   Figure 4, the source node S transmits the data packet to nodes A and
   B, in two different timeslots within the same TSCH slotframe.

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

       Figure 4: Packet Replication: S transmits twice the same data
      packet, to its Destination Parent (DP) (A) and to its Alternate
                              Parent (AP) (B).

   By employing Packet Elimination function once a node receives the
   first copy of a data packet, it discards the subsequent copies.
   Because the first copy that reaches a node is the one that matters,
   it is the only copy that will be forwarded upward.

   Considering that the wireless medium is broadcast by nature, any
   neighbor of a transmitter may overhear a transmission.  By employing
   the Promiscuous Overhearing function, nodes will have multiple
   opportunities to receive a given data packet.  For instance, in
   Figure 4, when the source node S transmits the data packet to node A,
   node B may overhear this transmission.

   6TiSCH expects elimination and replication of packets along a complex
   Track, but has no position about how the sequence numbers would be
   tagged in the packet.

   As it goes, 6TiSCH expects that timeSlots corresponding to copies of
   a same packet along a Track are correlated by configuration, and does
   not need to process the sequence numbers.

Thubert, et al.           Expires 7 March 2025                 [Page 26]
Internet-Draft              RAW Technologies              September 2024

   The semantics of the configuration must enable correlated timeSlots
   to be grouped for transmit (and respectively receive) with 'OR'
   relations, and then an 'AND' relation must be configurable between
   groups.  The semantics is that if the transmit (and respectively
   receive) 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.2.2.1.2.  Topology and capabilities

   6TiSCH nodes are usually IoT devices, characterized by very limited
   amount of memory, just enough buffers to store one or a few IPv6
   packets, and limited bandwidth between peers.  It results that a node
   will maintain only a small number of peering information, and will
   not be able to store many packets waiting to be forwarded.  Peers can
   be identified through MAC or IPv6 addresses.

   Neighbors can be discovered over the radio using mechanism such as
   Enhanced Beacons, but, though the neighbor information is available
   in the 6TiSCH interface data model, 6TiSCH does not describe a
   protocol to pro-actively push the neighborhood information to a PCE.
   This protocol should be described and should operate over CoAP.  The
   protocol should be able to carry multiple metrics, in particular the
   same metrics as used for RPL operations [RFC6551].

   The energy that the device consumes in sleep, transmit and receive
   modes can be evaluated and reported.  So can the amount of energy
   that is stored in the device and the power that it can be scavenged
   from the environment.  The PCE should be able to compute Tracks that
   will implement policies on how the energy is consumed, for instance
   balance between nodes, ensure that the spent energy does not exceeded
   the scavenged energy over a period of time, etc...

5.2.2.1.3.  Schedule Management by a PCE

   6TiSCH supports a mixed model of centralized routes and distributed
   routes.  Centralized routes can for example be computed by a entity
   such as a PCE [PCE].  Distributed routes are computed by RPL
   [RFC6550].

   Both methods may inject routes in the Routing Tables of the 6TiSCH
   routers.  In either case, each route is associated with a 6TiSCH
   topology that can be a RPL Instance topology or a Track.  The 6TiSCH
   topology is indexed by a Instance ID, in a format that reuses the
   RPLInstanceID as defined in RPL.

Thubert, et al.           Expires 7 March 2025                 [Page 27]
Internet-Draft              RAW Technologies              September 2024

   Both RPL and PCE rely on shared sources such as policies to define
   Global and Local RPLInstanceIDs that can be used by either method.
   It is possible for centralized and distributed routing to share a
   same topology.  Generally they will operate in different slotFrames,
   and centralized routes will be used for scheduled traffic and will
   have precedence over distributed routes in case of conflict between
   the slotFrames.

5.2.2.1.4.  SlotFrames and Priorities

   IEEE802.15.4 TSCH avoids contention on the medium by formatting time
   and frequencies in cells of transmission of equal duration.  In order
   to describe that formatting of time and frequencies, the 6TiSCH
   architecture defines a global concept that is called a Channel
   Distribution and Usage (CDU) matrix; a CDU matrix is a matrix of
   cells with an height equal to the number of available channels
   (indexed by ChannelOffsets) and a width (in timeSlots) that is the
   period of the network scheduling operation (indexed by slotOffsets)
   for that CDU matrix.

   The 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 pseudo-random
   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 architecture.  The matrix represents the
   overall utilisation 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.

Thubert, et al.           Expires 7 March 2025                 [Page 28]
Internet-Draft              RAW Technologies              September 2024

   A slotFrame is the base object that a PCE needs to manipulate to
   program a schedule into one device.  The slotFrame is a device
   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 "SlotFrames and Priorities" of
   [RFC9030], and figures 17 and 18 of [RFC9030] illustrate that
   projection.

5.3.  Summary

   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 adopted and widely deployed in the last
   10 years by the major competing standards, Wireless 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 (1 to 10ms) used in
   Factory Automation and motion control.

6.  5G

6.1.  Provenance and Documents

   The 3rd Generation Partnership Project (3GPP) incorporates many
   companies whose business is related to cellular network operation as
   well as network equipment and device manufacturing.  All generations
   of 3GPP technologies provide scheduled wireless segments, primarily
   in licensed spectrum which is beneficial for reliability and
   availability.

Thubert, et al.           Expires 7 March 2025                 [Page 29]
Internet-Draft              RAW Technologies              September 2024

   In 2016, the 3GPP started to design New Radio (NR) technology
   belonging to the fifth generation (5G) of cellular networks.  NR has
   been designed from the beginning to not only address enhanced Mobile
   Broadband (eMBB) services for consumer devices such as smart phones
   or tablets but is also tailored for future Internet of Things (IoT)
   communication and connected cyber-physical systems.  In addition to
   eMBB, requirement categories have been defined on Massive Machine-
   Type Communication (M-MTC) for a large number of connected devices/
   sensors, and Ultra-Reliable Low-Latency Communication (URLLC) for
   connected control systems and critical communication as illustrated
   in Figure 5.  It is the URLLC capabilities that make 5G a great
   candidate for reliable low-latency communication.  With these three
   corner stones, NR is a complete solution supporting the connectivity
   needs of consumers, enterprises, and public sector for both wide area
   and local area, e.g. indoor deployments.  A general overview of NR
   can be found in [TS38300].

                                enhanced
                            Mobile Broadband
                                   ^
                                  / \
                                 /   \
                                /     \
                               /       \
                              /   5G    \
                             /           \
                            /             \
                           /               \
                          +-----------------+
                       Massive          Ultra-Reliable
                     Machine-Type        Low-Latency
                    Communication       Communication

                       Figure 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 1ms latency budget [TR37910].  Those evaluations were
   consolidated and forwarded to ITU to be included in the [IMT2020]
   work.

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

Thubert, et al.           Expires 7 March 2025                 [Page 30]
Internet-Draft              RAW Technologies              September 2024

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

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

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

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

   In addition, several enhancements have been done on system
   architecture level which are reflected in System architecture for the
   5G System (5GS) [TS23501].  These enhancements include multiple
   features in support of Time-Sensitive Communications (TSC) by Release
   16 and Release 17.  Further improvements are provided in Release 18,
   e.g., support for DetNet [TR2370046].

   The adoption and the use of 5G is facilitated by multiple
   organizations.  For instance, the 5G Alliance for Connected
   Industries and Automation (5G-ACIA) brings together widely varying 5G
   stakeholders including Information and Communication Technology (ICT)
   players and Operational Technology (OT) companies, e.g.: industrial
   automation enterprises, machine builders, and end users.  Another
   example is the 5G Automotive Association (5GAA), which bridges ICT
   and automotive technology companies to develop end-to-end solutions
   for future mobility and transportation services.

6.2.  General Characteristics

   The 5G Radio Access Network (5G RAN) with its NR interface includes
   several features to achieve Quality of Service (QoS), such as a
   guaranteeably low latency or tolerable packet error rates for
   selected data flows.  Determinism is achieved by centralized
   admission control and scheduling of the wireless frequency resources,
   which are typically licensed frequency bands assigned to a network
   operator.

Thubert, et al.           Expires 7 March 2025                 [Page 31]
Internet-Draft              RAW Technologies              September 2024

   NR enables short transmission slots in a radio subframe, which
   benefits low-latency applications.  NR also introduces mini-slots,
   where prioritized transmissions can be started without waiting for
   slot boundaries, further reducing latency.  As part of giving
   priority and faster radio access to URLLC traffic, NR introduces
   preemption where URLLC data transmission can preempt ongoing non-
   URLLC transmissions.  Additionally, NR applies very fast processing,
   enabling retransmissions even within short latency bounds.

   NR defines extra-robust transmission modes for increased reliability
   both for data and control radio channels.  Reliability is further
   improved by various techniques, such as multi-antenna transmission,
   the use of multiple frequency carriers in parallel and packet
   duplication over independent radio links.  NR also provides full
   mobility support, which is an important reliability aspect not only
   for devices that are moving, but also for devices located in a
   changing environment.

   Network slicing is seen as one of the key features for 5G, allowing
   vertical industries to take advantage of 5G networks and services.
   Network slicing is about transforming a Public Land Mobile Network
   (PLMN) from a single network to a network where logical partitions
   are created, with appropriate network isolation, resources, optimized
   topology and specific configuration to serve various service
   requirements.  An operator can configure and manage the mobile
   network to support various types of services enabled by 5G, for
   example eMBB and URLLC, depending on the different customers’ needs.

   Exposure of capabilities of 5G Systems to the network or applications
   outside the 3GPP domain have been added to Release 16 [TS23501].  Via
   exposure interfaces, applications can access 5G capabilities, e.g.,
   communication service monitoring and network maintenance.

   For several generations of mobile networks, 3GPP has considered how
   the communication system should work on a global scale with billions
   of users, taking into account resilience aspects, privacy regulation,
   protection of data, encryption, access and core network security, as
   well as interconnect.  Security requirements evolve as demands on
   trustworthiness increase.  For example, this has led to the
   introduction of enhanced privacy protection features in 5G. 5G also
   employs strong security algorithms, encryption of traffic, protection
   of signaling and protection of interfaces.

   One particular strength of mobile networks is the authentication,
   based on well-proven algorithms and tightly coupled with a global
   identity management infrastructure.  Since 3G, there is also mutual
   authentication, allowing the network to authenticate the device and
   the device to authenticate the network.  Another strength is secure

Thubert, et al.           Expires 7 March 2025                 [Page 32]
Internet-Draft              RAW Technologies              September 2024

   solutions for storage and distribution of keys fulfilling regulatory
   requirements and allowing international roaming.  When connecting to
   5G, the user meets the entire communication system, where security is
   the result of standardization, product security, deployment,
   operations and management as well as incident handling capabilities.
   The mobile networks approach the entirety in a rather coordinated
   fashion which is beneficial for security.

6.3.  Deployment and Spectrum

   The 5G system allows deployment in a vast spectrum range, addressing
   use-cases in both wide-area as well as local networks.  Furthermore,
   5G can be configured for public and non-public access.

   When it comes to spectrum, NR allows combining the merits of many
   frequency bands, such as the high bandwidths in millimeter Waves
   (mmW) for extreme capacity locally, as well as the broad coverage
   when using mid- and low frequency bands to address wide-area
   scenarios.  URLLC is achievable in all these bands.  Spectrum can be
   either licensed, which means that the license holder is the only
   authorized user of that spectrum range, or unlicensed, which means
   that anyone who wants to use the spectrum can do so.

   A prerequisite for critical communication is performance
   predictability, which can be achieved by the full control of the
   access to the spectrum, which 5G provides.  Licensed spectrum
   guarantees control over spectrum usage by the system, making it a
   preferable option for critical communication.  However, unlicensed
   spectrum can provide an additional resource for scaling non-critical
   communications.  While NR is initially developed for usage of
   licensed spectrum, the functionality to access also unlicensed
   spectrum was introduced in 3GPP Release 16.  Moreover, URLLC features
   are enhanced in Release 17 [RP210854] to be better applicable to
   unlicensed spectrum.

   Licensed spectrum dedicated to mobile communications has been
   allocated to mobile service providers, i.e. issued as longer-term
   licenses by national administrations around the world.  These
   licenses have often been associated with coverage requirements and
   issued across whole countries, or in large regions.  Besides this,
   configured as a non-public network (NPN) deployment, 5G can provide
   network services also to a non-operator defined organization and its
   premises such as a factory deployment.  By this isolation, quality of
   service requirements, as well as security requirements can be
   achieved.  An integration with a public network, if required, is also
   possible.  The non-public (local) network can thus be interconnected
   with a public network, allowing devices to roam between the networks.

Thubert, et al.           Expires 7 March 2025                 [Page 33]
Internet-Draft              RAW Technologies              September 2024

   In an alternative model, some countries are now in the process of
   allocating parts of the 5G spectrum for local use to industries.
   These non-service providers then have a choice of applying for a
   local license themselves and operating their own network or
   cooperating with a public network operator or service provider.

6.4.  Applicability to Deterministic Flows

6.4.1.  System Architecture

   The 5G system [TS23501] consists of the User Equipment (UE) at the
   terminal side, and the Radio Access Network (RAN) with the gNB as
   radio base station node, as well as the Core Network (CN), which is
   connected to the external Data Network (DN).  The core network is
   based on a service-based architecture with the central functions:
   Access and Mobility Management Function (AMF), Session Management
   Function (SMF) and User Plane Function (UPF) as illustrated in
   Figure 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 definition of acronyms
   used in the figure.)"

   The gNB’s main responsibility is the radio resource management,
   including admission control and scheduling, mobility control and
   radio measurement handling.  The AMF handles the UE’s connection
   status and security, while the SMF controls the UE’s data sessions.
   The UPF handles the user plane traffic.

   The SMF can instantiate various Packet Data Unit (PDU) sessions for
   the UE, each associated with a set of QoS flows, i.e., with different
   QoS profiles.  Segregation of those sessions is also possible, e.g.,
   resource isolation in the RAN and in the CN can be defined (slicing).

Thubert, et al.           Expires 7 March 2025                 [Page 34]
Internet-Draft              RAW Technologies              September 2024

             +----+  +---+   +---+    +---+    +---+   +---+
             |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

Thubert, et al.           Expires 7 March 2025                 [Page 35]
Internet-Draft              RAW Technologies              September 2024

   To allow UE mobility across cells/gNBs, handover mechanisms are
   supported in NR.  For an established connection, i.e., connected mode
   mobility, a gNB can configure a UE to report measurements of received
   signal strength and quality of its own and neighbouring cells,
   periodically or event-based.  Based on these measurement reports, the
   gNB decides to handover a UE to another target cell/gNB.  Before
   triggering the handover, it is hand-shaked with the target gNB based
   on network signalling.  A handover command is then sent to the UE and
   the UE switches its connection to the target cell/gNB.  The Packet
   Data Convergence Protocol (PDCP) of the UE can be configured to avoid
   data loss in this procedure, i.e., handle retransmissions if needed.
   Data forwarding is possible between source and target gNB as well.
   To improve the mobility performance further, i.e., to avoid
   connection failures, e.g., due to too-late handovers, the mechanism
   of conditional handover is introduced in Release 16 specifications.
   Therein a conditional handover command, defining a triggering point,
   can be sent to the UE before UE enters a handover situation.  A
   further improvement that has been introduced in Release 16 is the
   Dual Active Protocol Stack (DAPS), where the UE maintains the
   connection to the source cell while connecting to the target cell.
   This way, potential interruptions in packet delivery can be avoided
   entirely.

6.4.2.  Overview of The Radio Protocol Stack

   The protocol architecture for NR consists of the L1 Physical layer
   (PHY) and as part of the L2, the sublayers of Medium Access Control
   (MAC), Radio Link Control (RLC), Packet Data Convergence Protocol
   (PDCP), as well as the Service Data Adaption Protocol (SDAP).

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

   The MAC sub-layer handles multiplexing and priority handling of
   logical channels (associated with QoS flows) to transport blocks for
   PHY transmission, as well as scheduling information reporting and
   error correction through Hybrid Automated Repeat Request (HARQ).

   The RLC sublayer handles sequence numbering of higher layer packets,
   retransmissions through Automated Repeat Request (ARQ), if
   configured, as well as segmentation and reassembly and duplicate
   detection.

   The PDCP sublayer consists of functionalities for ciphering/
   deciphering, integrity protection/verification, re-ordering and in-
   order delivery, duplication and duplicate handling for higher layer
   packets, and acts as the anchor protocol to support handovers.

Thubert, et al.           Expires 7 March 2025                 [Page 36]
Internet-Draft              RAW Technologies              September 2024

   The SDAP sublayer provides services to map QoS flows, as established
   by the 5G core network, to data radio bearers (associated with
   logical channels), as used in the 5G RAN.

   Additionally, in RAN, the Radio Resource Control (RRC) protocol,
   handles the access control and configuration signalling for the
   aforementioned protocol layers.  RRC messages are considered L3 and
   thus transmitted also via those radio protocol layers.

   To provide low latency and high reliability for one transmission
   link, i.e., to transport data (or control signaling) of one radio
   bearer via one carrier, several features have been introduced on the
   user plane protocols for PHY and L2, as explained in the following.

6.4.3.  Radio (PHY)

   NR is designed with native support of antenna arrays utilizing
   benefits from beamforming, transmissions over multiple MIMO layers
   and advanced receiver algorithms allowing effective interference
   cancellation.  Those antenna techniques are the basis for high signal
   quality and effectiveness of spectral usage.  Spatial diversity with
   up to 4 MIMO layers in UL and up to 8 MIMO layers in DL is supported.
   Together with spatial-domain multiplexing, antenna arrays can focus
   power in desired direction to form beams.  NR supports beam
   management mechanisms to find the best suitable beam for UE initially
   and when it is moving.  In addition, gNBs can coordinate their
   respective DL and UL transmissions over the backhaul network keeping
   interference reasonably low, and even make transmissions or
   receptions from multiple points (multi-TRP).  Multi-TRP can be used
   for repetition of data packet in time, in frequency or over multiple
   MIMO layers which can improve reliability even further.

   Any downlink transmission to a UE starts from resource allocation
   signaling over the Physical Downlink Control Channel (PDCCH).  If it
   is successfully received, the UE will know about the scheduled
   transmission and may receive data over the Physical Downlink Shared
   Channel (PDSCH).  If retransmission is required according to the HARQ
   scheme, a signaling of negative acknowledgement (NACK) on the
   Physical Uplink Control Channel (PUCCH) is involved and PDCCH
   together with PDSCH transmissions (possibly with additional
   redundancy bits) are transmitted and soft-combined with previously
   received bits.  Otherwise, if no valid control signaling for
   scheduling data is received, nothing is transmitted on PUCCH
   (discontinuous transmission - DTX),and the base station upon
   detecting DTX will retransmit the initial data.

Thubert, et al.           Expires 7 March 2025                 [Page 37]
Internet-Draft              RAW Technologies              September 2024

   An uplink transmission normally starts from a Scheduling Request (SR)
   – a signaling message from the UE to the base station sent via PUCCH.
   Once the scheduler is informed about buffer data in UE, e.g., by SR,
   the UE transmits a data packet on the Physical Uplink Shared Channel
   (PUSCH).  Pre-scheduling not relying on SR is also possible (see
   following section).

   Since transmission of data packets require usage of control and data
   channels, there are several methods to maintain the needed
   reliability.  NR uses Low Density Parity Check (LDPC) codes for data
   channels, Polar codes for PDCCH, as well as orthogonal sequences and
   Polar codes for PUCCH.  For ultra-reliability of data channels, very
   robust (low spectral efficiency) Modulation and Coding Scheme (MCS)
   tables are introduced containing very low (down to 1/20) LDPC code
   rates using BPSK or QPSK.  Also, PDCCH and PUCCH channels support
   multiple code rates including very low ones for the channel
   robustness.

   A connected UE reports downlink (DL) quality to gNB by sending
   Channel State Information (CSI) reports via PUCCH while uplink (UL)
   quality is measured directly at gNB.  For both uplink and downlink,
   gNB selects the desired MCS number and signals it to the UE by
   Downlink Control Information (DCI) via PDCCH channel.  For URLLC
   services, the UE can assist the gNB by advising that MCS targeting
   10^-5 Block Error Rate (BLER) are used.  Robust link adaptation
   algorithms can maintain the needed level of reliability considering a
   given latency bound.

   Low latency on the physical layer is provided by short transmission
   duration which is possible by using high Subcarrier Spacing (SCS) and
   the allocation of only one or a few Orthogonal Frequency Division
   Multiplexing (OFDM) symbols.  For example, the shortest latency for
   the worst case in DL can be 0.23ms and in UL can be 0.24ms according
   to (section 5.7.1 in [TR37910]).  Moreover, if the initial
   transmission has failed, HARQ feedback can quickly be provided and an
   HARQ retransmission is scheduled.

Thubert, et al.           Expires 7 March 2025                 [Page 38]
Internet-Draft              RAW Technologies              September 2024

   Dynamic multiplexing of data associated with different services is
   highly desirable for efficient use of system resources and to
   maximize system capacity.  Assignment of resources for eMBB is
   usually done with regular (longer) transmission slots, which can lead
   to blocking of low latency services.  To overcome the blocking, eMBB
   resources can be pre-empted and re-assigned to URLLC services.  In
   this way, spectrally efficient assignments for eMBB can be ensured
   while providing flexibility required to ensure a bounded latency for
   URLLC services.  In downlink, the gNB can notify the eMBB UE about
   pre-emption after it has happened, while in uplink there are two pre-
   emption mechanisms: special signaling to cancel eMBB transmission and
   URLLC dynamic power boost to suppress eMBB transmission.

6.4.4.  Scheduling and QoS (MAC)

   One integral part of the 5G system is the Quality of Service (QoS)
   framework [TS23501].  QoS flows are setup by the 5G system for
   certain IP or Ethernet packet flows, so that packets of each flow
   receive the same forwarding treatment, i.e., in scheduling and
   admission control.  QoS flows can for example be associated with
   different priority level, packet delay budgets and tolerable packet
   error rates.  Since radio resources are centrally scheduled in NR,
   the admission control function can ensure that only those QoS flows
   are admitted for which QoS targets can be reached.

   NR transmissions in both UL and DL are scheduled by the gNB
   [TS38300].  This ensures radio resource efficiency, fairness in
   resource usage of the users and enables differentiated treatment of
   the data flows of the users according to the QoS targets of the
   flows.  Those QoS flows are handled as data radio bearers or logical
   channels in NR RAN scheduling.

   The gNB can dynamically assign DL and UL radio resources to users,
   indicating the resources as DL assignments or UL grants via control
   channel to the UE.  Radio resources are defined as blocks of OFDM
   symbols in spectral domain and time domain.  Different lengths are
   supported in time domain, i.e., (multiple) slot or mini-slot lengths.
   Resources of multiple frequency carriers can be aggregated and
   jointly scheduled to the UE.

   Scheduling decisions are based, e.g., on channel quality measured on
   reference signals and reported by the UE (cf. periodical CSI reports
   for DL channel quality).  The transmission reliability can be chosen
   in the scheduling algorithm, i.e., by link adaptation where an
   appropriate transmission format (e.g., robustness of modulation and
   coding scheme, controlled UL power) is selected for the radio channel
   condition of the UE.  Retransmissions, based on HARQ feedback, are
   also controlled by the scheduler.  The feedback transmission in HARQ

Thubert, et al.           Expires 7 March 2025                 [Page 39]
Internet-Draft              RAW Technologies              September 2024

   loop introduces delays, but there are methods to minimize it by using
   short transmission formats, sub-slot feedback reporting and PUCCH
   carrier switching.  If needed to avoid HARQ round-trip time delays,
   repeated transmissions can be also scheduled beforehand, to the cost
   of reduced spectral efficiency.

   In dynamic DL scheduling, transmission can be initiated immediately
   when DL data becomes available in the gNB.  However, for dynamic UL
   scheduling, when data becomes available but no UL resources are
   available yet, the UE indicates the need for UL resources to the gNB
   via a (single bit) scheduling request message in the UL control
   channel.  When thereupon UL resources are scheduled to the UE, the UE
   can transmit its data and may include a buffer status report,
   indicating the exact amount of data per logical channel still left to
   be sent.  More UL resources may be scheduled accordingly.  To avoid
   the latency introduced in the scheduling request loop, UL radio
   resources can also be pre-scheduled.

   In particular for periodical traffic patterns, the pre-scheduling can
   rely on the scheduling features DL Semi-Persistent Scheduling (SPS)
   and UL Configured Grant (CG).  With these features, periodically
   recurring resources can be assigned in DL and UL.  Multiple parallels
   of those configurations are supported, in order to serve multiple
   parallel traffic flows of the same UE.

   To support QoS enforcement in the case of mixed traffic with
   different QoS requirements, several features have recently been
   introduced.  This way, e.g., different periodical critical QoS flows
   can be served together with best effort transmissions, by the same
   UE.  Among others, these features (partly Release 16) are: 1) UL
   logical channel transmission restrictions allowing to map logical
   channels of certain QoS only to intended UL resources of a certain
   frequency carrier, slot-length, or CG configuration, and 2) intra-UE
   pre-emption and multiplexing, allowing critical UL transmissions to
   either pre-empt non-critical transmissions or being multiplexed with
   non-critical transmissions keeping different reliability targets.

   When multiple frequency carriers are aggregated, duplicate parallel
   transmissions can be employed (beside repeated transmissions on one
   carrier).  This is possible in the Carrier Aggregation (CA)
   architecture where those carriers originate from the same gNB, or in
   the Dual Connectivity (DC) architecture where the carriers originate
   from different gNBs, i.e., the UE is connected to two gNBs in this
   case.  In both cases, transmission reliability is improved by this
   means of providing frequency diversity.

Thubert, et al.           Expires 7 March 2025                 [Page 40]
Internet-Draft              RAW Technologies              September 2024

   In addition to licensed spectrum, a 5G system can also utilize
   unlicensed spectrum to offload non-critical traffic.  This version of
   NR is called NR-U, part of 3GPP Release 16.  The central scheduling
   approach applies also for unlicensed radio resources, but in addition
   also the mandatory channel access mechanisms for unlicensed spectrum,
   e.g., Listen Before Talk (LBT) are supported in NR-U.  This way, by
   using NR, operators have and can control access to both licensed and
   unlicensed frequency resources.

6.4.5.  Time-Sensitive Communications (TSC)

   Recent 3GPP releases have introduced various features to support
   multiple aspects of Time-Sensitive Communication (TSC), which
   includes Time-Sensitive Networking (TSN) and beyond as described in
   this section.

   The main objective of Time-Sensitive Networking (TSN) is to provide
   guaranteed data delivery within a guaranteed time window, i.e.,
   bounded low latency.  IEEE 802.1 TSN [IEEE802.1TSN] is a set of open
   standards that provide features to enable deterministic communication
   on standard IEEE 802.3 Ethernet [IEEE802.3].  TSN standards can be
   seen as a toolbox for traffic shaping, resource management, time
   synchronization, and reliability.

   A TSN stream is a data flow between one end station (Talker) to
   another end station (Listener).  In the centralized configuration
   model, TSN bridges are configured by the Central Network Controller
   (CNC) [IEEE802.1Qcc] to provide deterministic connectivity for the
   TSN stream through the network.  Time-based traffic shaping provided
   by Scheduled Traffic [IEEE802.1Qbv] may be used to achieve bounded
   low latency.  The TSN tool for time synchronization is the
   generalized Precision Time Protocol (gPTP) [IEEE802.1AS]), which
   provides reliable time synchronization that can be used by end
   stations and by other TSN tools, e.g., Scheduled Traffic
   [IEEE802.1Qbv].  High availability, as a result of ultra-reliability,
   is provided for data flows by the Frame Replication and Elimination
   for Reliability (FRER) [IEEE802.1CB] mechanism.

   3GPP Release 16 includes integration of 5G with TSN, i.e., specifies
   functions for the 5G System (5GS) to deliver TSN streams such that
   the meet their QoS requirements.  A key aspect of the integration is
   the 5GS appears from the rest of the network as a set of TSN bridges,
   in particular, one virtual bridge per User Plane Function (UPF) on
   the user plane.  The 5GS includes TSN Translator (TT) functionality
   for the adaptation of the 5GS to the TSN bridged network and for
   hiding the 5GS internal procedures.  The 5GS provides the following
   components:

Thubert, et al.           Expires 7 March 2025                 [Page 41]
Internet-Draft              RAW Technologies              September 2024

   1.  interface to TSN controller, as per [IEEE802.1Qcc] for the fully
       centralized configuration model

   2.  time synchronization via reception and transmission of gPTP PDUs
       [IEEE802.1AS]

   3.  low latency, hence, can be integrated with Scheduled Traffic
       [IEEE802.1Qbv]

   4.  reliability, hence, can be integrated with FRER [IEEE802.1CB]

   3GPP Release 17 [TS23501] introduced enhancements to generalize
   support for Time-Sensitive Communications (TSC) beyond TSN.  This
   includes IP communications to provide time-sensitive service to,
   e.g., Video, Imaging and Audio for Professional Applications (VIAPA).
   The system model of 5G acting as a “TSN bridge” in Release 16 has
   been reused to enable the 5GS acting as a “TSC node” in a more
   generic sense (which includes TSN bridge and IP node).  In the case
   of TSC that does not involve TSN, requirements are given via exposure
   interface and the control plane provides the service based on QoS and
   time synchronization requests from an Application Function (AF).

   Figure 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 adapts 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.  TSN Translators (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., more
   flexible network topology because a wireless hop can replace several
   wireline hops thus significantly reduce the number of hops end-to-
   end.  [TSN5G] dives more into the integration of 5G with TSN.

Thubert, et al.           Expires 7 March 2025                 [Page 42]
Internet-Draft              RAW Technologies              September 2024

                    +------------------------------+
                    | 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 1us accuracy
   level.  Since NR is a scheduled system, an NR UE and a gNB are
   tightly synchronized to their OFDM symbol structures.  A 5G internal
   reference time can be provided to the UE via broadcast or unicast
   signaling, associating a known OFDM symbol to this reference clock.
   The 5G internal reference time can be shared within the 5G network,
   i.e., radio and core network components.  Release 16 has introduced
   interworking with gPTP for multiple time domains, where the 5GS acts
   as a virtual gPTP time-aware system and supports the forwarding of
   gPTP time synchronization information between end stations and
   bridges through the 5G user plane TTs.  These account for the
   residence time of the 5GS in the time synchronization procedure.  One
   special option is when the 5GS internal reference time is not only

Thubert, et al.           Expires 7 March 2025                 [Page 43]
Internet-Draft              RAW Technologies              September 2024

   used within the 5GS, but also to the rest of the devices in the
   deployment, including connected TSN bridges and end stations.
   Release 17 includes further improvements, i.e., methods for
   propagation delay compensation in RAN, further improving the accuracy
   for time synchronization over-the-air, as well as the possibility for
   the TSN grandmaster clock to reside on the UE side.  More extensions
   and flexibility were added to the time synchronization service making
   it general for TSC with additional support of other types of clocks
   and time distribution such as boundary clock, transparent clock peer-
   to-peer, transparent clock end-to-end, aside from the time-aware
   system used for TSN.  Additionally, it is possible to use internal
   access stratum signaling to distribute timing (and not the usual
   (g)PTP messages), for which the required accuracy can be provided by
   the AF [TS23501].  The same time synchronization service is expected
   to be further extended and enhanced in Release 18 to support Timing
   Resiliency (according to study item [SP211634]), where the 5G system
   can provide a back-up or alternative timing source for the failure of
   the local GNSS source (or other primary timing source) used by the
   vertical.

   IETF Deterministic Networking (DetNet) is the technology to support
   time-sensitive communications at the IP layer. 3GPP Release 18
   includes a study [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 11).  In particular, it is listed what parameters 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 DetNet over TSN work, 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 9.  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

Thubert, et al.           Expires 7 March 2025                 [Page 44]
Internet-Draft              RAW Technologies              September 2024

   (the device) and in Host B (the network).  RHF can implement
   replication and elimination functions as per [IEEE802.1CB] or the
   Packet Replication, Elimination, and Ordering Functions (PREOF) of
   IETF Deterministic Networking (DetNet) [RFC8655].

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

                    Figure 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 those PDU sessions of the
   different UEs are handled independently internal to the 5GS.  There
   is no single point of failure in this solution, which also includes
   RHF outside of the 5G system, e.g., as per FRER or as PREOF
   specifications.

             +.........+
             .  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 being outside of the 5G system make 5G equally supporting
   integration for reliability both with FRER of TSN and PREOF of DetNet
   as they both rely on the same concept.

Thubert, et al.           Expires 7 March 2025                 [Page 45]
Internet-Draft              RAW Technologies              September 2024

6.5.  Summary

   5G technology enables deterministic communication.  Based on the
   centralized admission control and the scheduling of the wireless
   resources, licensed or unlicensed, quality of service such as latency
   and reliability can be guaranteed. 5G contains several features to
   achieve ultra-reliable and low latency performance, e.g., support for
   different OFDM numerologies and slot-durations, as well as fast
   processing capabilities and redundancy techniques that lead to
   achievable latency numbers of below 1ms with 99.999% or higher
   confidence.

   5G also includes features to support Industrial IoT use cases, e.g.,
   via the integration of 5G with TSN.  This includes 5G capabilities
   for each TSN component, latency, resource management, time
   synchronization, and reliability.  Furthermore, 5G support for TSN
   can be leveraged when 5G is used as subnet technology for DetNet, in
   combination with or instead of TSN, which is the primary subnet for
   DetNet.  In addition, the support for integration with TSN
   reliability was added to 5G by making DetNet reliability also
   applicable, 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.

7.  L-band Digital Aeronautical Communications System

   One of the main pillars of the modern Air Traffic Management (ATM)
   system is the existence of a communication infrastructure that
   enables efficient aircraft guidance and safe separation in all phases
   of flight.  Although current systems are technically mature, they are
   suffering from the VHF band’s increasing saturation in high-density
   areas and the limitations posed by analogue radio.  Therefore,
   aviation globally and the European Union (EU) in particular, strives
   for a sustainable modernization of the aeronautical communication
   infrastructure.

   In the long-term, ATM communication shall transition from analogue
   VHF voice and VDL2 communication to more spectrum efficient digital
   data communication.  The European ATM Master Plan foresees this
   transition to be realized for terrestrial communications by the
   development and implementation of the L-band Digital Aeronautical
   Communications System (LDACS).  LDACS shall enable IPv6 based air-
   ground communication related to the safety and regularity of the
   flight.  The particular challenge is that no new frequencies can be

Thubert, et al.           Expires 7 March 2025                 [Page 46]
Internet-Draft              RAW Technologies              September 2024

   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, more in
   [RFC9372].

7.1.  Provenance and Documents

   The development of LDACS has already made substantial progress in the
   Single European Sky ATM Research (SESAR) framework, and is currently
   being continued in the follow-up program, SESAR2020 [RIH18].  A key
   objective of the SESAR activities is to develop, implement and
   validate a modern aeronautical data link able to evolve with aviation
   needs over long-term.  To this end, an LDACS specification has been
   produced [GRA19] and is continuously updated; transmitter
   demonstrators were developed to test the spectrum compatibility of
   LDACS with legacy systems operating in the L-band [SAJ14]; and the
   overall system performance was analyzed by computer simulations,
   indicating that LDACS can fulfill the identified requirements
   [GRA11].

   LDACS standardization within the framework of the International Civil
   Aviation Organization (ICAO) started in December 2016.  The ICAO
   standardization group has produced an initial Standards and
   Recommended Practices (SARPs) document [ICAO18].  The SARPs document
   defines the general characteristics of LDACS.  The ICAO
   standardization group plans to produce an ICAO technical manual - the
   ICAO equivalent to a technical standard - within the next years.
   Generally, the group is open to input from all sources and develops
   LDACS in the open.

   Up to now the LDACS standardization has been focused on the
   development of the physical layer and the data link layer, only
   recently have higher layers come into the focus of the LDACS
   development activities.  There is currently no "IPv6 over LDACS"
   specification; however, SESAR2020 has started the testing of
   IPv6-based LDACS testbeds.  The IPv6 architecture for the
   aeronautical telecommunication network is called the Future
   Communications Infrastructure (FCI).  FCI shall support quality of
   service, diversity, and mobility under the umbrella of the "multi-
   link concept".  This work is conducted by ICAO working group WG-I.

   In addition to standardization activities several industrial LDACS
   prototypes have been built.  One set of LDACS prototypes has been
   evaluated in flight trials confirming the theoretical results
   predicting the system performance [GRA18][SCH19].

Thubert, et al.           Expires 7 March 2025                 [Page 47]
Internet-Draft              RAW Technologies              September 2024

7.2.  General Characteristics

   LDACS will become one of several wireless access networks connecting
   aircraft to the Aeronautical Telecommunications Network (ATN).  The
   LDACS access network contains several ground stations, each of them
   providing one LDACS radio cell.  The LDACS air interface is a
   cellular data link with a star-topology connecting aircraft to
   ground-stations with a full duplex radio link.  Each ground-station
   is the centralized instance controlling all air-ground communications
   within its radio cell.

   The user data rate of LDACS is 315 kbit/s to 1428 kbit/s on the
   forward link, and 294 kbit/s to 1390 kbit/s on the reverse link,
   depending on coding and modulation.  Due to strong interference from
   legacy systems in the L-band, the most robust coding and modulation
   should be expected for initial deployment i.e. 315/294 kbit/s on the
   forward/reverse link, respectively.

   In addition to the communications capability, LDACS also offers a
   navigation capability.  Ranging data, similar to DME (Distance
   Measuring Equipment), is extracted from the LDACS communication links
   between aircraft and LDACS ground stations.  This results in LDACS
   providing an APNT (Alternative Position, Navigation and Timing)
   capability to supplement the existing on-board GNSS (Global
   Navigation Satellite System) without the need for additional
   bandwidth.  Operationally, there will be no difference for pilots
   whether the navigation data are provided by LDACS or DME.  This
   capability was flight tested and proven during the MICONAV flight
   trials in 2019 [BAT19].

   In previous works and during the MICONAV flight campaign in 2019, it
   was also shown, that LDACS can be used for surveillance capability.
   Filip et al.  [FIL19] shown passive radar capabilities of LDACS and
   Automatic Dependence Surveillance – Contract (ADS-C) was demonstrated
   via LDACS during the flight campaign 2019 [SCH19].

   Since LDACS has been mainly designed for air traffic management
   communication it supports mutual entity authentication, integrity and
   confidentiality capabilities of user data messages and some control
   channel protection capabilities [MAE18], [MAE191], [MAE192], [MAE20].

   Overall this makes LDACS the world's first truly integrated
   Communications, Navigation, and Surveillance (CNS) system and is the
   worldwide most mature, secure, terrestrial long-range CNS technology
   for civil aviation.

Thubert, et al.           Expires 7 March 2025                 [Page 48]
Internet-Draft              RAW Technologies              September 2024

7.3.  Deployment and Spectrum

   LDACS has its origin in merging parts of the B-VHF [BRA06], B-AMC
   [SCH08], TIA-902 (P34) [HAI09], and WiMAX IEEE 802.16e technologies
   [EHA11].  In 2007 the spectrum for LDACS was allocated at the World
   Radio Conference (WRC).

   It was decided to allocate the spectrum next to Distance Measuring
   Equipment (DME), resulting in an in-lay approach between the DME
   channels for LDAC [SCH14].

   LDACS is currently being standardized by ICAO and several roll-out
   strategies are discussed:

   The LDACS data link provides enhanced capabilities to existing
   Aeronautical communications infrastructure enabling them to better
   support user needs and new applications.  The deployment scalability
   of LDACS allows its implementation to start in areas where most
   needed to Improve immediately the performance of already fielded
   infrastructure.  Later the deployment is extended based on
   operational demand.  An attractive scenario for upgrading the
   existing VHF communication systems by adding an additional LDACS data
   link is described below.

   When considering the current VDL Mode 2 infrastructure and user base,
   a very attractive win-win situation comes about, when the
   technological advantages of LDACS are combined with the existing VDL
   mode 2 infrastructure.  LDACS provides at least 50 time more capacity
   than VDL Mode 2 and is a natural enhancement to the existing VDL Mode
   2 business model.  The advantage of this approach is that the VDL
   Mode 2 infrastructure can be fully reused.  Beyond that, it opens the
   way for further enhancements which can increase business efficiency
   and minimize investment risk.  [ICAO19]

7.4.  Applicability to Deterministic Flows

   As LDACS is a ground-based digital communications system for flight
   guidance and communications related to safety and regularity of
   flight, time-bounded deterministic arrival times for safety critical
   messages are a key feature for its successful deployment and roll-
   out.

Thubert, et al.           Expires 7 March 2025                 [Page 49]
Internet-Draft              RAW Technologies              September 2024

7.4.1.  System Architecture

   Up to 512 Aircraft Station (AS) communicate to an LDACS Ground
   Station (GS) in the Reverse Link (RL).  GS communicate to AS in the
   Forward Link (FL).  Via an Access-Router (AC-R) GSs connect the LDACS
   sub-network to the global Aeronautical Telecommunications Network
   (ATN) to which the corresponding Air Traffic Services (ATS) and
   Aeronautical Operational Control (AOC) end systems are attached.

7.4.2.  Overview of The Radio Protocol Stack

   The protocol stack of LDACS is implemented in the AS and GS: It
   consists of the Physical Layer (PHY) with five major functional
   blocks above it.  Four are placed in the Data Link Layer (DLL) of the
   AS and GS: (1) Medium Access Layer (MAC), (2) Voice Interface (VI),
   (3) Data Link Service (DLS), and (4) LDACS Management Entity (LME).
   The last entity resides within the Sub-Network Layer: Sub-Network
   Protocol (SNP).  The LDACS network is externally connected to voice
   units, radio control units, and the ATN Network Layer.

   Communications between MAC and LME layer is split into four distinct
   control channels: The Broadcast Control Channel (BCCH) where LDACS
   ground stations announce their specific LDACS cell, including
   physical parameters and cell identification; the Random Access
   Channel (RACH) where LDACS airborne radios can request access to an
   LDACS cell; the Common Control Channel (CCCH) where LDACS ground
   stations allocate resources to aircraft radios, enabling the airborne
   side to transmit user payload; 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 user payload.
   Communications between MAC and DLS layer is handled by the Data
   Channel (DCH) where user payload is handled.

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

Thubert, et al.           Expires 7 March 2025                 [Page 50]
Internet-Draft              RAW Technologies              September 2024

            IPv6                   Network Layer
              |
              |
   +------------------+  +----+
   |        SNP       |--|    |   Sub-Network
   |                  |  |    |   Layer
   +------------------+  |    |
              |          | LME|
   +------------------+  |    |
   |        DLS       |  |    |   Logical Link
   |                  |  |    |   Control Layer
   +------------------+  +----+
              |             |
             DCH         DCCH/CCCH
              |          RACH/BCCH
              |             |
   +--------------------------+
   |           MAC            |   Medium Access
   |                          |   Layer
   +--------------------------+
              |
   +--------------------------+
   |           PHY            |   Physical Layer
   +--------------------------+
              |
              |
            ((*))
            FL/RL              radio channels
                               separated by
                               Frequency Division Duplex

                Figure 10: LDACS protocol stack in AS and GS

7.4.3.  Radio (PHY)

   The physical layer provides the means to transfer data over the radio
   channel.  The LDACS ground-station supports bi-directional links to
   multiple aircraft under its control.  The forward link direction (FL;
   ground-to-air) and the reverse link direction (RL; air-to-ground) are
   separated by frequency division duplex.  Forward link and reverse
   link use a 500 kHz channel each.  The ground-station transmits a
   continuous stream of OFDM symbols on the forward link.  In the
   reverse link different aircraft are separated in time and frequency
   using a combination of Orthogonal Frequency-Division Multiple-Access
   (OFDMA) and Time-Division Multiple-Access (TDMA).  Aircraft thus
   transmit discontinuously on the reverse link with radio bursts sent

Thubert, et al.           Expires 7 March 2025                 [Page 51]
Internet-Draft              RAW Technologies              September 2024

   in precisely defined transmission opportunities allocated by the
   ground-station.  The most important service on the PHY layer of LDACS
   is the PHY time framing service, which indicates that the PHY layer
   is ready to transmit in a given slot and to indicate PHY layer
   framing and timing to the MAC time framing service.  LDACS does not
   support beam-forming or Multiple Input Multiple Output (MIMO).

7.4.4.  Scheduling, Frame Structure and QoS (MAC)

   The data-link layer provides the necessary protocols to facilitate
   concurrent and reliable data transfer for multiple users.  The LDACS
   data link layer is organized in two sub-layers: The medium access
   sub-layer and the logical link control sub-layer.  The medium access
   sub-layer manages the organization of transmission opportunities in
   slots of time and frequency.  The logical link control sub-layer
   provides acknowledged point-to-point logical channels between the
   aircraft and the ground-station using an automatic repeat request
   protocol.  LDACS supports also unacknowledged point-to-point channels
   and ground-to-air broadcast.  Before going more into depth about the
   LDACS medium access, the frame structure of LDACS is introduced:

   The LDACS framing structure for FL and RL is based on Super-Frames
   (SF) of 240 ms duration.  Each SF corresponds to 2000 OFDM symbols.
   The FL and RL SF boundaries are aligned in time (from the view of the
   GS).

   In the FL, an SF contains a Broadcast Frame of duration 6.72 ms (56
   OFDM symbols) for the Broadcast Control Channel (BCCH), and four
   Multi-Frames (MF), each of duration 58.32 ms (486 OFDM symbols).

   In the RL, each SF starts with a Random Access (RA) slot of length
   6.72 ms with two opportunities for sending RL random access frames
   for the Random Access Channel (RACH), followed by four MFs.  These
   MFs have the same fixed duration of 58.32 ms as in the FL, but a
   different internal structure

   Figure 11 and Figure 12 illustrate the LDACS frame structure.

Thubert, et al.           Expires 7 March 2025                 [Page 52]
Internet-Draft              RAW Technologies              September 2024

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

                     Figure 11: SF structure for LDACS

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

                     Figure 12: MF structure for LDACS

   This fixed frame structure allows for a reliable and dependable
   transmission of data.  Next, the LDACS medium access layer is
   introduced:

   LDACS medium access is always under the control of the ground-station
   of a radio cell.  Any medium access for the transmission of user data
   has to be requested with a resource request message stating the
   requested amount of resources and class of service.  The ground-
   station performs resource scheduling on the basis of these requests

Thubert, et al.           Expires 7 March 2025                 [Page 53]
Internet-Draft              RAW Technologies              September 2024

   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 forward link, this is done locally in the
   ground-station, on the reverse link a dedicated contention-free
   control channel is used (Dedicated Control Channel (DCCH); roughly 83
   bit every 60 ms).  A resource allocation is always announced in the
   control channel of the forward link (Common Control Channel (CCCH);
   variable sized).  Due to the spacing of the reverse link control
   channels of every 60 ms, a medium access delay in the same order of
   magnitude is to be expected.

   Resources can also be requested "permanently".  The permanent
   resource request mechanism supports requesting recurring resources in
   given time intervals.  A permanent resource request has to be
   canceled by the user (or by the ground-station, which is always in
   control).  User data transmissions over LDACS are therefore always
   scheduled by the ground-station, while control data uses statically
   (i.e. at net entry) allocated recurring resources (DCCH and CCCH).
   The current specification documents specify no scheduling algorithm.
   However performance evaluations so far have used strict priority
   scheduling and round robin for equal priorities for simplicity.  In
   the current prototype implementations LDACS classes of service are
   thus realized as priorities of medium access and not as flows.  Note
   that this can starve out low priority flows.  However, this is not
   seen as a big problem since safety related message always go first in
   any case.  Scheduling of reverse link resources is done in physical
   Protocol Data Units (PDU) of 112 bit (or larger if more aggressive
   coding and modulation is used).  Scheduling on the forward link is
   done Byte-wise since the forward link is transmitted continuously by
   the ground-station.

   In order to support diversity, LDACS supports handovers to other
   ground-stations on different channels.  Handovers may be initiated by
   the aircraft (break-before-make) or by the ground-station (make-
   before-break).  Beyond this, FCI diversity shall be implemented by
   the multi-link concept.

7.5.  Summary

   LDACS has been designed with applications related to the safety and
   regularity of the flight in mind.  It has therefore been designed as
   a deterministic wireless data link (as far as possible).

Thubert, et al.           Expires 7 March 2025                 [Page 54]
Internet-Draft              RAW Technologies              September 2024

   It is a secure, scalable and spectrum efficient data link with
   embedded navigation capability and thus, is the first truly
   integrated CNS system recognized by ICAO.  During flight tests the
   LDACS capabilities have been successfully demonstrated.  A viable
   roll-out scenario has been developed which allows gradual
   introduction of LDACS with immediate use and revenues.  Finally, ICAO
   is developing LDACS standards to pave the way for a successful roll-
   out in the near future.

8.  IANA Considerations

   This specification does not require IANA action.

9.  Security Considerations

   This document surveys existing networking technology and defines no
   protocol behaviors or operational practices.  The IETF specifications
   referenced here each provide their own Security Considerations.  Most
   RAW technologies integrate some authentication or encryption
   mechanisms that were defined outside the IETF.

10.  Contributors

   This document aggregates articles from authors specialized in each
   technologies.  Beyond the main authors listed in the front page, the
   following contributors proposed additional text and refinement that
   improved the documertn greatly!

   Georgios Z.  Papadopoulos:  Contributed to the TSCH section.

   Nils Maeurer:  Contributed to the LDACS section.

   Thomas Graeupl:  Contributed to the LDACS section.

   Torsten Dudda, Alexey Shapin, and Sara Sandberg:  Contributed to the
      5G section.

   Rocco Di Taranto:  Contributed to the Wi-Fi section

   Rute Sofia:  Contributed to the Introduction and Terminology sections

Thubert, et al.           Expires 7 March 2025                 [Page 55]
Internet-Draft              RAW Technologies              September 2024

11.  Acknowledgments

   Many thanks to the participants of the RAW WG where a lot of the work
   discussed here happened, and Malcolm Smith for his review of the
   802.11 section.  Special thanks for post directorate and IESG
   reviewers, Roman Danyliw, Victoria Pritchard, and Carlos Jesus
   Bernardos Cano.

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

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

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

   [RFC8655]  Finn, N., Thubert, P., Varga, B., and J. Farkas,
              "Deterministic Networking Architecture", RFC 8655,
              DOI 10.17487/RFC8655, October 2019,
              <https://www.rfc-editor.org/info/rfc8655>.

   [RFC9030]  Thubert, P., Ed., "An Architecture for IPv6 over the Time-
              Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)",
              RFC 9030, DOI 10.17487/RFC9030, May 2021,
              <https://www.rfc-editor.org/info/rfc9030>.

   [I-D.ietf-raw-architecture]
              Thubert, P., "Reliable and Available Wireless
              Architecture", Work in Progress, Internet-Draft, draft-
              ietf-raw-architecture-18, 8 July 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-raw-
              architecture-18>.

13.  Informative References

   [RFC8480]  Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH
              Operation Sublayer (6top) Protocol (6P)", RFC 8480,
              DOI 10.17487/RFC8480, November 2018,
              <https://www.rfc-editor.org/info/rfc8480>.

Thubert, et al.           Expires 7 March 2025                 [Page 56]
Internet-Draft              RAW Technologies              September 2024

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

   [RFC9033]  Chang, T., Ed., Vučinić, M., Vilajosana, X., Duquennoy,
              S., and D. Dujovne, "6TiSCH Minimal Scheduling Function
              (MSF)", RFC 9033, DOI 10.17487/RFC9033, May 2021,
              <https://www.rfc-editor.org/info/rfc9033>.

   [RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
              Low-Power and Lossy Networks", RFC 6550,
              DOI 10.17487/RFC6550, March 2012,
              <https://www.rfc-editor.org/info/rfc6550>.

   [RFC6551]  Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
              and D. Barthel, "Routing Metrics Used for Path Calculation
              in Low-Power and Lossy Networks", RFC 6551,
              DOI 10.17487/RFC6551, March 2012,
              <https://www.rfc-editor.org/info/rfc6551>.

   [RFC6291]  Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
              D., and S. Mansfield, "Guidelines for the Use of the "OAM"
              Acronym in the IETF", BCP 161, RFC 6291,
              DOI 10.17487/RFC6291, June 2011,
              <https://www.rfc-editor.org/info/rfc6291>.

   [RFC7276]  Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
              Weingarten, "An Overview of Operations, Administration,
              and Maintenance (OAM) Tools", RFC 7276,
              DOI 10.17487/RFC7276, June 2014,
              <https://www.rfc-editor.org/info/rfc7276>.

   [RFC8279]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
              Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
              Explicit Replication (BIER)", RFC 8279,
              DOI 10.17487/RFC8279, November 2017,
              <https://www.rfc-editor.org/info/rfc8279>.

   [RFC9023]  Varga, B., Ed., Farkas, J., Malis, A., and S. Bryant,
              "Deterministic Networking (DetNet) Data Plane: IP over
              IEEE 802.1 Time-Sensitive Networking (TSN)", RFC 9023,
              DOI 10.17487/RFC9023, June 2021,
              <https://www.rfc-editor.org/info/rfc9023>.

Thubert, et al.           Expires 7 March 2025                 [Page 57]
Internet-Draft              RAW Technologies              September 2024

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

   [I-D.ietf-roll-nsa-extension]
              Koutsiamanis, R., 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-12, 8
              November 2023, <https://datatracker.ietf.org/doc/html/
              draft-ietf-roll-nsa-extension-12>.

   [I-D.ietf-roll-dao-projection]
              Thubert, P., Jadhav, R., and M. Richardson, "Root
              initiated routing state in RPL", Work in Progress,
              Internet-Draft, draft-ietf-roll-dao-projection-34, 30
              November 2023, <https://datatracker.ietf.org/doc/html/
              draft-ietf-roll-dao-projection-34>.

   [I-D.thubert-bier-replication-elimination]
              Thubert, P., Eckert, T. T., Brodard, Z., and H. Jiang,
              "BIER-TE extensions for Packet Replication and Elimination
              Function (PREF) and OAM", Work in Progress, Internet-
              Draft, draft-thubert-bier-replication-elimination-03, 3
              March 2018, <https://datatracker.ietf.org/doc/html/draft-
              thubert-bier-replication-elimination-03>.

   [I-D.ietf-6tisch-coap]
              Sudhaakar, R. S. and P. Zand, "6TiSCH Resource Management
              and Interaction using CoAP", Work in Progress, Internet-
              Draft, draft-ietf-6tisch-coap-03, 9 March 2015,
              <https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-
              coap-03>.

   [IEEE Std 802.15.4]
              IEEE standard for Information Technology, "IEEE Std
              802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
              and Physical Layer (PHY) Specifications for Low-Rate
              Wireless Personal Area Networks".

Thubert, et al.           Expires 7 March 2025                 [Page 58]
Internet-Draft              RAW Technologies              September 2024

   [IEEE Std 802.11]
              IEEE standard for Information Technology, "IEEE Standard
              802.11 - IEEE Standard for Information Technology -
              Telecommunications and information exchange between
              systems Local and metropolitan area networks - Specific
              requirements - Part 11: Wireless LAN Medium Access Control
              (MAC) and Physical Layer (PHY) Specifications.",
              <https://ieeexplore.ieee.org/document/9363693>.

   [IEEE Std 802.11ax]
              IEEE standard for Information Technology, "802.11ax:
              Enhancements for High Efficiency WLAN", 2021,
              <https://ieeexplore.ieee.org/document/9442429>.

   [IEEE Std 802.11ay]
              IEEE standard for Information Technology, "802.11ay:
              Enhanced throughput for operation in license-exempt bands
              above 45 GHz", 2021,
              <https://ieeexplore.ieee.org/document/9502046/>.

   [IEEE Std 802.11ad]
              "802.11ad: Enhancements for very high throughput in the 60
              GHz band", 2012,
              <https://ieeexplore.ieee.org/document/6392842/>.

   [IEEE 802.11be WIP]
              IEEE standard for Information Technology, "802.11be:
              Extreme High Throughput PAR",
              <https://mentor.ieee.org/802.11/dcn/18/11-18-1231-04-0eht-
              eht-draft-proposed-par.docx>.

   [IEEE Std 802.1Qat]
              "802.1Qat: Stream Reservation Protocol".

   [Cavalcanti_2019]
              Dave Cavalcanti et al., "Extending Time Distribution and
              Timeliness Capabilities over the Air to Enable Future
              Wireless Industrial Automation Systems, the Proceedings of
              IEEE", June 2019.

   [Nitsche_2015]
              Thomas Nitsche et al., "IEEE 802.11ad: directional 60 GHz
              communication for multi-Gigabit-per-second Wi-Fi",
              December 2014.

   [Ghasempour_2017]
              Yasaman Ghasempour et al., "802.11ay: Next-Generation 60
              GHz Communications for 100 Gb/s Wi-Fi", December 2017.

Thubert, et al.           Expires 7 March 2025                 [Page 59]
Internet-Draft              RAW Technologies              September 2024

   [IEEE_doc_11-18-2009-06]
              IEEE standard for Information Technology, "802.11 Real-
              Time Applications (RTA) Topic Interest Group (TIG)
              Report", November 2018.

   [IEEE_doc_11-19-0373-00]
              Kevin Stanton et Al., "Time-Sensitive Applications Support
              in EHT", March 2019.

   [vilajosana21]
              Xavier Vilajosana et al., "IETF 6TiSCH: A Tutorial", March
              2021.

   [ISA100.11a]
              ISA/IEC, "ISA100.11a, Wireless Systems for Automation,
              also IEC 62734", 2011, <http://www.isa100wci.org/en-
              US/Documents/PDF/3405-ISA100-WirelessSystems-Future-broch-
              WEB-ETSI.aspx>.

   [WirelessHART]
              www.hartcomm.org, "Industrial Communication Networks -
              Wireless Communication Network and Communication Profiles
              - WirelessHART - IEC 62591", 2010.

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

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

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

   [RIH18]    Rihacek, C., Haindl, B., Fantappie, P., Pierattelli, S.,
              Gräupl, T., Schnell, M., and N. Fistas, "L-band Digital
              Aeronautical Communications System (LDACS) Activities in
              SESAR2020", Proceedings of the Integrated Communications
              Navigation and Surveillance Conference (ICNS) Herndon, VA,
              USA, April 2018.

   [GRA19]    Gräupl, T., Rihacek, C., and B. Haindl, "LDACS A/G
              Specification", SESAR2020 PJ14-02-01 D3.3.010, February
              2019.

   [SAJ14]    Sajatovic, M., Günzel, H., and S. Müller, "WA04 D22 Test
              Report for Assessing LDACS1 Transmitter Impact upon DME/
              TACAN Receivers", April 2014.

Thubert, et al.           Expires 7 March 2025                 [Page 60]
Internet-Draft              RAW Technologies              September 2024

   [GRA11]    Gräupl, T. and M. Ehammer, "L-DACS1 Data Link Layer
              Evolution of ATN/IPS", Proceedings of the 30th IEEE/AIAA
              Digital Avionics Systems Conference (DASC) Seattle, WA,
              USA, October 2011.

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

   [GRA18]    al., T. G. E., "L-band Digital Aeronautical Communications
              System (LDACS) flight trials in the national German
              project MICONAV", Proceedings of the Integrated
              Communications, Navigation, Surveillance Conference
              (ICNS) Herndon, VA, USA, April 2018.

   [SCH19]    Schnell, M., "DLR tests digital communications
              technologies combined with additional navigation functions
              for the first time", 3 March 2019,
              <https://www.dlr.de/dlr/en/desktopdefault.aspx/tabid-
              10081/151_read-32951/#/gallery/33877>.

   [TR37910]  3GPP, "Study on self evaluation towards IMT-2020
              submission", 3GPP TR 37.910,
              <https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=3190>.

   [TR38824]  3GPP, "Study on physical layer enhancements for NR ultra-
              reliable and low latency case (URLLC)", 3GPP TR 38.824,
              <https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=3498>.

   [TR38825]  3GPP, "Study on NR industrial Internet of Things (IoT)",
              3GPP TR 38.825,
              <https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=3492>.

   [TS22104]  3GPP, "Service requirements for cyber-physical control
              applications in vertical domains", 3GPP TS 22.104,
              <https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=3528>.

   [TR22804]  3GPP, "Study on Communication for Automation in Vertical
              domains (CAV)", 3GPP TS 22.804,
              <https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=3187>.

Thubert, et al.           Expires 7 March 2025                 [Page 61]
Internet-Draft              RAW Technologies              September 2024

   [TS23501]  3GPP, "System architecture for the 5G System (5GS)",
              3GPP TS 23.501,
              <https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=3144>.

   [TS38300]  3GPP, "NR Overall description", 3GPP TS 38.300,
              <https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=3191>.

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

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

   [TR2370046]
              3GPP, "Study on 5GS DetNet interworking",
              3GPP TR23.700-46, August 2022,
              <https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=3994>.

   [SP211634] 3GPP, "Study on 5G Timing Resiliency, TSC, and URLLC
              enhancements", 3GPP SP-211634, December 2021,
              <https://www.3gpp.org/ftp/tsg_sa/TSG_SA/
              TSGS_94E_Electronic_2021_12/Docs/SP-211634.zip>.

   [IMT2020]  "ITU towards IMT for 2020 and beyond",
              <https://www.itu.int/en/ITU-R/study-groups/rsg5/rwp5d/imt-
              2020/Pages/default.aspx>.

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

   [IEEE802.1AS]
              IEEE, "IEEE Standard for Local and metropolitan area
              networks -- Timing and Synchronization for Time-Sensitive
              Applications", IEEE 802.1AS-2020,
              <https://standards.ieee.org/content/ieee-standards/en/
              standard/802_1AS-2020.html>.

   [IEEE802.1CB]
              IEEE, "IEEE Standard for Local and metropolitan area
              networks -- Frame Replication and Elimination for

Thubert, et al.           Expires 7 March 2025                 [Page 62]
Internet-Draft              RAW Technologies              September 2024

              Reliability", DOI 10.1109/IEEEStd2017.8091139, IEEE 
              802.1CB-2017,
              <https://ieeexplore.ieee.org/document/8091139>.

   [IEEE802.1Qbv]
              IEEE, "IEEE Standard for Local and metropolitan area
              networks -- Bridges and Bridged Networks -- Amendment 25:
              Enhancements for Scheduled Traffic", IEEE 802.1Qbv-2015,
              <https://ieeexplore.ieee.org/document/7440741>.

   [IEEE802.1Qcc]
              IEEE, "IEEE Standard for Local and metropolitan area
              networks -- Bridges and Bridged Networks -- Amendment 31:
              Stream Reservation Protocol (SRP) Enhancements and
              Performance Improvements", IEEE 802.1Qcc-2018,
              <https://ieeexplore.ieee.org/document/8514112>.

   [IEEE802.3]
              IEEE, "IEEE Standard for Ethernet", IEEE 802.3-2018,
              <https://ieeexplore.ieee.org/document/8457469>.

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

   [MAE18]    Maeurer, N. and A. Bilzhause, "A Cybersecurity
              Architecture for the L-band Digital Aeronautical
              Communications System (LDACS)", IEEE 37th Digital Avionics
              Systems Conference (DASC), pp. 1-10, London, UK , 2017.

   [MAE191]   Maeurer, N. and C. Schmitt, "Towards Successful
              Realization of the LDACS Cybersecurity Architecture: An
              Updated Datalink Security Threat- and Risk Analysis", IEEE
              Integrated Communications, Navigation and Surveillance
              Conference (ICNS), pp. 1-13, Herndon, VA, USA , 2019.

   [ICAO19]   International Civil Aviation Organization (ICAO), "TLDACS
              White Paper–A Roll-out Scenario", Working Paper
              COMMUNICATIONS PANEL–DATA COMMUNICATIONS INFRASTRUCTURE
              WORKING GROUP, Montreal, Canada , October 2019.

   [MAE192]   Maeurer, N., Graeupl, T., and C. Schmitt, "Evaluation of
              the LDACS Cybersecurity Implementation", IEEE 38th Digital
              Avionics Systems Conference (DACS), pp. 1-10, San Diego,
              CA, USA , September 2019.

Thubert, et al.           Expires 7 March 2025                 [Page 63]
Internet-Draft              RAW Technologies              September 2024

   [MAE20]    Maeurer, N., Graeupl, T., and C. Schmitt, "Comparing
              Different Diffie-Hellman Key Exchange Flavors for LDACS",
              IEEE 39th Digital Avionics Systems Conference (DACS), pp.
              1-10, San Diego, CA, USA , October 2019.

   [FIL19]    Filip-Dhaubhadel, A. and D. Shutin, "LDACS- Based Non-
              Cooperative Surveillance Multistatic Radar Design and
              Detection Coverage Assessment", IEEE 38th Digital Avionics
              Systems Conference (DACS), pp. 1-10, San Diego, CA, USA ,
              September 2019.

   [BAT19]    Battista, G., Osechas, O., Narayanan, S., Crespillo, O.G.,
              Gerbeth, D., Maeurer, N., Mielke, D., and T. Graeupl,
              "Real-Time Demonstration of Integrated Communication and
              Navigation Services Using LDACS", IEEE Integrated
              Communications, Navigation and Surveillance Conference
              (ICNS), pp. 1-12, Herndon, VA, USA , 2019.

   [BRA06]    Brandes, S., Schnell, M., Rokitansky, C.H., Ehammer, M.,
              Graeupl, T., Steendam, H., Guenach, M., Rihacek, C., and
              B. Haindl, "B-VHF -Selected Simulation Results and Final
              Assessment", IEEE 25th Digital Avionics Systems Conference
              (DACS), pp. 1-12, New York, NY, USA , September 2019.

   [SCH08]    Schnell, M., Brandes, S., Gligorevic, S., Rokitansky,
              C.H., Ehammer, M., Graeupl, T., Rihacek, C., and M.
              Sajatovic, "B-AMC - Broadband Aeronautical Multi-carrier
              Communications", IEEE 8th Integrated Communications,
              Navigation and Surveillance Conference (ICNS), pp. 1-13,
              New York, NY, USA , April 2008.

   [HAI09]    Haindl, B., Rihacek, C., Sajatovic, M., Phillips, B.,
              Budinger, J., Schnell, M., Kamiano, D., and W. Wilson,
              "Improvement of L-DACS1 Design by Combining B-AMC with P34
              and WiMAX Technologies", IEEE 9th Integrated
              Communications, Navigation and Surveillance Conference
              (ICNS), pp. 1-8, New York, NY, USA , May 2009.

   [EHA11]    Ehammer, M. and T. Graeupl, "AeroMACS - An Airport
              Communications System", IEEE 30th Digital Avionics Systems
              Conference (DACS), pp. 1-16, New York, NY, USA , September
              2011.

   [SCH14]    Schnell, M., Epple, U., Shutin, D., and N.
              Schneckenburger, "LDACS: Future Aeronautical
              Communications for Air- Traffic Management", IEEE
              Communications Magazine, 52(5), 104-110 , 2017.

Thubert, et al.           Expires 7 March 2025                 [Page 64]
Internet-Draft              RAW Technologies              September 2024

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

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

   [Fang_2021]
              Fang, J., Cavalcanti, D., Cordeiro, C., and C. Cheng,
              "Wireless TSN with Multi-Radio Wi-Fi", IEEE International
              Conference on Standards for Communications and Networking,
              December 2021. , 2021.

Authors' Addresses

   Pascal Thubert (editor)
   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

Thubert, et al.           Expires 7 March 2025                 [Page 65]
Internet-Draft              RAW Technologies              September 2024

   Corinna Schmitt
   Research Institute CODE, UniBw M
   Werner-Heisenberg-Weg 39
   85577 Neubiberg
   Germany
   Email: corinna.schmitt@unibw.de

   Janos Farkas
   Ericsson
   Budapest
   Magyar tudosok korutja 11
   1117
   Hungary
   Email: janos.farkas@ericsson.com

Thubert, et al.           Expires 7 March 2025                 [Page 66]