<?xml version='1.0' encoding='utf-8'?>
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?> version="1.0" encoding="utf-8"?>

<!DOCTYPE rfc [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" ipr='trust200902' tocInclude="true"  obsoletes="" updates="" symRefs="true" sortRefs="false" consensus="true" submissionType="IETF" xml:lang="en" version="3" docName="draft-ietf-raw-technologies-17" > number="9913">

<front>
   <title abbrev='RAW Technologies'>Reliable and Available Wireless (RAW) Technologies</title>
   <seriesInfo name="RFC" value="9913"/>
   <author initials='P' surname='Thubert' fullname='Pascal Thubert' role='editor'>
      <!-- <organization abbrev='Cisco Systems'>Cisco Systems, Inc</organization> -->
      <address>
         <postal>
            <city>Roquefort-les-Pins</city>
            <code>06330</code>
          <country>France</country>
         </postal>
         <email>pascal.thubert@gmail.com</email>
      </address>
   </author>
   <author initials='D' surname='Cavalcanti' fullname='Dave Cavalcanti'>
      <organization abbrev='Intel'>Intel Corporation</organization>
      <address>
         <postal>
            <street>2111 NE 25th Ave </street>
            <city> Hillsboro, OR</city> Hillsboro</city>
	    <region>OR</region>
            <code>97124</code>
            <country>USA</country>
            <country>United States of America</country>
         </postal>
         <phone>503 712 5566</phone>
         <email>dave.cavalcanti@intel.com</email>
      </address>
   </author>
   <author initials='X' surname='Vilajosana' fullname='Xavier Vilajosana'>
      <organization>Universitat Oberta de Catalunya</organization>
      <address>
         <postal>
            <street>156 Rambla Poblenou</street>
            <city>Barcelona</city>
            <region>Catalonia</region>
            <code>08018</code>
            <country>Spain</country>
         </postal>
         <email>xvilajosana@uoc.edu</email></address>
    </author>

   <author initials='C' surname='Schmitt' fullname='Corinna Schmitt'>
      <organization>Research Institute CODE, UniBw M</organization>
      <address>
         <postal>
            <street>Werner-Heisenberg-Weg 39</street>
            <city>Neubiberg</city>
            <code>85577</code>
            <country>Germany</country>
         </postal>
         <email>corinna.schmitt@unibw.de</email></address>
    </author>
       <author initials='J' surname='Farkas' fullname='Janos Farkas'>
      <organization abbrev='Ericsson'>Ericsson</organization>
      <address>
         <postal>
            <street>Magyar tudosok korutja 11</street>
            <city> Budapest</city>
            <code>1117</code>
            <country>Hungary</country>
         </postal>
         <email>janos.farkas@ericsson.com</email>
      </address>
   </author>

   <date/>
   <area>Internet Area</area>
   <workgroup>RAW</workgroup>
   <keyword>Draft</keyword>
   <abstract>
      <t>

   <date month="February" year="2026"/>

   <area>RTG</area>
   <workgroup>detnet</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

<!-- [rfced] Should "/" here be updated to "or" or "and"?

Original:
   This document surveys the short and middle range radio technologies
   that are suitable to provide a Deterministic Networking / Reliable
   and Available Wireless (RAW) service over, presents the
   characteristics that RAW may leverage, and explores the applicability
   of the technologies to carry deterministic flows, as of its time of
   publication.

Perhaps:
   This document surveys the short- and middle-range radio technologies
   over which providing Deterministic Networking (DetNet) or Reliable
   and Available Wireless (RAW) service is suitable, presents the
   characteristics that RAW may leverage, and explores the applicability
   of the technologies to carry deterministic flows, as of the time of
   publication.
-->

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

<middle>
   <section><name>Introduction</name>

   <t>
   Deterministic Networking (DetNet) <xref target="RFC8557"/> provides a
   capability to carry specified unicast or multicast data flows for real-time
   applications with extremely low data loss rates and bounded latency within
   a network domain.  Techniques that might be used include
     (1) reserving data-plane data plane resources for individual (or aggregated) DetNet
     flows in some or all of the intermediate nodes along the path of the
     flow,
     (2) providing explicit routes for DetNet flows that do not immediately
     change with the network topology, and
     (3) distributing data from DetNet flow packets over time and/or space
     (e.g., different frequencies, frequencies or non-Shared Risk Links) non-shared risk links) to ensure
     delivery of each packet in spite of the unavailability of a path.  DetNet path.</t>
<t>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.
   </t>
   <t>
   The Reliable and Available Wireless (RAW) Architecture architecture <xref target='I-D.ietf-raw-architecture'/>
   target="RFC9912"/> extends the DetNet Architecture architecture <xref target="RFC8655"/>
   to adapt to the specific challenges of the wireless medium, in particular particular,
   intermittently lossy connectivity, by optimizing the use of diversity and
   multipathing. <xref target='I-D.ietf-raw-architecture'/> target='RFC9912'/> defines the concepts of Reliability reliability
   and Availability availability that are used in this document. In turn, this document
   presents wireless technologies with capabilities capabilities, such as time
   synchronization and scheduling of transmission, that would make RAW/DetNet
   operations possible over such media. The technologies studied in this
   document were identified in the charter during the RAW WG Working Group (WG) formation and
   inherited by DetNet (when the WG picked up the work on RAW).
   </t>
   <t>
   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.
  </t>
   <t>
   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:
</t>
   <ul>
   <li>
   per-hop
   <li>per-hop retransmissions (aka (also known as Automatic Repeat Request or ARQ),
   </li><li>
   variation (ARQ)),</li>
   <li>variation of the modulation Modulation and coding scheme (MCS),
   </li><li>
   short range broadcast,
   </li><li>
   Multiple User Coding Scheme (MCS),</li>
   <li>short-range broadcast,</li>
   <li>Multi-User - Multiple Input Multiple Output (MU-MIMO),
   </li><li>
   constructive (MU-MIMO),</li>
   <li>constructive interference, and
   </li><li>
   overhearing and</li>
   <li>overhearing whereby multiple receivers are scheduled to receive the same
   transmission, which saves both energy on the sender and spectrum.
   </li>
   </ul>
   <t>
   These capabilities may be offered by the lower layer and may be controlled by RAW, separately or in combination.
   </t>

<!-- [rfced] The series in this sentence is difficult to read because of the
many commas. We have updated to use semicolons to separate the items in
the series as shown below; please review for accuracy.

Original:

   The control loop involves communication monitoring through
   Operations, Administration and Maintenance (OAM), path control
   through a Path computation Element (PCE) and a runtime distributed
   Path Selection Engine (PSE) and extended packet replication,
   elimination, and ordering functions (PREOF).

Current:

   The control loop involves communication monitoring through
   Operations, Administration, and Maintenance (OAM); path control
   through a Path Computation Element (PCE) and a runtime distributed
   Path Selection Engine (PSE); and extended Packet Replication,
   Elimination, and Ordering Functions (PREOF).
-->

  <t>
   RAW defines a network-layer control loop that optimizes the use of links
   with constrained spectrum and energy while maintaining the expected
   connectivity properties, typically reliability and latency. The control
   loop involves communication monitoring through Operations, Administration Administration,
   and Maintenance (OAM), (OAM); path control through a Path computation Computation Element
   (PCE) and a runtime distributed Path Selection Engine (PSE) (PSE); and extended packet replication, elimination,
   Packet Replication, Elimination, and ordering functions Ordering Functions (PREOF).
   </t>
   <t>
   This document surveys the short short- and middle range middle-range radio technologies that are suitable to provide
   over which providing a DetNet/RAW service over, is suitable,
   presents the characteristics that RAW may leverage, and explores the applicability of
   the technologies to carry deterministic flows.  The studied technologies
   are Wi-Fi 6/7, TimeSlotted Time-Slotted Channel Hopping (TSCH), 3GPP 5G, and L-band
   Digital Aeronautical Communications System (LDACS).  The purpose of this
   document is to support and enable work on the these (and possibly other
   similar compatible technologies) at the IETF IETF, specifically in the DetNet working group
   Working Group working on RAW.
   </t>
   <t>
   This document surveys existing networking technology and defines no technology; it does not define protocol behaviors or operational practices.
   The IETF specifications referenced herein each provide their own Security Considerations, security considerations, and lower layer lower-layer technologies provide their own security at Layer-2; Layer 2; a security study of the technologies is explicitly not in scope.
   </t>
   </section><!-- title="Introduction"-->
   </section>

   <section><name>Terminology</name>
   <t>

<!-- [rfced] We updated this text to point to Section 3 instead of Section 2
of draft-ietf-raw-architecture (RFC-to-be 9912). Please confirm.

Original:

   This document uses the terminology and acronyms defined in Section 2
   of <xref target="RFC8655"/> [RFC8655] and Section 2 of [I-D.ietf-raw-architecture].

Updated:

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

   <t>
   This document uses the terminology and acronyms defined in <xref
   target="RFC8655" section="2"/> and <xref target='I-D.ietf-raw-architecture'/>. section="3" target='RFC9912'/>.
   </t>
   </section><!-- Terminology -->
   </section>

   <section anchor='detpak'><name>Towards Reliable and Available Wireless Networks</name>
   <section anchor='schre'><name>Scheduling for Reliability</name>
   <t>
   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., packets (e.g., delay or loss, loss) are eliminated.
   </t>
   <t>
   The reliability of a Deterministic Network deterministic network <xref target='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 times
   the amount number of the critical packets within the available resources of the
   communication hardware (e.g.; (e.g., buffers) and that of the transmission medium (e.g.;
   (e.g., bandwidth, transmission slots).  The schedule can also be used to
   shape the flows by controlling the time of transmission of the packets that
   compose the flow at every hop.
   </t>

   <t>
   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, Protocol (PTP),
   standardized as IEEE 1588 and IEC 61588, has mapping through profiles to
   Ethernet, industrial and SmartGrid protocols, and Wi-Fi with IEEE Std
   802.1AS.
   </t>
   </section><!-- Towards Reliable and Available Networks -->
   </section>
   <section anchor='divav'><name>Diversity for Availability</name>
   <t>
   Equipment (e.g., node) failure, for instance a broken switch or an access point rebooting, a broken
   wire or radio adapter, or a fixed obstacle to the transmission, failure can
   be the cause of multiple packets being lost in a row before the
   flows are rerouted or the system may recover. recovers. Examples of equipment failure include a broken switch, an access point rebooting, a broken
   wire or radio adapter, or a fixed obstacle to the transmission.
   </t>
   <t>
   This
   Equipment failure is not acceptable for critical applications such as those related to safety.
   A typical process control loop will tolerate an occasional packet loss, but
   a loss of several packets in a row will cause an emergency stop.
   In an amusement ride (e.g., at Disneyland, Universal, Universal Studios, or MGM Studios parks) parks),
   a continuous loss of packet packets for a few 100ms 100 ms may trigger an automatic
   interruption of the ride and cause the evacuation of the attraction floor to restart it.
   </t>
   <t>
   Network Availability 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 fading, or moving obstacles. The
   best results are typically achieved by pseudo-randomly pseudorandomly cumulating all forms
   of diversity, 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.
   </t>
   </section><!-- Diversity for Availability -->
   </section>

   <section anchor='wessbenef'><name>Benefits anchor='wessbenef'>
     <name>Benefits of Scheduling</name>
   <t>
   Scheduling redundant transmissions of the critical packets on diverse paths
   improves the resiliency against breakages and statistical transmission
   loss, such as those due to cosmic particles on wires, 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.
   </t>
   <t>
   When required, the worst case 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.
   </t>
   <t>
   In addition, scheduling provides specific value over the wireless medium:
   </t>
   <ul>
   <li>
   Scheduling allows a time-sharing operation, where every transmission is assigned its own time/frequency resource. Sender The sender and receiver are synchronized and scheduled to talk on a given frequency resource at a given time and for a given duration. This way, scheduling can avoid collisions between scheduled transmissions and enable a high ratio of critical traffic (think 60 60% or 70% of high priority high-priority traffic with ultra low loss) compared to statistical priority-based schemes.
   </li>
   <li>
   Scheduling can be used as a technique for both time and frequency diversity
   (e.g., between transmission retries), allowing the next transmission to
   happen on a different frequency as programmed in both the sender and the
   receiver.  This is useful to defeat co-channel interference from un-controlled
   uncontrolled transmitters as well as multipath fading.
   </li>
   <li>
   Transmissions can be also scheduled on multiple channels in parallel,
   which enables using the use of the full available spectrum while avoiding the
   hidden terminal problem, e.g., when the next packet in a same flow interferes
   on a same channel with the previous one that progressed a few hops farther.
   </li>
   <li>
   On the other hand, scheduling
   Scheduling optimizes the bandwidth usage: compared usage. Compared to
   classical Collision Avoidance collision avoidance techniques, there is no blank time related to
   inter-frame space
   Interframe Space (IFS) and exponential back-off in scheduled operations.
   A minimal Clear Channel Assessment 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.
   </li>
   <li>
   Finally, scheduling
   Scheduling plays a critical role to save in saving energy. In IoT, the Internet of Things (IoT), energy is
   the foremost concern, and synchronizing the sender and listener enables
   always maintaining them in deep sleep when there is no scheduled
   transmission. This avoids idle listening and long preambles preambles, and it enables long
   sleep periods between traffic and resynchronization, allowing
   battery-operated nodes to operate in a mesh topology for multiple years.
   </li>
   </ul>
   </section><!-- Benefits
   </section>
 </section>

<!-- [rfced] Please review the titles of Scheduling on Wireless -->

   </section><!-- Towards Reliable Sections 4-7 (the sections for the
technologies reviewed by this document). Would it be helpful to readers
to update the titles of Sections 4 and Available Networks 5 as shown below? Note that the
suggested aligns with the last sentence in the abstract and a similar
sentence in the Introduction.

Original:
  4.  IEEE 802.11
  5.  IEEE 802.15.4 Timeslotted Channel Hopping
  6.  5G
  7.  L-band Digital Aeronautical Communications System

Perhaps:
  4.  Wi-Fi
  5.  Time-Slotted Channel Hopping (TSCH)
  6.  5G
  7.  L-band Digital Aeronautical Communications System (LDACS)
-->

   <section><name>IEEE

   <section>
     <name>IEEE 802.11</name>

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

	  </t> Reality (VR).</t>
      <t>Leveraging IEEE Std 802.11, the Wi-Fi Alliance <xref target="WFA"/>
      delivered Wi-Fi 6, 7, and now 8 with more capabilities to schedule and
      deliver frames in due time at fast rates. Still, as with any radio
      technology, Wi-Fi is sensitive to frame loss, which can only be combated
      with the maximum use of diversity, diversity in space, time, channel, and even technology.
	  </t>
	  <t>
      technology.</t>

<!-- [rfced] Please clarify "for uses case with".

Original:
   In parallel, the Avnu Alliance <xref target="Avnu"/>, [Avnu], which focuses on applications
   of TSN for real time data, formed a workgroup for uses case with TSN
   capabilities over wireless, leveraging both 3GPP and IEEE Std 802.11
   standards.

	  </t>
     <t>

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

      <t>In parallel, the Avnu Alliance <xref target="Avnu"/>, which focuses
      on applications of TSN for real-time data, formed a workgroup for uses
      case with TSN capabilities over wireless, leveraging both 3GPP and IEEE
      Std 802.11 standards.</t>

<!-- [rfced] Will readers understand what "the latter" is here?

Original:
   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.
-->

      <t>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.
	  </t>
     <t>
     This play.</t>
      <t>This section surveys the IEEE 802.11 features that are most relevant to RAW,
      noting that there are a great many more in the specification, some of
      which may also possibly be of interest as well for a RAW solution.  For instance,
      frame fragmentation reduces the impact of a very transient transmission
      loss, both on latency and energy consumption.
      </t>

        <section><name>Provenance consumption.</t>

        <section>
	  <name>Provenance and Documents</name>

   <t>
   The

     <t>The IEEE 802 LAN/MAN Standards Committee (SC) develops and maintains
   networking standards and recommended practices for local, metropolitan, and
   other area networks, networks using an open and accredited process, and it advocates
   them on a global basis. The most widely used standards are for Ethernet,
   Bridging and Virtual Bridged LANs LAN, Wireless LAN, Wireless PAN, Personal Area Network (PAN), Wireless MAN,
   Wireless Coexistence, Media Independent Handover Services, and Wireless RAN.
   Radio Access Network (RAN). An individual Working Group working group provides the focus for each area.
   </t>
        <t>
        	The area.</t>

        <t>The IEEE 802.11 Wireless LAN (WLAN) standards define the
        underlying MAC Medium Access Control (MAC) and PHY Physical (PHY) layers for the Wi-Fi technology. 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 <xref target='IEEE80211ax'/> (approved in 2021), 2021) and throughput, latency, and
        reliability enhancements in P802.11be IEEE Std 802.11be <xref target='IEEE80211be'/>
        (approved in 2024).
         </t>
        <t>
        	IEEE 2024).</t>
        <t>IEEE Std 802.11-2012 includes support for TSN time synchronization
        based on IEEE 802.1AS over the 802.11 Timing Measurement
        protocol. IEEE Std 802.11-2016 additionally includes an extension to
        the 802.1AS operation over 802.11 for Fine Timing Measurement (FTM),
        as well as the Stream Reservation Protocol (IEEE 802.1Qat). 802.11
        WLANs can also be part of a 802.1Q bridged networks with enhancements
        enabled by the 802.11ak amendment retrofitted in IEEE Std
        802.11-2020. Traffic classification based on 802.1Q VLAN tags is also
        supported in 802.11. Other 802.1 TSN capabilities such as 802.1Qbv and
        802.1CB, which are media agnostic, can already operate over
        802.11. The IEEE Std 802.11ax-2021 defines additional scheduling
        capabilities that can enhance the timeliness performance in the 802.11
        MAC and achieve lower bounded lower-bounded latency. The IEEE 802.11be has introduced
        introduces features to enhance the support for 802.1 TSN capabilities capabilities,
        especially those related to worst-case latency, reliability reliability, and availability.

	</t>
    <t>
		The
        availability.</t>
	<t>The IEEE 802.11 working group Working Group has been working in collaboration
	with the IEEE 802.1 working group Working Group for several years 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 trade-offs
	between latency and reliability guarantees must be considered as well
	as managed deployment requirements. An overview of 802.1 TSN
	capabilities and challenges for their extensions to 802.11 are
	discussed in <xref target='Cavalcanti_2019'/>.
     		</t>
     		<t> target='Cavalcanti_2019'/>.</t>
	<t>The Wi-Fi Alliance is the worldwide network of companies that drives
	global Wi-Fi adoption and evolution through thought leadership,
	spectrum advocacy, and industry-wide collaboration. The WFA work helps
	ensure that Wi-Fi devices and networks provide users the
	interoperability, security, and reliability they have come to expect.
        	</t>
        	<t> expect.</t>
       	<t>The Avnu Alliance is also a global industry forum developing
       	interoperability testing for TSN capable TSN-capable devices across multiple media
       	including Ethernet, Wi-Fi, and 5G.
		</t>
		<t>
     		The 5G.</t>
	<t>The following IEEE Std 802.11
	specifications/certifications <xref target='IEEE80211'/> specifications/certifications are relevant in the context of reliable
	and available wireless services and support for time-sensitive networking capabilities:
     		</t><dl TSN capabilities:</t>

<!-- [rfced] Should "AIEEE802.11-2016" be updated to "IEEE802.11-2016" (no
"A")? If "AIEEE802.11-2016" is correct, is a reference needed? If so,
please provide it.

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

<ul  spacing='normal'>
            <dt>Time Synchronization:</dt><dd> IEEE802.11-2016
  <li>Time synchronization: IEEE Std 802.11-2016 with IEEE802.1AS; IEEE Std 802.1AS; WFA TimeSync Certification.</dd>
            <dt>Congestion Control:</dt><dd> Certification</li>
  <li>Congestion control: IEEE Std 802.11-2016 Admission Control; WFA Admission Control.</dd>
            <dt>Security:</dt><dd> Control</li>
  <li>Security: WFA Wi-Fi Protected Access, WPA2 WPA2, and WPA3.</dd>
            <dt>Interoperating WPA3</li>
  <li>Interoperating with IEEE802.1Q bridges:</dt><dd> IEEE 802.1Q bridges: IEEE Std 802.11-2020 incorporating 802.11ak.</dd>
            <dt>Stream 802.11ak</li>
  <li>Stream Reservation Protocol (part of <xref target='IEEE8021Qat'/>):</dt><dd> AIEEE802.11-2016</dd>
            <dt>Scheduled target='IEEE8021Qat'/>): AIEEE802.11-2016</li>
  <li>Scheduled channel access:</dt><dd> IEEE802.11ad Enhancements access: IEEE 802.11ad enhancements for very high throughput in the 60 GHz band <xref target='IEEE80211ad'/>.</dd>
            <dt>802.11 target='IEEE80211ad'/></li>
  <li>802.11 Real-Time Applications:</dt><dd> Applications: Topic Interest Group (TIG) ReportDoc <xref target='IEEE_doc_11-18-2009-06'/>.</dd>
          </dl><t>
         </t>

        <t>
        In target='IEEE_doc_11-18-2009-06'/></li>
</ul>

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

<ul spacing='normal'>
        	<dt>IEEE 802.11ax:
  <li><xref target='IEEE80211ax'/>: Enhancements for High Efficiency (HE).</dt><dd><xref target='IEEE80211ax'/></dd>
        	<dt>IEEE 802.11be (HE)</li>
  <li><xref target='IEEE80211be'/>: Extreme High Throughput (EHT).</dt><dd><xref target='IEEE80211be'/></dd>
        	<dt>IEE 802.11ay (EHT)</li>
  <li><xref target='IEEE80211ay'/>: Enhanced throughput for operation in license-exempt bands above 45 GHz.</dt><dd> <xref target='IEEE80211ay'/></dd>
        	</dl><t>
        </t>
     		<t>
     		The GHz</li>
