RFC 9913
Reliable and Available Wireless (RAW) Technologies
RFC 9913 ๐ Reliable and Available Wireless (RAW) Technologies
Okay bestie, this is RFC 9913 ๐ฆ Its title is Reliable and Available Wireless (RAW) Technologies, and it's Informational, so it's not a Standards Track spec. It's dated April 2026 and sits in ISSN 2070-1721.
The authors are P. Thubert, Ed. (Independent), D. Cavalcanti (Intel), X. Vilajosana (Universitat Oberta de Catalunya), C. Schmitt (Research Institute CODE, UniBw M), and J. Farkas (Ericsson). โจ
The title block doesn't list anything it obsoletes or updates, so this doc stands on its own ๐
Abstract ๐ธ
Okay so this doc is a survey of the short- and middle-range radio techs that could support DetNet, and more specifically the RAW service ๐ง It also covers the characteristics RAW could take advantage of, and checks how well each tech could carry deterministic flows as of the time it was published.
The techs it studies are Wi-Fi 6/7, Time-Slotted Channel Hopping (TSCH), 3GPP 5G, and L-band Digital Aeronautical Communications System (LDACS) ๐
Status of This Memo ๐
It's not an Internet Standards Track spec. It's published just for information, bestie ๐
This doc is a product of the IETF and reflects the consensus of the IETF community. It went through public review and got approved for publication by the IESG. Not every IESG-approved doc is a candidate for any level of Internet Standard, so check out Section 2 of RFC 7841 for the deets ๐ฅ
For the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9913 ๐
Copyright Notice ยฉ๏ธ
This is the legal bit, but it still matters ๐
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.The doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read them, because they explain your rights and restrictions for this doc ๐
Any Code Components pulled out of this doc must include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions. They're provided without warranty, as the Revised BSD License describes ๐ซถ
Table of Contents ๐บ๏ธ
1. Introduction
2. Terminology
3. Towards Reliable and Available Wireless Networks
3.1. Scheduling for Reliability
3.2. Diversity for Availability
3.3. Benefits of Scheduling
4. IEEE 802.11 Wireless Local Area Networks (WLAN)
4.1. Provenance and Documents
4.2. 802.11ax High Efficiency (HE)
4.2.1. General Characteristics
4.2.2. Applicability to Deterministic Flows
4.3. 802.11be Extreme High Throughput (EHT)
4.3.1. General Characteristics
4.3.2. Applicability to Deterministic Flows
4.4. 802.11ad and 802.11ay (mmWave Operation)
4.4.1. General Characteristics
4.4.2. Applicability to Deterministic Flows
5. IEEE 802.15.4 Time-Slotted Channel Hopping (TSCH)
5.1. Provenance and Documents
5.2. General Characteristics
5.2.1. 6TiSCH Tracks
5.3. Applicability to Deterministic Flows
5.3.1. Centralized Path Computation
6. 5G
6.1. Provenance and Documents
6.2. General Characteristics
6.3. Deployment and Spectrum
6.4. Applicability to Deterministic Flows
6.4.1. System Architecture
6.4.2. Overview of the Radio Protocol Stack
6.4.3. Radio (PHY)
6.4.4. Scheduling and QoS (MAC)
6.4.5. Time-Sensitive Communications (TSC)
7. L-Band Digital Aeronautical Communications System (LDACS)
7.1. Provenance and Documents
7.2. General Characteristics
7.3. Deployment and Spectrum
7.4. Applicability to Deterministic Flows
7.4.1. System Architecture
7.4.2. Overview of the Radio Protocol Stack
7.4.3. Radio (PHY)
7.4.4. Scheduling, Frame Structure, and QoS (MAC)
8. IANA Considerations
9. Security Considerations
10. References
10.1. Normative References
10.2. Informative References
Acknowledgments
Contributors
Authors' Addresses1. Introduction โจ
Deterministic Networking (DetNet) [RFC8557] is the capability that carries specified unicast or multicast data flows for real-time apps, with extremely low data loss and bounded latency inside a network domain ๐ Techniques it might use include (1) reserving data plane resources for individual (or aggregated) DetNet flows on some or all intermediate nodes along the flow's path, (2) providing explicit routes for DetNet flows that don't immediately change when the network topology does, and (3) spreading the data from DetNet flow packets over time and/or space (like different frequencies or non-shared risk links) so every packet still gets delivered even when a path is unavailable ๐ฆ
DetNet works at the IP layer, and it usually runs over wired lower-layer techs like Time-Sensitive Networking (TSN), as defined by IEEE 802.1 and IEEE 802.3 ๐
The Reliable and Available Wireless (RAW) architecture [RFC9912] extends the DetNet architecture [RFC8655] to handle the specific challenges of wireless, especially intermittently lossy connectivity. It does this by optimizing the use of diversity and multipathing ๐ [RFC9912] defines the concepts of reliability and availability used in this doc. This doc then presents wireless techs with capabilities like time synchronization and transmission scheduling, which would make RAW operations possible over that medium ๐ง The techs studied here were identified in the charter during the formation of the RAW Working Group (WG), and were inherited by DetNet when the WG picked up the RAW work โญ
Making wireless reliable and available is even harder than it is with wires ๐ญ That's because there are lots of causes of radio transmission loss, and they pile up on top of congestion losses and the delays from overbooked shared resources.
RAW, like DetNet, needs and uses lower-layer stuff like time synchronization and traffic shapers. To balance out the bad effects of radio transmission losses, RAW also uses extra lower-layer capabilities, some of which might be specific to wireless or at least more typically applied there. Those lower-layer techniques include:
- per-hop retransmissions (also known as Automatic Repeat Request (ARQ)),
- variation of the Modulation and Coding Scheme (MCS),
- short-range broadcast,
- Multi-User - Multiple Input Multiple Output (MU-MIMO),
- constructive interference, and
- overhearing, whereby multiple receivers are scheduled to receive the same transmission, which saves energy on the sender and spectrum too ๐
These capabilities might be offered by the lower layer and controlled by RAW, separately or combined ๐
RAW defines a network-layer control loop that optimizes the use of links with constrained spectrum and energy, while keeping the expected connectivity properties (typically reliability and latency) ๐ฅ The loop involves communication monitoring through Operations, Administration, and Maintenance (OAM). It also involves path control through a Path Computation Element (PCE) and a runtime distributed Path Selection Engine (PSE), plus extended Packet Replication, Elimination, and Ordering Functions (PREOF) ๐ง
This doc surveys the short- and middle-range radio techs that could support a RAW service, presents the characteristics RAW can leverage, and explores how those techs could carry deterministic flows ๐ The studied techs are Wi-Fi 6/7, Time-Slotted Channel Hopping (TSCH), 3GPP 5G, and L-band Digital Aeronautical Communications System (LDACS). The goal is to support and enable work on these techs (and possibly other similar compatible ones) at the IETF, specifically in the DetNet WG working on RAW ๐
Last but not least, this doc only surveys existing networking tech. It doesn't define protocol behaviors or operational practices ๐ The IETF specs it references each have their own security considerations, and lower-layer techs provide their own security at Layer 2. A security study of these techs is explicitly not in scope ๐
2. Terminology ๐
This doc uses the terminology and acronyms defined in Section 2 of [RFC8655] and Section 3 of [RFC9912] ๐ซถ
3. Towards Reliable and Available Wireless Networks ๐
3.1. Scheduling for Reliability โฐ
A packet network is reliable for critical (e.g., time-sensitive) packets once the undesirable statistical effects hitting those packets (like delay or loss) are eliminated ๐
The reliability of a deterministic network [RFC8655] often depends on precisely applying a tight schedule. That schedule controls the use of time-shared resources like CPUs and buffers, and keeps the number of critical packets within the available resources of the communication hardware (e.g., buffers) and the transmission medium (e.g., bandwidth, transmission slots) at all times ๐ง The schedule can also shape flows by controlling the transmission time of the packets that make up the flow at every hop โจ
To pull this off, there must be a shared sense of time throughout the network ๐ฐ๏ธ That sense of time is usually provided by the lower layer and is not in scope for RAW. For example, the Precision Time Protocol (PTP), standardized as IEEE 1588 and IEC 61588, maps through profiles to Ethernet, industrial and SmartGrid protocols, and Wi-Fi with IEEE Std 802.1AS ๐
3.2. Diversity for Availability ๐ฆ
Equipment (e.g., node) failure can cause multiple packets to be lost in a row before the flows get rerouted or the system recovers ๐ฑ Examples include a broken switch, an access point rebooting, a broken wire or radio adapter, or a fixed obstacle in the way of the transmission ๐ง
Equipment failure is not acceptable for critical apps like safety ones ๐จ A typical process control loop can tolerate an occasional packet loss, but losing several packets in a row will cause an emergency stop ๐ Amusement rides are a fun example too: at places like Disneyland, Universal Studios, or MGM Studios parks, a continuous loss of packets for a few 100 ms may trigger an automatic interruption of the ride, and the attraction floor gets evacuated so it can restart ๐ข
Network availability comes from making transmission resilient against hardware failures and against radio transmission losses caused by uncontrolled events, like co-channel interferers, multipath fading, or moving obstacles ๐ช๏ธ The best results are usually achieved by pseudorandomly stacking all forms of diversity: in the spatial domain with replication and elimination, in the time domain with ARQ and diverse scheduled transmissions, and in the frequency domain with frequency hopping or channel hopping between frames ๐ธ
3.3. Benefits of Scheduling โจ
okay bestie, so scheduling redundant transmissions of the critical packets on diverse paths makes things way more resilient against breakages and statistical transmission loss ๐ก๏ธ. That includes the stuff like cosmic particles on wires and interference on wireless ๐ก. Transmission losses are orders of magnitude more frequent on wireless, but redundancy and diversity are needed in all cases for life- and mission-critical applications ๐ no cap.
When it's required, the worst-case time of delivery can be guaranteed as part of the end-to-end schedule โฐ. The sense of time that has to be shared across the whole network can also be exposed to and leveraged by other applications ๐ซถ.
Scheduling also gives you some specific perks over the wireless medium ๐ :
- Scheduling allows a time-sharing operation, where every transmission is assigned its own time/frequency resource ๐ฆ. The sender and receiver are synchronized and scheduled to talk on a given frequency resource at a given time and for a given duration. This way, scheduling can avoid collisions between scheduled transmissions and enable a high ratio of critical traffic (think 60% or 70% of high-priority traffic with ultra low loss) compared to statistical priority-based schemes ๐.
- Scheduling can be used as a technique for both time and frequency diversity (e.g., between transmission retries) ๐, allowing the next transmission to happen on a different frequency as programmed in both the sender and the receiver. This is useful to defeat co-channel interference from uncontrolled transmitters as well as multipath fading ๐ฅ.
- Transmissions can also be scheduled on multiple channels in parallel ๐ง, which enables the use of the full available spectrum while avoiding the hidden terminal problem. For example, that happens when the next packet in the same flow interferes on the same channel with the previous one that progressed a few hops farther ๐.
- Scheduling optimizes the bandwidth usage ๐. Compared to classical collision avoidance techniques, there is no blank time related to Interframe Space (IFS) and exponential back-off in scheduled operations. A minimal clear channel assessment may be needed to comply with local regulations such as ETSI 300-328, but that won't detect a collision when the senders are synchronized โจ.
- Scheduling plays a critical role in saving energy ๐. In the Internet of Things (IoT), energy is the foremost concern, and synchronizing the sender and listener means they can always be kept in deep sleep when there is no scheduled transmission ๐ด. This avoids idle listening and long preambles, and it enables long sleep periods between traffic and resynchronization. That lets battery-operated nodes operate in a mesh topology for multiple years ๐.
4. IEEE 802.11 Wireless Local Area Networks (WLAN) โจ
In recent years, the evolution of the IEEE Std 802.11 standard has taken a new direction ๐ธ. It's emphasizing improved reliability and reduced latency in addition to minor improvements in speed, all so it can unlock new fields of application such as industrial IoT and Virtual Reality (VR) ๐ฅฝ.
Leveraging IEEE Std 802.11, the Wi-Fi Alliance [WFA] delivered Wi-Fi 6, 7, and now 8 ๐ถ, with more capabilities to schedule and deliver frames in due time at fast rates. Still, as with any radio technology, Wi-Fi is sensitive to frame loss ๐ญ. That can only be combated with the maximum use of diversity in space, time, channel, and even technology.
In parallel, the Avnu Alliance [Avnu], which focuses on applications of TSN for real-time data, formed a workgroup to investigate TSN capabilities over wireless ๐. It's leveraging both 3GPP and IEEE Std 802.11 standards.
To achieve the latter, the reliability must be handled at an upper layer that can select Wi-Fi and other wired or wireless technologies for parallel transmissions ๐ง . This is where RAW comes into play ๐.
This section surveys the IEEE 802.11 features that are most relevant to RAW ๐. There are a great many more in the specification, and some of them may also possibly be of interest for a RAW solution. For instance, frame fragmentation reduces the impact of a very transient transmission loss, both on latency and energy consumption ๐.
4.1. Provenance and Documents ๐
The IEEE 802 LAN/MAN Standards Committee (SC) develops and maintains networking standards and recommended practices for local, metropolitan, and other area networks. It does this using an open and accredited process, and it advocates them on a global basis ๐. The most widely used standards are for Ethernet, Bridging and Virtual Bridged LAN, Wireless LAN, Wireless Personal Area Network (PAN), Wireless MAN, Wireless Coexistence, Media Independent Handover Services, and Wireless Radio Access Network (RAN). An individual working group provides the focus for each area ๐ซถ.
The IEEE 802.11 Wireless LAN (WLAN) standards define the underlying Medium Access Control (MAC) and Physical (PHY) layers for the Wi-Fi technology ๐. Previous 802.11 generations, such as 802.11n and 802.11ac, focused mainly on improving peak throughput ๐. More recent generations are also considering other performance vectors, such as efficiency enhancements for dense environments in IEEE Std 802.11ax [IEEE802.11ax] (approved in 2021), and throughput, latency, and reliability enhancements in IEEE Std 802.11be [IEEE802.11be] (approved in 2024) ๐ฅ.
IEEE Std 802.11-2012 includes support for TSN time synchronization based on IEEE 802.1AS over the 802.11 Timing Measurement protocol โฑ๏ธ. IEEE Std 802.11-2016 additionally includes an extension to the 802.1AS operation over 802.11 for Fine Timing Measurement (FTM), as well as the Stream Reservation Protocol (IEEE 802.1Qat) ๐ . 802.11 WLANs can also be part of 802.1Q bridged networks, with enhancements enabled by the 802.11ak amendment retrofitted in IEEE Std 802.11-2020 ๐. Traffic classification based on 802.1Q VLAN tags is also supported in 802.11 ๐ท๏ธ. Other 802.1 TSN capabilities such as 802.1Qbv and 802.1CB, which are media agnostic, can already operate over 802.11 ๐ฆ. The IEEE Std 802.11ax-2021 (which has been incorporated into IEEE Std 802.11-2024) defines additional scheduling capabilities that can enhance the timeliness performance in the 802.11 MAC and achieve lower-bounded latency โก. IEEE 802.11be introduces features to enhance the support for 802.1 TSN capabilities, especially those related to worst-case latency, reliability, and availability ๐.
The IEEE 802.11 Working Group has been working in collaboration with the IEEE 802.1 Working Group for several years, extending some 802.1 features over 802.11 ๐ค. As with any wireless media, 802.11 imposes new constraints and restrictions on TSN-grade QoS. 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 is discussed in [Cavalcanti_2019] ๐.
The Wi-Fi Alliance is the worldwide network of companies that drives global Wi-Fi adoption and evolution through thought leadership, spectrum advocacy, and industry-wide collaboration ๐. The WFA work helps ensure that Wi-Fi devices and networks give users the interoperability, security, and reliability they've come to expect ๐.
The Avnu Alliance is also a global industry forum developing interoperability testing for TSN-capable devices across multiple media, including Ethernet, Wi-Fi, and 5G ๐ก.
The following IEEE Std 802.11 specifications/certifications [IEEE802.11] are relevant in the context of reliable and available wireless services and support for TSN capabilities ๐ฏ:
- Time synchronization: IEEE Std 802.11-2016 with IEEE Std 802.1AS; WFA TimeSync Certification
- Congestion control: IEEE Std 802.11-2016 Admission Control; WFA Admission Control
- Security: WFA Wi-Fi Protected Access, WPA2, and WPA3 ๐
- Interoperating with IEEE 802.1Q bridges: IEEE Std 802.11-2020 incorporating 802.11ak
- Stream Reservation Protocol (part of [IEEE802.1Qat]): IEEE802.11-2016
- Scheduled channel access: IEEE 802.11ad enhancements for very high throughput in the 60 GHz band [IEEE802.11ad] ๐ซ
- 802.11 Real-Time Applications: Topic Interest Group (TIG) ReportDoc [IEEE_doc_11-18-2009-06]
In addition, major amendments being developed by the IEEE 802.11 Working Group include capabilities that can be used as the basis for providing more reliable and predictable wireless connectivity and supporting time-sensitive applications ๐ง:
- [IEEE802.11ax]: Enhancements for High Efficiency (HE)
- [IEEE802.11be]: Extreme High Throughput (EHT)
- [IEEE802.11ay]: Enhanced throughput for operation in license-exempt bands above 45 GHz
The main 802.11ax, 802.11be, 802.11ad, and 802.11ay capabilities and their relevance to RAW are discussed in the remainder of this section ๐. As P802.11bn is still in early stages of development, its capabilities are not included in this document ๐.
4.2. 802.11ax High Efficiency (HE) ๐ฆ
4.2.1. General Characteristics
The next generation Wi-Fi (Wi-Fi 6) is based on the IEEE802.11ax amendment [IEEE802.11ax], which includes specific capabilities to increase efficiency and control and to reduce latency ๐ . Some of these features include higher-order 1024-QAM modulation, support for uplink (UL) Multi-User - Multiple Input Multiple Output (MU-MIMO), Orthogonal Frequency-Division Multiple Access (OFDMA), trigger-based access, and Target Wake Time (TWT) for enhanced power savings ๐.
The OFDMA mode and trigger-based access enable the Access Point (AP), after reserving the channel using the clear channel assessment procedure for a given duration, to schedule multi-user transmissions ๐๏ธ. This 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 ๐ป. It also includes support for operation in the new 6 GHz band, which has been open to unlicensed use by the Federal Communications Commission (FCC) and other regulatory agencies worldwide ๐.
4.2.1.1. Multi-User OFDMA and Trigger-Based Scheduled Access ๐
802.11ax introduced an OFDMA mode in which multiple users can be scheduled across the frequency domain ๐งฉ. In this mode, the Access Point (AP) can initiate multi-user UL transmissions in the same PHY Protocol Data Unit (PPDU) by sending a trigger frame ๐ฆ. This centralized scheduling capability gives the AP much more control of the channel in its Basic Service Set (BSS) ๐. It can remove contention between associated stations for UL transmissions, therefore reducing the randomness caused by access based on Carrier Sense Multiple Access (CSMA) between stations within the same BSS ๐.
The AP can also transmit simultaneously to multiple users in the downlink (DL) direction by using a DL MU OFDMA PPDU ๐ค. In order to initiate a contention-free Transmission Opportunity (TXOP) using the OFDMA mode, the AP still follows the typical listen-before-talk procedure to acquire the medium ๐ง. That ensures interoperability and compliance with unlicensed band access rules โ . However, 802.11ax also includes a Multi-User Enhanced Distributed Channel Access (MU-EDCA) capability, which allows the AP to get higher channel access priority than other devices in its BSS ๐.
4.2.1.2. Traffic Isolation via OFDMA Resource Management and Resource Unit Allocation
Okay so 802.11ax uses something called an OFDMA Resource Unit (RU) to hand out frequency chunks to different stations over time ๐ RUs let multiple stations transmit at the same time, starting and ending together โจ The trick is padding, where extra bits get sent at the same power level ๐ The current RU allocation algorithms give you traffic isolation per station ๐ฆ That doesn't do time-aware scheduling by itself, but it's a big deal for reliability because it isolates traffic on a shared medium ๐
4.2.1.3. Improved PHY Robustness
The 802.11ax PHY can run with a 0.8, 1.6, or 3.2 microsecond Guard Interval (GI) ๐ธ The bigger GI options protect better against multipath, which is expected to be a real challenge in industrial environments ๐ญ OFDMA also lets you use smaller RUs (e.g., 2 MHz), which helps cut noise power and boost Signal-to-Noise Ratio (SNR), so you get better Packet Error Rate (PER) performance ๐ซถ
802.11ax supports beamforming like 802.11ac does, but it adds UL MU-MIMO, which helps reliability a lot ๐ฅ UL MU-MIMO is also powered by the trigger-based access operation in 802.11ax ๐
4.2.1.4. Support for 6 GHz Band
The 802.11ax specification [IEEE802.11ax] supports operation in the 6 GHz band ๐ There's a ton of new spectrum, and no legacy 802.11 device (prior 802.11ax) can operate in this band, so 802.11ax running here can be even more efficient ๐ง
4.2.2. Applicability to Deterministic Flows
TSN capabilities, as defined by the IEEE 802.1 TSN standards, are the underlying mechanism for deterministic flows in a Local Area Network (LAN) ๐ The IEEE 802.11 Working Group added absolute time synchronization to extend the TSN 802.1AS protocol, so time-sensitive flows get precise time sync over 802.11 links โญ Since IEEE 802.11 and IEEE 802.1 TSN are both based on the IEEE 802 architecture, 802.11 devices can directly implement some TSN capabilities with no gateway/translation protocol needed ๐ Basic features needed for operation in an 802.1Q LAN are already enabled for 802.11 ๐ฆ Some TSN capabilities, like 802.1Qbv, can already work over the existing 802.11 MAC Service Access Point (SAP) [Sudhakaran2021] ๐ Implementation and experimental results of TSN capabilities (802.1AS, 802.1Qbv, and 802.1CB) extended over standard Ethernet and Wi-Fi devices are also described in [Fang_2021] ๐ธ Still, the IEEE 802.11 MAC/PHY could be extended to improve how IEEE 802.1 TSN features operate and reach better performance metrics [Cavalcanti1287] ๐ญ
TSN capabilities supported over 802.11 (which also extends to 802.11ax) include:
- 802.1AS-based time synchronization (other time synchronization techniques may also be used)
- Interoperating with IEEE 802.1Q bridges
- Time-sensitive traffic stream classification
The existing 802.11 TSN capabilities above, plus the 802.11ax OFDMA and AP-controlled access within a BSS, give us a brand new toolkit for time-sensitive flows ๐งฐโจ But it's important to understand the trade-offs and constraints that come with these capabilities, plus the redundancy and diversity mechanisms that can deliver more predictable and reliable performance ๐ซถ
4.2.2.1. 802.11 Managed Network Operation and Admission Control
Time-sensitive applications and TSN standards are expected to run in a managed network (e.g., an industrial/enterprise network) ๐ผ That lets you carefully manage and integrate Wi-Fi operation with the overall TSN management framework, as defined in [IEEE802.1Qcc] ๐
Some of the random-access latency and interference from legacy/unmanaged devices can be reduced under a centralized management mode, as defined in [IEEE802.1Qcc] ๐
The existing traffic stream identification, configuration, and admission control procedures in the QoS mechanism of [IEEE802.11] can be reused ๐ However, because many time-sensitive applications need a very high degree of determinism, extra capabilities to manage interference and legacy devices within tight time constraints still need to be explored ๐ค
4.2.2.2. Scheduling for Bounded Latency and Diversity
As discussed earlier, the OFDMA mode in [IEEE802.11ax] makes it possible to assign different RUs (time/frequency resources) to users within a PPDU ๐ The specification defines several RU sizes (26, 52, 106, 242, 484, and 996 subcarriers) ๐ The AP can also decide on a Modulation and Coding Scheme (MCS) and the grouping of users within a given OFMDA PPDU ๐ That flexibility can be used to support time-sensitive applications with bounded latency, especially:
- in a managed network where stations can be configured to operate under the control of the AP,
- in a controlled environment (which contains only devices operating on the unlicensed band installed by the facility owner and where unexpected interference from other systems and/or radio access technologies only sporadically happens), or
- in a deployment where channel and link redundancy is used to reduce the impact of unmanaged devices and interference.
When the network is lightly loaded, latencies under 1 ms are possible when Wi-Fi runs in a contention-based mode (i.e., without OFDMA) โก It has also been shown that 1 ms latencies are achievable in a controlled environment with higher efficiency when multi-user transmissions are used (enabled by OFDMA operation) [Cavalcanti_2019] ๐ฆ Obviously, there are latency, reliability, and capacity trade-offs to weigh ๐ For instance, smaller RUs mean longer transmission durations, which may affect the minimal latency you can reach. But contention latency and randomness elimination in an interference-free environment thanks to multi-user transmission is a major benefit of the OFDMA mode ๐ง
The flexibility to dynamically assign RUs to each transmission also lets the AP provide frequency diversity, which can help boost reliability ๐
4.3. 802.11be Extreme High Throughput (EHT)
4.3.1. General Characteristics
[IEEE802.11be] was the next major 802.11 amendment (after IEEE Std 802.11ax-2021) for operation in the 2.4, 5, and 6 GHz bands ๐ 802.11be adds new PHY and MAC features, and it targets extremely high throughput (at least 30 Gbps) ๐ It also aims to improve worst-case latency and jitter ๐ณ It's also expected to improve integration with 802.1 TSN so time-sensitive applications can run over Ethernet and Wireless LANs ๐
The main 802.11be features relevant to this document include:
- 320 MHz bandwidth and more efficient utilization of non-contiguous spectrum
- Multi-Link Operation (MLO)
- QoS enhancements to reduce latency and increase reliability
4.3.2. Applicability to Deterministic Flows
The 802.11 Real-Time Applications (RTA) Topic Interest Group (TIG) shared detailed info on use cases, issues, and potential solutions for better time-sensitive application support in 802.11 ๐ The RTA TIG report [IEEE_doc_11-18-2009-06] was used as input to the 802.11be project scope ๐ซถ
Improvements for worst-case latency, jitter, and reliability were the main topics in the RTA report, motivated by applications in gaming, industrial automation, robotics, etc. ๐ค The RTA report also highlighted the need to support additional TSN capabilities, like time-aware (802.1Qbv) shaping and packet replication and elimination as defined in 802.1CB ๐ฎ
IEEE Std 802.11be builds on and enhances 802.11ax capabilities to improve worst-case latency and jitter ๐ช Some of the enhancement areas are discussed next โจ
4.3.2.1. Enhanced Scheduled Operation for Bounded Latency
In addition to the throughput enhancements, 802.11be uses the trigger-based scheduled operation enabled by 802.11ax to provide efficient and more predictable medium access ๐ฏ
802.11be introduced QoS signaling enhancements, such as an additional QoS characteristics element, that lets stations give the AP detailed info about deterministic traffic streams ๐จ That helps AP implementations do a better job scheduling deterministic flows ๐
4.3.2.2. Multi-Link Operation
802.11be introduces new features to improve operation over multiple links and channels ๐ฃ๏ธ By leveraging multiple links and channels, 802.11be can isolate time-sensitive traffic from network congestion, which is one of the main causes of large latency variations ๐ โโ๏ธ In a managed 802.11be network, it should be possible to steer traffic to certain links and channels to isolate time-sensitive traffic from other traffic and help achieve bounded latency ๐ The Multi-Link Operation (MLO) is a major 802.11be feature that can enhance latency and reliability by letting data frames be duplicated across links ๐ฏโโ๏ธ
4.4. 802.11ad and 802.11ay (mmWave Operation)
4.4.1. General Characteristics
The IEEE 802.11ad amendment defines PHY and MAC capabilities for multi-Gbps throughput in the 60 GHz millimeter wave (mmWave) band ๐ The standard tackles the rough mmWave signal propagation and provides directional communication capabilities that use beamforming to cope with increased attenuation ๐ก An overview of 802.11ad can be found in [Nitsche_2015] ๐
IEEE 802.11ay is currently developing enhancements to 802.11ad to enable next-generation mmWave operation targeting 100 Gbps throughput ๐ Some of the main 802.11ay enhancements include MIMO, channel bonding, improved channel access, and beamforming training ๐ซ An overview of the 802.11ay capabilities can be found in [Ghasempour_2017] ๐ฆ
4.4.2. Applicability to Deterministic Flows
The high data rates of 802.11ad and 802.11ay can cut latency down to microsecond levels, which is so good ๐ Limited interference from legacy and other unlicensed devices in 60 GHz is also a perk ๐ However, the directionality and short range typical of mmWave operation bring new challenges, like the overhead needed for beam training and blockage issues, which affect both latency and reliability ๐ฌ So it's important to understand the use case and deployment conditions in order to properly apply and configure 802.11ad/ay networks for time-sensitive applications ๐ง
The 802.11ad standard includes a scheduled access mode in which the central controller, after contending for and reserving the channel for a dedicated period, can allocate contention-free service periods to stations ๐๏ธ This scheduling capability is also available in 802.11ay, and it's one of the mechanisms that can provide bounded latency to time-sensitive data flows in interference-free scenarios ๐ซง An analysis of the theoretical latency bounds achievable with 802.11ad service periods is provided in [Cavalcanti_2019] ๐
5. IEEE 802.15.4 Time-Slotted Channel Hopping (TSCH) โจ
okay bestie, IEEE Std 802.15.4 TSCH was literally the first IEEE radio spec aimed straight at industrial IoT ๐ญ๐ It became the base for two of the big industrial wireless process control standards, Wireless Highway Addressable Remote Transducer Protocol (HART) and ISA100.11a. iconic foundation, no cap ๐
The MAC/PHY standards handle the relatively slow rates used in process control (typically in the order of 4-5 per second) ๐ข but tbh the tech is not suited for the faster periods used in factory automation and motion control, which run at 1 to 10 ms โก it's giving "too quick for this one" ๐
5.1. Provenance and Documents
so the IEEE 802.15.4 Task Group has been driving the development of low-power, low-cost radio tech ๐๐ธ The IEEE 802.15.4 Physical (PHY) layer was designed for demanding low-power scenarios that use unlicensed bands, both the 2.4 GHz and sub-GHz Industrial, Scientific and Medical (ISM) bands ๐ก That meant the team had to think carefully about frame size, data rate, and bandwidth so they could get reduced collision probability, reduced packet error rate, and decent range with limited transmission power. main character engineering ๐ง
Some specifics: the PHY layer supports frames of up to 127 bytes ๐ฆ The Medium Access Control (MAC) sublayer overhead is in the order of 10-20 bytes, which leaves about 100 bytes for the upper layers ๐ IEEE 802.15.4 uses spread spectrum modulation, such as Direct Sequence Spread Spectrum (DSSS) ๐
The Time-Slotted Channel Hopping (TSCH) mode was added in the 2015 revision of the IEEE 802.15.4 standard [IEEE802.15.4] ๐ TSCH is aimed at the embedded and industrial world, where reliability, energy consumption, and cost are the things driving the whole application space ๐
Building on IEEE 802.15.4, TSN on low-power constrained wireless networks has been partially addressed by ISA100.11a [ISA100.11a] and WirelessHART [WirelessHART] ๐ฆ Both involve a central controller that computes redundant paths for industrial process control traffic over a TSCH mesh. ISA100.11a also introduces IPv6 capabilities [RFC8200], with a link-local address for the join process and a global unicast address for later exchanges. ngl though, the IPv6 traffic typically ends at a local application gateway, so the full power of IPv6 for end-to-end communication is not enabled ๐
At the IETF, the 6TiSCH Working Group [TiSCH] has enabled distributed routing and scheduling that exploit the deterministic access capabilities TSCH provides for IPv6 ๐ฅ The group designed the essential mechanisms, the 6TiSCH Operation (6top) sublayer and the Scheduling Functions (SFs), to enable management plane operation while making sure IPv6 is supported ๐ซถ
- The 6top Protocol (6P) is defined in [RFC8480] and provides a pairwise negotiation mechanism for control plane operation. It supports agreement on a schedule between neighbors, which is what makes distributed scheduling possible โจ
- 6P goes hand in hand with an SF, the policy that decides how to maintain cells and trigger 6P transactions. The Minimal Scheduling Function (MSF) [RFC9033] is the default SF defined by the 6TiSCH WG ๐
- With these mechanisms, 6TiSCH can establish Layer 2 links between neighboring nodes and support best-effort traffic. The Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550] provides the routing structure, letting 6TiSCH devices establish links with well-connected neighbors, which forms the acyclic network graphs ๐ธ
In 6TiSCH, a Track is the concept of a recovery graph in the RAW architecture applied to wireless ๐ฆ A Track can follow a simple sequence of relay nodes, or it can be structured as a more complex Destination-Oriented Directed Acyclic Graph (DODAG) to a unicast destination. Along a Track, 6TiSCH nodes reserve resources so packets get transmitted efficiently, while aiming to optimize properties like reliability and to keep jitter small or latency bounded โญ The Track structure enables Layer 2 forwarding schemes, which cuts the overhead of making routing decisions at Layer 3 ๐ง
The 6TiSCH architecture [RFC9030] identifies different models for scheduling resources along so-called Tracks (see Section 5.2.1), using the TSCH schedule structure ๐ however, the focus in 6TiSCH is on best-effort traffic, and the group was never chartered to produce standards work related to Tracks ๐
There are several works that can complement the overview in this document ๐ For example, [vilajosana21] gives a detailed description of the 6TiSCH protocols, how they link together, and how they integrate with other standards like RPL and 6Lo ๐
5.2. General Characteristics
okay the core trick in IEEE 802.15.4 is that TSCH splits time into multiple time slots that repeat over and over ๐ Each device has its own view of when it sends or receives and on which channel the transmission happens. That's the device's slotframe, where the channel and destination of a transmission are a function of time โฐ Put all the slotframes of all the devices together and you get a time/frequency matrix with at most one transmission in each cell (see more in Section 5.3.1.4) ๐งฉ
The IEEE 802.15.4 TSCH standard doesn't define any scheduling mechanism. It only provides the architecture, a slotted structure that a proper schedule can manage ๐๏ธ That schedule represents the possible communications of a node with its neighbors, and it's managed by a Scheduling Function such as the Minimal Scheduling Function (MSF) [RFC9033] ๐ In MSF, each cell is identified by its slotOffset and channelOffset coordinates. A cell's timeSlot offset tells you its position in time, relative to the beginning of the slotframe. A cell's channel offset is an index that maps to a frequency at each iteration of the slotframe ๐ Each packet exchanged between neighbors happens within one cell.
The size of a cell is one timeSlot duration, between 10 to 15 milliseconds โฑ๏ธ An Absolute Slot Number (ASN) indicates how many slots have elapsed since the network started, and it increments at every slot. It's a 5-byte counter that can support networks running for more than 300 years without wrapping (assuming a 10 ms timeSlot) ๐คฏ๐ Channel hopping gives increased reliability against multipath fading and external interference ๐ฆ TSCH handles this through a channel-hopping sequence referred to as macHopSeq in the IEEE 802.15.4 specification ๐ธ
The Time-Frequency Division Multiple Access provided by TSCH lets you orchestrate traffic flows by spreading them in time and frequency, which makes bandwidth utilization way more efficient ๐ That efficiency can be combined with OFDM modulations, which IEEE 802.15.4 has also supported since the 2015 version [IEEE802.15.4] โจ
TSCH networks operate in ISM bands, where the spectrum is shared by different coexisting technologies ๐ป Regulators such as the FCC, ETSI, and ARIB impose duty cycle regulations to limit band use, but interference can still hurt the probability of delivering a packet ๐ฌ Some of these reliability challenges get handled at the MAC layer by adding redundancy and diversity, through channel hopping, scheduling, and ARQ policies ๐ซถ Yet the MAC layer only has a 1-hop view, so it's limited to local actions for fixing underperforming links ๐ฅบ
5.2.1. 6TiSCH Tracks โจ
okay so, 6TiSCH tracks are the bestie of deterministic networking ๐ฆ In the 6TiSCH architecture [RFC9030], a Track is basically the DetNet architecture's protection path, but applied to 6TiSCH networks. A Track can be structured as a Destination-Oriented Directed Acyclic Graph (DODAG) pointing at a destination for unicast traffic ๐ธ Along a Track, 6TiSCH nodes reserve resources so packets get transmitted efficiently, while aiming to optimize things like reliability and keep jitter small or latency bounded ๐ The Track structure lets Layer 2 forwarding happen, which means less overhead from making routing decisions at Layer 3. iconic, honestly ๐
Serial Tracks are the concatenation of cells or bundles along a routing path from a source to a destination ๐ง The serial Track idea is like the circuit concept, where resources are chained into a multi-hop topology. See Section 5.2.1.2 for how that gets used in the data plane to forward packets ๐
Scheduling makes sure delivery is reliable and happens in bounded time along any Track, but high availability needs PREOF functions applied along a more complex DODAG Track structure ๐ฅ A DODAG has forking and joining nodes, and that's where replication and elimination can be exploited. Spatial redundancy does increase the overall energy consumption of the network, but it significantly improves network availability and the packet delivery ratio, so it's a whole vibe ๐ A Track may also branch off and rejoin for so-called Packet Replication and Elimination (PRE), over non-congruent branches ๐ฆ PRE may be used to complement Layer 2 ARQ and receiver-end ordering to complete or extend the PREOF functions ๐ญ This is how industrial expectations of packet delivery within bounded delay get met over a Track that includes wireless links, even when the Track extends beyond the 6TiSCH network ๐
The RAW recovery graph described in the RAW architecture [RFC9912] inherits directly from that model ๐ RAW extends the graph beyond a DODAG, as long as a given packet cannot loop within the Track โจ
Figure 1 below is the picture, and it's giving main character energy ๐
+-----+
| IoT |
| G/W |
+-----+
^ <---- Elimination
| |
Track branch | |
+-------+ +--------+ Subnet backbone
| |
+--|--+ +--|--+
| | | Backbone | | | Backbone
o | | | router | | | router
+--/--+ +--|--+
o / o o---o----/ o
o o---o--/ o o o o o
o \ / o o LLN o
o v <---- Replication
o
Figure 1: End-to-End Deterministic TrackIn Figure 1, a Track runs from a field device in a 6TiSCH network to an IoT gateway that sits on an IEEE 802.1 TSN backbone ๐
The Replication function in the field device sends a copy of each packet over two different branches, and a PCE schedules each hop of both branches so the two copies arrive on time at the gateway ๐ซถ If there's a loss on one branch, hopefully the other copy still makes it in time. If two copies reach the IoT gateway, the Elimination function in the gateway ignores the extra packet and only hands one copy up to upper layers. no cap, that's clever ๐ง โจ
At each 6TiSCH hop along the Track, the PCE may schedule more than one timeSlot for a packet, so it can support Layer 2 retries (ARQ) ๐ It's also possible for the field device to only use the second branch if sending over the first branch fails ๐ธ
In current deployments, a TSCH Track doesn't necessarily support PRE, but it is systematically multipath ๐ฆ That means a Track is scheduled so each hop has at least two forwarding solutions, and the forwarding decision is to try the preferred one and use the other if Layer 2 transmission fails, as detected by ARQ ๐
Methods to implement complex Tracks are described in [RFC9914] and complemented by extensions to the RPL routing protocol in [NSA-EXT] for best-effort traffic ๐ง But a centralized routing technique, like the one promoted in DetNet, is still missing ๐ญ
5.2.1.1. Track Scheduling Protocol ๐
Section 4.4 of the 6TiSCH architecture [RFC9030] describes four approaches to manage the TSCH schedule of the Low-Power and Lossy Network (LLN) nodes: static scheduling, neighbor-to-neighbor scheduling, remote monitoring and scheduling management, and hop-by-hop scheduling ๐ The Track operation for DetNet corresponds to remote monitoring and scheduling management by a PCE โจ
5.2.1.2. Track Forwarding ๐ฆ
In the 6TiSCH architecture [RFC9030], forwarding is the per-packet operation that lets a packet get delivered to a next hop or an upper layer in a node ๐ Forwarding is based on preexisting state installed as a result of the routing computation of a Track by a PCE ๐ซถ The 6TiSCH architecture supports three forwarding models: GMPLS Track Forwarding (TF), 6LoWPAN Fragment Forwarding (FF), and IPv6 Forwarding (6F), which is the classical IP operation [RFC9030] ๐ The DetNet case relates to the Track Forwarding operation under the control of a PCE ๐
A Track is a unidirectional path between a source and a destination ๐ Time and frequency resources called cells (see Section 5.3.1.4) are allocated to enable the forwarding operation along the Track. In a Track cell, normal IEEE 802.15.4 ARQ usually happens, though the acknowledgment may be omitted in some cases, for instance, if there's no scheduled cell for a retry ๐ญ
Track Forwarding is the simplest and fastest operation โญ A bundle of cells set to receive (RX-cells) is uniquely paired to a bundle of cells set to transmit (TX-cells), which is a Layer 2 forwarding state that works regardless of the network-layer protocol ๐ This model can effectively be seen as a Generalized Multiprotocol Label Switching (GMPLS) operation, because the info used to switch a frame isn't an explicit label. It's related to other properties of how the packet was received (a particular cell, in the case of 6TiSCH) ๐ง So as long as the TSCH MAC (and Layer 2 security) accepts a frame, that frame can be switched no matter the protocol, whether it's an IPv6 packet, a 6LoWPAN fragment, or a frame from an alternate protocol like WirelessHART or ISA100.11a ๐
A data frame forwarded along a Track normally has a destination MAC address set to broadcast (or a multicast address, depending on MAC support) ๐ฆ This way, the MAC layer in intermediate nodes accepts the incoming frame, and 6top switches it without changing the MAC header ๐ธ With IEEE 802.15.4, this effectively means the address is broadcast, so the short address for the frame's destination is set to 0xFFFF along the Track โจ
A Track is formed end to end as a succession of paired bundles: a receive bundle from the previous hop and a transmit bundle to the next hop along the Track ๐ A cell in such a bundle belongs to one Track at most ๐ For a given iteration of the device schedule, the effective channel of the cell is obtained by adding a pseudorandom number to the channelOffset of the cell, which rotates the frequency used for transmission ๐ The bundles may be computed to accommodate both variable rates and retransmissions, so they might not be fully used at a given iteration of the schedule ๐ The 6TiSCH architecture provides additional means to avoid wasting cells and to avoid overflows in the transmit bundle, as described in the following paragraphs ๐ซถ
On one hand, a TX-cell that isn't needed for the current iteration may be reused opportunistically on a per-hop basis for routed packets ๐ When all the frames received for a given Track are effectively transmitted, any available TX-cell for that Track can be reused for upper-layer traffic whose next-hop router matches the next hop along the Track ๐ง In that case, the cell being used is effectively a TX-cell from the Track, but the short address for the destination is that of the next-hop router ๐ธ So a frame received in an RX-cell of a Track, with a destination MAC address set to this node instead of 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 so is never received at the 6top sublayer.) ๐
On the other hand, it might happen that there aren't enough TX-cells in the transmit bundle to accommodate the Track traffic, for instance, if more retransmissions are needed than were provisioned ๐ญ In that case, the frame can be placed for transmission in the bundle used for Layer 3 traffic towards the next hop along the Track, as long as it can be routed by the upper layer. Typically, that means the frame carries an IPv6 packet ๐ฆ The MAC address should be set to the next-hop MAC address to avoid confusion ๐ So a frame received over a Layer 3 bundle may actually be associated with a Track ๐ On a classical IP link like Ethernet, off-Track traffic is typically excess over the reservation, routed along the non-reserved path based on its QoS setting. But with 6TiSCH, since the Layer 3 bundle may be used because of transmission failures, it makes sense for the receiver to recognize a frame that should be re-Tracked and put it back on the appropriate bundle if possible ๐ A frame should be re-Tracked if the per-hop-behavior group indicated in the Differentiated Services field in the IPv6 header is set to deterministic forwarding, as discussed in Section 5.3.1.1 โจ A frame is re-Tracked by scheduling it for transmission over the transmit bundle associated with the Track, with the destination MAC address set to broadcast ๐
5.2.1.2.1. OAM ๐
"An Overview of Operations, Administration, and Maintenance (OAM) Tools" [RFC7276] provides an overview of the existing tooling for OAM [RFC6291] ๐ง Tracks are complex paths, and new tooling is necessary to manage them with respect to load control, timing, and the Packet Replication and Elimination Functions (PREF) ๐ญ
An example of such tooling can be found in the context of Bit Index Explicit Replication (BIER) [RFC8279] and, more specifically, BIER Traffic Engineering (BIER-TE) [RFC9262] ๐ฆ
5.3. Applicability to Deterministic Flows โจ
okay bestie, this is where we talk about where RAW actually fits ๐ฆ In the RAW context, low-power reliable networks should go after non-critical control scenarios like Class 2, plus monitoring scenarios like Class 4, as defined by [RFC5673]. These radio transducers are built for industrial vibes, so they run low data rates (typically somewhere between 50 kbps and 250 kbps) and use robust modulations that trade speed for reliability ๐ TSCH networks are organized as meshes and hooked up to a backbone. Latency in the mesh is mostly shaped by propagation stuff like interference. ARQ methods and redundancy techniques like replication and elimination should be studied so the performance is there for deterministic scenarios ๐ฅ
Nodes in a TSCH network are tightly synchronized โฐ That's what makes the slotted structure possible and keeps resources used efficiently, as long as the scheduling policies are on point. Scheduling is the key to orchestrating the resources that different nodes in a Track or a path are using. Slotframes can be split into resource blocks, which reserves the needed capacity for certain flows. Periodic and bursty traffic can be handled independently in the schedule, using active and reactive policies and taking advantage of overprovisioned cells. Along a Track (see Section 5.2.1), resource blocks can be chained so nodes in earlier hops send their data before the next packet arrives, which gives tight control of latency along the Track ๐ Collision loss is avoided for best-effort traffic by overprovisioning resources, which gives the management plane time to dedicate more resources if needed.
5.3.1. Centralized Path Computation ๐
When it comes to end-to-end communication over TSCH, a 6TiSCH device usually doesn't place a bandwidth request between itself and another device. Instead, an Operation Control System (OCS) invoked through a Human/Machine Interface (HMI) hands the traffic specification (in particular, the latency, reliability, and the end nodes) to a PCE. The PCE then computes a Track between the end nodes and provisions every hop in that Track with per-flow state. That state covers the per-hop operation for a given packet, the corresponding timeSlots, and the flow identification that tells which packet goes in which Track, sorts out duplicates, and so on. An example of an OCS and HMI is shown in Figure 2.
For a static configuration that serves one purpose for a long time, a node is expected to be provisioned in one shot with a full schedule that aggregates its behavior across multiple Tracks. The 6TiSCH architecture expects the schedule to be programmed over the Constrained Application Protocol (CoAP), as discussed in [CoAP-6TiSCH].
A Hybrid mode may be required too, where a single Track gets added, modified, or removed (for instance, if a Track isn't performing the way it should). For that case, the expectation is that a protocol flowing along a Track, kind of like classical Traffic Engineering (TE) [CCAMP], may be used to update the state in the devices. That flow wasn't designed for this job, so DetNet is expected to figure out which end-to-end protocols should be used in that case ๐ง
Operational Control System and HMI
-+-+-+-+-+-+-+ Northbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
PCE PCE PCE PCE
-+-+-+-+-+-+-+ Southbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
--- 6TiSCH------6TiSCH------6TiSCH------6TiSCH--
6TiSCH / Device Device Device Device \
Device- - 6TiSCH
\ 6TiSCH 6TiSCH 6TiSCH 6TiSCH / Device
----Device------Device------Device------Device--
Figure 2: Architectural Layers5.3.1.1. Packet Marking and Handling ๐ท๏ธ
Section 4.7.1 of [RFC9030] describes the packet tagging and marking that's expected in 6TiSCH networks ๐
5.3.1.1.1. Tagging Packets for Flow Identification ๐
Packets that a PCE routes along a Track get tagged so they uniquely identify the Track and its associated transmit bundle of timeSlots.
As a result, the tagging used for a DetNet flow outside the 6TiSCH Low-Power and Lossy Network (LLN) must be swapped into 6TiSCH formats and back again as the packet enters and then leaves the 6TiSCH network. Swap in, swap out, periodt ๐
5.3.1.1.2. Replication, Retries, and Elimination ๐ฆ
The 6TiSCH architecture [RFC9030] uses PREOF over several alternate paths in a network to provide redundancy and parallel transmissions that bound the end-to-end delay. Looking at the scenario in Figure 3, there are a lot of different paths S could take to reach R. A simple way to benefit from this topology is to use the two independent paths via nodes A, C, E and via B, D, F, but more complex paths are possible too.
(A) (C) (E)
source (S) (R) (destination)
(B) (D) (F)
Figure 3: A Typical Ladder Shape with Two Parallel Paths Toward
the DestinationWith a packet replication function, each node forwards a copy of each data packet over two different branches. For instance, in Figure 4 the source node S sends the data packet to nodes A and B, in two different timeSlots within the same TSCH slotframe. In that figure, S transmits the same data packet twice: once to its Destination Parent (DP) (A), and once to its Alternate Parent (AP) (B).
===> (A) => (C) => (E) ===
// \\// \\// \\
source (S) //\\ //\\ (R) (destination)
\\ // \\ // \\ //
===> (B) => (D) => (F) ===
Figure 4: Packet ReplicationWith a packet elimination function, once a node receives the first copy of a data packet, it discards the subsequent copies. Because the first copy that reaches a node is the one that matters, it's the only copy that gets forwarded upward ๐
The wireless medium is broadcast by nature, so any neighbor of a transmitter may overhear a transmission. With the promiscuous overhearing function, nodes get multiple chances to receive a given data packet. For instance, in Figure 4, when the source node S transmits the data packet to node A, node B may overhear that transmission ๐
6TiSCH expects elimination and replication of packets along a complex Track, but it takes no position on how the sequence numbers would be tagged in the packet ๐คทโโ๏ธ As it goes, 6TiSCH expects that timeSlots corresponding to copies of the same packet along a Track are correlated by configuration, so processing the sequence numbers is not needed.
The semantics of the configuration must let correlated timeSlots be grouped for transmit (and receive, respectively) with 'OR' relations, and then an 'AND' relation must be configurable between groups. The semantics are that if the transmit (or receive, respectively) operation succeeded in one timeSlot in an 'OR' group, then all the other timeSlots in that group are ignored. Now, if there are at least two groups, the 'AND' relation between the groups means one operation must succeed in each of the groups. Further details can be found in the 6TiSCH architecture document [RFC9030].
5.3.1.2. Topology and Capabilities ๐ธ
6TiSCH nodes are usually IoT devices, with a very limited amount of memory, just enough buffers to store one or a few IPv6 packets, and limited bandwidth between peers. So a node keeps only a small amount of peering information and can't store many packets waiting to be forwarded ๐ฅบ Peers can be identified through MAC or IPv6 addresses.
Neighbors can be discovered over the radio using mechanisms such as enhanced beacons. Even though the neighbor information is available in the 6TiSCH interface data model, 6TiSCH doesn't describe a protocol that proactively pushes neighborhood information to a PCE. That protocol should be described and should operate over CoAP. It should be able to carry multiple metrics, in particular the same metrics used for RPL operations [RFC6551].
The energy a device consumes in sleep, transmit, and receive modes can be evaluated and reported, and so can the amount of energy stored in the device and the power that can be scavenged from the environment โก The PCE should be able to compute Tracks that implement policies on how the energy is consumed, for instance policies that balance between nodes and make sure the spent energy doesn't exceed the scavenged energy over a period of time.
5.3.1.3. Schedule Management by a PCE ๐
6TiSCH supports a mixed model of centralized routes and distributed routes. Centralized routes can, for example, be computed by an entity such as a PCE [PCE]. Distributed routes are computed by RPL [RFC6550].
Both methods may inject routes into the routing tables of the 6TiSCH routers. In either case, each route is associated with a 6TiSCH topology that can be an RPL Instance topology or a Track. The 6TiSCH topology is indexed by an Instance ID, in a format that reuses the RPLInstanceID as defined in RPL.
Both RPL and PCE rely on shared sources, such as policies, to define Global and Local RPLInstanceIDs that can be used by either method. It's possible for centralized and distributed routing to share the same topology. Generally, they'll operate in different slotframes, and centralized routes will be used for scheduled traffic and will have precedence over distributed routes in case of conflict between the slotframes ๐งโโ๏ธ
5.3.1.4. Slotframes and Priorities โจ
okay bestie, so IEEE 802.15.4 TSCH avoids contention on the medium by slicing time and frequencies into transmission cells that all have the same duration ๐ To describe that layout, the 6TiSCH architecture defines a global concept called the Channel Distribution and Usage (CDU) matrix ๐ A CDU matrix is a grid of cells. Its height is the number of available channels (indexed by channelOffsets), and its width is the period of the network scheduling operation, measured in timeSlots (indexed by slotOffsets) ๐
The PCE uses the CDU matrix as the map of all channel utilization ๐บ๏ธ It's giving time-travel energy, because this organization depends on the time in the future. The frequency used by a cell rotates in a pseudorandom way, starting from an initial position at an epoch time, as the CDU matrix loops over and over and over ๐
A cell is one timeSlot long, and values of 10 to 15 milliseconds are typical in 802.15.4 TSCH ๐ธ That's enough room for a frame, an acknowledgement, and the security validation on the receive side, which can take up to a few milliseconds on some device architectures ๐ The matrix shows the overall use of the spectrum over time by a scheduled network operation. Literally the whole vibe ๐
A CDU matrix is computed by the PCE, but nodes can opportunistically use unallocated timeSlots for classic best-effort IP traffic โจ If there's a conflict, the PCE wins ๐ Multiple schedules can coexist. When that happens, the schedule adds another dimension to the matrix, and those dimensions are ordered by priority ๐ฆ
A slotframe is the base object a PCE needs to manipulate in order to program a schedule into one device ๐ง It's the device's view of a transmission schedule. There can be more than one, each with a different priority, so when there's contention, the highest priority applies ๐ In other words, a slotframe is the projection of a schedule from the CDU matrix onto one device. If you want more on that, Section 4.3.5 of [RFC9030] has the details, and Figures 17 and 18 of [RFC9030] show that projection visually ๐ iykyk, it's a whole mood ๐
6. 5G ๐ก
5G technology enables deterministic communication ๐ซ Based on centralized admission control and scheduling of the wireless resources, whether licensed or unlicensed, Quality of Service (QoS) such as latency and reliability can be guaranteed ๐ 5G has a bunch of features for ultra-reliable and low-latency performance (e.g., support for different OFDM numerologies and slot durations) ๐ Add in fast processing and redundancy techniques, and you get achievable latency numbers of below 1 ms with 99.999% or higher confidence ๐ญ So iconic.
5G also includes features for industrial IoT use cases, e.g., through the integration of 5G with TSN ๐ญ That covers 5G capabilities for each TSN component, plus latency, resource management, time synchronization, and reliability โฐ 5G support for TSN can also be leveraged when 5G is used as the subnet technology for DetNet, either in combination with or instead of TSN, which is the primary subnet for DetNet ๐ค Support for integration with TSN reliability was added to 5G by making DetNet reliability applicable too, because TSN and DetNet reliability have a lot in common ๐ซถ Providing IP service is native to 5G, and 3GPP Release 18 adds direct support for DetNet to 5G ๐
Overall, 5G provides scheduled wireless segments with high reliability and availability ๐ It also includes capabilities for integrating with IP networks, which makes 5G a suitable technology to apply RAW ๐ฆ
6.1. Provenance and Documents ๐
The 3rd Generation Partnership Project (3GPP) brings together lots of companies in cellular network operation, network equipment, and device manufacturing ๐ข All generations of 3GPP technologies provide scheduled wireless segments, mainly in licensed spectrum, which is great for reliability and availability ๐
In 2016, 3GPP started designing New Radio (NR), the technology belonging to the fifth generation (5G) of cellular networks ๐ NR was designed from the start to cover enhanced Mobile Broadband (eMBB) services for consumer devices like smartphones or tablets, and it's also tailored for future IoT communication and connected cyber-physical systems ๐ค On top of eMBB, requirement categories were defined for Massive Machine-Type Communication (M-MTC), meaning a large number of connected devices and sensors, and for Ultra-Reliable Low-Latency Communications (URLLC), meaning connected control systems and critical communication, as shown in Figure 5 ๐ฅ URLLC is the part that makes 5G a great candidate for reliable low-latency communication ๐ With these three cornerstones, NR is a complete solution for the connectivity needs of consumers, enterprises, and the public sector, for both wide-area and local-area (e.g., indoor) deployments ๐ A general overview of NR can be found in [TS38300].
enhanced
Mobile Broadband
^
/ \
/ \
/ \
/ \
/ 5G \
/ \
/ \
/ \
+-----------------+
Massive Ultra-Reliable
Machine-Type Low-Latency
Communication Communication
Figure 5: 5G Application AreasWhen the first NR specification was released in 2018 (Release 15), many companies proved that NR is a URLLC-capable technology that can deliver data packets at 10^-5 packet error rate within a 1 ms latency budget [TR37910] ๐คฏ Those evaluations were consolidated and forwarded to ITU to be included in the work on [IMT2020] ๐
To understand communication requirements for automation in vertical domains, 3GPP studied different use cases [TR22804] and released a technical specification with reliability, availability, and latency demands for a variety of applications [TS22104] ๐
As an evolution of NR, multiple studies focused on radio aspects were conducted in scope of 3GPP Release 16, including the following two:
- "Study on physical layer enhancements for NR ultra-reliable and low latency case (URLLC)" [TR38824] ๐ถ
- "Study on NR industrial Internet of Things (IoT)" [TR38825] ๐ญ
As a result of these studies, further NR enhancements were standardized in 3GPP Release 16 and are available in [TS38300], and they continued in 3GPP Release 17 standardization (according to [RP210854]) ๐
Several enhancements were also made at the system architecture level, reflected in "System architecture for the 5G System (5GS)" [TS23501] ๐งฉ These include multiple features supporting Time-Sensitive Communications (TSC) by Release 16 and Release 17. Further improvements, like support for DetNet [TR2370046], are provided in Release 18 โจ
The adoption and use of 5G is supported by multiple organizations ๐ For instance, the 5G Alliance for Connected Industries and Automation (5G-ACIA) brings together a super wide range of 5G stakeholders, including Information and Communication Technology (ICT) players and Operational Technology (OT) companies (e.g., industrial automation enterprises, machine builders, and end users) ๐ค Another example is the 5G Automotive Association (5GAA), which bridges ICT and automotive technology companies to develop end-to-end solutions for future mobility and transportation services ๐๐จ
6.2. General Characteristics โจ
okay so bestie, the 5G Radio Access Network (5G RAN) with its NR interface comes packed with features for Quality of Service (QoS) ๐ like a guaranteed low latency or tolerable packet error rates for selected data flows. ๐ The determinism is achieved by centralized admission control and scheduling of the wireless frequency resources, which are typically licensed frequency bands assigned to a network operator. It's giving organized, no cap ๐ซถ
NR enables short transmission slots in a radio subframe, which is so good for low-latency apps โก NR also brings in mini-slots, where prioritized transmissions can start without waiting for slot boundaries, so the latency drops even more ๐ฆ As part of giving URLLC traffic priority and faster radio access, NR introduces preemption, where URLLC data transmission can preempt ongoing non-URLLC transmissions. main character energy, fr fr ๐ Additionally, NR applies very fast processing, which means retransmissions can happen even within short latency bounds. ngl that's iconic ๐ญ
NR defines extra-robust transmission modes for increased reliability for both data and control radio channels. ๐ธ Reliability gets an extra boost from things like multi-antenna transmission, using multiple frequency carriers in parallel, and packet duplication over independent radio links. NR also provides full mobility support, which is a huge reliability aspect not only for devices that are moving, but also for devices sitting in a changing environment. ๐ง
Network slicing is seen as one of the key features for 5G, letting vertical industries take advantage of 5G networks and services. ๐ Basically, network slicing is about turning a Public Land Mobile Network (PLMN) from one single network into a network with logical partitions, each with appropriate network isolation, resources, optimized topology, and specific configurations for different service requirements. โจ An operator can configure and manage the mobile network to support the various types of services enabled by 5G (e.g., eMBB and URLLC), depending on what different customers need. it's giving custom-made ๐
Exposure of 5G system capabilities to the network or to applications outside the 3GPP domain has been added to Release 16 [TS23501]. ๐ Applications can access 5G capabilities like communication service monitoring and network maintenance via exposure interfaces. ๐
For several generations of mobile networks, 3GPP has looked at how the communication system should work on a global scale with billions of users, taking into account resilience, privacy regulation, data protection, encryption, access and core network security, as well as interconnect. ๐ฅ Security requirements keep evolving as demands on trustworthiness go up. For example, this led to enhanced privacy protection features in 5G. 5G also uses strong security algorithms, encrypts traffic, protects signaling, and protects interfaces. ๐
One particular strength of mobile networks is authentication, based on well-proven algorithms and tightly coupled with a global identity management infrastructure. ๐ Since 3G there has also been mutual authentication, so the network can authenticate the device and the device can authenticate the network. Another strength is secure solutions for storage and distribution of keys, which meet regulatory requirements and allow international roaming. ๐ When connecting to 5G, the user meets the entire communication system, where security is the result of standardization, product security, deployment, operations, and management, plus incident-handling capabilities. The mobile networks approach the whole thing in a rather coordinated fashion, which is super beneficial for security. ๐ซถ
6.3. Deployment and Spectrum ๐ฆ
The 5G system allows deployment across a vast spectrum range, addressing use cases in both wide-area and local-area networks. โจ Furthermore, 5G can be configured for public and non-public access. ๐
When it comes to spectrum, NR lets you combine the merits of many frequency bands, like the high bandwidths in millimeter waves (mmWaves) for extreme local capacity and the broad coverage of mid- and low-frequency bands for wide-area scenarios. ๐ธ URLLC is achievable in all of these bands. Spectrum can be either licensed, meaning the license holder is the only authorized user of that spectrum range, or unlicensed, meaning anyone who wants to use the spectrum can do so. ๐
A prerequisite for critical communication is performance predictability, which can be achieved by full control of access to the spectrum, and 5G provides exactly that. ๐ Licensed spectrum guarantees control over spectrum usage by the system, which makes it the preferable option for critical communication. ๐ฅ However, unlicensed spectrum can provide an additional resource for scaling non-critical communications. While NR was initially developed for licensed spectrum, the ability to access unlicensed spectrum was introduced in 3GPP Release 16. Moreover, URLLC features are enhanced in Release 17 [RP210854] to be better applicable to unlicensed spectrum. ๐ง
Licensed spectrum dedicated to mobile communications has been allocated to mobile service providers, i.e., issued as longer-term licenses by national administrations around the world. ๐ These licenses have often come with coverage requirements and were issued across whole countries or large regions. Besides this, when configured as a non-public network (NPN) deployment, 5G can also provide network services to a non-operator defined organization and its premises, such as a factory deployment. ๐ With this isolation, QoS requirements as well as security requirements can be achieved. An integration with a public network, if required, is also possible. The non-public (local) network can therefore be interconnected with a public network, allowing devices to roam between the networks. ๐ซถ
In an alternative model, some countries are now allocating parts of the 5G spectrum for local use by industries. ๐ธ These non-service providers then get to choose: apply for a local license themselves and operate their own network, or cooperate with a public network operator or service provider. โจ
6.4. Applicability to Deterministic Flows ๐
6.4.1. System Architecture ๐
The 5G system [TS23501] consists of the User Equipment (UE) on the terminal side, the Radio Access Network (RAN) with the gNodeB (gNB) as radio base station node, and the Core Network (CN), which connects to the external Data Network (DN). ๐ฆ The CN is based on a service-based architecture with these central functions: Access and Mobility Management Function (AMF), Session Management Function (SMF), and User Plane Function (UPF), as illustrated in Figure 6. (Note that this document only explains key functions; however, Figure 6 gives a more detailed view, and [SYSTOVER5G] summarizes the functions and provides the full definitions of the acronyms used in the figure.) ๐ง
The gNB's main job is radio resource management, including admission control and scheduling, mobility control, and radio measurement handling. ๐ The AMF handles the UE's connection status and security, while the SMF controls the UE's data sessions. And the UPF handles the user plane traffic. ๐
The SMF can instantiate various Packet Data Unit (PDU) sessions for the UE, each associated with a set of QoS flows, i.e., with different QoS profiles). ๐ Segregation of those sessions is also possible; for example, resource isolation in the RAN and CN can be defined (slicing). โจ
+----+ +---+ +---+ +---+ +---+ +---+
|NSSF| |NEF| |NRF| |PCF| |UDM| |AF |
+--+-+ +-+-+ +-+-+ +-+-+ +-+-+ +-+-+
| | | | | |
Nnssf| Nnef| Nnrf| Npcf| Nudm| Naf|
| | | | | |
---+------+-+-----+-+------------+--+-----+-+---
| | | |
Nausf| Nausf| Nsmf| |
| | | |
+--+-+ +-+-+ +-+-+ +-+-+
|AUSF| |AMF| |SMF| |SCP|
+----+ +++-+ +-+-+ +---+
/ | |
/ | |
/ | |
N1 N2 N4
/ | |
/ | |
/ | |
+--+-+ +--+--+ +--+---+ +----+
| UE +---+(R)AN+--N3--+ UPF +--N6--+ DN |
+----+ +-----+ ++----++ +----+
| |
+-N9-+
Figure 6: 5G System Architecture๐ธ To allow UE mobility across cells/gNBs, handover mechanisms are supported in NR. For an established connection (i.e., connected mode mobility), a gNB can configure a UE to report measurements of received signal strength and quality of its own and neighboring cells, either periodically or based on events. ๐ Based on these measurement reports, the gNB decides to hand over a UE to another target cell/gNB. Before triggering the handover, it does a handshake with the target gNB via network signaling. A handover command is then sent to the UE, and the UE switches its connection to the target cell/gNB. ๐ฆ The Packet Data Convergence Protocol (PDCP) of the UE can be configured to avoid data loss during this procedure, i.e., to handle retransmissions if needed. Data forwarding is possible between source and target gNB as well. ๐ซถ
To improve mobility performance further (i.e., to avoid connection failures due to too-late handovers), the mechanism of conditional handover was introduced in Release 16 specifications. โจ Therein, a conditional handover command, defining a triggering point, can be sent to the UE before the UE enters a handover situation. ๐ A further improvement introduced in Release 16 is the Dual Active Protocol Stack (DAPS), where the UE keeps its connection to the source cell while connecting to the target cell. ๐ This way, potential interruptions in packet delivery can be avoided entirely. it's literally so smart ๐ง๐
6.4.2. Overview of the Radio Protocol Stack โจ
okay so the NR protocol stack is basically a layer cake ๐. At the bottom is Layer 1, the Physical (PHY) layer. Then, as part of Layer 2, you get the sublayers of Medium Access Control (MAC), Radio Link Control (RLC), Packet Data Convergence Protocol (PDCP), and Service Data Adaption Protocol (SDAP) ๐ .
The PHY layer is the signal-processing queen ๐. It handles encoding and decoding of data and control bits, modulation, antenna precoding, and mapping.
The MAC sublayer handles multiplexing and priority handling of logical channels (associated with QoS flows) into transport blocks for PHY transmission. It also takes care of scheduling information reporting and error correction through Hybrid Automated Repeat Request (HARQ) ๐.
RLC is giving sequence numbering for higher-layer packets ๐ข. It does retransmissions through Automated Repeat Request (ARQ), if configured, plus segmentation and reassembly, and duplicate detection.
PDCP does ciphering and deciphering, integrity protection and verification, reordering and in-order delivery, and duplication and duplicate handling for higher-layer packets. It's also the anchor protocol that supports handovers ๐ฆ.
SDAP maps QoS flows, as established by the 5G core network, to data radio bearers (associated with logical channels), as used in the 5G RAN ๐ง.
Then there's the Radio Resource Control (RRC) protocol, which handles access control and configuration signaling for all of those layers. RRC messages count as Layer 3, so they also get sent through those radio protocol layers ๐.
Finally, to get low latency and high reliability for one transmission link (so, to transport data or control signaling of one radio bearer via one carrier), a bunch of features have been added to the user plane protocols for PHY and Layer 2. We'll go through them below ๐ธ.
6.4.3. Radio (PHY) ๐ก
NR is built with native support for antenna arrays, which get benefits from beamforming, transmissions over multiple MIMO layers, and advanced receiver algorithms that allow effective interference cancellation. Those antenna techniques are the basis for high signal quality and effective spectral usage ๐. Spatial diversity with up to four MIMO layers in UL and up to eight MIMO layers in DL is supported. Together with spatial-domain multiplexing, antenna arrays can focus power in the desired direction to form beams. NR supports beam management mechanisms to find the best suitable beam for UE initially and when it is moving. Also, gNBs can coordinate their respective downlink (DL) and uplink (UL) transmissions over the backhaul network, keeping interference reasonably low, and even make transmissions or receptions from multiple points (multi-TRP). Multi-TRP can be used for repetition of a data packet in time, in frequency, or over multiple MIMO layers, which can improve reliability even further ๐ซถ.
Any DL transmission to a UE starts from resource allocation signaling over the Physical Downlink Control Channel (PDCCH). If it is successfully received, the UE will know about the scheduled transmission and may receive data over the Physical Downlink Shared Channel (PDSCH). If retransmission is required according to the HARQ scheme, a negative acknowledgement (NACK) signal goes out on the Physical Uplink Control Channel (PUCCH), and PDCCH together with PDSCH transmissions (possibly with additional redundancy bits) are sent and soft-combined with previously received bits. Otherwise, if no valid control signaling for scheduling data is received, nothing is transmitted on PUCCH (discontinuous transmission (DTX)), and upon detecting DTX, the base station will retransmit the initial data ๐.
An UL transmission normally starts from a Scheduling Request (SR), a signaling message from the UE to the base station sent via PUCCH. Once the scheduler knows about buffer data in the UE (e.g., by SR), the UE transmits a data packet on the Physical Uplink Shared Channel (PUSCH). Pre-scheduling, which doesn't rely on SR, is also possible (see Section 6.4.4).
Since transmitting data packets requires control and data channels, there are several ways to keep the needed reliability ๐ก๏ธ. NR uses Low Density Parity Check (LDPC) codes for data channels, polar codes for PDCCH, and orthogonal sequences and polar codes for PUCCH. For ultra-reliability of data channels, very robust (low-spectral efficiency) Modulation and Coding Scheme (MCS) tables are introduced, containing very low (down to 1/20) LDPC code rates using Binary Phase-Shift Keying (BPSK) or Quadrature Phase-Shift Keying (QPSK). Also, PDCCH and PUCCH channels support multiple code rates, including very low ones, for channel robustness.
A connected UE reports DL quality to the gNB by sending Channel State Information (CSI) reports via PUCCH, while UL quality is measured directly at the gNB. For both UL and DL, the gNB selects the desired MCS number and signals it to the UE by Downlink Control Information (DCI) via PDCCH. For URLLC services, the UE can help the gNB by advising that MCS targeting a 10^-5 Block Error Rate (BLER) are used. Robust link adaptation algorithms can maintain the needed level of reliability, considering a given latency bound ๐ฏ.
Low latency on the PHY layer comes from short transmission duration, which is possible by using high Subcarrier Spacing (SCS) and allocating only one or a few Orthogonal Frequency Division Multiplexing (OFDM) symbols โก. For example, the shortest latency for the worst case is 0.23 ms in DL and 0.24 ms in UL (according to Section 5.7.1 in [TR37910]). Moreover, if the initial transmission has failed, HARQ feedback can quickly be provided and an HARQ retransmission scheduled.
Dynamic multiplexing of data for different services is highly desirable, because it makes efficient use of system resources and maximizes system capacity ๐. Assignment of resources for eMBB is usually done with regular (longer) transmission slots, which can lead to blocking of low-latency services. To overcome the blocking, eMBB resources can be preempted and reassigned to URLLC services. This way, spectrally efficient assignments for eMBB can be ensured while still providing the flexibility needed to ensure a bounded latency for URLLC services. In DL, the gNB can notify the eMBB UE about preemption after it has happened. In UL, there are two preemption mechanisms: special signaling to cancel eMBB transmission, and URLLC dynamic power boost to suppress eMBB transmission ๐.
6.4.4. Scheduling and QoS (MAC) โจ
Okay bestie, one of the biggest pieces of the 5G system is the Quality of Service (QoS) framework [TS23501] ๐ . The 5G system sets up QoS flows for certain IP or Ethernet packet flows, so that packets in each flow get the same forwarding treatment (that's scheduling and admission control) ๐. For example, QoS flows can be linked to different priority levels, packet delay budgets, and tolerable packet error rates ๐ฆ. And since radio resources are centrally scheduled in NR, the admission control function makes sure that only QoS flows whose QoS targets can actually be reached get in ๐. Not letting just anyone through, periodt ๐.
NR transmissions in both UL and DL are scheduled by the gNB [TS38300] ๐ซถ. This keeps radio resource use efficient and fair across users, and it lets the data flows of each user get differentiated treatment based on their QoS targets ๐. Those QoS flows are handled as data radio bearers or logical channels in NR RAN scheduling ๐ธ.
The gNB can dynamically assign DL and UL radio resources to users, telling the UE about them as DL assignments or UL grants over the control channel ๐ง. Radio resources are defined as blocks of OFDM symbols in the spectral and time domains โจ. Different time-domain lengths are supported (so, multiple slot or mini-slot lengths) ๐. Resources from multiple frequency carriers can be aggregated and jointly scheduled to the UE ๐.
Scheduling decisions are based on things like channel quality measured on reference signals and reported by the UE (cf. periodical CSI reports for DL channel quality) ๐ฅ. The transmission reliability can be picked in the scheduling algorithm, which is link adaptation: an appropriate transmission format (for example, robustness of modulation and coding scheme, or controlled UL power) gets selected for the UE's radio channel condition ๐ฆ. Retransmissions based on HARQ feedback are also controlled by the scheduler ๐ . The feedback in the HARQ loop adds delay, but there are ways to shrink it, like short transmission formats, sub-slot feedback reporting, and PUCCH carrier switching โญ. If needed to avoid HARQ round-trip time delays, repeated transmissions can also be scheduled beforehand, but that costs spectral efficiency ๐.
In dynamic DL scheduling, transmission can start right away when DL data shows up at the gNB ๐. Dynamic UL scheduling is trickier ๐ญ. When data shows up but no UL resources are available yet, the UE asks for UL resources by sending a (single bit) scheduling request message on the UL control channel ๐โโ๏ธ. Once UL resources are scheduled, the UE can transmit its data and may include a buffer status report saying exactly how much data is still left to send per logical channel ๐. More UL resources may then get scheduled accordingly ๐. To dodge the latency of the scheduling request loop, UL radio resources can also be pre-scheduled ๐ซ.
For periodic traffic patterns especially, pre-scheduling can rely on DL Semi-Persistent Scheduling (SPS) and UL Configured Grant (CG) ๐. With these, periodically recurring resources can be assigned in DL and UL ๐. Multiple parallel configurations of these are supported so the same UE can serve multiple parallel traffic flows ๐.
To keep QoS enforced when mixed traffic has different QoS requirements, several features were recently introduced ๐. They let different periodic critical QoS flows get served, together with best-effort transmissions, by the same UE ๐ซถ. These features include the following:
- UL logical channel transmission restrictions, allowing logical channels of certain QoS to only be mapped to intended UL resources of a certain frequency carrier, slot length, or CG configuration ๐งฉ.
- intra-UE preemption and multiplexing, allowing critical UL transmissions to either preempt non-critical transmissions or be multiplexed with non-critical transmissions while keeping different reliability targets ๐ฆ.
When multiple frequency carriers are aggregated, duplicate parallel transmissions can be used (on top of repeated transmissions on one carrier) ๐. This works in the Carrier Aggregation (CA) architecture, where the carriers come from the same gNB, or in the Dual Connectivity (DC) architecture, where the carriers come from different gNBs (meaning the UE is connected to two gNBs in this case) ๐. Either way, transmission reliability goes up thanks to frequency diversity ๐ฆ.
In addition to licensed spectrum, a 5G system can also use unlicensed spectrum to offload non-critical traffic ๐. This version of NR, called NR-U, is part of 3GPP Release 16 ๐ง. The central scheduling approach also applies to unlicensed radio resources, and the mandatory channel access mechanisms for unlicensed spectrum (for example, Listen Before Talk (LBT) is supported in NR-U) are in play too ๐. So with NR, operators have and can control access to both licensed and unlicensed frequency resources ๐.
6.4.5. Time-Sensitive Communications (TSC) ๐ฐ๏ธ
Recent 3GPP releases have introduced a bunch of features for different parts of Time-Sensitive Communication (TSC), which includes Time-Sensitive Networking (TSN) and beyond, as we'll see in this section ๐.
The main goal of TSN is to guarantee data delivery within a guaranteed time window (aka bounded low latency) ๐ฏ. IEEE 802.1 TSN [IEEE802.1TSN] is a set of open standards that add features for deterministic communication on standard IEEE 802.3 Ethernet [IEEE802.3] ๐ง . TSN standards are basically a toolbox for traffic shaping, resource management, time synchronization, and reliability ๐งฐ.
A TSN stream is a data flow from one end station (talker) to another end station (listener) ๐ฃ๏ธ. In the centralized configuration model, TSN bridges get configured by the Central Network Controller (CNC) [IEEE802.1Qcc] to give the TSN stream deterministic connectivity through the network ๐. Time-based traffic shaping from scheduled traffic [IEEE802.1Qbv] may be used to achieve bounded low latency โฑ๏ธ. The TSN tool for time synchronization is the generalized Precision Time Protocol (gPTP) [IEEE802.1AS], which provides reliable time sync that end stations and other TSN tools (e.g., scheduled traffic [IEEE802.1Qbv]) can use ๐ซง. High availability, from ultra-reliability, is provided for data flows by the Frame Replication and Elimination for Reliability (FRER) mechanism [IEEE802.1CB] ๐ก๏ธ.
3GPP Release 16 brings 5G and TSN together, meaning it specifies functions for the 5G System (5GS) to deliver TSN streams so their QoS requirements are met ๐ค. The big thing here is that, from the rest of the network, the 5GS looks like a set of TSN bridges (specifically, one virtual bridge per User Plane Function (UPF) on the user plane) ๐ช. The 5GS includes TSN Translator (TT) functionality to adapt the 5GS to the TSN bridged network and to hide the 5GS internal procedures ๐ถ๏ธ. The 5GS provides the following components:
- interface to TSN controller, as per [IEEE802.1Qcc] for the fully centralized configuration model
- time synchronization via reception and transmission of gPTP PDUs [IEEE802.1AS]
- low latency, which allows integration with scheduled traffic [IEEE802.1Qbv]
- reliability, which allows integration with FRER [IEEE802.1CB]
3GPP Release 17 [TS23501] pushed TSC beyond TSN with enhancements ๐. This includes IP communications to provide time-sensitive services (e.g., to Video, Imaging, and Audio for Professional Applications (VIAPA)) ๐ฅ. The system model where 5G acts as a "TSN bridge" in Release 16 got reused so the 5GS can act as a "TSC node" in a more generic sense (which covers both a TSN bridge and an IP node) ๐. When TSC doesn't involve TSN, requirements are given via exposure interfaces, and the control plane provides the service based on QoS and time synchronization requests from an Application Function (AF) ๐ก.
Figure 7 shows 5G-TSN integration, where an industrial controller (Ind Ctrlr) is connected to industrial Input/Output devices (I/O dev) via 5G ๐ญ. The 5GS can directly transport Ethernet frames since Release 15, so end-to-end Ethernet connectivity is provided ๐งต. The 5GS implements the required interfaces towards TSN controller functions such as the CNC, so it adapts to the settings of the TSN network ๐๏ธ. A 5G user plane virtual bridge interconnects TSN bridges or connects end stations (e.g., I/O devices to the TSN network) ๐. The TTs, meaning the Device-Side TSN Translator (DS-TT) at the UE and the Network-Side TSN Translator (NW-TT) at the UPF, play a key role in the interconnection ๐ซ. Also, 5G brings flexibility in various aspects, e.g., a more flexible network topology, because a wireless hop can replace several wireline hops, which significantly reduces the number of hops end to end ๐ฆ. [TSN5G] goes deeper into the integration of 5G with TSN ๐.
+------------------------------+
| 5G System |
| +---+|
| +-+ +-+ +-+ +-+ +-+ |TSN||
| | | | | | | | | | | |AF |......+
| +++ +++ +++ +++ +++ +-+-+| .
| | | | | | | | .
| -+---+---++--+-+-+--+-+- | .
| | | | | | +--+--+
| +++ +++ +++ +++ | | TSN |
| | | | | | | | | | |Ctrlr+.......+
| +++ +++ +++ +++ | +--+--+ .
| | . .
| | . .
| +..........................+ | . .
| . Virtual Bridge . | . .
+---+ | . +--+--+ +---+ +---+--+ . | +--+---+ .
|I/O+----------------+DS|UE+---+RAN+-+UPF|NW+------+ TSN +----+ .
|dev| | . |TT| | | | | |TT| . | |bridge| | .
+---+ | . +--+--+ +---+ +---+--+ . | +------+ | .
| +..........................+ | . +-+-+-+
| | . | Ind |
| +..........................+ | . |Ctrlr|
| . Virtual Bridge . | . +-+---+
+---+ +------+ | . +--+--+ +---+ +---+--+ . | +--+---+ |
|I/O+--+ TSN +------+DS|UE+---+RAN+-+UPF|NW+------+ TSN +----+
|dev| |bridge| | . |TT| | | | | |TT| . | |bridge|
+---+ +------+ | . +--+--+ +---+ +---+--+ . | +------+
| +..........................+ |
+------------------------------+
<----------------- end-to-end Ethernet ------------------->
Figure 7: 5G - TSN IntegrationNR is giving precision ๐ . It supports accurate reference time synchronization at the 1 ยตs accuracy level ๐ฏ. NR is a scheduled system, so an NR UE and a gNB are tightly synced to their OFDM symbol structures โฑ๏ธ. A 5G internal reference time can be handed to the UE through broadcast or unicast signaling, linking a known OFDM symbol to this reference clock ๐ซถ. That 5G internal reference time can be shared across the whole 5G network, meaning the radio and core network components โจ. Release 16 brought interworking with gPTP for multiple time domains. The 5GS acts as a virtual gPTP time-aware system and forwards gPTP time synchronization info between end stations and bridges through the 5G user plane TTs ๐ฆ. These account for the residence time of the 5GS in the time synchronization procedure. One special option is when the 5GS internal reference time is used not just inside the 5GS but by all the other devices in the deployment too, including connected TSN bridges and end stations ๐.
Release 17 added further improvements, like methods for propagation delay compensation in the RAN, which make over-the-air time sync even more accurate ๐ฅ. It also made it possible for the TSN grandmaster clock to live on the UE side ๐. More extensions and flexibility were added to the time synchronization service, so it's general enough for TSC and supports other clock types and time distribution, like boundary clocks and transparent clocks (both peer-to-peer and end-to-end), on top of the time-aware system used for TSN ๐ง. Internal access stratum signaling can also be used to distribute timing instead of the usual (g)PTP messages, and the AF [TS23501] can provide the accuracy needed for that ๐. The same time synchronization service is expected to get further extended and enhanced in Release 18 for Timing Resiliency (according to study item [SP211634]). There, the 5G system can act as a backup or alternative timing source if the local GNSS source (or another primary timing source) used by the vertical fails ๐.
IETF DetNet is the tech for time-sensitive communications at the IP layer ๐ธ. 3GPP Release 18 includes a study [TR2370046] on interworking between 5G and DetNet ๐. Along the TSC framework introduced for Release 17, the 5GS acts as a DetNet node for DetNet support. See Figure 7.1-1 in [TR2370046] ๐. The study explains how the 5GS is exposed by the Time Sensitive Communication and Time Synchronization Function (TSCTSF) to the DetNet controller as a router at per-UPF granularity, similar to the per-UPF Virtual TSN Bridge granularity shown in Figure 7 ๐ . It also lists the parameters that the TSCTSF provides to the DetNet controller. The study covers how the TSCTSF maps DetNet flow parameters to 5G QoS parameters too ๐ง . Note that TSN is the primary subnetwork technology for DetNet. That means the work on DetNet over TSN, e.g., [RFC9023], can be leveraged through the TSN support built into 5G ๐ซถ.
Redundancy architectures were specified to provide reliability against any kind of failure on the radio link or in the nodes of the RAN and the core network ๐ญ. Redundant user plane paths can be provided with the dual connectivity architecture. The UE sets up two PDU sessions towards the same data network, and the 5G system makes the paths of the two PDU sessions independent, as illustrated in Figure 8 โจ. Two PDU sessions are involved. The first runs from the UE via gNB1 to UPF1, acting as the first PDU session anchor. The second runs from the UE via gNB2 to UPF2, acting as the second PDU session anchor ๐.
+........+
. Device . +------+ +------+ +------+
. . + gNB1 +--N3--+ UPF1 |--N6--+ |
. ./+------+ +------+ | |
. +----+ / | |
. | |/. | |
. | UE + . | DN |
. | |\. | |
. +----+ \ | |
. .\+------+ +------+ | |
+........+ + gNB2 +--N3--+ UPF2 |--N6--+ |
+------+ +------+ +------+
Figure 8: Reliability with Single UEThe independent paths can keep going 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) ๐. An RHF can implement replication and elimination functions as per [IEEE802.1CB], or the Packet Replication, Elimination, and Ordering Functions (PREOF) of IETF DetNet [RFC8655] โจ.
An alternative solution uses multiple UEs per device for user plane redundancy, as illustrated in Figure 9 ๐. Each UE sets up a PDU session. The 5GS makes sure the PDU sessions of the different UEs are handled independently inside the 5GS ๐ . There is no single point of failure in this solution, which also includes an RHF outside of the 5G system, e.g., as per the FRER [IEEE802.1CB] or PREOF [RFC8655] specifications ๐ก๏ธ.
+.........+
. Device .
. .
. +----+ . +------+ +------+ +------+
. | UE +-----+ gNB1 +--N3--+ UPF1 |--N6--+ |
. +----+ . +------+ +------+ | |
. . | DN |
. +----+ . +------+ +------+ | |
. | UE +-----+ gNB2 +--N3--+ UPF2 |--N6--+ |
. +----+ . +------+ +------+ +------+
. .
+.........+
Figure 9: Reliability with Dual UENote that the abstraction provided by the RHF, and the location of the RHF outside of the 5G system, let 5G support integration for reliability with both TSN FRER [IEEE802.1CB] and DetNet PREOF [RFC8655]. That's because they both rely on the same concept ๐ฅ๐.
7. L-Band Digital Aeronautical Communications System (LDACS) โ๏ธ
One of the main pillars of the modern Air Traffic Management (ATM) system is a communication infrastructure that enables efficient aircraft guidance and safe separation in all phases of flight ๐ซ. Current systems are technically mature, but they suffer from the VHF band's increasing saturation in high-density areas and the limits of analog radio ๐ฉ. So aviation, globally and in the European Union (EU) especially, is striving for a sustainable modernization of the aeronautical communication infrastructure ๐.
In the long term, ATM communication shall transition from analog VHF voice and VHF Digital Link (VDL) Mode 2 communication to more spectrum-efficient digital data communication ๐ก. The European ATM Master Plan foresees this transition being realized for terrestrial communications through the development and implementation of the L-band Digital Aeronautical Communications System (LDACS) ๐ฏ.
LDACS was designed with applications related to the safety and regularity of flight in mind ๐ซถ. It was therefore designed as a deterministic wireless data link (as far as possible) โฑ๏ธ.
It's a secure, scalable, and spectrum-efficient data link with embedded navigation capability. That makes it the first truly integrated Communications, Navigation, and Surveillance (CNS) system recognized by the International Civil Aviation Organization (ICAO) ๐. LDACS capabilities have been successfully demonstrated during flight tests ๐. A viable rollout scenario has been developed, which allows gradual introduction of LDACS with immediate use and revenues ๐ฐ. Finally, ICAO is developing LDACS standards to pave the way for the future ๐ฎ.
LDACS shall enable IPv6-based air-ground communication related to the safety and regularity of flight. The big challenge is that no new frequencies can be made available for terrestrial aeronautical communication ๐ญ. So it was necessary to develop procedures to enable LDACS to operate in parallel with other services in the same frequency band; see [RFC9372] for more information ๐ฆ.
7.1. Provenance and Documents
LDACS development has already made substantial progress in the Single European Sky ATM Research (SESAR) framework, and it's currently being continued in the follow-up program, SESAR2020 [RIH18] ๐ธ. A key objective of the SESAR activities is to develop, implement, and validate a modern aeronautical data link that can evolve with aviation needs over the long term โจ. To this end, an LDACS specification has been produced [GRA19] and is continuously updated. Transmitter demonstrators were developed to test the spectrum compatibility of LDACS with legacy systems operating in the L-band [SAJ14], and the overall system performance was analyzed by computer simulations, which indicated that LDACS can fulfill the identified requirements [GRA11] ๐งช.
LDACS standardization within the framework of the ICAO started in December 2016. The ICAO standardization group has produced an initial Standards and Recommended Practices (SARPs) document [ICAO18]. The SARPs document defines the general characteristics of LDACS ๐.
Up to now, LDACS standardization has focused on the development of the Physical (PHY) layer and the data link layer. Only recently have higher layers come into focus in LDACS development activities ๐ฅน. There is currently no "IPv6 over LDACS" specification. However, SESAR2020 has started testing IPv6-based LDACS testbeds ๐งช. The IPv6 architecture for the aeronautical telecommunication network is called the Future Communications Infrastructure (FCI). FCI shall support QoS, diversity, and mobility under the umbrella of the "multi-link concept". This work is conducted by the ICAO WG-I Working Group ๐ .
In addition to standardization activities, several industrial LDACS prototypes have been built. One set of LDACS prototypes has been evaluated in flight trials, confirming the theoretical results predicting the system performance [GRA18] [BEL22] [GRA23] ๐.
.
Okay, Part 12, here we go! ๐ฆ Picking up right where we left off: LDACS, the L-Band Digital Aeronautical Communications System, and we're now in the general characteristics and deployment bit. Let's gooo ๐
7.2. General Characteristics
okay so LDACS is gonna be one of several wireless access networks connecting aircraft to the Aeronautical Telecommunications Network (ATN) ๐ฉ๏ธโจ The LDACS access network has several ground stations, and each one runs its own LDACS radio cell. The air interface is a cellular data link with a star topology, so aircraft connect to ground stations over a full duplex radio link. ๐ธ Each ground station is the centralized instance controlling all air-ground communications inside its radio cell. bestie, it's the boss of its cell ๐
The user data rate is 315 kbit/s to 1428 kbit/s on the forward link (FL), and 294 kbit/s to 1390 kbit/s on the reverse link (RL), depending on coding and modulation. ๐ Because there's strong interference from legacy systems in the L-band, the most robust coding and modulation should be expected for initial deployment, so 315 kbit/s on the FL and 294 kbit/s on the RL. ngl that's the realistic starting point ๐
LDACS also does navigation, not just communications ๐ง Ranging data, similar to Distance Measuring Equipment (DME), gets extracted from the LDACS communication links between aircraft and ground stations. So LDACS can provide an Alternative Position, Navigation, and Timing (APNT) capability to back up the on-board Global Navigation Satellite System (GNSS), and it doesn't need any extra bandwidth for that ๐คฏ Pilots won't notice a difference whether the navigation data comes from LDACS or DME, which is so iconic. This was flight tested and proven during the MICONAV flight trials in 2019 [BAT19] ๐
It also does surveillance! During previous work and the MICONAV flight campaign in 2019, it was shown that LDACS can do surveillance too ๐ Filip et al. [FIL19] showed the passive radar capabilities of LDACS, and Automatic Dependence Surveillance - Contract (ADS-C) was demonstrated over LDACS during the 2019 flight campaign [SCH19]. main character energy ๐ฆ
Since LDACS was mainly designed for air traffic management communication, it supports mutual entity authentication, integrity and confidentiality for user data messages, and some control channel protection capabilities [MAE18] [MAE191] [MAE192] [MAE20] ๐๐ซถ
Overall, this makes LDACS the world's first truly integrated CNS system ๐ญ It's the most mature, secure, and terrestrial long-range CNS technology for civil aviation worldwide. iconic behaviour, honestly ๐๐
7.3. Deployment and Spectrum
LDACS comes from merging parts of the B-VHF [BRA06], B-AMC [SCH08], TIA-902 (P34) [HAI09], and WiMAX IEEE 802.16e [EHA11] technologies ๐งฉ In 2007, the spectrum for LDACS was allocated at the World Radio Conference (WRC). ๐
The spectrum was decided to be allocated next to Distance Measuring Equipment (DME), which makes an in-lay approach between the DME channels for LDAC [SCH14] ๐
LDACS is currently being standardized by ICAO, and several rollout strategies are being discussed ๐ธ
The LDACS data link gives enhanced capabilities to existing aeronautical communications infrastructures, so they can better support user needs and new applications โจ The deployment scalability of LDACS means implementation can start in the areas where it's most needed, to immediately improve the performance of already-fielded infrastructure ๐ Later, the deployment is extended based on operational demand. An attractive scenario for upgrading the existing VHF communication systems is adding an additional LDACS data link, and it's described below ๐ฆ
When you look at the current VDL Mode 2 infrastructure and user base, a really attractive win-win situation shows up when LDACS technology is combined with the existing VDL Mode 2 infrastructure ๐ LDACS provides at least 50 times more capacity than VDL Mode 2, and it's a natural enhancement to the existing VDL Mode 2 business model ๐ญ The best part is that the VDL Mode 2 infrastructure can be fully reused. Beyond that, it opens the way for further enhancements [ICAO19] ๐
7.4. Applicability to Deterministic Flows
As LDACS is a ground-based digital communications system for flight guidance and communications related to the safety and regularity of flight, time-bounded deterministic arrival times for safety-critical messages are a key feature for its successful deployment and rollout โญ no cap, this is the whole point ๐
7.4.1. System Architecture
Up to 512 Aircraft Stations (ASes) communicate to an LDACS Ground Station (GS) in the reverse link (RL) ๐ซ A GS communicates to an AS in the forward link (FL). Via an Access-Router (AC-R), GSs connect the LDACS subnetwork to the global Aeronautical Telecommunications Network (ATN), where the corresponding Air Traffic Services (ATS) and Aeronautical Operational Control (AOC) end systems are attached ๐งโจ
7.4.2. Overview of the Radio Protocol Stack
The protocol stack of LDACS is implemented in the AS and GS. It consists of the Physical (PHY) layer with five major functional blocks above it. Four of them sit in the data link layer (DLL) of the AS and GS:
- Medium Access Layer (MAC),
- Voice Interface (VI),
- Data Link Service (DLS), and
- LDACS Management Entity (LME).
The last entity lives within the subnetwork layer: the Subnetwork Protocol (SNP). The LDACS network is externally connected to voice units, radio control units, and the ATN network layer ๐
Communications between the MAC and LME layers are split into four distinct control channels:
- the Broadcast Control Channel (BCCH), where LDACS ground stations announce their specific LDACS cell, including physical parameters and cell identification;
- the Random Access Channel (RACH), where LDACS airborne radios can request access to an LDACS cell;
- the Common Control Channel (CCCH), where LDACS ground stations allocate resources to aircraft radios, enabling the airborne side to transmit the user payload; and
- the Dedicated Control Channel (DCCH), where LDACS airborne radios can request user data resources from the LDACS ground station so the airborne side can transmit the user payload.
Communications between the MAC and DLS layers are handled by the Data Channel (DCH), where the user payload is handled ๐
Figure 10 shows the protocol stack of LDACS as implemented in the AS and GS ๐
IPv6 Network Layer
|
|
+------------------+ +----+
| SNP |--| | Subnetwork
| | | | Layer
+------------------+ | |
| | LME|
+------------------+ | |
| DLS | | | Logical Link
| | | | Control Layer
+------------------+ +----+
| |
DCH DCCH/CCCH
| RACH/BCCH
| |
+--------------------------+
| MAC | Medium Access
| | Layer
+--------------------------+
|
+--------------------------+
| PHY | Physical Layer
+--------------------------+
|
|
((*))
FL/RL radio channels
separated by
frequency division duplex
Figure 10: LDACS Protocol Stack in AS and GS7.4.3. Radio (PHY)
The PHY layer provides the means to transfer data over the radio channel ๐ก The LDACS ground station supports bidirectional links to multiple aircraft under its control. The FL direction (ground to air) and the RL direction (air to ground) are separated by frequency division duplex. FL and RL each use a 500 kHz channel. The ground station transmits a continuous stream of OFDM symbols on the FL. In the RL, different aircraft are separated in time and frequency using a combination of Orthogonal Frequency-Division Multiple Access (OFDMA) and Time-Division Multiple-Access (TDMA). So aircraft transmit discontinuously on the RL, with radio bursts sent in precisely defined transmission opportunities allocated by the ground station ๐ฆ The most important service on the PHY layer of LDACS is the PHY time framing service, which indicates that the PHY layer is ready to transmit in a given slot, and it indicates PHY layer framing and timing to the MAC time framing service. LDACS does not support beam-forming or Multiple Input Multiple Output (MIMO), so no fancy antenna tricks here ๐ โจ
7.4.4. Scheduling, Frame Structure, and QoS (MAC) โจ
okay so the data link layer is the part that lets a bunch of users share the air at once and still get their stuff through reliably ๐ซถ LDACS splits it into two sublayers. The medium access sublayer manages the transmission opportunities, organised in slots of time and frequency ๐ธ The logical link control sublayer gives you acknowledged point-to-point logical channels between the aircraft and the ground station, using an automatic repeat request protocol. LDACS also does unacknowledged point-to-point channels and ground-to-air broadcast ๐ก
Next up is the frame structure, then a deeper dive into LDACS medium access ๐
The LDACS framing for FL and RL is built on Super-Frames (SF) that last 240 ms each ๐ฆ Each SF is 2000 OFDM symbols long. The FL and RL SF boundaries line up in time, from the view of the GS.
In the FL, each SF has a broadcast frame lasting 6.72 ms (56 OFDM symbols) for the Broadcast Control Channel (BCCH), followed by four Multi-Frames (MF), each lasting 58.32 ms (486 OFDM symbols) ๐
In the RL, each SF starts with a Random Access (RA) slot that's 6.72 ms long. That slot has two opportunities for sending RL random access frames for the Random Access Channel (RACH), and then four MFs come after it ๐ง These MFs have the same fixed duration of 58.32 ms as in the FL, but a different internal structure.
Figures 11 and 12 show the LDACS frame structure. This fixed frame structure is what makes the transmission of data so reliable and dependable ๐
^
| +------+------------+------------+------------+------------+
| FL | BCCH | MF | MF | MF | MF |
F +------+------------+------------+------------+------------+
r <---------------- Super-Frame (SF) - 240 ms --------------->
e
q +------+------------+------------+------------+------------+
u RL | RACH | MF | MF | MF | MF |
e +------+------------+------------+------------+------------+
n <---------------- Super-Frame (SF) - 240 ms --------------->
c
y
|
----------------------------- Time ------------------------------>
|Figure 11: SF Structure for LDACS
^
| +-------------+------+-------------+
| FL | DCH | CCCH | DCH |
F +-------------+------+-------------+
r <--- Multi-Frame (MF) - 58.32 ms -->
e
q +------+---------------------------+
u RL | DCCH | DCH |
e +------+---------------------------+
n <--- Multi-Frame (MF) - 58.32 ms -->
c
y
|
-------------------- Time ------------------>
|Figure 12: MF Structure for LDACS
Next, the LDACS medium access layer ๐
LDACS medium access is always under the control of the ground station of a radio cell. Any medium access for sending user data has to be requested with a resource request message that states how many resources are needed and the class of service ๐ The ground station does the resource scheduling based on those requests and grants resources with resource allocation messages. Resource request and allocation messages get exchanged over dedicated contention-free control channels ๐
LDACS has two ways to request resources from the scheduler in the ground station. Resources can be requested "on demand", or permanently allocated by a LDACS ground station with a given class of service โจ On the FL, this happens locally in the ground station. On the RL, a dedicated contention-free control channel is used: the Dedicated Control Channel (DCCH), which carries roughly 83 bits every 60 ms. A resource allocation is always announced in the control channel of the FL, the Common Control Channel (CCCH), which is variable sized. Because the RL control channels are spaced every 60 ms, you should expect a medium access delay in the same order of magnitude ๐
Resources can also be requested "permanently". The permanent resource request mechanism supports requesting recurring resources at given time intervals ๐ A permanent resource request has to be cancelled by the user, or by the ground station, which is always in control ๐ So user data transmissions over LDACS are always scheduled by the ground station, while control data uses statically allocated recurring resources (DCCH and CCCH), allocated at net entry. The current specification documents specify no scheduling algorithm. However, performance evaluations so far have used strict priority scheduling, and round robin for equal priorities, because they're simple ๐ In the current prototype implementations, LDACS classes of service are realised as priorities of medium access and not as flows. Note that this can starve out low-priority flows ๐ญ Still, it's not seen as a big problem, since safety-related messages always go first in any case ๐ซถ Scheduling of RL resources is done in physical Protocol Data Units (PDU) of 112 bits (or larger if more aggressive coding and modulation is used). Scheduling on the FL is done byte wise, since the FL is transmitted continuously by the ground station.
In order to support diversity, LDACS supports handovers to other ground stations on different channels ๐ฆ Handovers may be initiated by the aircraft (break before make) or by the ground station (make before break). Beyond this, FCI diversity shall be implemented by the multi-link concept.
8. IANA Considerations ๐
This document has no IANA actions.
9. Security Considerations ๐
Most RAW technologies integrate some authentication or encryption mechanisms that are defined outside the IETF. The IETF specifications referenced herein each provide their own security considerations, and the lower-layer technologies used provide their own security at Layer 2.
10. References โญ
10.1. Normative References
[RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October 2009, https://www.rfc-editor.org/info/rfc5673.
[RFC8557] Finn, N. and P. Thubert, "Deterministic Networking Problem Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019, https://www.rfc-editor.org/info/rfc8557.
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, https://www.rfc-editor.org/info/rfc8655.
[RFC9912] Thubert, P., Ed., "Reliable and Available Wireless (RAW) Architecture", RFC 9912, DOI 10.17487/RFC9912, April 2026, https://www.rfc-editor.org/info/rfc9912.
10.2. Informative References
[Avnu] "Avnu Alliance", https://www.avnu.org.
[BAT19] Battista, G., Osechas, O., Narayanan, S., Crespillo, O.G., Gerbeth, D., Maeurer, N., Mielke, D., and T. Graeupl, "Real-Time Demonstration of Integrated Communication and Navigation Services Using LDACS", Integrated Communications, Navigation and Surveillance Conference (ICNS), pp. i-xii, DOI 10.1109/ICNSURV.2019.8735195, 2019, https://elib.dlr.de/134475/1/08735195.pdf.
[BEL22] Bellido-Manganell, M. A., Grรคupl, T., Heirich, O., Mรคurer, N., Filip-Dhaubhadel, A., Mielke, D. M., Schalk, L. M., Becker, D., Schneckenburger, N., and M. Schnell, "LDACS Flight Trials: Demonstration and Performance Analysis of the Future Aeronautical Communications System", IEEE Transactions on Aerospace and Electronic Systems, vol. 58, no. 1, pp. 615-634, DOI 10.1109/TAES.2021.3111722, February 2022, https://doi.org/10.1109/TAES.2021.3111722.
[BRA06] Brandes, S., Schnell, M., Rokitansky, C.-h., Ehammer, M., Graeupl, T., Steendam, H., Guenach, M., Rihacek, C., and B. Haindl, "B-VHF - Selected Simulation Results and Final Assessment", IEEE 25th Digital Avionics Systems Conference (DACS), pp. 1-12, DOI 10.1109/DASC.2006.313670, 2006, https://doi.org/10.1109/DASC.2006.313670.
[Cavalcanti1287] Cavalcanti, D., Venkatesan, G., Cariou, L., and C. Cordeiro, "TSN support in 802.11 and potential extensions for TGbe", 10 September 2019, https://mentor.ieee.org/802.11/dcn/19/11-19-1287.
[Cavalcanti_2019] Cavalcanti, D., Perez-Ramirez, J., Rashid, M. M., Fang, J., Galeev, M., and K. B. Stanton, "Extending Accurate Time Distribution and Timeliness Capabilities Over the Air to Enable Future Wireless Industrial Automation Systems", Proceedings of the IEEE, vol. 107, no. 6, pp. 1132-1152, DOI 10.1109/JPROC.2019.2903414, June 2019, https://doi.org/10.1109/JPROC.2019.2903414.
[CCAMP] IETF, "Common Control and Measurement Plane", https://datatracker.ietf.org/doc/charter-ietf-ccamp/.
[CoAP-6TiSCH] Sudhaakar, R. S., Ed. and P. Zand, "6TiSCH Resource Management and Interaction using CoAP", Work in Progress, Internet-Draft, draft-ietf-6tisch-coap-03, 9 March 2015, https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-coap-03.
[EHA11] Ehammer, M., Pschernig, E., and T. Graeupl, "AeroMACS - An Airport Communications System", 2011 IEEE/AIAA 30th Digital Avionics Systems Conference, pp. 4C1-1-4C1-16, DOI 10.1109/DASC.2011.6095903, 2011, https://doi.org/10.1109/DASC.2011.6095903.
[Fang_2021] Fang, J., Sudhakaran, S., Cavalcanti, D., Cordeiro, C., and C. Chen, "Wireless TSN with Multi-Radio Wi-Fi", 2021 IEEE Conference on Standards for Communications and Networking (CSCN), pp. 105-110, DOI 10.1109/CSCN53733.2021.9686180, 2021, https://doi.org/10.1109/CSCN53733.2021.9686180.
[FIL19] Filip-Dhaubhadel, A. and D. Shutin, "LDACS- Based Non-Cooperative Surveillance Multistatic Radar Design and Detection Coverage Assessment", IEEE/AIAA 38th Digital Avionics Systems Conference (DASC), pp. 1-10, DOI 10.1109/DASC43569.2019.9081714, 2019, https://doi.org/10.1109/DASC43569.2019.9081714.
[Ghasempour_2017] Ghasempour, Y., Silva, C. R. C. M. D., Cordeiro, C., and E. W. Knightly, "802.11ay: Next-Generation 60 GHz Communications for 100 Gb/s Wi-Fi", IEEE Communications Magazine, vol. 55, no. 12, pp. 186-192, DOI 10.1109/MCOM.2017.1700393, December 2017, https://doi.org/10.1109/MCOM.2017.1700393.
[GRA11] Grรคupl, T., "LDACS1 Data Link Layer Evolution of ATN/IPS", IEEE/AIAA 30th Digital Avionics Systems Conference, pp. 1-28, DOI 10.1109/DASC.2011.6096230, October 2011, https://doi.org/10.1109/DASC.2011.6096230.
Okay bestie, the reference pile is massive ๐ and every single citation has to stay exactly right, so I've kept the whole list verbatim in a code block ๐ซถ
[GRA18] Grรคupl, T., Schneckenburger, N., Jost, T., Schnell, M.,
Filip, A., Bellido-Manganell, M. A., Mielke, D. M.,
Mรคurer, N., Kumar, R., Osechas, O., and G. Battista,
"L-band Digital Aeronautical Communications System (LDACS)
flight trials in the national German project MICONAV",
2018 Integrated Communications, Navigation, Surveillance
Conference (ICNS), pp. 4A2-1-4A2-7,
DOI 10.1109/ICNSURV.2018.8384881, April 2018,
<https://doi.org/10.1109/ICNSURV.2018.8384881>.
[GRA19] Grรคupl, T., Rihacek, C., Haindl, B., and Q. Parrod,
"SESAR2020 - PJ14-02-01 - LDACS A/G SPECIFICATION",
EDITION 00.02.02, 16 August 2019, <https://www.ldacs.com/
wp-content/uploads/2013/12/SESAR2020_PJ14_D3_3_030_LDACS_A
G_Specification_00_02_02-1_0.pdf>.
[GRA23] Grรคupl, T., Mielke, D. M., Bellido-Manganell, M. A.,
Jansen, L. J., Mรคurer, N., Gรผrbรผz, A., Filip-Dhaubhadel,
A., Schalk, L., Becker, D., Skorepa, M., Wrobel, F.,
Morioka, K., Kurz, S., and J. Meser, "LDACS Flight Trials:
Demonstration of ATS-B2, IPS, and Seamless Mobility", 2023
Integrated Communication, Navigation and Surveillance
Conference (ICNS), pp. 1-13,
DOI 10.1109/ICNS58246.2023.10124329, 2023,
<https://doi.org/10.1109/ICNS58246.2023.10124329>.
[HAI09] Haindl, B., Rihacek, C., Sajatovic, M., Phillips, B.,
Budinger, J., Schnell, M., Kamiano, D., and W. Wilson,
"Improvement of L-DACS1 Design by Combining B-AMC with P34
and WiMAX Technologies", 2009 Integrated Communications,
Navigation and Surveillance Conference, pp. 1-8,
DOI 10.1109/ICNSURV.2009.5172873, May 2009,
<https://doi.org/10.1109/ICNSURV.2009.5172873>.
[ICAO18] International Civil Aviation Organization (ICAO), "L-Band
Digital Aeronautical Communication System (LDACS)",
International Standards and Recommended Practices, Annex
10 - Aeronautical Telecommunications, Vol. III -
Communication Systems, July 2018,
<https://elibrary.icao.int/product/279816>.
[ICAO19] International Civil Aviation Organization (ICAO), "TLDACS
White Paper - A Roll-out Scenario", Communications Panel -
Data Communications Infrastructure Working Group, October
2019, <https://www.ldacs.com/wp-content/uploads/2013/12/
ACP-DCIWG-IP01-LDACS-White-Paper.pdf>.
[IEEE802.11]
IEEE, "IEEE Standard for Information Technology --
Telecommunications and Information Exchange between
Systems Local and Metropolitan Area Networks -- Specific
Requirements Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications", IEEE
Std 802.11-2024, DOI 10.1109/IEEESTD.2025.10979691, 2024,
<https://ieeexplore.ieee.org/document/10979691>.
[IEEE802.11ad]
IEEE, "IEEE Standard for Information technology --
Telecommunications and information exchange between
systems -- Local and metropolitan area networks --
Specific requirements-Part 11: Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY) Specifications
Amendment 3: Enhancements for Very High Throughput in the
60 GHz Band", IEEE Std 802.11ad-2012,
DOI 10.1109/IEEESTD.2012.6392842, 2012,
<https://ieeexplore.ieee.org/document/6392842/>.
[IEEE802.11ax]
IEEE, "IEEE Standard for Information Technology --
Telecommunications and Information Exchange between
Systems Local and Metropolitan Area Networks -- Specific
Requirements Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications Amendment 1:
Enhancements for High-Efficiency WLAN", IEEE Std 802.11ax-
2021, DOI 10.1109/IEEESTD.2021.9442429, 2021,
<https://ieeexplore.ieee.org/document/9442429>.
[IEEE802.11ay]
IEEE, "IEEE Standard for Information Technology --
Telecommunications and Information Exchange between
Systems Local and Metropolitan Area Networks -- Specific
Requirements Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications Amendment 2:
Enhanced Throughput for Operation in License-exempt Bands
above 45 GHz", IEEE Std 802.11ay-2021,
DOI 10.1109/IEEESTD.2021.9502046, 2021,
<https://ieeexplore.ieee.org/document/9502046/>.
[IEEE802.11be]
IEEE, "IEEE Standard for Information technology --
Telecommunications and information exchange between
systems Local and metropolitan area networks -- Specific
requirements - Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications Amendment 2:
Enhancements for Extremely High Throughput (EHT)", IEEE
Std 802.11be-2024, DOI 10.1109/IEEESTD.2024.11090080,
<https://ieeexplore.ieee.org/document/11090080>.
[IEEE802.15.4]
IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE
Std 802.15.4-2015, DOI 10.1109/IEEESTD.2016.7460875,
<https://doi.org/10.1109/IEEESTD.2016.7460875>.
[IEEE802.1AS]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks -- Timing and Synchronization for Time-Sensitive
Applications", IEEE Std 802.1AS-2020,
DOI 10.1109/IEEESTD.2020.9121845,
<https://doi.org/10.1109/IEEESTD.2020.9121845>.
[IEEE802.1CB]
IEEE, "IEEE Standard for Local and metropolitan area
networks -- Frame Replication and Elimination for
Reliability", IEEE Std 802.1CB-2017,
DOI 10.1109/IEEEStd2017.8091139, 2017,
<https://ieeexplore.ieee.org/document/8091139>.
[IEEE802.1Qat]
IEEE, "IEEE Standard for Local and metropolitan area
networks -- Virtual Bridged Local Area Networks Amendment
14: Stream Reservation Protocol (SRP)", IEEE Std 802.1Qat-
2010, DOI 10.1109/IEEESTD.2010.5594972,
<https://doi.org/10.1109/IEEESTD.2010.5594972>.
[IEEE802.1Qbv]
IEEE, "IEEE Standard for Local and metropolitan area
networks -- Bridges and Bridged Networks - Amendment 25:
Enhancements for Scheduled Traffic", IEEE Std 802.1Qbv-
2015, DOI 10.1109/IEEESTD.2016.8613095, 2016,
<https://doi.org/10.1109/IEEESTD.2016.8613095>.
[IEEE802.1Qcc]
IEEE, "IEEE Standard for Local and metropolitan area
networks -- Bridges and Bridged Networks -- Amendment 31:
Stream Reservation Protocol (SRP) Enhancements and
Performance Improvements", IEEE Std 802.1Qcc-2018,
DOI 10.1109/IEEESTD.2018.8514112,
<https://ieeexplore.ieee.org/document/8514112>.
[IEEE802.1TSN]
IEEE 802.1 Working Group, "Time-Sensitive Networking Task
Group", <http://www.ieee802.org/1/pages/tsn.html>.
[IEEE802.3]
IEEE, "IEEE Standard for Ethernet", IEEE Std 802.3-2022,
DOI 10.1109/IEEESTD.2022.9844436,
<https://ieeexplore.ieee.org/document/9844436>.
[IEEE_doc_11-18-2009-06]
IEEE, "802.11 Real-Time Applications (RTA) Topic Interest
Group (TIG) Report", November 2018,
<https://mentor.ieee.org/802.11/dcn/18/11-18-2009-06-0rta-
rta-report-draft.docx>.
[IMT2020] ITU, "IMT-2020 (a.k.a. "5G")", <https://www.itu.int/en/
ITU-R/study-groups/rsg5/rwp5d/imt-2020/Pages/
default.aspx>.
[ISA100.11a]
ISA, "ISA100 Wireless", ANSI/ISA-100.11a-2011 (IEC 26743),
<https://isa100wci.org/about-isa100-wireless?_gl=1*19xrxgo
*_up*MQ..*_ga*NDczNjkxOTQ1LjE3NjI0NjQ2NDk.*_ga_L2KSW4EHCS*
czE3NjI0NjQ2NDkkbzEkZzEkdDE3NjI0NjQ3MzQkajYwJGwwJGgw>.
[MAE18] Maeurer, N. and A. Bilzhause, "A Cybersecurity
Architecture for the L-band Digital Aeronautical
Communications System (LDACS)", 2018 IEEE/AIAA 37th
Digital Avionics Systems Conference (DASC), pp. 1-10,
DOI 10.1109/DASC.2018.8569878, 2018,
<https://doi.org/10.1109/DASC.2018.8569878>.
[MAE191] Maeurer, N. and C. Schmitt, "Towards Successful
Realization of the LDACS Cybersecurity Architecture: An
Updated Datalink Security Threat- and Risk Analysis",
Integrated Communications, Navigation and Surveillance
Conference (ICNS), pp. 1-13,
DOI 10.1109/ICNSURV.2019.8735139, 2019,
<https://doi.org/10.1109/ICNSURV.2019.8735139>.
[MAE192] Maeurer, N., Graeupl, T., and C. Schmitt, "Evaluation of
the LDACS Cybersecurity Implementation", IEEE/AIAA 38th
Digital Avionics Systems Conference (DASC), pp. 1-10,
DOI 10.1109/DASC43569.2019.9081786, September 2019,
<https://doi.org/10.1109/DASC43569.2019.9081786>.
[MAE20] Maeurer, N., Graeupl, T., Gentsch, C., and C. Schmitt,
"Comparing Different Diffie-Hellman Key Exchange Flavors
for LDACS", AIAA/IEEE 39th Digital Avionics Systems
Conference (DASC), pp. 1-10,
DOI 10.1109/DASC50938.2020.9256746, 2020,
<https://doi.org/10.1109/DASC50938.2020.9256746>.
[Nitsche_2015]
Nitsche, T., Cordeiro, C., Flores, A. B., Knightly, E. W.,
Perahia, E., and J. C. Widmer, "IEEE 802.11ad: directional
60 GHz communication for multi-Gigabit-per-second Wi-Fi",
IEEE Communications Magazine, vol. 52, no. 12, pp.
132-141, DOI 10.1109/MCOM.2014.6979964, December 2014,
<https://doi.org/10.1109/MCOM.2014.6979964>.
[NSA-EXT] Koutsiamanis, R., Ed., Papadopoulos, G. Z., Montavont, N.,
and P. Thubert, "Common Ancestor Objective Function and
Parent Set DAG Metric Container Extension", Work in
Progress, Internet-Draft, draft-ietf-roll-nsa-extension-
13, 7 July 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-roll-nsa-extension-13>.
[PCE] IETF, "Path Computation Element",
<https://datatracker.ietf.org/doc/charter-ietf-pce/>.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291,
DOI 10.17487/RFC6291, June 2011,
<https://www.rfc-editor.org/info/rfc6291>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>.
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
and D. Barthel, "Routing Metrics Used for Path Calculation
in Low-Power and Lossy Networks", RFC 6551,
DOI 10.17487/RFC6551, March 2012,
<https://www.rfc-editor.org/info/rfc6551>.- [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. Weingarten, "An Overview of Operations, Administration, and Maintenance (OAM) Tools", RFC 7276, DOI 10.17487/RFC7276, June 2014,
<https://www.rfc-editor.org/info/rfc7276>. ๐ - [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. ๐ - [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>. ๐ฆ - [RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH Operation Sublayer (6top) Protocol (6P)", RFC 8480, DOI 10.17487/RFC8480, November 2018,
<https://www.rfc-editor.org/info/rfc8480>. ๐ธ - [RFC9023] Varga, B., Ed., Farkas, J., Malis, A., and S. Bryant, "Deterministic Networking (DetNet) Data Plane: IP over IEEE 802.1 Time-Sensitive Networking (TSN)", RFC 9023, DOI 10.17487/RFC9023, June 2021,
<https://www.rfc-editor.org/info/rfc9023>. โฐ - [RFC9030] Thubert, P., Ed., "An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", RFC 9030, DOI 10.17487/RFC9030, May 2021,
<https://www.rfc-editor.org/info/rfc9030>. ๐ง - [RFC9033] Chang, T., Ed., Vuฤiniฤ, M., Vilajosana, X., Duquennoy, S., and D. Dujovne, "6TiSCH Minimal Scheduling Function (MSF)", RFC 9033, DOI 10.17487/RFC9033, May 2021,
<https://www.rfc-editor.org/info/rfc9033>. ๐ - [RFC9262] Eckert, T., Ed., Menth, M., and G. Cauchie, "Tree Engineering for Bit Index Explicit Replication (BIER-TE)", RFC 9262, DOI 10.17487/RFC9262, October 2022,
<https://www.rfc-editor.org/info/rfc9262>. ๐ณ - [RFC9372] Mรคurer, N., Ed., Grรคupl, T., Ed., and C. Schmitt, Ed., "L-Band Digital Aeronautical Communications System (LDACS)", RFC 9372, DOI 10.17487/RFC9372, March 2023,
<https://www.rfc-editor.org/info/rfc9372>. โ๏ธ - [RFC9914] Thubert, P., Ed., Jadhav, R.A., and M. Richardson, "Root-Initiated Routing State in the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 9914, DOI 10.17487/RFC9914, April 2026,
<https://www.rfc-editor.org/info/rfc9914>. ๐ - [RIH18] Rihacek, C., Haindl, B., Fantappie, P., Pierattelli, S., Grรคupl, T., Schnell, M., and N. Fistas, "L-band Digital Aeronautical Communications System (LDACS) Activities in SESAR2020", 2018 Integrated Communications, Navigation, Surveillance Conference (ICNS), pp. 4A1-1-4A1-8, DOI 10.1109/ICNSURV.2018.8384880, April 2018,
<https://doi.org/10.1109/ICNSURV.2018.8384880>. ๐ฅ - [RP210854] 3GPP, "Revised WID: Enhanced Industrial Internet of Things (IoT) and ultra-reliable and low latency communication (URLLC) support for NR", 3GPP RP-210854, March 2021,
<https://www.3gpp.org/ftp/tsg_ran/TSG_RAN/TSGR_91e/Docs/RP-210854.zip>. ๐ญ - [SAJ14] Haindl, B., Meser, J., Sajatovic, M., Muller, S., Arthaber, H., Faseth, T., and M. Zaisberger, "LDACS1 conformance and compatibility assessment", 2014 IEEE/AIAA 33rd Digital Avionics Systems Conference (DASC), pp. 3B3-1-3B3-11, DOI 10.1109/DASC.2014.6979447, October 2014,
<https://doi.org/10.1109/DASC.2014.6979447>. ๐ฉ๏ธ - [SCH08] Schnell, M., Brandes, S., Gligorevic, S., Rokitansky, C.-H., Ehammer, M., Graeupl, T., Rihacek, C., and M. Sajatovic, "B-AMC - Broadband Aeronautical Multi-carrier Communications", 2008 Integrated Communications, Navigation and Surveillance Conference, pp. 1-12, DOI 10.1109/ICNSURV.2008.4559173, 2008,
<https://doi.org/10.1109/ICNSURV.2008.4559173>. ๐ก - [SCH14] Schnell, M., Epple, U., Shutin, D., and N. Schneckenburger, "LDACS: Future Aeronautical Communications for Air- Traffic Management", IEEE Communications Magazine, vol. 52, no. 5, pp. 104-110, DOI 10.1109/MCOM.2014.6815900, May 2014,
<https://doi.org/10.1109/MCOM.2014.6815900>. ๐ผ - [SCH19] German Aerospace Center (DLR), "DLR tests digital communications technologies combined with additional navigation functions for the first time", 27 March 2019,
<https://www.dlr.de/en/latest/news/2019/01/20190327_modern-technology-for-the-flight-deck>. ๐งญ - [SP211634] 3GPP, "Study on 5G Timing Resiliency, TSC, and URLLC enhancements", 3GPP SP-211634, December 2021,
<https://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_94E_Electronic_2021_12/Docs/SP-211634.zip>. โฑ๏ธ - [Sudhakaran2021] Sudhakaran, S., Montgomery, K., Kashef, M., Cavalcanti, D., and R. Candell, "Wireless Time Sensitive Networking for Industrial Collaborative Robotic Workcells", 2021 17th IEEE International Conference on Factory Communication Systems (WFCS), pp. 91-94, DOI 10.1109/WFCS46889.2021.9483447, 2021,
<https://ieeexplore.ieee.org/abstract/document/9483447>. ๐ค - [SYSTOVER5G] 3GPP, "5G System Overview", 8 August 2022,
<https://www.3gpp.org/technologies/5g-system-overview>. ๐ถ - [TiSCH] IETF, "IPv6 over the TSCH mode over 802.15.4e",
<https://datatracker.ietf.org/doc/charter-ietf-6tisch/>. ๐ - [TR22804] 3GPP, "Study on Communication for Automation in Vertical domains (CAV)", 3GPP TS 22.804,
<https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3187>. ๐๏ธ - [TR2370046] 3GPP, "Study on 5GS Deterministic Networking (DetNet) interworking", 3GPP TR 23.700-46,
<https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3994>. ๐ - [TR37910] 3GPP, "Study on self evaluation towards IMT-2020 submission", 3GPP TR 37.910,
<https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3190>. ๐ - [TR38824] 3GPP, "Study on physical layer enhancements for NR ultra-reliable and low latency case (URLLC)", 3GPP TR 38.824,
<https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3498>. ๐ซ - [TR38825] 3GPP, "Study on NR industrial Internet of Things (IoT)", 3GPP TR 38.825,
<https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3492>. ๐ ๏ธ - [TS22104] 3GPP, "Service requirements for cyber-physical control applications in vertical domains", 3GPP TS 22.104,
<https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3528>. ๐ฏ - [TS23501] 3GPP, "System architecture for the 5G System (5GS)", 3GPP TS 23.501,
<https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3144>. ๐๏ธ - [TS38300] 3GPP, "NR; NR and NG-RAN Overall description; Stage-2", 3GPP TS 38.300,
<https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3191>. ๐บ๏ธ - [TSN5G] 5G-ACIA, "Integration of 5G with Time-Sensitive Networking for Industrial Communications", 5G-ACIA White Paper,
<https://5g-acia.org/whitepapers/integration-of-5g-with-time-sensitive-networking-for-industrial-communications>. ๐ง - [vilajosana21] Vilajosana, X., Watteyne, T., Chang, T., Vucinic, M., Duquennoy, S., and P. Thubert, "IETF 6TiSCH: A Tutorial", Communications Surveys and Tutorials, IEEE Communications Society, HAL ID: hal-02420974, DOI 10.1109/COMST.2019.2939407, December 2019,
<https://inria.hal.science/hal-02420974/file/IETF_6TiSCH__A_Tutorial__17099609gkvsxdpffdvc_%20(1).pdf>. ๐ - [WFA] "Wi-Fi Alliance",
<https://www.wi-fi.org>. ๐ - [WirelessHART] FieldComm Group, "WirelessHART",
<https://www.fieldcommgroup.org/technologies/wirelesshart>. ๐
Acknowledgments โจ
Many thanks to the participants of the RAW WG, where a lot of the work discussed in this document happened, and to Malcolm Smith for his review of the section on IEEE 802.11. ๐ซถ Special thanks for post directorate and IESG reviewers Roman Danyliw, Victoria Pritchard, Donald Eastlake, Mohamed Boucadair, Jiankang Yao, Shivan Kaul Sahib, Mallory Knodel, Ron Bonica, Ketan Talaulikar, รric Vyncke, and Carlos J. Bernardos. ๐ They really showed up for this one, bestie. ๐
Contributors ๐
This document pulls together articles from authors who are specialists in each technology, which is lowkey the best part. ๐ง Beyond the main authors listed on the front page, the following contributors proposed additional text and refinements that improved the document. ๐
- Georgios Z. Papadopoulos contributed to Section 5 ("IEEE 802.15.4 Time-Slotted Channel Hopping (TSCH)"). ๐
- Nils Maeurer and Thomas Graeupl contributed to Section 7 ("L-Band Digital Aeronautical Communications System (LDACS)"). โ๏ธ
- Torsten Dudda, Alexey Shapin, and Sara Sandberg contributed to Section 6 ("5G"). ๐ถ
- Rocco Di Taranto contributed to Section 4 ("IEEE 802.11"). ๐
- Rute Sofia contributed to Section 1 ("Introduction") and Section 2 ("Terminology"). ๐
Authors' Addresses ๐ฆ
Pascal Thubert (editor)
Independent
06330 Roquefort-les-Pins
France
Email: pascal.thubert@gmail.com
Dave Cavalcanti
Intel Corporation
2111 NE 25th Ave
Hillsboro, OR 97124
United States of America
Phone: 503 712 5566
Email: dave.cavalcanti@intel.com
Xavier Vilajosana
Universitat Oberta de Catalunya
156 Rambla Poblenou
08018 Barcelona Catalonia
Spain
Email: xvilajosana@uoc.edu
Corinna Schmitt
Research Institute CODE, UniBw M
Werner-Heisenberg-Weg 39
85577 Neubiberg
Germany
Email: corinna.schmitt@unibw.de
Janos Farkas
Ericsson
Budapest
Magyar tudosok korutja 11
1117
Hungary
Email: janos.farkas@ericsson.com๐ฆ where this page comes from
- ietf: rfc9913 2026-04
- ๐ girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms