rfc9913v1.txt   rfc9913.txt 
Internet Engineering Task Force (IETF) P. Thubert, Ed. Internet Engineering Task Force (IETF) P. Thubert, Ed.
Request for Comments: 9913 Request for Comments: 9913 Independent
Category: Informational D. Cavalcanti Category: Informational D. Cavalcanti
ISSN: 2070-1721 Intel ISSN: 2070-1721 Intel
X. Vilajosana X. Vilajosana
Universitat Oberta de Catalunya Universitat Oberta de Catalunya
C. Schmitt C. Schmitt
Research Institute CODE, UniBw M Research Institute CODE, UniBw M
J. Farkas J. Farkas
Ericsson Ericsson
February 2026 February 2026
Reliable and Available Wireless (RAW) Technologies Reliable and Available Wireless (RAW) Technologies
Abstract Abstract
This document surveys the short- and middle-range radio technologies This document surveys the short- and middle-range radio technologies
over which providing a Deterministic Networking (DetNet) / Reliable over which providing Deterministic Networking (DetNet), and more
and Available Wireless (RAW) service is suitable, presents the specifically, Reliable and Available Wireless (RAW) service is
characteristics that RAW may leverage, and explores the applicability suitable. It also presents the characteristics that RAW may leverage
of the technologies to carry deterministic flows, as of the time of and explores the applicability of the technologies to carry
publication. The studied technologies are Wi-Fi 6/7, Time-Slotted deterministic flows, as of the time of publication. The studied
Channel Hopping (TSCH), 3GPP 5G, and L-band Digital Aeronautical technologies are Wi-Fi 6/7, Time-Slotted Channel Hopping (TSCH), 3GPP
Communications System (LDACS). 5G, and L-band Digital Aeronautical Communications System (LDACS).
Status of This Memo Status of This Memo
This document is not an Internet Standards Track specification; it is This document is not an Internet Standards Track specification; it is
published for informational purposes. published for informational purposes.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents Internet Engineering Steering Group (IESG). Not all documents
skipping to change at line 526 skipping to change at line 526
the underlying mechanism for supporting deterministic flows in a the underlying mechanism for supporting deterministic flows in a
Local Area Network (LAN). The IEEE 802.11 Working Group has Local Area Network (LAN). The IEEE 802.11 Working Group has
incorporated support for absolute time synchronization to extend the incorporated support for absolute time synchronization to extend the
TSN 802.1AS protocol so that time-sensitive flows can experience TSN 802.1AS protocol so that time-sensitive flows can experience
precise time synchronization when operating over 802.11 links. As precise time synchronization when operating over 802.11 links. As
IEEE 802.11 and IEEE 802.1 TSN are both based on the IEEE 802 IEEE 802.11 and IEEE 802.1 TSN are both based on the IEEE 802
architecture, 802.11 devices can directly implement some TSN architecture, 802.11 devices can directly implement some TSN
capabilities without the need for a gateway/translation protocol. capabilities without the need for a gateway/translation protocol.
Basic features required for operation in a 802.1Q LAN are already Basic features required for operation in a 802.1Q LAN are already
enabled for 802.11. Some TSN capabilities, such as 802.1Qbv, can enabled for 802.11. Some TSN capabilities, such as 802.1Qbv, can
already operate over the existing 802.11 MAC SAP [Sudhakaran2021]. already operate over the existing 802.11 MAC Service Access Point
Implementation and experimental results of TSN capabilities (802.1AS, (SAP) [Sudhakaran2021]. Implementation and experimental results of
802.1Qbv, and 802.1CB) extended over standard Ethernet and Wi-Fi TSN capabilities (802.1AS, 802.1Qbv, and 802.1CB) extended over
devices have also been described in [Fang_2021]. Nevertheless, the standard Ethernet and Wi-Fi devices have also been described in
IEEE 802.11 MAC/PHY could be extended to improve the operation of [Fang_2021]. Nevertheless, the IEEE 802.11 MAC/PHY could be extended
IEEE 802.1 TSN features and achieve better performance metrics to improve the operation of IEEE 802.1 TSN features and achieve
[Cavalcanti1287]. better performance metrics [Cavalcanti1287].
TSN capabilities supported over 802.11 (which also extends to TSN capabilities supported over 802.11 (which also extends to
802.11ax) include: 802.11ax) include:
1. 802.1AS-based time synchronization (other time synchronization 1. 802.1AS-based time synchronization (other time synchronization
techniques may also be used) techniques may also be used)
2. Interoperating with IEEE 802.1Q bridges 2. Interoperating with IEEE 802.1Q bridges
3. Time-sensitive traffic stream classification 3. Time-sensitive traffic stream classification
skipping to change at line 589 skipping to change at line 589
with bounded latency, especially in a managed network where stations with bounded latency, especially in a managed network where stations
can be configured to operate under the control of the AP, in a can be configured to operate under the control of the AP, in a
controlled environment (which contains only devices operating on the controlled environment (which contains only devices operating on the
unlicensed band installed by the facility owner and where unexpected unlicensed band installed by the facility owner and where unexpected
interference from other systems and/or radio access technologies only interference from other systems and/or radio access technologies only
sporadically happens), or in a deployment where channel and link sporadically happens), or in a deployment where channel and link
redundancy is used to reduce the impact of unmanaged devices and redundancy is used to reduce the impact of unmanaged devices and
interference. interference.
When the network is lightly loaded, it is possible to achieve When the network is lightly loaded, it is possible to achieve
latencies under 1 msec when Wi-Fi is operated in a contention-based latencies under 1 ms when Wi-Fi is operated in a contention-based
mode (i.e., without OFDMA). It also has been shown that it is mode (i.e., without OFDMA). It also has been shown that it is
possible to achieve 1 msec latencies in a controlled environment with possible to achieve 1 ms latencies in a controlled environment with
higher efficiency when multi-user transmissions are used (enabled by higher efficiency when multi-user transmissions are used (enabled by
OFDMA operation) [Cavalcanti_2019]. Obviously, there are latency, OFDMA operation) [Cavalcanti_2019]. Obviously, there are latency,
reliability, and capacity trade-offs to be considered. For instance, reliability, and capacity trade-offs to be considered. For instance,
smaller RUs result in longer transmission durations, which may impact smaller RUs result in longer transmission durations, which may impact
the minimal latency that can be achieved, but the contention latency the minimal latency that can be achieved, but the contention latency
and randomness elimination in an interference-free environment due to and randomness elimination in an interference-free environment due to
multi-user transmission is a major benefit of the OFDMA mode. multi-user transmission is a major benefit of the OFDMA mode.
The flexibility to dynamically assign RUs to each transmission also The flexibility to dynamically assign RUs to each transmission also
enables the AP to provide frequency diversity, which can help enables the AP to provide frequency diversity, which can help
skipping to change at line 1009 skipping to change at line 1009
to avoid waste of cells as well as overflows in the transmit bundle, to avoid waste of cells as well as overflows in the transmit bundle,
as described in the following paragraphs. as described in the following paragraphs.
On 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. When all of the frames that were received for a given Track packets. When all of the frames that were received for a given Track
are effectively transmitted, any available TX-cell for that Track can are effectively transmitted, any available TX-cell for that Track can
be reused for upper-layer traffic for which the next-hop router be reused for upper-layer traffic for which the next-hop router
matches the next hop along the Track. In that case, the cell that is matches the next hop along the Track. In that case, the cell that is
being used is effectively a TX-cell from the Track, but the short being used is effectively a TX-cell from the Track, but the short
address for the destination is that of the next-hop router. It address for the destination is that of the next-hop router. As a
results that a frame that is received in an RX-cell of a Track with a result, a frame that is received in an RX-cell of a Track with a
destination MAC address set to this node as opposed to broadcast must 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 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 with an unrecognized MAC address is dropped at the lower MAC layer
and thus is not received at the 6top sublayer). and thus is not received at the 6top sublayer).
On the other hand, it might happen that there are not enough TX-cells On the other hand, it might happen that there are not enough TX-cells
in the transmit bundle to accommodate the Track traffic, for in the transmit bundle to accommodate the Track traffic, for
instance, if more retransmissions are needed than provisioned. In instance, if more retransmissions are needed than provisioned. In
that case, the frame can be placed for transmission in the bundle that case, the frame can be placed for transmission in the bundle
that is used for Layer 3 traffic towards the next hop along the Track that is used for Layer 3 traffic towards the next hop along the Track
as long as it can be routed by the upper layer, that is, typically, as long as it can be routed by the upper layer, that is, typically,
if the frame transports an IPv6 packet. The MAC address should be if the frame transports an IPv6 packet. The MAC address should be
set to the next-hop MAC address to avoid confusion. It results that set to the next-hop MAC address to avoid confusion. As a result, a
a frame that is received over a Layer 3 bundle may be in fact frame that is received over a Layer 3 bundle may be in fact
associated with a Track. In a classical IP link such as an Ethernet, associated with a Track. In a classical IP link such as an Ethernet,
off-Track traffic is typically in excess over reservation to be off-Track traffic is typically in excess over reservation to be
routed along the non-reserved path based on its QoS setting. routed along the non-reserved path based on its QoS setting.
However, with 6TiSCH, since the use of the Layer 3 bundle may be due However, with 6TiSCH, since the use of the Layer 3 bundle may be due
to transmission failures, it makes sense for the receiver to to transmission failures, it makes sense for the receiver to
recognize a frame that should be re-Tracked and to place it back on recognize a frame that should be re-Tracked and to place it back on
the appropriate bundle if possible. A frame should be re-Tracked if the appropriate bundle if possible. A frame should be re-Tracked if
the per-hop-behavior group indicated in the Differentiated Services the per-hop-behavior group indicated in the Differentiated Services
field in the IPv6 header is set to deterministic forwarding, as field in the IPv6 header is set to deterministic forwarding, as
discussed in Section 5.3.1.1. A frame is re-Tracked by scheduling it discussed in Section 5.3.1.1. A frame is re-Tracked by scheduling it
skipping to change at line 1138 skipping to change at line 1138
5.3.1.1. Packet Marking and Handling 5.3.1.1. Packet Marking and Handling
Section 4.7.1 of [RFC9030] describes the packet tagging and marking Section 4.7.1 of [RFC9030] describes the packet tagging and marking
that is expected in 6TiSCH networks. that is expected in 6TiSCH networks.
5.3.1.1.1. Tagging Packets for Flow Identification 5.3.1.1.1. Tagging Packets for Flow Identification
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.
It results that the tagging that is used for a DetNet flow outside As a result, the tagging that is used for a DetNet flow outside the
the 6TiSCH Low-Power and Lossy Network (LLN) must be swapped into 6TiSCH Low-Power and Lossy Network (LLN) must be swapped into 6TiSCH
6TiSCH formats and back as the packet enters and then leaves the formats and back as the packet enters and then leaves the 6TiSCH
6TiSCH network. network.
5.3.1.1.2. Replication, Retries, and Elimination 5.3.1.1.2. Replication, Retries, and Elimination
The 6TiSCH architecture [RFC9030] leverages PREOF over several The 6TiSCH architecture [RFC9030] leverages PREOF over several
alternate paths in a network to provide redundancy and parallel alternate paths in a network to provide redundancy and parallel
transmissions to bound the end-to-end delay. Considering the transmissions to bound the end-to-end delay. Considering the
scenario shown in Figure 3, many different paths are possible for S scenario shown in Figure 3, many different paths are possible for S
to reach R. A simple way to benefit from this topology could be to to reach R. A simple way to benefit from this topology could be to
use the two independent paths via nodes A, C, E and via B, D, F, but use the two independent paths via nodes A, C, E and via B, D, F, but
more complex paths are possible as well. more complex paths are possible as well.
skipping to change at line 1212 skipping to change at line 1212
then all the other timeslots in the group are ignored. Now, if there then all the other timeslots in the group are ignored. Now, if there
are at least two groups, the 'AND' relation between the groups are at least two groups, the 'AND' relation between the groups
indicates that one operation must succeed in each of the groups. indicates that one operation must succeed in each of the groups.
Further details can be found in the 6TiSCH architecture document Further details can be found in the 6TiSCH architecture document
[RFC9030]. [RFC9030].
5.3.1.2. Topology and Capabilities 5.3.1.2. Topology and Capabilities
6TiSCH nodes are usually IoT devices, characterized by a very limited 6TiSCH nodes are usually IoT devices, characterized by a very limited
amount of memory, just enough buffers to store one or a few IPv6 amount of memory, just enough buffers to store one or a few IPv6
packets, and limited bandwidth between peers. It results that a node packets, and limited bandwidth between peers. As a result, a node
will maintain only a small amount of peering information and will not will maintain only a small amount of peering information and will not
be able to store many packets waiting to be forwarded. Peers can be be able to store many packets waiting to be forwarded. Peers can be
identified through MAC or IPv6 addresses. identified through MAC or IPv6 addresses.
Neighbors can be discovered over the radio using mechanisms such as Neighbors can be discovered over the radio using mechanisms such as
enhanced beacons, but although the neighbor information is available enhanced beacons, but although the neighbor information is available
in the 6TiSCH interface data model, 6TiSCH does not describe a in the 6TiSCH interface data model, 6TiSCH does not describe a
protocol to proactively push the neighborhood information to a PCE. protocol to proactively push the neighborhood information to a PCE.
This protocol should be described and should operate over CoAP. The This protocol should be described and should operate over CoAP. The
protocol should be able to carry multiple metrics, in particular, the protocol should be able to carry multiple metrics, in particular, the
skipping to change at line 1692 skipping to change at line 1692
Shared Channel (PUSCH). Pre-scheduling, not relying on SR, is also Shared Channel (PUSCH). Pre-scheduling, not relying on SR, is also
possible (see Section 6.4.4). possible (see Section 6.4.4).
Since transmission of data packets requires 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 channels, there are several methods to maintain the needed
reliability. NR uses Low Density Parity Check (LDPC) codes for data reliability. NR uses Low Density Parity Check (LDPC) codes for data
channels, polar codes for PDCCH, as well as orthogonal sequences and channels, polar codes for PDCCH, as well as orthogonal sequences and
polar codes for PUCCH. For ultra-reliability of data channels, very polar codes for PUCCH. For ultra-reliability of data channels, very
robust (low-spectral efficiency) Modulation and Coding Scheme (MCS) robust (low-spectral efficiency) Modulation and Coding Scheme (MCS)
tables are introduced containing very low (down to 1/20) LDPC code tables are introduced containing very low (down to 1/20) LDPC code
rates using BPSK or QPSK. Also, PDCCH and PUCCH channels support rates using Binary Phase-Shift Keying (BPSK) or Quadrature Phase-
multiple code rates including very low ones for the channel Shift Keying (QPSK). Also, PDCCH and PUCCH channels support multiple
robustness. code rates including very low ones for the channel robustness.
A connected UE reports downlink (DL) quality to gNB by sending A connected UE reports downlink (DL) quality to gNB by sending
Channel State Information (CSI) reports via PUCCH while uplink (UL) Channel State Information (CSI) reports via PUCCH while uplink (UL)
quality is measured directly at gNB. For both uplink and downlink, quality is measured directly at gNB. For both uplink and downlink,
gNB selects the desired MCS number and signals it to the UE by gNB selects the desired MCS number and signals it to the UE by
Downlink Control Information (DCI) via PDCCH channel. For URLLC Downlink Control Information (DCI) via PDCCH channel. For URLLC
services, the UE can assist the gNB by advising that MCS targeting a services, the UE can assist the gNB by advising that MCS targeting a
10^-5 Block Error Rate (BLER) are used. Robust link adaptation 10^-5 Block Error Rate (BLER) are used. Robust link adaptation
algorithms can maintain the needed level of reliability, considering algorithms can maintain the needed level of reliability, considering
a given latency bound. a given latency bound.
skipping to change at line 1933 skipping to change at line 1933
|I/O+--+ TSN +------+DS|UE+---+RAN+-+UPF|NW+------+ TSN +----+ |I/O+--+ TSN +------+DS|UE+---+RAN+-+UPF|NW+------+ TSN +----+
|dev| |bridge| | . |TT| | | | | |TT| . | |bridge| |dev| |bridge| | . |TT| | | | | |TT| . | |bridge|
+---+ +------+ | . +--+--+ +---+ +---+--+ . | +------+ +---+ +------+ | . +--+--+ +---+ +---+--+ . | +------+
| +..........................+ | | +..........................+ |
+------------------------------+ +------------------------------+
<----------------- end-to-end Ethernet -------------------> <----------------- end-to-end Ethernet ------------------->
Figure 7: 5G - TSN Integration Figure 7: 5G - TSN Integration
NR supports accurate reference time synchronization in 1us accuracy NR supports accurate reference time synchronization in 1 µs accuracy
level. Since NR is a scheduled system, an NR UE and a gNB are level. Since NR is a scheduled system, an NR UE and a gNB are
tightly synchronized to their OFDM symbol structures. A 5G internal tightly synchronized to their OFDM symbol structures. A 5G internal
reference time can be provided to the UE via broadcast or unicast reference time can be provided to the UE via broadcast or unicast
signaling, associating a known OFDM symbol to this reference clock. signaling, associating a known OFDM symbol to this reference clock.
The 5G internal reference time can be shared within the 5G network The 5G internal reference time can be shared within the 5G network
(i.e., radio and core network components). Release 16 has introduced (i.e., radio and core network components). Release 16 has introduced
interworking with gPTP for multiple time domains, where the 5GS acts interworking with gPTP for multiple time domains, where the 5GS acts
as a virtual gPTP time-aware system and supports the forwarding of as a virtual gPTP time-aware system and supports the forwarding of
gPTP time synchronization information between end stations and gPTP time synchronization information between end stations and
bridges through the 5G user plane TTs. These account for the bridges through the 5G user plane TTs. These account for the
skipping to change at line 2056 skipping to change at line 2056
system is the existence of a communication infrastructure that system is the existence of a communication infrastructure that
enables efficient aircraft guidance and safe separation in all phases enables efficient aircraft guidance and safe separation in all phases
of flight. Although current systems are technically mature, they of flight. Although current systems are technically mature, they
suffer from the VHF band's increasing saturation in high-density suffer from the VHF band's increasing saturation in high-density
areas and the limitations posed by analog radio. Therefore, aviation areas and the limitations posed by analog radio. Therefore, aviation
(globally and in the European Union (EU) in particular) strives for a (globally and in the European Union (EU) in particular) strives for a
sustainable modernization of the aeronautical communication sustainable modernization of the aeronautical communication
infrastructure. infrastructure.
In the long term, ATM communication shall transition from analog VHF In the long term, ATM communication shall transition from analog VHF
voice and VDL Mode 2 communication to more spectrum-efficient digital voice and VHF Digital Link (VDL) Mode 2 communication to more
data communication. The European ATM Master Plan foresees this spectrum-efficient digital data communication. The European ATM
transition to be realized for terrestrial communications by the Master Plan foresees this transition to be realized for terrestrial
development and implementation of the L-band Digital Aeronautical communications by the development and implementation of the L-band
Communications System (LDACS). Digital Aeronautical Communications System (LDACS).
LDACS has been designed with applications related to the safety and LDACS has been designed with applications related to the safety and
regularity of the flight in mind. It has therefore been designed as regularity of the flight in mind. It has therefore been designed as
a deterministic wireless data link (as far as possible). a deterministic wireless data link (as far as possible).
It is a secure, scalable, and spectrum-efficient data link with It is a secure, scalable, and spectrum-efficient data link with
embedded navigation capability; thus, it is the first truly embedded navigation capability; thus, it is the first truly
integrated Communications, Navigation, and Surveillance (CNS) system integrated Communications, Navigation, and Surveillance (CNS) system
recognized by the International Civil Aviation Organization (ICAO). recognized by the International Civil Aviation Organization (ICAO).
During flight tests, the LDACS capabilities have been successfully During flight tests, the LDACS capabilities have been successfully
skipping to change at line 2565 skipping to change at line 2565
coap-03>. coap-03>.
[IEEE802.15.4] [IEEE802.15.4]
IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE
Std 802.15.4-2015, DOI 10.1109/IEEESTD.2016.7460875, Std 802.15.4-2015, DOI 10.1109/IEEESTD.2016.7460875,
<https://doi.org/10.1109/IEEESTD.2016.7460875>. <https://doi.org/10.1109/IEEESTD.2016.7460875>.
[IEEE802.11] [IEEE802.11]
IEEE, "IEEE Standard for Information Technology -- IEEE, "IEEE Standard for Information Technology --
Telecommunications and Information Exchange between Telecommunications and Information Exchange between
Systems - Local and Metropolitan Area Networks -- Specific Systems Local and Metropolitan Area Networks -- Specific
Requirements - Part 11: Wireless LAN Medium Access Control Requirements Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications", IEEE (MAC) and Physical Layer (PHY) Specifications", IEEE
Std 802.11-2020, DOI 10.1109/IEEESTD.2021.9363693, 2020, Std 802.11-2024, DOI 10.1109/IEEESTD.2025.10979691, 2024,
<https://ieeexplore.ieee.org/document/9363693>. <https://ieeexplore.ieee.org/document/10979691>.
[IEEE802.11ax] [IEEE802.11ax]
IEEE, "IEEE Standard for Information Technology -- IEEE, "IEEE Standard for Information Technology --
Telecommunications and Information Exchange between Telecommunications and Information Exchange between
Systems Local and Metropolitan Area Networks -- Specific Systems Local and Metropolitan Area Networks -- Specific
Requirements Part 11: Wireless LAN Medium Access Control Requirements Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications Amendment 1: (MAC) and Physical Layer (PHY) Specifications Amendment 1:
Enhancements for High-Efficiency WLAN", IEEE Std 802.11ax- Enhancements for High-Efficiency WLAN", IEEE Std 802.11ax-
2021, DOI 10.1109/IEEESTD.2021.9442429, 2021, 2021, DOI 10.1109/IEEESTD.2021.9442429, 2021,
<https://ieeexplore.ieee.org/document/9442429>. <https://ieeexplore.ieee.org/document/9442429>.
skipping to change at line 2841 skipping to change at line 2841
[IEEE802.1Qcc] [IEEE802.1Qcc]
IEEE, "IEEE Standard for Local and metropolitan area IEEE, "IEEE Standard for Local and metropolitan area
networks -- Bridges and Bridged Networks -- Amendment 31: networks -- Bridges and Bridged Networks -- Amendment 31:
Stream Reservation Protocol (SRP) Enhancements and Stream Reservation Protocol (SRP) Enhancements and
Performance Improvements", IEEE Std 802.1Qcc-2018, Performance Improvements", IEEE Std 802.1Qcc-2018,
DOI 10.1109/IEEESTD.2018.8514112, DOI 10.1109/IEEESTD.2018.8514112,
<https://ieeexplore.ieee.org/document/8514112>. <https://ieeexplore.ieee.org/document/8514112>.
[IEEE802.3] [IEEE802.3]
IEEE, "IEEE Standard for Ethernet", IEEE Std 802.3-2018, IEEE, "IEEE Standard for Ethernet", IEEE Std 802.3-2022,
DOI 10.1109/IEEESTD.2018.8457469, DOI 10.1109/IEEESTD.2022.9844436,
<https://ieeexplore.ieee.org/document/8457469>. <https://ieeexplore.ieee.org/document/9844436>.
[TSN5G] 5G-ACIA, "Integration of 5G with Time-Sensitive Networking [TSN5G] 5G-ACIA, "Integration of 5G with Time-Sensitive Networking
for Industrial Communications", 5G-ACIA White Paper, for Industrial Communications", 5G-ACIA White Paper,
<https://5g-acia.org/whitepapers/integration-of-5g-with- <https://5g-acia.org/whitepapers/integration-of-5g-with-
time-sensitive-networking-for-industrial-communications>. time-sensitive-networking-for-industrial-communications>.
[MAE18] Maeurer, N. and A. Bilzhause, "A Cybersecurity [MAE18] Maeurer, N. and A. Bilzhause, "A Cybersecurity
Architecture for the L-band Digital Aeronautical Architecture for the L-band Digital Aeronautical
Communications System (LDACS)", 2018 IEEE/AIAA 37th Communications System (LDACS)", 2018 IEEE/AIAA 37th
Digital Avionics Systems Conference (DASC), pp. 1-10, Digital Avionics Systems Conference (DASC), pp. 1-10,
skipping to change at line 2982 skipping to change at line 2982
Mallory Knodel, Ron Bonica, Ketan Talaulikar, Éric Vyncke, and Carlos Mallory Knodel, Ron Bonica, Ketan Talaulikar, Éric Vyncke, and Carlos
J. Bernardos. J. Bernardos.
Contributors Contributors
This document aggregates articles from authors specialized in each This document aggregates articles from authors specialized in each
technology. Beyond the main authors listed on the front page, the technology. Beyond the main authors listed on the front page, the
following contributors proposed additional text and refinements that following contributors proposed additional text and refinements that
improved the document. improved the document.
* Georgios Z. Papadopoulos contributed to the TSCH section. * Georgios Z. Papadopoulos contributed to Section 5 ("IEEE 802.15.4
Time-Slotted Channel Hopping (TSCH)").
* Nils Maeurer and Thomas Graeupl contributed to the LDACS section. * 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 the * Torsten Dudda, Alexey Shapin, and Sara Sandberg contributed to
5G section. Section 6 ("5G").
* Rocco Di Taranto contributed to the Wi-Fi section. * Rocco Di Taranto contributed to Section 4 ("IEEE 802.11").
* Rute Sofia contributed to the Introduction and Terminology * Rute Sofia contributed to Section 1 ("Introduction") and Section 2
sections. ("Terminology").
Authors' Addresses Authors' Addresses
Pascal Thubert (editor) Pascal Thubert (editor)
Independent
06330 Roquefort-les-Pins 06330 Roquefort-les-Pins
France France
Email: pascal.thubert@gmail.com Email: pascal.thubert@gmail.com
Dave Cavalcanti Dave Cavalcanti
Intel Corporation Intel Corporation
2111 NE 25th Ave 2111 NE 25th Ave
Hillsboro, OR 97124 Hillsboro, OR 97124
United States of America United States of America
Phone: 503 712 5566 Phone: 503 712 5566
 End of changes. 21 change blocks. 
49 lines changed or deleted 52 lines changed or added

This html diff was produced by rfcdiff 1.48.