</ul>
     <t>The main 802.11ax, 802.11be, 802.11ad, and 802.11ay capabilities and
     their relevance to RAW are discussed in the remainder of this section.
     As P802.11bn is still in early stages of development, its capabilities
     are not included in this document.
            </t>
        </section> <!-- Provenance and Documents-->
        <section anchor="HE"><name>802.11ax anchor="HE">
	  <name>802.11ax High Efficiency (HE)</name>
        	<section><name>General Characteristics</name>
        		<t>
       	<section>

<!-- [rfced] How may we revise the phrase "to increase efficiency, control and
reduce latency" to clarify how the word "control" should be understood?

Original:

  The next generation Wi-Fi (Wi-Fi 6) is based on the IEEE802.11ax amendment
  [IEEE Std 802.11ax], which includes specific capabilities to increase
  efficiency, control and reduce latency.

Perhaps:

  The next generation Wi-Fi (Wi-Fi 6) is based on the IEEE802.11ax amendment
  [IEEE Std 802.11ax], which includes specific capabilities to increase
  efficiency and to control and reduce latency.

Or:

  The next generation Wi-Fi (Wi-Fi 6) is based on the IEEE802.11ax amendment
  [IEEE Std 802.11ax], which includes specific capabilities to increase
  efficiency and control and to reduce latency.

-->

	<name>General Characteristics</name>
	<t>The next generation Wi-Fi (Wi-Fi 6) is based on the IEEE Std 802.11ax
	amendment <xref target='IEEE80211ax'/>, which includes specific
	capabilities to increase efficiency, control and reduce latency. Some
	of these features include higher order higher-order 1024-QAM modulation, support
	for uplink  multiple user (MU) multiple input multiple output (MIMO), orthogonal frequency-division multiple access Multi-User - Multiple Input Multiple Output (MU-MIMO),
	Orthogonal Frequency-Division Multiple Access (OFDMA), trigger-based access
	access, and Target Wake time Time (TWT) for enhanced power savings. The
	OFDMA mode and trigger-based access enable the AP, Access Point (AP), after reserving the
	channel using the clear channel assessment procedure for a given
	duration, to schedule multi-user transmissions, which is a key
	capability required to increase latency predictability and reliability
	for time-sensitive flows. 802.11ax can operate in up to 160 MHz channels
	channels, and it includes support for operation in the new 6 GHz band,
	which has been open to unlicensed use by the FCC Federal Communications
	Commission (FCC) and other regulatory agencies worldwide.
        			</t>
        		<section><name>Multi-User worldwide.</t>
	<section>
	  <name>Multi-User OFDMA and Trigger-based Trigger-Based Scheduled Access</name>
        			<t>
        				802.11ax
          <t>802.11ax introduced an OFDMA mode in which multiple users can be
          scheduled across the frequency domain. In this mode, the Access
          Point (AP) can initiate multi-user (MU) Uplink 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) (BSS), and it can
          remove contention between associated stations for uplink
          transmissions, therefore reducing the randomness caused by CSMA-based access based on Carrier
          Sense Multiple Access (CSMA) between stations within
          the same BSS. The AP can also transmit simultaneously to multiple
          users in the downlink direction by using a Downlink downlink (DL) MU OFDMA
          PPDU. In order to initiate a contention free contention-free Transmission
          Opportunity (TXOP) using the OFDMA mode, the AP still follows the
          typical listen before talk 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 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.
        			</t>
          BSS.</t>
	</section> <!--Multi-User OFDMA and Trigger-based Scheduled Access -->

                  		<section><name>Traffic

	<section>
	  <name>Traffic Isolation via OFDMA Resource Management and Resource Unit Allocation</name>
<t>

 802.11ax
	  <t>802.11ax relies on the notion of an OFDMA Resource Unit (RU) to
	  allocate frequency chunks to different STAs stations 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 station. While this does not support
	  time-aware scheduling, scheduling per se, it is a key aspect to assist
	  reliability, as it provides traffic isolation in a shared medium.
	  </t>
                  		</section><!-- Traffic Isolation via OFDMA Resource Management and Resource Unit -->
        		<section><name>Improved
	</section>
	<section>
	  <name>Improved PHY Robustness</name>
        			<t>
        				The
	  <t>The 802.11ax PHY can operate with a 0.8, 1.6 1.6, or 3.2 microsecond guard interval
	  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 of operating with smaller resource units (e.g. RUs
	  (e.g., 2 MHz) enabled by OFDMA also helps reduce noise power and
	  improve SNR, Signal-to-Noise Ratio (SNR), leading to better packet error rate Packet Error Rate (PER) performance.
        			</t>
        			<t>
        				802.11ax performance.</t>
	  <t>802.11ax supports beamforming as in 802.11ac, 802.11ac but introduces UL MU MIMO,
	  MU-MIMO, which helps improve reliability. The UL MU MIMO MU-MIMO capability
	  is also enabled by the trigger based trigger-based access operation in 802.11ax.
        				</t> 802.11ax.</t>
	</section> <!-- Improved PHY Robustness -->
     	<section><name>Support for 6GHz 6 GHz Band</name>
        				<t>
        					The
	<t>The 802.11ax specification <xref target='IEEE80211ax'/> includes
	support for operation in the 6 GHz band. Given the amount of new
	spectrum available available, as well as the fact that no legacy 802.11 device
	(prior 802.11ax) will be able to operate in this band, 802.11ax
	operation in this new band can be even more efficient.
        					</t> efficient.</t>
	</section> <!-- Support for 6GHz band -->
       	</section> <!-- General Characteristics-->

        <section><name>Applicability to Deterministic Flows</name>
        	<t>
        		TSN
       	<t>TSN capabilities, as defined by the IEEE 802.1 TSN standards,
       	provide the underlying mechanism for supporting deterministic flows in
       	a Local Area Network (LAN). The IEEE 802.11 working group Working Group has incorporated
       	support for absolute time synchronization to extend the TSN 802.1AS
       	protocol so that time-sensitive flow flows can experience precise time
       	synchronization when operating over 802.11 links. As IEEE 802.11 and
       	IEEE 802.1 TSN are both based on the IEEE 802 architecture, 802.11
       	devices can directly implement some TSN capabilities without the need
       	for a gateway/translation protocol. Basic features required for
       	operation in a 802.1Q LAN are already enabled for 802.11. Some TSN
       	capabilities, such as 802.1Qbv, can already operate over the existing
       	802.11 MAC SAP <xref target='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 <xref target='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 <xref
       	target='Cavalcanti1287'/>.
                </t><t>
                TSN
                </t>
		<t>TSN capabilities supported over 802.11 (which also extends to 802.11ax), include:
        		</t> 802.11ax) include:</t>
                <ol type='%d.'>
        		<li> 802.1AS based Time Synchronization type='1'>
        	  <li>802.1AS-based time synchronization (other time synchronization techniques may also be used) </li>
        		<li> Interoperating
        	  <li>Interoperating with IEEE802.1Q IEEE 802.1Q bridges</li>
        		<li> Time-sensitive Traffic Stream Classification</li>
        	  <li>Time-sensitive traffic stream classification</li>
        	</ol>
        	<t>
        			The
        	<t>The existing 802.11 TSN capabilities listed above, and the
        	802.11ax OFDMA and AP-controlled access within a BSS BSS, provide a
        	new set of tools to better serve time-sensitive
        	flows. However, it is important to understand the tradeoffs trade-offs
        	and constraints associated with such capabilities, as well as
        	redundancy and diversity mechanisms that can be used to
        	provide more predictable and reliable performance.
        	</t>
        	<section><name> 802.11
        	<section><name>802.11 Managed Network Operation and Admission Control</name>
        	<t>
        		Time-sensitive
        	<t>Time-sensitive applications and TSN standards are expected
        	to operate in a managed network (e.g. (e.g., an industrial/enterprise
        	network). This enables to carefully manage careful management and integrate integration of the
        	Wi-Fi operation with the overall TSN management framework, as
        	defined in the <xref target='IEEE802.1Qcc'/> specification. target='IEEE802.1Qcc'/>.
        	</t>
         	<t>
        		Some
         	<t>Some of the random-access latency and interference from
         	legacy/unmanaged devices can be reduced under a centralized
         	management mode as defined in <xref target='IEEE802.1Qcc'/>.
        	</t>
        	<t>
        		Existing
        	<t>Existing traffic stream identification, configuration configuration, and
        	admission control procedures defined in <xref target='IEEE80211'/> the QoS mechanism in <xref
        	target='IEEE80211'/> can be re-used. reused. However,
        	given the high degree of determinism required by many
        	time-sensitive applications, additional capabilities to manage
        	interference and legacy devices within tight time-constraints time constraints
        	need to be explored.
        	</t> explored.</t>
        	</section>

<!-- 802.11 Managed [rfced] Would you like to update the following long sentence to be a
bulleted list? Or do you prefer the original?

Original:

   Such flexibility can be leveraged to support time-sensitive applications
   with bounded latency, especially in a managed network operation 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 admission 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.

Perhaps:

   Such flexibility can be leveraged to support time-sensitive applications
   with bounded latency, especially:

   * in a managed network where stations can be configured to operate under the
   control of the AP,

   * in a controlled environment (which contains only devices operating on the
   unlicensed band installed by the facility owner and where unexpected
   interference from other systems and/or radio access technologies only
   sporadically happens), or

   * in a deployment where channel and link redundancy is used to reduce the
   impact of unmanaged devices and interference.

-->
        	<section><name>Scheduling

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

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

      	<t>The flexibility to dynamically assign RUs to each transmission also
      	enables the AP to provide frequency diversity, which can help increase reliability.
        	</t>
      	reliability.</t>
       	</section>
        </section> <!--Scheduling for bounded latency and diversity-->
        </section> <!-- Applicability to deterministic flows -->
        </section><!-- 802.11ax High Efficiency (HE)   -->

     <section anchor="EHT"><name>802.11be anchor="EHT">
       <name>802.11be Extreme High Throughput (EHT)</name>

        	<section><name>General Characteristics</name>
        		<t>
        			The <xref
       		<t><xref target='IEEE80211be'/>  ammendment was the next
       		major 802.11 amendment (after IEEE Std 802.11ax-2021) for
       		operation in the 2.4, 5 5, and 6 GHz bands. 802.11be includes new
       		PHY and MAC features features, and it is targeting extremely high
       		throughput (at least 30 Gbps), as well as enhancements to worst case
       		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.
        			</t>
        		<t>

					The 802.11be LANs.</t>
       		<t>The main features of 802.11be that are relevant to this document include:
        			</t><ol type='%d.'>
        				<li> 320MHz include:</t>
		<ol type='1'>
       		  <li>320 MHz bandwidth and more efficient utilization of non-contiguous spectrum. </li>
        				<li> Multi-link operation. </li>
        				<li> QoS spectrum</li>
       		  <li>Multi-Link Operation (MLO)</li>
       		  <li>QoS enhancements to reduce latency and increase  reliability. </li>
        			</ol><t>
        		</t> reliability</li>
       		</ol>
        	</section>

<!-- General Characteristics-->
        	<section><name>Applicability [rfced] How may we clarify "and potential solution directions"?

Original:
   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.

Perhaps:
   The 802.11 Real-Time Applications (RTA) Topic Interest Group (TIG)
   provided detailed information on use cases, issues, and a potential
   solution to improve support for time-sensitive
   applications in 802.11.
-->

        	<section>
		  <name>Applicability to Deterministic Flows</name>
        		<t>
        			The
       		  <t>The 802.11 Real-Time Applications (RTA) Topic Interest
       		  Group (TIG) provided detailed information on use cases, issues
       		  issues, and potential solution directions to improve support
       		  for time-sensitive applications in 802.11. The RTA TIG
       		  report <xref target='IEEE_doc_11-18-2009-06'/> was used as
       		  input to the 802.11be project scope.
        		</t>
        		<t>
        			Improvements scope.</t>

       		  <t>Improvements for worst-case latency, jitter jitter, and
       		  reliability were the main topics identified in the RTA
       		  report, which were motivated by applications in gaming,
       		  industrial automation, robotics, etc. The RTA report also
       		  highlighted the need to support additional TSN capabilities,
       		  such as time-aware (802.1Qbv) shaping and packet replication
       		  and elimination as defined in 802.1CB.
        		</t>
        		<t>
        			IEEE
        		<t>IEEE Std 802.11be builds on and enhances 802.11ax
        		capabilities to improve worst case latency and
        		jitter. Some of the enhancement areas are discussed next.
        			</t>
        		<section><name>Enhanced
        		next.</t>

			<section>
			<name>Enhanced Scheduled Operation for Bounded Latency </name>
        			<t>
        				In Latency</name>
       			<t>In addition to the throughput enhancements,
       			802.11be leverages the trigger-based scheduled
       			operation enabled by 802.11ax to provide efficient and
       			more predictable medium access.
        		</t>
        		<t>

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

        				</t> flows.</t>
        		</section> <!-- Enhanced scheduled operation for bounded latency -->

        		<!--section><name>Multi-AP Coordination</name>
        			<t>
        				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.

	       			</t>

<t> 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).
	       			</t>

     			<t> 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).   			</t>
        		</section>  Multi-AP coordination -->

        		<section><name>Multi-link operation</name>
        			<t>
        				802.11be

      	<section>
	  <name>Multi-Link Operation</name>
	  <t>802.11be introduces new features to improve operation over
	  multiple links and channels. By leveraging multiple links/channels, links and channels,
	  802.11be can isolate time-sensitive traffic from network congestion,
	  one of the main causes of large latency variations. In a managed
	  802.11be network, it should be possible to steer traffic to certain links/channels
	  links and channels to isolate time-sensitive traffic from other traffic
	  and help achieve bounded latency.  The multi-link operation Multi-Link Operation (MLO) is
	  a major feature in the 802.11be amendment that can enhance latency
	  and reliability by enabling data frames to be duplicated across links.
        			</t>
	  links.</t>
    	</section> <!--Multi-link operation-->
      </section>
        </section><!-- 802.11be Extreme High Throughput (EHT)  -->

        <section><name>802.11ad
    </section>

    <section>
      <name>802.11ad and 802.11ay (mmWave operation)</name>
        	<section><name>General Operation)</name>
      <section>
	<name>General Characteristics</name>
        		<t>
        			The
        <t>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 <xref target='Nitsche_2015'/>.
        		</t>
        		<t>
        			The
        target='Nitsche_2015'/>.</t>
	<t>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 access, and
	beamforming training. An overview of the 802.11ay capabilities can be
	found in <xref target='Ghasempour_2017'/>.
        			</t>
        	</section><!--General Characteristics -->
        	<section><name>Applicability target='Ghasempour_2017'/>.</t>
      </section>

      <section>
	<name>Applicability to deterministic flows</name>
        		<t>
        			The high data Deterministic Flows</name>
        <t>The high-data rates achievable with 802.11ad and 802.11ay can
        significantly reduce latency down to microsecond levels. Limited
        interference from legacy and other unlicensed devices in 60 GHz is
        also a benefit. However, the directionality and short range typical in
        mmWave operation impose new challenges such as the overhead required
        for beam training and blockage issues, which impact both latency and
        reliability. Therefore, it is important to understand the use case and
        deployment conditions in order to properly apply and configure
        802.11ad/ay networks for time sensitive applications.
        		</t>
        		<t>
        			The time-sensitive applications.</t>
	<t>The 802.11ad standard includes a scheduled access mode in which the
	central controller, after contending and reserving the channel for a
	dedicated period, can allocate to stations contention-free service
	periods. This scheduling capability is also available in 802.11ay, and
	it is one of the mechanisms that can be used to provide bounded
	latency to time-sensitive data flows in interference-free
	scenarios. An analysis of the theoretical latency bounds that can be
	achieved with 802.11ad service periods is provided in <xref
	target='Cavalcanti_2019'/>.
        </t>
      </section> <!-- Applicability to deterministic flows-->
        </section><!-- 802.11ad and 802.11ay (mmWave operation)  -->

   </section><!-- title="IEEE 802.11" -->
    </section>
  </section>

   <section><name>IEEE 802.15.4 Timeslotted Time-Slotted Channel Hopping </name>

      <t> IEEE (TSCH)</name>

      <t>IEEE Std 802.15.4 TSCH was the first IEEE radio specification aimed
      directly at Industrial industrial IoT applications, for use in
	  Process Control process control
      loops and monitoring. It was used as a base for the major industrial
      wireless process control standards, Wireless HART Highway Addressable Remote
      Transducer Protocol (HART) and ISA100.11a.
	  </t><t>
	  While
      </t>
      <t>While the MAC/PHY standards enable the relatively slow rates used in Process
	  Control
      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
      factory automation and motion control.
	  </t>

   <section><name>Provenance control (1 to 10 ms).</t>

   <section>
     <name>Provenance and Documents</name>
   <t>
   The IEEE802.15.4
   <t>The IEEE 802.15.4 Task Group has been driving the development of low-power
   low-power, low-cost radio technology.  The IEEE802.15.4 IEEE 802.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 sub-GHz Industrial, Scientific and
   Medical (ISM) bands. This has imposed requirements in terms of frame size,
   data rate 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 IEEE 802.15.4 uses spread spectrum
   modulation such as the Direct Sequence Spread Spectrum (DSSS).
   </t>

   <t>
   The Timeslotted Time-Slotted Channel Hopping (TSCH) mode was added to the 2015 revision of
   the IEEE802.15.4 IEEE 802.15.4 standard <xref target='IEEE802154'/>. TSCH is
   targeted at the embedded and industrial world, where reliability, energy
   consumption
   consumption, and cost drive the application space.
   </t>

   <!--  TSN-like activities, past and present (introduce the likes of as OFDMA, URLLC and EHT) -->
   <t>
   Time sensitive networking
   Building on low power IEEE 802.15.4, TSN on low-power constrained wireless networks, building on IEEE802.15.4,
   have networks
   has been partially addressed by ISA100.11a <xref target='ISA100.11a'/> and WirelessHART
   <xref target='WirelessHART'/>. Both technologies
   involve a central controller that computes redundant paths for industrial
   process control traffic over a TSCH mesh. Moreover, ISA100.11a introduces
   IPv6 capabilities <xref target='RFC8200'/> capabilities with a Link-Local Address link-local address for the join process and a
   global unicast address for later exchanges, but the IPv6 traffic typically
   ends at a local application gateway and the full power of IPv6 for end-to-end
   communication is not enabled.
   </t>

   <t>
   At the IETF, the 6TiSCH working group Working Group <xref target='TiSCH'/> has
   enabled distributed routing and scheduling to exploit the deterministic
   access capabilities provided by TSCH for IPv6. The group designed the essential
   mechanisms, the 6top layer 6TiSCH Operation (6top) sublayer and the Scheduling Functions (SFs), to enable
   the management plane operation while ensuring IPv6 is
   supported:
   supported.
   </t>
   <ul>
   <li>
   </li><li>
   The
     <li>The 6top Protocol (6P) is defined in <xref target='RFC8480'/>.
   The 6P Protocol target='RFC8480'/> and
     provides a pairwise negotiation mechanism to the control plane operation.
     The protocol supports agreement on a schedule between neighbors, enabling
     distributed scheduling.
   </li><li>6P scheduling.</li>
     <li>6P goes hand-in-hand hand in hand with an SF, the policy that decides how to
     maintain cells and trigger 6P transactions. The Minimal Scheduling Function
     (MSF) <xref target='RFC9033'/> is the default SF defined by the 6TiSCH WG.
   </li><li>With
     WG.</li>
<!-- [rfced] We were unable to find RPL explicitly mentioned in RFC
8480. Should this citation be updated? Perhaps to [RFC6550]?

Original:

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

     <li>With these mechanisms mechanisms, 6TiSCH can establish layer Layer 2 links between neighbouring
     neighboring nodes and support best effort best-effort traffic. RPL The Routing Protocol for Low-Power and Lossy Networks (RPL) <xref
     target='RFC8480'/> provides the routing structure, enabling the 6TiSCH
     devices to establish the links with well connected neighbours and well-connected neighbors, thus
     forming the acyclic network graphs.
   </li> graphs.</li>
   </ul>
   <t>
<!-- [rfced] In the two instances below, may we update "the application to
wireless" to "applied to" as follows? Also, should these sentences be
more closely aligned? In particular, should the phrases "concept of a
recovery graph in the RAW architecture" and "concept of a DetNet
architecture protection path applied to 6TiSCH networks" be aligned?

Original:

   A Track at 6TiSCH is the application to wireless of the concept of a
   Recovery Graph in the RAW architecture.
   ...
   A Track in the 6TiSCH Architecture [RFC9030] is the application to
   6TiSCH networks of the concept of a protection path in the "Detnet
   architecture" [RFC8655].

Perhaps:

   In 6TiSCH, a Track is the concept of a recovery graph in the RAW
   architecture applied to wireless.
   ...
   In the 6TiSCH architecture [RFC9030], a Track is the concept of a DetNet
   architecture protection path applied to 6TiSCH networks.
-->

   <t>
   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 nodes, or it can be structured as a
   more complex Destination Oriented 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 Layer 2 forwarding schemes, reducing the overhead of taking making
   routing decisions at the Layer-3. Layer 3.
   </t>

     <!--  DetNet-like arching art (introduce the likes of ISA100.11a or WiHART) -->
   <t>
   The 6TiSCH architecture <xref target='RFC9030'/>
   identifies different models to schedule resources along so-called Tracks
   (see <xref target='Tracks'/>) target='Tracks'/>), exploiting the
   TSCH schedule structure however structure; however, the focus at in 6TiSCH is on best effort traffic best-effort traffic,
   and the group was never chartered to produce standard standards work related to Tracks.
   </t>

   <t>
   There are several works that can be used to complement the overview provided in this document.
   For example example, <xref target='vilajosana21'/> provides a detailed description of the 6TiSCH protocols,
   how they are linked together together, and how they are integrated with other standards like RPL and 6Lo.
   <!--
   <xref target='morell13'/> introduces how label switching can be implemented in a TSCH network.
   It proposes a policy to distribute labels in multihop network so as to enable differential services
   through the network paths. <xref target='dearmas16'/> presents an approach to improve network reliability
   at layer 3, considering and IEEE802.15.4 TSCH network and exploiting packet replication and path diversity
   for that aim.-->
   </t>

   </section><!--Provenance
   </section>

