rfc9913.original.xml   rfc9913.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="utf-8"?>
<?rfc toc="yes"?>
<?rfc tocompact="no"?> <!DOCTYPE rfc [
<?rfc tocdepth="4"?> <!ENTITY nbsp "&#160;">
<?rfc tocindent="yes"?> <!ENTITY zwsp "&#8203;">
<?rfc symrefs="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc sortrefs="yes"?> <!ENTITY wj "&#8288;">
<?rfc comments="yes"?> ]>
<?rfc inline="yes"?>
<?rfc compact="no"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" ipr='trust200902
<?rfc subcompact="no"?> ' tocInclude="true" obsoletes="" updates="" symRefs="true" sortRefs="false" con
<?rfc authorship="yes"?> sensus="true" submissionType="IETF" xml:lang="en" version="3" docName="draft-iet
<?rfc tocappendix="yes"?> f-raw-technologies-17" number="9913">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" ipr='trust20090
2' tocInclude="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en
" version="3" docName="draft-ietf-raw-technologies-17" >
<front> <front>
<title abbrev='RAW Technologies'>Reliable and Available Wireless (RAW) Techno logies</title> <title abbrev='RAW Technologies'>Reliable and Available Wireless (RAW) Techno logies</title>
<seriesInfo name="RFC" value="9913"/>
<author initials='P' surname='Thubert' fullname='Pascal Thubert' role='editor '> <author initials='P' surname='Thubert' fullname='Pascal Thubert' role='editor '>
<!-- <organization abbrev='Cisco Systems'>Cisco Systems, Inc</organization > -->
<address> <address>
<postal> <postal>
<city>Roquefort-les-Pins</city> <city>Roquefort-les-Pins</city>
<code>06330</code> <code>06330</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>pascal.thubert@gmail.com</email> <email>pascal.thubert@gmail.com</email>
</address> </address>
</author> </author>
<author initials='D' surname='Cavalcanti' fullname='Dave Cavalcanti'> <author initials='D' surname='Cavalcanti' fullname='Dave Cavalcanti'>
<organization abbrev='Intel'>Intel Corporation</organization> <organization abbrev='Intel'>Intel Corporation</organization>
<address> <address>
<postal> <postal>
<street>2111 NE 25th Ave </street> <street>2111 NE 25th Ave </street>
<city> Hillsboro, OR</city> <city> Hillsboro</city>
<region>OR</region>
<code>97124</code> <code>97124</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<phone>503 712 5566</phone> <phone>503 712 5566</phone>
<email>dave.cavalcanti@intel.com</email> <email>dave.cavalcanti@intel.com</email>
</address> </address>
</author> </author>
<author initials='X' surname='Vilajosana' fullname='Xavier Vilajosana'> <author initials='X' surname='Vilajosana' fullname='Xavier Vilajosana'>
<organization>Universitat Oberta de Catalunya</organization> <organization>Universitat Oberta de Catalunya</organization>
<address> <address>
<postal> <postal>
<street>156 Rambla Poblenou</street> <street>156 Rambla Poblenou</street>
skipping to change at line 79 skipping to change at line 76
<postal> <postal>
<street>Magyar tudosok korutja 11</street> <street>Magyar tudosok korutja 11</street>
<city> Budapest</city> <city> Budapest</city>
<code>1117</code> <code>1117</code>
<country>Hungary</country> <country>Hungary</country>
</postal> </postal>
<email>janos.farkas@ericsson.com</email> <email>janos.farkas@ericsson.com</email>
</address> </address>
</author> </author>
<date/> <date month="February" year="2026"/>
<area>Internet Area</area>
<workgroup>RAW</workgroup> <area>RTG</area>
<keyword>Draft</keyword> <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> <abstract>
<t> This document surveys the short and middle range radio technologies <t>This document surveys the short- and middle-range radio technologies
that are suitable to provide a Deterministic Networking / over which providing a Deterministic Networking (DetNet) /
Reliable and Available Wireless (RAW) service over, presents the Reliable and Available Wireless (RAW) service is suitable,
characteristics that RAW may leverage, and explores the applicability presents the characteristics that RAW may leverage, and explores the
of the technologies to carry deterministic flows, as of its time of public applicability of the technologies to carry deterministic flows, as of
ation. the time of publication. The studied technologies are Wi-Fi 6/7,
The studied Time-Slotted Channel Hopping (TSCH), 3GPP 5G, and L-band Digital
technologies are Wi-Fi 6/7, TimeSlotted Channel Hopping (TSCH), 3GPP Aeronautical Communications System (LDACS).
5G, and L-band Digital Aeronautical Communications System (LDACS).
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section><name>Introduction</name> <section><name>Introduction</name>
<t> <t>
Deterministic Networking (DetNet) <xref target="RFC8557"/> provides a capabil Deterministic Networking (DetNet) <xref target="RFC8557"/> provides a
ity to carry specified capability to carry specified unicast or multicast data flows for real-time
unicast or multicast data flows for real-time applications with extremely low applications with extremely low data loss rates and bounded latency within
data loss rates and bounded latency within a network a network domain. Techniques that might be used include
domain. Techniques that might be used include (1) reserving data-plane resou (1) reserving data plane resources for individual (or aggregated) DetNet
rces flows in some or all of the intermediate nodes along the path of the
for individual (or aggregated) DetNet flows in some or all of the flow,
intermediate nodes along the path of the flow, (2) providing explicit (2) providing explicit routes for DetNet flows that do not immediately
routes for DetNet flows that do not immediately change with the change with the network topology, and
network topology, and (3) distributing data from DetNet flow packets (3) distributing data from DetNet flow packets over time and/or space
over time and/or space (e.g., different frequencies, or non-Shared Risk Links (e.g., different frequencies or non-shared risk links) to ensure
) to ensure delivery of each packet in delivery of each packet in spite of the unavailability of a path.</t>
spite of the unavailability of a path. DetNet operates at the IP layer and t <t>DetNet operates at the IP layer and typically
ypically
delivers service over wired lower-layer technologies such as Time-Sensitive delivers service over wired lower-layer technologies such as Time-Sensitive
Networking (TSN) as defined by IEEE 802.1 and IEEE 802.3. Networking (TSN) as defined by IEEE 802.1 and IEEE 802.3.
</t> </t>
<t> <t>
The Reliable and Available Wireless (RAW) Architecture <xref target='I-D.ietf The Reliable and Available Wireless (RAW) architecture <xref
-raw-architecture'/> extends the DetNet Architecture <xref target="RFC8655"/> to target="RFC9912"/> extends the DetNet architecture <xref target="RFC8655"/>
adapt to the specific challenges of the wireless medium, in particular intermit to adapt to the specific challenges of the wireless medium, in particular,
tently lossy connectivity, by optimizing the use of diversity and multipathing. intermittently lossy connectivity, by optimizing the use of diversity and
<xref target='I-D.ietf-raw-architecture'/> defines the concepts of Reliability a multipathing. <xref target='RFC9912'/> defines the concepts of reliability
nd Availability that are used in this document. In turn, this document presents and availability that are used in this document. In turn, this document
wireless technologies with capabilities such as time synchronization and schedu presents wireless technologies with capabilities, such as time
ling of transmission, that would make RAW/DetNet operations possible over such m synchronization and scheduling of transmission, that would make RAW/DetNet
edia. The technologies studied in this document were identified in the charter d operations possible over such media. The technologies studied in this
uring the RAW WG formation and inherited by DetNet document were identified in the charter during the RAW Working Group (WG) for
(when the WG picked up the work on RAW). mation and
inherited by DetNet (when the WG picked up the work on RAW).
</t> </t>
<t> <t>
Making wireless reliable and available is even more challenging than it is 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 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 . to the congestion losses and the delays caused by overbooked shared resources .
</t> </t>
<t> <t>
RAW, like DetNet, needs and leverages lower-layer capabilities such as time s RAW, like DetNet, needs and leverages lower-layer capabilities such as time
ynchronization and traffic shapers. To balance the adverse effects of the radio synchronization and traffic shapers. To balance the adverse effects of the
transmission losses, RAW leverages additional lower-layer capabilities, some of radio transmission losses, RAW leverages additional lower-layer
which may be specific or at least more typically applied to wireless. Such lower capabilities, some of which may be specific or at least more typically
-layer techniques include: applied to wireless. Such lower-layer techniques include:
</t> </t>
<ul> <ul>
<li> <li>per-hop retransmissions (also known as Automatic Repeat Request (ARQ)),</
per-hop retransmissions (aka Automatic Repeat Request or ARQ), li>
</li><li> <li>variation of the Modulation and Coding Scheme (MCS),</li>
variation of the modulation and coding scheme (MCS), <li>short-range broadcast,</li>
</li><li> <li>Multi-User - Multiple Input Multiple Output (MU-MIMO),</li>
short range broadcast, <li>constructive interference, and</li>
</li><li> <li>overhearing whereby multiple receivers are scheduled to receive the same
Multiple User - Multiple Input Multiple Output (MU-MIMO), transmission, which saves both energy on the sender and spectrum.
</li><li>
constructive interference, and
</li><li>
overhearing whereby multiple receivers are scheduled to receive the same tran
smission, which saves both energy on the sender and spectrum.
</li> </li>
</ul> </ul>
<t> <t>
These capabilities may be offered by the lower layer and may be controlled by RAW, separately or in combination. These capabilities may be offered by the lower layer and may be controlled by RAW, separately or in combination.
</t> </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> <t>
RAW defines a network-layer control loop that optimizes the use of links with RAW defines a network-layer control loop that optimizes the use of links
constrained spectrum and energy while maintaining the expected connectivity pro with constrained spectrum and energy while maintaining the expected
perties, typically reliability and latency. The control loop involves communicat connectivity properties, typically reliability and latency. The control
ion monitoring through Operations, Administration and Maintenance (OAM), path co loop involves communication monitoring through Operations, Administration,
ntrol through a Path computation Element (PCE) and a runtime distributed Path Se and Maintenance (OAM); path control through a Path Computation Element
lection Engine (PSE) and extended packet replication, elimination, and ordering (PCE) and a runtime distributed Path Selection Engine (PSE); and extended
functions (PREOF). Packet Replication, Elimination, and Ordering Functions (PREOF).
</t> </t>
<t> <t>
This document surveys the short and middle range radio technologies that are This document surveys the short- and middle-range radio technologies
suitable to provide a DetNet/RAW service over, over which providing a DetNet/RAW service is suitable,
presents the characteristics that RAW may leverage, and explores the applicab presents the characteristics that RAW may leverage, and explores the applicab
ility of the technologies to carry deterministic flows. ility of
The studied technologies are Wi-Fi 6/7, TimeSlotted Channel Hopping (TSCH), 3 the technologies to carry deterministic flows. The studied technologies
GPP 5G, and L-band Digital Aeronautical Communications System (LDACS). are Wi-Fi 6/7, Time-Slotted Channel Hopping (TSCH), 3GPP 5G, and L-band
The purpose of this document is to support and enable work on the these (and Digital Aeronautical Communications System (LDACS). The purpose of this
possibly other similar compatible technologies) at the IETF specifically in the document is to support and enable work on the these (and possibly other
DetNet working group working on RAW. similar compatible technologies) at the IETF, specifically in the DetNet
Working Group working on RAW.
</t> </t>
<t> <t>
This document surveys existing networking technology and defines no protocol This document surveys existing networking technology; it does not define prot
behaviors or operational practices. ocol behaviors or operational practices.
The IETF specifications referenced herein each provide their own Security Con The IETF specifications referenced herein each provide their own security con
siderations, and lower layer technologies provide their own security at Layer-2; siderations, and lower-layer technologies provide their own security at Layer 2;
a security study of the technologies is explicitly not in scope. a security study of the technologies is explicitly not in scope.
</t> </t>
</section><!-- title="Introduction"--> </section>
<section><name>Terminology</name> <section><name>Terminology</name>
<!-- [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 [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> <t>
This document uses the terminology and acronyms defined in Section 2 of <xref This document uses the terminology and acronyms defined in <xref
target="RFC8655"/> and Section 2 of <xref target='I-D.ietf-raw-architecture'/>. target="RFC8655" section="2"/> and <xref section="3" target='RFC9912'/>.
</t> </t>
</section><!-- Terminology --> </section>
<section anchor='detpak'><name>Towards Reliable and Available Wireless Networ ks</name> <section anchor='detpak'><name>Towards Reliable and Available Wireless Networ ks</name>
<section anchor='schre'><name>Scheduling for Reliability</name> <section anchor='schre'><name>Scheduling for Reliability</name>
<t> <t>
A packet network is reliable for critical (e.g., time-sensitive) packets A packet network is reliable for critical (e.g., time-sensitive) packets
when the undesirable statistical effects that affect the transmission of when the undesirable statistical effects that affect the transmission of
those packets, e.g., delay or loss, are eliminated. those packets (e.g., delay or loss) are eliminated.
</t> </t>
<t> <t>
The reliability of a Deterministic Network <xref target='RFC8655'/> The reliability of a deterministic network <xref target='RFC8655'/> often
often relies on precisely applying a tight schedule that controls the use relies on precisely applying a tight schedule that controls the use of
of time-shared resources such as CPUs and buffers, and maintains at all time-shared resources such as CPUs and buffers, and maintains at all times
time the amount of the critical packets within the available resources of the number of the critical packets within the available resources of the
the communication hardware (e.g.; buffers) and that of the transmission mediu communication hardware (e.g., buffers) and the transmission medium
m (e.g.; bandwidth, transmission slots). (e.g., bandwidth, transmission slots). The schedule can also be used to
The schedule can also be used to shape the flows by controlling the time of t shape the flows by controlling the time of transmission of the packets that
ransmission of the packets that compose the flow at every hop. compose the flow at every hop.
</t> </t>
<t> <t>
To achieve this, there must be a shared sense of time throughout the network. To achieve this, there must be a shared sense of time throughout the
The sense of time is usually provided by the lower layer and is not in network. The sense of time is usually provided by the lower layer and is
scope for RAW. As an example, the Precision Time Protocol, standardized as not in scope for RAW. As an example, the Precision Time Protocol (PTP),
IEEE 1588 and IEC 61588, has mapping through profiles to Ethernet, industrial standardized as IEEE 1588 and IEC 61588, has mapping through profiles to
and SmartGrid protocols, and Wi-Fi with IEEE Std 802.1AS. Ethernet, industrial and SmartGrid protocols, and Wi-Fi with IEEE Std
802.1AS.
</t> </t>
</section><!-- Towards Reliable and Available Networks --> </section>
<section anchor='divav'><name>Diversity for Availability</name> <section anchor='divav'><name>Diversity for Availability</name>
<t> <t>
Equipment (e.g., node) failure, for instance a broken switch or an access poi Equipment (e.g., node) failure can
nt rebooting, a broken be the cause of multiple packets being lost in a row before the
wire or radio adapter, or a fixed obstacle to the transmission, can flows are rerouted or the system recovers. Examples of equipment failure incl
be the cause of multiple packets lost in a row before the ude a broken switch, an access point rebooting, a broken
flows are rerouted or the system may recover. wire or radio adapter, or a fixed obstacle to the transmission.
</t> </t>
<t> <t>
This is not acceptable for critical applications such as related to safety. Equipment failure is not acceptable for critical applications such as those r elated to safety.
A typical process control loop will tolerate an occasional packet loss, but 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. a loss of several packets in a row will cause an emergency stop.
In an amusement ride (e.g., at Disneyland, Universal, or MGM Studios parks) In an amusement ride (e.g., at Disneyland, Universal Studios, or MGM Studios
a continuous loss of packet for a few 100ms may trigger an automatic parks),
a continuous loss of packets for a few 100 ms may trigger an automatic
interruption of the ride and cause the evacuation of the attraction floor to restart it. interruption of the ride and cause the evacuation of the attraction floor to restart it.
</t> </t>
<t> <t>
Network Availability is obtained by making the transmission resilient against Network availability is obtained by making the transmission resilient against
hardware failures and radio transmission losses due to uncontrolled events hardware failures and radio transmission losses due to uncontrolled events
such as co-channel interferers, multipath fading or moving obstacles. The such as co-channel interferers, multipath fading, or moving obstacles. The
best results are typically achieved by pseudo-randomly cumulating all forms best results are typically achieved by pseudorandomly cumulating all forms
of diversity, in the spatial domain with replication and elimination, in the of diversity -- in the spatial domain with replication and elimination, in th
e
time domain with ARQ and diverse scheduled transmissions, and in the time domain with ARQ and diverse scheduled transmissions, and in the
frequency domain with frequency hopping or channel hopping between frames. frequency domain with frequency hopping or channel hopping between frames.
</t> </t>
</section><!-- Diversity for Availability --> </section>
<section anchor='wessbenef'><name>Benefits of Scheduling</name>
<section anchor='wessbenef'>
<name>Benefits of Scheduling</name>
<t> <t>
Scheduling redundant transmissions of the critical packets on diverse paths Scheduling redundant transmissions of the critical packets on diverse paths
improves the resiliency against breakages and statistical transmission improves the resiliency against breakages and statistical transmission
loss, such as due to cosmic particles on wires, and interferences on loss, such as those due to cosmic particles on wires and interferences on
wireless. While transmission losses are orders of magnitude more frequent on wireless, wireless. While transmission losses are orders of magnitude more frequent on wireless,
redundancy and diversity are needed in all cases for life- and mission-critic al applications. redundancy and diversity are needed in all cases for life- and mission-critic al applications.
</t> </t>
<t> <t>
When required, the worst case time of delivery can be guaranteed as part of When required, the worst-case time of delivery can be guaranteed as part of
the end-to-end schedule, and the sense of time that must be shared 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. throughout the network can be exposed to and leveraged by other applications.
</t> </t>
<t> <t>
In addition, scheduling provides specific value over the wireless medium: In addition, scheduling provides specific value over the wireless medium:
</t> </t>
<ul> <ul>
<li> <li>
Scheduling allows a time-sharing operation, where every transmission is assig ned its own time/frequency resource. Sender and receiver are synchronized and sc heduled to talk on a given frequency resource at a given time and for a given du ration. This way, scheduling can avoid collisions between scheduled transmission s and enable a high ratio of critical traffic (think 60 or 70% of high priority traffic with ultra low loss) compared to statistical priority-based schemes. Scheduling allows a time-sharing operation, where every transmission is assig ned its own time/frequency resource. The sender and receiver are synchronized an d scheduled to talk on a given frequency resource at a given time and for a give n duration. This way, scheduling can avoid collisions between scheduled transmis sions and enable a high ratio of critical traffic (think 60% or 70% of high-prio rity traffic with ultra low loss) compared to statistical priority-based schemes .
</li> </li>
<li> <li>
Scheduling can be used as a technique for both time and frequency diversity ( 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 (e.g., between transmission retries), allowing the next transmission to
a different frequency as programmed in both the sender and the receiver. happen on a different frequency as programmed in both the sender and the
This is useful to defeat co-channel interference from un-controlled receiver. This is useful to defeat co-channel interference from
transmitters as well as multipath fading. uncontrolled transmitters as well as multipath fading.
</li> </li>
<li> <li>
Transmissions can be also scheduled on multiple channels in parallel, Transmissions can be also scheduled on multiple channels in parallel,
which enables using the full available spectrum while avoiding the which enables the use of the full available spectrum while avoiding the
hidden terminal problem, e.g., when the next packet in a same flow interferes hidden terminal problem, e.g., when the next packet in a same flow interferes
on a same channel with the previous one that progressed a few hops farther. on a same channel with the previous one that progressed a few hops farther.
</li> </li>
<li> <li>
On the other hand, scheduling optimizes the bandwidth usage: compared to Scheduling optimizes the bandwidth usage. Compared to
classical Collision Avoidance techniques, there is no blank time related to classical collision avoidance techniques, there is no blank time related to
inter-frame space (IFS) and exponential back-off in scheduled operations. Interframe Space (IFS) and exponential back-off in scheduled operations.
A minimal Clear Channel Assessment may be needed to comply with the local A minimal clear channel assessment may be needed to comply with the local
regulations such as ETSI 300-328, but that will not detect a collision when regulations such as ETSI 300-328, but that will not detect a collision when
the senders are synchronized. the senders are synchronized.
</li> </li>
<li> <li>
Finally, scheduling plays a critical role to save energy. In IoT, energy is Scheduling plays a critical role in saving energy. In the Internet of Things
the foremost concern, and synchronizing sender and listener enables (IoT), energy is
the foremost concern, and synchronizing the sender and listener enables
always maintaining them in deep sleep when there is no scheduled always maintaining them in deep sleep when there is no scheduled
transmission. This avoids idle listening and long preambles and enables long transmission. This avoids idle listening and long preambles, and it enables l ong
sleep periods between traffic and resynchronization, allowing sleep periods between traffic and resynchronization, allowing
battery-operated nodes to operate in a mesh topology for multiple years. battery-operated nodes to operate in a mesh topology for multiple years.
</li> </li>
</ul> </ul>
</section><!-- Benefits of Scheduling on Wireless --> </section>
</section>
</section><!-- Towards Reliable and Available Networks --> <!-- [rfced] Please review the titles of 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 5 as shown below? Note that the
suggested aligns with the last sentence in the abstract and a similar
sentence in the Introduction.
<section><name>IEEE 802.11</name> Original:
4. IEEE 802.11
5. IEEE 802.15.4 Timeslotted Channel Hopping
6. 5G
7. L-band Digital Aeronautical Communications System
<t> In the recent years, the evolution of the IEEE Std 802.11 standard Perhaps:
has taken a new direction, emphasizing improved reliability and 4. Wi-Fi
reduced latency in addition to minor improvements in speed, to enable 5. Time-Slotted Channel Hopping (TSCH)
new fields of application such as Industrial IoT and Virtual Reality. 6. 5G
7. L-band Digital Aeronautical Communications System (LDACS)
-->
</t> <section>
<t>Leveraging IEEE Std 802.11, the Wi-Fi Alliance <xref target="WFA"/> <name>IEEE 802.11</name>
delivered Wi-Fi 6, 7, and now 8 with more capabilities to schedule and deliver <t>In recent years, the evolution of the IEEE Std 802.11 standard
frames in due time at fast rates. Still, as any radio technology, Wi-Fi is sensi has taken a new direction, emphasizing improved reliability and reduced
tive to frame loss, which can only be combated with the maximum use of diversity latency in addition to minor improvements in speed, to enable new fields
, in space, time, channel, and even technology. of application such as industrial IoT and Virtual Reality (VR).</t>
</t> <t>Leveraging IEEE Std 802.11, the Wi-Fi Alliance <xref target="WFA"/>
<t> delivered Wi-Fi 6, 7, and now 8 with more capabilities to schedule and
In parallel, the Avnu Alliance <xref target="Avnu"/>, which focuses on appl deliver frames in due time at fast rates. Still, as with any radio
ications of TSN for real time data, formed a workgroup for uses case with TSN ca technology, Wi-Fi is sensitive to frame loss, which can only be combated
pabilities over wireless, leveraging both 3GPP and IEEE Std 802.11 standards. with the maximum use of diversity in space, time, channel, and even
technology.</t>
</t> <!-- [rfced] Please clarify "for uses case with".
<t>
To achieve the latter, the reliability must be handled at an upper laye
r that can select Wi-Fi and other wired or wireless technologies for parallel tr
ansmissions. This is where RAW comes into play.
</t>
<t>
This section surveys 802.11 features that are most relevant to RAW, noting
that there are a great many more in the specification, some of which possibly 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 co
nsumption.
</t>
<section><name>Provenance and Documents</name> Original:
In parallel, the Avnu Alliance [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> Perhaps:
The IEEE 802 LAN/MAN Standards Committee (SC) develops and maintains networki In parallel, the Avnu Alliance [Avnu], which focuses on applications
ng standards and recommended practices for local, metropolitan, and other area n of TSN for real-time data, formed a workgroup to investigate TSN
etworks, using an open and accredited process, and advocates them on a global ba capabilities over wireless, leveraging both 3GPP and IEEE Std 802.11
sis. The most widely used standards are for Ethernet, Bridging and Virtual Bridg standards.
ed LANs Wireless LAN, Wireless PAN, Wireless MAN, Wireless Coexistence, Media In -->
dependent Handover Services, and Wireless RAN. An individual Working Group provi
des the focus for each area.
</t>
<t>
The IEEE 802.11 Wireless LAN (WLAN) standards define the underlyi
ng MAC and PHY layers for the Wi-Fi technology. While previous 802.11 generation
s, such as 802.11n and 802.11ac, have focused mainly on improving peak throughpu
t, more recent generations are also considering other performance vectors, such
as efficiency enhancements for dense environments in IEEEE Std 802.11ax <xref ta
rget='IEEE80211ax'/> (approved in 2021), throughput, latency, and reliability en
hancements in P802.11be <xref target='IEEE80211be'/> (approved in 2024).
</t>
<t>
IEEE Std 802.11-2012 includes support for TSN time synchronizatio
n based on IEEE 802.1AS over 802.11 Timing Measurement protocol. IEEE Std 802.11
-2016 additionally includes an extension to the 802.1AS operation over 802.11 fo
r Fine Timing Measurement (FTM), as well as the Stream Reservation Protocol (IEE
E 802.1Qat). 802.11 WLANs can also be part of a 802.1Q bridged networks with enh
ancements 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. O
ther 802.1 TSN capabilities such as 802.1Qbv and 802.1CB, which are media agnost
ic, can already operate over 802.11. The IEEE Std 802.11ax-2021 defines addition
al scheduling capabilities that can enhance the timeliness performance in the 80
2.11 MAC and achieve lower bounded latency. The IEEE 802.11be has introduced fea
tures to enhance the support for 802.1 TSN capabilities especially related to wo
rst-case latency, reliability and availability.
</t> <t>In parallel, the Avnu Alliance <xref target="Avnu"/>, which focuses
<t> on applications of TSN for real-time data, formed a workgroup for uses
The IEEE 802.11 working group has been working in collaboration w case with TSN capabilities over wireless, leveraging both 3GPP and IEEE
ith the IEEE 802.1 working group for several years extending some 802.1 features Std 802.11 standards.</t>
over 802.11. As with any wireless media, 802.11 imposes new constraints and res
trictions to TSN-grade QoS, and tradeoffs between latency and reliability guaran
tees 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 disc
ussed in <xref target='Cavalcanti_2019'/>.
</t>
<t>
Wi-Fi Alliance is the worldwide network of companies that drives glo
bal Wi-Fi adoption and evolution through thought leadership, spectrum advocacy,
and industry-wide collaboration. The WFA work helps ensure that Wi-Fi devices an
d networks provide users the interoperability, security, and reliability they ha
ve come to expect.
</t>
<t>
Avnu Alliance is also a global industry forum developing interoperabi
lity testing for TSN capable devices across multiple media including Ethernet, W
i-Fi, and 5G.
</t>
<t>
The following <xref target='IEEE80211'/> specifications/certifica
tions are relevant in the context of reliable and available wireless services an
d support for time-sensitive networking capabilities:
</t><dl spacing='normal'>
<dt>Time Synchronization:</dt><dd> IEEE802.11-2016 with IEEE802.1AS;
WFA TimeSync Certification.</dd>
<dt>Congestion Control:</dt><dd> IEEE Std 802.11-2016 Admission Cont
rol; WFA Admission Control.</dd>
<dt>Security:</dt><dd> WFA Wi-Fi Protected Access, WPA2 and WPA3.</d
d>
<dt>Interoperating with IEEE802.1Q bridges:</dt><dd> IEEE Std 802.11
-2020 incorporating 802.11ak.</dd>
<dt>Stream Reservation Protocol (part of <xref target='IEEE8021Qat'/
>):</dt><dd> AIEEE802.11-2016</dd>
<dt>Scheduled channel access:</dt><dd> IEEE802.11ad Enhancements for
very high throughput in the 60 GHz band <xref target='IEEE80211ad'/>.</dd>
<dt>802.11 Real-Time Applications:</dt><dd> Topic Interest Group (TI
G) ReportDoc <xref target='IEEE_doc_11-18-2009-06'/>.</dd>
</dl><t>
</t>
<t> <!-- [rfced] Will readers understand what "the latter" is here?
In addition, major amendments being developed by the IEEE802.11 Working
Group include capabilities that can be used as the basis for providing more reli Original:
able and predictable wireless connectivity and support time-sensitive applicatio To achieve the latter, the reliability must be handled at an upper
ns: layer that can select Wi-Fi and other wired or wireless technologies
</t><dl spacing='normal'> for parallel transmissions.
<dt>IEEE 802.11ax: Enhancements for High Efficiency (HE).</dt><dd -->
><xref target='IEEE80211ax'/></dd>
<dt>IEEE 802.11be Extreme High Throughput (EHT).</dt><dd><xref ta <t>To achieve the latter, the reliability must be handled at an upper
rget='IEEE80211be'/></dd> layer that can select Wi-Fi and other wired or wireless technologies for
<dt>IEE 802.11ay Enhanced throughput for operation in license-exe parallel transmissions. This is where RAW comes into play.</t>
mpt bands above 45 GHz.</dt><dd> <xref target='IEEE80211ay'/></dd> <t>This section surveys the IEEE 802.11 features that are most relevant to
</dl><t> RAW,
</t> noting that there are a great many more in the specification, some of
<t> which may also possibly be of interest for a RAW solution. For instance,
The main 802.11ax, 802.11be, 802.11ad, and 802.11ay capabilities frame fragmentation reduces the impact of a very transient transmission
and their relevance to RAW are discussed in the remainder of this section. loss, both on latency and energy consumption.</t>
As P802.11bn is still in early stages of development, its
capabilities are not included in this document. <section>
<name>Provenance and Documents</name>
<t>The IEEE 802 LAN/MAN Standards Committee (SC) develops and maintains
networking standards and recommended practices for local, metropolitan, and
other area networks using an open and accredited process, and it advocates
them on a global basis. The most widely used standards are for Ethernet,
Bridging and Virtual Bridged LAN, Wireless LAN, Wireless Personal Area Networ
k (PAN), Wireless MAN,
Wireless Coexistence, Media Independent Handover Services, and Wireless
Radio Access Network (RAN). An individual working group provides the focus fo
r each area.</t>
<t>The IEEE 802.11 Wireless LAN (WLAN) standards define the
underlying Medium Access Control (MAC) and Physical (PHY) layers for the
Wi-Fi technology. While previous
802.11 generations, such as 802.11n and 802.11ac, focused mainly
on improving peak throughput, more recent generations are also
considering other performance vectors, such as efficiency enhancements
for dense environments in IEEEE Std 802.11ax <xref target='IEEE80211ax'/
> (approved in 2021) and throughput, latency, and
reliability enhancements in IEEE Std 802.11be <xref target='IEEE80211be'
/>
(approved in 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 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 latency. IEEE 802.11be
introduces features to enhance the support for 802.1 TSN capabilities,
especially those related to worst-case latency, reliability, and
availability.</t>
<t>The IEEE 802.11 Working Group has been working in collaboration
with the IEEE 802.1 Working Group for several years, extending some
802.1 features over 802.11. As with any wireless media, 802.11 imposes
new constraints and restrictions to TSN-grade QoS, and trade-offs
between latency and reliability guarantees must be considered as well
as managed deployment requirements. An overview of 802.1 TSN
capabilities and challenges for their extensions to 802.11 are
discussed in <xref 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>The Avnu Alliance is also a global industry forum developing
interoperability testing for TSN-capable devices across multiple
media
including Ethernet, Wi-Fi, and 5G.</t>
<t>The following IEEE Std 802.11
specifications/certifications <xref target='IEEE80211'/> are relevant in
the context of reliable
and available wireless services and support for 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'>
<li>Time synchronization: IEEE Std 802.11-2016 with IEEE Std 802.1AS; WFA Time
Sync Certification</li>
<li>Congestion control: IEEE Std 802.11-2016 Admission Control; WFA Admission
Control</li>
<li>Security: WFA Wi-Fi Protected Access, WPA2, and WPA3</li>
<li>Interoperating with IEEE 802.1Q bridges: IEEE Std 802.11-2020 incorporatin
g 802.11ak</li>
<li>Stream Reservation Protocol (part of <xref target='IEEE8021Qat'/>): AIEEE8
02.11-2016</li>
<li>Scheduled channel access: IEEE 802.11ad enhancements for very high through
put in the 60 GHz band <xref target='IEEE80211ad'/></li>
<li>802.11 Real-Time Applications: Topic Interest Group (TIG) ReportDoc <xref
target='IEEE_doc_11-18-2009-06'/></li>
</ul>
<t>In addition, major amendments being developed by the IEEE 802.11 Working
Group include capabilities that can be used as the basis for providing
more reliable and predictable wireless connectivity and support
time-sensitive applications:</t>
<ul spacing='normal'>
<li><xref target='IEEE80211ax'/>: Enhancements for High Efficiency (HE)</li>
<li><xref target='IEEE80211be'/>: Extreme High Throughput (EHT)</li>
<li><xref target='IEEE80211ay'/>: Enhanced throughput for operation in license
-exempt bands above 45 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> </t>
</section> <!-- Provenance and Documents--> </section>
<section anchor="HE"><name>802.11ax High Efficiency (HE)</name> <section anchor="HE">
<section><name>General Characteristics</name> <name>802.11ax High Efficiency (HE)</name>
<t> <section>
The next generation Wi-Fi (Wi-Fi 6) is based on t
he IEEE802.11ax amendment <xref target='IEEE80211ax'/>, which includes specific
capabilities to increase efficiency, control and reduce latency. Some of these f
eatures include higher order 1024-QAM modulation, support for uplink multiple u
ser (MU) multiple input multiple output (MIMO), orthogonal frequency-division mu
ltiple access (OFDMA), trigger-based access and Target Wake time (TWT) for enhan
ced power savings. The OFDMA mode and trigger-based access enable the AP, after
reserving the channel using the clear channel assessment procedure for a given d
uration, to schedule multi-user transmissions, which is a key capability require
d to increase latency predictability and reliability for time-sensitive flows. 8
02.11ax can operate in up to 160 MHz channels and it includes support for operat
ion in the new 6 GHz band, which has been open to unlicensed use by the FCC and
other regulatory agencies worldwide.
</t>
<section><name>Multi-User OFDMA and Trigger-based Schedul
ed Access</name>
<t>
802.11ax introduced an OFDMA mode in whic
h multiple users can be scheduled across the frequency domain. In this mode, the
Access Point (AP) can initiate multi-user (MU) Uplink (UL) transmissions in the
same PHY Protocol Data Unit (PPDU) by sending a trigger frame. This centralized
scheduling capability gives the AP much more control of the channel in its Basi
c Service Set (BSS) and it can remove contention between associated stations for
uplink transmissions, therefore reducing the randomness caused by CSMA-based ac
cess between stations within the same BSS. The AP can also transmit simultaneous
ly to multiple users in the downlink direction by using a Downlink (DL) MU OFDMA
PPDU. In order to initiate a contention free Transmission Opportunity (TXOP) us
ing the OFDMA mode, the AP still follows the typical listen before talk procedur
e to acquire the medium, which ensures interoperability and compliance with unli
censed band access rules. However, 802.11ax also includes a multi-user Enhanced
Distributed Channel Access (MU-EDCA) capability, which allows the AP to get high
er channel access priority than other devices in its BSS.
</t>
</section> <!--Multi-User OFDMA and Trigger-based Schedul
ed Access -->
<section><name>Traffic Isolation via OFDMA Resour <!-- [rfced] How may we revise the phrase "to increase efficiency, control and
ce Management and Resource Unit Allocation</name> reduce latency" to clarify how the word "control" should be understood?
<t>
802.11ax relies on the notion of OFDMA Resource Unit (RU) to allocate Original:
frequency chunks to different STAs over time. RUs provide a way to allow
for multiple stations to transmit simultaneously, starting and ending at
the same time. The way this is achieved is via padding, where extra bits
are transmitted with the same power level. The current RU allocation
algorithms provide a way to achieve traffic isolation per station which
while per se does not support time-aware scheduling, is a key aspect to
assist reliability, as it provides traffic isolation in a shared medium.
</t> The next generation Wi-Fi (Wi-Fi 6) is based on the IEEE802.11ax amendment
</section><!-- Traffic Isolation via OFDMA Resour [IEEE Std 802.11ax], which includes specific capabilities to increase
ce Management and Resource Unit --> efficiency, control and reduce latency.
<section><name>Improved PHY Robustness</name>
<t> Perhaps:
The 802.11ax PHY can operate with 0.8, 1.
6 or 3.2 microsecond guard interval (GI). The larger GI options provide better p The next generation Wi-Fi (Wi-Fi 6) is based on the IEEE802.11ax amendment
rotection against multipath, which is expected to be a challenge in industrial e [IEEE Std 802.11ax], which includes specific capabilities to increase
nvironments. The possibility to operate with smaller resource units (e.g. 2 MHz) efficiency and to control and reduce latency.
enabled by OFDMA also helps reduce noise power and improve SNR, leading to bett
er packet error rate (PER) performance. Or:
</t>
<t> The next generation Wi-Fi (Wi-Fi 6) is based on the IEEE802.11ax amendment
802.11ax supports beamforming as in 802.1 [IEEE Std 802.11ax], which includes specific capabilities to increase
1ac, but introduces UL MU MIMO, which helps improve reliability. The UL MU MIMO efficiency and control and to reduce latency.
capability is also enabled by the trigger based access operation in 802.11ax.
</t> -->
</section> <!-- Improved PHY Robustness -->
<section><name>Support for 6GHz Band</name> <name>General Characteristics</name>
<t> <t>The next generation Wi-Fi (Wi-Fi 6) is based on the IEEE Std 802.11ax
The 802.11ax specification <xref amendment <xref target='IEEE80211ax'/>, which includes specific
target='IEEE80211ax'/> includes support for operation in the 6 GHz band. Given t capabilities to increase efficiency, control and reduce latency. Some
he amount of new spectrum available as well as the fact that no legacy 802.11 de of these features include higher-order 1024-QAM modulation, support
vice (prior 802.11ax) will be able to operate in this band, 802.11ax operation i for uplink Multi-User - Multiple Input Multiple Output (MU-MIMO),
n this new band can be even more efficient. Orthogonal Frequency-Division Multiple Access (OFDMA), trigger-based
</t> access, and Target Wake Time (TWT) for enhanced power savings. The
</section> <!-- Support for 6GHz band --> OFDMA mode and trigger-based access enable the Access Point (AP), after r
</section> <!-- General Characteristics--> eserving the
channel using the clear channel assessment procedure for a given
duration, to schedule multi-user transmissions, which is a key
capability required to increase latency predictability and reliability
for time-sensitive flows. 802.11ax can operate in up to 160 MHz
channels, and it includes support for operation in the new 6 GHz band,
which has been open to unlicensed use by the Federal Communications
Commission (FCC) and other regulatory agencies worldwide.</t>
<section>
<name>Multi-User OFDMA and Trigger-Based Scheduled Access</name>
<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 uplink (UL) transmissions in
the same PHY Protocol Data Unit (PPDU) by sending a trigger
frame. This centralized scheduling capability gives the AP much more
control of the channel in its Basic Service Set (BSS), and it can
remove contention between associated stations for uplink
transmissions, therefore reducing the randomness caused by access base
d 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 (DL) MU OFDMA
PPDU. In order to initiate a contention-free Transmission
Opportunity (TXOP) using the OFDMA mode, the AP still follows the
typical listen-before-talk procedure to acquire the medium, which
ensures interoperability and compliance with unlicensed band access
rules. However, 802.11ax also includes a Multi-User Enhanced
Distributed Channel Access (MU-EDCA) capability, which allows the AP
to get higher channel access priority than other devices in its
BSS.</t>
</section>
<section>
<name>Traffic Isolation via OFDMA Resource Management and Resource Unit
Allocation</name>
<t>802.11ax relies on the notion of an OFDMA Resource Unit (RU) to
allocate frequency chunks to different stations over time. RUs provide
a
way to allow multiple stations to transmit simultaneously,
starting and ending at the same time. The way this is achieved is
via padding, where extra bits are transmitted with the same power
level. The current RU allocation algorithms provide a way to
achieve traffic isolation per station. While this does not support
time-aware scheduling per se, it is a key aspect to assist
reliability, as it provides traffic isolation in a shared medium.
</t>
</section>
<section>
<name>Improved PHY Robustness</name>
<t>The 802.11ax PHY can operate with a 0.8, 1.6, or 3.2 microsecond
Guard Interval (GI). The larger GI options provide better protection
against multipath, which is expected to be a challenge in industrial
environments. The possibility of operating with smaller RUs
(e.g., 2 MHz) enabled by OFDMA also helps reduce noise power and
improve Signal-to-Noise Ratio (SNR), leading to better Packet Error Rat
e (PER) performance.</t>
<t>802.11ax supports beamforming as in 802.11ac but introduces UL
MU-MIMO, which helps improve reliability. The UL MU-MIMO capability
is also enabled by the trigger-based access operation in 802.11ax.</t>
</section>
<section><name>Support for 6 GHz Band</name>
<t>The 802.11ax specification <xref target='IEEE80211ax'/> includes
support for operation in the 6 GHz band. Given the amount of new
spectrum available, as well as the fact that no legacy 802.11 device
(prior 802.11ax) will be able to operate in this band, 802.11ax
operation in this new band can be even more efficient.</t>
</section>
</section>
<section><name>Applicability to Deterministic Flows</name> <section><name>Applicability to Deterministic Flows</name>
<t> <t>TSN capabilities, as defined by the IEEE 802.1 TSN standards,
TSN capabilities, as defined by the IEEE 802.1 TSN standa provide the underlying mechanism for supporting deterministic flo
rds, provide the underlying mechanism for supporting deterministic flows in a Lo ws in
cal Area Network (LAN). The 802.11 working group has incorporated support for ab a Local Area Network (LAN). The IEEE 802.11 Working Group has inc
solute time synchronization to extend the TSN 802.1AS protocol so that time-sens orporated
itive flow can experience precise time synchronization when operating over 802.1 support for absolute time synchronization to extend the TSN 802.1
1 links. As IEEE 802.11 and IEEE 802.1 TSN are both based on the IEEE 802 archit AS
ecture, 802.11 devices can directly implement some TSN capabilities without the protocol so that time-sensitive flows can experience precise time
need for a gateway/translation protocol. Basic features required for operation i synchronization when operating over 802.11 links. As IEEE 802.11
n a 802.1Q LAN are already enabled for 802.11. Some TSN capabilities, such as 80 and
2.1Qbv, can already operate over the existing 802.11 MAC SAP <xref target='Sudha IEEE 802.1 TSN are both based on the IEEE 802 architecture, 802.1
karan2021'/>. Implementation and experimental results of TSN capabilities (802.1 1
AS, 802.1Qbv, and 802.1CB) extended over standard Ethernet and Wi-Fi devices hav devices can directly implement some TSN capabilities without the
e also been described in <xref target='Fang_2021'/>. Nevertheless, the IEEE 802. need
11 MAC/PHY could be extended to improve the operation of IEEE 802.1 TSN features for a gateway/translation protocol. Basic features required for
and achieve better performance metrics <xref target='Cavalcanti1287'/>. operation in a 802.1Q LAN are already enabled for 802.11. Some TS
</t><t> N
TSN capabilities supported over 802.11 (which also extends to 80 capabilities, such as 802.1Qbv, can already operate over the exis
2.11ax), include: ting
</t> 802.11 MAC SAP <xref target='Sudhakaran2021'/>. Implementation an
<ol type='%d.'> d
<li> 802.1AS based Time Synchronization (other time synch experimental results of TSN capabilities (802.1AS, 802.1Qbv, and
ronization techniques may also be used) </li> 802.1CB) extended over standard Ethernet and Wi-Fi devices have a
<li> Interoperating with IEEE802.1Q bridges</li> lso
<li> Time-sensitive Traffic Stream Classification</li> been described in <xref target='Fang_2021'/>. Nevertheless, the I
</ol> EEE
<t> 802.11 MAC/PHY could be extended to improve the operation of IEEE
The existing 802.11 TSN capabilities listed above 802.1 TSN features and achieve better performance metrics <xref
, and the 802.11ax OFDMA and AP-controlled access within a BSS provide a new set target='Cavalcanti1287'/>.
of tools to better serve time-sensitive flows. However, it is important to unde </t>
rstand the tradeoffs and constraints associated with such capabilities, as well <t>TSN capabilities supported over 802.11 (which also extends to
as redundancy and diversity mechanisms that can be used to provide more predicta 802.11ax) include:</t>
ble and reliable performance. <ol type='1'>
</t> <li>802.1AS-based time synchronization (other time synchronizat
<section><name> 802.11 Managed Network Operation and Admission Co ion techniques may also be used) </li>
ntrol</name> <li>Interoperating with IEEE 802.1Q bridges</li>
<t> <li>Time-sensitive traffic stream classification</li>
Time-sensitive applications and TSN standards are expecte </ol>
d to operate in a managed network (e.g. industrial/enterprise network). This ena <t>The existing 802.11 TSN capabilities listed above, and the
bles to carefully manage and integrate the Wi-Fi operation with the overall TSN 802.11ax OFDMA and AP-controlled access within a BSS, provide a
management framework, as defined in the <xref target='IEEE802.1Qcc'/> specificat new set of tools to better serve time-sensitive
ion. flows. However, it is important to understand the trade-offs
</t> and constraints associated with such capabilities, as well as
<t> redundancy and diversity mechanisms that can be used to
Some of the random-access latency and interference from l provide more predictable and reliable performance.
egacy/unmanaged devices can be reduced under a centralized management mode as de
fined in <xref target='IEEE802.1Qcc'/>.
</t>
<t>
Existing traffic stream identification, configuration and
admission control procedures defined in <xref target='IEEE80211'/> QoS mechanis
m can be re-used. However, given the high degree of determinism required by many
time-sensitive applications, additional capabilities to manage interference and
legacy devices within tight time-constraints need to be explored.
</t>
</section> <!-- 802.11 Managed network operation and admission co
ntrol -->
<section><name>Scheduling for Bounded Latency and Diversity</name
>
<t>
As discussed earlier, the <xref target='IEEE80211ax'/> OF
DMA mode introduces the possibility of assigning different RUs (time/frequency r
esources) to users within a PPDU. Several RU sizes are defined in the specificat
ion (26, 52, 106, 242, 484, 996 subcarriers). In addition, the AP can also decid
e on MCS (Modulation and Coding Scheme) and grouping of users within a given OFM
DA PPDU. Such flexibility can be leveraged to support time-sensitive application
s with bounded latency, especially in a managed network where stations can be co
nfigured to operate under the control of the AP, in a controlled environment (wh
ich contains only devices operating on the unlicensed band installed by the faci
lity owner and where unexpected interference from other systems and/or radio acc
ess technologies only sporadically happens), or in a deployment where channel/li
nk redundancy is used to reduce the impact of unmanaged devices/interference.
</t> </t>
<t> <section><name>802.11 Managed Network Operation and Admission Con
When the network is lightly loaded, it is possible to ach trol</name>
ieve latencies under 1 msec when Wi-Fi is operated in contention-based (i.e., wi <t>Time-sensitive applications and TSN standards are expected
thout OFDMA) mode. It is also has been shown that it is possible to achieve 1 ms to operate in a managed network (e.g., an industrial/enterprise
ec latencies in controlled environment with higher efficiency when multi-user tr network). This enables careful management and integration of the
ansmissions are used (enabled by OFDMA operation) <xref target='Cavalcanti_2019 Wi-Fi operation with the overall TSN management framework, as
'/>. Obviously, there are latency, reliability and capacity tradeoffs to be cons defined in <xref target='IEEE802.1Qcc'/>.
idered. 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-use
r transmission is a major benefit of the OFDMA mode.
</t> </t>
<t> <t>Some of the random-access latency and interference from
The flexibility to dynamically assign RUs to each transmi legacy/unmanaged devices can be reduced under a centralized
ssion also enables the AP to provide frequency diversity, which can help increas management mode as defined in <xref target='IEEE802.1Qcc'/>.
e reliability.
</t> </t>
</section> <!--Scheduling for bounded latency and diversity--> <t>Existing traffic stream identification, configuration, and
</section> <!-- Applicability to deterministic flows --> admission control procedures defined in the QoS mechanism in <xre
</section><!-- 802.11ax High Efficiency (HE) --> f
target='IEEE80211'/> can be reused. However,
given the high degree of determinism required by many
time-sensitive applications, additional capabilities to manage
interference and legacy devices within tight time constraints
need to be explored.</t>
</section>
<section anchor="EHT"><name>802.11be Extreme High Throughput (EHT)</name <!-- [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 where stations can be
configured to operate under the control of the AP, in a controlled
environment (which contains only devices operating on the unlicensed band
installed by the facility owner and where unexpected interference from
other systems and/or radio access technologies only sporadically happens),
or in a deployment where channel/link redundancy is used to reduce the
impact of unmanaged devices/ interference.
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 for Bounded Latency and Diversity</name>
<t>As discussed earlier, the
OFDMA mode in <xref target='IEEE80211ax'/> introduces the possi
bility 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 ca
n
also decide on a Modulation and Coding Scheme (MCS) and
grouping of users within a given OFMDA PPDU. Such
flexibility can be leveraged to support time-sensitive
applications with bounded latency, especially in a managed
network where stations can be configured to operate under
the control of the AP, in a controlled environment (which
contains only devices operating on the unlicensed band
installed by the facility owner and where unexpected
interference from other systems and/or radio access
technologies only sporadically happens), or in a deployment
where channel and link redundancy is used to reduce the impact
of unmanaged devices and interference.</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-bas
ed mode
(i.e., without OFDMA). It 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, the
re
are latency, reliability, and capacity trade-offs to be considere
d. For
instance, smaller RUs result in longer transmission durations, wh
ich
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 flexibility to dynamically assign RUs to each transmission also
enables the AP to provide frequency diversity, which can help increase
reliability.</t>
</section>
</section>
</section>
<section anchor="EHT">
<name>802.11be Extreme High Throughput (EHT)</name>
<section><name>General Characteristics</name> <section><name>General Characteristics</name>
<t> <t><xref target='IEEE80211be'/> was the next
The <xref target='IEEE80211be'/> ammendment was major 802.11 amendment (after IEEE Std 802.11ax-2021) for
the next major 802.11 amendment (after IEEE Std 802.11ax-2021) for operation in operation in the 2.4, 5, and 6 GHz bands. 802.11be includ
the 2.4, 5 and 6 GHz bands. 802.11be includes new PHY and MAC features and it is es new
targeting extremely high throughput (at least 30 Gbps), as well as enhancements PHY and MAC features, and it is targeting extremely high
to worst case latency and jitter. It is also expected to improve the integratio throughput (at least 30 Gbps), as well as enhancements to
n with 802.1 TSN to support time-sensitive applications over Ethernet and Wirele worst-case latency and jitter. It is also expected to imp
ss LANs. rove
</t> the integration with 802.1 TSN to support time-sensitive
<t> applications over Ethernet and Wireless LANs.</t>
<t>The main features of 802.11be that are relevant to thi
s document include:</t>
<ol type='1'>
<li>320 MHz bandwidth and more efficient utilization of
non-contiguous spectrum</li>
<li>Multi-Link Operation (MLO)</li>
<li>QoS enhancements to reduce latency and increase rel
iability</li>
</ol>
</section>
The 802.11be main features relevant to th <!-- [rfced] How may we clarify "and potential solution directions"?
is document include:
</t><ol type='%d.'> Original:
<li> 320MHz bandwidth and more efficient The 802.11 Real-Time Applications (RTA) Topic Interest Group (TIG)
utilization of non-contiguous spectrum. </li> provided detailed information on use cases, issues and potential
<li> Multi-link operation. </li> solution directions to improve support for time-sensitive
<li> QoS enhancements to reduce latency a applications in 802.11.
nd increase reliability. </li>
</ol><t> Perhaps:
</t> The 802.11 Real-Time Applications (RTA) Topic Interest Group (TIG)
</section> <!-- General Characteristics--> provided detailed information on use cases, issues, and a potential
<section><name>Applicability to Deterministic Flows</name> solution to improve support for time-sensitive
<t> applications in 802.11.
The 802.11 Real-Time Applications (RTA) Topic Int -->
erest Group (TIG) provided detailed information on use cases, issues and potenti
al solution directions to improve support for time-sensitive applications in 802 <section>
.11. The RTA TIG report <xref target='IEEE_doc_11-18-2009-06'/> was used as inpu <name>Applicability to Deterministic Flows</name>
t to the 802.11be project scope. <t>The 802.11 Real-Time Applications (RTA) Topic Intere
</t> st
<t> Group (TIG) provided detailed information on use cases,
Improvements for worst-case latency, jitter and r issues, and potential solution directions to improve su
eliability were the main topics identified in the RTA report, which were motivat pport
ed by applications in gaming, industrial automation, robotics, etc. The RTA repo for time-sensitive applications in 802.11. The RTA TIG
rt also highlighted the need to support additional TSN capabilities, such as tim report <xref target='IEEE_doc_11-18-2009-06'/> was used
e-aware (802.1Qbv) shaping and packet replication and elimination as defined in as
802.1CB. input to the 802.11be project scope.</t>
</t>
<t> <t>Improvements for worst-case latency, jitter, and
IEEE Std 802.11be builds on and enhances 802.11ax reliability were the main topics identified in the RTA
capabilities to improve worst case latency and jitter. Some of the enhancement report, which were motivated by applications in gaming,
areas are discussed next. industrial automation, robotics, etc. The RTA report al
</t> so
<section><name>Enhanced Scheduled Operation for Bounded L highlighted the need to support additional TSN capabili
atency </name> ties,
<t> such as time-aware (802.1Qbv) shaping and packet replic
In addition to the throughput enhancement ation
s, 802.11be leverages the trigger-based scheduled operation enabled by 802.11ax and elimination as defined in 802.1CB.
to provide efficient and more predictable medium access.
</t> </t>
<t> <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>
802.11be introduced QoS signaling <section>
enhancements, such as an additional QoS characteristics element, that enables S <name>Enhanced Scheduled Operation for Bounded Latency</n
TAs to provide detailed information about deterministic traffic stream to the AP ame>
. This capability helps AP implementations to better support scheduling for dete <t>In addition to the throughput enhancements,
rministic flows. 802.11be leverages the trigger-based scheduled
operation enabled by 802.11ax to provide efficien
t and
more predictable medium access.
</t>
<t>802.11be introduced QoS signaling enhancements,
such as an additional QoS characteristics element,
that enables stations to provide detailed information
about deterministic traffic stream to the AP. This
capability helps AP implementations to better support
scheduling for deterministic flows.</t>
</section>
</t>
</section> <!-- Enhanced scheduled operation for bounded
latency -->
<!--section><name>Multi-AP Coordination</name> <!--section><name>Multi-AP Coordination</name>
<t> <t>
Multi-AP coordination is one of the main new candidate features in 802.11be. It can provide benefits in throughput and ca pacity and has the potential to address some of the issues that impact worst cas e latency and reliability. Multi-AP coordination is one of the main new candidate features in 802.11be. It can provide benefits in throughput and ca pacity and has the potential to address some of the issues that impact worst cas e latency and reliability.
Multi-AP coordination is expected to addr ess the contention due to overlapping Basic Service Sets (OBSS), which is one of the main sources of random latency variations. Multi-AP coordination is expected to addr ess the contention due to overlapping Basic Service Sets (OBSS), which is one of the main sources of random latency variations.
</t> </t>
<t> Overall, multi-AP coordination algorithms consider three different phases: <t> Overall, multi-AP coordination algorithms consider three different phases:
setup (where APs handling overlapping BSSs are assigned roles in a manual setup (where APs handling overlapping BSSs are assigned roles in a manual
or automated way, e.g., coordinator and coordinated APs); coordination or automated way, e.g., coordinator and coordinated APs); coordination
(where APs establish links among themselves, e.g., from a coordinating AP (where APs establish links among themselves, e.g., from a coordinating AP
to coordinated APs; and then assign resources to served stations); to coordinated APs; and then assign resources to served stations);
transmission (where the coordinating APs optimize the distribution of the transmission (where the coordinating APs optimize the distribution of the
transmission opportunities). transmission opportunities).
</t> </t>
<t> <t> Several multi-AP coordination approaches have been
Several multi-AP coordination approaches discussed with different levels of complexities and
have been discussed with different levels of complexities and benefits, but spec benefits, but specific coordination methods have not
ific coordination methods have not yet been defined. Out of the different yet been defined. Out of the different categories,
categories, MAC-driven examples include: coordinated OFDMA (Co-OFDMA); MAC-driven examples include: coordinated OFDMA
Coordinated TDMA (Co-TDMA); HARQ; whereas PHY-driven examples include: (Co-OFDMA); Coordinated TDMA (Co-TDMA); HARQ; whereas
Coordinated Spatial Reuse (Co-SR) and Coordinated Beamforming (Co-BF). PHY-driven examples include: Coordinated Spatial Reuse
(Co-SR) and Coordinated Beamforming (Co-BF).
</t> </t>
</section> Multi-AP coordination --> </section> Multi-AP coordination -->
<section><name>Multi-link operation</name> <section>
<t> <name>Multi-Link Operation</name>
802.11be introduces new features to impro <t>802.11be introduces new features to improve operation over
ve operation over multiple links and channels. By leveraging multiple links/chan multiple links and channels. By leveraging multiple links and channels,
nels, 802.11be can isolate time-sensitive traffic from network congestion, one o 802.11be can isolate time-sensitive traffic from network congestion,
f the main causes of large latency variations. In a managed 802.11be network, it one of the main causes of large latency variations. In a managed
should be possible to steer traffic to certain links/channels to isolate time-s 802.11be network, it should be possible to steer traffic to certain
ensitive traffic from other traffic and help achieve bounded latency. links and channels to isolate time-sensitive traffic from other traffic
The multi-link operation (MLO) is and help achieve bounded latency. The Multi-Link Operation (MLO) is
a major feature in the 802.11be amendment that can enhance latency and reliabil a major feature in the 802.11be amendment that can enhance latency
ity by enabling data frames to be duplicated across links. and reliability by enabling data frames to be duplicated across
</t> links.</t>
</section> <!--Multi-link operation--> </section>
</section> </section>
</section><!-- 802.11be Extreme High Throughput (EHT) --> </section>
<section><name>802.11ad and 802.11ay (mmWave operation)</name> <section>
<section><name>General Characteristics</name> <name>802.11ad and 802.11ay (mmWave Operation)</name>
<t> <section>
The IEEE 802.11ad amendment defines PHY and MAC c <name>General Characteristics</name>
apabilities to enable multi-Gbps throughput in the 60 GHz millimeter wave (mmWav <t>The IEEE 802.11ad amendment defines PHY and MAC
e) band. The standard addresses the adverse mmWave signal propagation characteri capabilities to enable multi-Gbps throughput in the 60
stics and provides directional communication capabilities that take advantage of GHz millimeter wave (mmWave) band. The standard
beamforming to cope with increased attenuation. An overview of the 802.11ad sta addresses the adverse mmWave signal propagation
ndard can be found in <xref target='Nitsche_2015'/>. characteristics and provides directional communication
</t> capabilities that take advantage of beamforming to
<t> cope with increased attenuation. An overview of the
The IEEE 802.11ay is currently developing enhance 802.11ad standard can be found in <xref
ments to the 802.11ad standard to enable the next generation mmWave operation ta target='Nitsche_2015'/>.</t>
rgeting 100 Gbps throughput. Some of the main enhancements in 802.11ay include M <t>The IEEE 802.11ay is currently developing enhancements to the
IMO, channel bonding, improved channel access and beamforming training. An overv 802.11ad standard to enable the next generation mmWave operation
iew of the 802.11ay capabilities can be found in <xref target='Ghasempour_2017'/ targeting 100 Gbps throughput. Some of the main enhancements in
>. 802.11ay include MIMO, channel bonding, improved channel access, and
</t> beamforming training. An overview of the 802.11ay capabilities can be
</section><!--General Characteristics --> found in <xref target='Ghasempour_2017'/>.</t>
<section><name>Applicability to deterministic flows</name> </section>
<t>
The high data rates achievable with 802.11ad and
802.11ay can significantly reduce latency down to microsecond levels. Limited in
terference from legacy and other unlicensed devices in 60 GHz is also a benefit.
However, directionality and short range typical in mmWave operation impose new
challenges such as the overhead required for beam training and blockage issues,
which impact both latency and reliability. Therefore, it is important to underst
and the use case and deployment conditions in order to properly apply and config
ure 802.11ad/ay networks for time sensitive applications.
</t>
<t>
The 802.11ad standard includes a scheduled access
mode in which the central controller, after contending and reserving the channe
l for a dedicated period, can allocate to stations contention-free service perio
ds. This scheduling capability is also available in 802.11ay, and it is one of t
he mechanisms that can be used to provide bounded latency to time-sensitive data
flows in interference-free scenarios. An analysis of the theoretical latency bo
unds that can be achieved with 802.11ad service periods is provided in <xref tar
get='Cavalcanti_2019'/>.
</t>
</section> <!-- Applicability to deterministic flows-->
</section><!-- 802.11ad and 802.11ay (mmWave operation) -->
</section><!-- title="IEEE 802.11" --> <section>
<name>Applicability to 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 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>
</section>
</section>
<section><name>IEEE 802.15.4 Timeslotted Channel Hopping </name> <section><name>IEEE 802.15.4 Time-Slotted Channel Hopping (TSCH)</name>
<t> IEEE Std 802.15.4 TSCH was the first IEEE radio specification aimed <t>IEEE Std 802.15.4 TSCH was the first IEEE radio specification aimed
directly at Industrial IoT applications, for use in directly at industrial IoT applications, for use in process control
Process Control loops and monitoring. It was used as a base for the maj loops and monitoring. It was used as a base for the major industrial
or wireless process control standards, Wireless Highway Addressable Remote
industrial wireless process control standards, Wireless HART and ISA100 Transducer Protocol (HART) and ISA100.11a.
.11a. </t>
</t><t> <t>While the MAC/PHY standards enable the relatively slow rates used in
While the MAC/PHY standards enable the relatively slow rates used in Pr process control (typically in the order of 4-5 per second), the
ocess technology is not suited for the faster periods used in
Control (typically in the order of 4-5 per second), the technology is n factory automation and motion control (1 to 10 ms).</t>
ot suited for the faster periods (1 to 10ms) used in Factory Automation and moti
on control.
</t>
<section><name>Provenance and Documents</name> <section>
<t> <name>Provenance and Documents</name>
The IEEE802.15.4 Task Group has been driving the development of low-power <t>The IEEE 802.15.4 Task Group has been driving the development of
low-cost radio technology. low-power, low-cost radio technology. The IEEE 802.15.4 physical layer has
The IEEE802.15.4 physical layer has been designed to support demanding been designed to support demanding low-power scenarios targeting the use of
low-power scenarios targeting the use of unlicensed bands, both the 2.4 GHz unlicensed bands, both the 2.4 GHz and sub-GHz Industrial, Scientific and
and sub GHz Industrial, Scientific and Medical (ISM) bands. This has imposed Medical (ISM) bands. This has imposed requirements in terms of frame size,
requirements in terms of frame size, data rate and bandwidth to achieve data rate, and bandwidth to achieve reduced collision probability, reduced
reduced collision probability, reduced packet error rate, and acceptable packet error rate, and acceptable range with limited transmission
range with limited transmission power. The PHY layer supports frames of up to power. The PHY layer supports frames of up to 127 bytes. The Medium Access
127 bytes. The Medium Access Control (MAC) sublayer overhead is in the order Control (MAC) sublayer overhead is in the order of 10-20 bytes, leaving
of 10-20 bytes, leaving about 100 bytes to the upper layers. IEEE802.15.4 about 100 bytes to the upper layers. IEEE 802.15.4 uses spread spectrum
uses spread spectrum modulation such as the Direct Sequence Spread modulation such as the Direct Sequence Spread Spectrum (DSSS).
Spectrum (DSSS).
</t> </t>
<t> <t>
The Timeslotted Channel Hopping (TSCH) mode was added to the 2015 revision of The Time-Slotted Channel Hopping (TSCH) mode was added to the 2015 revision o
the IEEE802.15.4 standard <xref target='IEEE802154'/>. TSCH is f
the IEEE 802.15.4 standard <xref target='IEEE802154'/>. TSCH is
targeted at the embedded and industrial world, where reliability, energy targeted at the embedded and industrial world, where reliability, energy
consumption and cost drive the application space. consumption, and cost drive the application space.
</t> </t>
<!-- TSN-like activities, past and present (introduce the likes of as OFDMA, URLLC and EHT) --> <!-- TSN-like activities, past and present (introduce the likes of as OFDMA, URLLC and EHT) -->
<t> <t>
Time sensitive networking on low power constrained wireless networks, buildin Building on IEEE 802.15.4, TSN on low-power constrained wireless networks
g on IEEE802.15.4, has been partially addressed by ISA100.11a <xref target='ISA100.11a'/> and Wi
have been partially addressed by ISA100.11a <xref target='ISA100.11a'/> and relessHART
WirelessHART <xref target='WirelessHART'/>. Both technologies <xref target='WirelessHART'/>. Both technologies
involve a central controller that computes redundant paths for industrial involve a central controller that computes redundant paths for industrial
process control traffic over a TSCH mesh. Moreover, ISA100.11a introduces process control traffic over a TSCH mesh. Moreover, ISA100.11a introduces
IPv6 <xref target='RFC8200'/> capabilities with a Link-Local Address for the join process and a IPv6 capabilities <xref target='RFC8200'/> with a link-local address for the join process and a
global unicast address for later exchanges, but the IPv6 traffic typically 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 ends at a local application gateway and the full power of IPv6 for end-to-end
communication is not enabled. communication is not enabled.
</t> </t>
<t> <t>
At the IETF, the 6TiSCH working group <xref target='TiSCH'/> has At the IETF, the 6TiSCH Working Group <xref target='TiSCH'/> has
enabled distributed routing and scheduling to exploit the deterministic enabled distributed routing and scheduling to exploit the deterministic
access capabilities provided by TSCH for IPv6. The group designed the essenti al access capabilities provided by TSCH for IPv6. The group designed the essenti al
mechanisms, the 6top layer and the Scheduling Functions (SFs), to enable mechanisms, the 6TiSCH Operation (6top) sublayer and the Scheduling Functions (SFs), to enable
the management plane operation while ensuring IPv6 is the management plane operation while ensuring IPv6 is
supported: supported.
</t> </t>
<ul> <ul>
<li> <li>The 6top Protocol (6P) is defined in <xref target='RFC8480'/> and
</li><li> provides a pairwise negotiation mechanism to the control plane operation.
The 6top Protocol (6P) defined in <xref target='RFC8480'/>. The protocol supports agreement on a schedule between neighbors, enabling
The 6P Protocol provides a pairwise negotiation mechanism to the control plan distributed scheduling.</li>
e operation. <li>6P goes hand in hand with an SF, the policy that decides how to
The protocol supports agreement on a schedule between neighbors, enabling maintain cells and trigger 6P transactions. The Minimal Scheduling Function
distributed scheduling. (MSF) <xref target='RFC9033'/> is the default SF defined by the 6TiSCH
</li><li>6P goes hand-in-hand with an SF, the policy that decides WG.</li>
how to maintain cells and trigger 6P transactions. The Minimal Scheduling <!-- [rfced] We were unable to find RPL explicitly mentioned in RFC
Function (MSF) <xref target='RFC9033'/> is the default SF defined 8480. Should this citation be updated? Perhaps to [RFC6550]?
by the 6TiSCH WG.
</li><li>With these mechanisms 6TiSCH can establish layer 2 links between nei Original:
ghbouring nodes and
support best effort traffic. RPL <xref target='RFC8480'/> provides the routin RPL [RFC8480] provides the routing structure, enabling the 6TiSCH devices
g structure, to establish the links with well connected neighbours and thus forming the
enabling the 6TiSCH devices to establish the links with well connected neighb acyclic network graphs.
ours and thus -->
forming the acyclic network graphs.
</li> <li>With these mechanisms, 6TiSCH can establish Layer 2 links between
neighboring nodes and support best-effort traffic. The Routing Protocol for
Low-Power and Lossy Networks (RPL) <xref
target='RFC8480'/> provides the routing structure, enabling the 6TiSCH
devices to establish the links with well-connected neighbors, thus
forming the acyclic network graphs.</li>
</ul> </ul>
<!-- [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> <t>
A Track at 6TiSCH is the application to wireless of the concept of a Recovery Graph in A Track at 6TiSCH is the application to wireless of the concept of a recovery graph in
the RAW architecture. the RAW architecture.
A Track can follow a simple sequence of relay nodes or can be structured as a A Track can follow a simple sequence of relay nodes, or it can be structured
more complex Destination Oriented Directed Acyclic Graph (DODAG) to a unicast as a
more complex Destination-Oriented Directed Acyclic Graph (DODAG) to a unicast
destination. Along a Track, 6TiSCH nodes reserve the resources to enable the destination. Along a Track, 6TiSCH nodes reserve the resources to enable the
efficient transmission of packets while aiming to optimize certain properties efficient transmission of packets while aiming to optimize certain properties
such as reliability and ensure small jitter or bounded latency. The Track such as reliability and ensure small jitter or bounded latency. The Track
structure enables Layer-2 forwarding schemes, reducing the overhead of taking structure enables Layer 2 forwarding schemes, reducing the overhead of making
routing decisions at the Layer-3. routing decisions at Layer 3.
</t> </t>
<!-- DetNet-like arching art (introduce the likes of ISA100.11a or WiHART) --> <!-- DetNet-like arching art (introduce the likes of ISA100.11a or WiHART) -->
<t> <t>
The 6TiSCH architecture <xref target='RFC9030'/> The 6TiSCH architecture <xref target='RFC9030'/>
identifies different models to schedule resources along so-called Tracks identifies different models to schedule resources along so-called Tracks
(see <xref target='Tracks'/>) exploiting the (see <xref target='Tracks'/>), exploiting the
TSCH schedule structure however the focus at 6TiSCH is on best effort traffic TSCH schedule structure; however, the focus in 6TiSCH is on best-effort traff
and the group was never chartered to produce standard work related to Tracks. ic,
and the group was never chartered to produce standards work related to Tracks
.
</t> </t>
<t> <t>
There are several works that can be used to complement the overview provided in this document. There are several works that can be used to complement the overview provided in this document.
For example <xref target='vilajosana21'/> provides a detailed description of For example, <xref target='vilajosana21'/> provides a detailed description of
the 6TiSCH protocols, the 6TiSCH protocols,
how they are linked together and how they are integrated with other standards how they are linked together, and how they are integrated with other standard
like RPL and 6Lo. s like RPL and 6Lo.
<!-- <!--
<xref target='morell13'/> introduces how label switching can be implemented i n a TSCH network. <xref target='morell13'/> introduces how label switching can be implemented i n a TSCH network.
It proposes a policy to distribute labels in multihop network so as to enable differential services 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 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 r eplication and path diversity at layer 3, considering and IEEE802.15.4 TSCH network and exploiting packet r eplication and path diversity
for that aim.--> for that aim.-->
</t> </t>
</section>
</section><!--Provenance and Documents--> <!-- [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 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> <section><name>General Characteristics</name>
<t> <t>
As a core technique in IEEE802.15.4, TSCH splits time in multiple time slots As a core technique in IEEE 802.15.4, TSCH splits time in multiple time slots
that repeat over time. Each device has its own perspective of when the send that repeat over time. Each device has its own perspective of when the send o
or receive and on which channel the transmission happens. This constitutes r receive occurs and
the device's Slotframe where the channel and destination of a transmission by on which channel the transmission happens. This constitutes
the device's Slotframe, where the channel and destination of a transmission b
y
this device are a function of time. this device are a function of time.
The overall aggregation of all the Slotframes of all the devices constitutes 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 a time/frequency matrix with at most one transmission in each cell of the
matrix (more in <xref target='slotFrames'/>). matrix (see more in <xref target='slotFrames'/>).
</t> </t>
<t> <t>
The IEEE 802.15.4 TSCH standard does not define any scheduling mechanism but The IEEE 802.15.4 TSCH standard does not define any scheduling mechanism
only provides the architecture that establishes a slotted structure that can but only provides the architecture that establishes a slotted structure
be that can be managed by a proper schedule. This schedule represents the
managed by a proper schedule. This schedule represents the possible communica possible communications of a node with its neighbors and is managed by a
tions of a node with its Scheduling Function such as the Minimal Scheduling Function (MSF) <xref
neighbors, and is managed by a Scheduling Function such as the Minimal target='RFC9033'/>. In MSF, each cell in the schedule is identified by its
Scheduling Function (MSF) <xref target='RFC9033'/>. In MSF, each cell in slotoffset and channeloffset coordinates. A cell's timeslot offset
the schedule is identified by its slotoffset and channeloffset coordinates. A indicates its position in time, relative to the beginning of the
cell's timeslot offset indicates its position in time, relative to the slotframe. A cell's channel offset is an index that maps to a frequency at
beginning of the slotframe. A cell's channel offset is an index which maps to each iteration of the slotframe. Each packet exchanged between neighbors
a frequency at each iteration of the slotframe. Each packet exchanged between happens within one cell. The size of a cell is a timeslot duration, between
neighbors happens within one cell. The size of a cell is a timeslot duration, 10 to 15 milliseconds. An Absolute Slot Number (ASN) indicates the number
between 10 to 15 milliseconds. An Absolute Slot Number (ASN) indicates of slots elapsed since the network started. It increments at every
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 slot. This is a 5-byte counter that can support networks running for more
than 300 years without wrapping (assuming a 10-ms timeslot). Channel hopping than 300 years without wrapping (assuming a 10 ms timeslot). Channel
provides increased reliability to multi-path fading and external hopping provides increased reliability to multipath fading and external
interference. It is handled by TSCH through a channel hopping sequence interference. It is handled by TSCH through a channel-hopping sequence
referred as macHopSeq in the IEEE802.15.4 specification. referred to as macHopSeq in the IEEE 802.15.4 specification.
</t> </t>
<t> <t>
<!-- bandwidth, beam forming--> <!-- bandwidth, beam forming-->
The Time-Frequency Division Multiple Access provided by TSCH enables the The Time-Frequency Division Multiple Access provided by TSCH enables the
orchestration of traffic flows, spreading them in time and frequency, orchestration of traffic flows, spreading them in time and frequency,
and hence enabling an efficient management of the bandwidth utilization. and hence enabling an efficient management of the bandwidth utilization.
Such efficient bandwidth utilization can be combined with OFDM modulations Such efficient bandwidth utilization can be combined with OFDM modulations
also supported by the IEEE802.15.4 standard <xref target='IEEE802154'/> also supported by the IEEE 802.15.4 standard <xref target='IEEE802154'/>
since the 2015 version. since the 2015 version.
</t> </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> <t>
<!-- spectrum --> <!-- spectrum -->
TSCH networks operate in ISM bands in which the spectrum is shared by differ TSCH networks operate in ISM bands in which the spectrum is shared by
ent coexisting technologies. different coexisting technologies. Regulations such as the FCC, ETSI, and
Regulations such as FCC, ETSI and ARIB impose duty cycle regulations to limi ARIB impose duty cycle regulations to limit the use of the bands, but
t the use of the bands but yet interference may constraint the probability to de interference may still constrain the probability of delivering a packet. Pa
liver a packet. rt of
Part of these reliability challenges are addressed at the MAC introducing re these reliability challenges are addressed at the MAC introducing
dundancy and diversity, thanks to channel hopping, scheduling and ARQ policies. redundancy and diversity, thanks to channel hopping, scheduling, and ARQ
Yet, the MAC layer operates with a 1-hop vision, being limited to local acti policies. Yet, the MAC layer operates with a 1-hop vision, being limited
ons to mitigate underperforming links. to local actions to mitigate underperforming links.
<!-- Pascal-> not sure if you want to mention here about the capability prov ided by RAW to determine the best path regardless of the performance of a partic ular link --> <!-- Pascal-> not sure if you want to mention here about the capability prov ided by RAW to determine the best path regardless of the performance of a partic ular link -->
</t> </t>
<section anchor='Tracks'><name>6TiSCH Tracks</name> <section anchor='Tracks'><name>6TiSCH Tracks</name>
<t> <t>
A Track in the 6TiSCH Architecture <xref target='RFC9030'/> A Track in the 6TiSCH architecture <xref target='RFC9030'/> is the
is the application to 6TiSCH networks of the concept of a protection path in application to 6TiSCH networks of the concept of a protection path in the Det
the <xref target='RFC8655'>"Detnet architecture"</xref>. Net architecture <xref target='RFC8655'/>. A Track can be
A Track can be structured as a Destination Oriented Directed Acyclic Graph structured as a Destination-Oriented Directed Acyclic Graph (DODAG) to a
(DODAG) to a destination for unicast traffic. destination for unicast traffic. Along a Track, 6TiSCH nodes reserve the
Along a Track, 6TiSCH nodes reserve the resources to enable the resources to enable the efficient transmission of packets while aiming to
efficient transmission of packets while aiming to optimize certain properties optimize certain properties such as reliability and ensure small jitter or
such as reliability and ensure small jitter or bounded latency. The Track bounded latency. The Track structure enables Layer 2 forwarding schemes,
structure enables Layer-2 forwarding schemes, reducing the overhead of taking reducing the overhead of making routing decisions at Layer 3.
routing decisions at the Layer-3.
</t> </t>
<t> <t>
Serial Tracks can be understood as the concatenation of cells or bundles 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 along a routing path from a source towards a destination. The serial Track
concept is analogous to the circuit concept where resources are chained concept is analogous to the circuit concept where resources are chained
into a multi-hop topology, more in <xref target='fwd'/> on how that is used into a multi-hop topology; see more in <xref target='fwd'/> on how that is us ed
in the data plane to forward packets. in the data plane to forward packets.
</t> </t>
<t> <t>
Whereas scheduling ensures reliable delivery in bounded time along any Track, Whereas scheduling ensures reliable delivery in bounded time along any Track,
high availability requires the application of PREOF functions along a more high availability requires the application of PREOF functions along a more
complex DODAG Track structure. A DODAG has forking and joining nodes where complex DODAG Track structure. A DODAG has forking and joining nodes where
the concepts such as Replication and Elimination can be exploited. concepts like replication and elimination can be exploited.
Spatial redundancy increases the overall energy consumption in the network bu t Spatial redundancy increases the overall energy consumption in the network bu t
improves significantly the availability of the network as well as the packet significantly improves the availability of the network as well as the packet
delivery ratio. delivery ratio.
A Track may also branch off and rejoin, for the purpose of the so-called A Track may also branch off and rejoin, for the purpose of so-called
Packet Replication and Elimination (PRE), over non congruent branches. Packet Replication and Elimination (PRE), over non-congruent branches. PRE
PRE may be used to complement layer-2 ARQ and may be used to complement Layer 2 ARQ and receiver-end ordering to
receiver-end Ordering to complete/extend the PREOF functions. This enables complete/extend the PREOF functions. This enables meeting industrial
meeting industrial expectations of packet delivery within bounded delay expectations of packet delivery within bounded delay over a Track that
over a Track that includes wireless links, even when the Track includes wireless links, even when the Track extends beyond the 6TiSCH
extends beyond the network.
6TiSCH network.
</t> </t>
<t>The RAW Track described in the RAW Architecture <t>The RAW Track described in the RAW architecture <xref target='RFC9912'/>
<xref target='I-D.ietf-raw-architecture'/> inherits directly from that model. inherits directly from that model. RAW extends the graph beyond a DODAG as
RAW extends the graph beyond a DODAG as long as a given packet cannot loop long as a given packet cannot loop within the Track.</t>
within the Track. <figure anchor='fig4'><name>End-to-End Deterministic Track</name>
</t> <artwork><![CDATA[
<figure anchor='fig4'><name>End-to-End deterministic Track</name>
<artwork><![CDATA[
+-----+ +-----+
| IoT | | IoT |
| G/W | | G/W |
+-----+ +-----+
^ <---- Elimination ^ <---- Elimination
| | | |
Track branch | | Track branch | |
+-------+ +--------+ Subnet Backbone +-------+ +--------+ Subnet backbone
| | | |
+--|--+ +--|--+ +--|--+ +--|--+
| | | Backbone | | | Backbone | | | Backbone | | | Backbone
o | | | router | | | router o | | | router | | | router
+--/--+ +--|--+ +--/--+ +--|--+
o / o o---o----/ o o / o o---o----/ o
o o---o--/ o o o o o o o---o--/ o o o o o
o \ / o o LLN o o \ / o o LLN o
o v <---- Replication o v <---- Replication
o o
skipping to change at line 730 skipping to change at line 1183
| | | |
+--|--+ +--|--+ +--|--+ +--|--+
| | | Backbone | | | Backbone | | | Backbone | | | Backbone
o | | | router | | | router o | | | router | | | router
+--/--+ +--|--+ +--/--+ +--|--+
o / o o---o----/ o o / o o---o----/ o
o o---o--/ o o o o o o o---o--/ o o o o o
o \ / o o LLN o o \ / o o LLN o
o v <---- Replication o v <---- Replication
o o
]]></artwork> ]]></artwork>
</figure> </figure>
<t>In the example above (see <xref target='fig4'/>), a Track is laid out <t>In <xref target='fig4'/>, a Track is laid out
from a field device in a 6TiSCH network to an IoT gateway that is located from a field device in a 6TiSCH network to an IoT gateway that is located
on a IEEE802.1 TSN backbone. on an IEEE 802.1 TSN backbone.
</t> </t>
<t> <t>
The Replication function in the field device sends a copy of each packet 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 over two different branches, and a PCE schedules each hop of both branches
so that the two so that the two
copies arrive in due time at the gateway. In case of a loss on one branch, 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 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 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. ignores the extra packet and presents only one copy to upper layers.
</t> </t>
<t> <t>
At each 6TiSCH hop along the Track, the PCE may schedule more than one At each 6TiSCH hop along the Track, the PCE may schedule more than one
timeSlot for a packet, so as to support Layer-2 retries (ARQ). It is also timeSlot for a packet, so as to support Layer 2 retries (ARQ). It is also
possible that the field device only uses the second branch if sending over possible for the field device to only use the second branch if sending ove
r
the first branch fails. the first branch fails.
</t> </t>
<t> <t>
In current deployments, a TSCH Track does not necessarily support PRE but In current deployments, a TSCH Track does not necessarily support PRE but
is systematically multi-path. This means that a Track is scheduled so as is systematically multipath. This means that a Track is scheduled so as
to ensure that each hop has at least two forwarding solutions, and the 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 forwarding decision is to try the preferred one and use the other in
case of Layer-2 transmission failure as detected by ARQ. case of Layer 2 transmission failure as detected by ARQ.
</t> </t>
<t>Methods to implement complex Tracks are described <t>Methods to implement complex Tracks are described
in <xref target='I-D.ietf-roll-dao-projection'/> and complemented by in <xref target='RFC9914'/> and complemented by
extensions to the RPL routing protocol in extensions to the RPL routing protocol in
<xref target='I-D.ietf-roll-nsa-extension'/> for best effort traffic, but a <xref target='I-D.ietf-roll-nsa-extension'/> for best-effort traffic, but a
centralized routing technique such as promoted in DetNet is still missing. centralized routing technique such as one promoted in DetNet is still missing
.
</t> </t>
<section anchor='Tschd'><name>Track Scheduling Protocol</name> <section anchor='Tschd'>
<t> <name>Track Scheduling Protocol</name>
Section "Schedule Management Mechanisms" of the 6TiSCH architecture <t>Section <xref section="4.4" sectionFormat="bare" target="RFC9030"/> of
describes 4 approaches to manage the TSCH schedule of the LLN nodes: the 6TiSCH architecture <xref target="RFC9030"/> describes four
Static Scheduling, neighbor-to-neighbor Scheduling, remote monitoring approaches to manage the TSCH schedule of the Low-Power and Lossy Network (
and scheduling management, and Hop-by-hop scheduling. LLN) nodes: static
The Track operation for DetNet corresponds to a remote monitoring and scheduling, neighbor-to-neighbor scheduling, remote monitoring and
scheduling management by a PCE. scheduling management, and hop-by-hop scheduling. The Track operation
for DetNet corresponds to a remote monitoring and scheduling management
by a PCE.
</t> </t>
</section> </section>
<section anchor='fwd'><name>Track Forwarding</name> <section anchor='fwd'><name>Track Forwarding</name>
<t> <t>In the 6TiSCH architecture <xref target='RFC9030'/>, forwarding is
By forwarding, the 6TiSCH Architecture <xref target='RFC9030'/> means the per-packet operation that allows a packet to be delivered to a next ho
the per-packet operation that allows delivering a packet to a next hop p
or an upper layer in this node. or an upper layer in a node. Forwarding is based on preexisting
Forwarding is based on pre-existing state that was installed as a state that was installed as a result of the routing computation of a
result of the routing computation of a Track by a PCE. Track by a PCE. The 6TiSCH architecture supports three different
The 6TiSCH architecture supports three different forwarding model, forwarding models: GMPLS Track Forwarding (TF), 6LoWPAN Fragment
G-MPLS Track Forwarding (TF), 6LoWPAN Fragment Forwarding (FF) and Forwarding (FF), and IPv6 Forwarding (6F), which is the classical IP
IPv6 Forwarding (6F) which is the classical IP operation operation <xref target='RFC9030'/>. The DetNet case relates to the
<xref target='RFC9030'/>. Track Forwarding operation under the control of a PCE.
The DetNet case relates to the Track Forwarding operation under the
control of a PCE.
</t> </t>
<t> <t>
A Track is a unidirectional path between a source and a destination. A Track is a unidirectional path between a source and a destination.
Time/Frequency resources called cells (see <xref target='slotFrames' />) Time and frequency resources called cells (see <xref target='slotFra mes'/>)
are allocated to enable the forwarding operation along the Track. are allocated to enable the forwarding operation along the Track.
In a Track cell, the normal operation of IEEE802.15.4 In a Track cell, the normal operation of IEEE 802.15.4
ARQ usually happens, though the ARQ usually happens, though the
acknowledgment may be omitted in some cases, for instance if there acknowledgment may be omitted in some cases, for instance, if there
is no scheduled cell for a retry. is no scheduled cell for a retry.
</t> </t>
<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 forwarding
state that can be used regardless of the network layer protocol.
This model can effectively be seen as a Generalized Multi-protocol
Label Switching (G-MPLS) operation in that the information used to
switch a frame is not an explicit label, but rather related to other <!-- [rfced] Should "simplest and fastest" be updated to "simplest and fastest
properties of the way the packet was received, a particular cell in operation" (or something similar)?
the case of 6TiSCH.
As a result, as long as the TSCH MAC (and Layer-2 security) accepts Original:
a frame, that frame can be switched regardless of the protocol, Track Forwarding is the simplest and fastest.
whether this is an IPv6 packet, a 6LoWPAN fragment, or a frame from
an alternate protocol such as WirelessHART or ISA100.11a. 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 forwarding state that
can be used regardless of the network-layer protocol. This model
can effectively be seen as a Generalized Multiprotocol Label
Switching (GMPLS) operation in that the information used to
switch a frame is not an explicit label but is rather related to
other properties about the way the packet was received (a particular
cell, in the case of 6TiSCH). As a result, as long as the TSCH
MAC (and Layer 2 security) accepts a frame, that frame can be
switched regardless of the protocol, whether this is an IPv6
packet, a 6LoWPAN fragment, or a frame from an alternate protocol
such as WirelessHART or ISA100.11a.
</t> </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> <t>
A data frame that is forwarded along a Track normally has A data frame that is forwarded along a Track normally has
a destination MAC address that is set to broadcast - a destination MAC address that is set to broadcast
or a multicast address depending on MAC support. (or a multicast address, depending on MAC support).
This way, the MAC layer in the intermediate nodes accepts the This way, the MAC layer in the intermediate nodes accepts the
incoming frame and 6top switches it without incurring a change in incoming frame, and 6top switches it without incurring a change in
the MAC header. In the case of IEEE802.15.4, this means effectively the MAC header. In the case of IEEE 802.15.4, this means effectively
broadcast, so that along the Track the short address for the broadcast, so that the short address for the
destination of the frame is set to 0xFFFF. destination of the frame is set to 0xFFFF along the Track.
</t> </t>
<t> <t>
A Track is thus formed end-to-end as a succession of paired bundles, A Track is thus formed end to end as a succession of paired
a receive bundle from the previous hop and a transmit bundle to bundles: a receive bundle from the previous hop and a transmit
the next hop along the Track, and a cell in such a bundle belongs to bundle to the next hop along the Track. A cell in such a
at most one Track. bundle belongs to one Track at most. For a given iteration of the
For a given iteration of the device schedule, the effective channel device schedule, the effective channel of the cell is obtained by
of the cell is obtained by adding a pseudo-random number to the adding a pseudorandom number to the channelOffset of the cell,
channelOffset of the cell, which results in a rotation of the which results in a rotation of the frequency that was used for
frequency that used for transmission. transmission. The bundles may be computed so as to accommodate
The bundles may be computed so as to accommodate both variable rates both variable rates and retransmissions, so they might not be
and retransmissions, so they might not be fully used at a given fully used at a given iteration of the schedule. The 6TiSCH
iteration of the schedule. architecture provides additional means to avoid waste of cells as
The 6TiSCH architecture provides additional means to avoid waste of well as overflows in the transmit bundle, as described in the follow
cells as well as overflows in the transmit bundle, as follows: ing paragraphs.
</t> </t>
<t> <t>
In one hand, a TX-cell that is not needed for the current iteration 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 may be reused opportunistically on a per-hop basis for routed
packets. packets.
When all of the frame that were received for a given Track are When all of the frames that were received for a given Track are
effectively transmitted, any available TX-cell for that Track effectively transmitted, any available TX-cell for that Track
can be reused for upper layer traffic for which the next-hop router can be reused for upper-layer traffic for which the next-hop router
matches the next hop along the Track. In that case, the cell 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 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. short address for the destination is that of the next-hop router.
It results that a frame that is received in a RX-cell of a Track It results that a frame that is received in an RX-cell of a Track
with a destination MAC address set to this node as opposed to with a destination MAC address set to this node as opposed to
broadcast must be extracted from the Track and delivered to the broadcast must be extracted from the Track and delivered to the
upper layer (a frame with an unrecognized MAC address is dropped at 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). the lower MAC layer and thus is not received at the 6top sublayer).
</t> </t>
<t>On the other hand, it might happen that there are not enough <t>On the other hand, it might happen that there are not enough
TX-cells in the transmit bundle to accommodate the Track traffic, TX-cells in the transmit bundle to accommodate the Track traffic,
for instance if more retransmissions are needed than provisioned. for instance, if more retransmissions are needed than provisioned.
In that case, the frame can be placed for transmission in the In that case, the frame can be placed for transmission in the
bundle that is used for layer-3 traffic towards the next hop along bundle that is used for Layer 3 traffic towards the next hop along
the Track as long as it can be routed by the upper layer, that is, 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 typically, if the frame transports an IPv6 packet. The MAC address
should be set to the next-hop MAC address to avoid confusion. should be set to the next-hop MAC address to avoid confusion.
It results that a frame that is received over a layer-3 bundle may It results that a frame that is received over a Layer 3 bundle may
be in fact associated with a Track. In a classical IP link such as a n be in fact associated with a Track. In a classical IP link such as a n
Ethernet, off-Track traffic is typically in excess over reservation Ethernet, off-Track traffic is typically in excess over reservation
to be routed along the non-reserved path based on its QoS setting. to be routed along the non-reserved path based on its QoS setting.
But with 6TiSCH, since the use of the layer-3 bundle may be due to However, with 6TiSCH, since the use of the Layer 3 bundle may be due to
transmission failures, it makes sense for the receiver to recognize transmission failures, it makes sense for the receiver to recognize
a frame that should be re-Tracked, and to place it back on the a frame that should be re-Tracked and to place it back on the
appropriate bundle if possible. appropriate bundle if possible.
A frame should be re-Tracked if the Per-Hop-Behavior A frame should be re-Tracked if the per-hop-behavior
group indicated in the Differentiated Services Field in the group indicated in the Differentiated Services field in the
IPv6 header is set to Deterministic Forwarding, as discussed in IPv6 header is set to deterministic forwarding, as discussed in
<xref target='pmh'/>. <xref target='pmh'/>.
A frame is re-Tracked by scheduling it for transmission over the A frame is re-Tracked by scheduling it for transmission over the
transmit bundle associated with the Track, transmit bundle associated with the Track,
with the destination MAC address set to broadcast. with the destination MAC address set to broadcast.
</t> </t>
<section><name>OAM</name> <section>
<t> <name>OAM</name>
<t>"An Overview of Operations, Administration, and Maintenance (OAM)
<xref target='RFC7276'> "An Overview of Operations, Tools" <xref target='RFC7276'/> provides an
Administration, and Maintenance (OAM) Tools"</xref> provides an
overview of the existing tooling for OAM <xref target='RFC6291'/>. T racks are complex paths and new tooling overview of the existing tooling for OAM <xref target='RFC6291'/>. T racks are complex paths and new tooling
is necessary to manage them, with respect to load control, timing, is necessary to manage them, with respect to load control, timing,
and the Packet Replication and Elimination Functions (PREF). and the Packet Replication and Elimination Functions (PREF).
</t> </t>
<t> <t>
An example of such tooling can be found in the context of An example of such tooling can be found in the context of Bit Index
<xref target='RFC8279'>BIER</xref> and more specifically Explicit Replication (BIER)
<xref target='RFC9262'>BIER Traffic Engineering</xref> <xref target="RFC8279"/> and, more specifically, BIER Traffic
(BIER-TE). Engineering (BIER-TE) <xref target="RFC9262"/>.</t>
<!-- <!--
removed based on MB's review removed based on MB's review
<xref target='I-D.thubert-bier-replication-elimination'/> <xref target='I-D.thubert-bier-replication-elimination'/>
leverages BIER-TE to control the process of PREF, and to provide leverages BIER-TE to control the process of PREF, and to provide
traceability of these operations, in the deterministic dataplane, traceability of these operations, in the deterministic dataplane,
along a complex Track. along a complex Track.
--> -->
<!-- <!--
For the 6TiSCH type of constrained environment, For the 6TiSCH type of constrained environment,
<xref target='I-D.thubert-6lo-bier-dispatch'/> enables an efficient <xref target='I-D.thubert-6lo-bier-dispatch'/> enables an efficient
encoding of the BIER bitmap within the 6LoRH framework. encoding of the BIER bitmap within the 6LoRH framework.
--> -->
</t>
</section> </section>
</section> </section>
</section> <!-- 6TiSCH Tracks --> </section>
</section> <!-- General Characteristics --> </section>
<section><name>Applicability to Deterministic Flows</name> <section><name>Applicability to Deterministic Flows</name>
<t> <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 --> <!-- expected capabilities for safety and automation, e.g., loops per second -->
In the RAW context, low power reliable networks should address non-critical In the RAW context, low-power reliable networks should address
control scenarios such as Class 2 and monitoring scenarios such as Class 4 non-critical control scenarios such as Class 2 and monitoring scenarios
defined by the RFC5673 <xref target='RFC5673'/>. such as Class 4, as defined by <xref target='RFC5673'/>. As a low-power
As a low power technology targeting industrial scenarios radio transducers p technology targeting industrial scenarios, radio transducers provide
rovide low data rates (typically between 50 kbps to 250 kbps) and robust
low data rates (typically between 50kbps to 250kbps) and robust modulations modulations to trade-off performance to reliability. TSCH networks are
to trade-off performance to reliability. TSCH networks are organized in mesh organized in mesh topologies and connected to a backbone. Latency in the
topologies and connected to a backbone. Latency in the mesh network is mesh network is mainly influenced by propagation aspects such as
mainly influenced by propagation aspects such as interference. interference. ARQ methods and redundancy techniques such as replication
ARQ methods and redundancy techniques such as replication and elimination and elimination should be studied to provide the needed performance to
should be studied to provide the needed performance to address deterministic address deterministic scenarios.
scenarios.
</t> </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> <t>
Nodes in a TSCH network are tightly synchronized. This enables building the Nodes in a TSCH network are tightly synchronized. This enables building
slotted structure and ensures efficient utilization of resources thanks to the slotted structure and ensures efficient utilization of resources
proper scheduling policies. Scheduling is key to orchestrate the resources thanks to proper scheduling policies. Scheduling is key to orchestrate the
that different nodes in a Track or a path are using. Slotframes can be resources that different nodes in a Track or a path are using. Slotframes
split in resource blocks reserving the needed capacity to certain flows. can be split in resource blocks, reserving the needed capacity to certain
Periodic and bursty traffic can be handled independently in the schedule, flows. Periodic and bursty traffic can be handled independently in the
using active and reactive policies and taking advantage of overprovisioned schedule, using active and reactive policies and taking advantage of
cells. Along a Track <xref target='Tracks'/>, resource blocks overprovisioned cells. Along a Track (see <xref target='Tracks'/>), resource
can be chained so nodes in previous hops transmit their data before the n blocks can be chained so nodes in previous hops transmit their data before
ext the next packet comes. This provides a tight control to latency along a
packet comes. Track. Collision loss is avoided for best-effort traffic by
This provides a tight control to latency along a Track. Collision loss is overprovisioning resources, giving time to the management plane of the
avoided for best effort traffic by overprovisioning resources, giving time network to dedicate more resources if needed.</t>
to the management plane of the network to dedicate more resources if needed.
<!-- <!--
-time synchronization -time synchronization
- scheduling capabilities, discuss such things as Resource Units, time slot s or resource blocks. - scheduling capabilities, discuss such things as Resource Units, time slot s or resource blocks.
Can we reserve periodic resources vs. ask each time, what precision can w e get in latency control. Can we reserve periodic resources vs. ask each time, what precision can w e get in latency control.
- diversity scenarios, what's available, - diversity scenarios, what's available,
- gap analysis, e.g. discuss multihop, or what's missing how to do PREOF fe atures. - gap analysis, e.g. discuss multihop, or what's missing how to do PREOF fe atures.
--> -->
</t>
<section anchor='detnet'><name>Centralized Path Computation</name> <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> <t>
When considering end-to-end communication over TSCH, a 6TiSCH device usually When considering end-to-end communication over TSCH, a 6TiSCH device
does usually does not place a request for bandwidth between itself and another
not place a request for bandwidth between itself and another device in the ne device in the network. Rather, an Operation Control System (OCS) invoked
twork. through a Human-Machine Interface (HMI) provides the traffic specification,
Rather, an Operation Control System (OCS) invoked through a Human/Machine Int in particular, in terms of latency and reliability, and the end nodes, to a
erface PCE. With this, the PCE computes a Track between the end nodes and
(HMI) provides the Traffic Specification, in particular in terms of latency provisions every hop in the Track with per-flow state that describes the
and reliability, and the end nodes, to a PCE. per-hop operation for a given packet, the corresponding timeSlots, and the
With this, the PCE computes a Track between the end nodes and provisions ever flow identification to recognize which packet is placed in which Track,
y sort out duplicates, etc. An example of an OCS and HMI
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 and HMI
is depicted in <xref target='NorthSouth'/>. is depicted in <xref target='NorthSouth'/>.
</t> </t>
<t> <t>
For a static configuration that serves a certain purpose for a long period of 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 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 schedule, which incorporates the aggregation of its behavior for multiple
Tracks. The 6TiSCH Architecture expects that the programing of the schedule Tracks. The 6TiSCH architecture expects that the programming of the schedule
is done over the Constrained Application Protocol (CoAP) such as discussed in is done over the Constrained Application Protocol (CoAP) as discussed in <xre
<xref target='I-D.ietf-6tisch-coap'>"6TiSCH f target='I-D.ietf-6tisch-coap'/>.
Resource Management and Interaction using CoAP"</xref>.
</t> </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> <t>
But an Hybrid mode may be required as well whereby a single Track is added, However, a Hybrid mode may be required as well, whereby a single Track is add
modified, or removed, for instance if it appears that a Track does not ed,
perform as expected. modified, or removed (for instance, if it appears that a Track does not
perform as expected).
For that case, the expectation is that a protocol that flows along a Track 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) (to be), in a fashion similar to classical Traffic Engineering (TE)
<xref target='CCAMP'/>, may be used to update the state in the devices. <xref target='CCAMP'/>, may be used to update the state in the devices.
In general, that flow was not designed and it is expected that DetNet will de termine the appropriate In general, that flow was not designed, and it is expected that DetNet will d etermine the appropriate
end-to-end protocols to be used in that case. end-to-end protocols to be used in that case.
</t> </t>
<t keepWithNext='true'>Stream Management Entity</t><figure align='center' anchor <!-- [rfced] What is meant by "Stream Management Entity" above Figure 2? Should
='NorthSouth'> 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> <name>Architectural Layers</name>
<artwork align='left'><![CDATA[ <artwork align='left'><![CDATA[
Operational Control System and HMI Operational Control System and HMI
-+-+-+-+-+-+-+ Northbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+-+-+-+-+-+-+ Northbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
PCE PCE PCE PCE PCE PCE PCE PCE
-+-+-+-+-+-+-+ Southbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+-+-+-+-+-+-+ Southbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
--- 6TiSCH------6TiSCH------6TiSCH------6TiSCH-- --- 6TiSCH------6TiSCH------6TiSCH------6TiSCH--
6TiSCH / Device Device Device Device \ 6TiSCH / Device Device Device Device \
Device- - 6TiSCH Device- - 6TiSCH
\ 6TiSCH 6TiSCH 6TiSCH 6TiSCH / Device \ 6TiSCH 6TiSCH 6TiSCH 6TiSCH / Device
----Device------Device------Device------Device-- ----Device------Device------Device------Device--
]]></artwork>
]]></artwork>
</figure> </figure>
<section anchor='pmh'><name>Packet Marking and Handling</name> <section anchor='pmh'><name>Packet Marking and Handling</name>
<t> <t>
Section "Packet Marking and Handling" of <xref target='RFC9030' section="4.7.1"/> describes the packet tagging and
<xref target='RFC9030'/> describes the packet tagging and
marking that is expected in 6TiSCH networks. marking that is expected in 6TiSCH networks.
</t> </t>
<section anchor='pmhft'><name>Tagging Packets for Flow Identification</name> <section anchor='pmhft'><name>Tagging Packets for Flow Identification</name>
<t> <t>
Packets that are routed by a PCE along a Track, are tagged to uniquely Packets that are routed by a PCE along a Track are tagged to uniquely
identify the Track and associated transmit bundle of timeSlots. identify the Track and associated transmit bundle of timeSlots.
</t> </t>
<t> <t>
It results that the tagging that is used for a DetNet flow outside the 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 6TiSCH Low-Power and Lossy Network (LLN) must be swapped into 6TiSCH formats and back as the packet
enters and then leaves the 6TiSCH network. enters and then leaves the 6TiSCH network.
</t> </t>
</section> </section>
<section anchor='pmhrre'><name>Replication, Retries and Elimination</name> <section anchor='pmhrre'><name>Replication, Retries, and Elimination</name>
<t> <t>
The 6TiSCH Architecture <xref target='RFC9030'/> leverages PREOF over The 6TiSCH architecture <xref target='RFC9030'/> leverages PREOF over
several alternate paths in a network to provide several alternate paths in a network to provide redundancy and parallel
redundancy and parallel transmissions to bound the end-to-end delay. transmissions to bound the end-to-end delay. Considering the scenario
Considering the scenario shown in <xref target='fig_ladder'/>, shown in <xref target='fig_ladder'/>, many different paths are possible
many different paths are possible for S to reach R. for S to reach R. A simple way to benefit from this topology could be
A simple way to benefit from this topology could be to use the to use the two independent paths via nodes A, C, E and via B, D, F, but m
two independent paths via nodes A, C, E and via B, D, F. ore complex paths are possible as well.
But more complex paths are possible as well.
</t> </t>
<figure anchor='fig_ladder' align='center'><name>A Typical Ladder Shape wi th Two Parallel Paths Toward the Destination</name> <figure anchor='fig_ladder' align='center'><name>A Typical Ladder Shape wi th Two Parallel Paths Toward the Destination</name>
<artwork align='center'><![CDATA[ <artwork align='center'><![CDATA[
(A) (C) (E) (A) (C) (E)
source (S) (R) (destination) source (S) (R) (destination)
(B) (D) (F) (B) (D) (F)
]]></artwork>
]]></artwork>
</figure> </figure>
<t> <t>By employing a packet replication function, each node forwards a copy
By employing a Packet Replication function, each node forwards of each data packet over two different branches. For instance, in <xref
a copy of each data packet over two different branches. target='fig_replication'/>, the source node S transmits the data packet to
For instance, in <xref target='fig_replication'/>, the source node S nodes A and B, in two different timeslots within the same TSCH slotframe. S
transmits the data packet to nodes A and B, in two different transmits twice the same data packet to its Destination Parent
timeslots within the same TSCH slotframe. (DP) (A) and to its Alternate Parent (AP) (B).
</t> </t>
<figure anchor='fig_replication' align='center'><name>Packet Replication : S transmits twice the same data packet, to its Destination Parent (DP) (A) and to its Alternate Parent (AP) (B).</name> <figure anchor='fig_replication' align='center'><name>Packet Replication </name>
<artwork align='center'><![CDATA[ <artwork align='center'><![CDATA[
===> (A) => (C) => (E) === ===> (A) => (C) => (E) ===
// \\// \\// \\ // \\// \\// \\
source (S) //\\ //\\ (R) (destination) source (S) //\\ //\\ (R) (destination)
\\ // \\ // \\ // \\ // \\ // \\ //
===> (B) => (D) => (F) === ===> (B) => (D) => (F) ===
]]></artwork>
]]></artwork>
</figure> </figure>
<t> <!-- [rfced] We have moved the text below from the title of Figure 4 and added
By employing Packet Elimination function once a node receives the it to the text introducing the figure. Please review. Also, please
first copy of a data packet, it discards the subsequent copies. clarify "twice" here. Would updating as follows (move "twice", add colon,
Because the first copy that reaches a node is the and add "once") convey the intended meaning?
one that matters, it is the only copy that will be
forwarded upward.
</t>
<t> Original:
Considering that the wireless medium is broadcast by nature, any S transmits twice the same data
neighbor of packet, to its Destination Parent (DP) (A) and to its Alternate
a transmitter may overhear a transmission. Parent (AP) (B).
By employing the Promiscuous Overhearing function, nodes will hav
e multiple Perhaps:
opportunities to receive a given data packet. In the figure above, S transmits the same data
For instance, in <xref target='fig_replication'/>, when the sourc packet twice: once to its Destination Parent (DP) (A) and once to its Alterna
e node S te
transmits the data packet to node A, node B may overhear this tra Parent (AP) (B).
nsmission. -->
<t></t>
<t>By employing a packet elimination function once it receives the
first copy of a data packet, a node discards the subsequent copies.
Because the first copy that reaches a node is the one that matters, it
is the only copy that will be forwarded upward.</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 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 the transmission.
</t> </t>
<t> <t>
6TiSCH expects elimination and replication of packets along a complex 6TiSCH expects elimination and replication of packets along a complex
Track, but has no position about how the sequence numbers would be tagged in Track but has no position about how the sequence numbers would be tagged in
the packet. 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> <t>
As it goes, 6TiSCH expects that timeSlots corresponding to copies As it goes, 6TiSCH expects that timeSlots corresponding to copies
of a same packet along a Track are correlated by configuration, and does not of the same packet along a Track are correlated by configuration, and does no t
need to process the sequence numbers. need to process the sequence numbers.
</t> </t>
<t> <t>
The semantics of the configuration must enable correlated timeSlots to be The semantics of the configuration must enable correlated timeSlots to be
grouped for transmit (and respectively receive) with 'OR' relations, grouped for transmit (and receive, respectively) with 'OR' relations,
and then an 'AND' relation must be configurable between groups. and then an 'AND' relation must be configurable between groups.
The semantics is that if the transmit (and respectively receive) operation The semantics are such that if the transmit (and receive, respectively) opera tion
succeeded in one timeSlot in an 'OR' group, then all the other timeslots in succeeded in one timeSlot in an 'OR' group, then all the other timeslots in
the group are ignored. the group are ignored.
Now, if there are at least two groups, the 'AND' relation between the groups 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 deta ils indicates that one operation must succeed in each of the groups. Further deta ils
can be found in the 6TiSCH Architecture document <xref target='RFC9030'/>. can be found in the 6TiSCH architecture document <xref target='RFC9030'/>.
</t> </t>
</section> </section>
</section> </section>
<section anchor='topo'><name>Topology and Capabilities</name> <section anchor='topo'><name>Topology and Capabilities</name>
<t>6TiSCH nodes are usually IoT devices, characterized by very limited amount <t>6TiSCH nodes are usually IoT devices, characterized by a very limited amou nt
of memory, just enough buffers to store one or a few IPv6 packets, and 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 limited bandwidth between peers. It results that a node will maintain only a
small number of peering information, and will not be able to store many small amount of peering information and will not be able to store many
packets waiting to be forwarded. Peers can be identified through MAC or IPv6 packets waiting to be forwarded. Peers can be identified through MAC or IPv6
addresses. addresses.
</t> </t>
<t> <t>
Neighbors can be discovered over the radio using mechanism such as Enhanced B Neighbors can be discovered over the radio using mechanisms such as enhanced
eacons, beacons,
but, though the neighbor information is available in the 6TiSCH interface but although the neighbor information is available in the 6TiSCH interface
data model, 6TiSCH does not describe a protocol to pro-actively push the data model, 6TiSCH does not describe a protocol to proactively push the
neighborhood information to a PCE. neighborhood information to a PCE.
This protocol should be described and should operate over CoAP. The protocol This protocol should be described and should operate over CoAP. The protocol
should be able to carry multiple metrics, in particular the same metrics as should be able to carry multiple metrics, in particular, the same metrics tha t are
used for RPL operations <xref target='RFC6551'/>. used for RPL operations <xref target='RFC6551'/>.
</t> </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> <t>
The energy that the device consumes in sleep, transmit and receive modes can The energy that the device consumes in sleep, transmit, and receive modes can
be evaluated and reported. So can the amount of energy that is stored in the be evaluated and reported, and so can the amount of energy that is stored in
device and the power that it can be scavenged from the environment. The PCE the
device and the power that can be scavenged from the environment. The PCE
should be able to compute Tracks that will implement policies on how the 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 sp energy is consumed, for instance, policies that balance between nodes and ens
ent ure that the spent
energy does not exceeded the scavenged energy over a period of time. energy does not exceed the scavenged energy over a period of time.
</t> </t>
</section> </section>
<section anchor='schd'><name>Schedule Management by a PCE</name> <section anchor='schd'><name>Schedule Management by a PCE</name>
<t> <t>
6TiSCH supports a mixed model of centralized routes and distributed routes . 6TiSCH supports a mixed model of centralized routes and distributed routes .
Centralized routes can for example be computed by a entity such as a Centralized routes can, for example, be computed by an entity such as a
PCE <xref target='PCE'/>. PCE <xref target='PCE'/>.
Distributed routes are computed by <xref target='RFC6550'>RPL</xref>. Distributed routes are computed by RPL <xref target='RFC6550'/>.
</t> </t>
<t> <t>
Both methods may inject routes in the Routing Tables of the 6TiSCH routers . Both methods may inject routes in the routing tables of the 6TiSCH routers .
In either case, each route is associated with a 6TiSCH topology that can 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 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 indexed by an Instance ID, in a format that reuses the RPLInstanceID as
defined in RPL. defined in RPL.
</t> </t>
<t> <t>
Both RPL and PCE rely on shared sources such as policies to define Global 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 and Local RPLInstanceIDs that can be used by either method. It is possible
for centralized and distributed routing to share a same topology. for centralized and distributed routing to share the same topology.
Generally they will operate in different slotFrames, and centralized Generally, they will operate in different slotFrames, and centralized
routes will be used for scheduled traffic and will have precedence over routes will be used for scheduled traffic and will have precedence over
distributed routes in case of conflict between the slotFrames. distributed routes in case of conflict between the slotFrames.
</t> </t>
</section> <!--anchor="schd" title="Schedule Management by a PCE"--> </section>
<section anchor='slotFrames'><name>SlotFrames and Priorities</name> <section anchor='slotFrames'><name>SlotFrames and Priorities</name>
<t> <t>
IEEE802.15.4 TSCH avoids contention on the medium by formatting time IEEE 802.15.4 TSCH avoids contention on the medium by formatting time
and frequencies in cells of transmission of equal duration. and frequencies in cells of transmission of equal duration.
In order to describe that formatting of time and frequencies, the In order to describe that formatting of time and frequencies, the
6TiSCH architecture defines a global concept that is called a Channel 6TiSCH architecture defines a global concept that is called a Channel
Distribution and Usage (CDU) matrix; a CDU matrix is a matrix of Distribution and Usage (CDU) matrix; a CDU matrix is a matrix of
cells with an height equal to the number of available channels cells with a height equal to the number of available channels
(indexed by ChannelOffsets) and a width (in timeSlots) that is the (indexed by ChannelOffsets) and a width (in timeSlots) that is the
period of the network scheduling operation (indexed by slotOffsets) for period of the network scheduling operation (indexed by slotOffsets) for
that CDU matrix. that CDU matrix.
</t> </t>
<t> <t>
The CDU Matrix is used by the PCE as the map of all the channel The CDU matrix is used by the PCE as the map of all the channel
utilization. This organization depends on the time in the future. utilization. This organization depends on the time in the future.
The frequency used by a cell in the matrix rotates in a pseudo-random The frequency used by a cell in the matrix rotates in a pseudorandom
fashion, from an initial position at an epoch time, as the CDU matrix fashion, from an initial position at an epoch time, as the CDU matrix
iterates over and over. iterates over and over.
</t> </t>
<t> <t>
The size of a cell is a timeSlot duration, and The size of a cell is a timeSlot duration, and
values of 10 to 15 milliseconds are typical in 802.15.4 TSCH to values of 10 to 15 milliseconds are typical in 802.15.4 TSCH to
accommodate for the transmission of a frame and an acknowledgement, accommodate for the transmission of a frame and an acknowledgement,
including the security validation on the receive side which may take including the security validation on the receive side, which may take
up to a few milliseconds on some device architecture. The matrix up to a few milliseconds on some device architectures. The matrix
represents the overall utilisation of the spectrum over time by a represents the overall utilization of the spectrum over time by a
scheduled network operation. scheduled network operation.
</t> </t>
<t> <t>
A CDU matrix is computed by the PCE, but unallocated timeSlots may be A CDU matrix is computed by the PCE, but unallocated timeSlots may be
used opportunistically by the nodes for classical best effort IP used opportunistically by the nodes for classical best-effort IP
traffic. The PCE has precedence in the allocation in case of a conflict . traffic. The PCE has precedence in the allocation in case of a conflict .
Multiple schedules may coexist, in which Multiple schedules may coexist, in which
case the schedule adds a dimension to the matrix and the dimensions are case the schedule adds a dimension to the matrix, and the dimensions ar e
ordered by priority. ordered by priority.
</t> </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 <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 to program a schedule into one device. The slotFrame is a device
perspective of a transmission schedule; there can be more than one perspective of a transmission schedule; there can be more than one
with different priorities so in case of a contention the highest with different priorities so in case of a contention the highest
priority applies. In other words, a slotFrame is the projection of a priority applies. In other words, a slotFrame is the projection of a
schedule from the CDU matrix onto one device. 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 [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 Elaboration on that concept can be found in section "SlotFrames and
Priorities" of <xref target='RFC9030'/>, and figures 17 and 18 of Priorities" of <xref target='RFC9030'/>, and Figures 17 and 18 in
<xref target='RFC9030'/> illustrate that projection. <xref target='RFC9030'/> illustrate that projection.
</t> </t>
</section> </section>
</section> </section>
</section>
</section>
</section><!-- Applicability to deterministic flows --> <section>
<name>5G</name>
</section> <!-- IEEE 802.15.4 TimeSlotted Channel Hopping--> <t>5G technology enables deterministic communication. Based on the
centralized admission control and the scheduling of the wireless
<section><name>5G</name> resources, licensed or unlicensed, Quality of Service (QoS) such as latency
and
<t> reliability can be guaranteed. 5G contains several features to achieve
5G technology enables deterministic communication. Based on the centralized ultra-reliable and low-latency performance (e.g., support for different
admission control and the scheduling of the wireless resources, licensed or OFDM numerologies and slot durations), as well as fast processing
unlicensed, quality of service such as latency and reliability can be capabilities and redundancy techniques that lead to achievable latency
guaranteed. 5G contains several features to achieve ultra-reliable and low numbers of below 1 ms with 99.999% or higher confidence.
latency performance, e.g., support for different OFDM numerologies and
slot-durations, as well as fast processing capabilities and redundancy
techniques that lead to achievable latency numbers of below 1ms with
99.999% or higher confidence.
</t> </t>
<t> <t>
5G also includes features to support Industrial IoT use cases, e.g., via the 5G also includes features to support industrial IoT use cases, e.g., via the
integration of 5G with TSN. This includes 5G capabilities for each TSN integration of 5G with TSN. This includes 5G capabilities for each TSN
component, latency, resource management, time synchronization, and component, latency, resource management, time synchronization, and
reliability. Furthermore, 5G support for TSN can be leveraged when 5G is used reliability. Furthermore, 5G support for TSN can be leveraged when 5G is used
as subnet technology for DetNet, in combination with or instead of TSN, which as the subnet technology for DetNet, in combination with or instead of TSN, w hich
is the primary subnet for DetNet. In addition, the support for integration is the primary subnet for DetNet. In addition, the support for integration
with TSN reliability was added to 5G by making DetNet reliability also with TSN reliability was added to 5G by making DetNet reliability also
applicable, due to the commonalities between TSN and DetNet reliability. applicable, due to the commonalities between TSN and DetNet reliability.
Moreover, providing IP service is native to 5G and 3GPP Release 18 adds direc t Moreover, providing IP service is native to 5G, and 3GPP Release 18 adds dire ct
support for DetNet to 5G. support for DetNet to 5G.
</t> </t>
<t> <t>
Overall, 5G provides scheduled wireless segments with high reliability and Overall, 5G provides scheduled wireless segments with high reliability and
availability. In addition, 5G includes capabilities for integration to IP availability. In addition, 5G includes capabilities for integration to IP
networks. This makes 5G a suitable technology to apply RAW upon. networks. This makes 5G a suitable technology upon which to apply RAW.
</t> </t>
<section><name>Provenance and Documents</name> <section><name>Provenance and Documents</name>
<t> <t>
The 3rd Generation Partnership Project (3GPP) incorporates many companies The 3rd Generation Partnership Project (3GPP) incorporates many companies
whose business is related to cellular network operation as well as network whose business is related to cellular network operation as well as network
equipment and device manufacturing. All generations of 3GPP technologies equipment and device manufacturing. All generations of 3GPP technologies
provide scheduled wireless segments, primarily in licensed spectrum which is provide scheduled wireless segments, primarily in licensed spectrum, which is
beneficial for reliability and availability. beneficial for reliability and availability.
</t> </t>
<t> <t>
In 2016, the 3GPP started to design New Radio (NR) technology belonging to 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 fifth generation (5G) of cellular networks. NR has been designed from
the beginning to not only address enhanced Mobile Broadband (eMBB) services the beginning to not only address enhanced Mobile Broadband (eMBB) services
for consumer devices such as smart phones or tablets but is also tailored for consumer devices such as smart phones or tablets, but it is also
for future Internet of Things (IoT) communication and connected tailored for future IoT communication and connected
cyber-physical systems. In addition to eMBB, requirement categories have cyber-physical systems. In addition to eMBB, requirement categories have
been defined on Massive Machine-Type Communication (M-MTC) for a large been defined on Massive Machine-Type Communication (M-MTC) for a large
number of connected devices/sensors, and Ultra-Reliable Low-Latency number of connected devices/sensors and on Ultra-Reliable Low-Latency
Communication (URLLC) for connected control systems and critical Communications (URLLC) for connected control systems and critical
communication as illustrated in <xref target='fig-5g-triangle'/>. It is communication as illustrated in <xref target='fig-5g-triangle'/>. It is the
the URLLC capabilities that make 5G a great candidate for reliable URLLC capabilities that make 5G a great candidate for reliable low-latency
low-latency communication. With these three corner stones, NR is a complete communication. With these three cornerstones, NR is a complete solution
solution supporting the connectivity needs of consumers, enterprises, and supporting the connectivity needs of consumers, enterprises, and the public
public sector for both wide area and local area, e.g. indoor deployments. sector for both wide-area and local-area (e.g., indoor) deployments. A
A general overview of NR can be found in <xref target='TS38300'/>. general overview of NR can be found in <xref target='TS38300'/>.
</t> </t>
<figure anchor='fig-5g-triangle'><name>5G Application Areas</name> <figure anchor='fig-5g-triangle'><name>5G Application Areas</name>
<artwork align="center"><![CDATA[ <artwork align="center"><![CDATA[
enhanced enhanced
Mobile Broadband Mobile Broadband
^ ^
/ \ / \
/ \ / \
/ \ / \
skipping to change at line 1307 skipping to change at line 1906
+-----------------+ +-----------------+
Massive Ultra-Reliable Massive Ultra-Reliable
Machine-Type Low-Latency Machine-Type Low-Latency
Communication Communication Communication Communication
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
As a result of releasing the first NR specification in 2018 (Release 15), it 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 has been proven by many companies that NR is a URLLC-capable technology and
can deliver data packets at 10^-5 packet error rate within 1ms latency can deliver data packets at 10<sup>-5</sup> packet error rate within a 1 ms l atency
budget <xref target='TR37910'/>. Those evaluations were consolidated and budget <xref target='TR37910'/>. Those evaluations were consolidated and
forwarded to ITU to be included in the <xref target='IMT2020'/> work. forwarded to ITU to be included in the work on <xref target='IMT2020'/>.
</t> </t>
<t> <t>
In order to understand communication requirements for automation in vertical In order to understand communication requirements for automation in vertical
domains, 3GPP studied different use cases <xref target='TR22804'/> and domains, 3GPP studied different use cases <xref target='TR22804'/> and
released technical specification with reliability, availability and latency released a technical specification with reliability, availability, and latenc y
demands for a variety of applications <xref target='TS22104'/>. demands for a variety of applications <xref target='TS22104'/>.
</t> </t>
<t> <t>
As an evolution of NR, multiple studies have been conducted in scope of 3GPP As an evolution of NR, multiple studies that focus on radio aspects have been
Release 16 including the following two, focusing on radio aspects: conducted in scope of 3GPP
</t><ol type='%d.'> Release 16, including the following two:
<li> Study on physical layer enhancements for NR ultra-reliable and low
latency communication (URLLC) <xref target='TR38824'/>.</li>
<li> Study on NR industrial Internet of Things (I-IoT)
<xref target='TR38825'/>.</li>
</ol><t>
</t> </t>
<ol type='1'>
<li>"Study on physical layer enhancements for NR ultra-reliable and low
latency case (URLLC)" <xref target='TR38824'/></li>
<li>"Study on NR industrial Internet of Things (IoT)" <xref
target='TR38825'/></li>
</ol>
<t> <t>
Resulting of these studies, further enhancements to NR have been standardized As a result of these studies, further enhancements to NR have been standardiz
in 3GPP Release 16, hence, available in <xref target='TS38300'/>, and ed
in 3GPP Release 16 and are available in <xref target='TS38300'/> and
continued in 3GPP Release 17 standardization (according to <xref target='RP21 0854'/>). continued in 3GPP Release 17 standardization (according to <xref target='RP21 0854'/>).
</t> </t>
<t> <t>
In addition, several enhancements have been done on system architecture level In addition, several enhancements have been made on the system architecture l
which are reflected in System architecture for the 5G System (5GS) evel,
which are reflected in "System architecture for the 5G System (5GS)"
<xref target='TS23501'/>. <xref target='TS23501'/>.
These enhancements include multiple features in support of Time-Sensitive These enhancements include multiple features in support of Time-Sensitive
Communications (TSC) by Release 16 and Release 17. Further improvements are Communications (TSC) by Release 16 and Release 17. Further improvements, such
provided in Release 18, e.g., support for DetNet <xref target='TR2370046'/>. as support for DetNet <xref target='TR2370046'/>, are
provided in Release 18.
</t> </t>
<t> <t>
The adoption and the use of 5G is facilitated by multiple organizations. For The adoption and the use of 5G is facilitated by multiple organizations. For
instance, the 5G Alliance for Connected Industries and Automation (5G-ACIA) instance, the 5G Alliance for Connected Industries and Automation (5G-ACIA)
brings together widely varying 5G stakeholders including Information and brings together widely varying 5G stakeholders including Information and
Communication Technology (ICT) players and Operational Technology (OT) Communication Technology (ICT) players and Operational Technology (OT)
companies, e.g.: industrial automation enterprises, machine builders, and companies (e.g., industrial automation enterprises, machine builders, and
end users. Another example is the 5G Automotive Association (5GAA), which end users). Another example is the 5G Automotive Association (5GAA), which
bridges ICT and automotive technology companies to develop end-to-end bridges ICT and automotive technology companies to develop end-to-end
solutions for future mobility and transportation services. solutions for future mobility and transportation services.
</t> </t>
</section><!-- Provenance and Documents --> </section>
<section><name>General Characteristics</name> <section><name>General Characteristics</name>
<t> <t>
The 5G Radio Access Network (5G RAN) with its NR interface includes several The 5G Radio Access Network (5G RAN) with its NR interface includes several
features to achieve Quality of Service (QoS), such as a guaranteeably features to achieve Quality of Service (QoS), such as a guaranteeably
low latency or tolerable packet error rates for selected data flows. low latency or tolerable packet error rates for selected data flows.
Determinism is achieved by centralized admission control and scheduling of Determinism is achieved by centralized admission control and scheduling of
the wireless frequency resources, which are typically licensed frequency the wireless frequency resources, which are typically licensed frequency
bands assigned to a network operator. bands assigned to a network operator.
</t> </t>
<t> <t>
NR enables short transmission slots in a radio subframe, which benefits NR enables short transmission slots in a radio subframe, which benefits
low-latency applications. NR also introduces mini-slots, where prioritized low-latency applications. NR also introduces mini-slots, where prioritized
transmissions can be started without waiting for slot boundaries, further transmissions can be started without waiting for slot boundaries, further
reducing latency. As part of giving priority and faster radio access to reducing latency. As part of giving priority and faster radio access to
URLLC traffic, NR introduces preemption where URLLC data transmission can URLLC traffic, NR introduces preemption, where URLLC data transmission can
preempt ongoing non-URLLC transmissions. Additionally, NR applies very fast preempt ongoing non-URLLC transmissions. Additionally, NR applies very fast
processing, enabling retransmissions even within short latency bounds. processing, enabling retransmissions even within short latency bounds.
</t> </t>
<t> <t>
NR defines extra-robust transmission modes for increased reliability both NR defines extra-robust transmission modes for increased reliability for both
for data and control radio channels. Reliability is further improved by data and control radio channels. Reliability is further improved by
various techniques, such as multi-antenna transmission, the use of multiple various techniques, such as multi-antenna transmission, the use of multiple
frequency carriers in parallel and packet duplication over independent radio frequency carriers in parallel, and packet duplication over independent radio
links. NR also provides full mobility support, which is an important links. NR also provides full mobility support, which is an important
reliability aspect not only for devices that are moving, but also for reliability aspect not only for devices that are moving, but also for
devices located in a changing environment. devices located in a changing environment.
</t> </t>
<t> <t>
Network slicing is seen as one of the key features for 5G, allowing vertical Network slicing is seen as one of the key features for 5G, allowing
industries to take advantage of 5G networks and services. Network slicing is vertical industries to take advantage of 5G networks and services. Network
about transforming a Public Land Mobile Network (PLMN) from a single network slicing is about transforming a Public Land Mobile Network (PLMN) from a
to a network where logical partitions are created, with appropriate network single network to a network where logical partitions are created, with
isolation, resources, optimized topology and specific configuration to serve appropriate network isolation, resources, optimized topology, and specific
various service requirements. An operator can configure and manage the configurations to serve various service requirements. An operator can
mobile network to support various types of services enabled by 5G, for configure and manage the mobile network to support various types of
example eMBB and URLLC, depending on the different customers’ needs. services enabled by 5G (e.g., eMBB and URLLC), depending on the different
needs of customers.
</t> </t>
<t> <t>
Exposure of capabilities of 5G Systems to the network or applications Exposure of capabilities of 5G systems to the network or applications
outside the 3GPP domain have been added to Release 16 outside the 3GPP domain have been added to Release 16
<xref target='TS23501'/>. Via exposure interfaces, applications can access <xref target='TS23501'/>. Applications can access
5G capabilities, e.g., communication service monitoring and network 5G capabilities like communication service monitoring and network
maintenance. maintenance via exposure interfaces.
</t> </t>
<t> <t>
For several generations of mobile networks, 3GPP has considered how the For several generations of mobile networks, 3GPP has considered how the
communication system should work on a global scale with billions of users, communication system should work on a global scale with billions of users,
taking into account resilience aspects, privacy regulation, protection of taking into account resilience aspects, privacy regulation, protection of
data, encryption, access and core network security, as well as interconnect. data, encryption, access and core network security, as well as interconnect.
Security requirements evolve as demands on trustworthiness increase. For Security requirements evolve as demands on trustworthiness increase. For
example, this has led to the introduction of enhanced privacy protection example, this has led to the introduction of enhanced privacy protection
features in 5G. 5G also employs strong security algorithms, encryption of features in 5G. 5G also employs strong security algorithms, encryption of
traffic, protection of signaling and protection of interfaces. traffic, protection of signaling, and protection of interfaces.
</t> </t>
<t> <t>
One particular strength of mobile networks is the authentication, based on One particular strength of mobile networks is the authentication, based on
well-proven algorithms and tightly coupled with a global identity management well-proven algorithms and tightly coupled with a global identity management
infrastructure. Since 3G, there is also mutual authentication, allowing the infrastructure. Since 3G, there is also mutual authentication, allowing the
network to authenticate the device and the device to authenticate the network to authenticate the device and the device to authenticate the
network. Another strength is secure solutions for storage and distribution network. Another strength is secure solutions for storage and distribution
of keys fulfilling regulatory requirements and allowing international of keys, fulfilling regulatory requirements and allowing international
roaming. When connecting to 5G, the user meets the entire communication roaming. When connecting to 5G, the user meets the entire communication
system, where security is the result of standardization, product security, system, where security is the result of standardization, product security,
deployment, operations and management as well as incident handling deployment, operations, and management as well as incident-handling
capabilities. The mobile networks approach the entirety in a rather capabilities. The mobile networks approach the entirety in a rather
coordinated fashion which is beneficial for security. coordinated fashion, which is beneficial for security.
</t> </t>
</section><!-- General Characteristics --> </section>
<section><name>Deployment and Spectrum</name> <section><name>Deployment and Spectrum</name>
<t> <t>
The 5G system allows deployment in a vast spectrum range, addressing The 5G system allows deployment in a vast spectrum range, addressing
use-cases in both wide-area as well as local networks. Furthermore, 5G can use cases in both wide-area and local-area networks. Furthermore, 5G can
be configured for public and non-public access. be configured for public and non-public access.
</t> </t>
<t> <t>
When it comes to spectrum, NR allows combining the merits of many frequency When it comes to spectrum, NR allows combining the merits of many frequency
bands, such as the high bandwidths in millimeter Waves (mmW) for extreme bands, such as the high bandwidths in millimeter waves (mmWaves) for extreme
capacity locally, as well as the broad coverage when using mid- and low capacity locally and the broad coverage when using mid- and
frequency bands to address wide-area scenarios. URLLC is achievable in all low-frequency bands to address wide-area scenarios. URLLC is achievable in
these bands. Spectrum can be either licensed, which means that the license all these bands. Spectrum can be either licensed, which means that the
holder is the only authorized user of that spectrum range, or unlicensed, license holder is the only authorized user of that spectrum range, or
which means that anyone who wants to use the spectrum can do so. unlicensed, which means that anyone who wants to use the spectrum can do
so.
</t> </t>
<t> <t>
A prerequisite for critical communication is performance predictability, A prerequisite for critical communication is performance predictability,
which can be achieved by the full control of the access to the spectrum, which can be achieved by full control of access to the spectrum,
which 5G provides. Licensed spectrum guarantees control over spectrum usage which 5G provides. Licensed spectrum guarantees control over spectrum usage
by the system, making it a preferable option for critical communication. by the system, making it a preferable option for critical communication.
However, unlicensed spectrum can provide an additional resource for scaling However, unlicensed spectrum can provide an additional resource for scaling
non-critical communications. While NR is initially developed for usage of non-critical communications. While NR was initially developed for usage of
licensed spectrum, the functionality to access also unlicensed spectrum was licensed spectrum, the functionality to also access unlicensed spectrum was
introduced in 3GPP Release 16. Moreover, URLLC features are enhanced in introduced in 3GPP Release 16. Moreover, URLLC features are enhanced in
Release 17 <xref target='RP210854'/> to be better applicable to unlicensed Release 17 <xref target='RP210854'/> to be better applicable to unlicensed
spectrum. spectrum.
</t> </t>
<t> <t>
Licensed spectrum dedicated to mobile communications has been allocated to Licensed spectrum dedicated to mobile communications has been allocated to
mobile service providers, i.e. issued as longer-term licenses by national mobile service providers, i.e., issued as longer-term licenses by national
administrations around the world. These licenses have often been associated administrations around the world. These licenses have often been
with coverage requirements and issued across whole countries, or in large associated with coverage requirements and issued across whole countries or
regions. Besides this, configured as a non-public network (NPN) deployment, large regions. Besides this, configured as a non-public network (NPN)
5G can provide network services also to a non-operator defined organization deployment, 5G can also provide network services to a non-operator defined
and its premises such as a factory deployment. By this isolation, quality of organization and its premises such as a factory deployment. With this
service requirements, as well as security requirements can be achieved. An isolation, QoS requirements as well as security requirements can be
integration with a public network, if required, is also possible. The achieved. An integration with a public network, if required, is also
non-public (local) network can thus be interconnected with a public network, possible. The non-public (local) network can thus be interconnected with a
allowing devices to roam between the networks. public network, allowing devices to roam between the networks.
</t> </t>
<t> <t>
In an alternative model, some countries are now in the process of allocating 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 parts of the 5G spectrum for local use to industries. These non-service
providers then have a choice of applying for a local license themselves and providers then have the choice to apply for a local license themselves and
operating their own network or cooperating with a public network operator or operate their own network or to cooperate with a public network operator or
service provider. service provider.
</t> </t>
</section><!-- Deployment and Spectrum --> </section>
<section><name>Applicability to Deterministic Flows</name> <section><name>Applicability to Deterministic Flows</name>
<section><name>System Architecture</name> <section><name>System Architecture</name>
<t> <t>
The 5G system <xref target='TS23501'/> consists of the User Equipment (UE) 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 as at the terminal side, the Radio Access Network (RAN) with the gNodeB (gNB) as
radio base station node, as well as the Core Network (CN), which is connected radio base station node, and the Core Network (CN), which is connected
to the external Data Network (DN). The core network is based on a service-bas to the external Data Network (DN). The CN is based on a service-based
ed architecture with the following central functions: Access and Mobility Manage
architecture with the central functions: Access and Mobility Management ment
Function (AMF), Session Management Function (SMF) and User Plane Function (UP Function (AMF), Session Management Function (SMF), and User Plane Function (U
F) PF)
as illustrated in <xref target='fig-5g-arch'/>. "(Note that this document onl as illustrated in <xref target='fig-5g-arch'/>. (Note that this document only
y explains key functions; however, <xref target='fig-5g-arch'/> provides a more
explains key functions, however, <xref target='fig-5g-arch'/> provides a more detailed view, and <xref target='SYSTOVER5G'/> summarizes the functions and p
detailed view, and rovides the full
<xref target='SYSTOVER5G'/> summarizes the functions and provides the full definitions of the acronyms used in the figure.)
definition of acronyms used in the figure.)"
</t> </t>
<t>The gNB’s main responsibility is the radio resource management, including <t>The gNB's main responsibility is radio resource management, including
admission control and scheduling, mobility control and radio measurement admission control and scheduling, mobility control, and radio measurement
handling. The AMF handles the UE’s connection status and security, while the handling. The AMF handles the UE's connection status and security, while the
SMF controls the UE’s data sessions. The UPF handles the user plane traffic. SMF controls the UE's data sessions. The UPF handles the user plane traffic.
</t> </t>
<t>The SMF can instantiate various Packet Data Unit (PDU) sessions for the <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 UE, each associated with a set of QoS flows, i.e., with different QoS
profiles. Segregation of those sessions is also possible, e.g., resource profiles). Segregation of those sessions is also possible; for example, resou
isolation in the RAN and in the CN can be defined (slicing). rce
isolation in the RAN and CN can be defined (slicing).
</t> </t>
<figure anchor='fig-5g-arch'><name>5G System Architecture</name> <figure anchor='fig-5g-arch'><name>5G System Architecture</name>
<artwork align="center"><![CDATA[ <artwork align="center"><![CDATA[
+----+ +---+ +---+ +---+ +---+ +---+ +----+ +---+ +---+ +---+ +---+ +---+
|NSSF| |NEF| |NRF| |PCF| |UDM| |AF | |NSSF| |NEF| |NRF| |PCF| |UDM| |AF |
+--+-+ +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ +--+-+ +-+-+ +-+-+ +-+-+ +-+-+ +-+-+
| | | | | | | | | | | |
Nnssf| Nnef| Nnrf| Npcf| Nudm| Naf| Nnssf| Nnef| Nnrf| Npcf| Nudm| Naf|
| | | | | | | | | | | |
skipping to change at line 1553 skipping to change at line 2153
/ | | / | |
+--+-+ +--+--+ +--+---+ +----+ +--+-+ +--+--+ +--+---+ +----+
| UE +---+(R)AN+--N3--+ UPF +--N6--+ DN | | UE +---+(R)AN+--N3--+ UPF +--N6--+ DN |
+----+ +-----+ ++----++ +----+ +----+ +-----+ ++----++ +----+
| | | |
+-N9-+ +-N9-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
To allow UE mobility across cells/gNBs, handover mechanisms are supported in To allow UE mobility across cells/gNBs, handover mechanisms are supported
NR. For an established connection, i.e., connected mode mobility, a gNB can in NR. For an established connection (i.e., connected mode mobility), a gNB
configure a UE to report measurements of received signal strength and can configure a UE to report measurements of received signal strength and
quality of its own and neighbouring cells, periodically or event-based. quality of its own and neighboring cells, periodically or based on events.
Based on these measurement reports, the gNB decides to handover a UE to Based on these measurement reports, the gNB decides to hand over a UE to
another target cell/gNB. Before triggering the handover, it is hand-shaked another target cell/gNB. Before triggering the handover, it is handshaked
with the target gNB based on network signalling. A handover command is then with the target gNB based on network signaling. A handover command is then
sent to the UE and the UE switches its connection to the target cell/gNB. sent to the UE, and the UE switches its connection to the target cell/gNB.
The Packet Data Convergence Protocol (PDCP) of the UE can be configured to The Packet Data Convergence Protocol (PDCP) of the UE can be configured to
avoid data loss in this procedure, i.e., handle retransmissions if needed. avoid data loss in this procedure, i.e., to handle retransmissions if
Data forwarding is possible between source and target gNB as well. To needed. Data forwarding is possible between source and target gNB as
improve the mobility performance further, i.e., to avoid connection failures, well. To improve the mobility performance further (i.e., to avoid connection
e.g., due to too-late handovers, the mechanism of conditional handover is failures due to too-late handovers), the mechanism of
introduced in Release 16 specifications. Therein a conditional handover conditional handover is introduced in Release 16 specifications. Therein, a
command, defining a triggering point, can be sent to the UE before UE enters conditional handover command, defining a triggering point, can be sent to
a handover situation. A further improvement that has been introduced in the UE before the UE enters a handover situation. A further improvement that
Release 16 is the Dual Active Protocol Stack (DAPS), where the UE maintains has been introduced in Release 16 is the Dual Active Protocol Stack (DAPS),
the connection to the source cell while connecting to the target cell. This where the UE maintains the connection to the source cell while connecting
way, potential interruptions in packet delivery can be avoided entirely. to the target cell. This way, potential interruptions in packet delivery
can be avoided entirely.
</t> </t>
</section><!-- System Architecture --> </section>
<section><name>Overview of The Radio Protocol Stack</name> <section><name>Overview of the Radio Protocol Stack</name>
<t> <t>
The protocol architecture for NR consists of the L1 Physical layer (PHY) and The protocol architecture for NR consists of the Layer 1 Physical (PHY) layer
as part of the L2, the sublayers of Medium Access Control (MAC), Radio Link and,
Control (RLC), Packet Data Convergence Protocol (PDCP), as well as the as part of Layer 2, the sublayers of Medium Access Control (MAC), Radio Link
Control (RLC), Packet Data Convergence Protocol (PDCP), and
Service Data Adaption Protocol (SDAP). Service Data Adaption Protocol (SDAP).
</t> </t>
<t> <t>
The PHY layer handles signal processing related actions, such as The PHY layer handles actions related to signal processing, such as
encoding/decoding of data and control bits, modulation, antenna precoding encoding/decoding of data and control bits, modulation, antenna precoding,
and mapping. and mapping.
</t> </t>
<t> <t>
The MAC sub-layer handles multiplexing and priority handling of logical The MAC sublayer handles multiplexing and priority handling of logical
channels (associated with QoS flows) to transport blocks for PHY channels (associated with QoS flows) to transport blocks for PHY
transmission, as well as scheduling information reporting and error transmission, as well as scheduling information reporting and error
correction through Hybrid Automated Repeat Request (HARQ). correction through Hybrid Automated Repeat Request (HARQ).
</t> </t>
<t> <t>
The RLC sublayer handles sequence numbering of higher layer packets, The RLC sublayer handles sequence numbering of higher-layer packets,
retransmissions through Automated Repeat Request (ARQ), if configured, as retransmissions through Automated Repeat Request (ARQ), if configured, as
well as segmentation and reassembly and duplicate detection. well as segmentation and reassembly and duplicate detection.
</t> </t>
<t> <t>
The PDCP sublayer consists of functionalities for ciphering/deciphering, The PDCP sublayer consists of functionalities for ciphering/deciphering,
integrity protection/verification, re-ordering and in-order delivery, integrity protection/verification, reordering and in-order delivery, and
duplication and duplicate handling for higher layer packets, and acts as the duplication and duplicate handling for higher-layer packets. This sublayer al
so acts as the
anchor protocol to support handovers. anchor protocol to support handovers.
</t> </t>
<t> <t>
The SDAP sublayer provides services to map QoS flows, as established by the The SDAP sublayer provides services to map QoS flows, as established by the
5G core network, to data radio bearers (associated with logical channels), 5G core network, to data radio bearers (associated with logical channels),
as used in the 5G RAN. as used in the 5G RAN.
</t> </t>
<t> <t>
Additionally, in RAN, the Radio Resource Control (RRC) protocol, handles the Additionally, in RAN, the Radio Resource Control (RRC) protocol handles the
access control and configuration signalling for the aforementioned protocol access control and configuration signaling for the aforementioned protocol
layers. RRC messages are considered L3 and thus transmitted also via those layers. RRC messages are considered Layer 3 and are thus also transmitted via
those
radio protocol layers. radio protocol layers.
</t> </t>
<t> <t>To provide low latency and high reliability for one transmission
To provide low latency and high reliability for one transmission link, i.e., link (i.e., to transport data or control signaling of one radio
to transport data (or control signaling) of one radio bearer via one carrier, bearer via one carrier), several features have been introduced on the
several features have been introduced on the user plane protocols for PHY user plane protocols for PHY and Layer 2, as explained below.
and L2, as explained in the following.
</t> </t>
</section><!-- Overview of Radio Protocol Stack --> </section>
<section><name>Radio (PHY)</name> <section><name>Radio (PHY)</name>
<t> <t>
NR is designed with native support of antenna arrays utilizing benefits from NR is designed with native support of antenna arrays utilizing benefits from
beamforming, transmissions over multiple MIMO layers and advanced receiver beamforming, transmissions over multiple MIMO layers, and advanced receiver
algorithms allowing effective interference cancellation. Those antenna algorithms allowing effective interference cancellation. Those antenna
techniques are the basis for high signal quality and effectiveness of techniques are the basis for high signal quality and the effectiveness of
spectral usage. Spatial diversity with up to 4 MIMO layers in UL and up to 8 spectral usage. Spatial diversity with up to four MIMO layers in UL and up to
eight
MIMO layers in DL is supported. Together with spatial-domain multiplexing, MIMO layers in DL is supported. Together with spatial-domain multiplexing,
antenna arrays can focus power in desired direction to form beams. NR 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 supports beam management mechanisms to find the best suitable beam for UE
initially and when it is moving. In addition, gNBs can coordinate their initially and when it is moving. In addition, gNBs can coordinate their
respective DL and UL transmissions over the backhaul network keeping respective DL and UL transmissions over the backhaul network, keeping
interference reasonably low, and even make transmissions or receptions from interference reasonably low, and even make transmissions or receptions from
multiple points (multi-TRP). Multi-TRP can be used for repetition of data multiple points (multi-TRP). Multi-TRP can be used for repetition of a data
packet in time, in frequency or over multiple MIMO layers which can improve packet in time, in frequency, or over multiple MIMO layers, which can improve
reliability even further. reliability even further.
</t> </t>
<t> <t>
Any downlink transmission to a UE starts from resource allocation signaling Any downlink transmission to a UE starts from resource allocation signaling
over the Physical Downlink Control Channel (PDCCH). If it is successfully over the Physical Downlink Control Channel (PDCCH). If it is successfully
received, the UE will know about the scheduled transmission and may receive received, the UE will know about the scheduled transmission and may receive
data over the Physical Downlink Shared Channel (PDSCH). If retransmission is data over the Physical Downlink Shared Channel (PDSCH). If retransmission is
required according to the HARQ scheme, a signaling of negative required according to the HARQ scheme, a signaling of negative
acknowledgement (NACK) on the Physical Uplink Control Channel (PUCCH) is acknowledgement (NACK) on the Physical Uplink Control Channel (PUCCH) is
involved and PDCCH together with PDSCH transmissions (possibly with involved, and PDCCH together with PDSCH transmissions (possibly with
additional redundancy bits) are transmitted and soft-combined with additional redundancy bits) are transmitted and soft-combined with
previously received bits. Otherwise, if no valid control signaling for previously received bits. Otherwise, if no valid control signaling for
scheduling data is received, nothing is transmitted on PUCCH (discontinuous scheduling data is received, nothing is transmitted on PUCCH (discontinuous
transmission - DTX),and the base station upon detecting DTX will retransmit transmission (DTX)), and upon detecting DTX, the base station will retransmit
the initial data. the initial data.
</t> </t>
<t> <t>
An uplink transmission normally starts from a Scheduling Request (SR) – a An uplink transmission normally starts from a Scheduling Request (SR), a
signaling message from the UE to the base station sent via PUCCH. signaling message from the UE to the base station sent via PUCCH.
Once the scheduler is informed about buffer data in UE, e.g., by SR, the UE Once the scheduler is informed about buffer data in the UE (e.g., by SR), the UE
transmits a data packet on the Physical Uplink Shared Channel (PUSCH). transmits a data packet on the Physical Uplink Shared Channel (PUSCH).
Pre-scheduling not relying on SR is also possible (see following section). Pre-scheduling, not relying on SR, is also possible (see <xref target="schedu ling_qos"/>).
</t> </t>
<t> <t>
Since transmission of data packets require usage of control and data Since transmission of data packets requires usage of control and data
channels, there are several methods to maintain the needed reliability. NR channels, there are several methods to maintain the needed reliability. NR
uses Low Density Parity Check (LDPC) codes for data channels, Polar codes uses Low Density Parity Check (LDPC) codes for data channels, polar codes
for PDCCH, as well as orthogonal sequences and Polar codes for PUCCH. For for PDCCH, as well as orthogonal sequences and polar codes for PUCCH. For
ultra-reliability of data channels, very robust (low spectral efficiency) ultra-reliability of data channels, very robust (low-spectral efficiency)
Modulation and Coding Scheme (MCS) tables are introduced containing very low 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 (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 channels support multiple code rates including very low ones for the channel
robustness. robustness.
</t> </t>
<t> <t>
A connected UE reports downlink (DL) quality to gNB by sending Channel State A connected UE reports downlink (DL) quality to gNB by sending Channel State
Information (CSI) reports via PUCCH while uplink (UL) quality is measured Information (CSI) reports via PUCCH while uplink (UL) quality is measured
directly at gNB. For both uplink and downlink, gNB selects the desired MCS 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 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 PDCCH channel. For URLLC services, the UE can assist the gNB by advising
that MCS targeting 10^-5 Block Error Rate (BLER) are used. Robust link that MCS targeting a 10^-5 Block Error Rate (BLER) are used. Robust link
adaptation algorithms can maintain the needed level of reliability adaptation algorithms can maintain the needed level of reliability,
considering a given latency bound. considering a given latency bound.
</t> </t>
<t> <t>
Low latency on the physical layer is provided by short transmission duration Low latency on the physical layer is provided by short transmission duration,
which is possible by using high Subcarrier Spacing (SCS) and the allocation which is possible by using high Subcarrier Spacing (SCS) and the allocation
of only one or a few Orthogonal Frequency Division Multiplexing (OFDM) of only one or a few Orthogonal Frequency Division Multiplexing (OFDM)
symbols. For example, the shortest latency for the worst case in DL can be symbols. For example, the shortest latency for the worst case is
0.23ms and in UL can be 0.24ms according to (section 5.7.1 in 0.23 ms in DL and 0.24 ms in UL (according to Section 5.7.1 in
<xref target='TR37910'/>). Moreover, if the initial transmission has failed, <xref target='TR37910'/>). Moreover, if the initial transmission has failed,
HARQ feedback can quickly be provided and an HARQ retransmission is HARQ feedback can quickly be provided and an HARQ retransmission
scheduled. scheduled.
</t> </t>
<t> <t>
Dynamic multiplexing of data associated with different services is highly Dynamic multiplexing of data associated with different services is highly
desirable for efficient use of system resources and to maximize system desirable for efficient use of system resources and to maximize system
capacity. Assignment of resources for eMBB is usually done with regular capacity. Assignment of resources for eMBB is usually done with regular
(longer) transmission slots, which can lead to blocking of low latency (longer) transmission slots, which can lead to blocking of low-latency
services. To overcome the blocking, eMBB resources can be pre-empted and services. To overcome the blocking, eMBB resources can be preempted and
re-assigned to URLLC services. In this way, spectrally efficient assignments reassigned to URLLC services. In this way, spectrally efficient assignments
for eMBB can be ensured while providing flexibility required to ensure a 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 bounded latency for URLLC services. In downlink, the gNB can notify the eMBB
UE about pre-emption after it has happened, while in uplink there are two UE about preemption after it has happened, while in uplink there are two
pre-emption mechanisms: special signaling to cancel eMBB transmission and preemption mechanisms: special signaling to cancel eMBB transmission and
URLLC dynamic power boost to suppress eMBB transmission. URLLC dynamic power boost to suppress eMBB transmission.
</t> </t>
</section><!-- Radio (PHY) --> </section>
<section><name>Scheduling and QoS (MAC)</name> <section anchor="scheduling_qos"><name>Scheduling and QoS (MAC)</name>
<t> <t>
One integral part of the 5G system is the Quality of Service (QoS) framework One integral part of the 5G system is the Quality of Service (QoS) framework
<xref target='TS23501'/>. QoS flows are setup by the 5G system for certain <xref target='TS23501'/>. QoS flows are set up by the 5G system for certain
IP or Ethernet packet flows, so that packets of each flow receive the same IP or Ethernet packet flows, so that packets of each flow receive the same
forwarding treatment, i.e., in scheduling and admission control. QoS flows forwarding treatment (i.e., in scheduling and admission control). For example
can for example be associated with different priority level, packet delay , QoS flows
budgets and tolerable packet error rates. Since radio resources are can be associated with different priority levels, packet delay
budgets, and tolerable packet error rates. Since radio resources are
centrally scheduled in NR, the admission control function can ensure that centrally scheduled in NR, the admission control function can ensure that
only those QoS flows are admitted for which QoS targets can be reached. only QoS flows for which QoS targets can be reached are admitted.
</t> </t>
<t> <t>
NR transmissions in both UL and DL are scheduled by the gNB NR transmissions in both UL and DL are scheduled by the gNB
<xref target='TS38300'/>. This ensures radio resource efficiency, fairness <xref target='TS38300'/>. This ensures radio resource efficiency and fairness
in resource usage of the users and enables differentiated treatment of the in resource usage of the users, and it enables differentiated treatment of th
e
data flows of the users according to the QoS targets of the flows. Those QoS 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 flows are handled as data radio bearers or logical channels in NR RAN
scheduling. scheduling.
</t> </t>
<t> <t>
The gNB can dynamically assign DL and UL radio resources to users, The gNB can dynamically assign DL and UL radio resources to users,
indicating the resources as DL assignments or UL grants via control channel 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 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, domain and time domain. Different lengths are supported in time domain,
i.e., (multiple) slot or mini-slot lengths. Resources of multiple frequency (i.e., multiple slot or mini-slot lengths). Resources of multiple frequency
carriers can be aggregated and jointly scheduled to the UE. carriers can be aggregated and jointly scheduled to the UE.
</t> </t>
<t> <t>
Scheduling decisions are based, e.g., on channel quality measured on Scheduling decisions are based, e.g., on channel quality measured on
reference signals and reported by the UE (cf. periodical CSI reports for DL reference signals and reported by the UE (cf. periodical CSI reports
channel quality). The transmission reliability can be chosen in the for DL channel quality). The transmission reliability can be chosen
scheduling algorithm, i.e., by link adaptation where an appropriate in the scheduling algorithm, i.e., chosen by link adaptation where an
transmission format (e.g., robustness of modulation and coding scheme, appropriate transmission format (e.g., robustness of modulation and
controlled UL power) is selected for the radio channel condition of the UE. 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 Retransmissions, based on HARQ feedback, are also controlled by the
scheduler. The feedback transmission in HARQ loop introduces delays, but scheduler. The feedback transmission in HARQ loop introduces delays, but
there are methods to minimize it by using short transmission formats, there are methods to minimize it by using short transmission formats,
sub-slot feedback reporting and PUCCH carrier switching. If needed to sub-slot feedback reporting, and PUCCH carrier switching. If needed to
avoid HARQ round-trip time delays, repeated transmissions can be also avoid HARQ round-trip time delays, repeated transmissions can be also
scheduled beforehand, to the cost of reduced spectral efficiency. scheduled beforehand, to the cost of reduced spectral efficiency.
</t> </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> <t>
In dynamic DL scheduling, transmission can be initiated immediately In dynamic DL scheduling, transmission can be initiated immediately
when DL data becomes available in the gNB. However, for dynamic UL when DL data becomes available in the gNB. However, for dynamic UL
scheduling, when data becomes available but no UL resources are available 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) 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 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 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 include a buffer status report that indicates the exact amount of data per
logical channel still left to be sent. More UL resources may be scheduled logical channel still left to be sent. More UL resources may be scheduled
accordingly. To avoid the latency introduced in the scheduling request loop, accordingly. To avoid the latency introduced in the scheduling request loop,
UL radio resources can also be pre-scheduled. UL radio resources can also be pre-scheduled.
</t> </t>
<t> <t>
In particular for periodical traffic patterns, the pre-scheduling can rely In particular, for periodical traffic patterns, the pre-scheduling can rely
on the scheduling features DL Semi-Persistent Scheduling (SPS) and UL on the scheduling features DL Semi-Persistent Scheduling (SPS) and UL
Configured Grant (CG). With these features, periodically recurring resources Configured Grant (CG). With these features, periodically recurring resources
can be assigned in DL and UL. Multiple parallels of those configurations are can be assigned in DL and UL. Multiple parallels of those configurations are
supported, in order to serve multiple parallel traffic flows of the same UE. 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:
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> <t>
To support QoS enforcement in the case of mixed traffic with different QoS To support QoS enforcement in the case of mixed traffic with different QoS
requirements, several features have recently been introduced. This way, requirements, several features have recently been introduced. This way, e.g.,
e.g., different periodical critical QoS flows can be served together with different periodical critical QoS flows can be served, together with
best effort transmissions, by the same UE. Among others, these features best-effort transmissions by the same UE. These features
(partly Release 16) are: 1) UL logical channel transmission restrictions (partly Release 16) include the following:</t>
allowing to map logical channels of certain QoS only to intended UL
resources of a certain frequency carrier, slot-length, or CG configuration,
and 2) intra-UE pre-emption and multiplexing, allowing critical UL
transmissions to either pre-empt non-critical transmissions or being
multiplexed with non-critical transmissions keeping different reliability
targets.
</t>
<ul>
<li>UL logical channel transmission restrictions, allowing logical
channels of certain QoS to only be mapped to intended UL resources of a certai
n frequency
carrier, slot length, or CG configuration.</li>
<li>intra-UE preemption and multiplexing, allowing critical UL
transmissions to either preempt non-critical transmissions or be
multiplexed with non-critical transmissions keeping different reliability
targets.</li>
</ul>
<t> <t>
When multiple frequency carriers are aggregated, duplicate parallel When multiple frequency carriers are aggregated, duplicate parallel
transmissions can be employed (beside repeated transmissions on one transmissions can be employed (beside repeated transmissions on one
carrier). This is possible in the Carrier Aggregation (CA) architecture carrier). This is possible in the Carrier Aggregation (CA) architecture
where those carriers originate from the same gNB, or in the Dual where those carriers originate from the same gNB or in the Dual
Connectivity (DC) architecture where the carriers originate from different Connectivity (DC) architecture where the carriers originate from different
gNBs, i.e., the UE is connected to two gNBs in this case. In both cases, gNBs (i.e., the UE is connected to two gNBs in this case). In both cases,
transmission reliability is improved by this means of providing frequency transmission reliability is improved by this means of providing frequency
diversity. diversity.
</t> </t>
<t> <t>
In addition to licensed spectrum, a 5G system can also utilize unlicensed In addition to licensed spectrum, a 5G system can also utilize unlicensed
spectrum to offload non-critical traffic. This version of NR is called NR-U, spectrum to offload non-critical traffic. This version of NR, called NR-U, is
part of 3GPP Release 16. The central scheduling approach applies also for part of 3GPP Release 16. The central scheduling approach also applies for
unlicensed radio resources, but in addition also the mandatory channel unlicensed radio resources and the mandatory channel
access mechanisms for unlicensed spectrum, e.g., Listen Before Talk (LBT) access mechanisms for unlicensed spectrum (e.g., Listen Before Talk (LBT)
are supported in NR-U. This way, by using NR, operators have and can control is supported in NR-U). This way, by using NR, operators have and can control
access to both licensed and unlicensed frequency resources. access to both licensed and unlicensed frequency resources.
</t> </t>
</section><!-- Scheduling and QoS (MAC) --> </section>
<section><name>Time-Sensitive Communications (TSC)</name> <section><name>Time-Sensitive Communications (TSC)</name>
<t> <t>
Recent 3GPP releases have introduced various features to support multiple Recent 3GPP releases have introduced various features to support multiple
aspects of Time-Sensitive Communication (TSC), which includes Time-Sensitive aspects of Time-Sensitive Communication (TSC), which includes Time-Sensitive
Networking (TSN) and beyond as described in this section. Networking (TSN) and beyond, as described in this section.
</t> </t>
<t> <t>
The main objective of Time-Sensitive Networking (TSN) is to provide The main objective of TSN is to provide guaranteed data delivery within a
guaranteed data delivery within a guaranteed time window, i.e., bounded low guaranteed time window (i.e., bounded low latency). IEEE 802.1 TSN <xref
latency. IEEE 802.1 TSN <xref target='IEEE802.1TSN'/> is a set of open target='IEEE802.1TSN'/> is a set of open standards that provide features to
standards that provide features to enable deterministic communication on enable deterministic communication on standard IEEE 802.3 Ethernet <xref
standard IEEE 802.3 Ethernet <xref target='IEEE802.3'/>. TSN standards can target='IEEE802.3'/>. TSN standards can be seen as a toolbox for traffic
be seen as a toolbox for traffic shaping, resource management, time shaping, resource management, time synchronization, and reliability.
synchronization, and reliability.
</t> </t>
<t> <t>
A TSN stream is a data flow between one end station (Talker) to another end A TSN stream is a data flow between one end station (talker) to another end
station (Listener). In the centralized configuration model, TSN bridges are station (listener). In the centralized configuration model, TSN bridges are
configured by the Central Network Controller (CNC) configured by the Central Network Controller (CNC)
<xref target='IEEE802.1Qcc'/> to provide deterministic connectivity for the <xref target='IEEE802.1Qcc'/> to provide deterministic connectivity for the
TSN stream through the network. Time-based traffic shaping provided by TSN stream through the network. Time-based traffic shaping provided by
Scheduled Traffic <xref target='IEEE802.1Qbv'/> may be used to achieve scheduled traffic <xref target='IEEE802.1Qbv'/> may be used to achieve
bounded low latency. The TSN tool for time synchronization is the bounded low latency. The TSN tool for time synchronization is the
generalized Precision Time Protocol (gPTP) <xref target='IEEE802.1AS'/>), generalized Precision Time Protocol (gPTP) <xref target='IEEE802.1AS'/>,
which provides reliable time synchronization that can be used by end which provides reliable time synchronization that can be used by end
stations and by other TSN tools, e.g., Scheduled Traffic stations and by other TSN tools (e.g., scheduled traffic
<xref target='IEEE802.1Qbv'/>. High availability, as a result of <xref target='IEEE802.1Qbv'/>). High availability, as a result of
ultra-reliability, is provided for data flows by the Frame Replication and ultra-reliability, is provided for data flows by the Frame Replication and
Elimination for Reliability (FRER) <xref target='IEEE802.1CB'/> mechanism. Elimination for Reliability (FRER) mechanism <xref target='IEEE802.1CB'/>.
</t> </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> <t>
3GPP Release 16 includes integration of 5G with TSN, i.e., specifies 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 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 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 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 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 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 the TSN bridged network and for hiding the 5GS internal procedures. The 5GS
provides the following components: provides the following components:
</t><ol type='%d.'>
<!-- [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='1'>
<li>interface to TSN controller, as per <xref target='IEEE802.1Qcc'/> for <li>interface to TSN controller, as per <xref target='IEEE802.1Qcc'/> for
the fully centralized configuration model</li> the fully centralized configuration model</li>
<li>time synchronization via reception and transmission of gPTP PDUs <li>time synchronization via reception and transmission of gPTP PDUs
<xref target='IEEE802.1AS'/></li> <xref target='IEEE802.1AS'/></li>
<li>low latency, hence, can be integrated with Scheduled Traffic <li>low latency, hence, can be integrated with scheduled traffic
<xref target='IEEE802.1Qbv'/></li> <xref target='IEEE802.1Qbv'/></li>
<li>reliability, hence, can be integrated with FRER <li>reliability, hence, can be integrated with FRER
<xref target='IEEE802.1CB'/></li> <xref target='IEEE802.1CB'/></li>
</ol><t> </ol>
</t>
<t> <t>
3GPP Release 17 <xref target='TS23501'/> introduced enhancements to 3GPP Release 17 <xref target='TS23501'/> introduced enhancements to
generalize support for Time-Sensitive Communications (TSC) beyond TSN. generalize support for TSC beyond TSN. This includes IP communications to
This includes IP communications to provide time-sensitive service to, e.g., provide time-sensitive services (e.g., to Video, Imaging, and Audio for
Video, Imaging and Audio for Professional Applications (VIAPA). The system Professional Applications (VIAPA)). The system model of 5G
model of 5G acting as a “TSN bridge” in Release 16 has been reused to enable acting as a "TSN bridge" in Release 16 has been reused to enable the 5GS
the 5GS acting as a “TSC node” in a more generic sense (which includes TSN acting as a "TSC node" in a more generic sense (which includes TSN bridge
bridge and IP node). In the case of TSC that does not involve TSN, and IP node). In the case of TSC that does not involve TSN, requirements
requirements are given via exposure interface and the control plane provides are given via exposure interfaces, and the control plane provides the service
the service based on QoS and time synchronization requests from an based on QoS and time synchronization requests from an Application Function
Application Function (AF). (AF).
</t> </t>
<t> <t>
<xref target='fig-5g-tsn'/> shows an illustration of 5G-TSN integration <xref target='fig-5g-tsn'/> shows an illustration of 5G-TSN integration
where an industrial controller (Ind Ctrlr) is connected to industrial where an industrial controller (Ind Ctrlr) is connected to industrial
Input/Output devices (I/O dev) via 5G. The 5GS can directly transport Input/Output devices (I/O dev) via 5G. The 5GS can directly transport
Ethernet frames since Release 15, thus, end-to-end Ethernet connectivity is Ethernet frames since Release 15; thus, end-to-end Ethernet connectivity is
provided. The 5GS implements the required interfaces towards the TSN provided. The 5GS implements the required interfaces towards the TSN
controller functions such as the CNC, thus adapts to the settings of the TSN controller functions such as the CNC, thus adapting to the settings of the TS N
network. A 5G user plane virtual bridge interconnects TSN bridges or connects network. A 5G user plane virtual bridge interconnects TSN bridges or connects
end stations, e.g., I/O devices to the TSN network. TSN Translators (TTs), end stations (e.g., I/O devices to the TSN network). TTs,
i.e., the Device-Side TSN Translator (DS-TT) at the UE and the Network-Side i.e., the Device-Side TSN Translator (DS-TT) at the UE and the Network-Side
TSN Translator (NW-TT) at the UPF have a key role in the interconnection. TSN Translator (NW-TT) at the UPF, have a key role in the interconnection.
Note that the introduction of 5G brings flexibility in various aspects, e.g., Note that the introduction of 5G brings flexibility in various aspects, e.g.,
more flexible network topology because a wireless hop can replace several a more flexible network topology because a wireless hop can replace several
wireline hops thus significantly reduce the number of hops end-to-end. wireline hops, thus significantly reducing the number of hops end to end.
<xref target='TSN5G'/> dives more into the integration of 5G with TSN. <xref target='TSN5G'/> dives more into the integration of 5G with TSN.
</t> </t>
<figure anchor='fig-5g-tsn'><name>5G - TSN Integration</name> <figure anchor='fig-5g-tsn'><name>5G - TSN Integration</name>
<artwork align="center"><![CDATA[ <artwork align="center"><![CDATA[
+------------------------------+ +------------------------------+
| 5G System | | 5G System |
| +---+| | +---+|
| +-+ +-+ +-+ +-+ +-+ |TSN|| | +-+ +-+ +-+ +-+ +-+ |TSN||
| | | | | | | | | | | |AF |......+ | | | | | | | | | | | |AF |......+
skipping to change at line 1957 skipping to change at line 2639
<----------------- end-to-end Ethernet -------------------> <----------------- end-to-end Ethernet ------------------->
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
NR supports accurate reference time synchronization in 1us accuracy level. 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 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 to their OFDM symbol structures. A 5G internal reference time can be
provided to the UE via broadcast or unicast signaling, associating a known 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 OFDM symbol to this reference clock. The 5G internal reference time can be
shared within the 5G network, i.e., radio and core network components. shared within the 5G network (i.e., radio and core network components).
Release 16 has introduced interworking with gPTP for multiple time domains, 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 where the 5GS acts as a virtual gPTP time-aware system and supports the
forwarding of gPTP time synchronization information between end stations and forwarding of gPTP time synchronization information between end stations and
bridges through the 5G user plane TTs. These account for the residence time 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 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 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 the rest of the devices in the deployment, including connected TSN bridges
and end stations. Release 17 includes further improvements, i.e., methods and end stations. Release 17 includes further improvements (i.e., methods
for propagation delay compensation in RAN, further improving the accuracy for propagation delay compensation in RAN), further improving the accuracy
for time synchronization over-the-air, as well as the possibility for the for time synchronization over the air, as well as the possibility for the
TSN grandmaster clock to reside on the UE side. More extensions and TSN grandmaster clock to reside on the UE side. More extensions and
flexibility were added to the time synchronization service making it general flexibility were added to the time synchronization service, making it general
for TSC with additional support of other types of clocks and time for TSC, with additional support of other types of clocks and time
distribution such as boundary clock, transparent clock peer-to-peer, 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. 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 Additionally, it is possible to use internal access stratum signaling to
distribute timing (and not the usual (g)PTP messages), for which the required 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 accuracy can be provided by the AF <xref target='TS23501'/>. The same time
synchronization service is expected to be further extended and enhanced in synchronization service is expected to be further extended and enhanced in
Release 18 to support Timing Resiliency (according to study item Release 18 to support Timing Resiliency (according to study item
<xref target='SP211634'/>), where the 5G system can provide a back-up or <xref target='SP211634'/>), where the 5G system can provide a backup or
alternative timing source for the failure of the local GNSS source (or other alternative timing source for the failure of the local GNSS source (or other
primary timing source) used by the vertical. primary timing source) used by the vertical.
</t> </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> <t>
<!-- <!--
IETF Deterministic Networking (DetNet) is the technology to support IETF Deterministic Networking (DetNet) is the technology to support
time-sensitive communications at the IP layer. 3GPP Release 18 includes a time-sensitive communications at the IP layer. 3GPP Release 18 includes a
study <xref target='TR2370046'/> on whether and how to enable 3GPP support 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 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 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 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 5G System and the translation of DetNet flow specification to 5G QoS
parameters. Note that TSN is the primary subnetwork technology for DetNet. parameters. Note that TSN is the primary subnetwork technology for DetNet.
Thus, the DetNet over TSN work, e.g., <xref target='RFC9023'/>, can be 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 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 such an approach, it is out of scope for the 3GPP Release 18 study item
<xref target='TR2370046'/>. <xref target='TR2370046'/>.
--> -->
IETF Deterministic Networking (DetNet) is the technology to support
<!-- [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 DetNet is the technology to support
time-sensitive communications at the IP layer. 3GPP Release 18 includes a time-sensitive communications at the IP layer. 3GPP Release 18 includes a
study <xref target='TR2370046'/> on interworking between 5G and DetNet. study <xref target='TR2370046'/> on interworking between 5G and DetNet.
Along the TSC framework introduced for Release 17, the 5GS acts as Along the TSC framework introduced for Release 17, the 5GS acts as
a DetNet node for the support of DetNet, see Figure 7.1-1 in a DetNet node for the support of DetNet; see Figure 7.1-1 in
<xref target='TR2370046'/>. <xref target='TR2370046'/>.
The study provides details on how the 5GS is exposed by the Time Sensitive The study provides details on how the 5GS is exposed by the Time Sensitive
Communication and Time Synchronization Function (TSCTSF) to the DetNet Communication and Time Synchronization Function (TSCTSF) to the DetNet
controller as a router on a per UPF controller as a router on a per-UPF
granularity (similarly to the per UPF Virtual TSN Bridge granularity granularity (similar to the per-UPF Virtual TSN Bridge granularity
shown in Figure 11). In particular, it is listed what parameters are shown in <xref target="fig_LDACSframesuper"/>). In particular, it lists the p
arameters that are
provided by the TSCTSF to the DetNet controller. The study also provided by the TSCTSF to the DetNet controller. The study also
includes how the TSCTSF maps DetNet flow parameters to 5G QoS includes how the TSCTSF maps DetNet flow parameters to 5G QoS
parameters. Note that TSN is the primary subnetwork technology for DetNet. parameters. Note that TSN is the primary subnetwork technology for DetNet.
Thus, the DetNet over TSN work, e.g., <xref target='RFC9023'/>, can be Thus, the work on DetNet over TSN, e.g., <xref target='RFC9023'/>, can be
leveraged via the TSN support built in 5G. leveraged via the TSN support built in 5G.
</t> </t>
<t> <t>
Redundancy architectures were specified in order to provide reliability 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 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 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 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 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 independent as illustrated in <xref target='fig-5g-dual-ue'/>. There are two
PDU sessions involved in the solution: the first spans from the UE via gNB1 PDU sessions involved in the solution:
to UPF1, acting as the first PDU session anchor, while the second spans from The first spans from the UE via gNB1 to UPF1, acting as the first PDU
the UE via gNB2 to UPF2, acting as second the PDU session anchor. The session anchor, while
independent paths may continue beyond the 3GPP network. Redundancy Handling the second spans from the UE via gNB2 to UPF2, acting as second the
Functions (RHFs) are deployed outside of the 5GS, i.e., in Host A (the PDU session anchor.
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) <xref target='RFC8655'/>.
</t> </t>
<figure anchor='fig-5g-single-ue'><name>Reliability with Single UE</name> <!-- [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 DetNet
<xref target='RFC8655'/>.
</t>
<figure anchor='fig-5g-single-ue'>
<name>Reliability with Single UE</name>
<artwork align="center"><![CDATA[ <artwork align="center"><![CDATA[
+........+ +........+
. Device . +------+ +------+ +------+ . Device . +------+ +------+ +------+
. . + gNB1 +--N3--+ UPF1 |--N6--+ | . . + gNB1 +--N3--+ UPF1 |--N6--+ |
. ./+------+ +------+ | | . ./+------+ +------+ | |
. +----+ / | | . +----+ / | |
. | |/. | | . | |/. | |
. | UE + . | DN | . | UE + . | DN |
. | |\. | | . | |\. | |
. +----+ \ | | . +----+ \ | |
. .\+------+ +------+ | | . .\+------+ +------+ | |
+........+ + gNB2 +--N3--+ UPF2 |--N6--+ | +........+ + gNB2 +--N3--+ UPF2 |--N6--+ |
+------+ +------+ +------+ +------+ +------+ +------+
]]></artwork> ]]></artwork>
</figure> </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> <t>
An alternative solution is that multiple UEs per device are used for user 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 plane redundancy as illustrated in <xref target='fig-5g-dual-ue'/>. Each UE
sets up a PDU session. The 5GS ensures that those PDU sessions of the sets up a PDU session. The 5GS ensures that the PDU sessions of the
different UEs are handled independently internal to the 5GS. There is no different UEs are handled independently internal to the 5GS. There is no
single point of failure in this solution, which also includes RHF outside 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. of the 5G system, e.g., as per the FRER or PREOF specifications.
</t> </t>
<figure anchor='fig-5g-dual-ue'><name>Reliability with Dual UE</name> <figure anchor='fig-5g-dual-ue'><name>Reliability with Dual UE</name>
<artwork align="center"><![CDATA[ <artwork align="center"><![CDATA[
+.........+ +.........+
. Device . . Device .
. . . .
. +----+ . +------+ +------+ +------+ . +----+ . +------+ +------+ +------+
. | UE +-----+ gNB1 +--N3--+ UPF1 |--N6--+ | . | UE +-----+ gNB1 +--N3--+ UPF1 |--N6--+ |
. +----+ . +------+ +------+ | | . +----+ . +------+ +------+ | |
. . | DN | . . | DN |
. +----+ . +------+ +------+ | | . +----+ . +------+ +------+ | |
. | UE +-----+ gNB2 +--N3--+ UPF2 |--N6--+ | . | UE +-----+ gNB2 +--N3--+ UPF2 |--N6--+ |
. +----+ . +------+ +------+ +------+ . +----+ . +------+ +------+ +------+
. . . .
+.........+ +.........+
]]></artwork> ]]></artwork>
</figure> </figure>
<!-- [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.
Perhaps:
Note that the abstraction provided by the RHF and the location of the
RHF outside of the 5G system allow 5G to support
integration for reliability with both FRER in TSN and PREOF in DetNet,
as they both rely on the same concept.
-->
<t> <t>
Note that the abstraction provided by the RHF and the location of the RHF 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 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 reliability with both FRER of TSN and PREOF of DetNet, as they both rely on
the same concept. the same concept.
</t> </t>
</section>
</section>
</section>
</section><!-- Time-Sensitive Networking (TSN) Integration) --> <section>
<name>L-Band Digital Aeronautical Communications System (LDACS)</name>
</section><!-- Applicability to Deterministic Flows --> <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 suffer
from the VHF band's increasing saturation in high-density areas and the
limitations posed by analog radio. Therefore, aviation (globally and in the
European Union (EU) in particular) strives for a sustainable modernization
of the aeronautical communication infrastructure.</t>
</section> <!-- 5G --> <t>In the long term, ATM communication shall transition from analog VHF
voice and VDL Mode 2 communication to more spectrum-efficient digital data
communication. The European ATM Master Plan foresees this transition to be
realized for terrestrial communications by the development and
implementation of the L-band Digital Aeronautical Communications System
(LDACS).</t>
<section><name>L-band Digital Aeronautical Communications System</name> <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> <t>It is a secure, scalable, and spectrum-efficient data link with embedded
One of the main pillars of the modern Air Traffic Management (ATM) system is the navigation capability; thus, it is the first truly integrated
existence of a communication infrastructure that enables efficient aircraft gui Communications, Navigation, and Surveillance (CNS) system recognized by the
dance and safe separation in all phases of flight. Although current systems are International Civil Aviation Organization (ICAO). During flight tests, the
technically mature, they are suffering from the VHF band’s increasing saturation LDACS capabilities have been successfully demonstrated. A viable rollout
in high-density areas and the limitations posed by analogue radio. Therefore, a scenario has been developed, which allows gradual introduction of LDACS with
viation globally and the European Union (EU) in particular, strives for a sustai immediate use and revenues. Finally, ICAO is developing LDACS standards to
nable modernization of the aeronautical communication infrastructure. pave the way for the future.</t>
</t><t>
In the long-term, ATM communication shall transition from analogue VHF voice and
VDL2 communication to more spectrum efficient digital data communication. The E
uropean ATM Master Plan foresees this transition to be realized for terrestrial
communications by the development and implementation of the L-band Digital Aeron
autical Communications System (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 is a secure, scalable and spectrum efficient data link with
embedded navigation capability and thus, is the first truly integrate
d
Communications, Navigation, and Surveillance (CNS) system recognized
by the International Civil Aviation Organization
(ICAO) During flight tests the LDACS
capabilities have been successfully demonstrated. A viable roll-out
scenario has been developed which allows gradual introduction of LDAC
S
with immediate use and revenues. Finally, ICAO is developing LDACS
standards to pave the way for the future.
</t>
<t>
LDACS shall enable IPv6 based air-ground communication related to the safety and <t>LDACS shall enable IPv6-based air-ground communication related to the
regularity of the flight. The particular challenge is that no new frequencies c safety and regularity of the flight. The particular challenge is that no
an be made available for terrestrial aeronautical communication. It was thus nec new frequencies can be made available for terrestrial aeronautical
essary to develop procedures to enable the operation of LDACS in parallel with o communication. It was thus necessary to develop procedures to enable the
ther services in the same frequency band, more in <xref target='RFC9372'/>. operation of LDACS in parallel with other services in the same frequency
</t> band; see <xref target='RFC9372'/> for more information.</t>
<section><name>Provenance and Documents</name>
<t> <section>
The development of LDACS has already made substantial progress in the <name>Provenance and Documents</name>
Single European Sky ATM Research (SESAR) framework, and is currently being cont <t>The development of LDACS has already made substantial progress in
inued in the follow-up program, SESAR2020 <xref target='RIH18'/>. A key objectiv the Single European Sky ATM Research (SESAR) framework, and it is
e of the SESAR activities is to develop, implement and validate a modern aeronau currently being continued in the follow-up program, SESAR2020 <xref
tical data link able to evolve with aviation needs over long-term. To this end, target='RIH18'/>. A key objective of the SESAR activities is to
an LDACS specification has been produced <xref target='GRA19'/> and is continuou develop, implement, and validate a modern aeronautical data link able to
sly updated; transmitter demonstrators were developed to test the spectrum compa evolve with aviation needs over the long term. To this end, an LDACS
tibility of LDACS with legacy systems operating in the L-band <xref target='SAJ1 specification has been produced <xref target='GRA19'/> and is
4'/>; and the overall system performance was analyzed by computer simulations, i continuously updated; transmitter demonstrators were developed to test
ndicating that LDACS can fulfill the identified requirements <xref target='GRA11 the spectrum compatibility of LDACS with legacy systems operating in
'/>. the L-band <xref target='SAJ14'/>, and the overall system performance
</t><t> was analyzed by computer simulations, indicating that LDACS can fulfill
LDACS standardization within the framework of the ICAO started in Dec the identified requirements <xref target='GRA11'/>.</t>
ember 2016. The ICAO standardization group has produced an initial Standards and
Recommended Practices (SARPs) document <xref target='ICAO18'/>. The SARPs docum <t>LDACS standardization within the framework of the ICAO started in
ent defines the general characteristics of LDACS. December 2016. The ICAO standardization group has produced an initial
</t><t> Standards and Recommended Practices (SARPs) document <xref
Up to now the LDACS standardization has been focused on the developme target='ICAO18'/>. The SARPs document defines the general
nt of the physical layer and the data link layer, only recently have higher laye characteristics of LDACS.</t>
rs come into the focus of the LDACS development activities. There is currently n
o "IPv6 over LDACS" specification; however, SESAR2020 has started the testing of <t>Up to now, the LDACS standardization has been focused on the
IPv6-based LDACS testbeds. The IPv6 architecture for the aeronautical telecommu development of the physical layer and the data link layer; only recently
nication network is called the Future Communications Infrastructure (FCI). FCI s have higher layers come into the focus of the LDACS development
hall support quality of service, diversity, and mobility under the umbrella of t activities. There is currently no "IPv6 over LDACS" specification;
he "multi-link concept". This work is conducted by ICAO working group WG-I. however, SESAR2020 has started the testing of IPv6-based LDACS
</t><t> testbeds. The IPv6 architecture for the aeronautical telecommunication
In addition to standardization activities several industrial LDACS pr network is called the Future Communications Infrastructure (FCI). FCI
ototypes have been built. One set of LDACS prototypes has been evaluated in flig shall support QoS, diversity, and mobility under the
ht trials confirming the theoretical results predicting the system performance < umbrella of the "multi-link concept". This work is conducted by the ICAO
xref target='GRA18'/><xref target='BEL22'/><xref target='GRA23'/> . WG-I Working Group.</t>
</t> <t>In addition to standardization activities,
</section><!-- Provenance and Documents --> several industrial LDACS prototypes have been built. One set of LDACS
prototypes has been evaluated in flight trials, confirming the
theoretical results predicting the system performance <xref
target='GRA18'/> <xref target='BEL22'/> <xref target='GRA23'/>.</t>
</section>
<section><name>General Characteristics</name> <section><name>General Characteristics</name>
<t> <t>
LDACS will become one of several wireless access networks connecting LDACS will become one of several wireless access networks connecting
aircraft to the Aeronautical Telecommunications Network (ATN). The aircraft to the Aeronautical Telecommunications Network (ATN). The
LDACS access network contains several ground stations, each of them LDACS access network contains several ground stations, each of which
providing one LDACS radio cell. The LDACS air interface is a provides one LDACS radio cell. The LDACS air interface is a
cellular data link with a star-topology connecting aircraft to cellular data link with a star topology connecting aircraft to
ground-stations with a full duplex radio link. Each ground-station ground stations with a full duplex radio link. Each ground station
is the centralized instance controlling all air-ground communications is the centralized instance controlling all air-ground communications
within its radio cell. within its radio cell.
</t> </t>
<t> <t>
The user data rate of LDACS is 315 kbit/s to 1428 kbit/s on the forwa The user data rate of LDACS is 315 kbit/s to 1428 kbit/s on the
rd link, and 294 kbit/s to 1390 kbit/s on the reverse link, depending on coding forward link and 294 kbit/s to 1390 kbit/s on the reverse link,
and modulation. Due to strong interference from legacy systems in the L-band, th depending on coding and modulation. Due to strong interference from
e most robust coding and modulation should be expected for initial deployment, i legacy systems in the L-band, the most robust coding and modulation
.e., 315/294 kbit/s on the forward/reverse link, respectively. should be expected for initial deployment, i.e., 315 kbit/s on
the forward link and 294 kbit/s on the reverse link.
</t> </t>
<t> <t>
In addition to the communications capability, LDACS also offers a In addition to the communications capability, LDACS also offers a
navigation capability. Ranging data, similar to DME (Distance navigation capability. Ranging data, similar to DME (Distance
Measuring Equipment), is extracted from the LDACS communication links Measuring Equipment), is extracted from the LDACS communication links
between aircraft and LDACS ground stations. This results in LDACS between aircraft and LDACS ground stations. This results in LDACS
providing an APNT (Alternative Position, Navigation and Timing) providing an APNT (Alternative Position, Navigation and Timing)
capability to supplement the existing on-board GNSS (Global Navigatio n capability to supplement the existing on-board GNSS (Global Navigatio n
Satellite System) without the need for additional bandwidth. Satellite System) without the need for additional bandwidth.
Operationally, there will be no difference for pilots whether the Operationally, there will be no difference for pilots whether the
navigation data are provided by LDACS or DME. This capability was navigation data are provided by LDACS or DME. This capability was
flight tested and proven during the MICONAV flight trials in 2019 flight tested and proven during the MICONAV flight trials in 2019
<xref target="BAT19"/>. <xref target="BAT19"/>.
</t> </t>
<t> <t>
In previous works and during the MICONAV flight campaign in 2019, it In previous works and during the MICONAV flight campaign in 2019, it
was also shown, that LDACS can be used for surveillance capability. was also shown that LDACS can be used for surveillance capability.
Filip et al. <xref target="FIL19"/> shown passive radar capabilities Filip et al.&nbsp;<xref target="FIL19"/> have shown the passive radar
of LDACS and capabilities of LDACS, and
Automatic Dependence Surveillance – Contract (ADS-C) was demonstrated Automatic Dependence Surveillance - Contract (ADS-C) was demonstrated
via LDACS during the flight campaign 2019 <xref target="SCH19"/>. via LDACS during the flight campaign 2019 <xref target="SCH19"/>.
</t> </t>
<t> <t>
Since LDACS has been mainly designed for air traffic management commu Since LDACS has been mainly designed for air traffic management
nication it supports mutual entity authentication, integrity and confidentiality communication, it supports mutual entity authentication, integrity
capabilities of user data messages and some control channel protection capabili and confidentiality capabilities of user data messages, and some
ties <xref target="MAE18"/>, <xref target="MAE191"/>, <xref target="MAE192"/>, control channel protection capabilities <xref target="MAE18"/>
<xref target="MAE20"/>. <!--<xref target='MAE19'/>.--> <xref target="MAE191"/> <xref target="MAE192"/> <xref
target="MAE20"/>. <!--<xref target='MAE19'/>.-->
</t> </t>
<t> <t>
Overall this makes LDACS the world's first truly integrated CNS syste Overall, this makes LDACS the world's first truly integrated CNS syst
m em
and is the worldwide most mature, secure, terrestrial long-range CNS and is the most mature, secure, and terrestrial long-range CNS
technology for civil aviation. technology for civil aviation worldwide.
</t> </t>
</section>
</section><!-- General Characteristics -->
<section><name>Deployment and Spectrum</name> <section><name>Deployment and Spectrum</name>
<t> <t>
LDACS has its origin in merging parts of the B-VHF <xref target="BRA0 6"/>, B-AMC LDACS has its origin in merging parts of the B-VHF <xref target="BRA0 6"/>, B-AMC
<xref target="SCH08"/>, TIA-902 (P34) <xref target="HAI09"/>, and WiM <xref target="SCH08"/>, TIA-902 (P34) <xref target="HAI09"/>, and WiM
AX IEEE 802.16e technologies AX IEEE 802.16e
<xref target="EHA11"/>. In 2007 the spectrum for LDACS was allocated <xref target="EHA11"/> technologies. In 2007, the spectrum for LDACS
at the World was allocated at the World
Radio Conference (WRC). Radio Conference (WRC).
</t> </t>
<t> <t>
It was decided to allocate the spectrum next to Distance Measuring It was decided to allocate the spectrum next to Distance Measuring
Equipment (DME), resulting in an in-lay approach between the DME Equipment (DME), resulting in an in-lay approach between the DME
channels for LDAC <xref target="SCH14"/>. channels for LDAC <xref target="SCH14"/>.
</t> </t>
<t> <t>
LDACS is currently being standardized by ICAO and several roll-out LDACS is currently being standardized by ICAO and several rollout
strategies are discussed: strategies are discussed.
</t> </t>
<t> <t>
The LDACS data link provides enhanced capabilities to existing The LDACS data link provides enhanced capabilities to existing
Aeronautical communications infrastructure enabling them to better aeronautical communications infrastructures, enabling them to better
support user needs and new applications. The deployment scalability o f support user needs and new applications. The deployment scalability o f
LDACS allows its implementation to start in areas where most needed t LDACS allows its implementation to start in areas where it is most ne
o eded to
Improve immediately the performance of already fielded infrastructure immediately improve the performance of and already-fielded infrastruc
. ture.
Later the deployment is extended based on operational demand. Later, the deployment is extended based on operational demand.
An attractive scenario for upgrading the existing VHF communication An attractive scenario for upgrading the existing VHF communication
systems by adding an additional LDACS data link is described below. systems by adding an additional LDACS data link is described below.
</t> </t>
<t> <t>
When considering the current VDL Mode 2 infrastructure and user base, When considering the current VDL Mode 2 infrastructure and user base,
a very attractive win-win situation comes about, when the a very attractive win-win situation comes about when the
technological advantages of LDACS are combined with the existing VDL technological advantages of LDACS are combined with the existing VDL
mode 2 infrastructure. LDACS provides at least 50 time more capacity Mode 2 infrastructure. LDACS provides at least 50 times more capacity
than VDL Mode 2 and is a natural enhancement to the existing VDL Mode 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 business model. The advantage of this approach is that the VDL Mode
2 infrastructure can be fully reused. Beyond that, it opens the way 2 infrastructure can be fully reused. Beyond that, it opens the way
for further enhancements <xref target="ICAO19"/>. for further enhancements <xref target="ICAO19"/>.
</t> </t>
</section><!-- Deployment and Spectrum --> </section>
<section><name>Applicability to Deterministic Flows</name> <section><name>Applicability to Deterministic Flows</name>
<t> <t>
As LDACS is a ground-based digital communications system for flight As LDACS is a ground-based digital communications system for flight
guidance and communications related to safety and regularity of guidance and communications related to safety and regularity of
flight, time-bounded deterministic arrival times for safety critical flight, time-bounded deterministic arrival times for safety critical
messages are a key feature for its successful deployment and roll-out . messages are a key feature for its successful deployment and rollout.
</t> </t>
<section><name>System Architecture</name> <section><name>System Architecture</name>
<t> <t>
Up to 512 Aircraft Station (AS) communicate to an LDACS Ground Up to 512 Aircraft Stations (ASes) communicate to an LDACS Ground
Station (GS) in the Reverse Link (RL). GS communicate to an AS in Station (GS) in the reverse link (RL). A GS communicates to an AS
the Forward Link (FL). Via an Access-Router (AC-R) GSs connect in
the LDACS sub-network to the global Aeronautical the Forward Link (FL). Via an Access-Router (AC-R), GSs connect
the LDACS subnetwork to the global Aeronautical
Telecommunications Network (ATN) to which the corresponding Air Telecommunications Network (ATN) to which the corresponding Air
Traffic Services (ATS) and Aeronautical Operational Control (AOC) Traffic Services (ATS) and Aeronautical Operational Control (AOC)
end systems are attached. end systems are attached.
</t> </t>
</section><!-- System Architecture --> </section>
<section><name>Overview of the Radio Protocol Stack</name> <section>
<t> <name>Overview of the Radio Protocol Stack</name>
The protocol stack of LDACS is implemented in the AS and GS: It <t>The protocol stack of LDACS is implemented in the AS and GS; it
consists of the Physical Layer (PHY) with five major functional consists of the physical (PHY) layer with five major functional
blocks above it. Four are placed in the Data Link Layer (DLL) of blocks above it. Four are placed in the data link layer (DLL) of
the the AS and GS:</t>
AS and GS: (1) Medium Access Layer (MAC), (2) Voice Interface (VI <ol>
), <li>Medium Access Layer (MAC),</li>
(3) Data Link Service (DLS), and (4) LDACS Management Entity (LME <li>Voice Interface (VI),</li>
). <li>Data Link Service (DLS), and</li>
The last entity resides within the Sub-Network Layer: Sub-Network <li>LDACS Management Entity (LME).</li>
Protocol (SNP). The LDACS network is externally connected to voi </ol>
ce <t>The last entity resides within the subnetwork layer: the
units, radio control units, and the ATN Network Layer. Subnetwork Protocol (SNP). The LDACS network is externally
connected to voice units, radio control units, and the ATN
network layer.
</t> </t>
<t> <t>
Communications between MAC and LME layer is split into four distinct Communications between the MAC and LME layers is split into four
control channels: distinct control channels:</t>
The Broadcast Control Channel (BCCH) where LDACS ground stations ann <ol>
ounce their specific LDACS cell, including physical parameters and cell identifi <li>the Broadcast Control Channel (BCCH), where LDACS ground station
cation; the Random Access Channel (RACH) where LDACS airborne radios can request s announce their specific LDACS cell,
access to an LDACS cell; the Common Control Channel (CCCH) where LDACS ground s including physical parameters and cell identification;</li>
tations allocate resources to aircraft radios, enabling the airborne side to tra <li>the Random Access Channel (RACH), where LDACS airborne radios ca
nsmit user payload; the Dedicated Control Channel (DCCH) where LDACS airborne ra n request
dios can request user data resources from the LDACS ground station so the airbor access to an LDACS cell;</li>
ne side can transmit user payload. <li>the Common Control Channel (CCCH), where
Communications between MAC and DLS layer is handled by the Data Chan LDACS ground stations allocate resources to aircraft radios,
nel (DCH) where user payload is handled. enabling the airborne side to transmit the user payload; and</li>
<li>the Dedicated Control Channel (DCCH), where LDACS airborne
radios can request user data resources from the LDACS ground
station so the airborne side can transmit the user payload.</li>
</ol>
<t>Communications between the MAC and DLS layers is handled by the Dat
a Channel (DCH) where the user payload is
handled.
</t> </t>
<t> <t>
<xref target="fig_LDACSprotocolstack"/> shows the protocol stack of LDACS as implemented in the AS <xref target="fig_LDACSprotocolstack"/> shows the protocol stack of LDACS as implemented in the AS
and GS. and GS.
</t> </t>
<figure title="LDACS protocol stack in AS and GS" anchor="fig_LDACSp <figure anchor="fig_LDACSprotocolstack">
rotocolstack"> <name>LDACS Protocol Stack in AS and GS</name>
<artwork> <artwork><![CDATA[
<![CDATA[
IPv6 Network Layer IPv6 Network Layer
| |
| |
+------------------+ +----+ +------------------+ +----+
| SNP |--| | Sub-Network | SNP |--| | Subnetwork
| | | | Layer | | | | Layer
+------------------+ | | +------------------+ | |
| | LME| | | LME|
+------------------+ | | +------------------+ | |
| DLS | | | Logical Link | DLS | | | Logical Link
| | | | Control Layer | | | | Control Layer
+------------------+ +----+ +------------------+ +----+
| | | |
DCH DCCH/CCCH DCH DCCH/CCCH
| RACH/BCCH | RACH/BCCH
skipping to change at line 2289 skipping to change at line 3107
+--------------------------+ +--------------------------+
| |
+--------------------------+ +--------------------------+
| PHY | Physical Layer | PHY | Physical Layer
+--------------------------+ +--------------------------+
| |
| |
((*)) ((*))
FL/RL radio channels FL/RL radio channels
separated by separated by
Frequency Division Duplex frequency division duplex
]]></artwork>
]]>
</artwork>
</figure> </figure>
</section><!-- Overview of The Radio Protocol Stack --> </section>
<section><name>Radio (PHY)</name> <section><name>Radio (PHY)</name>
<t> <t>
The physical layer provides the means to transfer data over the r The physical layer provides the means to transfer data over the
adio radio channel. The LDACS ground station supports bidirectional
channel. The LDACS ground-station supports bi-directional links links to multiple aircraft under its control. The forward link
to direction (which is ground to air) and the reverse link
multiple aircraft under its control. The forward link direction direction (which is air to ground) are separated by
(FL; frequency division duplex. Forward link and reverse link use a
ground-to-air) and the reverse link direction (RL; air-to-ground) 500 kHz channel each. The ground station transmits a
are
separated by frequency division duplex. Forward link and reverse
link use a 500 kHz channel each. The ground-station transmits a
continuous stream of OFDM symbols on the forward link. In the continuous stream of OFDM symbols on the forward link. In the
reverse link different aircraft are separated in time and frequen reverse link, different aircrafts are separated in time and
cy frequency using a combination of Orthogonal Frequency-Division
using a combination of Orthogonal Frequency-Division Multiple-Acc Multiple Access (OFDMA) and Time-Division Multiple-Access
ess (TDMA). Thus, aircraft transmit discontinuously on the reverse
(OFDMA) and Time-Division Multiple-Access (TDMA). Aircraft thus link with radio bursts sent in precisely defined transmission
transmit discontinuously on the reverse link with radio bursts se opportunities allocated by the ground station. The most
nt important service on the PHY layer of LDACS is the PHY time
in precisely defined transmission opportunities allocated by the framing service, which indicates that the PHY layer is ready to
ground-station. The most important service on the PHY layer of L transmit in a given slot and indicates PHY layer framing and
DACS timing to the MAC time framing service. LDACS does not support
is the PHY time framing service, which indicates that the PHY lay
er is
ready to transmit in a given slot and to indicate PHY layer frami
ng
and timing to the MAC time framing service. LDACS does not suppor
t
beam-forming or Multiple Input Multiple Output (MIMO). beam-forming or Multiple Input Multiple Output (MIMO).
</t> </t>
</section><!-- Radio (PHY) --> </section>
<section><name>Scheduling, Frame Structure and QoS (MAC)</name> <section><name>Scheduling, Frame Structure, and QoS (MAC)</name>
<t> <t>
The data-link layer provides the necessary protocols to facilitat The data link layer provides the necessary protocols to
e facilitate concurrent and reliable data transfer for multiple
concurrent and reliable data transfer for multiple users. The LD users. The LDACS data link layer is organized in two
ACS sublayers: the medium access sublayer and the logical link
data link layer is organized in two sub-layers: The medium access control sublayer. The medium access sublayer manages the
sub-layer and the logical link control sub-layer. The medium acc organization of transmission opportunities in slots of time and
ess frequency. The logical link control sublayer provides
sub-layer manages the organization of transmission opportunities acknowledged point-to-point logical channels between the
in aircraft and the ground station using an automatic repeat
slots of time and frequency. The logical link control sub-layer request protocol. LDACS also supports unacknowledged
provides acknowledged point-to-point logical channels between the point-to-point channels and ground-to-air broadcast.
aircraft and the ground-station using an automatic repeat request </t>
protocol. LDACS supports also unacknowledged point-to-point chan <t>Next, the frame
nels structure of LDACS is introduced, followed by
and ground-to-air broadcast. a more in-depth discussion of the LDACS medium access.
Before going more into depth about the LDACS medium access, the f
rame structure of LDACS is introduced:
</t> </t>
<t> <t>
The LDACS framing structure for FL and RL is based on Super-Frame s The LDACS framing structure for FL and RL is based on Super-Frame s
(SF) of 240 ms duration. Each SF corresponds to 2000 OFDM symbol s. (SF) of 240 ms duration. Each SF corresponds to 2000 OFDM symbol s.
The FL and RL SF boundaries are aligned in time (from the view of the The FL and RL SF boundaries are aligned in time (from the view of the
GS). GS).
</t> </t>
<t> <t>
In the FL, an SF contains a Broadcast Frame of duration 6.72 ms ( In the FL, an SF contains a broadcast frame with a duration of 6.
56 72 ms (56
OFDM symbols) for the Broadcast Control Channel (BCCH), and four OFDM symbols) for the Broadcast Control Channel (BCCH) and four
Multi-Frames (MF), each of duration 58.32 ms (486 OFDM symbols). Multi-Frames (MF), each with a duration of 58.32 ms (486 OFDM sym
</t> bols).
<t>
In the RL, each SF starts with a Random Access (RA) slot of lengt
h
6.72 ms with two opportunities for sending RL random access frame
s
for the Random Access Channel (RACH), followed by four MFs. Thes
e
MFs have the same fixed duration of 58.32 ms as in the FL, but a
different internal structure
</t> </t>
<t> <t>
<xref target="fig_LDACSframesuper"/> and <xref target="fig_LDACSf In the RL, each SF starts with a Random Access (RA) slot with a
ramesmulti"/> illustrate the LDACS frame structure. length of 6.72 ms with two opportunities for sending RL random
access frames for the Random Access Channel (RACH), followed by
four MFs. These MFs have the same fixed duration of 58.32 ms
as in the FL but a different internal structure.
</t> </t>
<t>Figures <xref target="fig_LDACSframesuper" format="counter"/>
and <xref target="fig_LDACSframesmulti" format="counter"/>
illustrate the LDACS frame structure. This fixed frame structure allo
ws for the reliable and dependable
transmission of data.</t>
<figure title="SF structure for LDACS" anchor="fig_LDACSframesuper"> <figure anchor="fig_LDACSframesuper">
<artwork> <name>SF Structure for LDACS</name>
<![CDATA[ <artwork><![CDATA[
^ ^
| +------+------------+------------+------------+------------+ | +------+------------+------------+------------+------------+
| FL | BCCH | MF | MF | MF | MF | | FL | BCCH | MF | MF | MF | MF |
F +------+------------+------------+------------+------------+ F +------+------------+------------+------------+------------+
r <---------------- Super-Frame (SF) - 240ms ----------------> r <---------------- Super-Frame (SF) - 240 ms --------------->
e e
q +------+------------+------------+------------+------------+ q +------+------------+------------+------------+------------+
u RL | RACH | MF | MF | MF | MF | u RL | RACH | MF | MF | MF | MF |
e +------+------------+------------+------------+------------+ e +------+------------+------------+------------+------------+
n <---------------- Super-Frame (SF) - 240ms ----------------> n <---------------- Super-Frame (SF) - 240 ms --------------->
c c
y y
| |
----------------------------- Time ------------------------------> ----------------------------- Time ------------------------------>
| |
]]> ]]></artwork>
</artwork>
</figure> </figure>
<figure title="MF Structure for LDACS" anchor="fig_LDACSframesmulti" <figure anchor="fig_LDACSframesmulti">
> <name>MF Structure for LDACS</name>
<artwork> <artwork><![CDATA[
<![CDATA[
^ ^
| +-------------+------+-------------+ | +-------------+------+-------------+
| FL | DCH | CCCH | DCH | | FL | DCH | CCCH | DCH |
F +-------------+------+-------------+ F +-------------+------+-------------+
r <---- Multi-Frame (MF) - 58.32ms --> r <--- Multi-Frame (MF) - 58.32 ms -->
e e
q +------+---------------------------+ q +------+---------------------------+
u RL | DCCH | DCH | u RL | DCCH | DCH |
e +------+---------------------------+ e +------+---------------------------+
n <---- Multi-Frame (MF) - 58.32ms --> n <--- Multi-Frame (MF) - 58.32 ms -->
c c
y y
| |
-------------------- Time ------------------> -------------------- Time ------------------>
| |
]]> ]]></artwork>
</artwork>
</figure> </figure>
<!-- [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> <t>
This fixed frame structure allows for a reliable and dependable Next, the LDACS medium
transmission of data. Next, the LDACS medium access layer is introduced.
access layer is introduced:
</t> </t>
<t> <t>
LDACS medium access is always under the control of the ground-station LDACS medium access is always under the control of the ground station
of a radio cell. Any medium access for the transmission of user data of a radio cell. Any medium access for the transmission of user data
has to be requested with a resource request message stating the has to be requested with a resource request message stating the
requested amount of resources and class of service. The ground- requested amount of resources and class of service. The ground
station performs resource scheduling on the basis of these requests station performs resource scheduling on the basis of these requests
and grants resources with resource allocation messages. Resource and grants resources with resource allocation messages. Resource
request and allocation messages are exchanged over dedicated request and allocation messages are exchanged over dedicated
contention-free control channels. contention-free control channels.
</t> </t>
<t> <t>
LDACS has two mechanisms to request resources from the scheduler in LDACS has two mechanisms to request resources from the scheduler in
the ground-station. the ground station.
Resources can either be requested "on demand" or permanently
Resources can either be requested "on demand", or permanently allocat allocated by a LDACS ground station with a given class of service.
ed by a LDACS ground station, with a given class of service. On the forward link, this is done locally in the ground station; on
On the forward link, this is done the reverse link, a dedicated contention-free control channel is
locally in the ground-station, on the reverse link a dedicated used (the Dedicated Control Channel (DCCH); roughly 83 bits every 60
contention-free control channel is used (Dedicated Control Channel ms). A resource allocation is always announced in the control
(DCCH); roughly 83 bit every 60 ms). A resource allocation is always channel of the forward link (Common Control Channel (CCCH);
announced in the control channel of the forward link (Common Control variable sized). Due to the spacing of the reverse link control
Channel (CCCH); variable sized). Due to the spacing of the reverse channels of every 60 ms, a medium access delay in the same order of
link control channels of every 60 ms, a medium access delay in the magnitude is to be expected.
same order of magnitude is to be expected.
</t> </t>
<t> <t>
Resources can also be requested "permanently". The permanent Resources can also be requested "permanently". The permanent
resource request mechanism supports requesting recurring resources in resource request mechanism supports requesting recurring resources at
given time intervals. A permanent resource request has to be given time intervals. A permanent resource request has to be
canceled by the user (or by the ground-station, which is always in canceled by the user (or by the ground station, which is always in
control). User data transmissions over LDACS are therefore always control). User data transmissions over LDACS are therefore always
scheduled by the ground-station, while control data uses statically scheduled by the ground station, while control data uses statically
(i.e. at net entry) allocated recurring resources (DCCH and CCCH). (i.e., at net entry) allocated recurring resources (DCCH and CCCH).
The current specification documents specify no scheduling algorithm. The current specification documents specify no scheduling algorithm.
However performance evaluations so far have used strict priority However, performance evaluations so far have used strict priority
scheduling and round robin for equal priorities for simplicity. In scheduling and round robin for equal priorities for simplicity. In
the current prototype implementations LDACS classes of service are the current prototype implementations, LDACS classes of service are
thus realized as priorities of medium access and not as flows. Note thus realized as priorities of medium access and not as flows. Note
that this can starve out low priority flows. However, this is not that this can starve out low-priority flows. However, this is not
seen as a big problem since safety related message always go first in seen as a big problem since safety-related messages always go first i
n
any case. Scheduling of reverse link resources is done in physical any case. Scheduling of reverse link resources is done in physical
Protocol Data Units (PDU) of 112 bit (or larger if more aggressive Protocol Data Units (PDU) of 112 bits (or larger if more aggressive
coding and modulation is used). Scheduling on the forward link is coding and modulation is used). Scheduling on the forward link is
done Byte-wise since the forward link is transmitted continuously by done byte wise since the forward link is transmitted continuously by
the ground-station. the ground station.
</t> </t>
<t> <t>
In order to support diversity, LDACS supports handovers to other In order to support diversity, LDACS supports handovers to other
ground-stations on different channels. Handovers may be initiated by ground stations on different channels. Handovers may be initiated by
the aircraft (break-before-make) or by the ground-station (make- the aircraft (break before make) or by the ground station (make befor
before-break). Beyond this, FCI diversity shall e break). Beyond this, FCI diversity shall
be implemented by the multi-link concept. be implemented by the multi-link concept.
</t> </t>
</section><!-- Scheduling, Frame Structure and QoS (MAC) --> </section>
</section>
</section><!-- Applicability to deterministic flows --> </section>
</section><!-- title="L-band Digital Aeronautical Communications System" -->
<section><name>IANA Considerations</name> <section><name>IANA Considerations</name>
<t> <t>This document has no IANA actions.</t>
This specification does not require IANA action.
</t>
</section> </section>
<section anchor='sec'><name>Security Considerations</name> <section anchor='sec'><name>Security Considerations</name>
<t> <t>
Most RAW technologies integrate some authentication or encryption Most RAW technologies integrate some authentication or encryption
mechanisms that were defined outside the IETF. mechanisms that are defined outside the IETF. The IETF
The IETF specifications referenced herein each provide their own specifications referenced herein each provide their own security
Security Considerations, and the lower layer technologies used considerations, and the lower-layer technologies used provide their
provide their own security at Layer-2. own security at Layer 2.
</t> </t>
</section> </section>
</middle>
<section><name>Contributors</name> <back>
<t> This document aggregates articles from authors specialized in each <displayreference target="I-D.ietf-6tisch-coap" to="CoAP-6TiSCH"/>
technologies. Beyond the main authors listed in the front page, the following <displayreference target="I-D.ietf-roll-nsa-extension" to="NSA-EXT"/>
contributors proposed additional text and refinement that improved the <displayreference target="IEEE802154" to="IEEE802.15.4"/>
document. <displayreference target="IEEE80211" to="IEEE802.11"/>
</t><dl spacing='normal'> <displayreference target="IEEE8021Qat" to="IEEE802.1Qat"/>
<dt>Georgios Z. Papadopoulos:</dt><dd> Contribute <displayreference target="IEEE80211ad" to="IEEE802.11ad"/>
d to the TSCH section. </dd> <displayreference target="IEEE80211ax" to="IEEE802.11ax"/>
<dt>Nils Maeurer:</dt><dd> Contributed to the LDA <displayreference target="IEEE80211ay" to="IEEE802.11ay"/>
CS section. </dd> <displayreference target="IEEE80211be" to="IEEE802.11be"/>
<dt>Thomas Graeupl:</dt><dd> Contributed to the L
DACS section. </dd>
<dt>Torsten Dudda, Alexey Shapin, and Sara Sandbe
rg:</dt><dd> Contributed to the 5G section. </dd>
<dt>Rocco Di Taranto:</dt><dd> Contributed to the Wi-Fi section<
/dd>
<dt>Rute Sofia:</dt><dd> Contributed to the Introduction and Ter
minology sections</dd>
</dl><t>
</t> <references><name>References</name>
</section>
<section><name>Acknowledgments</name> <!-- [rfced] Would you like the references to be alphabetized
<t> or left in their current order?
Many thanks to the participants of the RAW WG where a lot of the -->
work discussed here happened, and Malcolm Smith for his review of the 802.11 sec
tion. Special thanks for post directorate and IESG reviewers, Roman Danyliw, Vic
toria Pritchard, Donald Eastlake, Mohamed Boucadair, Jiankang Yao, Shivan Kaul S
ahib, Mallory Knodel, Ron Bonica, Ketan Talaulikar, Eric Vyncke, and Carlos Jesu
s Bernardos Cano.
</t>
</section><!-- ack -->
</middle>
-&gt; <!-- [rfced] Note that we removed spaces from some citation tags per
<back> Section 3.5 of RFC 7322 ("RFC Style Guide"). For example:
<displayreference target="IEEE802154" to="IEEE Std 802.15.4"/>
<displayreference target="IEEE80211" to="IEEE Std 802.11"/> Original:
<displayreference target="IEEE8021Qat" to="IEEE Std 802.1Qat"/> [IEEE Std 802.15.4]
<displayreference target="IEEE80211ad" to="IEEE Std 802.11ad"/>
<displayreference target="IEEE80211ax" to="IEEE Std 802.11ax"/> Updated:
<displayreference target="IEEE80211ay" to="IEEE Std 802.11ay"/> [IEEE802.15.4]
<displayreference target="IEEE80211be" to="IEEE 802.11be"/> -->
<!-- [rfced] This reference points to a superseded version of IEEE Std 802.11;
the most recent version was approved in 2024. May we update this
reference to point to the 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 most recent version of the 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 let us know if any updates are needed
or if the 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 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 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 URL and reference to point to the 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 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 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
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 title at the
URL. We have updated this reference to match the URL.
Original:
[IMT2020] "ITU towards IMT for 2020 and 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 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 reference
accordingly.
Original:
[SCH19] Schnell, M., "DLR tests digital communications
technologies combined with additional navigation functions
for the first time", 3 March 2019,
<https://www.dlr.de/dlr/en/desktopdefault.aspx/tabid-
10081/151_read-32951/#/gallery/33877>.
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>.
-->
<references><name>Normative References</name> <references><name>Normative References</name>
<xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5673.x
FC.5673.xml'/> <!-- Industrial Routing Requirements in Low-Power and Lossy Netwo ml'/>
rks --> <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8557.x
<xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R ml'/>
FC.8557.xml'/> <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8655.x
<!-- DetNet PS --> ml'/>
<xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
FC.8655.xml'/> <!-- [RFC9912]
<!-- detnet-architecture --> draft-ietf-raw-architecture-30
<xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference. companion doc RFC 9912
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="edit
or">
</author>
<date month='February' year='2026'/>
</front>
<seriesInfo name="RFC" value="9912"/>
<seriesInfo name="DOI" value="10.17487/RFC9912"/>
</reference>
</references> </references>
<references><name>Informative References</name> <references><name>Informative References</name>
<xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9030.x
FC.9030.xml'/> <!-- 6Tisch Archi --> ml'/>
<xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referenc <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8480.x
e.RFC.8480.xml'/> <!-- 6P Protocol Specification --> ml'/>
<xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC. <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9372.x
9372.xml'/> ml'/>
<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9033.x
ml'/>
<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.x
ml'/>
<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6550.x
ml'/>
<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6551.x
ml'/>
<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6291.x
ml'/>
<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7276.x
ml'/>
<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8279.x
ml'/>
<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9023.x
ml'/>
<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9262.x
ml'/>
<!-- <xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/ref <!-- [I-D.ietf-roll-nsa-extension]
erence.RFC.8938.xml'/> detnet-dataplane --> draft-ietf-roll-nsa-extension-13
IESG State: I-D Exists as of 11/06/25
-->
<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 Contai
ner Extension</title>
<author initials="R." surname="Koutsiamanis" fullname="Remous-Aris Koutsia
manis" role="editor">
<organization>IMT Atlantique</organization>
</author>
<author initials="G. Z." surname="Papadopoulos" fullname="Georgios Z. Papa
dopoulos">
<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" />
<xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referenc e.RFC.9033.xml'/> <!-- 6Tisch MSF --> </reference>
<xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R <!-- [I-D.ietf-roll-dao-projection]
FC.8200.xml'/> <!-- Internet Protocol, Version 6 (IPv6) Specification --> draft-ietf-roll-dao-projection-40
<xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referenc companion doc
e.RFC.6550.xml'/> <!-- RPL --> RFC-to-be 9914
<xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referenc -->
e.RFC.6551.xml'/> <!-- RPL metrics -->
<xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referenc
e.RFC.6291.xml'/> <!-- OAM guidelines -->
<xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referenc
e.RFC.7276.xml'/> <!-- OAM -->
<xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referenc
e.RFC.8279.xml'/> <!-- Mcast BIER -->
<xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.9023.xml'/> <!-- DetNet IP over TSN -->
<xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference
.RFC.9262.xml'/> <!-- bier-te-architecture -->
-&gt; <reference anchor="RFC9914" target="https://www.rfc-editor.org/info/rfc9914">
<xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe <front>
rence.I-D.ietf-roll-nsa-extension.xml'/> <title>Root-Initiated Routing State in the Routing Protocol for Low-Power
<xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/referen and Lossy Networks (RPL)</title>
ce.I-D.ietf-roll-dao-projection.xml'/> <author initials="P." surname="Thubert" fullname="Pascal Thubert" role="ed
<!-- <xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/ref itor">
erence.I-D.thubert-bier-replication-elimination.xml'/> --> </author>
<!--xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe <author initials="R.A." surname="Jadhav" fullname="Rahul Jadhav">
rence.I-D.thubert-6lo-bier-dispatch.xml'/ --> <organization>AccuKnox</organization>
<xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/referen </author>
ce.I-D.ietf-6tisch-coap.xml'/> <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>
<!-- [I-D.ietf-6tisch-coap]
draft-ietf-6tisch-coap-03
IESG State: Expired as of 11/06/25
-->
<reference anchor="I-D.ietf-6tisch-coap" target="https://datatracker.ietf.org/do
c/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 Sudhaaka
r" 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'> <reference anchor='IEEE802154'>
<front> <front>
<title>IEEE Std 802.15.4, Part. 15.4: Wireless Medium Access <title>IEEE Standard for Low-Rate Wireless Networks
Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate
Wireless Personal Area Networks
</title> </title>
<author> <author>
<organization>IEEE standard for Information Technology</organizat ion> <organization>IEEE</organization>
</author> </author>
<date/> <date/>
</front> </front>
<seriesInfo name="IEEE Std" value="802.15.4-2015"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7460875"/>
</reference> </reference>
<reference anchor='IEEE80211' <reference anchor='IEEE80211'
target="https://ieeexplore.ieee.org/document/9363693" > target="https://ieeexplore.ieee.org/document/9363693" >
<front> <front>
<title> <title>
IEEE Standard 802.11 - IEEE Standard for Information IEEE Standard for Information Technology -- Telecommunications and Information E
Technology - Telecommunications and information exchange xchange between Systems - Local and Metropolitan Area Networks -- Specific Requi
between systems Local and metropolitan area networks - rements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (
Specific requirements - Part 11: Wireless LAN Medium PHY) Specifications
Access Control (MAC) and Physical Layer (PHY)
Specifications.
</title> </title>
<author> <author>
<organization>IEEE standard for Information Technology</organizat ion> <organization>IEEE</organization>
</author> </author>
<date/> <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 -[- Telecommunications and Information
Exchange between Systems Local and Metropolitan Area Networks -[- Specific Requi
rements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PH
Y) Specifications
</title>
<author>
<organization>IEEE</organization>
</author>
<date year="2024"/>
</front> </front>
<seriesInfo name="IEEE Std" value="802.11-2024"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2025.10979691"/>
</reference> </reference>
-->
<reference anchor='IEEE80211ax' <reference anchor='IEEE80211ax'
target="https://ieeexplore.ieee.org/document/9442429"> target="https://ieeexplore.ieee.org/document/9442429">
<front> <front>
<title> <title>IEEE Standard for Information Technology -- Telecommunications
802.11ax: Enhancements for High Efficiency WLAN and Information Exchange between Systems Local and Metropolitan Area Networks --
Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Phy
sical Layer (PHY) Specifications Amendment 1: Enhancements for High-Efficiency W
LAN
</title> </title>
<author> <author>
<organization>IEEE standard for Information Technology</organizat ion> <organization>IEEE</organization>
</author> </author>
<date year='2021'/> <date year='2021'/>
</front> </front>
<seriesInfo name="IEEE Std" value="802.11ax-2021"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2021.9442429"/>
</reference> </reference>
<reference anchor='IEEE80211ay' <reference anchor='IEEE80211ay'
target="https://ieeexplore.ieee.org/document/9502046/"> target="https://ieeexplore.ieee.org/document/9502046/">
<front> <front>
<title> <title>IEEE Standard for Information Technology -- Telecommunications
802.11ay: Enhanced throughput for operation in license-exempt bands and Information Exchange between Systems Local and Metropolitan Area Networks --
above 45 GHz Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Phy
sical Layer (PHY) Specifications Amendment 2: Enhanced Throughput for Operation
in License-exempt Bands above 45 GHz
</title> </title>
<author> <author>
<organization>IEEE standard for Information Technology</organizat ion> <organization>IEEE</organization>
</author> </author>
<date year='2021'/> <date year='2021'/>
</front> </front>
<seriesInfo name="IEEE Std" value="802.11ay-2021"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2021.9502046"/>
</reference> </reference>
<reference anchor='IEEE80211ad' <reference anchor='IEEE80211ad'
target="https://ieeexplore.ieee.org/document/6392842/"> target="https://ieeexplore.ieee.org/document/6392842/">
<front> <front>
<title> <title>IEEE Standard for Information technology -- Telecommunications
802.11ad: Enhancements for very high throughput in the 60 GHz band 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 Thro
ughput in the 60 GHz Band
</title> </title>
<author></author> <author>
<organization>IEEE</organization>
</author>
<date year='2012'/> <date year='2012'/>
</front> </front>
<seriesInfo name="IEEE Std" value="802.11ad-2012"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2012.6392842"/>
</reference> </reference>
<reference anchor='IEEE80211be' <reference anchor='IEEE80211be'
target="https://mentor.ieee.org/802.11/dcn/18/11-18-1231-04-0eh t-eht-draft-proposed-par.docx"> target="https://ieeexplore.ieee.org/document/11090080">
<front> <front>
<title> <title>IEEE Standard for Information technology -- Telecommunications
802.11be: Extreme High Throughput PAR and information exchange between systems Local and metropolitan area networks --
Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and P
hysical Layer (PHY) Specifications Amendment 2: Enhancements for Extremely High
Throughput (EHT)
</title> </title>
<author> <author>
<organization>IEEE standard for Information Technology</organizat ion> <organization>IEEE</organization>
</author> </author>
<date/> <date/>
</front> </front>
<seriesInfo name="IEEE Std" value="802.11be-2024"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2024.11090080"/>
</reference> </reference>
<reference anchor='IEEE8021Qat'> <reference anchor='IEEE8021Qat'>
<front> <front>
<title> <title>IEEE Standard for Local and metropolitan area networks -- Virtu
802.1Qat: Stream Reservation Protocol al Bridged Local Area Networks Amendment 14: Stream Reservation Protocol (SRP)
</title> </title>
<author></author> <author>
<organization>IEEE</organization>
</author>
<date/> <date/>
</front> </front>
<seriesInfo name="IEEE Std" value="802.1Qat-2010"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2010.5594972"/>
</reference> </reference>
<reference anchor='Cavalcanti_2019'> <reference anchor='Cavalcanti_2019'>
<front> <front>
<title> <title>Extending Accurate Time Distribution and Timeliness
Extending Time Distribution and Capabilities Over the Air to Enable Future Wireless Industrial
Timeliness Capabilities over the Air to Enable Future Wir Automation Systems
eless Industrial
Automation Systems, the Proceedings of IEEE
</title> </title>
<author initials='' surname='Dave Cavalcanti et al.' fullname='Dave Ca <author fullname='Dave Cavalcanti'/>
valcanti'> <author fullname='Javier Perez-Ramirez'/>
<organization>IEEE standard for Information Technology</organizat <author fullname='Mohammad Mamunur Rashid'/>
ion> <author fullname='Juan Fang'/>
<address></address> <author fullname='Mikhail Galeev'/>
</author> <author fullname='Kevin B. Stanton'/>
<date month='June' year='2019'/> <date month='June' year='2019'/>
</front> </front>
<refcontent>Proceedings of the IEEE, vol. 107, no. 6, pp. 1132-1152</ref
content>
<seriesInfo name="DOI" value="10.1109/JPROC.2019.2903414"/>
</reference> </reference>
<reference anchor='Nitsche_2015'> <reference anchor='Nitsche_2015'>
<front> <front>
<title> <title>
IEEE 802.11ad: directional 60 GHz communication for multi-Gigabit-pe r-second Wi-Fi IEEE 802.11ad: directional 60 GHz communication for multi-Gigabit-pe r-second Wi-Fi
</title> </title>
<author initials='' surname='Thomas Nitsche et al.' fullname='Thomas N <author fullname='Thomas Nitsche'/>
itsche'> <author fullname='Carlos Cordeiro'/>
<organization>IEEE standard for Information Technology</organizat <author fullname='Adriana B. Flores'/>
ion> <author fullname='Edward W. Knightly'/>
<address></address> <author fullname='Eldad Perahia'/>
</author> <author fullname='Joerg C. Widmer'/>
<date month='December' year='2014'/> <date month='December' year='2014'/>
</front> </front>
<refcontent>IEEE Communications Magazine, vol. 52, no. 12, pp. 132-141</
refcontent>
<seriesInfo name="DOI" value="10.1109/MCOM.2014.6979964"/>
</reference> </reference>
<reference anchor='Ghasempour_2017'> <reference anchor='Ghasempour_2017'>
<front> <front>
<title> <title>
802.11ay: Next-Generation 60 GHz Communications for 100 Gb/s Wi-Fi 802.11ay: Next-Generation 60 GHz Communications for 100 Gb/s Wi-Fi
</title> </title>
<author initials='' surname='Yasaman Ghasempour et al.' fullname='Yasa <author fullname='Yasaman Ghasempour'/>
man Ghasempour'> <author fullname='Claudio R. C. M. de Silva'/>
<organization>IEEE standard for Information Technology</organizat <author fullname='Carlos Cordeiro'/>
ion> <author fullname='Edward W. Knightly'/>
<address></address>
</author>
<date month='December' year='2017'/> <date month='December' year='2017'/>
</front> </front>
<refcontent>IEEE Communications Magazine, vol. 55, no. 12, pp. 186-192</
refcontent>
<seriesInfo name="DOI" value="10.1109/MCOM.2017.1700393"/>
</reference> </reference>
<reference anchor='IEEE_doc_11-18-2009-06'> <reference 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> <front>
<title> <title>
802.11 Real-Time Applications (RTA) Topic Interest Group (TIG) Repor t 802.11 Real-Time Applications (RTA) Topic Interest Group (TIG) Repor t
</title> </title>
<author> <author>
<organization>IEEE standard for Information Technology</organizat ion> <organization>IEEE</organization>
</author> </author>
<date month='November' year='2018'/> <date month='November' year='2018'/>
</front> </front>
</reference> </reference>
<!-- <!--
<reference anchor='IEEE_doc_11-19-0373-00'> <reference anchor='IEEE_doc_11-19-0373-00'>
<front> <front>
<title> <title>
Time-Sensitive Applications Support in EHT Time-Sensitive Applications Support in EHT
skipping to change at line 2747 skipping to change at line 3837
</author> </author>
<date month='June' year='2019'/> <date month='June' year='2019'/>
</front> </front>
</reference --> </reference -->
<reference anchor='vilajosana21' target="https://inria.hal.science/hal- 02420974/file/IETF_6TiSCH__A_Tutorial__17099609gkvsxdpffdvc_%20(1).pdf"> <reference anchor='vilajosana21' target="https://inria.hal.science/hal- 02420974/file/IETF_6TiSCH__A_Tutorial__17099609gkvsxdpffdvc_%20(1).pdf">
<front> <front>
<title> <title>
IETF 6TiSCH: A Tutorial IETF 6TiSCH: A Tutorial
</title> </title>
<author initials='' surname='Xavier Vilajosana et al.' fullname='Xavie <author fullname="Xavier Vilajosana"/>
r Vilajosana et al.'> <author fullname="Thomas Watteyne"/>
<organization>IEEE Communications Surveys and Tutorials, vol. 22, no <author fullname="Tengfei Chang"/>
. 1, pp. 595-615 </organization><address></address> <author fullname="Malisa Vucinic"/>
</author> <author fullname="Simon Duquennoy"/>
<date month='March' year='2021'/> <author fullname="Pascal Thubert"/>
<date month="December" year="2019"/>
</front> </front>
<refcontent>Communications Surveys and Tutorials, IEEE Communications So
ciety</refcontent>
<seriesInfo name="HAL ID:" value="hal-02420974"/>
<seriesInfo name="DOI" value="10.1109/COMST.2019.2939407"/>
</reference> </reference>
<reference anchor='ISA100.11a' target='http://www.isa100wci.org/en-US/Docu ments/PDF/3405-ISA100-WirelessSystems-Future-broch-WEB-ETSI.aspx'> <reference anchor='ISA100.11a' target='https://isa100wci.org/about-isa100- wireless?_gl=1*19xrxgo*_up*MQ..*_ga*NDczNjkxOTQ1LjE3NjI0NjQ2NDk.*_ga_L2KSW4EHCS* czE3NjI0NjQ2NDkkbzEkZzEkdDE3NjI0NjQ3MzQkajYwJGwwJGgw'>
<front> <front>
<title>ISA100.11a, Wireless Systems for Automation, also IEC 62734</ti tle> <title>ISA100 Wireless</title>
<author> <author>
<organization>ISA/IEC</organization> <organization>ISA</organization>
</author> </author>
<date year='2011'/>
</front> </front>
<refcontent>ANSI/ISA-100.11a-2011 (IEC 26743)</refcontent>
</reference> </reference>
<reference anchor='WirelessHART'> <reference anchor='WirelessHART' target="https://www.fieldcommgroup.org/te chnologies/wirelesshart">
<front> <front>
<title>Industrial Communication Networks - Wireless Communication <title>WirelessHART</title>
Network and Communication Profiles - WirelessHART - IEC 62591</title
>
<author> <author>
<organization>www.hartcomm.org</organization> <organization>FieldComm Group</organization>
</author> </author>
<date year='2010'/>
</front> </front>
</reference> </reference>
<reference anchor='WFA'> <reference anchor='WFA' target="https://www.wi-fi.org">
<front> <front>
<title>Wi-Fi Alliance</title> <title>Wi-Fi Alliance</title>
<author> <author></author>
<organization>www.wi-fi.org</organization>
</author>
</front> </front>
</reference> </reference>
<reference anchor='Avnu'> <reference anchor='Avnu' target="https://www.avnu.org">
<front> <front>
<title>Avnu Alliance</title> <title>Avnu Alliance</title>
<author> <author>
<organization>avnu.org</organization>
</author> </author>
</front> </front>
</reference> </reference>
<reference anchor='PCE' target='https://dataTracker.ietf.org/doc/charter-i etf-pce/'> <reference anchor='PCE' target='https://datatracker.ietf.org/doc/charter-i etf-pce/'>
<front> <front>
<title>Path Computation Element</title> <title>Path Computation Element</title>
<author> <author>
<organization>IETF</organization> <organization>IETF</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<reference anchor='CCAMP' target='https://dataTracker.ietf.org/doc/charter -ietf-ccamp/'> <reference anchor='CCAMP' target='https://datatracker.ietf.org/doc/charter -ietf-ccamp/'>
<front> <front>
<title>Common Control and Measurement Plane</title> <title>Common Control and Measurement Plane</title>
<author> <author>
<organization>IETF</organization> <organization>IETF</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<!--reference anchor="MPLS" target="https://dataTracker.ietf.org/doc/chart er-ietf-mpls/"> <!--reference anchor="MPLS" target="https://dataTracker.ietf.org/doc/chart er-ietf-mpls/">
<front> <front>
<title>Multiprotocol Label Switching</title> <title>Multiprotocol Label Switching</title>
<author> <author>
<organization>IETF</organization> <organization>IETF</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference--> </reference-->
<reference anchor='TiSCH' target='https://dataTracker.ietf.org/doc/charter -ietf-6tisch/'> <reference anchor='TiSCH' target='https://datatracker.ietf.org/doc/charter -ietf-6tisch/'>
<front> <front>
<title>IPv6 over the TSCH mode over 802.15.4</title> <title>IPv6 over the TSCH mode over 802.15.4e</title>
<author> <author>
<organization>IETF</organization> <organization>IETF</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<reference anchor='RIH18'> <reference anchor='RIH18'>
<front> <front>
<title>L-band Digital Aeronautical Communications System (LDACS) Act ivities in SESAR2020</title> <title>L-band Digital Aeronautical Communications System (LDACS) Act ivities in SESAR2020</title>
skipping to change at line 2850 skipping to change at line 3940
<author fullname='P. Fantappie'></author> <author fullname='P. Fantappie'></author>
<author fullname='S. Pierattelli'></author> <author fullname='S. Pierattelli'></author>
<author fullname='Thomas Gräupl'> <author fullname='Thomas Gräupl'>
<organization>German Aerospace Center (DLR)</organization> <organization>German Aerospace Center (DLR)</organization>
</author> </author>
<author fullname='M. Schnell'> <author fullname='M. Schnell'>
<organization>German Aerospace Center (DLR)</organization></autho r> <organization>German Aerospace Center (DLR)</organization></autho r>
<author fullname='N. Fistas'></author> <author fullname='N. Fistas'></author>
<date month='April' year='2018'/> <date month='April' year='2018'/>
</front> </front>
<seriesInfo name='Proceedings of the Integrated Communications Navigati <refcontent>2018 Integrated Communications, Navigation, Surveillance Co
on and Surveillance Conference (ICNS)' value='Herndon, VA, USA'/> nference (ICNS), pp. 4A1-1-4A1-8</refcontent>
<seriesInfo name="DOI" value="10.1109/ICNSURV.2018.8384880"/>
</reference> </reference>
<reference anchor='GRA19'> <reference 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> <front>
<title>LDACS A/G Specification</title> <title>SESAR2020 - PJ14-02-01 - LDACS A/G SPECIFICATION</title>
<author fullname='Thomas Gräupl'> <author fullname='Thomas Gräupl'>
<organization>German Aerospace Center (DLR)</organization></autho <organization>German Aerospace Center (DLR)</organization>
r> </author>
<author fullname='C. Rihacek'> <author fullname='Christoph Rihacek'>
<organization>German Aerospace Center (DLR)</organization></autho <organization>German Aerospace Center (DLR)</organization>
r> </author>
<author fullname='B. Haindl'> <author fullname='Bernhard Haindl'>
<organization>German Aerospace Center (DLR)</organization></autho <organization>German Aerospace Center (DLR)</organization>
r> </author>
<date month='February' year='2019'/> <author fullname="Quentin Parrod"/>
<date day='16' month='August' year='2019'/>
</front> </front>
<seriesInfo name='SESAR2020' value='PJ14-02-01 D3.3.010'/> <refcontent>EDITION 00.02.02</refcontent>
</reference> </reference>
<reference anchor='SAJ14'> <reference anchor='SAJ14'>
<front> <front>
<title>LDACS1 conformance and compatibility assessment</title> <title>LDACS1 conformance and compatibility assessment</title>
<author fullname='B. Haindl and al'></author> <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'/> <date month='October' year='2014'/>
</front> </front>
<seriesInfo name='IEEE/AIAA 33rd Digital Avionics Systems Conference (D <refcontent>2014 IEEE/AIAA 33rd Digital Avionics Systems Conference (DA
ASC)' value='DOI 10.1109/DASC.2014.6979447'/> SC), pp. 3B3-1-3B3-11</refcontent>
<seriesInfo name="DOI" value="10.1109/DASC.2014.6979447"/>
</reference> </reference>
<reference anchor='GRA11'> <reference anchor='GRA11'>
<front> <front>
<title>L-DACS1 Data Link Layer Evolution of ATN/IPS</title> <title>LDACS1 Data Link Layer Evolution of ATN/IPS</title>
<author fullname='Thomas Gräupl'> <author fullname='Thomas Gräupl'>
<organization>German Aerospace Center (DLR)</organization> <organization>German Aerospace Center (DLR)</organization>
</author> </author>
<author fullname='M. Ehammer'></author>
<date month='October' year='2011'/> <date month='October' year='2011'/>
</front> </front>
<seriesInfo name='Proceedings of the 30th IEEE/AIAA Digital Avionics Sys <refcontent>IEEE/AIAA 30th Digital Avionics Systems Conference, pp. 1-28
tems Conference (DASC)' value='Seattle, WA, USA'/> </refcontent>
<seriesInfo name="DOI" value="10.1109/DASC.2011.6096230"/>
</reference> </reference>
<reference anchor='ICAO18'> <reference anchor='ICAO18' target="https://elibrary.icao.int/product/27981 6">
<front> <front>
<title>L-Band Digital Aeronautical Communication System (LDACS)</tit le> <title>L-Band Digital Aeronautical Communication System (LDACS)</tit le>
<author> <author>
<organization>International Civil Aviation Organization (ICAO)</o rganization> <organization>International Civil Aviation Organization (ICAO)</o rganization>
</author> </author>
<date month='July' year='2018'/> <date month='July' year='2018'/>
</front> </front>
<seriesInfo name='International Standards and Recommended Practices' val ue='Annex 10 - Aeronautical Telecommunications, Vol. III - Communication Systems '/> <refcontent>International Standards and Recommended Practices, Annex 10 - Aeronautical Telecommunications, Vol. III - Communication Systems</refcontent >
</reference> </reference>
<reference anchor='GRA18'> <reference anchor='GRA18'>
<front> <front>
<title>L-band Digital Aeronautical Communications System (LDACS) fli ght trials in the national German project MICONAV</title> <title>L-band Digital Aeronautical Communications System (LDACS) fli ght trials in the national German project MICONAV</title>
<author fullname='Thomas Gräupl et al.'></author> <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'/> <date month='April' year='2018'/>
</front> </front>
<seriesInfo name='Proceedings of the Integrated Communications, Navigati <refcontent>2018 Integrated Communications, Navigation, Surveillance Co
on, Surveillance Conference (ICNS)' value='Herndon, VA, USA'/> nference (ICNS), pp. 4A2-1-4A2-7</refcontent>
<seriesInfo name="DOI" value="10.1109/ICNSURV.2018.8384881"/>
</reference> </reference>
<reference anchor='BEL22' > <reference anchor='BEL22' >
<front> <front>
<title>LDACS Flight Trials: Demonstration of ATS-B2, IPS, and Seamle <title>LDACS Flight Trials: Demonstration and Performance Analysis of
ss Mobility</title> the Future Aeronautical Communications System</title>
<author fullname='Bellido-Manganell, M.A and al'></author> <author fullname="Miguel A. Bellido-Manganell"/>
<date year='2022'/> <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> </front>
<seriesInfo name='IEEE Transactions on Aerospace and Electronic Systems, <refcontent>IEEE Transactions on Aerospace and Electronic Systems, vol.
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>
<reference anchor='GRA23' > <reference anchor='GRA23' >
<front> <front>
<title>LDACS Flight Trials: Demonstration of ATS-B2, IPS, and Seamle ss Mobility</title> <title>LDACS Flight Trials: Demonstration of ATS-B2, IPS, and Seamle ss Mobility</title>
<author fullname='Gräupl, T. and al'></author> <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'/> <date year='2023'/>
</front> </front>
<seriesInfo name='Proceedings of the 2023 Integrated Communication, Navi <refcontent>2023 Integrated Communication, Navigation and Surveillance
gation and Surveillance Conference (ICNS), Herndon, VA, USA' value='DOI 10.1109 Conference (ICNS), pp. 1-13</refcontent>
/ICNS58246.2023.10124329' /> <seriesInfo name="DOI" value="10.1109/ICNS58246.2023.10124329"/>
</reference> </reference>
<reference anchor='TR37910' target='https://portal.3gpp.org/desktopmodules /Specifications/SpecificationDetails.aspx?specificationId=3190'> <reference anchor='TR37910' target='https://portal.3gpp.org/desktopmodules /Specifications/SpecificationDetails.aspx?specificationId=3190'>
<front> <front>
<title>Study on self evaluation towards IMT-2020 submission</title> <title>Study on self evaluation towards IMT-2020 submission</title>
<seriesInfo name="3GPP" value="TR 37.910"/> <seriesInfo name="3GPP" value="TR 37.910"/>
<author> <author>
<organization showOnFrontPage="true">3GPP</organization> <organization showOnFrontPage="true">3GPP</organization>
</author> </author>
</front> </front>
skipping to change at line 2987 skipping to change at line 4125
<title>System architecture for the 5G System (5GS)</title> <title>System architecture for the 5G System (5GS)</title>
<seriesInfo name="3GPP" value="TS 23.501"/> <seriesInfo name="3GPP" value="TS 23.501"/>
<author> <author>
<organization showOnFrontPage="true">3GPP</organization> <organization showOnFrontPage="true">3GPP</organization>
</author> </author>
</front> </front>
</reference> </reference>
<reference anchor='TS38300' target='https://portal.3gpp.org/desktopmodule s/Specifications/SpecificationDetails.aspx?specificationId=3191'> <reference anchor='TS38300' target='https://portal.3gpp.org/desktopmodule s/Specifications/SpecificationDetails.aspx?specificationId=3191'>
<front> <front>
<title>NR Overall description</title> <title>NR; NR and NG-RAN Overall description; Stage-2</title>
<seriesInfo name="3GPP" value="TS 38.300"/> <seriesInfo name="3GPP" value="TS 38.300"/>
<author> <author>
<organization showOnFrontPage="true">3GPP</organization> <organization showOnFrontPage="true">3GPP</organization>
</author> </author>
</front> </front>
</reference> </reference>
<reference anchor='SYSTOVER5G' target='https://www.3gpp.org/technologie s/5g-system-overview'> <reference anchor='SYSTOVER5G' target='https://www.3gpp.org/technologie s/5g-system-overview'>
<front> <front>
<title>5G system overview</title> <title>5G System Overview</title>
<author> <author>
<organization showOnFrontPage="true">3GPP</organization> <organization showOnFrontPage="true">3GPP</organization>
</author> </author>
<date day="8" month="8" year="2022"/>
</front> </front>
</reference> </reference>
<reference anchor='RP210854' target='https://www.3gpp.org/ftp/tsg_ran/T SG_RAN/TSGR_91e/Docs/RP-210854.zip'> <reference anchor='RP210854' target='https://www.3gpp.org/ftp/tsg_ran/T SG_RAN/TSGR_91e/Docs/RP-210854.zip'>
<front> <front>
<title>Revised WID: Enhanced Industrial Internet of Things (IoT) and u ltra-reliable and low latency communication (URLLC) support for NR</title> <title>Revised WID: Enhanced Industrial Internet of Things (IoT) and u ltra-reliable and low latency communication (URLLC) support for NR</title>
<seriesInfo name="3GPP" value="RP-210854"/> <seriesInfo name="3GPP" value="RP-210854"/>
<author> <author>
<organization showOnFrontPage="true">3GPP</organization> <organization showOnFrontPage="true">3GPP</organization>
</author> </author>
<date month='March' year='2021'/> <date month='March' year='2021'/>
</front> </front>
</reference> </reference>
<reference anchor='TR2370046' target='https://portal.3gpp.org/desktopmo dules/Specifications/SpecificationDetails.aspx?specificationId=3994'> <reference anchor='TR2370046' target='https://portal.3gpp.org/desktopmo dules/Specifications/SpecificationDetails.aspx?specificationId=3994'>
<front> <front>
<title>Study on 5GS DetNet interworking</title> <title> Study on 5GS Deterministic Networking (DetNet) interworking</t
<seriesInfo name="3GPP" value="TR23.700-46"/> itle>
<seriesInfo name="3GPP" value="TR 23.700-46"/>
<author> <author>
<organization showOnFrontPage="true">3GPP</organization> <organization showOnFrontPage="true">3GPP</organization>
</author> </author>
<date month='August' year='2022'/>
</front> </front>
</reference> </reference>
<!--reference anchor='SP211633' target='https://www.3gpp.org/ftp/tsg_sa /TSG_SA/TSGS_94E_Electronic_2021_12/Docs/SP-211633.zip'> <!--reference anchor='SP211633' target='https://www.3gpp.org/ftp/tsg_sa /TSG_SA/TSGS_94E_Electronic_2021_12/Docs/SP-211633.zip'>
<front> <front>
<title>New SID: Extensions to the TSC Framework to support DetNet</tit le> <title>New SID: Extensions to the TSC Framework to support DetNet</tit le>
<seriesInfo name="3GPP" value="SP-211633"/> <seriesInfo name="3GPP" value="SP-211633"/>
<author> <author>
<organization showOnFrontPage="true">3GPP</organization> <organization showOnFrontPage="true">3GPP</organization>
</author> </author>
skipping to change at line 3050 skipping to change at line 4188
<seriesInfo name="3GPP" value="SP-211634"/> <seriesInfo name="3GPP" value="SP-211634"/>
<author> <author>
<organization showOnFrontPage="true">3GPP</organization> <organization showOnFrontPage="true">3GPP</organization>
</author> </author>
<date month='December' year='2021'/> <date month='December' year='2021'/>
</front> </front>
</reference> </reference>
<reference anchor='IMT2020' target='https://www.itu.int/en/ITU-R/study- groups/rsg5/rwp5d/imt-2020/Pages/default.aspx'> <reference anchor='IMT2020' target='https://www.itu.int/en/ITU-R/study- groups/rsg5/rwp5d/imt-2020/Pages/default.aspx'>
<front> <front>
<title>ITU towards IMT for 2020 and beyond</title> <title>IMT-2020 (a.k.a. "5G")</title>
<author></author> <author>
<organization>ITU</organization>
</author>
</front> </front>
</reference> </reference>
<reference anchor="IEEE802.1TSN" target="http://www.ieee802.org/1/pages/ts n.html" quoteTitle="true" derivedAnchor="IEEE802.1TSN"> <reference anchor="IEEE802.1TSN" target="http://www.ieee802.org/1/pages/ts n.html">
<front> <front>
<title>Time-Sensitive Networking (TSN) Task Group</title> <title>Time-Sensitive Networking Task Group</title>
<author> <author>
<organization showOnFrontPage="true">IEEE 802.1</organization> <organization showOnFrontPage="true">IEEE 802.1 Working Group</organ ization>
</author> </author>
</front> </front>
</reference> </reference>
<reference anchor="IEEE802.1AS" target="https://standards.ieee.org/content/ ieee-standards/en/standard/802_1AS-2020.html" quoteTitle="true" derivedAnchor="I EEE802.1AS"> <reference anchor="IEEE802.1AS">
<front> <front>
<title>IEEE Standard for Local and metropolitan area networks -- Timin <title>IEEE Standard for Local and Metropolitan Area Networks -- Timin
g and Synchronization for Time-Sensitive Applications</title> g and Synchronization for Time-Sensitive Applications</title>
<seriesInfo name="IEEE" value="802.1AS-2020"/>
<author> <author>
<organization showOnFrontPage="true">IEEE</organization> <organization showOnFrontPage="true">IEEE</organization>
</author> </author>
</front> </front>
<seriesInfo name="IEEE Std" value="802.1AS-2020"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9121845"/>
</reference> </reference>
<reference anchor="IEEE802.1CB" target="https://ieeexplore.ieee.org/docume nt/8091139" quoteTitle="true" derivedAnchor="IEEE802.1CB"> <reference anchor="IEEE802.1CB" target="https://ieeexplore.ieee.org/docume nt/8091139">
<front> <front>
<title>IEEE Standard for Local and metropolitan area networks -- Frame Replication and Elimination for Reliability</title> <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> <author>
<organization showOnFrontPage="true">IEEE</organization> <organization showOnFrontPage="true">IEEE</organization>
</author> </author>
<date/> <date year="2017"/>
</front> </front>
</reference> <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/docume nt/7440741" quoteTitle="true" derivedAnchor="IEEE802.1Qbv"> <reference anchor="IEEE802.1Qbv">
<front> <front>
<title>IEEE Standard for Local and metropolitan area networks -- Bridg <title>IEEE Standard for Local and metropolitan area networks -- Bridg
es and Bridged Networks -- Amendment 25: Enhancements for Scheduled Traffic</tit es and Bridged Networks - Amendment 25: Enhancements for Scheduled Traffic</titl
le> e>
<seriesInfo name="IEEE" value="802.1Qbv-2015"/>
<author> <author>
<organization showOnFrontPage="true">IEEE</organization> <organization showOnFrontPage="true">IEEE</organization>
</author> </author>
<date year="2016"/>
</front> </front>
<seriesInfo name="IEEE Std" value="802.1Qbv-2015"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2016.8613095"/>
</reference> </reference>
<reference anchor="IEEE802.1Qcc" target="https://ieeexplore.ieee.org/do cument/8514112" quoteTitle="true" derivedAnchor="IEEE802.1Qcc"> <reference anchor="IEEE802.1Qcc" target="https://ieeexplore.ieee.org/do cument/8514112">
<front> <front>
<title>IEEE Standard for Local and metropolitan area networks -- Bridg es and Bridged Networks -- Amendment 31: Stream Reservation Protocol (SRP) Enhan cements and Performance Improvements</title> <title>IEEE Standard for Local and metropolitan area networks -- Bridg es and Bridged Networks -- Amendment 31: Stream Reservation Protocol (SRP) Enhan cements and Performance Improvements</title>
<seriesInfo name="IEEE" value="802.1Qcc-2018"/>
<author> <author>
<organization showOnFrontPage="true">IEEE</organization> <organization showOnFrontPage="true">IEEE</organization>
</author> </author>
</front> </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">
<front>
<title>IEEE Standard for Ethernet</title>
<author>
<organization showOnFrontPage="true">IEEE</organization>
</author>
</front>
<seriesInfo name="IEEE Std" value="802.3-2018"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8457469"/>
</reference> </reference>
<reference anchor="IEEE802.3" target="https://ieeexplore.ieee.org/document <!-- Citation specialist note: XML for possible update to [IEEE802.3]
/8457469" quoteTitle="true" derivedAnchor="IEEE802.3"> <reference anchor="IEEE802.3" target="https://ieeexplore.ieee.org/document
/9844436">
<front> <front>
<title>IEEE Standard for Ethernet</title> <title>IEEE Standard for Ethernet</title>
<seriesInfo name="IEEE" value="802.3-2018"/>
<author> <author>
<organization showOnFrontPage="true">IEEE</organization> <organization showOnFrontPage="true">IEEE</organization>
</author> </author>
</front> </front>
<seriesInfo name="IEEE Std" value="802.3-2022"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2022.9844436"/>
</reference> </reference>
-->
<reference anchor="TSN5G" target="https://5g-acia.org/whitepapers/integrati on-of-5g-with-time-sensitive-networking-for-industrial-communications" quoteTitl e="true" derivedAnchor="TSN5G"> <reference anchor="TSN5G" target="https://5g-acia.org/whitepapers/integrati on-of-5g-with-time-sensitive-networking-for-industrial-communications">
<front> <front>
<title>Integration of 5G with Time-Sensitive Networking for Industrial Communications</title> <title>Integration of 5G with Time-Sensitive Networking for Industrial Communications</title>
<seriesInfo name="5G-ACIA" value="whitepaper"/>
<author> <author>
<organization showOnFrontPage="true">5G-ACIA</organization> <organization showOnFrontPage="true">5G-ACIA</organization>
</author> </author>
</front> </front>
<refcontent>5G-ACIA White Paper</refcontent>
</reference> </reference>
<reference anchor="MAE18"> <!--REF9--> <reference anchor="MAE18"> <!--REF9-->
<front> <front>
<title>A Cybersecurity Architecture for the L-band Digital Aeronautical Co mmunications System (LDACS) <title>A Cybersecurity Architecture for the L-band Digital Aeronautical Co mmunications System (LDACS)
</title> </title>
<author initials="N." surname="Maeurer"/> <author initials="N." surname="Maeurer"/>
<author initials="A." surname="Bilzhause"/> <author initials="A." surname="Bilzhause"/>
<date year="2017"/> <date year="2018"/>
</front> </front>
<seriesInfo name='IEEE 37th Digital Avionics Systems Conference (DASC), pp <refcontent>2018 IEEE/AIAA 37th Digital Avionics Systems Conference (DASC)
. 1-10, London, UK' value=''/> , pp. 1-10</refcontent>
<seriesInfo name="DOI" value="10.1109/DASC.2018.8569878"/>
</reference> </reference>
<reference anchor="MAE191"> <!--REF2--> <reference anchor="MAE191"> <!--REF2-->
<front> <front>
<title>Towards Successful Realization of the LDACS Cybersecurity Architect ure: An Updated Datalink Security Threat- and Risk Analysis <title>Towards Successful Realization of the LDACS Cybersecurity Architect ure: An Updated Datalink Security Threat- and Risk Analysis
</title> </title>
<author initials="N." surname="Maeurer"/> <author initials="N." surname="Maeurer"/>
<author initials="C." surname="Schmitt"/> <author initials="C." surname="Schmitt"/>
<date year="2019"/> <date year="2019"/>
</front> </front>
<seriesInfo name='IEEE Integrated Communications, Navigation and Surveilla <refcontent>Integrated Communications, Navigation and Surveillance Confere
nce Conference (ICNS), pp. 1-13, Herndon, VA, USA' value=''/> nce (ICNS), pp. 1-13</refcontent>
<seriesInfo name="DOI" value="10.1109/ICNSURV.2019.8735139"/>
</reference> </reference>
<reference anchor="ICAO19"> <!--REF2--> <reference anchor="ICAO19" target="https://www.ldacs.com/wp-content/upload s/2013/12/ACP-DCIWG-IP01-LDACS-White-Paper.pdf"> <!--REF2-->
<front> <front>
<title>TLDACS White Paper–A Roll-out Scenario <title>TLDACS White Paper - A Roll-out Scenario
</title> </title>
<author> <author>
<organization showOnFrontPage="true">International Civil Aviation Organiza tion (ICAO)</organization> <organization showOnFrontPage="true">International Civil Aviation Organiza tion (ICAO)</organization>
</author> </author>
<date year="2019" month="October"/> <date year="2019" month="October"/>
</front> </front>
<seriesInfo name='Working Paper <refcontent>Communications Panel - Data Communications
COMMUNICATIONS PANEL–DATA COMMUNICATIONS INFRASTRUCTURE Infrastructure Working Group</refcontent>
WORKING GROUP, Montreal, Canada
' value=''/>
</reference> </reference>
<reference anchor="MAE192"> <!--REF1--> <reference anchor="MAE192"> <!--REF1-->
<front> <front>
<title>Evaluation of the LDACS Cybersecurity Implementation <title>Evaluation of the LDACS Cybersecurity Implementation
</title> </title>
<author initials="N." surname="Maeurer"/> <author initials="N." surname="Maeurer"/>
<author initials="T." surname="Graeupl"/> <author initials="T." surname="Graeupl"/>
<author initials="C." surname="Schmitt"/> <author initials="C." surname="Schmitt"/>
<date year="2019" month="September"/> <date year="2019" month="September"/>
</front> </front>
<seriesInfo name='IEEE 38th Digital Avionics Systems Conference (DACS), pp <refcontent>IEEE/AIAA 38th Digital Avionics Systems Conference (DASC), pp.
. 1-10, San Diego, CA, USA' value=''/> 1-10</refcontent>
<seriesInfo name="DOI" value="10.1109/DASC43569.2019.9081786"/>
</reference> </reference>
<reference anchor="MAE20"> <!--REF1--> <reference anchor="MAE20"> <!--REF1-->
<front> <front>
<title>Comparing Different Diffie-Hellman Key Exchange Flavors for LDACS <title>Comparing Different Diffie-Hellman Key Exchange Flavors for LDACS
</title> </title>
<author initials="N." surname="Maeurer"/> <author initials="N." surname="Maeurer"/>
<author initials="T." surname="Graeupl"/> <author initials="T." surname="Graeupl"/>
<author initials="C." surname="Gentsch"/>
<author initials="C." surname="Schmitt"/> <author initials="C." surname="Schmitt"/>
<date year="2019" month="October"/> <date year="2020"/>
</front> </front>
<seriesInfo name='IEEE 39th Digital Avionics Systems Conference (DACS), pp <refcontent>AIAA/IEEE 39th Digital Avionics Systems Conference (DASC), pp.
. 1-10, San Diego, CA, USA' value=''/> 1-10</refcontent>
<seriesInfo name="DOI" value="10.1109/DASC50938.2020.9256746"/>
</reference> </reference>
<reference anchor="FIL19"> <!--REF1--> <reference anchor="FIL19"> <!--REF1-->
<front> <front>
<title>LDACS- <title>LDACS-
Based Non-Cooperative Surveillance Multistatic Radar Design Based Non-Cooperative Surveillance Multistatic Radar Design
and Detection Coverage Assessment and Detection Coverage Assessment
</title> </title>
<author initials="A." surname="Filip-Dhaubhadel"/> <author initials="A." surname="Filip-Dhaubhadel"/>
<author initials="D." surname="Shutin"/> <author initials="D." surname="Shutin"/>
<date year="2019" month="September"/> <date year="2019"/>
</front> </front>
<seriesInfo name='IEEE 38th Digital Avionics Systems Conference (DACS), pp <refcontent>IEEE/AIAA 38th Digital Avionics Systems Conference (DASC), pp.
. 1-10, San Diego, CA, USA' value=''/> 1-10</refcontent>
<seriesInfo name="DOI" value="10.1109/DASC43569.2019.9081714"/>
</reference> </reference>
<reference anchor="BAT19"> <!--REF2--> <reference anchor="BAT19" target="https://elib.dlr.de/134475/1/08735195.pd f"> <!--REF2-->
<front> <front>
<title>Real-Time Demonstration of <title>Real-Time Demonstration of
Integrated Communication and Navigation Services Using Integrated Communication and Navigation Services Using
LDACS LDACS
</title> </title>
<author initials="G." surname="Battista"/> <author initials="G." surname="Battista"/>
<author initials="O." surname="Osechas"/> <author initials="O." surname="Osechas"/>
<author initials="S." surname="Narayanan"/> <author initials="S." surname="Narayanan"/>
<author initials="O.G." surname="Crespillo"/> <author initials="O.G." surname="Crespillo"/>
<author initials="D." surname="Gerbeth"/> <author initials="D." surname="Gerbeth"/>
<author initials="N." surname="Maeurer"/> <author initials="N." surname="Maeurer"/>
<author initials="D." surname="Mielke"/> <author initials="D." surname="Mielke"/>
<author initials="T." surname="Graeupl"/> <author initials="T." surname="Graeupl"/>
<date year="2019"/> <date year="2019"/>
</front> </front>
<seriesInfo name='IEEE Integrated Communications, Navigation and Surveilla <refcontent>Integrated Communications, Navigation and Surveillance Confere
nce Conference (ICNS), pp. 1-12, Herndon, VA, USA' value=''/> nce (ICNS), pp. i-xii</refcontent>
<seriesInfo name="DOI" value="10.1109/ICNSURV.2019.8735195"/>
</reference> </reference>
<reference anchor="BRA06"> <!--REF1--> <reference anchor="BRA06"> <!--REF1-->
<front> <front>
<title>B-VHF -Selected Simulation Results and Final Assessment <title>B-VHF - Selected Simulation Results and Final Assessment
</title> </title>
<author initials="S." surname="Brandes"/> <author initials="S." surname="Brandes"/>
<author initials="M." surname="Schnell"/> <author initials="M." surname="Schnell"/>
<author initials="C.H." surname="Rokitansky"/> <author initials="C.-h." surname="Rokitansky"/>
<author initials="M." surname="Ehammer"/> <author initials="M." surname="Ehammer"/>
<author initials="T." surname="Graeupl"/> <author initials="T." surname="Graeupl"/>
<author initials="H." surname="Steendam"/> <author initials="H." surname="Steendam"/>
<author initials="M." surname="Guenach"/> <author initials="M." surname="Guenach"/>
<author initials="C." surname="Rihacek"/> <author initials="C." surname="Rihacek"/>
<author initials="B." surname="Haindl"/> <author initials="B." surname="Haindl"/>
<date year="2019" month="September"/> <date year="2006"/>
</front> </front>
<seriesInfo name='IEEE 25th Digital Avionics Systems Conference (DACS), pp <refcontent>IEEE 25th Digital Avionics Systems Conference (DACS), pp. 1-12
. 1-12, New York, NY, USA' value=''/> </refcontent>
<seriesInfo name="DOI" value="10.1109/DASC.2006.313670"/>
</reference> </reference>
<reference anchor="SCH08"> <!--REF2--> <reference anchor="SCH08"> <!--REF2-->
<front> <front>
<title>B-AMC - <title>B-AMC -
Broadband Aeronautical Multi-carrier Communications Broadband Aeronautical Multi-carrier Communications
</title> </title>
<author initials="M." surname="Schnell"/> <author initials="M." surname="Schnell"/>
<author initials="S." surname="Brandes"/> <author initials="S." surname="Brandes"/>
<author initials="S." surname="Gligorevic"/> <author initials="S." surname="Gligorevic"/>
<author initials="C.H." surname="Rokitansky"/> <author initials="C.-H." surname="Rokitansky"/>
<author initials="M." surname="Ehammer"/> <author initials="M." surname="Ehammer"/>
<author initials="T." surname="Graeupl"/> <author initials="T." surname="Graeupl"/>
<author initials="C." surname="Rihacek"/> <author initials="C." surname="Rihacek"/>
<author initials="M." surname="Sajatovic"/> <author initials="M." surname="Sajatovic"/>
<date year="2008" month="April"/> <date year="2008"/>
</front> </front>
<seriesInfo name='IEEE 8th Integrated Communications, Navigation and Surve <refcontent>2008 Integrated Communications, Navigation and Surveillance Co
illance Conference (ICNS), pp. 1-13, New York, NY, USA' value=''/> nference, pp. 1-12</refcontent>
<seriesInfo name="DOI" value="10.1109/ICNSURV.2008.4559173"/>
</reference> </reference>
<reference anchor='SCH19' target='https://www.dlr.de/en/latest/news/2019/0
<reference anchor='SCH19' target='https://www.dlr.de/dlr/en/desktopdefault 1/20190327_modern-technology-for-the-flight-deck'>
.aspx/tabid-10081/151_read-32951/#/gallery/33877'>
<front> <front>
<title>DLR tests digital communications technologies combined with a dditional navigation functions for the first time</title> <title>DLR tests digital communications technologies combined with a dditional navigation functions for the first time</title>
<author fullname='M. Schnell'> <author>
<organization>German Aerospace Center (DLR)</organization></autho r> <organization>German Aerospace Center (DLR)</organization></autho r>
<date day='03' month='March' year='2019'/> <date day='27' month='March' year='2019'/>
</front> </front>
</reference> </reference>
<reference anchor="HAI09"> <!--REF2--> <reference anchor="HAI09"> <!--REF2-->
<front> <front>
<title>Improvement of L-DACS1 Design by Combining B-AMC with P34 <title>Improvement of L-DACS1 Design by Combining B-AMC with P34
and WiMAX Technologies and WiMAX Technologies
</title> </title>
<author initials="B." surname="Haindl"/> <author initials="B." surname="Haindl"/>
<author initials="C." surname="Rihacek"/> <author initials="C." surname="Rihacek"/>
<author initials="M." surname="Sajatovic"/> <author initials="M." surname="Sajatovic"/>
<author initials="B." surname="Phillips"/> <author initials="B." surname="Phillips"/>
<author initials="J." surname="Budinger"/> <author initials="J." surname="Budinger"/>
<author initials="M." surname="Schnell"/> <author initials="M." surname="Schnell"/>
<author initials="D." surname="Kamiano"/> <author initials="D." surname="Kamiano"/>
<author initials="W." surname="Wilson"/> <author initials="W." surname="Wilson"/>
<date year="2009" month="May"/> <date year="2009" month="May"/>
</front> </front>
<seriesInfo name='IEEE 9th Integrated Communications, Navigation and Surve <refcontent>2009 Integrated Communications, Navigation and Surveillance Co
illance Conference (ICNS), pp. 1-8, New York, NY, USA' value=''/> nference, pp. 1-8</refcontent>
<seriesInfo name="DOI" value="10.1109/ICNSURV.2009.5172873"/>
</reference> </reference>
<reference anchor="EHA11"> <!--REF1--> <reference anchor="EHA11"> <!--REF1-->
<front> <front>
<title>AeroMACS - An Airport <title>AeroMACS - An Airport
Communications System Communications System
</title> </title>
<author initials="M." surname="Ehammer"/> <author initials="M." surname="Ehammer"/>
<author initials="E." surname="Pschernig"/>
<author initials="T." surname="Graeupl"/> <author initials="T." surname="Graeupl"/>
<date year="2011" month="September"/> <date year="2011"/>
</front> </front>
<seriesInfo name='IEEE 30th Digital Avionics Systems Conference (DACS), pp <refcontent>2011 IEEE/AIAA 30th Digital Avionics Systems Conference, pp. 4
. 1-16, New York, NY, USA' value=''/> C1-1-4C1-16</refcontent>
<seriesInfo name="DOI" value="10.1109/DASC.2011.6095903"/>
</reference> </reference>
<reference anchor="SCH14"> <!--BELL19--> <reference anchor="SCH14"> <!--BELL19-->
<front> <front>
<title>LDACS: Future Aeronautical Communications for Air- <title>LDACS: Future Aeronautical Communications for Air-
Traffic Management Traffic Management
</title> </title>
<author initials="M." surname="Schnell"/> <author initials="M." surname="Schnell"/>
<author initials="U." surname="Epple"/> <author initials="U." surname="Epple"/>
<author initials="D." surname="Shutin"/> <author initials="D." surname="Shutin"/>
<author initials="N." surname="Schneckenburger"/> <author initials="N." surname="Schneckenburger"/>
<date year="2017" /> <date month="May" year="2014" />
</front> </front>
<seriesInfo name='IEEE Communications Magazine, 52(5), <refcontent>IEEE Communications Magazine, vol. 52, no. 5, pp. 104-110</ref
104-110 content>
' value=''/> <seriesInfo name="DOI" value="10.1109/MCOM.2014.6815900"/>
</reference> </reference>
<reference anchor="Cavalcanti1287" target='https://mentor.ieee.org/802.11/ dcn/19/11-19-1287'> <!--Cavalcanti1287--> <reference anchor="Cavalcanti1287" target='https://mentor.ieee.org/802.11/ dcn/19/11-19-1287'> <!--Cavalcanti1287-->
<front> <front>
<title>TSN support in 802.11 and potential extensions for TGbe <title>TSN support in 802.11 and potential extensions for TGbe
</title> </title>
<author initials="D." surname="Cavalcanti"/> <author initials="D." surname="Cavalcanti"/>
<author initials="G." surname="Venkatesan"/> <author initials="G." surname="Venkatesan"/>
<author initials="L." surname="Cariou"/> <author initials="L." surname="Cariou"/>
<author initials="C." surname="Cordeiro"/> <author initials="C." surname="Cordeiro"/>
<date year="2019" /> <date day="10" month="9" year="2019" />
</front> </front>
</reference> </reference>
<reference anchor="Sudhakaran2021" target='https://ieeexplore.ieee.org/abs tract/document/9483447'> <!--SURUTH --> <reference anchor="Sudhakaran2021" target='https://ieeexplore.ieee.org/abs tract/document/9483447'> <!--SURUTH -->
<front> <front>
<title> <title>
Wireless Time Sensitive Networking for Industrial Collaborative Robotic Workcells Wireless Time Sensitive Networking for Industrial Collaborative Robotic Workcells
</title> </title>
<author initials="S." surname="Sudhakaran"/> <author initials="S." surname="Sudhakaran"/>
<author initials="K." surname="Montgomery"/> <author initials="K." surname="Montgomery"/>
<author initials="M." surname="Kashef"/> <author initials="M." surname="Kashef"/>
<author initials="D." surname="Cavalcanti"/> <author initials="D." surname="Cavalcanti"/>
<author initials="R." surname="Candell"/> <author initials="R." surname="Candell"/>
<date year="2021" /> <date year="2021" />
</front> </front>
<seriesInfo name='17th IEEE International Conference on Factory Communicat <refcontent>2021 17th IEEE International Conference on Factory Communicati
ion Systems (WFCS)' value=''/> on Systems (WFCS), pp. 91-94</refcontent>
<seriesInfo name="DOI" value="10.1109/WFCS46889.2021.9483447"/>
</reference> </reference>
<reference anchor="Fang_2021" > <!--FANG --> <reference anchor="Fang_2021" > <!--FANG -->
<front> <front>
<title> <title>
Wireless TSN with Multi-Radio Wi-Fi Wireless TSN with Multi-Radio Wi-Fi
</title> </title>
<author initials="J." surname="Fang"/> <author initials="J." surname="Fang"/>
<author initials="S." surname="Sudhakaran"/>
<author initials="D." surname="Cavalcanti"/> <author initials="D." surname="Cavalcanti"/>
<author initials="C." surname="Cordeiro"/> <author initials="C." surname="Cordeiro"/>
<author initials="C." surname="Cheng"/> <author initials="C." surname="Chen"/>
<date year="2021" /> <date year="2021" />
</front> </front>
<seriesInfo name='IEEE International Conference on Standards for Communica <refcontent>2021 IEEE Conference on Standards for Communications and Netwo
tions and Networking, December 2021.' value=''/> rking (CSCN), pp. 105-110</refcontent>
<seriesInfo name="DOI" value="10.1109/CSCN53733.2021.9686180"/>
</reference> </reference>
</references> </references>
</back> </references>
</rfc> <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 an
d 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>
<!-- CONVERT WARNING: wide character found at character 2041 of the output --> <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>
<!-- [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 ("Termi
nology").
-->
<ul spacing="normal">
<li><t><contact fullname="Georgios Z. Papadopoulos"/> contributed to the TS
CH section.</t></li>
<li><t><contact fullname="Nils Maeurer"/> and <contact fullname="Thomas Gra
eupl"/> 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 sect
ion.</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 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 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 IEE
E 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>
 End of changes. 540 change blocks. 
1790 lines changed or deleted 2718 lines changed or added

This html diff was produced by rfcdiff 1.48.