<!-- [rfced] FYI - We have added the verb "occurs" for clarity in the text
below. Please review.

Original:

   Each device has its own perspective of when the send or receive and Documents--> on
   which channel the transmission happens.

Current:

   Each device has its own perspective of when the send or receive occurs and
   on which channel the transmission happens.

-->

   <section><name>General Characteristics</name>
   <t>
   As a core technique in IEEE802.15.4, IEEE 802.15.4, TSCH splits time in multiple time slots
   that repeat over time. Each device has its own perspective of when the send or receive occurs and
   on which channel the transmission happens. This constitutes
   the device's Slotframe 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 (see more in <xref target='slotFrames'/>).
   </t>

   <t>
   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, neighbors and is managed by a
   Scheduling Function such as the Minimal Scheduling Function (MSF) <xref
   target='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 that maps to a frequency at
   each iteration of the slotframe. Each packet exchanged between neighbors
   happens within one cell. The size of a cell is a timeslot duration, between
   10 to 15 milliseconds. An Absolute Slot Number (ASN) indicates the number
   of slots elapsed since the network started. It increments at every
   slot. This is a 5-byte counter that can support networks running for more
   than 300 years without wrapping (assuming a 10-ms 10 ms timeslot). Channel
   hopping provides increased reliability to multi-path multipath fading and external
   interference. It is handled by TSCH through a channel hopping channel-hopping sequence
   referred to as macHopSeq in the IEEE802.15.4 IEEE 802.15.4 specification.
   </t>

   <t>
   <!-- bandwidth, beam forming-->
    The Time-Frequency Division Multiple Access provided by TSCH enables the
    orchestration of traffic flows, spreading them in time and frequency,
    and hence enabling an efficient management of the bandwidth utilization.
    Such efficient bandwidth utilization can be combined with OFDM modulations
    also supported by the IEEE802.15.4 IEEE 802.15.4 standard <xref target='IEEE802154'/>
    since the 2015 version.
   </t>

<!-- [rfced] How may we revise "at the MAC introducing" to increase clarity?

Original:

   Part of these reliability challenges are addressed at the MAC
   introducing redundancy and diversity, thanks to channel hopping,
   scheduling and ARQ policies.

Perhaps:

   Part of these reliability challenges are addressed at the MAC layer by
   introducing redundancy and diversity, thanks to channel hopping,
   scheduling, and ARQ policies.

-->

   <t>
   <!-- spectrum -->
    TSCH networks operate in ISM bands in which the spectrum is shared by
    different coexisting technologies.  Regulations such as the FCC, ETSI ETSI, and
    ARIB impose duty cycle regulations to limit the use of the bands bands, but yet
    interference may constraint still constrain the probability to deliver of delivering a packet.  Part of
    these reliability challenges are addressed at the MAC introducing
    redundancy and diversity, thanks to channel hopping, scheduling scheduling, and ARQ
    policies.  Yet, the MAC layer operates with a 1-hop vision, being limited
    to local actions to mitigate underperforming links.
    <!-- Pascal-> not sure if you want to mention here about the capability provided by RAW to determine the best path regardless of the performance of a particular link -->
   </t>

   <section anchor='Tracks'><name>6TiSCH Tracks</name>

   <t>
   A Track in the 6TiSCH Architecture architecture <xref target='RFC9030'/> is the
   application to 6TiSCH networks of the concept of a protection path in the DetNet architecture <xref target='RFC8655'>"Detnet architecture"</xref>. target='RFC8655'/>.  A Track can be
   structured as a Destination Oriented 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 Layer 2 forwarding schemes,
   reducing the overhead of taking making routing decisions at the Layer-3. Layer 3.
   </t>
   <t>
   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, topology; see more in <xref target='fwd'/> on how that is used
   in the data plane to forward packets.
   </t>
   <t>
   Whereas scheduling ensures reliable delivery in bounded time along any Track,
   high availability requires the application of PREOF functions along a more
   complex DODAG Track structure. A DODAG has forking and joining nodes where
   the
   concepts such as Replication like replication and Elimination elimination can be exploited.
   Spatial redundancy increases the overall energy consumption in the network but
   improves
   significantly improves the availability of the network as well as the packet
   delivery ratio.

   A Track may also branch off and rejoin, for the purpose of the so-called
   Packet Replication and Elimination (PRE), over non congruent non-congruent branches.  PRE
   may be used to complement layer-2 Layer 2 ARQ and receiver-end Ordering ordering to
   complete/extend the PREOF functions. This enables meeting industrial
   expectations of packet delivery within bounded delay over a Track that
   includes wireless links, even when the Track extends beyond the 6TiSCH
   network.
      </t>
   <t>The RAW Track described in the RAW Architecture architecture <xref target='I-D.ietf-raw-architecture'/> target='RFC9912'/>
   inherits directly from that model.  RAW extends the graph beyond a DODAG as
   long as a given packet cannot loop within the Track.
   </t> Track.</t>
         <figure anchor='fig4'><name>End-to-End deterministic Deterministic Track</name>
	 <artwork><![CDATA[
                  +-----+
                  | IoT |
                  | G/W |
                  +-----+
                     ^  <---- Elimination
                    | |
     Track branch   | |
            +-------+ +--------+ Subnet Backbone 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
]]></artwork>
   </figure>
      <t>In the example above (see <xref target='fig4'/>), target='fig4'/>, a Track is laid out
      from a field device in a 6TiSCH network to an IoT gateway that is located
      on a IEEE802.1 an IEEE 802.1 TSN backbone.
      </t>
      <t>
      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.
      </t>
      <t>
      At each 6TiSCH hop along the Track, the PCE may schedule more than one
      timeSlot for a packet, so as to support Layer-2 Layer 2 retries (ARQ). It is also
      possible that for the field device to only uses use the second branch if sending over
      the first branch fails.
      </t>
      <t>
      In current deployments, a TSCH Track does not necessarily support PRE but
      is systematically multi-path. multipath. This means that a Track is scheduled so as
      to ensure that each hop has at least two forwarding solutions, and the
      forwarding decision is to try the preferred one and use the other in
      case of Layer-2 Layer 2 transmission failure as detected by ARQ.
         </t>
           <t>Methods to implement complex Tracks are described
   in <xref target='I-D.ietf-roll-dao-projection'/> target='RFC9914'/> and complemented by
   extensions to the RPL routing protocol in
   <xref target='I-D.ietf-roll-nsa-extension'/> for best effort best-effort traffic, but a
   centralized routing technique such as one promoted in DetNet is still missing.
      </t>
     <section anchor='Tschd'><name>Track anchor='Tschd'>
       <name>Track Scheduling Protocol</name>
      <t>
         Section "Schedule Management Mechanisms"
     <t>Section <xref section="4.4" sectionFormat="bare" target="RFC9030"/> of
     the 6TiSCH architecture <xref target="RFC9030"/> describes 4 four
     approaches to manage the TSCH schedule of the LLN Low-Power and Lossy Network (LLN) nodes:
         Static Scheduling, static
     scheduling, neighbor-to-neighbor Scheduling, scheduling, remote monitoring and
     scheduling management, and Hop-by-hop hop-by-hop scheduling.  The Track operation
     for DetNet corresponds to a remote monitoring and scheduling management
     by a PCE.
      </t>
   </section>

   <section anchor='fwd'><name>Track Forwarding</name>
      <t>
         By forwarding,
      <t>In the 6TiSCH Architecture architecture <xref target='RFC9030'/> means target='RFC9030'/>, forwarding is
      the per-packet operation that allows delivering a packet to be delivered to a next hop
      or an upper layer in this a node.  Forwarding is based on pre-existing preexisting
      state that was installed as a result of the routing computation of a
      Track by a PCE.  The 6TiSCH architecture supports three different
      forwarding model,
         G-MPLS models: GMPLS Track Forwarding (TF), 6LoWPAN Fragment
      Forwarding (FF) (FF), and IPv6 Forwarding (6F) (6F), which is the classical IP
      operation <xref target='RFC9030'/>. The DetNet case relates to the
      Track Forwarding operation under the control of a PCE.
      </t>
         <t>
            A Track is a unidirectional path between a source and a destination.
            Time/Frequency
            Time and frequency resources called cells (see <xref target='slotFrames'/>)
            are allocated to enable the forwarding operation along the Track.
            In a Track cell, the normal operation of IEEE802.15.4 IEEE 802.15.4
            ARQ usually happens, though the
            acknowledgment may be omitted in some cases, for instance instance, if there
            is no scheduled cell for a retry.
         </t>

<!-- [rfced] Should "simplest and fastest" be updated to "simplest and fastest
operation" (or something similar)?

Original:
  Track Forwarding is the simplest and fastest.

Perhaps:
  Track Forwarding is the simplest and fastest operation.
-->

         <t>
            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 Layer 2 forwarding state that
            can be used regardless of the network layer network-layer protocol.  This model
            can effectively be seen as a Generalized Multi-protocol Multiprotocol Label
            Switching (G-MPLS) (GMPLS) operation in that the information used to
            switch a frame is not an explicit label, label but is rather related to
            other properties of about the way the packet was received, a received (a particular cell
            cell, in the case of 6TiSCH. 6TiSCH).  As a result, as long as the TSCH
            MAC (and Layer-2 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.
         </t>

<!-- [rfced] Will "this means effectively broadcast" be clear to readers?

Original:
   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.

Perhaps:
   In the case of
   IEEE 802.15.4, this effectively means that the address is broadcast,
   so that the short address for the destination of the frame is set to
   0xFFFF along the Track.
-->

         <t>
            A data frame that is forwarded along a Track normally has
            a destination MAC address that is set to broadcast -
            or
            (or a multicast address address, depending on MAC support. support).
            This way, the MAC layer in the intermediate nodes accepts the
            incoming frame frame, and 6top switches it without incurring a change in
            the MAC header. In the case of IEEE802.15.4, IEEE 802.15.4, this means effectively
            broadcast, so that along the Track the short address for the
            destination of the frame is set to 0xFFFF. 0xFFFF along the Track.
         </t>
         <t>
            A Track is thus formed end-to-end end to end as a succession of paired bundles,
            bundles: a receive bundle from the previous hop and a transmit
            bundle to the next hop along the Track, and a Track. A cell in such a
            bundle belongs to
            at most one Track. Track at most.  For a given iteration of the
            device schedule, the effective channel of the cell is obtained by
            adding a pseudo-random pseudorandom number to the channelOffset of the cell,
            which results in a rotation of the frequency that was used for
            transmission.  The bundles may be computed so as to accommodate
            both variable rates and retransmissions, so they might not be
            fully used at a given iteration of the schedule.  The 6TiSCH
            architecture provides additional means to avoid waste of cells as
            well as overflows in the transmit bundle, as follows: described in the following paragraphs.
         </t>

         <t>
            In
            On one hand, a TX-cell that is not needed for the current iteration
            may be reused opportunistically on a per-hop basis for routed
            packets.
            When all of the frame frames that were received for a given Track are
            effectively transmitted, any available TX-cell for that Track
            can be reused for upper layer 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 an RX-cell of a Track
            with a destination MAC address set to this node as opposed to
            broadcast must be extracted from the Track and delivered to the
            upper layer (a frame with an unrecognized MAC address is dropped at
            the lower MAC layer and thus is not received at the 6top sublayer).
         </t>
         <t>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 instance, if more retransmissions are needed than provisioned.
            In that case, the frame can be placed for transmission in the
            bundle that is used for layer-3 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 Layer 3 bundle may
            be in fact associated with a Track. In a classical IP link such as an
            Ethernet, off-Track traffic is typically in excess over reservation
            to be routed along the non-reserved path based on its QoS setting.
            But
            However, with 6TiSCH, since the use of the layer-3 Layer 3 bundle may be due to
            transmission failures, it makes sense for the receiver to recognize
            a frame that should be re-Tracked, re-Tracked and to place it back on the
            appropriate bundle if possible.
            A frame should be re-Tracked if the Per-Hop-Behavior per-hop-behavior
            group indicated in the Differentiated Services Field field in the
            IPv6 header is set to Deterministic Forwarding, deterministic forwarding, as discussed in
            <xref target='pmh'/>.
            A frame is re-Tracked by scheduling it for transmission over the
            transmit bundle associated with the Track,
            with the destination MAC address set to broadcast.
         </t>

         <section><name>OAM</name>
            <t>

	        <xref target='RFC7276'> "An

         <section>
	   <name>OAM</name>
            <t>"An Overview of Operations, Administration, and Maintenance (OAM) Tools"</xref> Tools" <xref target='RFC7276'/> provides an
            overview of the existing tooling for OAM <xref target='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).
            </t>
            <t>
            An example of such tooling can be found in the context of Bit Index Explicit Replication (BIER)
            <xref target='RFC8279'>BIER</xref> and target="RFC8279"/> and, more specifically
            <xref target='RFC9262'>BIER specifically, BIER Traffic Engineering</xref>
            (BIER-TE).
            Engineering (BIER-TE) <xref target="RFC9262"/>.</t>

			<!--
            removed based on MB's review
            <xref target='I-D.thubert-bier-replication-elimination'/>
            leverages BIER-TE to control the process of PREF, and to provide
            traceability of these operations, in the deterministic dataplane,
            along a complex Track.
            -->
			<!--
            For the 6TiSCH type of constrained environment,
            <xref target='I-D.thubert-6lo-bier-dispatch'/> enables an efficient
            encoding of the BIER bitmap within the 6LoRH framework.
            -->
			</t>

   </section>
   </section>

   </section> <!-- 6TiSCH Tracks  -->

   </section> <!-- General Characteristics  -->
   <section><name>Applicability to Deterministic Flows</name>
   <t>

<!-- [rfced] Please clarify "to trade-off performance to reliability". Does
the suggested text below convey the intended meaning?

Original:
   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.

Perhaps:
   As a low-power
   technology targeting industrial scenarios, radio transducers provide
   low data rates (typically between 50 kbps to 250 kbps) and robust
   modulations to trade off performance for reliability.
-->

   <!-- expected capabilities for safety and automation, e.g., loops per second -->
    In the RAW context, low power low-power reliable networks should address
    non-critical control scenarios such as Class 2 and monitoring scenarios
    such as Class 4 4, as defined by the RFC5673 <xref target='RFC5673'/>.  As a low power low-power
    technology targeting industrial scenarios scenarios, radio transducers provide
    low data rates (typically between 50kbps 50 kbps to 250kbps) 250 kbps) 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.
   </t>

<!-- [rfced] Should "tight control to latency" be updated to "tight control of
latency" (i.e., "of" rather than "to")? Or is the current okay?

Original:
  This provides a tight control to latency along a Track.

Perhaps:
  This provides a tight control of latency along a Track.
-->

   <t>
    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 blocks, reserving the needed capacity to certain
    flows.  Periodic and bursty traffic can be handled independently in the
    schedule, using active and reactive policies and taking advantage of
    overprovisioned cells. Along a Track (see <xref target='Tracks'/>, target='Tracks'/>), 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 best-effort traffic by
    overprovisioning resources, giving time to the management plane of the
    network to dedicate more resources if needed. needed.</t>

      <!--

     -time synchronization
     - scheduling capabilities, discuss such things as Resource Units, time slots or resource blocks.
       Can we reserve periodic resources vs. ask each time, what precision can we get in latency control.
     - diversity scenarios, what's available,
     - gap analysis, e.g. discuss multihop, or what's missing how to do PREOF features.
     -->
   </t>

      <section anchor='detnet'><name>Centralized Path Computation</name>

<!-- [rfced] How may we update the the text starting with "in particular..."
to clarify what is provided to a PCE?

Original:
   Rather, an Operation Control System
   (OCS) invoked through a Human/Machine Interface (HMI) provides the
   Traffic Specification, in particular in terms of latency and
   reliability, and the end nodes, to a PCE.

Perhaps:
   Rather, an Operation Control System
   (OCS) invoked through a Human/Machine Interface (HMI) provides the
   traffic specification (in particular, in terms of latency and
   reliability) and the end nodes to a PCE.

Or:
   Rather, an Operation Control System
   (OCS) invoked through a Human/Machine Interface (HMI) provides the
   traffic specification (in particular, in terms of latency,
   reliability, and the end nodes) to a PCE.
-->

   <t>
   When considering end-to-end communication over TSCH, a 6TiSCH device
   usually does not place a request for bandwidth between itself and another
   device in the network.  Rather, an Operation Control System (OCS) invoked
   through a Human/Machine Human-Machine Interface (HMI) provides the Traffic Specification, traffic specification,
   in particular particular, in terms of latency and reliability, and the end nodes, to a
   PCE.  With this, the PCE computes a Track between the end nodes and
   provisions every hop in the Track with per-flow state that describes the
   per-hop operation for a given packet, the corresponding timeSlots, and the
   flow identification to recognize which packet is placed in which Track,
   sort out duplicates, etc.  An example of Operational Control System an OCS and HMI
   is depicted in <xref target='NorthSouth'/>.
   </t>
   <t>
   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 architecture expects that the programing programming of the schedule
   is done over the Constrained Application Protocol (CoAP) such as discussed in <xref target='I-D.ietf-6tisch-coap'>"6TiSCH
   Resource Management and Interaction using CoAP"</xref>. target='I-D.ietf-6tisch-coap'/>.
   </t>
<!-- [rfced] Will readers understand "(to be)" in this sentence? Should it be
removed or clarified?

Original:
   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.

Perhaps (remove "to be"):
   For that case, the
   expectation is that a protocol that flows along a Track, in a
   fashion similar to classical Traffic Engineering (TE) [CCAMP], may be
   used to update the state in the devices.
-->

   <t>
   But an
   However, a Hybrid mode may be required as well well, whereby a single Track is added,
   modified, or removed, for instance removed (for instance, if it appears that a Track does not
   perform as expected. 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)
   <xref target='CCAMP'/>, may be used to update the state in the devices.
   In general, that flow was not designed designed, and it is expected that DetNet will determine the appropriate
   end-to-end protocols to be used in that case.
   </t>

<t keepWithNext='true'>Stream

<!-- [rfced] What is meant by "Stream Management Entity</t><figure Entity" above Figure 2? Should
this be expanded into a complete sentence or handled in some other way?
-->

<t>Stream Management Entity</t>
<figure align='center' anchor='NorthSouth'>
<name>Architectural Layers</name>
    <artwork align='left'><![CDATA[
                      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--
]]></artwork>
</figure>

   <section anchor='pmh'><name>Packet Marking and Handling</name>
   <t>
   Section "Packet Marking and Handling" of
   <xref target='RFC9030'/> target='RFC9030' section="4.7.1"/> describes the packet tagging and
   marking that is expected in 6TiSCH networks.
   </t>
   <section anchor='pmhft'><name>Tagging Packets for Flow Identification</name>
    <t>
     Packets that are routed by a PCE along a Track, Track are tagged to uniquely
     identify the Track and associated transmit bundle of timeSlots.
    </t>

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

   <section anchor='pmhrre'><name>Replication, Retries Retries, and Elimination</name>
    <t>
       The 6TiSCH Architecture architecture <xref target='RFC9030'/> leverages PREOF over
       several alternate paths in a network to provide redundancy and parallel
       transmissions to bound the end-to-end delay.  Considering the scenario
       shown in <xref target='fig_ladder'/>, 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 F, but more complex paths are possible as well.
    </t>

      <figure anchor='fig_ladder' align='center'><name>A Typical Ladder Shape with Two Parallel Paths Toward the Destination</name>
         <artwork align='center'><![CDATA[
                 (A)   (C)   (E)

   source (S)                       (R) (destination)

                 (B)   (D)   (F)
]]></artwork>
     </figure>

    <t>
    	By

    <t>By employing a Packet Replication packet replication function, each node forwards a copy
    of each data packet over two different branches.  For instance, in <xref
    target='fig_replication'/>, the source node S transmits the data packet to
    nodes A and B, in two different timeslots within the same TSCH slotframe.
    </t>

        <figure anchor='fig_replication' align='center'><name>Packet Replication: S transmits twice the same data packet, packet to its Destination Parent
	(DP) (A) and to its Alternate Parent (AP) (B).</name> (B).
    </t>

        <figure anchor='fig_replication' align='center'><name>Packet Replication</name>
            <artwork align='center'><![CDATA[
               ===> (A) => (C) => (E) ===
             //        \\//   \\//       \\
   source (S)          //\\   //\\         (R) (destination)
             \\       //  \\ //  \\      //
               ===> (B) => (D) => (F) ===
]]></artwork>
        </figure>

    <t>
        By

<!-- [rfced] We have moved the text below from the title of Figure 4 and added
it to the text introducing the figure. Please review. Also, please
clarify "twice" here. Would updating as follows (move "twice", add colon,
and add "once") convey the intended meaning?

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

Perhaps:
   In the figure above, S transmits the same data
   packet twice: once to its Destination Parent (DP) (A) and once to its Alternate
   Parent (AP) (B).
-->

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

    <t>
		Considering upward.</t>

    <t>Considering that the wireless medium is broadcast by nature, any
    neighbor of a transmitter may overhear a transmission.  By employing the Promiscuous Overhearing
    promiscuous overhearing function, nodes will have multiple opportunities
    to receive a given data packet.  For instance, in <xref
    target='fig_replication'/>, when the source node S transmits the data
    packet to node A, node B may overhear this the transmission.
	</t>

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

<!-- [rfced] Please clarify the text starting with ", and does not need".

Original:
   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.

Perhaps:
   As it goes, 6TiSCH expects that timeSlots corresponding to copies of
   the same packet along a Track are correlated by configuration, so
   processing the sequence numbers is not needed.
-->

   <t>
   As it goes, 6TiSCH expects that timeSlots corresponding to copies
   of the same packet along a Track are correlated by configuration, and does not
   need to process the sequence numbers.
   </t>
   <t>
   The semantics of the configuration must enable correlated timeSlots to be
   grouped for transmit (and respectively receive) receive, respectively) with 'OR' relations,
   and then an 'AND' relation must be configurable between groups.
   The semantics is are such that if the transmit (and respectively receive) receive, respectively) operation
   succeeded in one timeSlot in an 'OR' group, then all the other timeslots in
   the group are ignored.
   Now, if there are at least two groups, the 'AND' relation between the groups
   indicates that one operation must succeed in each of the groups. Further details
   can be found in the 6TiSCH Architecture architecture document <xref target='RFC9030'/>.
   </t>
   </section>
   </section>

   <section anchor='topo'><name>Topology and Capabilities</name>

   <t>6TiSCH nodes are usually IoT devices, characterized by a very limited amount
   of memory, just enough buffers to store one or a few IPv6 packets, and
   limited bandwidth between peers. It results that a node will maintain only a
   small number amount of peering information, information and will not be able to store many
   packets waiting to be forwarded. Peers can be identified through MAC or IPv6
   addresses.
   </t>
   <t>
   Neighbors can be discovered over the radio using mechanism mechanisms such as Enhanced Beacons,
   but, though enhanced beacons,
   but although the neighbor information is available in the 6TiSCH interface
   data model, 6TiSCH does not describe a protocol to pro-actively proactively push the
   neighborhood information to a PCE.
   This protocol should be described and should operate over CoAP. The protocol
   should be able to carry multiple metrics, in particular particular, the same metrics as that are
   used for RPL operations <xref target='RFC6551'/>.
   </t>
<!-- [rfced] FYI - We added "policies that" after "for instance" in the text
below. Please confirm that this is correct.

Original:

   The PCE should be able to compute Tracks that will implement policies on
   how the energy is consumed, for instance balance between nodes and ensure
   that the spent energy does not exceeded the scavenged energy over a period
   of time.

Perhaps:

   The PCE should be able to compute Tracks that will implement policies on
   how the energy is consumed, for instance, policies that balance between
   nodes and ensure that the spent energy does not exceed the scavenged
   energy over a period of time.

-->

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

   </section>

   <section anchor='schd'><name>Schedule Management by a PCE</name>
      <t>
      6TiSCH supports a mixed model of centralized routes and distributed routes.
      Centralized routes can can, for example example, be computed by a an entity such as a
      PCE <xref target='PCE'/>.
      Distributed routes are computed by RPL <xref target='RFC6550'>RPL</xref>. target='RFC6550'/>.
      </t>
      <t>
      Both methods may inject routes in the Routing Tables routing tables of the 6TiSCH routers.
      In either case, each route is associated with a 6TiSCH topology that can
      be a RPL Instance topology or a Track. The 6TiSCH topology is
      indexed by an Instance ID, in a format that reuses the RPLInstanceID as
      defined in RPL.
      </t>
      <t>
      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 the same topology.
      Generally
      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.
      </t>

   </section> <!--anchor="schd" title="Schedule Management by a PCE"-->

      <section anchor='slotFrames'><name>SlotFrames and Priorities</name>
         <t>
         IEEE802.15.4
         IEEE 802.15.4 TSCH avoids contention on the medium by formatting time
         and frequencies in cells of transmission of equal duration.
         In order to describe that formatting of time and frequencies, the
         6TiSCH architecture defines a global concept that is called a Channel
         Distribution and Usage (CDU) matrix; a CDU matrix is a matrix of
         cells with an a height equal to the number of available channels
         (indexed by ChannelOffsets) and a width (in timeSlots) that is the
         period of the network scheduling operation (indexed by slotOffsets) for
         that CDU matrix.
         </t>
         <t>
         The CDU Matrix 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 pseudorandom
         fashion, from an initial position at an epoch time, as the CDU matrix
         iterates over and over.
         </t>
         <t>
         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 side, which may take
         up to a few milliseconds on some device architecture. architectures. The matrix
         represents the overall utilisation utilization of the spectrum over time by a
         scheduled network operation.
         </t>
         <t>
         A CDU matrix is computed by the PCE, but unallocated timeSlots may be
         used opportunistically by the nodes for classical best effort 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 matrix, and the dimensions are
         ordered by priority.
         </t>
<!-- [rfced] Should "device perspective" here be updated to "device's
perspective" (with 's)? Or is another meaning intended?

Original:
   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.
-->

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

<!-- [rfced] We were unable to find a section titled "SlotFrames and
Priorities" in RFC 9030. Should the text below reference Section 4.3.5 of
RFC 9030 (titled "Slotframes and CDU Matrix") instead?

Original:

   Elaboration on that concept can be found in section "SlotFrames and
   Priorities" of <xref target='RFC9030'/>, [RFC9030], and figures 17 and 18 of [RFC9030] illustrate that
   projection.

Perhaps:

   Elaboration on that concept can be found in Section 4.3.5 of [RFC9030], and
   Figures 17 and 18 of [RFC9030] illustrate that projection.

-->

         Elaboration on that concept can be found in section "SlotFrames and
         Priorities" of <xref target='RFC9030'/>, and Figures 17 and 18 in
         <xref target='RFC9030'/> illustrate that projection.
         </t>
      </section>
   </section>

   </section><!-- Applicability to deterministic flows  -->
  </section> <!-- IEEE 802.15.4  TimeSlotted Channel Hopping-->

   <section><name>5G</name>

   <t>
   5G
  </section>

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

   <t>
   5G also includes features to support Industrial industrial IoT use cases, e.g., via the
   integration of 5G with TSN. This includes 5G capabilities for each TSN
   component, latency, resource management, time synchronization, and
   reliability. Furthermore, 5G support for TSN can be leveraged when 5G is used
   as the subnet technology for DetNet, in combination with or instead of TSN, which
   is the primary subnet for DetNet. In addition, the support for integration
   with TSN reliability was added to 5G by making DetNet reliability also
   applicable, due to the commonalities between TSN and DetNet reliability.
   Moreover, providing IP service is native to 5G 5G, and 3GPP Release 18 adds direct
   support for DetNet to 5G.
   </t>

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

   <section><name>Provenance and Documents</name>
   <t>
   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 spectrum, which is
   beneficial for reliability and availability.
   </t>

   <t>
   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 tablets, but it is also
   tailored for future Internet of Things (IoT) 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, devices/sensors and on Ultra-Reliable Low-Latency
   Communication
   Communications (URLLC) for connected control systems and critical
   communication as illustrated in <xref target='fig-5g-triangle'/>. It is the
   URLLC capabilities that make 5G a great candidate for reliable low-latency
   communication. With these three corner stones, cornerstones, NR is a complete solution
   supporting the connectivity needs of consumers, enterprises, and the public
   sector for both wide area wide-area and local area, e.g. indoor local-area (e.g., indoor) deployments.  A
   general overview of NR can be found in <xref target='TS38300'/>.
   </t>

<figure anchor='fig-5g-triangle'><name>5G Application Areas</name>
<artwork align="center"><![CDATA[
            enhanced
        Mobile Broadband
               ^
              / \
             /   \
            /     \
           /       \
          /   5G    \
         /           \
        /             \
       /               \
      +-----------------+
   Massive          Ultra-Reliable
 Machine-Type        Low-Latency
Communication       Communication
]]></artwork>
</figure>

   <t>
   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 10<sup>-5</sup> packet error rate within 1ms a 1 ms latency
   budget <xref target='TR37910'/>. Those evaluations were consolidated and
   forwarded to ITU to be included in the work on <xref target='IMT2020'/> work. target='IMT2020'/>.
   </t>

   <t>
   In order to understand communication requirements for automation in vertical
   domains, 3GPP studied different use cases <xref target='TR22804'/> and
   released a technical specification with reliability, availability availability, and latency
   demands for a variety of applications <xref target='TS22104'/>.
   </t>

   <t>
   As an evolution of NR, multiple studies that focus on radio aspects have been conducted in scope of 3GPP
   Release 16 16, including the following two, focusing on radio aspects:
   </t><ol type='%d.'>
      <li> Study two:
   </t>
   <ol type='1'>
   <li>"Study on physical layer enhancements for NR ultra-reliable and low
   latency communication (URLLC) case (URLLC)" <xref target='TR38824'/>.</li>
      <li> Study target='TR38824'/></li>

   <li>"Study on NR industrial Internet of Things (I-IoT) (IoT)" <xref target='TR38825'/>.</li>
     </ol><t>
   </t>
   target='TR38825'/></li>
     </ol>
   <t>
   Resulting
   As a result of these studies, further enhancements to NR have been standardized
   in 3GPP Release 16, hence, 16 and  are available in <xref target='TS38300'/>, target='TS38300'/> and
   continued in 3GPP Release 17 standardization (according to <xref target='RP210854'/>).
   </t>

   <t>

   In addition, several enhancements have been done made on the system architecture level level,
   which are reflected in System "System architecture for the 5G System (5GS) (5GS)"
   <xref target='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., improvements, such as support for DetNet <xref target='TR2370046'/>. target='TR2370046'/>, are
   provided in Release 18.

   </t>

   <t>
   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.:
   companies (e.g., industrial automation enterprises, machine builders, and
   end users. 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.
   </t>

   </section><!-- Provenance and Documents   -->

   </section>

   <section><name>General Characteristics</name>

   <t>
   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.
   </t>

   <t>
   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 preemption, where URLLC data transmission can
   preempt ongoing non-URLLC transmissions. Additionally, NR applies very fast
   processing, enabling retransmissions even within short latency bounds.
   </t>

   <t>
   NR defines extra-robust transmission modes for increased reliability both for both
   data and control radio channels. Reliability is further improved by
   various techniques, such as multi-antenna transmission, the use of multiple
   frequency carriers in parallel 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.
   </t>

   <t>
   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 topology, and specific configuration
   configurations 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 5G (e.g., eMBB and URLLC, URLLC), depending on the different customers’ needs.
   needs of customers.
   </t>

   <t>
   Exposure of capabilities of 5G Systems systems to the network or applications
   outside the 3GPP domain have been added to Release 16
   <xref target='TS23501'/>. Via exposure interfaces, applications Applications can access
   5G capabilities, e.g., capabilities like communication service monitoring and network
   maintenance.
   maintenance via exposure interfaces.
   </t>

   <t>
   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 signaling, and protection of interfaces.
   </t>

   <t>
   One particular strength of mobile networks is the authentication, based on
   well-proven algorithms and tightly coupled with a global identity management
   infrastructure. Since 3G, there is also mutual authentication, allowing the
   network to authenticate the device and the device to authenticate the
   network. Another strength is secure solutions for storage and distribution
   of keys 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 operations, and management as well as incident handling incident-handling
   capabilities. The mobile networks approach the entirety in a rather
   coordinated fashion fashion, which is beneficial for security.
   </t>

   </section><!-- General Characteristics   -->

   </section>

   <section><name>Deployment and Spectrum</name>

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

   <t>
   When it comes to spectrum, NR allows combining the merits of many frequency
   bands, such as the high bandwidths in millimeter Waves (mmW) waves (mmWaves) for extreme
   capacity locally, as well as locally and the broad coverage when using mid- and low
   frequency
   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.
   </t>

   <t>
   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 was initially developed for usage of
   licensed spectrum, the functionality to access also access unlicensed spectrum was
   introduced in 3GPP Release 16. Moreover, URLLC features are enhanced in
   Release 17 <xref target='RP210854'/> to be better applicable to unlicensed
   spectrum.
   </t>

   <t>
   Licensed spectrum dedicated to mobile communications has been allocated to
   mobile service providers, i.e. 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, countries or in
   large regions. Besides this, configured as a non-public network (NPN)
   deployment, 5G can also provide network services also to a non-operator defined
   organization and its premises such as a factory deployment. By With this
   isolation, quality of
   service requirements, QoS requirements as well as security requirements can be
   achieved. An integration with a public network, if required, is also
   possible. The non-public (local) network can thus be interconnected with a
   public network, allowing devices to roam between the networks.
   </t>

   <t>
   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 the choice of applying to apply for a local license themselves and
   operating
   operate their own network or cooperating to cooperate with a public network operator or
   service provider.
   </t>

   </section><!-- Deployment and Spectrum   -->

   </section>

   <section><name>Applicability to Deterministic Flows</name>

   <section><name>System Architecture</name>

   <t>
   The 5G system <xref target='TS23501'/> consists of the User Equipment (UE)
   at the terminal side, and the Radio Access Network (RAN) with the gNB gNodeB (gNB) as
   radio base station node, as well as and the Core Network (CN), which is connected
   to the external Data Network (DN). The core network CN is based on a service-based
   architecture with the following central functions: Access and Mobility Management
   Function (AMF), Session Management Function (SMF) (SMF), and User Plane Function (UPF)
   as illustrated in <xref target='fig-5g-arch'/>. "(Note (Note that this document only
   explains key functions, functions; however, <xref target='fig-5g-arch'/> provides a more
   detailed view, and <xref target='SYSTOVER5G'/> summarizes the functions and provides the full
   definition
   definitions of the acronyms used in the figure.)" figure.)
   </t>

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

   <t>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.
   profiles). Segregation of those sessions is also possible, e.g., possible; for example, resource
   isolation in the RAN and in the CN can be defined (slicing).
   </t>

<figure anchor='fig-5g-arch'><name>5G System Architecture</name>
<artwork align="center"><![CDATA[
  +----+  +---+   +---+    +---+    +---+   +---+
  |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-+
]]></artwork>
</figure>

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

   </section><!-- System Architecture   -->

   </section>

   <section><name>Overview of The the Radio Protocol Stack</name>

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

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

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

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

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

   <t>
   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.
   </t>

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

   <t>
   To

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

   </section><!-- Overview of Radio Protocol Stack   -->

   </section>

   <section><name>Radio (PHY)</name>

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

   <t>
   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
   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 (DTX)), and upon detecting DTX, the base station upon detecting DTX will retransmit
   the initial data.
   </t>

   <t>
   An uplink transmission normally starts from a Scheduling Request (SR) – (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., the UE (e.g., by SR, SR), the UE
   transmits a data packet on the Physical Uplink Shared Channel (PUSCH).
   Pre-scheduling
   Pre-scheduling, not relying on SR SR, is also possible (see following section). <xref target="scheduling_qos"/>).
   </t>

   <t>
   Since transmission of data packets require requires usage of control and data
   channels, there are several methods to maintain the needed reliability. NR
   uses Low Density Parity Check (LDPC) codes for data channels, Polar polar codes
   for PDCCH, as well as orthogonal sequences and Polar polar codes for PUCCH. For
   ultra-reliability of data channels, very robust (low spectral (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.
   </t>

   <t>
   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 a 10^-5 Block Error Rate (BLER) are used. Robust link
   adaptation algorithms can maintain the needed level of reliability reliability,
   considering a given latency bound.
   </t>

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

   <t>
   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 low-latency
   services. To overcome the blocking, eMBB resources can be pre-empted preempted and
   re-assigned
   reassigned to URLLC services. In this way, spectrally efficient assignments
   for eMBB can be ensured while providing the flexibility required to ensure a
   bounded latency for URLLC services. In downlink, the gNB can notify the eMBB
   UE about pre-emption preemption after it has happened, while in uplink there are two
   pre-emption
   preemption mechanisms: special signaling to cancel eMBB transmission and
   URLLC dynamic power boost to suppress eMBB transmission.
   </t>

   </section><!-- Radio (PHY)   -->

  <section><name>Scheduling

   </section>

  <section anchor="scheduling_qos"><name>Scheduling and QoS (MAC)</name>

   <t>
   One integral part of the 5G system is the Quality of Service (QoS) framework
   <xref target='TS23501'/>. QoS flows are setup set up by the 5G system for certain
   IP or Ethernet packet flows, so that packets of each flow receive the same
   forwarding treatment, i.e., treatment (i.e., in scheduling and admission control. control). For example, QoS flows
   can for example be associated with different priority level, levels, packet delay
   budgets
   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. reached are admitted.
   </t>

   <t>
   NR transmissions in both UL and DL are scheduled by the gNB
   <xref target='TS38300'/>. This ensures radio resource efficiency, efficiency and fairness
   in resource usage of the users users, and it enables differentiated treatment of the
   data flows of the users according to the QoS targets of the flows. Those QoS
   flows are handled as data radio bearers or logical channels in NR RAN
   scheduling.
   </t>

   <t>
   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)
   (i.e., multiple slot or mini-slot lengths. lengths). Resources of multiple frequency
   carriers can be aggregated and jointly scheduled to the UE.
   </t>

   <t>
   Scheduling decisions are based, e.g., on channel quality measured on
   reference signals and reported by the UE (cf. periodical CSI reports
   for DL channel quality).  The transmission reliability can be chosen
   in the scheduling algorithm, i.e., chosen by link adaptation where an
   appropriate transmission format (e.g., robustness of modulation and
   coding scheme, controlled UL power) is selected for the radio channel
   condition of the UE.
   Retransmissions, based on HARQ feedback, are also controlled by the
   scheduler. The feedback transmission in HARQ loop introduces delays, but
   there are methods to minimize it by using short transmission formats,
   sub-slot feedback reporting 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.
   </t>

<!-- [rfced] Will "When thereupon UL resources are scheduled to the UE" be
clear to readers?

Original:
   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.

Perhaps:
   When UL resources are scheduled, the UE
   can transmit its data and may include a buffer status report
   that indicates the exact amount of data per logical channel still left to
   be sent.
-->

   <t>
   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 report that indicates the exact amount of data per
   logical channel still left to be sent. More UL resources may be scheduled
   accordingly. To avoid the latency introduced in the scheduling request loop,
   UL radio resources can also be pre-scheduled.
   </t>

   <t>
   In particular 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,
   supported in order to serve multiple parallel traffic flows of the same UE.
   </t>

   <t>

<!-- [rfced] Please clarify "This way, e.g., " in the second sentence
below. Also, in the third sentence, what does "partly Release 16" mean?
The first sentence below is included for context.

Original:
   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

Perhaps:
   To support QoS enforcement in the case of mixed traffic with
   different QoS requirements, several features have recently been
   introduced.  These features allow different periodical critical QoS flows
   to be served, together with best-effort transmissions, by the same
   UE.  These features (partly discussed in Release 16) include the following:
-->

   <t>
   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. These features
   (partly Release 16) include the following:</t>

<ul>
  <li>UL logical channel transmission restrictions restrictions, allowing to map logical
  channels of certain QoS to only be mapped to intended UL resources of a certain frequency
  carrier, slot-length, slot length, or CG configuration,
   and 2) intra-UE pre-emption configuration.</li>
   <li>intra-UE preemption and multiplexing, allowing critical UL
   transmissions to either pre-empt preempt non-critical transmissions or being be
   multiplexed with non-critical transmissions keeping different reliability
   targets.
   </t>
   targets.</li>
</ul>
   <t>
   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, gNB or in the Dual
   Connectivity (DC) architecture where the carriers originate from different
   gNBs, i.e.,
   gNBs (i.e., the UE is connected to two gNBs in this case. case).  In both cases,
   transmission reliability is improved by this means of providing frequency
   diversity.
   </t>

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

   </section><!-- Scheduling and QoS (MAC)   -->

   </section>

  <section><name>Time-Sensitive Communications (TSC)</name>

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

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

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

<!-- [rfced] Please clarify "such that the meet their QoS requirements".

Original:
   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.

Perhaps:
   3GPP Release 16 includes integration of 5G with TSN, i.e., specifies
   functions for the 5G System (5GS) to deliver TSN streams so that
   the QoS requirements are met.
-->

<!-- [rfced] May we update this sentence for clarity? We suggest moving "from
the rest of the network" to appear before "the 5GS" and adding
parentheses around the "in particular..." phrase.

Original:
   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.

Perhaps:
   A key aspect of the integration is
   that, from the rest of the network, the 5GS appears as a set of TSN bridges (in
   particular, one virtual bridge per User Plane Function (UPF) on the
   user plane).
-->

   <t>
   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:

<!-- [rfced] Please clarify "hence, can be integrated" in these list items.

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

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

Perhaps:
   3.  low latency, which allows integration with Scheduled Traffic
       [IEEE802.1Qbv]

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

   </t><ol type='%d.'> type='1'>
      <li>interface to TSN controller, as per <xref target='IEEE802.1Qcc'/> for
      the fully centralized configuration model</li>
      <li>time synchronization via reception and transmission of gPTP PDUs
	  <xref target='IEEE802.1AS'/></li>
      <li>low latency, hence, can be integrated with Scheduled Traffic scheduled traffic
	  <xref target='IEEE802.1Qbv'/></li>
      <li>reliability, hence, can be integrated with FRER
	  <xref target='IEEE802.1CB'/></li>
	  </ol><t>
   </t>
	  </ol>

   <t>
   3GPP Release 17 <xref target='TS23501'/> introduced enhancements to
   generalize support for Time-Sensitive Communications (TSC) TSC beyond TSN.  This includes IP communications to
   provide time-sensitive service to, e.g., services (e.g., to Video, Imaging Imaging, and Audio for
   Professional Applications (VIAPA). (VIAPA)). The system model of 5G
   acting as a “TSN bridge” "TSN bridge" in Release 16 has been reused to enable the 5GS
   acting as a “TSC node” "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 interfaces, and the control plane provides the service
   based on QoS and time synchronization requests from an Application Function
   (AF).
   </t>

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

<figure anchor='fig-5g-tsn'><name>5G - TSN Integration</name>
<artwork align="center"><![CDATA[
                 +------------------------------+
                 | 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 ------------------->
]]></artwork>
</figure>

   <t>
   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., network (i.e., radio and core network components. components).
   Release 16 has introduced interworking with gPTP for multiple time domains,
   where the 5GS acts as a virtual gPTP time-aware system and supports the
   forwarding of gPTP time synchronization information between end stations and
   bridges through the 5G user plane TTs. These account for the residence time
   of the 5GS in the time synchronization procedure. One special option is when
   the 5GS internal reference time is not only used within the 5GS, but also to
   the rest of the devices in the deployment, including connected TSN bridges
   and end stations. Release 17 includes further improvements, i.e., improvements (i.e., methods
   for propagation delay compensation in RAN, RAN), further improving the accuracy
   for time synchronization over-the-air, 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 service, making it general
   for TSC TSC, with additional support of other types of clocks and time
   distribution such as boundary clock, transparent clock peer-to-peer, and
   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 <xref target='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
   <xref target='SP211634'/>), where the 5G system can provide a back-up backup or
   alternative timing source for the failure of the local GNSS source (or other
   primary timing source) used by the vertical.
   </t>
<!-- [rfced] How may we update the text starting with "making it general for
TSC with..." to improve readability?

Original:
   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.

Perhaps:
   More extensions and flexibility were added to the time synchronization
   service, making it general for TSC and providing additional support for other types of
   clocks and time distribution such as boundary clocks and transparent clocks (both peer-
   to-peer and end-to-end) aside from the time-aware system used
   for TSN.
-->

   <t>
   <!--
   IETF Deterministic Networking (DetNet) is the technology to support
   time-sensitive communications at the IP layer. 3GPP Release 18 includes a
   study <xref target='TR2370046'/> on whether and how to enable 3GPP support
   for DetNet such that a mapping is provided between DetNet and 5G. The support
   for DetNet is considered to be added via the TSC framework introduced for
   Release 17. The study includes what information needs to be exposed by the
   5G System and the translation of DetNet flow specification to 5G QoS
   parameters. Note that TSN is the primary subnetwork technology for DetNet.
   Thus, the DetNet over TSN work, e.g., <xref target='RFC9023'/>, can be
   leveraged via the TSN support built in 5G. As the standards are ready for
   such an approach, it is out of scope for the 3GPP Release 18 study item
   <xref target='TR2370046'/>.
   -->

<!-- [rfced] In the text below, please confirm that "Figure 11" is correct. We
ask because we do not see "UPF" or "Virtual TSN Bridge granularity" in
Figure 11 of this document.

Original:
   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).
-->

   IETF Deterministic Networking (DetNet) DetNet is the technology to support
   time-sensitive communications at the IP layer. 3GPP Release 18 includes a
   study <xref target='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, DetNet; see Figure 7.1-1 in
   <xref target='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 per-UPF
   granularity (similarly (similar to the per UPF per-UPF Virtual TSN Bridge granularity
   shown in Figure 11). <xref target="fig_LDACSframesuper"/>). In particular, it is listed what lists the parameters that are
   provided by the TSCTSF to the DetNet controller. The study also
   includes how the TSCTSF maps DetNet flow parameters to 5G QoS
   parameters. Note that TSN is the primary subnetwork technology for DetNet.
   Thus, the work on DetNet over TSN work, TSN, e.g., <xref target='RFC9023'/>, can be
   leveraged via the TSN support built in 5G.
   </t>

   <t>
   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 <xref target='fig-5g-dual-ue'/>. There are two
   PDU sessions involved in the solution: the
   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.
   </t>

<!-- [rfced] Should "Figure 9" be updated to "Figure 8" in the sentence below?
The text indicates a single UE. Also, we do not see Figure 8 discussed or
introduced elsewhere in the text.

Original:
   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.
-->

     <t>The independent paths may continue beyond the 3GPP
     network. Redundancy Handling Functions (RHFs) are deployed outside of the
     5GS, i.e., in Host A (the device) and in Host B (the network). RHF can
     implement replication and elimination functions as per <xref
     target='IEEE802.1CB'/> or the Packet Replication, Elimination, and
     Ordering Functions (PREOF) of IETF
   Deterministic Networking (DetNet) DetNet
     <xref target='RFC8655'/>.
   </t>

<figure anchor='fig-5g-single-ue'><name>Reliability anchor='fig-5g-single-ue'>
  <name>Reliability with Single UE</name>
<artwork align="center"><![CDATA[
+........+
. Device . +------+      +------+      +------+
.        . + gNB1 +--N3--+ UPF1 |--N6--+      |
.        ./+------+      +------+      |      |
. +----+ /                             |      |
. |    |/.                             |      |
. | UE + .                             |  DN  |
. |    |\.                             |      |
. +----+ \                             |      |
.        .\+------+      +------+      |      |
+........+ + gNB2 +--N3--+ UPF2 |--N6--+      |
           +------+      +------+      +------+
]]></artwork>
</figure>

<!-- [rfced] Would adding citations for "FRER or as PREOF specifications" here
be helpful to the reader? If so, please let us know which references to
include.

Original:
   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.
-->

   <t>
   An alternative solution is that multiple UEs per device are used for user
   plane redundancy as illustrated in <xref target='fig-5g-dual-ue'/>. Each UE
   sets up a PDU session. The 5GS ensures that those the PDU sessions of the
   different UEs are handled independently internal to the 5GS. There is no
   single point of failure in this solution, which also includes RHF outside
   of the 5G system, e.g., as per the FRER or as PREOF specifications.
   </t>

<figure anchor='fig-5g-dual-ue'><name>Reliability with Dual UE</name>
<artwork align="center"><![CDATA[
+.........+
.  Device .
.         .
. +----+  .  +------+      +------+      +------+
. | UE +-----+ gNB1 +--N3--+ UPF1 |--N6--+      |
. +----+  .  +------+      +------+      |      |
.         .                              |  DN  |
. +----+  .  +------+      +------+      |      |
. | UE +-----+ gNB2 +--N3--+ UPF2 |--N6--+      |
. +----+  .  +------+      +------+      +------+
.         .
+.........+
]]></artwork>
</figure>

   <t>

<!-- [rfced] How may we clarify "make 5G equally supporting"? Also, should
"FRER of TSN and PREOF of DetNet" be updated to "FRER in TSN and PREOF in
DetNet"?

Original:
   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.
   </t>

   </section><!-- Time-Sensitive Networking (TSN) Integration)   -->

   </section><!-- Applicability

Perhaps:
   Note that the abstraction provided by the RHF and the location of the
   RHF outside of the 5G system allow 5G to Deterministic Flows support
   integration for reliability with both FRER in TSN and PREOF in DetNet,
   as they both rely on the same concept.
-->

   </section> <!--

   <t>
   Note that the abstraction provided by the RHF and the location of the RHF
   being outside of the 5G -->

 <section><name>L-band system make 5G equally supporting integration for
   reliability with both FRER of TSN and PREOF of DetNet, as they both rely on
   the same concept.
   </t>
   </section>
   </section>
   </section>

 <section>
   <name>L-Band Digital Aeronautical Communications System</name>

   <t>
One System (LDACS)</name>

   <t>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 suffer
   from the VHF band’s band's increasing saturation in high-density areas and the
   limitations posed by analogue analog radio. Therefore, aviation globally (globally and in the
   European Union (EU) in particular, particular) strives for a sustainable modernization
   of the aeronautical communication infrastructure.
</t><t>
In infrastructure.</t>

   <t>In the long-term, long term, ATM communication shall transition from analogue analog VHF
   voice and VDL2 VDL Mode 2 communication to more spectrum efficient 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).
</t>
       <t>
           LDACS
   (LDACS).</t>

   <t>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).
       </t>
       <t>
           It possible).</t>

   <t>It is a secure, scalable scalable, and spectrum efficient spectrum-efficient data link with embedded
   navigation capability and capability; thus, it is the first truly integrated
   Communications, Navigation, and Surveillance (CNS) system recognized by the
   International Civil Aviation Organization
           (ICAO) (ICAO). During flight tests tests, the
   LDACS capabilities have been successfully demonstrated. A viable roll-out rollout
   scenario has been developed developed, which allows gradual introduction of LDACS with
   immediate use and revenues. Finally, ICAO is developing LDACS standards to
   pave the way for the            future.
       </t>
	   <t>

LDACS future.</t>

   <t>LDACS shall enable IPv6 based IPv6-based air-ground communication related to the
   safety and regularity of the flight. The particular challenge is that no
   new frequencies can be made available for terrestrial aeronautical
   communication. It was thus necessary to develop procedures to enable the
   operation of LDACS in parallel with other services in the same frequency band, more in
   band; see <xref target='RFC9372'/>.
</t>
   <section><name>Provenance target='RFC9372'/> for more information.</t>

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

       <t>LDACS standardization within the framework of the ICAO started in
       December 2016. The ICAO standardization group has produced an initial
       Standards and Recommended Practices (SARPs) document <xref
       target='ICAO18'/>. The SARPs document defines the general
       characteristics of LDACS.
       </t><t>
           Up LDACS.</t>

       <t>Up to now now, the LDACS standardization has been focused on the
       development of the physical layer and the data link layer, 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, QoS, diversity, and mobility under the
       umbrella of the "multi-link concept". This work is conducted by the ICAO working group WG-I.
       </t><t>
           In
        WG-I Working Group.</t>
       <t>In addition to standardization activities activities,
       several industrial LDACS prototypes have been built. One set of LDACS
       prototypes has been evaluated in flight trials trials, confirming the
       theoretical results predicting the system performance <xref target='GRA18'/><xref target='BEL22'/><xref target='GRA23'/> .
       </t>
   </section><!-- Provenance and Documents   -->
       target='GRA18'/> <xref target='BEL22'/> <xref target='GRA23'/>.</t>
   </section>

   <section><name>General Characteristics</name>
       <t>
           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 which
           provides one LDACS radio cell.  The LDACS air interface is a
           cellular data link with a star-topology star topology connecting aircraft to
           ground-stations
           ground stations with a full duplex radio link.  Each ground-station ground station
           is the centralized instance controlling all air-ground communications
           within its radio cell.
       </t>

       <t>
           The user data rate of LDACS is 315 kbit/s to 1428 kbit/s on the
           forward link, 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 315 kbit/s on
           the forward/reverse link, respectively. forward link and 294 kbit/s on the reverse link.
       </t>
       <t>
           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
           <xref target="BAT19"/>.
       </t>
       <t>
           In previous works and during the MICONAV flight campaign in 2019, it
           was also shown, shown that LDACS can be used for surveillance capability.
           Filip et al. <xref al.&nbsp;<xref target="FIL19"/> have shown the passive radar capabilities of LDACS LDACS, and
           Automatic Dependence Surveillance – - Contract (ADS-C) was demonstrated
           via LDACS during the flight campaign 2019 <xref target="SCH19"/>.
       </t>

       <t>
           Since LDACS has been mainly designed for air traffic management communication
           communication, it supports mutual entity authentication, integrity
           and confidentiality capabilities of user data messages messages, and some
           control channel protection capabilities <xref target="MAE18"/>, target="MAE18"/>
           <xref target="MAE191"/>, target="MAE191"/> <xref target="MAE192"/>, target="MAE192"/> <xref
           target="MAE20"/>. <!--<xref target='MAE19'/>.-->
       </t>
       <t>
           Overall
           Overall, this makes LDACS the world's first truly integrated CNS system
           and is the worldwide most mature, secure, and terrestrial long-range CNS
           technology for civil aviation. aviation worldwide.
       </t>

   </section><!-- General Characteristics  -->
   </section>

   <section><name>Deployment and Spectrum</name>
       <t>
           LDACS has its origin in merging parts of the B-VHF <xref target="BRA06"/>, B-AMC
           <xref target="SCH08"/>, TIA-902 (P34) <xref target="HAI09"/>, and WiMAX IEEE 802.16e technologies
           <xref target="EHA11"/>. target="EHA11"/> technologies. In 2007 2007, the spectrum for LDACS was allocated at the World
           Radio Conference (WRC).
       </t>
       <t>
           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 <xref target="SCH14"/>.
       </t>
       <t>
           LDACS is currently being standardized by ICAO and several roll-out rollout
           strategies are discussed: discussed.
       </t>
       <t>
           The LDACS data link provides enhanced capabilities to existing
           Aeronautical
           aeronautical communications infrastructure infrastructures, enabling them to better
           support user needs and new applications. The deployment scalability of
           LDACS allows its implementation to start in areas where it is most needed to
           Improve
           immediately improve the performance of already fielded and already-fielded infrastructure.
           Later
           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.
       </t>
       <t>
           When considering the current VDL Mode 2 infrastructure and user base,
           a very attractive win-win situation comes about, about when the
           technological advantages of LDACS are combined with the existing VDL
           mode
           Mode 2 infrastructure. LDACS provides at least 50 time times more capacity
           than VDL Mode 2 and is a natural enhancement to the existing VDL Mode
           2 business model. The advantage of this approach is that the VDL Mode
           2 infrastructure can be fully reused. Beyond that, it opens the way
           for further enhancements <xref target="ICAO19"/>.

       </t>
    </section><!-- Deployment and Spectrum  -->
    </section>

   <section><name>Applicability to Deterministic Flows</name>
       <t>
           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. rollout.
       </t>

       <section><name>System Architecture</name>
           <t>
               Up to 512 Aircraft Station (AS) Stations (ASes) communicate to an LDACS Ground
               Station (GS) in the Reverse Link reverse link (RL). A GS communicate communicates to an AS in
               the Forward Link (FL). Via an Access-Router (AC-R) (AC-R), GSs connect
               the LDACS sub-network subnetwork to the global Aeronautical
               Telecommunications Network (ATN) to which the corresponding Air
               Traffic Services (ATS) and Aeronautical Operational Control (AOC)
               end systems are attached.
           </t>
       </section><!-- System Architecture  -->

       <section><name>Overview
       </section>

       <section>
	 <name>Overview of the Radio Protocol Stack</name>
           <t>
               The
           <t>The protocol stack of LDACS is implemented in the AS and GS: It GS; it
           consists of the Physical Layer physical (PHY) layer with five major functional
           blocks above it.  Four are placed in the Data Link Layer data link layer (DLL) of
           the AS and GS: (1) Medium GS:</t>
	   <ol>
	     <li>Medium Access Layer (MAC), (2) Voice (MAC),</li>
	     <li>Voice Interface (VI),
               (3) Data (VI),</li>
	     <li>Data Link Service (DLS), and (4) LDACS and</li>
	     <li>LDACS Management Entity (LME).
               The (LME).</li>
	   </ol>
	   <t>The last entity resides within the Sub-Network Layer: Sub-Network subnetwork layer: the
	     Subnetwork Protocol (SNP).  The LDACS network is externally
	     connected to voice units, radio control units, and the ATN Network Layer.
	     network layer.
           </t>
           <t>
           Communications between the MAC and LME layer layers is split into four
           distinct control channels:
            The channels:</t>
	   <ol>
	     <li>the Broadcast Control Channel (BCCH) (BCCH), where LDACS ground stations announce their specific LDACS cell,
           including physical parameters and cell identification; the identification;</li>
	     <li>the Random Access Channel (RACH) (RACH), where LDACS airborne radios can request
           access to an LDACS cell; the cell;</li>
	     <li>the Common Control Channel (CCCH) (CCCH), where
           LDACS ground stations allocate resources to aircraft radios,
           enabling the airborne side to transmit the user payload; the and</li>
	     <li>the Dedicated Control Channel (DCCH) (DCCH), where LDACS airborne
	     radios can request user data resources from the LDACS ground
	     station so the airborne side can transmit the user payload.
            Communications payload.</li>
	   </ol>
	   <t>Communications between the MAC and DLS layer layers is handled by the Data Channel (DCH) where the user payload is
           handled.
           </t>
           <t>
               <xref target="fig_LDACSprotocolstack"/> shows the protocol stack of LDACS as implemented in the AS
               and GS.
           </t>
           <figure title="LDACS protocol stack anchor="fig_LDACSprotocolstack">
	     <name>LDACS Protocol Stack in AS and GS"  anchor="fig_LDACSprotocolstack">
               <artwork>
                   <![CDATA[ GS</name>
               <artwork><![CDATA[
         IPv6                   Network Layer
           |
           |
+------------------+  +----+
|        SNP       |--|    |   Sub-Network   Subnetwork
|                  |  |    |   Layer
+------------------+  |    |
           |          | LME|
+------------------+  |    |
|        DLS       |  |    |   Logical Link
|                  |  |    |   Control Layer
+------------------+  +----+
           |             |
          DCH         DCCH/CCCH
           |          RACH/BCCH
           |             |
+--------------------------+
|           MAC            |   Medium Access
|                          |   Layer
+--------------------------+
           |
+--------------------------+
|           PHY            |   Physical Layer
+--------------------------+
           |
           |
         ((*))
         FL/RL              radio channels
                            separated by
                            Frequency Division Duplex

                   ]]>
               </artwork>
                            frequency division duplex
]]></artwork>
           </figure>
       </section><!-- Overview of The Radio Protocol Stack  -->
       </section>

       <section><name>Radio (PHY)</name>
           <t>
               The physical layer provides the means to transfer data over the
               radio channel.  The LDACS ground-station ground station supports bi-directional bidirectional
               links to multiple aircraft under its control.  The forward link
               direction (FL;
               ground-to-air) (which is ground to air) and the reverse link
               direction (RL; air-to-ground) (which is air to ground) are separated by
               frequency division duplex.  Forward link and reverse link use a
               500 kHz channel each.  The ground-station ground station transmits a
               continuous stream of OFDM symbols on the forward link.  In the
               reverse link link, different aircraft aircrafts are separated in time and
               frequency using a combination of Orthogonal Frequency-Division Multiple-Access
               Multiple Access (OFDMA) and Time-Division Multiple-Access
               (TDMA).  Aircraft thus  Thus, aircraft transmit discontinuously on the reverse
               link with radio bursts sent in precisely defined transmission
               opportunities allocated by the
               ground-station. 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 indicates PHY layer framing and
               timing to the MAC time framing service. LDACS does not support
               beam-forming or Multiple Input Multiple Output (MIMO).
           </t>
       </section><!-- Radio (PHY)  -->
       </section>

       <section><name>Scheduling, Frame Structure Structure, and QoS (MAC)</name>
           <t>
               The data-link 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
               sublayers: the medium access
               sub-layer sublayer and the logical link
               control sub-layer. sublayer.  The medium access
               sub-layer sublayer manages the
               organization of transmission opportunities in slots of time and
               frequency.  The logical link control sub-layer sublayer provides
               acknowledged point-to-point logical channels between the
               aircraft and the ground-station ground station using an automatic repeat
               request protocol.  LDACS supports also supports unacknowledged
               point-to-point channels and ground-to-air broadcast.
               Before going more into depth about the LDACS medium access,
	   </t>
	   <t>Next, the frame
               structure of LDACS is introduced: introduced, followed by
               a more in-depth discussion of the LDACS medium access.
           </t>
           <t>
               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).
           </t>
           <t>
               In the FL, an SF contains a Broadcast Frame of broadcast frame with a duration of 6.72 ms (56
               OFDM symbols) for the Broadcast Control Channel (BCCH), (BCCH) and four
               Multi-Frames (MF), each of with a duration of 58.32 ms (486 OFDM symbols).
           </t>
           <t>
               In the RL, each SF starts with a Random Access (RA) slot of with a
               length of 6.72 ms with two opportunities for sending RL random
               access frames for the Random Access Channel (RACH), followed by
               four MFs.  These MFs have the same fixed duration of 58.32 ms
               as in the FL, FL but a different internal structure structure.
           </t>
           <t>
           <t>Figures <xref target="fig_LDACSframesuper"/> target="fig_LDACSframesuper" format="counter"/>
           and <xref target="fig_LDACSframesmulti"/> target="fig_LDACSframesmulti" format="counter"/>
           illustrate the LDACS frame structure.
           </t>

           <figure title="SF This fixed frame structure allows for LDACS" the reliable and dependable
           transmission of data.</t>

           <figure anchor="fig_LDACSframesuper">
               <artwork>
                   <![CDATA[
	     <name>SF Structure for LDACS</name>
               <artwork><![CDATA[
^
|     +------+------------+------------+------------+------------+
|  FL | BCCH |     MF     |     MF     |     MF     |     MF     |
F     +------+------------+------------+------------+------------+
r     <---------------- Super-Frame (SF) - 240ms ----------------> 240 ms --------------->
e
q     +------+------------+------------+------------+------------+
u  RL | RACH |     MF     |     MF     |     MF     |     MF     |
e     +------+------------+------------+------------+------------+
n     <---------------- Super-Frame (SF) - 240ms ----------------> 240 ms --------------->
c
y
|
----------------------------- Time ------------------------------>
|
                   ]]>
               </artwork>
]]></artwork>
           </figure>

           <figure title="MF anchor="fig_LDACSframesmulti">
	     <name>MF Structure for LDACS"  anchor="fig_LDACSframesmulti">
               <artwork>
                   <![CDATA[ LDACS</name>
               <artwork><![CDATA[
^
|     +-------------+------+-------------+
|  FL |     DCH     | CCCH |     DCH     |
F     +-------------+------+-------------+
r     <----     <--- Multi-Frame (MF) - 58.32ms 58.32 ms -->
e
q     +------+---------------------------+
u  RL | DCCH |             DCH           |
e     +------+---------------------------+
n     <----     <--- Multi-Frame (MF) - 58.32ms 58.32 ms -->
c
y
|
-------------------- Time ------------------>
|
                   ]]>
               </artwork>
]]></artwork>
           </figure>

           <t>

<!-- [rfced] FYI - We moved the first sentence below to appear before Figures
11 and 12. Let us know any concerns.

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

           <t>
           Next, the LDACS medium
           access layer is introduced.
           </t>
           <t>
           LDACS medium access is always under the control of the ground-station 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- ground
           station performs resource scheduling on the basis of these requests
           and grants resources with resource allocation messages.  Resource
           request and allocation messages are exchanged over dedicated
           contention-free control channels.
           </t>
           <t>
           LDACS has two mechanisms to request resources from the scheduler in
           the ground-station. ground station.
           Resources can either be requested "on demand", demand" or permanently
           allocated by a LDACS ground station, station with a given class of service.
           On the forward link, this is done locally in the ground-station, ground station; on
           the reverse link link, a dedicated contention-free control channel is
           used (Dedicated (the Dedicated Control Channel (DCCH); roughly 83 bit bits 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.
           </t>
           <t>
           Resources can also be requested "permanently".  The permanent
           resource request mechanism supports requesting recurring resources in at
           given time intervals.  A permanent resource request has to be
           canceled by the user (or by the ground-station, ground station, which is always in
           control).  User data transmissions over LDACS are therefore always
           scheduled by the ground-station, ground station, while control data uses statically
           (i.e.
           (i.e., at net entry) allocated recurring resources (DCCH and CCCH).
           The current specification documents specify no scheduling algorithm.
           However
           However, performance evaluations so far have used strict priority
           scheduling and round robin for equal priorities for simplicity.  In
           the current prototype implementations 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 low-priority flows.  However, this is not
           seen as a big problem since safety related message safety-related messages always go first in
           any case.  Scheduling of reverse link resources is done in physical
           Protocol Data Units (PDU) of 112 bit bits (or larger if more aggressive
           coding and modulation is used).  Scheduling on the forward link is
           done Byte-wise byte wise since the forward link is transmitted continuously by
           the ground-station. ground station.
           </t>
           <t>
           In order to support diversity, LDACS supports handovers to other
           ground-stations
           ground stations on different channels.  Handovers may be initiated by
           the aircraft (break-before-make) (break before make) or by the ground-station (make-
           before-break). ground station (make before break).  Beyond this, FCI diversity shall
           be implemented by the multi-link concept.
           </t>
       </section><!-- Scheduling, Frame Structure and QoS (MAC)  -->

   </section><!-- Applicability to deterministic flows  -->

   </section><!-- title="L-band Digital Aeronautical Communications System" -->
       </section>
   </section>
   </section>

   <section><name>IANA Considerations</name>
      <t>
    This specification does not require
      <t>This document has no IANA action.
      </t> actions.</t>
   </section>

   <section anchor='sec'><name>Security Considerations</name>
      <t>
    	Most RAW technologies integrate some authentication or encryption
    	mechanisms that were are defined outside the IETF.  The IETF
    	specifications referenced herein each provide their own
      Security Considerations, security
    	considerations, and the lower layer lower-layer technologies used provide their
    	own security at Layer-2. Layer 2.
      </t>
   </section>

	<section><name>Contributors</name>
   <t> This document aggregates articles
</middle>

<back>
<displayreference target="I-D.ietf-6tisch-coap" to="CoAP-6TiSCH"/>
<displayreference target="I-D.ietf-roll-nsa-extension" to="NSA-EXT"/>
<displayreference   target="IEEE802154" to="IEEE802.15.4"/>
<displayreference   target="IEEE80211" to="IEEE802.11"/>
<displayreference   target="IEEE8021Qat" to="IEEE802.1Qat"/>
<displayreference   target="IEEE80211ad" to="IEEE802.11ad"/>
<displayreference   target="IEEE80211ax" to="IEEE802.11ax"/>
<displayreference   target="IEEE80211ay" to="IEEE802.11ay"/>
<displayreference   target="IEEE80211be" to="IEEE802.11be"/>

   <references><name>References</name>

<!-- [rfced] Would you like the references to be alphabetized
or left in their current order?
-->

<!-- [rfced] Note that we removed spaces from authors specialized some citation tags per
Section 3.5 of RFC 7322 ("RFC Style Guide"). For example:

Original:
  [IEEE Std 802.15.4]

Updated:
  [IEEE802.15.4]
-->

<!-- [rfced] This reference points to a superseded version of IEEE Std 802.11;
the most recent version was approved in each
   technologies. Beyond 2024. May we update this
reference to point to the main authors listed most current version?

See:
https://ieeexplore.ieee.org/document/9363693 (superseded)
https://ieeexplore.ieee.org/document/10979691 (most current)

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

<!-- [rfced] This reference points to a superseded IEEE Std from 2018. The
newest version of this IEEE Std was published in 2022. May we update this
reference to point to the front page, most recent version of the following
   contributors proposed additional text standard?

See:
https://ieeexplore.ieee.org/document/8457469 (superseded)
https://ieeexplore.ieee.org/document/9844436 (most current)

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

<!-- [rfced] This reference has been superseded, but we cannot locate a more
recent version. Please review and refinement that improved let us know if any updates are needed
or if the
   document.
   			</t><dl  spacing='normal'>
   				<dt>Georgios Z. Papadopoulos:</dt><dd> Contributed current is correct.

See: https://ieeexplore.ieee.org/document/9442429 (superseded)

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

<!-- [rfced] Note that we have made substantial updates to the TSCH section. </dd>
   				<dt>Nils Maeurer:</dt><dd> Contributed References
section of this document for consistency and access. We have added URLs
and/or DOIs, and we have corrected some incorrect reference information
such as missing authors, incorrect dates, etc.

We have already updated the references below as follows. Please review for
accuracy and let us know if you have any objections.

a) Based on the context of the citations to this reference, we updated this
reference entry to point to the LDACS section. </dd>
   				<dt>Thomas Graeupl:</dt><dd> Contributed 2015 revision.

Original:
   [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".

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

b) We updated this reference entry as shown below as it is now published as
an IEEE standard.

Original:
   [IEEE 802.11be]
              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>.

Updated:
   [IEEE802.11be]
              IEEE, "IEEE Standard for Information technology -
              Telecommunications and information exchange between
              systems Local and metropolitan area networks - Specific
              requirements - Part 11: Wireless LAN Medium Access Control
              (MAC) and Physical Layer (PHY) Specifications Amendment 2:
              Enhancements for Extremely High Throughput (EHT)", IEEE
              Std 802.11be-2024, DOI 10.1109/IEEESTD.2024.11090080,
              <https://ieeexplore.ieee.org/document/11090080>.

c) The original URL for this reference pointed to a page that results in a 404
error. We have updated the LDACS section. </dd>
				<dt>Torsten Dudda, Alexey Shapin, URL and Sara Sandberg:</dt><dd> Contributed reference to point to the 5G section. </dd>
                <dt>Rocco Di Taranto:</dt><dd> Contributed home page for
ISA100 Wireless.

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

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

d) The original URL for this reference redirects to a page for the Wi-Fi section</dd>
                <dt>Rute Sofia:</dt><dd> Contributed FieldComm
Group (https://www.fieldcommgroup.org/).

Original URL:
www.hartcomm.org

There is a specific page for WirelessHART here:
https://www.fieldcommgroup.org/technologies/wirelesshart.

However, this does not match the original title of this reference. The
original title of this reference seems to be pointing to IEC 62951, which can
be found at this URL: https://webstore.iec.ch/en/publication/24433

We have updated this reference based of the Introduction and Terminology sections</dd>
   			</dl><t>

   		</t>
	</section>

	<section><name>Acknowledgments</name>
    <t>
    		Many thanks information available at
the redirected URL to point to FieldComm Group's page for
WirelessHART. Please let us know if you would prefer to point to the participants of
IEC page.

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

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

e) The original title for this reference doesn't match the RAW WG where a lot of title at the work discussed here happened,
URL. We have updated this reference to match the URL.

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

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

f) The original URL for his review this reference results in a 404 error. We found the
following URL, which matches the information for this reference, but
M. Schnell is not the author of this article. We have updated the 802.11 section. Special thanks reference
accordingly.

Original:
   [SCH19]    Schnell, M., "DLR tests digital communications
              technologies combined with additional navigation functions
              for post directorate and IESG reviewers, Roman Danyliw, Victoria Pritchard, Donald Eastlake, Mohamed Boucadair, Jiankang Yao, Shivan Kaul Sahib, Mallory Knodel, Ron Bonica, Ketan Talaulikar, Eric Vyncke, and Carlos Jesus Bernardos Cano.
    </t>
	</section><!-- ack the first time", 3 March 2019,
              <https://www.dlr.de/dlr/en/desktopdefault.aspx/tabid-
              10081/151_read-32951/#/gallery/33877>.

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

<back>
<displayreference   target="IEEE802154"            to="IEEE Std 802.15.4"/>
<displayreference   target="IEEE80211"             to="IEEE Std 802.11"/>
<displayreference   target="IEEE8021Qat"           to="IEEE Std 802.1Qat"/>
<displayreference   target="IEEE80211ad"           to="IEEE Std 802.11ad"/>
<displayreference   target="IEEE80211ax"           to="IEEE Std 802.11ax"/>
<displayreference   target="IEEE80211ay"           to="IEEE Std 802.11ay"/>
<displayreference   target="IEEE80211be"           to="IEEE 802.11be"/>

   <references><name>Normative References</name>
   <xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5673.xml'/> <!-- Industrial Routing Requirements in Low-Power and Lossy Networks --> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5673.xml'/>
   <xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8557.xml'/>
   <!-- DetNet PS --> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8557.xml'/>
   <xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml'/>

<!-- detnet-architecture [RFC9912]
draft-ietf-raw-architecture-30
companion doc RFC 9912
-->
   <xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-raw-architecture.xml'/>
<reference anchor="RFC9912" target="https://www.rfc-editor.org/info/rfc9912">
  <front>
    <title>Reliable and Available Wireless (RAW) Architecture</title>
    <author initials="P." surname="Thubert" fullname="Pascal Thubert" role="editor">
    </author>
    <date month='February' year='2026'/>
  </front>
  <seriesInfo name="RFC" value="9912"/>
  <seriesInfo name="DOI" value="10.17487/RFC9912"/>
</reference>

   </references>

   <references><name>Informative References</name>

   <xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9030.xml'/> <!-- 6Tisch Archi --> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9030.xml'/>
   <xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8480.xml'/> <!-- 6P Protocol Specification --> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8480.xml'/>
   <xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9372.xml'/>

     <!-- href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9372.xml'/>
   <xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8938.xml'/> detnet-dataplane --> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9033.xml'/>
   <xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9033.xml'/> <!-- 6Tisch MSF --> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml'/>
   <xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml'/> <!-- Internet Protocol, Version 6 (IPv6) Specification --> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6550.xml'/>
   <xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6550.xml'/> <!-- RPL --> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6551.xml'/>
   <xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6551.xml'/> <!-- RPL metrics --> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6291.xml'/>
   <xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6291.xml'/> <!-- OAM guidelines --> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7276.xml'/>
   <xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7276.xml'/> <!-- OAM --> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8279.xml'/>
   <xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8279.xml'/> <!-- Mcast BIER --> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9023.xml'/>
   <xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9023.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9262.xml'/>

<!-- DetNet IP over TSN [I-D.ietf-roll-nsa-extension]
draft-ietf-roll-nsa-extension-13
IESG State: I-D Exists as of 11/06/25
-->
     <xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9262.xml'/>
<reference anchor="I-D.ietf-roll-nsa-extension" target="https://datatracker.ietf.org/doc/html/draft-ietf-roll-nsa-extension-13">
   <front>
      <title>Common Ancestor Objective Function and Parent Set DAG Metric Container Extension</title>
      <author initials="R." surname="Koutsiamanis" fullname="Remous-Aris Koutsiamanis" role="editor">
         <organization>IMT Atlantique</organization>
      </author>
      <author initials="G. Z." surname="Papadopoulos" fullname="Georgios Z. Papadopoulos">
         <organization>IMT Atlantique</organization>
      </author>
      <author initials="N." surname="Montavont" fullname="Nicolas Montavont">
         <organization>IMT Atlantique</organization>
      </author>
      <author initials="P." surname="Thubert" fullname="Pascal Thubert">
         <organization>Cisco Systems</organization>
      </author>
      <date month="July" day="7" year="2025" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-roll-nsa-extension-13" />

</reference>

<!--  bier-te-architecture [I-D.ietf-roll-dao-projection]
draft-ietf-roll-dao-projection-40

companion doc

-->

	  <xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-roll-nsa-extension.xml'/>
      <xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-roll-dao-projection.xml'/>

<reference anchor="RFC9914" target="https://www.rfc-editor.org/info/rfc9914">
   <front>
      <title>Root-Initiated Routing State in the Routing Protocol for Low-Power and Lossy Networks (RPL)</title>
      <author initials="P." surname="Thubert" fullname="Pascal Thubert" role="editor">
         </author>
      <author initials="R.A." surname="Jadhav" fullname="Rahul Jadhav">
         <organization>AccuKnox</organization>
      </author>
      <author initials="M." surname="Richardson" fullname="Michael Richardson">
         <organization>Sandelman Software Works</organization>
      </author>
      <date month="February" year="2026" />
   </front>
  <seriesInfo name="RFC" value="9914"/>
  <seriesInfo name="DOI" value="10.17487/RFC9914"/>
</reference>

<!--   <xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.thubert-bier-replication-elimination.xml'/> -->
      <!--xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.thubert-6lo-bier-dispatch.xml'/ [I-D.ietf-6tisch-coap]
draft-ietf-6tisch-coap-03
IESG State: Expired as of 11/06/25
-->
      <xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6tisch-coap.xml'/>
<reference anchor="I-D.ietf-6tisch-coap" target="https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-coap-03">
   <front>
      <title>6TiSCH Resource Management and Interaction using CoAP</title>
      <author initials="R. S." surname="Sudhaakar" fullname="Raghuram S Sudhaakar" role="editor">
         <organization>Cisco</organization>
      </author>
      <author initials="P." surname="Zand" fullname="Pouria Zand">
         <organization>University of Twente</organization>
      </author>
      <date month="March" day="9" year="2015" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-6tisch-coap-03" />

</reference>
      <reference anchor='IEEE802154'>
         <front>
            <title>IEEE Std 802.15.4, Part. 15.4: Wireless Medium Access
            Control (MAC) and Physical Layer (PHY) Specifications Standard for Low-Rate Wireless Personal Area Networks
            </title>
            <author>
               <organization>IEEE standard for Information Technology</organization>
               <organization>IEEE</organization>
            </author>
            <date/>
         </front>
         <seriesInfo name="IEEE Std" value="802.15.4-2015"/>
         <seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7460875"/>
      </reference>

      <reference anchor='IEEE80211'
                 target="https://ieeexplore.ieee.org/document/9363693" >
        <front>
          <title>
IEEE Standard 802.11 - IEEE Standard for Information Technology - -- Telecommunications and information exchange Information Exchange between systems Systems - Local and metropolitan area networks - Metropolitan Area Networks -- Specific requirements Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
            Specifications. Specifications
          </title>
          <author>
               <organization>IEEE standard
               <organization>IEEE</organization>
           </author>
          <date year="2020"/>
        </front>
        <seriesInfo name="IEEE Std" value="802.11-2020"/>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2021.9363693"/>
      </reference>

<!-- Citation specialist note: XML for the most current version of [IEEE Std
802.11] (note: removed '[' character from title; couldn't add the double
hyphens without breaking the XML comment)

      <reference anchor='IEEE80211' target="https://ieeexplore.ieee.org/document/10979691">
        <front>
          <title>
IEEE Standard for Information Technology</organization> 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
          </title>
          <author>
               <organization>IEEE</organization>
           </author>
          <date/>
          <date year="2024"/>
        </front>
        <seriesInfo name="IEEE Std" value="802.11-2024"/>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2025.10979691"/>
      </reference>
-->

      <reference anchor='IEEE80211ax'
                 target="https://ieeexplore.ieee.org/document/9442429">
        <front>
          <title>
            802.11ax:
          <title>IEEE Standard for Information Technology -- Telecommunications and Information Exchange between Systems Local and Metropolitan Area Networks -- Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 1: Enhancements for High Efficiency High-Efficiency WLAN
          </title>
          <author>
               <organization>IEEE standard for Information Technology</organization>
               <organization>IEEE</organization>
           </author>
          <date year='2021'/>
        </front>
        <seriesInfo name="IEEE Std" value="802.11ax-2021"/>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2021.9442429"/>
      </reference>

      <reference anchor='IEEE80211ay'
                 target="https://ieeexplore.ieee.org/document/9502046/">
        <front>
          <title>
            802.11ay:
          <title>IEEE Standard for Information Technology -- Telecommunications and Information Exchange between Systems Local and Metropolitan Area Networks -- Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 2: Enhanced throughput Throughput for operation Operation in license-exempt bands License-exempt Bands above 45 GHz
          </title>
          <author>
               <organization>IEEE standard for Information Technology</organization>
               <organization>IEEE</organization>
           </author>
          <date year='2021'/>
        </front>
        <seriesInfo name="IEEE Std" value="802.11ay-2021"/>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2021.9502046"/>
      </reference>

      <reference anchor='IEEE80211ad'
                 target="https://ieeexplore.ieee.org/document/6392842/">
        <front>
          <title>
            802.11ad:
          <title>IEEE Standard for Information technology -- Telecommunications and information exchange between systems -- Local and metropolitan area networks -- Specific requirements-Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 3: Enhancements for very high throughput Very High Throughput in the 60 GHz band Band
          </title>
          <author></author>
          <author>
            <organization>IEEE</organization>
          </author>
          <date year='2012'/>
        </front>
        <seriesInfo name="IEEE Std" value="802.11ad-2012"/>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2012.6392842"/>
      </reference>

      <reference anchor='IEEE80211be'
                 target="https://mentor.ieee.org/802.11/dcn/18/11-18-1231-04-0eht-eht-draft-proposed-par.docx">
                 target="https://ieeexplore.ieee.org/document/11090080">
        <front>
          <title>
            802.11be: Extreme
          <title>IEEE Standard for Information technology -- Telecommunications and information exchange between systems Local and metropolitan area networks -- Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 2: Enhancements for Extremely High Throughput PAR (EHT)
          </title>
          <author>
               <organization>IEEE standard for Information Technology</organization>
               <organization>IEEE</organization>
           </author>
          <date/>
        </front>
        <seriesInfo name="IEEE Std" value="802.11be-2024"/>
	<seriesInfo name="DOI" value="10.1109/IEEESTD.2024.11090080"/>
      </reference>

      <reference anchor='IEEE8021Qat'>
        <front>
          <title>
            802.1Qat:
          <title>IEEE Standard for Local and metropolitan area networks -- Virtual Bridged Local Area Networks Amendment 14: Stream Reservation Protocol (SRP)
          </title>
          <author></author>
          <author>
            <organization>IEEE</organization>
          </author>
          <date/>
        </front>
        <seriesInfo name="IEEE Std" value="802.1Qat-2010"/>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2010.5594972"/>
      </reference>

      <reference anchor='Cavalcanti_2019'>
        <front>
          <title>
            Extending
          <title>Extending Accurate Time Distribution and Timeliness
Capabilities over Over the Air to Enable Future Wireless Industrial
Automation Systems, the Proceedings of IEEE Systems
          </title>
          <author initials='' surname='Dave Cavalcanti et al.' fullname='Dave Cavalcanti'>
               <organization>IEEE standard for Information Technology</organization>
           <address></address>
          </author> Cavalcanti'/>
          <author fullname='Javier Perez-Ramirez'/>
          <author fullname='Mohammad Mamunur Rashid'/>
          <author fullname='Juan Fang'/>
          <author fullname='Mikhail Galeev'/>
          <author fullname='Kevin B. Stanton'/>
          <date month='June' year='2019'/>
        </front>
        <refcontent>Proceedings of the IEEE, vol. 107, no. 6, pp. 1132-1152</refcontent>
        <seriesInfo name="DOI" value="10.1109/JPROC.2019.2903414"/>
      </reference>

      <reference anchor='Nitsche_2015'>
        <front>
          <title>
            IEEE 802.11ad: directional 60 GHz communication for multi-Gigabit-per-second Wi-Fi
          </title>
          <author initials='' surname='Thomas Nitsche et al.' fullname='Thomas Nitsche'>
               <organization>IEEE standard for Information Technology</organization>
           <address></address>
          </author> Nitsche'/>
          <author fullname='Carlos Cordeiro'/>
          <author fullname='Adriana B. Flores'/>
          <author fullname='Edward W. Knightly'/>
          <author fullname='Eldad Perahia'/>
          <author fullname='Joerg C. Widmer'/>
          <date month='December' year='2014'/>
        </front>
        <refcontent>IEEE Communications Magazine, vol. 52, no. 12, pp. 132-141</refcontent>
        <seriesInfo name="DOI" value="10.1109/MCOM.2014.6979964"/>
      </reference>

      <reference anchor='Ghasempour_2017'>
        <front>
          <title>
            802.11ay: Next-Generation 60 GHz Communications for 100 Gb/s Wi-Fi
          </title>
          <author initials='' surname='Yasaman Ghasempour et al.' fullname='Yasaman Ghasempour'>
               <organization>IEEE standard for Information Technology</organization>
           <address></address>
          </author> Ghasempour'/>
          <author fullname='Claudio R. C. M. de Silva'/>
          <author fullname='Carlos Cordeiro'/>
          <author fullname='Edward W. Knightly'/>
          <date month='December' year='2017'/>
        </front>
        <refcontent>IEEE Communications Magazine, vol. 55, no. 12, pp. 186-192</refcontent>
        <seriesInfo name="DOI" value="10.1109/MCOM.2017.1700393"/>
      </reference>

      <reference anchor='IEEE_doc_11-18-2009-06'> anchor='IEEE_doc_11-18-2009-06' target="https://mentor.ieee.org/802.11/dcn/18/11-18-2009-06-0rta-rta-report-draft.docx">
        <front>
          <title>
            802.11 Real-Time Applications (RTA) Topic Interest Group (TIG) Report
          </title>
          <author>
               <organization>IEEE standard for Information Technology</organization>
               <organization>IEEE</organization>
           </author>
          <date month='November' year='2018'/>
        </front>
      </reference>
<!--

      <reference anchor='IEEE_doc_11-19-0373-00'>
        <front>
          <title>
            Time-Sensitive Applications Support in EHT
          </title>
          <author initials='' surname='Kevin Stanton et Al.' fullname='Kevin Stanton'>
               <organization>IEEE standard for Information Technology</organization>
           <address></address>
          </author>
          <date month='March' year='2019'/>
        </front>
      </reference>
      <reference anchor='morell13'>
        <front>
          <title>
            Label switching over IEEE802.15.4e networks
          </title>
          <author initials='' surname='Antoni Morell et al.' fullname='Antoni Morell et al.'>
            <organization>Trans. Emerging Tel. Tech., 24: 458-475. doi:10.1002/ett.2650</organization><address></address>
          </author>
          <date month='April' year='2013'/>
        </front>
      </reference>

   <reference anchor='dearmas16'>
        <front>
          <title>
            Determinism through path diversity: Why packet replication makes sense
          </title>
          <author initials='' surname='Jesica de Armas et al.' fullname='Jesica de Armas et al.'>
            <organization>In 2016 International Conference on Intelligent Networking and Collaborative Systems (INCoS)</organization><address></address>
          </author>
          <date month='September' year='2016'/>
        </front>
      </reference>
-->

      <!--reference anchor='vilajosana19'>
        <front>
          <title>
            6TiSCH: Industrial Performance for IPv6 Internet-of-Things Networks
          </title>
          <author initials='' surname='Xavier Vilajosana et al.' fullname='Xavier Vilajosana et al.'>
            <organization>Proceedings of the IEEE, vol. 107, no. 6, pp. 1153-1165 </organization><address></address>
          </author>
          <date month='June' year='2019'/>
        </front>
      </reference -->

	  <reference anchor='vilajosana21' target="https://inria.hal.science/hal-02420974/file/IETF_6TiSCH__A_Tutorial__17099609gkvsxdpffdvc_%20(1).pdf">
        <front>
          <title>
            IETF 6TiSCH: A Tutorial
          </title>
          <author initials='' surname='Xavier Vilajosana et al.' fullname='Xavier Vilajosana et al.'>
            <organization>IEEE Communications fullname="Xavier Vilajosana"/>
          <author fullname="Thomas Watteyne"/>
          <author fullname="Tengfei Chang"/>
          <author fullname="Malisa Vucinic"/>
          <author fullname="Simon Duquennoy"/>
          <author fullname="Pascal Thubert"/>
          <date month="December" year="2019"/>
        </front>
        <refcontent>Communications Surveys and Tutorials, vol. 22, no. 1, pp. 595-615 </organization><address></address>
          </author>
          <date month='March' year='2021'/>
        </front> IEEE Communications Society</refcontent>
        <seriesInfo name="HAL ID:" value="hal-02420974"/>
        <seriesInfo name="DOI" value="10.1109/COMST.2019.2939407"/>
      </reference>

      <reference anchor='ISA100.11a' target='http://www.isa100wci.org/en-US/Documents/PDF/3405-ISA100-WirelessSystems-Future-broch-WEB-ETSI.aspx'> target='https://isa100wci.org/about-isa100-wireless?_gl=1*19xrxgo*_up*MQ..*_ga*NDczNjkxOTQ1LjE3NjI0NjQ2NDk.*_ga_L2KSW4EHCS*czE3NjI0NjQ2NDkkbzEkZzEkdDE3NjI0NjQ3MzQkajYwJGwwJGgw'>
        <front>
          <title>ISA100.11a, Wireless Systems for Automation, also IEC 62734</title>
          <title>ISA100 Wireless</title>

          <author>
            <organization>ISA/IEC</organization>
            <organization>ISA</organization>
          </author>

          <date year='2011'/>
        </front>
        <refcontent>ANSI/ISA-100.11a-2011 (IEC 26743)</refcontent>
      </reference>

      <reference anchor='WirelessHART'> anchor='WirelessHART' target="https://www.fieldcommgroup.org/technologies/wirelesshart">
         <front>
            <title>Industrial Communication Networks - Wireless Communication
            Network and Communication Profiles - WirelessHART - IEC 62591</title>
            <title>WirelessHART</title>
            <author>
               <organization>www.hartcomm.org</organization>
               <organization>FieldComm Group</organization>
            </author>
            <date year='2010'/>
         </front>
      </reference>

      <reference anchor='WFA'> anchor='WFA' target="https://www.wi-fi.org">
         <front>
           <title>Wi-Fi Alliance</title>
            <author>
               <organization>www.wi-fi.org</organization>
            </author>
         <author></author>
         </front>
      </reference>
      <reference anchor='Avnu'> anchor='Avnu' target="https://www.avnu.org">
         <front>
            <title>Avnu Alliance</title>
            <author>
               <organization>avnu.org</organization>
            </author>
         </front>
      </reference>

      <reference anchor='PCE' target='https://dataTracker.ietf.org/doc/charter-ietf-pce/'> target='https://datatracker.ietf.org/doc/charter-ietf-pce/'>
         <front>
            <title>Path Computation Element</title>
            <author>
               <organization>IETF</organization>
            </author>
            <date/>
         </front>
      </reference>

      <reference anchor='CCAMP' target='https://dataTracker.ietf.org/doc/charter-ietf-ccamp/'> target='https://datatracker.ietf.org/doc/charter-ietf-ccamp/'>
         <front>
            <title>Common Control and Measurement Plane</title>
            <author>
               <organization>IETF</organization>
            </author>
            <date/>
         </front>
      </reference>

      <!--reference anchor="MPLS" target="https://dataTracker.ietf.org/doc/charter-ietf-mpls/">
         <front>
            <title>Multiprotocol Label Switching</title>
            <author>
               <organization>IETF</organization>
            </author>
            <date/>
         </front>
      </reference-->

      <reference anchor='TiSCH' target='https://dataTracker.ietf.org/doc/charter-ietf-6tisch/'> target='https://datatracker.ietf.org/doc/charter-ietf-6tisch/'>
         <front>
            <title>IPv6 over the TSCH mode over 802.15.4</title> 802.15.4e</title>
            <author>
               <organization>IETF</organization>
            </author>
            <date/>
         </front>
      </reference>

      <reference anchor='RIH18'>
         <front>
            <title>L-band Digital Aeronautical Communications System (LDACS) Activities in SESAR2020</title>
            <author fullname='C. Rihacek'>
               <organization>German Aerospace Center (DLR)</organization></author>
            <author fullname='B. Haindl'></author>
            <author fullname='P. Fantappie'></author>
            <author fullname='S. Pierattelli'></author>
            <author fullname='Thomas Gräupl'>
               <organization>German Aerospace Center (DLR)</organization>
               </author>
            <author fullname='M. Schnell'>
               <organization>German Aerospace Center (DLR)</organization></author>
            <author fullname='N. Fistas'></author>
            <date month='April' year='2018'/>
         </front>
         <seriesInfo name='Proceedings of the
         <refcontent>2018 Integrated Communications Navigation and Communications, Navigation, Surveillance Conference (ICNS)' value='Herndon, VA, USA'/> (ICNS), pp. 4A1-1-4A1-8</refcontent>
         <seriesInfo name="DOI" value="10.1109/ICNSURV.2018.8384880"/>
      </reference>

      <reference anchor='GRA19'> anchor='GRA19' target="https://www.ldacs.com/wp-content/uploads/2013/12/SESAR2020_PJ14_D3_3_030_LDACS_AG_Specification_00_02_02-1_0.pdf">
         <front>
            <title>LDACS
            <title>SESAR2020 - PJ14-02-01 - LDACS A/G Specification</title> SPECIFICATION</title>
            <author fullname='Thomas Gräupl'>
               <organization>German Aerospace Center (DLR)</organization></author> (DLR)</organization>
            </author>
            <author fullname='C. fullname='Christoph Rihacek'>
               <organization>German Aerospace Center (DLR)</organization></author> (DLR)</organization>
            </author>
            <author fullname='B. fullname='Bernhard Haindl'>
               <organization>German Aerospace Center (DLR)</organization></author> (DLR)</organization>
            </author>
            <author fullname="Quentin Parrod"/>
            <date month='February' day='16' month='August' year='2019'/>
         </front>
         <seriesInfo name='SESAR2020' value='PJ14-02-01 D3.3.010'/>
         <refcontent>EDITION 00.02.02</refcontent>
      </reference>

      <reference anchor='SAJ14'>
         <front>
            <title>LDACS1 conformance and compatibility assessment</title>
            <author fullname='B. Haindl and al'></author> fullname="Bernhard Haindl"/>
            <author fullname="Josef Meser"/>
            <author fullname="Miodrag Sajatovic"/>
            <author fullname="Stefan Muller"/>
            <author fullname="Holger Arthaber"/>
            <author fullname="Thomas Faseth"/>
            <author fullname="Michael Zaisberger"/>
            <date month='October' year='2014'/>
         </front>
         <seriesInfo name='IEEE/AIAA
         <refcontent>2014 IEEE/AIAA 33rd Digital Avionics Systems Conference (DASC)' value='DOI 10.1109/DASC.2014.6979447'/> (DASC), pp. 3B3-1-3B3-11</refcontent>
         <seriesInfo name="DOI" value="10.1109/DASC.2014.6979447"/>
      </reference>

      <reference anchor='GRA11'>
         <front>
            <title>L-DACS1
            <title>LDACS1 Data Link Layer Evolution of ATN/IPS</title>
            <author fullname='Thomas Gräupl'>
               <organization>German Aerospace Center (DLR)</organization>
               </author>
            <author fullname='M. Ehammer'></author>
            <date month='October' year='2011'/>
         </front>
        <seriesInfo name='Proceedings of the
        <refcontent>IEEE/AIAA 30th IEEE/AIAA Digital Avionics Systems Conference (DASC)' value='Seattle, WA, USA'/> Conference, pp. 1-28</refcontent>
        <seriesInfo name="DOI" value="10.1109/DASC.2011.6096230"/>
      </reference>

      <reference anchor='ICAO18'> anchor='ICAO18' target="https://elibrary.icao.int/product/279816">
         <front>
            <title>L-Band Digital Aeronautical Communication System (LDACS)</title>
            <author>
               <organization>International Civil Aviation Organization (ICAO)</organization>
               </author>
            <date month='July' year='2018'/>
         </front>
        <seriesInfo name='International
         <refcontent>International Standards and Recommended Practices' value='Annex Practices, Annex 10 - Aeronautical Telecommunications, Vol. III - Communication Systems'/> Systems</refcontent>
      </reference>

      <reference anchor='GRA18'>
         <front>
            <title>L-band Digital Aeronautical Communications System (LDACS) flight trials in the national German project MICONAV</title>
            <author fullname='Thomas Gräupl et al.'></author> fullname="Thomas Gräupl"/>
            <author fullname="Nicolas Schneckenburger"/>
            <author fullname="Thomas Jost"/>
            <author fullname="Michael Schnell"/>
            <author fullname="Alexandra Filip"/>
            <author fullname="Miguel A. Bellido-Manganell"/>
            <author fullname="Daniel M. Mielke"/>
            <author fullname="Nils Mäurer"/>
            <author fullname="Rachit Kumar"/>
            <author fullname="Okuary Osechas"/>
            <author fullname="Giuseppe Battista"/>
            <date month='April' year='2018'/>
         </front>
        <seriesInfo name='Proceedings of the
         <refcontent>2018 Integrated Communications, Navigation, Surveillance Conference (ICNS)' value='Herndon, VA, USA'/> (ICNS), pp. 4A2-1-4A2-7</refcontent>
         <seriesInfo name="DOI" value="10.1109/ICNSURV.2018.8384881"/>
      </reference>

      <reference anchor='BEL22' >
         <front>
           <title>LDACS Flight Trials: Demonstration of ATS-B2, IPS, and Seamless Mobility</title> Performance Analysis of the Future Aeronautical Communications System</title>
           <author fullname='Bellido-Manganell, M.A and al'></author> fullname="Miguel A. Bellido-Manganell"/>
           <author fullname="Thomas Gräupl"/>
           <author fullname="Oliver Heirich"/>
           <author fullname="Nils Mäurer"/>
           <author fullname="Alexandra Filip-Dhaubhadel"/>
           <author fullname="Daniel M. Mielke"/>
           <author fullname="Lukas Marcel Schalk"/>
           <author fullname="Dennis Becker"/>
           <author fullname="Nicolas Schneckenburger"/>
           <author fullname="Michael Schnell"/>
            <date month='Feb' year='2022'/>
         </front>
        <seriesInfo name='IEEE
        <refcontent>IEEE Transactions on Aerospace and Electronic Systems, vol. 58' value='DOI 10.1109/TAES.2021.3111722' /> 58, no. 1, pp. 615-634</refcontent>
<seriesInfo name="DOI" value="10.1109/TAES.2021.3111722"/>
      </reference>

      <reference anchor='GRA23' >
         <front>
            <title>LDACS Flight Trials: Demonstration of ATS-B2, IPS, and Seamless Mobility</title>
            <author fullname='Gräupl, T. and al'></author> fullname="Thomas Gräupl"/>
            <author fullname="Daniel M. Mielke"/>
            <author fullname="Miguel A. Bellido-Manganell"/>
            <author fullname="Leonardus J.A. Jansen"/>
            <author fullname="Nils Mäurer"/>
            <author fullname="Ayten Gürbüz"/>
            <author fullname="Alexandra Filip-Dhaubhadel"/>
            <author fullname="Lukas Schalk"/>
            <author fullname="Dennis Becker"/>
            <author fullname="Michal Skorepa"/>
            <author fullname="Fryderyk Wrobel"/>
            <author fullname="Kazuyuki Morioka"/>
            <author fullname="Stefan Kurz"/>
            <author fullname="Josef Meser"/>
            <date year='2023'/>
         </front>
        <seriesInfo name='Proceedings of the 2023
         <refcontent>2023 Integrated Communication, Navigation and Surveillance Conference (ICNS), Herndon, VA, USA'  value='DOI 10.1109/ICNS58246.2023.10124329' /> pp. 1-13</refcontent>
         <seriesInfo name="DOI" value="10.1109/ICNS58246.2023.10124329"/>
      </reference>

      <reference anchor='TR37910' target='https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3190'>
        <front>
          <title>Study on self evaluation towards IMT-2020 submission</title>
          <seriesInfo name="3GPP" value="TR 37.910"/>
          <author>
            <organization showOnFrontPage="true">3GPP</organization>
          </author>
        </front>
      </reference>

      <reference anchor='TR38824' target='https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3498'>
        <front>
          <title>Study on physical layer enhancements for NR ultra-reliable and low latency case (URLLC)</title>
          <seriesInfo name="3GPP" value="TR 38.824"/>
          <author>
            <organization showOnFrontPage="true">3GPP</organization>
          </author>
        </front>
      </reference>

      <reference anchor='TR38825' target='https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3492'>
        <front>
          <title>Study on NR industrial Internet of Things (IoT)</title>
          <seriesInfo name="3GPP" value="TR 38.825"/>
          <author>
            <organization showOnFrontPage="true">3GPP</organization>
          </author>
        </front>
      </reference>

	  <reference anchor='TS22104' target='https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3528'>
        <front>
          <title>Service requirements for cyber-physical control applications in vertical domains</title>
          <seriesInfo name="3GPP" value="TS 22.104"/>
          <author>
            <organization showOnFrontPage="true">3GPP</organization>
          </author>
        </front>
      </reference>

      <reference anchor='TR22804' target='https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3187'>
        <front>
          <title>Study on Communication for Automation in Vertical domains (CAV)</title>
          <seriesInfo name="3GPP" value="TS 22.804"/>
          <author>
            <organization showOnFrontPage="true">3GPP</organization>
          </author>
        </front>
      </reference>

	  <reference anchor='TS23501' target='https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3144'>
        <front>
          <title>System architecture for the 5G System (5GS)</title>
          <seriesInfo name="3GPP" value="TS 23.501"/>
          <author>
            <organization showOnFrontPage="true">3GPP</organization>
          </author>
        </front>
      </reference>

       <reference anchor='TS38300' target='https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3191'>
        <front>
          <title>NR
          <title>NR; NR and NG-RAN Overall description</title> description; Stage-2</title>
          <seriesInfo name="3GPP" value="TS 38.300"/>
          <author>
            <organization showOnFrontPage="true">3GPP</organization>
          </author>
        </front>
      </reference>

	  <reference anchor='SYSTOVER5G' target='https://www.3gpp.org/technologies/5g-system-overview'>
        <front>
          <title>5G system overview</title> System Overview</title>
          <author>
            <organization showOnFrontPage="true">3GPP</organization>
          </author>
          <date day="8" month="8" year="2022"/>
        </front>
      </reference>

	  <reference anchor='RP210854' target='https://www.3gpp.org/ftp/tsg_ran/TSG_RAN/TSGR_91e/Docs/RP-210854.zip'>
        <front>
          <title>Revised WID: Enhanced Industrial Internet of Things (IoT) and ultra-reliable and low latency communication (URLLC) support for NR</title>
          <seriesInfo name="3GPP" value="RP-210854"/>
          <author>
            <organization showOnFrontPage="true">3GPP</organization>
          </author>
		  <date month='March' year='2021'/>
        </front>
      </reference>

	  <reference anchor='TR2370046' target='https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3994'>
        <front>
          <title>Study
          <title> Study on 5GS DetNet Deterministic Networking (DetNet) interworking</title>
          <seriesInfo name="3GPP" value="TR23.700-46"/> value="TR 23.700-46"/>
          <author>
            <organization showOnFrontPage="true">3GPP</organization>
          </author>
		  <date month='August' year='2022'/>
        </front>
      </reference>

	  <!--reference anchor='SP211633' target='https://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_94E_Electronic_2021_12/Docs/SP-211633.zip'>
        <front>
          <title>New SID: Extensions to the TSC Framework to support DetNet</title>
          <seriesInfo name="3GPP" value="SP-211633"/>
          <author>
            <organization showOnFrontPage="true">3GPP</organization>
          </author>
		  <date month='December' year='2021'/>
        </front>
      </reference-->

	  <reference anchor='SP211634' target='https://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_94E_Electronic_2021_12/Docs/SP-211634.zip '>
        <front>
          <title>Study on 5G Timing Resiliency, TSC, and URLLC enhancements</title>
          <seriesInfo name="3GPP" value="SP-211634"/>
          <author>
            <organization showOnFrontPage="true">3GPP</organization>
          </author>
		  <date month='December' year='2021'/>
        </front>
      </reference>

	  <reference anchor='IMT2020' target='https://www.itu.int/en/ITU-R/study-groups/rsg5/rwp5d/imt-2020/Pages/default.aspx'>
        <front>
          <title>ITU towards IMT for 2020 and beyond</title>
          <author></author>
          <title>IMT-2020 (a.k.a. "5G")</title>
          <author>
            <organization>ITU</organization>
          </author>
        </front>
      </reference>

      <reference anchor="IEEE802.1TSN" target="http://www.ieee802.org/1/pages/tsn.html" quoteTitle="true" derivedAnchor="IEEE802.1TSN"> target="http://www.ieee802.org/1/pages/tsn.html">
        <front>
          <title>Time-Sensitive Networking (TSN) Task Group</title>
          <author>
            <organization showOnFrontPage="true">IEEE 802.1</organization> 802.1 Working Group</organization>
          </author>
        </front>
      </reference>

     <reference anchor="IEEE802.1AS" target="https://standards.ieee.org/content/ieee-standards/en/standard/802_1AS-2020.html" quoteTitle="true" derivedAnchor="IEEE802.1AS"> anchor="IEEE802.1AS">
        <front>
          <title>IEEE Standard for Local and metropolitan area networks Metropolitan Area Networks -- Timing and Synchronization for Time-Sensitive Applications</title>
          <seriesInfo name="IEEE" value="802.1AS-2020"/>
          <author>
            <organization showOnFrontPage="true">IEEE</organization>
          </author>
        </front>
        <seriesInfo name="IEEE Std" value="802.1AS-2020"/>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9121845"/>
      </reference>

      <reference anchor="IEEE802.1CB" target="https://ieeexplore.ieee.org/document/8091139" quoteTitle="true" derivedAnchor="IEEE802.1CB"> target="https://ieeexplore.ieee.org/document/8091139">
        <front>
          <title>IEEE Standard for Local and metropolitan area networks -- Frame Replication and Elimination for Reliability</title>
          <seriesInfo name="DOI" value="10.1109/IEEEStd2017.8091139"/>
          <seriesInfo name="IEEE" value="802.1CB-2017"/>
          <author>
            <organization showOnFrontPage="true">IEEE</organization>
          </author>
          <date/>
          <date year="2017"/>
        </front>
        <seriesInfo name="IEEE Std" value="802.1CB-2017"/>
        <seriesInfo name="DOI" value="10.1109/IEEEStd2017.8091139"/>
      </reference>

     <reference anchor="IEEE802.1Qbv" target="https://ieeexplore.ieee.org/document/7440741" quoteTitle="true" derivedAnchor="IEEE802.1Qbv"> anchor="IEEE802.1Qbv">
        <front>
          <title>IEEE Standard for Local and metropolitan area networks -- Bridges and Bridged Networks -- - Amendment 25: Enhancements for Scheduled Traffic</title>
          <seriesInfo name="IEEE" value="802.1Qbv-2015"/>
          <author>
            <organization showOnFrontPage="true">IEEE</organization>
          </author>
          <date year="2016"/>
        </front>
        <seriesInfo name="IEEE Std" value="802.1Qbv-2015"/>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2016.8613095"/>
      </reference>

	  <reference anchor="IEEE802.1Qcc" target="https://ieeexplore.ieee.org/document/8514112" quoteTitle="true" derivedAnchor="IEEE802.1Qcc"> target="https://ieeexplore.ieee.org/document/8514112">
        <front>
          <title>IEEE Standard for Local and metropolitan area networks -- Bridges and Bridged Networks -- Amendment 31: Stream Reservation Protocol (SRP) Enhancements and Performance Improvements</title>
          <seriesInfo name="IEEE" value="802.1Qcc-2018"/>
          <author>
            <organization showOnFrontPage="true">IEEE</organization>
          </author>
        </front>
        <seriesInfo name="IEEE Std" value="802.1Qcc-2018"/>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8514112"/>
      </reference>
      <reference anchor="IEEE802.3" target="https://ieeexplore.ieee.org/document/8457469" quoteTitle="true" derivedAnchor="IEEE802.3"> target="https://ieeexplore.ieee.org/document/8457469">
        <front>
          <title>IEEE Standard for Ethernet</title>
          <author>
            <organization showOnFrontPage="true">IEEE</organization>
          </author>
        </front>
        <seriesInfo name="IEEE" name="IEEE Std" value="802.3-2018"/>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8457469"/>
      </reference>

<!--  Citation specialist note: XML for possible update to [IEEE802.3]
      <reference anchor="IEEE802.3" target="https://ieeexplore.ieee.org/document/9844436">
        <front>
          <title>IEEE Standard for Ethernet</title>
          <author>
            <organization showOnFrontPage="true">IEEE</organization>
          </author>
        </front>
        <seriesInfo name="IEEE Std" value="802.3-2022"/>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2022.9844436"/>
      </reference>
-->

     <reference anchor="TSN5G" target="https://5g-acia.org/whitepapers/integration-of-5g-with-time-sensitive-networking-for-industrial-communications" quoteTitle="true" derivedAnchor="TSN5G"> target="https://5g-acia.org/whitepapers/integration-of-5g-with-time-sensitive-networking-for-industrial-communications">
        <front>
          <title>Integration of 5G with Time-Sensitive Networking for Industrial Communications</title>
          <seriesInfo name="5G-ACIA" value="whitepaper"/>
          <author>
            <organization showOnFrontPage="true">5G-ACIA</organization>
          </author>
        </front>
        <refcontent>5G-ACIA White Paper</refcontent>
      </reference>

      <reference anchor="MAE18"> <!--REF9-->
      <front>
      <title>A Cybersecurity Architecture for the L-band Digital Aeronautical Communications System (LDACS)
      </title>
      <author initials="N." surname="Maeurer"/>
      <author initials="A." surname="Bilzhause"/>
      <date year="2017"/> year="2018"/>
      </front>
      <seriesInfo name='IEEE
      <refcontent>2018 IEEE/AIAA 37th Digital Avionics Systems Conference (DASC), pp. 1-10, London, UK' value=''/> 1-10</refcontent>
      <seriesInfo name="DOI" value="10.1109/DASC.2018.8569878"/>
      </reference>

      <reference anchor="MAE191"> <!--REF2-->
      <front>
      <title>Towards Successful Realization of the LDACS Cybersecurity Architecture: An Updated Datalink Security Threat- and Risk Analysis
      </title>
      <author initials="N." surname="Maeurer"/>
      <author initials="C." surname="Schmitt"/>
      <date year="2019"/>
      </front>
      <seriesInfo name='IEEE Integrated
      <refcontent>Integrated Communications, Navigation and Surveillance Conference (ICNS), pp. 1-13, Herndon, VA, USA' value=''/> 1-13</refcontent>
      <seriesInfo name="DOI" value="10.1109/ICNSURV.2019.8735139"/>
      </reference>

      <reference anchor="ICAO19"> anchor="ICAO19" target="https://www.ldacs.com/wp-content/uploads/2013/12/ACP-DCIWG-IP01-LDACS-White-Paper.pdf"> <!--REF2-->
      <front>
      <title>TLDACS White Paper–A Paper - A Roll-out Scenario
      </title>
      <author>
      <organization showOnFrontPage="true">International Civil Aviation Organization (ICAO)</organization>
      </author>
      <date year="2019" month="October"/>
      </front>
      <seriesInfo name='Working Paper
      COMMUNICATIONS PANEL–DATA COMMUNICATIONS INFRASTRUCTURE
      WORKING GROUP, Montreal, Canada
      ' value=''/>
      <refcontent>Communications Panel - Data Communications
Infrastructure Working Group</refcontent>
      </reference>

      <reference anchor="MAE192"> <!--REF1-->
      <front>
      <title>Evaluation of the LDACS Cybersecurity Implementation
      </title>
      <author initials="N." surname="Maeurer"/>
      <author initials="T." surname="Graeupl"/>
      <author initials="C." surname="Schmitt"/>
      <date year="2019" month="September"/>
      </front>
      <seriesInfo name='IEEE
      <refcontent>IEEE/AIAA 38th Digital Avionics Systems Conference (DACS), (DASC), pp. 1-10, San Diego, CA, USA' value=''/> 1-10</refcontent>
      <seriesInfo name="DOI" value="10.1109/DASC43569.2019.9081786"/>
      </reference>

      <reference anchor="MAE20"> <!--REF1-->
      <front>
      <title>Comparing Different Diffie-Hellman Key Exchange Flavors for LDACS
      </title>
      <author initials="N." surname="Maeurer"/>
      <author initials="T." surname="Graeupl"/>
      <author initials="C." surname="Gentsch"/>
      <author initials="C." surname="Schmitt"/>
      <date year="2019" month="October"/> year="2020"/>
      </front>
      <seriesInfo name='IEEE
      <refcontent>AIAA/IEEE 39th Digital Avionics Systems Conference (DACS), (DASC), pp. 1-10, San Diego, CA, USA' value=''/> 1-10</refcontent>
      <seriesInfo name="DOI" value="10.1109/DASC50938.2020.9256746"/>
      </reference>

      <reference anchor="FIL19"> <!--REF1-->
      <front>
      <title>LDACS-
      Based Non-Cooperative Surveillance Multistatic Radar Design
      and Detection Coverage Assessment
      </title>
      <author initials="A." surname="Filip-Dhaubhadel"/>
      <author initials="D." surname="Shutin"/>
      <date year="2019" month="September"/> year="2019"/>
      </front>
      <seriesInfo name='IEEE
      <refcontent>IEEE/AIAA 38th Digital Avionics Systems Conference (DACS), (DASC), pp. 1-10, San Diego, CA, USA' value=''/> 1-10</refcontent>
      <seriesInfo name="DOI" value="10.1109/DASC43569.2019.9081714"/>
      </reference>

      <reference anchor="BAT19"> anchor="BAT19" target="https://elib.dlr.de/134475/1/08735195.pdf"> <!--REF2-->
      <front>
      <title>Real-Time Demonstration of
      Integrated Communication and Navigation Services Using
      LDACS
      </title>
      <author initials="G." surname="Battista"/>
      <author initials="O." surname="Osechas"/>
      <author initials="S." surname="Narayanan"/>
      <author initials="O.G." surname="Crespillo"/>
      <author initials="D." surname="Gerbeth"/>
      <author initials="N." surname="Maeurer"/>
      <author initials="D." surname="Mielke"/>
      <author initials="T." surname="Graeupl"/>
      <date year="2019"/>
      </front>
      <seriesInfo name='IEEE Integrated
      <refcontent>Integrated Communications, Navigation and Surveillance Conference (ICNS), pp. 1-12, Herndon, VA, USA' value=''/> i-xii</refcontent>
      <seriesInfo name="DOI" value="10.1109/ICNSURV.2019.8735195"/>
      </reference>

      <reference anchor="BRA06"> <!--REF1-->
      <front>
      <title>B-VHF -Selected - Selected Simulation Results and Final Assessment
      </title>
      <author initials="S." surname="Brandes"/>
      <author initials="M." surname="Schnell"/>
      <author initials="C.H." initials="C.-h." surname="Rokitansky"/>
      <author initials="M." surname="Ehammer"/>
      <author initials="T." surname="Graeupl"/>
      <author initials="H." surname="Steendam"/>
      <author initials="M." surname="Guenach"/>
      <author initials="C." surname="Rihacek"/>
      <author initials="B." surname="Haindl"/>
      <date year="2019" month="September"/> year="2006"/>
      </front>
      <seriesInfo name='IEEE
      <refcontent>IEEE 25th Digital Avionics Systems Conference (DACS), pp. 1-12, New York, NY, USA' value=''/> 1-12</refcontent>
      <seriesInfo name="DOI" value="10.1109/DASC.2006.313670"/>
      </reference>

      <reference anchor="SCH08"> <!--REF2-->
      <front>
      <title>B-AMC -
      Broadband Aeronautical Multi-carrier Communications
      </title>
      <author initials="M." surname="Schnell"/>
      <author initials="S." surname="Brandes"/>
      <author initials="S." surname="Gligorevic"/>
      <author initials="C.H." initials="C.-H." surname="Rokitansky"/>
      <author initials="M." surname="Ehammer"/>
      <author initials="T." surname="Graeupl"/>
      <author initials="C." surname="Rihacek"/>
      <author initials="M." surname="Sajatovic"/>
      <date year="2008" month="April"/> year="2008"/>
      </front>
      <seriesInfo name='IEEE 8th
      <refcontent>2008 Integrated Communications, Navigation and Surveillance Conference (ICNS), Conference, pp. 1-13, New York, NY, USA' value=''/> 1-12</refcontent>
      <seriesInfo name="DOI" value="10.1109/ICNSURV.2008.4559173"/>
      </reference>
      <reference anchor='SCH19' target='https://www.dlr.de/dlr/en/desktopdefault.aspx/tabid-10081/151_read-32951/#/gallery/33877'> target='https://www.dlr.de/en/latest/news/2019/01/20190327_modern-technology-for-the-flight-deck'>
         <front>
            <title>DLR tests digital communications technologies combined with additional navigation functions for the first time</title>
            <author fullname='M. Schnell'>
            <author>
               <organization>German Aerospace Center (DLR)</organization></author>
            <date day='03' day='27' month='March' year='2019'/>
         </front>
      </reference>

      <reference anchor="HAI09"> <!--REF2-->
      <front>
      <title>Improvement of L-DACS1 Design by Combining B-AMC with P34
      and WiMAX Technologies
      </title>
      <author initials="B." surname="Haindl"/>
      <author initials="C." surname="Rihacek"/>
      <author initials="M." surname="Sajatovic"/>
      <author initials="B." surname="Phillips"/>
      <author initials="J." surname="Budinger"/>
      <author initials="M." surname="Schnell"/>
      <author initials="D." surname="Kamiano"/>
      <author initials="W." surname="Wilson"/>
      <date year="2009" month="May"/>
      </front>
      <seriesInfo name='IEEE 9th
      <refcontent>2009 Integrated Communications, Navigation and Surveillance Conference (ICNS), Conference, pp. 1-8, New York, NY, USA' value=''/> 1-8</refcontent>
      <seriesInfo name="DOI" value="10.1109/ICNSURV.2009.5172873"/>
      </reference>

      <reference anchor="EHA11"> <!--REF1-->
      <front>
      <title>AeroMACS - An Airport
      Communications System
      </title>
      <author initials="M." surname="Ehammer"/>
<author initials="E." surname="Pschernig"/>
      <author initials="T." surname="Graeupl"/>
      <date year="2011" month="September"/> year="2011"/>
      </front>
      <seriesInfo name='IEEE
      <refcontent>2011 IEEE/AIAA 30th Digital Avionics Systems Conference (DACS), Conference, pp. 1-16, New York, NY, USA' value=''/> 4C1-1-4C1-16</refcontent>
      <seriesInfo name="DOI" value="10.1109/DASC.2011.6095903"/>
      </reference>

      <reference anchor="SCH14"> <!--BELL19-->
      <front>
      <title>LDACS: Future Aeronautical Communications for Air-
      Traffic Management
      </title>
      <author initials="M." surname="Schnell"/>
      <author initials="U." surname="Epple"/>
      <author initials="D." surname="Shutin"/>
      <author initials="N." surname="Schneckenburger"/>
      <date year="2017" month="May" year="2014"  />
      </front>
      <seriesInfo name='IEEE
      <refcontent>IEEE Communications Magazine, 52(5),
      104-110
      ' value=''/> vol. 52, no. 5, pp. 104-110</refcontent>
      <seriesInfo name="DOI" value="10.1109/MCOM.2014.6815900"/>
      </reference>

      <reference anchor="Cavalcanti1287" target='https://mentor.ieee.org/802.11/dcn/19/11-19-1287'> <!--Cavalcanti1287-->
      <front>
      <title>TSN support in 802.11 and potential extensions for TGbe

      </title>
      <author initials="D." surname="Cavalcanti"/>
      <author initials="G." surname="Venkatesan"/>
      <author initials="L." surname="Cariou"/>
      <author initials="C." surname="Cordeiro"/>
      <date day="10" month="9" year="2019"  />
      </front>
      </reference>

      <reference anchor="Sudhakaran2021" target='https://ieeexplore.ieee.org/abstract/document/9483447'> <!--SURUTH -->
      <front>
      <title>
         Wireless Time Sensitive Networking for Industrial Collaborative Robotic Workcells
      </title>
      <author initials="S." surname="Sudhakaran"/>
      <author initials="K." surname="Montgomery"/>
      <author initials="M." surname="Kashef"/>
      <author initials="D." surname="Cavalcanti"/>
      <author initials="R." surname="Candell"/>
      <date year="2021"  />
      </front>
      <seriesInfo name='17th
      <refcontent>2021 17th IEEE International Conference on Factory Communication Systems (WFCS)' value=''/> (WFCS), pp. 91-94</refcontent>
      <seriesInfo name="DOI" value="10.1109/WFCS46889.2021.9483447"/>
      </reference>

      <reference anchor="Fang_2021" > <!--FANG -->
      <front>
      <title>
         Wireless TSN with Multi-Radio Wi-Fi
      </title>
      <author initials="J." surname="Fang"/>
      <author initials="S." surname="Sudhakaran"/>
      <author initials="D." surname="Cavalcanti"/>
      <author initials="C." surname="Cordeiro"/>
      <author initials="C." surname="Cheng"/> surname="Chen"/>
      <date year="2021"  />
      </front>
      <seriesInfo name='IEEE International
      <refcontent>2021 IEEE Conference on Standards for Communications and Networking, December 2021.' value=''/> Networking (CSCN), pp. 105-110</refcontent>
      <seriesInfo name="DOI" value="10.1109/CSCN53733.2021.9686180"/>
      </reference>

   </references>
</back>

</rfc>
   </references>

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

<section numbered="false"><name>Contributors</name>
   <t>This document aggregates articles from authors specialized in each
   technology. Beyond the main authors listed on the front page, the following
   contributors proposed additional text and refinements that improved the
   document.</t>

<!-- CONVERT WARNING: wide character found [rfced] In the Contributors section, would you like to point to specific
section numbers? This would create links in the HTML and PDF
outputs. Also, is Section 4 the "Wi-Fi section"? Will this be clear to
readers?

Current:
   *  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

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

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

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

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

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

   <ul spacing="normal">
     <li><t><contact fullname="Georgios Z. Papadopoulos"/> contributed to the TSCH section.</t></li>
     <li><t><contact fullname="Nils Maeurer"/> and <contact fullname="Thomas Graeupl"/> contributed to the LDACS section.</t></li>
     <li><t><contact fullname="Torsten Dudda"/>, <contact fullname="Alexey
     Shapin"/>, and <contact fullname="Sara Sandberg"/> contributed to the 5G
     section.</t></li>
     <li><t><contact fullname="Rocco Di Taranto"/> contributed to the Wi-Fi section.</t></li>
     <li><t><contact fullname="Rute Sofia"/> contributed to the Introduction and Terminology sections.</t></li>
   </ul>
</section>

<!-- [rfced] Some author comments are present in the XML. Please confirm that
no updates related to these comments are needed. Note that these comments
will be deleted prior to publication. -->

<!-- [rfced] Would you like to make use of <sup> for superscript for the two
instances of "10^-5" in this document? We updated the first instance so
you can see what this looks like. Note that in the HTML and PDF, it
appears as superscript; in the text output, <sup> generates a^b, which is
used in the original document.
-->

<!-- [rfced] Please review "It results that" in these sentences. Would either
removing this phrase or updating to "As a result", "Thus," (or something
else) improve these sentences? Note that how to update may depend on
context, so please review each instance in context.

Original:
   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 character 2041 the lower MAC layer
   and thus is not received at the 6top sublayer).
   ...
   It results that a frame
   that is received over a layer-3 bundle may be in fact associated with
   a Track.
   ...
   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.
   ...
   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.
-->

<!-- [rfced] Would you like to update "wide-area" and "local-area" in these
sentences to "WAN" and "LAN", respectively? Or do you prefer the current?

Current:
   With these three cornerstones, NR is a
   complete solution supporting the connectivity needs of consumers,
   enterprises, and the public sector for both wide-area and local-area
   (e.g., indoor) deployments.
   ...
   The 5G system allows deployment in a vast spectrum range, addressing
   use cases in both wide-area and local-area networks.

Perhaps:
   With these three cornerstones, NR is a
   complete solution supporting the connectivity needs of consumers,
   enterprises, and the public sector for both WAN and LAN
   (e.g., indoor) deployments.
   ...
   The 5G system allows deployment in a vast spectrum range, addressing
   use cases in both WANs and LANs.
-->

<!-- [rfced] Units of measure:

a) We see both "ms" and "msec" used in the document. Would you like to use one
form consistently or update to "millisecond" (or the plural "milliseconds"
depending on context)?

b) Will readers know what "1us" is here? Does this refer to microsecond (i.e.,
μs)? If so, may we update to use "microsecond" for clarity? Also, would
updating to "in 1us accuracy level" to "with an accuracy level of 1
microsecond" improve readability?

Original:
   NR supports accurate reference time synchronization in 1us accuracy
   level.

Perhaps:
   NR supports accurate reference time synchronization with an accuracy level
   of 1 microsecond.
-->

<!-- [rfced] Terminology:

a) We note inconsistencies in the terms below throughout the text. Should
these be uniform? If so, please let us know which form is preferred.

ChannelOffset vs. channeloffset vs. channelOffset
  Note: "channelOffset" is used in RFCs 8480, 9030, and 9033.

slotoffset vs. slotOffset
  Note: "slotoffset" is used in RFCs 8480, 9030, and 9033.

slotFrame vs. slotframe
  Note: "slotframe" is used in RFC 9030.

timeSlot vs. timeslot
  Note: "timeSlot" is used in RFC 9030.

b) We see one instance each of the terms below document. Should these be
updated to either "DetNet or RAW" or "DetNet and RAW"?

DetNet/RAW
RAW/DetNet

c) FYI - This document uses a mix of British and American English
spellings. We updated to American spelling for consistency per Section 3.1 of
RFC 7322 ("RFC Style Guide"). Note that we updated the spellings of the
following words: utiliz*, neighbor, signaling, and analog.

d) Some text includes "802.X" that is not prefaced by "IEEE" or "IEEE
Std". Are any updated needed for these? The document includes many instances;
some examples below.

Original:
   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 ...
   ...
   802.11 WLANs can
   also be part of a 802.1Q bridged networks with enhancements enabled
   by the 802.11ak amendment retrofitted in IEEE Std 802.11-2020.
   ...
   Traffic classification based on 802.1Q VLAN tags is also supported in
   802.11.  Other 802.1 TSN capabilities such as 802.1Qbv and 802.1CB,
   which are media agnostic, can already operate over 802.11.

Perhaps:
   While previous IEEE 802.11
   generations, such as IEEE 802.11n and IEEE 802.11ac, have focused mainly on
   improving peak throughput, more recent generations are also
   considering other performance vectors ...
   ...
   IEEE 802.11 WLANs can
   also be part of IEEE 802.1Q bridged networks with enhancements enabled
   by the output IEEE 802.11ak amendment retrofitted in IEEE Std 802.11-2020.
   ...
   Traffic classification based on IEEE 802.1Q VLAN tags is also supported in
   IEEE 802.11.  Other IEEE 802.1 TSN capabilities such as IEEE 802.1Qbv and IEEE 802.1CB,
   which are media agnostic, can already operate over IEEE 802.11.
-->

<!-- [rfced] Abbreviations:

a) How may we expand the following abbreviations?

BPSK (perhaps "Binary Phase-Shift Keying"?)
QPSK (perhaps "Quadrature Phase-Shift Keying"?)
SAP (perhaps "Service Access Point"?)
VDL (perhaps "VHF Digital Link"?)

b) FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.

Federal Communications Commission (FCC)
Carrier Sense Multiple Access (CSMA)
Highway Addressable Remote Transducer Protocol (HART)
Routing Protocol for Low-Power and Lossy Networks (RPL)
Signal-to-Noise Ratio (SNR)
station (STA)
Personal Area Network (PAN)
gNodeB (gNB)

c) FYI - "L1" and"L3" were used only once in the document, and "L2" was only
used twice. We updated to use the expanded forms "Layer 1", "Layer 2", and
"Layer 3".

d) This document contains these similar abbreviations. Will these cause any
confusion for readers? If so, we can update the 8 instances of "GS" to the
expansion "ground station" (and maybe also update instances of "AS" to
"aircraft station" as they are often used in the same text). We will go with
your preference here.

5GS - 5G System
GS - Ground Station

e) We note that this document switches between using the expanded and
abbreviated forms of the terms below. Would you like to expand the first
instance and then use the abbreviated form thereafter? Or do you prefer the
current?

physical vs. PHY (for the layer)
uplink vs. UL
downlink vs. DL
forward link vs. FL
reverse link vs. RL

-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which is helpful for readers.

For example, please consider whether the following should be updated:

a) "master"

Original:
  ...possibility for the TSN grandmaster clock to reside on the UE side.
  ...
  The European ATM Master Plan foresees...

b) "native"

Original:
  Moreover, providing IP service is native to 5G and 3GPP...
  ...
  NR is designed with native support of antenna arrays utilizing...
-->

</back>
</rfc>