| rfc9913v1.txt | rfc9913.txt | |||
|---|---|---|---|---|
| Internet Engineering Task Force (IETF) P. Thubert, Ed. | Internet Engineering Task Force (IETF) P. Thubert, Ed. | |||
| Request for Comments: 9913 | Request for Comments: 9913 Independent | |||
| Category: Informational D. Cavalcanti | Category: Informational D. Cavalcanti | |||
| ISSN: 2070-1721 Intel | ISSN: 2070-1721 Intel | |||
| X. Vilajosana | X. Vilajosana | |||
| Universitat Oberta de Catalunya | Universitat Oberta de Catalunya | |||
| C. Schmitt | C. Schmitt | |||
| Research Institute CODE, UniBw M | Research Institute CODE, UniBw M | |||
| J. Farkas | J. Farkas | |||
| Ericsson | Ericsson | |||
| February 2026 | February 2026 | |||
| Reliable and Available Wireless (RAW) Technologies | Reliable and Available Wireless (RAW) Technologies | |||
| Abstract | Abstract | |||
| This document surveys the short- and middle-range radio technologies | This document surveys the short- and middle-range radio technologies | |||
| over which providing a Deterministic Networking (DetNet) / Reliable | over which providing Deterministic Networking (DetNet), and more | |||
| and Available Wireless (RAW) service is suitable, presents the | specifically, Reliable and Available Wireless (RAW) service is | |||
| characteristics that RAW may leverage, and explores the applicability | suitable. It also presents the characteristics that RAW may leverage | |||
| of the technologies to carry deterministic flows, as of the time of | and explores the applicability of the technologies to carry | |||
| publication. The studied technologies are Wi-Fi 6/7, Time-Slotted | deterministic flows, as of the time of publication. The studied | |||
| Channel Hopping (TSCH), 3GPP 5G, and L-band Digital Aeronautical | technologies are Wi-Fi 6/7, Time-Slotted Channel Hopping (TSCH), 3GPP | |||
| Communications System (LDACS). | 5G, and L-band Digital Aeronautical Communications System (LDACS). | |||
| Status of This Memo | Status of This Memo | |||
| This document is not an Internet Standards Track specification; it is | This document is not an Internet Standards Track specification; it is | |||
| published for informational purposes. | published for informational purposes. | |||
| This document is a product of the Internet Engineering Task Force | This document is a product of the Internet Engineering Task Force | |||
| (IETF). It represents the consensus of the IETF community. It has | (IETF). It represents the consensus of the IETF community. It has | |||
| received public review and has been approved for publication by the | received public review and has been approved for publication by the | |||
| Internet Engineering Steering Group (IESG). Not all documents | Internet Engineering Steering Group (IESG). Not all documents | |||
| skipping to change at line 66 ¶ | skipping to change at line 66 ¶ | |||
| in the Revised BSD License. | in the Revised BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction | 1. Introduction | |||
| 2. Terminology | 2. Terminology | |||
| 3. Towards Reliable and Available Wireless Networks | 3. Towards Reliable and Available Wireless Networks | |||
| 3.1. Scheduling for Reliability | 3.1. Scheduling for Reliability | |||
| 3.2. Diversity for Availability | 3.2. Diversity for Availability | |||
| 3.3. Benefits of Scheduling | 3.3. Benefits of Scheduling | |||
| 4. IEEE 802.11 | 4. IEEE 802.11 Wireless Local Area Networks (WLAN) | |||
| 4.1. Provenance and Documents | 4.1. Provenance and Documents | |||
| 4.2. 802.11ax High Efficiency (HE) | 4.2. 802.11ax High Efficiency (HE) | |||
| 4.2.1. General Characteristics | 4.2.1. General Characteristics | |||
| 4.2.2. Applicability to Deterministic Flows | 4.2.2. Applicability to Deterministic Flows | |||
| 4.3. 802.11be Extreme High Throughput (EHT) | 4.3. 802.11be Extreme High Throughput (EHT) | |||
| 4.3.1. General Characteristics | 4.3.1. General Characteristics | |||
| 4.3.2. Applicability to Deterministic Flows | 4.3.2. Applicability to Deterministic Flows | |||
| 4.4. 802.11ad and 802.11ay (mmWave Operation) | 4.4. 802.11ad and 802.11ay (mmWave Operation) | |||
| 4.4.1. General Characteristics | 4.4.1. General Characteristics | |||
| 4.4.2. Applicability to Deterministic Flows | 4.4.2. Applicability to Deterministic Flows | |||
| skipping to change at line 136 ¶ | skipping to change at line 136 ¶ | |||
| wired lower-layer technologies such as Time-Sensitive Networking | wired lower-layer technologies such as Time-Sensitive Networking | |||
| (TSN) as defined by IEEE 802.1 and IEEE 802.3. | (TSN) as defined by IEEE 802.1 and IEEE 802.3. | |||
| The Reliable and Available Wireless (RAW) architecture [RFC9912] | The Reliable and Available Wireless (RAW) architecture [RFC9912] | |||
| extends the DetNet architecture [RFC8655] to adapt to the specific | extends the DetNet architecture [RFC8655] to adapt to the specific | |||
| challenges of the wireless medium, in particular, intermittently | challenges of the wireless medium, in particular, intermittently | |||
| lossy connectivity, by optimizing the use of diversity and | lossy connectivity, by optimizing the use of diversity and | |||
| multipathing. [RFC9912] defines the concepts of reliability and | multipathing. [RFC9912] defines the concepts of reliability and | |||
| availability that are used in this document. In turn, this document | availability that are used in this document. In turn, this document | |||
| presents wireless technologies with capabilities, such as time | presents wireless technologies with capabilities, such as time | |||
| synchronization and scheduling of transmission, that would make RAW/ | synchronization and scheduling of transmission, that would make RAW | |||
| DetNet operations possible over such media. The technologies studied | operations possible over such media. The technologies studied in | |||
| in this document were identified in the charter during the RAW | this document were identified in the charter during the RAW Working | |||
| Working Group (WG) formation and inherited by DetNet (when the WG | Group (WG) formation and inherited by DetNet (when the WG picked up | |||
| picked up the work on RAW). | the work on RAW). | |||
| Making wireless reliable and available is even more challenging than | Making wireless reliable and available is even more challenging than | |||
| it is with wires, due to the numerous causes of radio transmission | it is with wires, due to the numerous causes of radio transmission | |||
| losses that add up to the congestion losses and the delays caused by | losses that add up to the congestion losses and the delays caused by | |||
| overbooked shared resources. | overbooked shared resources. | |||
| RAW, like DetNet, needs and leverages lower-layer capabilities such | RAW, like DetNet, needs and leverages lower-layer capabilities such | |||
| as time synchronization and traffic shapers. To balance the adverse | as time synchronization and traffic shapers. To balance the adverse | |||
| effects of the radio transmission losses, RAW leverages additional | effects of the radio transmission losses, RAW leverages additional | |||
| lower-layer capabilities, some of which may be specific or at least | lower-layer capabilities, some of which may be specific or at least | |||
| skipping to change at line 182 ¶ | skipping to change at line 182 ¶ | |||
| RAW defines a network-layer control loop that optimizes the use of | RAW defines a network-layer control loop that optimizes the use of | |||
| links with constrained spectrum and energy while maintaining the | links with constrained spectrum and energy while maintaining the | |||
| expected connectivity properties, typically reliability and latency. | expected connectivity properties, typically reliability and latency. | |||
| The control loop involves communication monitoring through | The control loop involves communication monitoring through | |||
| Operations, Administration, and Maintenance (OAM); path control | Operations, Administration, and Maintenance (OAM); path control | |||
| through a Path Computation Element (PCE) and a runtime distributed | through a Path Computation Element (PCE) and a runtime distributed | |||
| Path Selection Engine (PSE); and extended Packet Replication, | Path Selection Engine (PSE); and extended Packet Replication, | |||
| Elimination, and Ordering Functions (PREOF). | Elimination, and Ordering Functions (PREOF). | |||
| This document surveys the short- and middle-range radio technologies | This document surveys the short- and middle-range radio technologies | |||
| over which providing a DetNet/RAW service is suitable, presents the | over which providing a RAW service is suitable, presents the | |||
| characteristics that RAW may leverage, and explores the applicability | characteristics that RAW may leverage, and explores the applicability | |||
| of the technologies to carry deterministic flows. The studied | of the technologies to carry deterministic flows. The studied | |||
| technologies are Wi-Fi 6/7, Time-Slotted Channel Hopping (TSCH), 3GPP | technologies are Wi-Fi 6/7, Time-Slotted Channel Hopping (TSCH), 3GPP | |||
| 5G, and L-band Digital Aeronautical Communications System (LDACS). | 5G, and L-band Digital Aeronautical Communications System (LDACS). | |||
| The purpose of this document is to support and enable work on the | The purpose of this document is to support and enable work on the | |||
| these (and possibly other similar compatible technologies) at the | these (and possibly other similar compatible technologies) at the | |||
| IETF, specifically in the DetNet Working Group working on RAW. | IETF, specifically in the DetNet Working Group working on RAW. | |||
| This document surveys existing networking technology; it does not | This document surveys existing networking technology; it does not | |||
| define protocol behaviors or operational practices. The IETF | define protocol behaviors or operational practices. The IETF | |||
| skipping to change at line 308 ¶ | skipping to change at line 308 ¶ | |||
| * Scheduling plays a critical role in saving energy. In the | * Scheduling plays a critical role in saving energy. In the | |||
| Internet of Things (IoT), energy is the foremost concern, and | Internet of Things (IoT), energy is the foremost concern, and | |||
| synchronizing the sender and listener enables always maintaining | synchronizing the sender and listener enables always maintaining | |||
| them in deep sleep when there is no scheduled transmission. This | them in deep sleep when there is no scheduled transmission. This | |||
| avoids idle listening and long preambles, and it enables long | avoids idle listening and long preambles, and it enables long | |||
| sleep periods between traffic and resynchronization, allowing | sleep periods between traffic and resynchronization, allowing | |||
| battery-operated nodes to operate in a mesh topology for multiple | battery-operated nodes to operate in a mesh topology for multiple | |||
| years. | years. | |||
| 4. IEEE 802.11 | 4. IEEE 802.11 Wireless Local Area Networks (WLAN) | |||
| In recent years, the evolution of the IEEE Std 802.11 standard has | In recent years, the evolution of the IEEE Std 802.11 standard has | |||
| taken a new direction, emphasizing improved reliability and reduced | taken a new direction, emphasizing improved reliability and reduced | |||
| latency in addition to minor improvements in speed, to enable new | latency in addition to minor improvements in speed, to enable new | |||
| fields of application such as industrial IoT and Virtual Reality | fields of application such as industrial IoT and Virtual Reality | |||
| (VR). | (VR). | |||
| Leveraging IEEE Std 802.11, the Wi-Fi Alliance [WFA] delivered Wi-Fi | 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 | 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- | in due time at fast rates. Still, as with any radio technology, Wi- | |||
| Fi is sensitive to frame loss, which can only be combated with the | Fi is sensitive to frame loss, which can only be combated with the | |||
| maximum use of diversity in space, time, channel, and even | maximum use of diversity in space, time, channel, and even | |||
| technology. | technology. | |||
| In parallel, the Avnu Alliance [Avnu], which focuses on applications | In parallel, the Avnu Alliance [Avnu], which focuses on applications | |||
| of TSN for real-time data, formed a workgroup for uses case with TSN | of TSN for real-time data, formed a workgroup to investigate TSN | |||
| capabilities over wireless, leveraging both 3GPP and IEEE Std 802.11 | capabilities over wireless, leveraging both 3GPP and IEEE Std 802.11 | |||
| standards. | standards. | |||
| To achieve the latter, the reliability must be handled at an upper | To achieve the latter, the reliability must be handled at an upper | |||
| layer that can select Wi-Fi and other wired or wireless technologies | layer that can select Wi-Fi and other wired or wireless technologies | |||
| for parallel transmissions. This is where RAW comes into play. | for parallel transmissions. This is where RAW comes into play. | |||
| This section surveys the IEEE 802.11 features that are most relevant | This section surveys the IEEE 802.11 features that are most relevant | |||
| to RAW, noting that there are a great many more in the specification, | to RAW, noting that there are a great many more in the specification, | |||
| some of which may also possibly be of interest for a RAW solution. | some of which may also possibly be of interest for a RAW solution. | |||
| skipping to change at line 411 ¶ | skipping to change at line 411 ¶ | |||
| * Congestion control: IEEE Std 802.11-2016 Admission Control; WFA | * Congestion control: IEEE Std 802.11-2016 Admission Control; WFA | |||
| Admission Control | Admission Control | |||
| * Security: WFA Wi-Fi Protected Access, WPA2, and WPA3 | * Security: WFA Wi-Fi Protected Access, WPA2, and WPA3 | |||
| * Interoperating with IEEE 802.1Q bridges: IEEE Std 802.11-2020 | * Interoperating with IEEE 802.1Q bridges: IEEE Std 802.11-2020 | |||
| incorporating 802.11ak | incorporating 802.11ak | |||
| * Stream Reservation Protocol (part of [IEEE802.1Qat]): | * Stream Reservation Protocol (part of [IEEE802.1Qat]): | |||
| AIEEE802.11-2016 | IEEE802.11-2016 | |||
| * Scheduled channel access: IEEE 802.11ad enhancements for very high | * Scheduled channel access: IEEE 802.11ad enhancements for very high | |||
| throughput in the 60 GHz band [IEEE802.11ad] | throughput in the 60 GHz band [IEEE802.11ad] | |||
| * 802.11 Real-Time Applications: Topic Interest Group (TIG) | * 802.11 Real-Time Applications: Topic Interest Group (TIG) | |||
| ReportDoc [IEEE_doc_11-18-2009-06] | ReportDoc [IEEE_doc_11-18-2009-06] | |||
| In addition, major amendments being developed by the IEEE 802.11 | In addition, major amendments being developed by the IEEE 802.11 | |||
| Working Group include capabilities that can be used as the basis for | Working Group include capabilities that can be used as the basis for | |||
| providing more reliable and predictable wireless connectivity and | providing more reliable and predictable wireless connectivity and | |||
| skipping to change at line 440 ¶ | skipping to change at line 440 ¶ | |||
| The main 802.11ax, 802.11be, 802.11ad, and 802.11ay capabilities and | The main 802.11ax, 802.11be, 802.11ad, and 802.11ay capabilities and | |||
| their relevance to RAW are discussed in the remainder of this | their relevance to RAW are discussed in the remainder of this | |||
| section. As P802.11bn is still in early stages of development, its | section. As P802.11bn is still in early stages of development, its | |||
| capabilities are not included in this document. | capabilities are not included in this document. | |||
| 4.2. 802.11ax High Efficiency (HE) | 4.2. 802.11ax High Efficiency (HE) | |||
| 4.2.1. General Characteristics | 4.2.1. General Characteristics | |||
| The next generation Wi-Fi (Wi-Fi 6) is based on the IEEE Std 802.11ax | The next generation Wi-Fi (Wi-Fi 6) is based on the IEEE802.11ax | |||
| amendment [IEEE802.11ax], which includes specific capabilities to | amendment [IEEE802.11ax], which includes specific capabilities to | |||
| increase efficiency, control and reduce latency. Some of these | increase efficiency and control and to reduce latency. Some of these | |||
| features include higher-order 1024-QAM modulation, support for uplink | features include higher-order 1024-QAM modulation, support for uplink | |||
| Multi-User - Multiple Input Multiple Output (MU-MIMO), Orthogonal | (UL) Multi-User - Multiple Input Multiple Output (MU-MIMO), | |||
| Frequency-Division Multiple Access (OFDMA), trigger-based access, and | Orthogonal Frequency-Division Multiple Access (OFDMA), trigger-based | |||
| Target Wake Time (TWT) for enhanced power savings. The OFDMA mode | access, and Target Wake Time (TWT) for enhanced power savings. The | |||
| and trigger-based access enable the Access Point (AP), after | OFDMA mode and trigger-based access enable the Access Point (AP), | |||
| reserving the channel using the clear channel assessment procedure | after reserving the channel using the clear channel assessment | |||
| for a given duration, to schedule multi-user transmissions, which is | procedure for a given duration, to schedule multi-user transmissions, | |||
| a key capability required to increase latency predictability and | which is a key capability required to increase latency predictability | |||
| reliability for time-sensitive flows. 802.11ax can operate in up to | and reliability for time-sensitive flows. 802.11ax can operate in up | |||
| 160 MHz channels, and it includes support for operation in the new 6 | to 160 MHz channels, and it includes support for operation in the new | |||
| GHz band, which has been open to unlicensed use by the Federal | 6 GHz band, which has been open to unlicensed use by the Federal | |||
| Communications Commission (FCC) and other regulatory agencies | Communications Commission (FCC) and other regulatory agencies | |||
| worldwide. | worldwide. | |||
| 4.2.1.1. Multi-User OFDMA and Trigger-Based Scheduled Access | 4.2.1.1. Multi-User OFDMA and Trigger-Based Scheduled Access | |||
| 802.11ax introduced an OFDMA mode in which multiple users can be | 802.11ax introduced an OFDMA mode in which multiple users can be | |||
| scheduled across the frequency domain. In this mode, the Access | scheduled across the frequency domain. In this mode, the Access | |||
| Point (AP) can initiate multi-user uplink (UL) transmissions in the | Point (AP) can initiate multi-user UL transmissions in the same PHY | |||
| same PHY Protocol Data Unit (PPDU) by sending a trigger frame. This | Protocol Data Unit (PPDU) by sending a trigger frame. This | |||
| centralized scheduling capability gives the AP much more control of | centralized scheduling capability gives the AP much more control of | |||
| the channel in its Basic Service Set (BSS), and it can remove | the channel in its Basic Service Set (BSS), and it can remove | |||
| contention between associated stations for uplink transmissions, | contention between associated stations for UL transmissions, | |||
| therefore reducing the randomness caused by access based on Carrier | therefore reducing the randomness caused by access based on Carrier | |||
| Sense Multiple Access (CSMA) between stations within the same BSS. | Sense Multiple Access (CSMA) between stations within the same BSS. | |||
| The AP can also transmit simultaneously to multiple users in the | The AP can also transmit simultaneously to multiple users in the | |||
| downlink direction by using a downlink (DL) MU OFDMA PPDU. In order | downlink (DL) direction by using a DL MU OFDMA PPDU. In order to | |||
| to initiate a contention-free Transmission Opportunity (TXOP) using | initiate a contention-free Transmission Opportunity (TXOP) using the | |||
| the OFDMA mode, the AP still follows the typical listen-before-talk | OFDMA mode, the AP still follows the typical listen-before-talk | |||
| procedure to acquire the medium, which ensures interoperability and | procedure to acquire the medium, which ensures interoperability and | |||
| compliance with unlicensed band access rules. However, 802.11ax also | compliance with unlicensed band access rules. However, 802.11ax also | |||
| includes a Multi-User Enhanced Distributed Channel Access (MU-EDCA) | includes a Multi-User Enhanced Distributed Channel Access (MU-EDCA) | |||
| capability, which allows the AP to get higher channel access priority | capability, which allows the AP to get higher channel access priority | |||
| than other devices in its BSS. | than other devices in its BSS. | |||
| 4.2.1.2. Traffic Isolation via OFDMA Resource Management and Resource | 4.2.1.2. Traffic Isolation via OFDMA Resource Management and Resource | |||
| Unit Allocation | Unit Allocation | |||
| 802.11ax relies on the notion of an OFDMA Resource Unit (RU) to | 802.11ax relies on the notion of an OFDMA Resource Unit (RU) to | |||
| skipping to change at line 526 ¶ | skipping to change at line 526 ¶ | |||
| the underlying mechanism for supporting deterministic flows in a | the underlying mechanism for supporting deterministic flows in a | |||
| Local Area Network (LAN). The IEEE 802.11 Working Group has | Local Area Network (LAN). The IEEE 802.11 Working Group has | |||
| incorporated support for absolute time synchronization to extend the | incorporated support for absolute time synchronization to extend the | |||
| TSN 802.1AS protocol so that time-sensitive flows can experience | TSN 802.1AS protocol so that time-sensitive flows can experience | |||
| precise time synchronization when operating over 802.11 links. As | precise time synchronization when operating over 802.11 links. As | |||
| IEEE 802.11 and IEEE 802.1 TSN are both based on the IEEE 802 | IEEE 802.11 and IEEE 802.1 TSN are both based on the IEEE 802 | |||
| architecture, 802.11 devices can directly implement some TSN | architecture, 802.11 devices can directly implement some TSN | |||
| capabilities without the need for a gateway/translation protocol. | capabilities without the need for a gateway/translation protocol. | |||
| Basic features required for operation in a 802.1Q LAN are already | Basic features required for operation in a 802.1Q LAN are already | |||
| enabled for 802.11. Some TSN capabilities, such as 802.1Qbv, can | enabled for 802.11. Some TSN capabilities, such as 802.1Qbv, can | |||
| already operate over the existing 802.11 MAC SAP [Sudhakaran2021]. | already operate over the existing 802.11 MAC Service Access Point | |||
| Implementation and experimental results of TSN capabilities (802.1AS, | (SAP) [Sudhakaran2021]. Implementation and experimental results of | |||
| 802.1Qbv, and 802.1CB) extended over standard Ethernet and Wi-Fi | TSN capabilities (802.1AS, 802.1Qbv, and 802.1CB) extended over | |||
| devices have also been described in [Fang_2021]. Nevertheless, the | standard Ethernet and Wi-Fi devices have also been described in | |||
| IEEE 802.11 MAC/PHY could be extended to improve the operation of | [Fang_2021]. Nevertheless, the IEEE 802.11 MAC/PHY could be extended | |||
| IEEE 802.1 TSN features and achieve better performance metrics | to improve the operation of IEEE 802.1 TSN features and achieve | |||
| [Cavalcanti1287]. | better performance metrics [Cavalcanti1287]. | |||
| TSN capabilities supported over 802.11 (which also extends to | TSN capabilities supported over 802.11 (which also extends to | |||
| 802.11ax) include: | 802.11ax) include: | |||
| 1. 802.1AS-based time synchronization (other time synchronization | 1. 802.1AS-based time synchronization (other time synchronization | |||
| techniques may also be used) | techniques may also be used) | |||
| 2. Interoperating with IEEE 802.1Q bridges | 2. Interoperating with IEEE 802.1Q bridges | |||
| 3. Time-sensitive traffic stream classification | 3. Time-sensitive traffic stream classification | |||
| skipping to change at line 579 ¶ | skipping to change at line 579 ¶ | |||
| 4.2.2.2. Scheduling for Bounded Latency and Diversity | 4.2.2.2. Scheduling for Bounded Latency and Diversity | |||
| As discussed earlier, the OFDMA mode in [IEEE802.11ax] introduces the | As discussed earlier, the OFDMA mode in [IEEE802.11ax] introduces the | |||
| possibility of assigning different RUs (time/frequency resources) to | possibility of assigning different RUs (time/frequency resources) to | |||
| users within a PPDU. Several RU sizes are defined in the | users within a PPDU. Several RU sizes are defined in the | |||
| specification (26, 52, 106, 242, 484, and 996 subcarriers). In | specification (26, 52, 106, 242, 484, and 996 subcarriers). In | |||
| addition, the AP can also decide on a Modulation and Coding Scheme | addition, the AP can also decide on a Modulation and Coding Scheme | |||
| (MCS) and grouping of users within a given OFMDA PPDU. Such | (MCS) and grouping of users within a given OFMDA PPDU. Such | |||
| flexibility can be leveraged to support time-sensitive applications | flexibility can be leveraged to support time-sensitive applications | |||
| with bounded latency, especially in a managed network where stations | with bounded latency, especially: | |||
| can be configured to operate under the control of the AP, in a | ||||
| controlled environment (which contains only devices operating on the | * in a managed network where stations can be configured to operate | |||
| unlicensed band installed by the facility owner and where unexpected | under the control of the AP, | |||
| interference from other systems and/or radio access technologies only | ||||
| sporadically happens), or in a deployment where channel and link | * in a controlled environment (which contains only devices operating | |||
| redundancy is used to reduce the impact of unmanaged devices and | on the unlicensed band installed by the facility owner and where | |||
| interference. | 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, it is possible to achieve | When the network is lightly loaded, it is possible to achieve | |||
| latencies under 1 msec when Wi-Fi is operated in a contention-based | latencies under 1 ms when Wi-Fi is operated in a contention-based | |||
| mode (i.e., without OFDMA). It also has been shown that it is | mode (i.e., without OFDMA). It also has been shown that it is | |||
| possible to achieve 1 msec latencies in a controlled environment with | possible to achieve 1 ms latencies in a controlled environment with | |||
| higher efficiency when multi-user transmissions are used (enabled by | higher efficiency when multi-user transmissions are used (enabled by | |||
| OFDMA operation) [Cavalcanti_2019]. Obviously, there are latency, | OFDMA operation) [Cavalcanti_2019]. Obviously, there are latency, | |||
| reliability, and capacity trade-offs to be considered. For instance, | reliability, and capacity trade-offs to be considered. For instance, | |||
| smaller RUs result in longer transmission durations, which may impact | smaller RUs result in longer transmission durations, which may impact | |||
| the minimal latency that can be achieved, but the contention latency | the minimal latency that can be achieved, but the contention latency | |||
| and randomness elimination in an interference-free environment due to | and randomness elimination in an interference-free environment due to | |||
| multi-user transmission is a major benefit of the OFDMA mode. | multi-user transmission is a major benefit of the OFDMA mode. | |||
| The flexibility to dynamically assign RUs to each transmission also | The flexibility to dynamically assign RUs to each transmission also | |||
| enables the AP to provide frequency diversity, which can help | enables the AP to provide frequency diversity, which can help | |||
| skipping to change at line 630 ¶ | skipping to change at line 634 ¶ | |||
| contiguous spectrum | contiguous spectrum | |||
| 2. Multi-Link Operation (MLO) | 2. Multi-Link Operation (MLO) | |||
| 3. QoS enhancements to reduce latency and increase reliability | 3. QoS enhancements to reduce latency and increase reliability | |||
| 4.3.2. Applicability to Deterministic Flows | 4.3.2. Applicability to Deterministic Flows | |||
| The 802.11 Real-Time Applications (RTA) Topic Interest Group (TIG) | The 802.11 Real-Time Applications (RTA) Topic Interest Group (TIG) | |||
| provided detailed information on use cases, issues, and potential | provided detailed information on use cases, issues, and potential | |||
| solution directions to improve support for time-sensitive | solutions to improve support for time-sensitive applications in | |||
| applications in 802.11. The RTA TIG report [IEEE_doc_11-18-2009-06] | 802.11. The RTA TIG report [IEEE_doc_11-18-2009-06] was used as | |||
| was used as input to the 802.11be project scope. | input to the 802.11be project scope. | |||
| Improvements for worst-case latency, jitter, and reliability were the | Improvements for worst-case latency, jitter, and reliability were the | |||
| main topics identified in the RTA report, which were motivated by | main topics identified in the RTA report, which were motivated by | |||
| applications in gaming, industrial automation, robotics, etc. The | applications in gaming, industrial automation, robotics, etc. The | |||
| RTA report also highlighted the need to support additional TSN | RTA report also highlighted the need to support additional TSN | |||
| capabilities, such as time-aware (802.1Qbv) shaping and packet | capabilities, such as time-aware (802.1Qbv) shaping and packet | |||
| replication and elimination as defined in 802.1CB. | replication and elimination as defined in 802.1CB. | |||
| IEEE Std 802.11be builds on and enhances 802.11ax capabilities to | IEEE Std 802.11be builds on and enhances 802.11ax capabilities to | |||
| improve worst case latency and jitter. Some of the enhancement areas | improve worst case latency and jitter. Some of the enhancement areas | |||
| skipping to change at line 726 ¶ | skipping to change at line 730 ¶ | |||
| Remote Transducer Protocol (HART) and ISA100.11a. | Remote Transducer Protocol (HART) and ISA100.11a. | |||
| While the MAC/PHY standards enable the relatively slow rates used in | While the MAC/PHY standards enable the relatively slow rates used in | |||
| process control (typically in the order of 4-5 per second), the | process control (typically in the order of 4-5 per second), the | |||
| technology is not suited for the faster periods used in factory | technology is not suited for the faster periods used in factory | |||
| automation and motion control (1 to 10 ms). | automation and motion control (1 to 10 ms). | |||
| 5.1. Provenance and Documents | 5.1. Provenance and Documents | |||
| The IEEE 802.15.4 Task Group has been driving the development of low- | The IEEE 802.15.4 Task Group has been driving the development of low- | |||
| power, low-cost radio technology. The IEEE 802.15.4 physical layer | power, low-cost radio technology. The IEEE 802.15.4 Physical (PHY) | |||
| has been designed to support demanding low-power scenarios targeting | layer has been designed to support demanding low-power scenarios | |||
| the use of unlicensed bands, both the 2.4 GHz and sub-GHz Industrial, | targeting the use of unlicensed bands, both the 2.4 GHz and sub-GHz | |||
| Scientific and Medical (ISM) bands. This has imposed requirements in | Industrial, Scientific and Medical (ISM) bands. This has imposed | |||
| terms of frame size, data rate, and bandwidth to achieve reduced | requirements in terms of frame size, data rate, and bandwidth to | |||
| collision probability, reduced packet error rate, and acceptable | achieve reduced collision probability, reduced packet error rate, and | |||
| range with limited transmission power. The PHY layer supports frames | acceptable range with limited transmission power. The PHY layer | |||
| of up to 127 bytes. The Medium Access Control (MAC) sublayer | supports frames of up to 127 bytes. The Medium Access Control (MAC) | |||
| overhead is in the order of 10-20 bytes, leaving about 100 bytes to | sublayer overhead is in the order of 10-20 bytes, leaving about 100 | |||
| the upper layers. IEEE 802.15.4 uses spread spectrum modulation such | bytes to the upper layers. IEEE 802.15.4 uses spread spectrum | |||
| as the Direct Sequence Spread Spectrum (DSSS). | modulation such as the Direct Sequence Spread Spectrum (DSSS). | |||
| The Time-Slotted Channel Hopping (TSCH) mode was added to the 2015 | The Time-Slotted Channel Hopping (TSCH) mode was added to the 2015 | |||
| revision of the IEEE 802.15.4 standard [IEEE802.15.4]. TSCH is | revision of the IEEE 802.15.4 standard [IEEE802.15.4]. TSCH is | |||
| targeted at the embedded and industrial world, where reliability, | targeted at the embedded and industrial world, where reliability, | |||
| energy consumption, and cost drive the application space. | energy consumption, and cost drive the application space. | |||
| Building on IEEE 802.15.4, TSN on low-power constrained wireless | Building on IEEE 802.15.4, TSN on low-power constrained wireless | |||
| networks has been partially addressed by ISA100.11a [ISA100.11a] and | networks has been partially addressed by ISA100.11a [ISA100.11a] and | |||
| WirelessHART [WirelessHART]. Both technologies involve a central | WirelessHART [WirelessHART]. Both technologies involve a central | |||
| controller that computes redundant paths for industrial process | controller that computes redundant paths for industrial process | |||
| skipping to change at line 772 ¶ | skipping to change at line 776 ¶ | |||
| The protocol supports agreement on a schedule between neighbors, | The protocol supports agreement on a schedule between neighbors, | |||
| enabling distributed scheduling. | enabling distributed scheduling. | |||
| * 6P goes hand in hand with an SF, the policy that decides how to | * 6P goes hand in hand with an SF, the policy that decides how to | |||
| maintain cells and trigger 6P transactions. The Minimal | maintain cells and trigger 6P transactions. The Minimal | |||
| Scheduling Function (MSF) [RFC9033] is the default SF defined by | Scheduling Function (MSF) [RFC9033] is the default SF defined by | |||
| the 6TiSCH WG. | the 6TiSCH WG. | |||
| * With these mechanisms, 6TiSCH can establish Layer 2 links between | * With these mechanisms, 6TiSCH can establish Layer 2 links between | |||
| neighboring nodes and support best-effort traffic. The Routing | neighboring nodes and support best-effort traffic. The Routing | |||
| Protocol for Low-Power and Lossy Networks (RPL) [RFC8480] provides | Protocol for Low-Power and Lossy Networks (RPL) [RFC6550] provides | |||
| the routing structure, enabling the 6TiSCH devices to establish | the routing structure, enabling the 6TiSCH devices to establish | |||
| the links with well-connected neighbors, thus forming the acyclic | the links with well-connected neighbors, thus forming the acyclic | |||
| network graphs. | network graphs. | |||
| A Track at 6TiSCH is the application to wireless of the concept of a | In 6TiSCH, a Track is the concept of a recovery graph in the RAW | |||
| recovery graph in the RAW architecture. A Track can follow a simple | architecture applied to wireless. A Track can follow a simple | |||
| sequence of relay nodes, or it can be structured as a more complex | sequence of relay nodes, or it can be structured as a more complex | |||
| Destination-Oriented Directed Acyclic Graph (DODAG) to a unicast | Destination-Oriented Directed Acyclic Graph (DODAG) to a unicast | |||
| destination. Along a Track, 6TiSCH nodes reserve the resources to | destination. Along a Track, 6TiSCH nodes reserve the resources to | |||
| enable the efficient transmission of packets while aiming to optimize | enable the efficient transmission of packets while aiming to optimize | |||
| certain properties such as reliability and ensure small jitter or | certain properties such as reliability and ensure small jitter or | |||
| bounded latency. The Track structure enables Layer 2 forwarding | bounded latency. The Track structure enables Layer 2 forwarding | |||
| schemes, reducing the overhead of making routing decisions at Layer | schemes, reducing the overhead of making routing decisions at Layer | |||
| 3. | 3. | |||
| The 6TiSCH architecture [RFC9030] identifies different models to | The 6TiSCH architecture [RFC9030] identifies different models to | |||
| skipping to change at line 805 ¶ | skipping to change at line 809 ¶ | |||
| provided in this document. For example, [vilajosana21] provides a | provided in this document. For example, [vilajosana21] provides a | |||
| detailed description of the 6TiSCH protocols, how they are linked | detailed description of the 6TiSCH protocols, how they are linked | |||
| together, and how they are integrated with other standards like RPL | together, and how they are integrated with other standards like RPL | |||
| and 6Lo. | and 6Lo. | |||
| 5.2. General Characteristics | 5.2. General Characteristics | |||
| As a core technique in IEEE 802.15.4, TSCH splits time in multiple | As a core technique in IEEE 802.15.4, TSCH splits time in multiple | |||
| time slots that repeat over time. Each device has its own | time slots that repeat over time. Each device has its own | |||
| perspective of when the send or receive occurs and on which channel | perspective of when the send or receive occurs and on which channel | |||
| the transmission happens. This constitutes the device's Slotframe, | the transmission happens. This constitutes the device's slotframe, | |||
| where the channel and destination of a transmission by this device | where the channel and destination of a transmission by this device | |||
| are a function of time. The overall aggregation of all the | are a function of time. The overall aggregation of all the | |||
| Slotframes of all the devices constitutes a time/frequency matrix | slotframes of all the devices constitutes a time/frequency matrix | |||
| with at most one transmission in each cell of the matrix (see more in | with at most one transmission in each cell of the matrix (see more in | |||
| Section 5.3.1.4). | Section 5.3.1.4). | |||
| The IEEE 802.15.4 TSCH standard does not define any scheduling | The IEEE 802.15.4 TSCH standard does not define any scheduling | |||
| mechanism but only provides the architecture that establishes a | mechanism but only provides the architecture that establishes a | |||
| slotted structure that can be managed by a proper schedule. This | slotted structure that can be managed by a proper schedule. This | |||
| schedule represents the possible communications of a node with its | schedule represents the possible communications of a node with its | |||
| neighbors and is managed by a Scheduling Function such as the Minimal | neighbors and is managed by a Scheduling Function such as the Minimal | |||
| Scheduling Function (MSF) [RFC9033]. In MSF, each cell in the | Scheduling Function (MSF) [RFC9033]. In MSF, each cell in the | |||
| schedule is identified by its slotoffset and channeloffset | schedule is identified by its slotOffset and channelOffset | |||
| coordinates. A cell's timeslot offset indicates its position in | coordinates. A cell's timeSlot offset indicates its position in | |||
| time, relative to the beginning of the slotframe. A cell's channel | 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 | offset is an index that maps to a frequency at each iteration of the | |||
| slotframe. Each packet exchanged between neighbors happens within | slotframe. Each packet exchanged between neighbors happens within | |||
| one cell. The size of a cell is a timeslot duration, between 10 to | one cell. The size of a cell is a timeSlot duration, between 10 to | |||
| 15 milliseconds. An Absolute Slot Number (ASN) indicates the number | 15 milliseconds. An Absolute Slot Number (ASN) indicates the number | |||
| of slots elapsed since the network started. It increments at every | of slots elapsed since the network started. It increments at every | |||
| slot. This is a 5-byte counter that can support networks running for | slot. This is a 5-byte counter that can support networks running for | |||
| more than 300 years without wrapping (assuming a 10 ms timeslot). | more than 300 years without wrapping (assuming a 10 ms timeSlot). | |||
| Channel hopping provides increased reliability to multipath fading | Channel hopping provides increased reliability to multipath fading | |||
| and external interference. It is handled by TSCH through a channel- | and external interference. It is handled by TSCH through a channel- | |||
| hopping sequence referred to as macHopSeq in the IEEE 802.15.4 | hopping sequence referred to as macHopSeq in the IEEE 802.15.4 | |||
| specification. | specification. | |||
| The Time-Frequency Division Multiple Access provided by TSCH enables | The Time-Frequency Division Multiple Access provided by TSCH enables | |||
| the orchestration of traffic flows, spreading them in time and | the orchestration of traffic flows, spreading them in time and | |||
| frequency, and hence enabling an efficient management of the | frequency, and hence enabling an efficient management of the | |||
| bandwidth utilization. Such efficient bandwidth utilization can be | bandwidth utilization. Such efficient bandwidth utilization can be | |||
| combined with OFDM modulations also supported by the IEEE 802.15.4 | combined with OFDM modulations also supported by the IEEE 802.15.4 | |||
| standard [IEEE802.15.4] since the 2015 version. | standard [IEEE802.15.4] since the 2015 version. | |||
| TSCH networks operate in ISM bands in which the spectrum is shared by | TSCH networks operate in ISM bands in which the spectrum is shared by | |||
| different coexisting technologies. Regulations such as the FCC, | different coexisting technologies. Regulations such as the FCC, | |||
| ETSI, and ARIB impose duty cycle regulations to limit the use of the | ETSI, and ARIB impose duty cycle regulations to limit the use of the | |||
| bands, but interference may still constrain the probability of | bands, but interference may still constrain the probability of | |||
| delivering a packet. Part of these reliability challenges are | delivering a packet. Part of these reliability challenges are | |||
| addressed at the MAC introducing redundancy and diversity, thanks to | addressed at the MAC layer by introducing redundancy and diversity, | |||
| channel hopping, scheduling, and ARQ policies. Yet, the MAC layer | thanks to channel hopping, scheduling, and ARQ policies. Yet, the | |||
| operates with a 1-hop vision, being limited to local actions to | MAC layer operates with a 1-hop vision, being limited to local | |||
| mitigate underperforming links. | actions to mitigate underperforming links. | |||
| 5.2.1. 6TiSCH Tracks | 5.2.1. 6TiSCH Tracks | |||
| A Track in the 6TiSCH architecture [RFC9030] is the application to | In the 6TiSCH architecture [RFC9030], a Track is the concept of a | |||
| 6TiSCH networks of the concept of a protection path in the DetNet | DetNet architecture protection path applied to 6TiSCH networks. A | |||
| architecture [RFC8655]. A Track can be structured as a Destination- | Track can be structured as a Destination-Oriented Directed Acyclic | |||
| Oriented Directed Acyclic Graph (DODAG) to a destination for unicast | Graph (DODAG) to a destination for unicast traffic. Along a Track, | |||
| traffic. Along a Track, 6TiSCH nodes reserve the resources to enable | 6TiSCH nodes reserve the resources to enable the efficient | |||
| the efficient transmission of packets while aiming to optimize | transmission of packets while aiming to optimize certain properties | |||
| certain properties such as reliability and ensure small jitter or | such as reliability and ensure small jitter or bounded latency. The | |||
| bounded latency. The Track structure enables Layer 2 forwarding | Track structure enables Layer 2 forwarding schemes, reducing the | |||
| schemes, reducing the overhead of making routing decisions at Layer | overhead of making routing decisions at Layer 3. | |||
| 3. | ||||
| Serial Tracks can be understood as the concatenation of cells or | Serial Tracks can be understood as the concatenation of cells or | |||
| bundles along a routing path from a source towards a destination. | bundles along a routing path from a source towards a destination. | |||
| The serial Track concept is analogous to the circuit concept where | The serial Track concept is analogous to the circuit concept where | |||
| resources are chained into a multi-hop topology; see more in | resources are chained into a multi-hop topology; see more in | |||
| Section 5.2.1.2 on how that is used in the data plane to forward | Section 5.2.1.2 on how that is used in the data plane to forward | |||
| packets. | packets. | |||
| Whereas scheduling ensures reliable delivery in bounded time along | Whereas scheduling ensures reliable delivery in bounded time along | |||
| any Track, high availability requires the application of PREOF | any Track, high availability requires the application of PREOF | |||
| skipping to change at line 885 ¶ | skipping to change at line 888 ¶ | |||
| overall energy consumption in the network but significantly improves | overall energy consumption in the network but significantly improves | |||
| the availability of the network as well as the packet delivery ratio. | the availability of the network as well as the packet delivery ratio. | |||
| A Track may also branch off and rejoin, for the purpose of so-called | A Track may also branch off and rejoin, for the purpose of so-called | |||
| Packet Replication and Elimination (PRE), over non-congruent | Packet Replication and Elimination (PRE), over non-congruent | |||
| branches. PRE may be used to complement Layer 2 ARQ and receiver-end | branches. PRE may be used to complement Layer 2 ARQ and receiver-end | |||
| ordering to complete/extend the PREOF functions. This enables | ordering to complete/extend the PREOF functions. This enables | |||
| meeting industrial expectations of packet delivery within bounded | meeting industrial expectations of packet delivery within bounded | |||
| delay over a Track that includes wireless links, even when the Track | delay over a Track that includes wireless links, even when the Track | |||
| extends beyond the 6TiSCH network. | extends beyond the 6TiSCH network. | |||
| The RAW Track described in the RAW architecture [RFC9912] inherits | The RAW recovery graph described in the RAW architecture [RFC9912] | |||
| directly from that model. RAW extends the graph beyond a DODAG as | inherits directly from that model. RAW extends the graph beyond a | |||
| long as a given packet cannot loop within the Track. | DODAG as long as a given packet cannot loop within the Track. | |||
| +-----+ | +-----+ | |||
| | IoT | | | IoT | | |||
| | G/W | | | G/W | | |||
| +-----+ | +-----+ | |||
| ^ <---- Elimination | ^ <---- Elimination | |||
| | | | | | | |||
| Track branch | | | Track branch | | | |||
| +-------+ +--------+ Subnet backbone | +-------+ +--------+ Subnet backbone | |||
| | | | | | | |||
| skipping to change at line 967 ¶ | skipping to change at line 970 ¶ | |||
| [RFC9030]. The DetNet case relates to the Track Forwarding operation | [RFC9030]. The DetNet case relates to the Track Forwarding operation | |||
| under the control of a PCE. | under the control of a PCE. | |||
| A Track is a unidirectional path between a source and a destination. | A Track is a unidirectional path between a source and a destination. | |||
| Time and frequency resources called cells (see Section 5.3.1.4) are | Time and frequency resources called cells (see Section 5.3.1.4) are | |||
| allocated to enable the forwarding operation along the Track. In a | allocated to enable the forwarding operation along the Track. In a | |||
| Track cell, the normal operation of IEEE 802.15.4 ARQ usually | Track cell, the normal operation of IEEE 802.15.4 ARQ usually | |||
| happens, though the acknowledgment may be omitted in some cases, for | happens, though the acknowledgment may be omitted in some cases, for | |||
| instance, if there is no scheduled cell for a retry. | instance, if there is no scheduled cell for a retry. | |||
| Track Forwarding is the simplest and fastest. A bundle of cells set | Track Forwarding is the simplest and fastest operation. A bundle of | |||
| to receive (RX-cells) is uniquely paired to a bundle of cells that | cells set to receive (RX-cells) is uniquely paired to a bundle of | |||
| are set to transmit (TX-cells), representing a Layer 2 forwarding | cells that are set to transmit (TX-cells), representing a Layer 2 | |||
| state that can be used regardless of the network-layer protocol. | forwarding state that can be used regardless of the network-layer | |||
| This model can effectively be seen as a Generalized Multiprotocol | protocol. This model can effectively be seen as a Generalized | |||
| Label Switching (GMPLS) operation in that the information used to | Multiprotocol Label Switching (GMPLS) operation in that the | |||
| switch a frame is not an explicit label but is rather related to | information used to switch a frame is not an explicit label but is | |||
| other properties about the way the packet was received (a particular | rather related to other properties about the way the packet was | |||
| cell, in the case of 6TiSCH). As a result, as long as the TSCH MAC | received (a particular cell, in the case of 6TiSCH). As a result, as | |||
| (and Layer 2 security) accepts a frame, that frame can be switched | long as the TSCH MAC (and Layer 2 security) accepts a frame, that | |||
| regardless of the protocol, whether this is an IPv6 packet, a 6LoWPAN | frame can be switched regardless of the protocol, whether this is an | |||
| fragment, or a frame from an alternate protocol such as WirelessHART | IPv6 packet, a 6LoWPAN fragment, or a frame from an alternate | |||
| or ISA100.11a. | protocol such as WirelessHART or ISA100.11a. | |||
| A data frame that is forwarded along a Track normally has a | A data frame that is forwarded along a Track normally has a | |||
| destination MAC address that is set to broadcast (or a multicast | destination MAC address that is set to broadcast (or a multicast | |||
| address, depending on MAC support). This way, the MAC layer in the | address, depending on MAC support). This way, the MAC layer in the | |||
| intermediate nodes accepts the incoming frame, and 6top switches it | intermediate nodes accepts the incoming frame, and 6top switches it | |||
| without incurring a change in the MAC header. In the case of IEEE | without incurring a change in the MAC header. In the case of IEEE | |||
| 802.15.4, this means effectively broadcast, so that the short address | 802.15.4, this effectively means that the address is broadcast, so | |||
| for the destination of the frame is set to 0xFFFF along the Track. | that the short address for the destination of the frame is set to | |||
| 0xFFFF along the Track. | ||||
| A Track is thus formed end to end as a succession of paired bundles: | A Track is thus formed end to end as a succession of paired bundles: | |||
| a receive bundle from the previous hop and a transmit bundle to the | 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 | 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 | Track at most. For a given iteration of the device schedule, the | |||
| effective channel of the cell is obtained by adding a pseudorandom | effective channel of the cell is obtained by adding a pseudorandom | |||
| number to the channelOffset of the cell, which results in a rotation | number to the channelOffset of the cell, which results in a rotation | |||
| of the frequency that was used for transmission. The bundles may be | of the frequency that was used for transmission. The bundles may be | |||
| computed so as to accommodate both variable rates and | computed so as to accommodate both variable rates and | |||
| retransmissions, so they might not be fully used at a given iteration | retransmissions, so they might not be fully used at a given iteration | |||
| skipping to change at line 1009 ¶ | skipping to change at line 1013 ¶ | |||
| to avoid waste of cells as well as overflows in the transmit bundle, | to avoid waste of cells as well as overflows in the transmit bundle, | |||
| as described in the following paragraphs. | as described in the following paragraphs. | |||
| On one hand, a TX-cell that is not needed for the current iteration | On one hand, a TX-cell that is not needed for the current iteration | |||
| may be reused opportunistically on a per-hop basis for routed | may be reused opportunistically on a per-hop basis for routed | |||
| packets. When all of the frames that were received for a given Track | packets. When all of the frames that were received for a given Track | |||
| are effectively transmitted, any available TX-cell for that Track can | are effectively transmitted, any available TX-cell for that Track can | |||
| be reused for upper-layer traffic for which the next-hop router | be reused for upper-layer traffic for which the next-hop router | |||
| matches the next hop along the Track. In that case, the cell that is | matches the next hop along the Track. In that case, the cell that is | |||
| being used is effectively a TX-cell from the Track, but the short | being used is effectively a TX-cell from the Track, but the short | |||
| address for the destination is that of the next-hop router. It | address for the destination is that of the next-hop router. As a | |||
| results that a frame that is received in an RX-cell of a Track with a | result, a frame that is received in an RX-cell of a Track with a | |||
| destination MAC address set to this node as opposed to broadcast must | destination MAC address set to this node as opposed to broadcast must | |||
| be extracted from the Track and delivered to the upper layer (a frame | be extracted from the Track and delivered to the upper layer (a frame | |||
| with an unrecognized MAC address is dropped at the lower MAC layer | with an unrecognized MAC address is dropped at the lower MAC layer | |||
| and thus is not received at the 6top sublayer). | and thus is not received at the 6top sublayer). | |||
| On the other hand, it might happen that there are not enough TX-cells | On the other hand, it might happen that there are not enough TX-cells | |||
| in the transmit bundle to accommodate the Track traffic, for | in the transmit bundle to accommodate the Track traffic, for | |||
| instance, if more retransmissions are needed than provisioned. In | instance, if more retransmissions are needed than provisioned. In | |||
| that case, the frame can be placed for transmission in the bundle | that case, the frame can be placed for transmission in the bundle | |||
| that is used for Layer 3 traffic towards the next hop along the Track | that is used for Layer 3 traffic towards the next hop along the Track | |||
| as long as it can be routed by the upper layer, that is, typically, | as long as it can be routed by the upper layer, that is, typically, | |||
| if the frame transports an IPv6 packet. The MAC address should be | if the frame transports an IPv6 packet. The MAC address should be | |||
| set to the next-hop MAC address to avoid confusion. It results that | set to the next-hop MAC address to avoid confusion. As a result, a | |||
| a frame that is received over a Layer 3 bundle may be in fact | frame that is received over a Layer 3 bundle may be in fact | |||
| associated with a Track. In a classical IP link such as an Ethernet, | associated with a Track. In a classical IP link such as an Ethernet, | |||
| off-Track traffic is typically in excess over reservation to be | off-Track traffic is typically in excess over reservation to be | |||
| routed along the non-reserved path based on its QoS setting. | routed along the non-reserved path based on its QoS setting. | |||
| However, with 6TiSCH, since the use of the Layer 3 bundle may be due | However, with 6TiSCH, since the use of the Layer 3 bundle may be due | |||
| to transmission failures, it makes sense for the receiver to | to transmission failures, it makes sense for the receiver to | |||
| recognize a frame that should be re-Tracked and to place it back on | recognize a frame that should be re-Tracked and to place it back on | |||
| the appropriate bundle if possible. A frame should be re-Tracked if | the appropriate bundle if possible. A frame should be re-Tracked if | |||
| the per-hop-behavior group indicated in the Differentiated Services | the per-hop-behavior group indicated in the Differentiated Services | |||
| field in the IPv6 header is set to deterministic forwarding, as | field in the IPv6 header is set to deterministic forwarding, as | |||
| discussed in Section 5.3.1.1. A frame is re-Tracked by scheduling it | discussed in Section 5.3.1.1. A frame is re-Tracked by scheduling it | |||
| skipping to change at line 1057 ¶ | skipping to change at line 1061 ¶ | |||
| Explicit Replication (BIER) [RFC8279] and, more specifically, BIER | Explicit Replication (BIER) [RFC8279] and, more specifically, BIER | |||
| Traffic Engineering (BIER-TE) [RFC9262]. | Traffic Engineering (BIER-TE) [RFC9262]. | |||
| 5.3. Applicability to Deterministic Flows | 5.3. Applicability to Deterministic Flows | |||
| In the RAW context, low-power reliable networks should address non- | In the RAW context, low-power reliable networks should address non- | |||
| critical control scenarios such as Class 2 and monitoring scenarios | critical control scenarios such as Class 2 and monitoring scenarios | |||
| such as Class 4, as defined by [RFC5673]. As a low-power technology | such as Class 4, as defined by [RFC5673]. As a low-power technology | |||
| targeting industrial scenarios, radio transducers provide low data | targeting industrial scenarios, radio transducers provide low data | |||
| rates (typically between 50 kbps to 250 kbps) and robust modulations | rates (typically between 50 kbps to 250 kbps) and robust modulations | |||
| to trade-off performance to reliability. TSCH networks are organized | to trade off performance for reliability. TSCH networks are | |||
| in mesh topologies and connected to a backbone. Latency in the mesh | organized in mesh topologies and connected to a backbone. Latency in | |||
| network is mainly influenced by propagation aspects such as | the mesh network is mainly influenced by propagation aspects such as | |||
| interference. ARQ methods and redundancy techniques such as | interference. ARQ methods and redundancy techniques such as | |||
| replication and elimination should be studied to provide the needed | replication and elimination should be studied to provide the needed | |||
| performance to address deterministic scenarios. | performance to address deterministic scenarios. | |||
| Nodes in a TSCH network are tightly synchronized. This enables | Nodes in a TSCH network are tightly synchronized. This enables | |||
| building the slotted structure and ensures efficient utilization of | building the slotted structure and ensures efficient utilization of | |||
| resources thanks to proper scheduling policies. Scheduling is key to | resources thanks to proper scheduling policies. Scheduling is key to | |||
| orchestrate the resources that different nodes in a Track or a path | orchestrate the resources that different nodes in a Track or a path | |||
| are using. Slotframes can be split in resource blocks, reserving the | are using. Slotframes can be split in resource blocks, reserving the | |||
| needed capacity to certain flows. Periodic and bursty traffic can be | needed capacity to certain flows. Periodic and bursty traffic can be | |||
| handled independently in the schedule, using active and reactive | handled independently in the schedule, using active and reactive | |||
| policies and taking advantage of overprovisioned cells. Along a | policies and taking advantage of overprovisioned cells. Along a | |||
| Track (see Section 5.2.1), resource blocks can be chained so nodes in | Track (see Section 5.2.1), resource blocks can be chained so nodes in | |||
| previous hops transmit their data before the next packet comes. This | previous hops transmit their data before the next packet comes. This | |||
| provides a tight control to latency along a Track. Collision loss is | provides a tight control of latency along a Track. Collision loss is | |||
| avoided for best-effort traffic by overprovisioning resources, giving | avoided for best-effort traffic by overprovisioning resources, giving | |||
| time to the management plane of the network to dedicate more | time to the management plane of the network to dedicate more | |||
| resources if needed. | resources if needed. | |||
| 5.3.1. Centralized Path Computation | 5.3.1. Centralized Path Computation | |||
| When considering end-to-end communication over TSCH, a 6TiSCH device | When considering end-to-end communication over TSCH, a 6TiSCH device | |||
| usually does not place a request for bandwidth between itself and | usually does not place a request for bandwidth between itself and | |||
| another device in the network. Rather, an Operation Control System | another device in the network. Rather, an Operation Control System | |||
| (OCS) invoked through a Human-Machine Interface (HMI) provides the | (OCS) invoked through a Human/Machine Interface (HMI) provides the | |||
| traffic specification, in particular, in terms of latency and | traffic specification (in particular, in terms of latency, | |||
| reliability, and the end nodes, to a PCE. With this, the PCE | reliability, and the end nodes) to a PCE. With this, the PCE | |||
| computes a Track between the end nodes and provisions every hop in | computes a Track between the end nodes and provisions every hop in | |||
| the Track with per-flow state that describes the per-hop operation | the Track with per-flow state that describes the per-hop operation | |||
| for a given packet, the corresponding timeSlots, and the flow | for a given packet, the corresponding timeSlots, and the flow | |||
| identification to recognize which packet is placed in which Track, | identification to recognize which packet is placed in which Track, | |||
| sort out duplicates, etc. An example of an OCS and HMI is depicted | sort out duplicates, etc. An example of an OCS and HMI is depicted | |||
| in Figure 2. | in Figure 2. | |||
| For a static configuration that serves a certain purpose for a long | For a static configuration that serves a certain purpose for a long | |||
| period of time, it is expected that a node will be provisioned in one | period of time, it is expected that a node will be provisioned in one | |||
| shot with a full schedule, which incorporates the aggregation of its | shot with a full schedule, which incorporates the aggregation of its | |||
| behavior for multiple Tracks. The 6TiSCH architecture expects that | behavior for multiple Tracks. The 6TiSCH architecture expects that | |||
| the programming of the schedule is done over the Constrained | the programming of the schedule is done over the Constrained | |||
| Application Protocol (CoAP) as discussed in [CoAP-6TiSCH]. | Application Protocol (CoAP) as discussed in [CoAP-6TiSCH]. | |||
| However, a Hybrid mode may be required as well, whereby a single | However, a Hybrid mode may be required as well, whereby a single | |||
| Track is added, modified, or removed (for instance, if it appears | Track is added, modified, or removed (for instance, if it appears | |||
| that a Track does not perform as expected). For that case, the | that a Track does not perform as expected). For that case, the | |||
| expectation is that a protocol that flows along a Track (to be), in a | expectation is that a protocol that flows along a Track, in a fashion | |||
| fashion similar to classical Traffic Engineering (TE) [CCAMP], may be | similar to classical Traffic Engineering (TE) [CCAMP], may be used to | |||
| used to update the state in the devices. In general, that flow was | update the state in the devices. In general, that flow was not | |||
| not designed, and it is expected that DetNet will determine the | designed, and it is expected that DetNet will determine the | |||
| appropriate end-to-end protocols to be used in that case. | appropriate end-to-end protocols to be used in that case. | |||
| Stream Management Entity | ||||
| Operational Control System and HMI | Operational Control System and HMI | |||
| -+-+-+-+-+-+-+ Northbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | -+-+-+-+-+-+-+ Northbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | |||
| PCE PCE PCE PCE | PCE PCE PCE PCE | |||
| -+-+-+-+-+-+-+ Southbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | -+-+-+-+-+-+-+ Southbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | |||
| --- 6TiSCH------6TiSCH------6TiSCH------6TiSCH-- | --- 6TiSCH------6TiSCH------6TiSCH------6TiSCH-- | |||
| 6TiSCH / Device Device Device Device \ | 6TiSCH / Device Device Device Device \ | |||
| skipping to change at line 1138 ¶ | skipping to change at line 1140 ¶ | |||
| 5.3.1.1. Packet Marking and Handling | 5.3.1.1. Packet Marking and Handling | |||
| Section 4.7.1 of [RFC9030] describes the packet tagging and marking | Section 4.7.1 of [RFC9030] describes the packet tagging and marking | |||
| that is expected in 6TiSCH networks. | that is expected in 6TiSCH networks. | |||
| 5.3.1.1.1. Tagging Packets for Flow Identification | 5.3.1.1.1. Tagging Packets for Flow Identification | |||
| Packets that are routed by a PCE along a Track are tagged to uniquely | Packets that are routed by a PCE along a Track are tagged to uniquely | |||
| identify the Track and associated transmit bundle of timeSlots. | identify the Track and associated transmit bundle of timeSlots. | |||
| It results that the tagging that is used for a DetNet flow outside | As a result, the tagging that is used for a DetNet flow outside the | |||
| the 6TiSCH Low-Power and Lossy Network (LLN) must be swapped into | 6TiSCH Low-Power and Lossy Network (LLN) must be swapped into 6TiSCH | |||
| 6TiSCH formats and back as the packet enters and then leaves the | formats and back as the packet enters and then leaves the 6TiSCH | |||
| 6TiSCH network. | network. | |||
| 5.3.1.1.2. Replication, Retries, and Elimination | 5.3.1.1.2. Replication, Retries, and Elimination | |||
| The 6TiSCH architecture [RFC9030] leverages PREOF over several | The 6TiSCH architecture [RFC9030] leverages PREOF over several | |||
| alternate paths in a network to provide redundancy and parallel | alternate paths in a network to provide redundancy and parallel | |||
| transmissions to bound the end-to-end delay. Considering the | transmissions to bound the end-to-end delay. Considering the | |||
| scenario shown in Figure 3, many different paths are possible for S | scenario shown in Figure 3, many different paths are possible for S | |||
| to reach R. A simple way to benefit from this topology could be to | to reach R. A simple way to benefit from this topology could be to | |||
| use the two independent paths via nodes A, C, E and via B, D, F, but | use the two independent paths via nodes A, C, E and via B, D, F, but | |||
| more complex paths are possible as well. | more complex paths are possible as well. | |||
| skipping to change at line 1165 ¶ | skipping to change at line 1167 ¶ | |||
| source (S) (R) (destination) | source (S) (R) (destination) | |||
| (B) (D) (F) | (B) (D) (F) | |||
| Figure 3: A Typical Ladder Shape with Two Parallel Paths Toward | Figure 3: A Typical Ladder Shape with Two Parallel Paths Toward | |||
| the Destination | the Destination | |||
| By employing a packet replication function, each node forwards a copy | By employing a packet replication function, each node forwards a copy | |||
| of each data packet over two different branches. For instance, in | of each data packet over two different branches. For instance, in | |||
| Figure 4, the source node S transmits the data packet to nodes A and | Figure 4, the source node S transmits the data packet to nodes A and | |||
| B, in two different timeslots within the same TSCH slotframe. S | B, in two different timeSlots within the same TSCH slotframe. In the | |||
| transmits twice the same data packet to its Destination Parent (DP) | figure below, S transmits the same data packet twice: once to its | |||
| (A) and to its Alternate Parent (AP) (B). | Destination Parent (DP) (A) and once to its Alternate Parent (AP) | |||
| (B). | ||||
| ===> (A) => (C) => (E) === | ===> (A) => (C) => (E) === | |||
| // \\// \\// \\ | // \\// \\// \\ | |||
| source (S) //\\ //\\ (R) (destination) | source (S) //\\ //\\ (R) (destination) | |||
| \\ // \\ // \\ // | \\ // \\ // \\ // | |||
| ===> (B) => (D) => (F) === | ===> (B) => (D) => (F) === | |||
| Figure 4: Packet Replication | Figure 4: Packet Replication | |||
| By employing a packet elimination function once it receives the first | By employing a packet elimination function once it receives the first | |||
| skipping to change at line 1194 ¶ | skipping to change at line 1197 ¶ | |||
| the promiscuous overhearing function, nodes will have multiple | the promiscuous overhearing function, nodes will have multiple | |||
| opportunities to receive a given data packet. For instance, in | opportunities to receive a given data packet. For instance, in | |||
| Figure 4, when the source node S transmits the data packet to node A, | Figure 4, when the source node S transmits the data packet to node A, | |||
| node B may overhear the transmission. | node B may overhear the transmission. | |||
| 6TiSCH expects elimination and replication of packets along a complex | 6TiSCH expects elimination and replication of packets along a complex | |||
| Track but has no position about how the sequence numbers would be | Track but has no position about how the sequence numbers would be | |||
| tagged in the packet. | tagged in the packet. | |||
| As it goes, 6TiSCH expects that timeSlots corresponding to copies of | As it goes, 6TiSCH expects that timeSlots corresponding to copies of | |||
| the same packet along a Track are correlated by configuration, and | the same packet along a Track are correlated by configuration, so | |||
| does not need to process the sequence numbers. | processing the sequence numbers is not needed. | |||
| The semantics of the configuration must enable correlated timeSlots | The semantics of the configuration must enable correlated timeSlots | |||
| to be grouped for transmit (and receive, respectively) with 'OR' | to be grouped for transmit (and receive, respectively) with 'OR' | |||
| relations, and then an 'AND' relation must be configurable between | relations, and then an 'AND' relation must be configurable between | |||
| groups. The semantics are such that if the transmit (and receive, | groups. The semantics are such that if the transmit (and receive, | |||
| respectively) operation succeeded in one timeSlot in an 'OR' group, | respectively) operation succeeded in one timeSlot in an 'OR' group, | |||
| then all the other timeslots in the group are ignored. Now, if there | then all the other timeSlots in the group are ignored. Now, if there | |||
| are at least two groups, the 'AND' relation between the groups | are at least two groups, the 'AND' relation between the groups | |||
| indicates that one operation must succeed in each of the groups. | indicates that one operation must succeed in each of the groups. | |||
| Further details can be found in the 6TiSCH architecture document | Further details can be found in the 6TiSCH architecture document | |||
| [RFC9030]. | [RFC9030]. | |||
| 5.3.1.2. Topology and Capabilities | 5.3.1.2. Topology and Capabilities | |||
| 6TiSCH nodes are usually IoT devices, characterized by a very limited | 6TiSCH nodes are usually IoT devices, characterized by a very limited | |||
| amount of memory, just enough buffers to store one or a few IPv6 | amount of memory, just enough buffers to store one or a few IPv6 | |||
| packets, and limited bandwidth between peers. It results that a node | packets, and limited bandwidth between peers. As a result, a node | |||
| will maintain only a small amount of peering information and will not | will maintain only a small amount of peering information and will not | |||
| be able to store many packets waiting to be forwarded. Peers can be | be able to store many packets waiting to be forwarded. Peers can be | |||
| identified through MAC or IPv6 addresses. | identified through MAC or IPv6 addresses. | |||
| Neighbors can be discovered over the radio using mechanisms such as | Neighbors can be discovered over the radio using mechanisms such as | |||
| enhanced beacons, but although the neighbor information is available | enhanced beacons, but although the neighbor information is available | |||
| in the 6TiSCH interface data model, 6TiSCH does not describe a | in the 6TiSCH interface data model, 6TiSCH does not describe a | |||
| protocol to proactively push the neighborhood information to a PCE. | protocol to proactively push the neighborhood information to a PCE. | |||
| This protocol should be described and should operate over CoAP. The | This protocol should be described and should operate over CoAP. The | |||
| protocol should be able to carry multiple metrics, in particular, the | protocol should be able to carry multiple metrics, in particular, the | |||
| skipping to change at line 1249 ¶ | skipping to change at line 1252 ¶ | |||
| Both methods may inject routes in the routing tables of the 6TiSCH | Both methods may inject routes in the routing tables of the 6TiSCH | |||
| routers. In either case, each route is associated with a 6TiSCH | routers. In either case, each route is associated with a 6TiSCH | |||
| topology that can be a RPL Instance topology or a Track. The 6TiSCH | topology that can be a RPL Instance topology or a Track. The 6TiSCH | |||
| topology is indexed by an Instance ID, in a format that reuses the | topology is indexed by an Instance ID, in a format that reuses the | |||
| RPLInstanceID as defined in RPL. | RPLInstanceID as defined in RPL. | |||
| Both RPL and PCE rely on shared sources such as policies to define | Both RPL and PCE rely on shared sources such as policies to define | |||
| Global and Local RPLInstanceIDs that can be used by either method. | Global and Local RPLInstanceIDs that can be used by either method. | |||
| It is possible for centralized and distributed routing to share the | It is possible for centralized and distributed routing to share the | |||
| same topology. Generally, they will operate in different slotFrames, | same topology. Generally, they will operate in different slotframes, | |||
| and centralized routes will be used for scheduled traffic and will | and centralized routes will be used for scheduled traffic and will | |||
| have precedence over distributed routes in case of conflict between | have precedence over distributed routes in case of conflict between | |||
| the slotFrames. | the slotframes. | |||
| 5.3.1.4. SlotFrames and Priorities | 5.3.1.4. Slotframes and Priorities | |||
| IEEE 802.15.4 TSCH avoids contention on the medium by formatting time | IEEE 802.15.4 TSCH avoids contention on the medium by formatting time | |||
| and frequencies in cells of transmission of equal duration. In order | and frequencies in cells of transmission of equal duration. In order | |||
| to describe that formatting of time and frequencies, the 6TiSCH | to describe that formatting of time and frequencies, the 6TiSCH | |||
| architecture defines a global concept that is called a Channel | architecture defines a global concept that is called a Channel | |||
| Distribution and Usage (CDU) matrix; a CDU matrix is a matrix of | Distribution and Usage (CDU) matrix; a CDU matrix is a matrix of | |||
| cells with a height equal to the number of available channels | cells with a height equal to the number of available channels | |||
| (indexed by ChannelOffsets) and a width (in timeSlots) that is the | (indexed by channelOffsets) and a width (in timeSlots) that is the | |||
| period of the network scheduling operation (indexed by slotOffsets) | period of the network scheduling operation (indexed by slotOffsets) | |||
| for that CDU matrix. | for that CDU matrix. | |||
| The CDU matrix is used by the PCE as the map of all the channel | The CDU matrix is used by the PCE as the map of all the channel | |||
| utilization. This organization depends on the time in the future. | utilization. This organization depends on the time in the future. | |||
| The frequency used by a cell in the matrix rotates in a pseudorandom | The frequency used by a cell in the matrix rotates in a pseudorandom | |||
| fashion, from an initial position at an epoch time, as the CDU matrix | fashion, from an initial position at an epoch time, as the CDU matrix | |||
| iterates over and over. | iterates over and over. | |||
| The size of a cell is a timeSlot duration, and values of 10 to 15 | The size of a cell is a timeSlot duration, and values of 10 to 15 | |||
| skipping to change at line 1287 ¶ | skipping to change at line 1290 ¶ | |||
| overall utilization of the spectrum over time by a scheduled network | overall utilization of the spectrum over time by a scheduled network | |||
| operation. | operation. | |||
| A CDU matrix is computed by the PCE, but unallocated timeSlots may be | A CDU matrix is computed by the PCE, but unallocated timeSlots may be | |||
| used opportunistically by the nodes for classical best-effort IP | used opportunistically by the nodes for classical best-effort IP | |||
| traffic. The PCE has precedence in the allocation in case of a | traffic. The PCE has precedence in the allocation in case of a | |||
| conflict. Multiple schedules may coexist, in which case the schedule | conflict. Multiple schedules may coexist, in which case the schedule | |||
| adds a dimension to the matrix, and the dimensions are ordered by | adds a dimension to the matrix, and the dimensions are ordered by | |||
| priority. | priority. | |||
| A slotFrame is the base object that a PCE needs to manipulate to | A slotframe is the base object that a PCE needs to manipulate to | |||
| program a schedule into one device. The slotFrame is a device | program a schedule into one device. The slotframe is a device's | |||
| perspective of a transmission schedule; there can be more than one | perspective of a transmission schedule; there can be more than one | |||
| with different priorities so in case of a contention the highest | with different priorities so in case of a contention the highest | |||
| priority applies. In other words, a slotFrame is the projection of a | priority applies. In other words, a slotframe is the projection of a | |||
| schedule from the CDU matrix onto one device. Elaboration on that | schedule from the CDU matrix onto one device. Elaboration on that | |||
| concept can be found in section "SlotFrames and Priorities" of | concept can be found in Section 4.3.5 of [RFC9030], and Figures 17 | |||
| [RFC9030], and Figures 17 and 18 in [RFC9030] illustrate that | and 18 of [RFC9030] illustrate that projection. | |||
| projection. | ||||
| 6. 5G | 6. 5G | |||
| 5G technology enables deterministic communication. Based on the | 5G technology enables deterministic communication. Based on the | |||
| centralized admission control and the scheduling of the wireless | centralized admission control and the scheduling of the wireless | |||
| resources, licensed or unlicensed, Quality of Service (QoS) such as | resources, licensed or unlicensed, Quality of Service (QoS) such as | |||
| latency and reliability can be guaranteed. 5G contains several | latency and reliability can be guaranteed. 5G contains several | |||
| features to achieve ultra-reliable and low-latency performance (e.g., | features to achieve ultra-reliable and low-latency performance (e.g., | |||
| support for different OFDM numerologies and slot durations), as well | support for different OFDM numerologies and slot durations), as well | |||
| as fast processing capabilities and redundancy techniques that lead | as fast processing capabilities and redundancy techniques that lead | |||
| skipping to change at line 1657 ¶ | skipping to change at line 1659 ¶ | |||
| NR is designed with native support of antenna arrays utilizing | NR is designed with native support of antenna arrays utilizing | |||
| benefits from beamforming, transmissions over multiple MIMO layers, | benefits from beamforming, transmissions over multiple MIMO layers, | |||
| and advanced receiver algorithms allowing effective interference | and advanced receiver algorithms allowing effective interference | |||
| cancellation. Those antenna techniques are the basis for high signal | cancellation. Those antenna techniques are the basis for high signal | |||
| quality and the effectiveness of spectral usage. Spatial diversity | quality and the effectiveness of spectral usage. Spatial diversity | |||
| with up to four MIMO layers in UL and up to eight MIMO layers in DL | with up to four MIMO layers in UL and up to eight MIMO layers in DL | |||
| is supported. Together with spatial-domain multiplexing, antenna | is supported. Together with spatial-domain multiplexing, antenna | |||
| arrays can focus power in the desired direction to form beams. NR | arrays can focus power in the desired direction to form beams. NR | |||
| supports beam management mechanisms to find the best suitable beam | supports beam management mechanisms to find the best suitable beam | |||
| for UE initially and when it is moving. In addition, gNBs can | for UE initially and when it is moving. In addition, gNBs can | |||
| coordinate their respective DL and UL transmissions over the backhaul | coordinate their respective downlink (DL) and uplink (UL) | |||
| network, keeping interference reasonably low, and even make | transmissions over the backhaul network, keeping interference | |||
| transmissions or receptions from multiple points (multi-TRP). Multi- | reasonably low, and even make transmissions or receptions from | |||
| TRP can be used for repetition of a data packet in time, in | multiple points (multi-TRP). Multi-TRP can be used for repetition of | |||
| frequency, or over multiple MIMO layers, which can improve | a data packet in time, in frequency, or over multiple MIMO layers, | |||
| reliability even further. | which can improve reliability even further. | |||
| Any downlink transmission to a UE starts from resource allocation | Any DL transmission to a UE starts from resource allocation signaling | |||
| signaling over the Physical Downlink Control Channel (PDCCH). If it | over the Physical Downlink Control Channel (PDCCH). If it is | |||
| is successfully received, the UE will know about the scheduled | successfully received, the UE will know about the scheduled | |||
| transmission and may receive data over the Physical Downlink Shared | transmission and may receive data over the Physical Downlink Shared | |||
| Channel (PDSCH). If retransmission is required according to the HARQ | Channel (PDSCH). If retransmission is required according to the HARQ | |||
| scheme, a signaling of negative acknowledgement (NACK) on the | scheme, a signaling of negative acknowledgement (NACK) on the | |||
| Physical Uplink Control Channel (PUCCH) is involved, and PDCCH | Physical Uplink Control Channel (PUCCH) is involved, and PDCCH | |||
| together with PDSCH transmissions (possibly with additional | together with PDSCH transmissions (possibly with additional | |||
| redundancy bits) are transmitted and soft-combined with previously | redundancy bits) are transmitted and soft-combined with previously | |||
| received bits. Otherwise, if no valid control signaling for | received bits. Otherwise, if no valid control signaling for | |||
| scheduling data is received, nothing is transmitted on PUCCH | scheduling data is received, nothing is transmitted on PUCCH | |||
| (discontinuous transmission (DTX)), and upon detecting DTX, the base | (discontinuous transmission (DTX)), and upon detecting DTX, the base | |||
| station will retransmit the initial data. | station will retransmit the initial data. | |||
| An uplink transmission normally starts from a Scheduling Request | An UL transmission normally starts from a Scheduling Request (SR), a | |||
| (SR), a signaling message from the UE to the base station sent via | signaling message from the UE to the base station sent via PUCCH. | |||
| PUCCH. Once the scheduler is informed about buffer data in the UE | Once the scheduler is informed about buffer data in the UE (e.g., by | |||
| (e.g., by SR), the UE transmits a data packet on the Physical Uplink | SR), the UE transmits a data packet on the Physical Uplink Shared | |||
| Shared Channel (PUSCH). Pre-scheduling, not relying on SR, is also | Channel (PUSCH). Pre-scheduling, not relying on SR, is also possible | |||
| possible (see Section 6.4.4). | (see Section 6.4.4). | |||
| Since transmission of data packets requires usage of control and data | Since transmission of data packets requires usage of control and data | |||
| channels, there are several methods to maintain the needed | channels, there are several methods to maintain the needed | |||
| reliability. NR uses Low Density Parity Check (LDPC) codes for data | reliability. NR uses Low Density Parity Check (LDPC) codes for data | |||
| channels, polar codes for PDCCH, as well as orthogonal sequences and | channels, polar codes for PDCCH, as well as orthogonal sequences and | |||
| polar codes for PUCCH. For ultra-reliability of data channels, very | polar codes for PUCCH. For ultra-reliability of data channels, very | |||
| robust (low-spectral efficiency) Modulation and Coding Scheme (MCS) | robust (low-spectral efficiency) Modulation and Coding Scheme (MCS) | |||
| tables are introduced containing very low (down to 1/20) LDPC code | tables are introduced containing very low (down to 1/20) LDPC code | |||
| rates using BPSK or QPSK. Also, PDCCH and PUCCH channels support | rates using Binary Phase-Shift Keying (BPSK) or Quadrature Phase- | |||
| multiple code rates including very low ones for the channel | Shift Keying (QPSK). Also, PDCCH and PUCCH channels support multiple | |||
| robustness. | code rates including very low ones for the channel robustness. | |||
| A connected UE reports downlink (DL) quality to gNB by sending | A connected UE reports DL quality to gNB by sending Channel State | |||
| Channel State Information (CSI) reports via PUCCH while uplink (UL) | Information (CSI) reports via PUCCH while UL quality is measured | |||
| quality is measured directly at gNB. For both uplink and downlink, | directly at gNB. For both UL and DL, gNB selects the desired MCS | |||
| gNB selects the desired MCS number and signals it to the UE by | number and signals it to the UE by Downlink Control Information (DCI) | |||
| Downlink Control Information (DCI) via PDCCH channel. For URLLC | via PDCCH channel. For URLLC services, the UE can assist the gNB by | |||
| services, the UE can assist the gNB by advising that MCS targeting a | advising that MCS targeting a 10^-5 Block Error Rate (BLER) are used. | |||
| 10^-5 Block Error Rate (BLER) are used. Robust link adaptation | Robust link adaptation algorithms can maintain the needed level of | |||
| algorithms can maintain the needed level of reliability, considering | reliability, considering a given latency bound. | |||
| a given latency bound. | ||||
| Low latency on the physical layer is provided by short transmission | Low latency on the PHY layer is provided by short transmission | |||
| duration, which is possible by using high Subcarrier Spacing (SCS) | duration, which is possible by using high Subcarrier Spacing (SCS) | |||
| and the allocation of only one or a few Orthogonal Frequency Division | and the allocation of only one or a few Orthogonal Frequency Division | |||
| Multiplexing (OFDM) symbols. For example, the shortest latency for | 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 | 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 | Section 5.7.1 in [TR37910]). Moreover, if the initial transmission | |||
| has failed, HARQ feedback can quickly be provided and an HARQ | has failed, HARQ feedback can quickly be provided and an HARQ | |||
| retransmission scheduled. | retransmission scheduled. | |||
| Dynamic multiplexing of data associated with different services is | Dynamic multiplexing of data associated with different services is | |||
| highly desirable for efficient use of system resources and to | highly desirable for efficient use of system resources and to | |||
| maximize system capacity. Assignment of resources for eMBB is | maximize system capacity. Assignment of resources for eMBB is | |||
| usually done with regular (longer) transmission slots, which can lead | usually done with regular (longer) transmission slots, which can lead | |||
| to blocking of low-latency services. To overcome the blocking, eMBB | to blocking of low-latency services. To overcome the blocking, eMBB | |||
| resources can be preempted and reassigned to URLLC services. In this | resources can be preempted and reassigned to URLLC services. In this | |||
| way, spectrally efficient assignments for eMBB can be ensured while | way, spectrally efficient assignments for eMBB can be ensured while | |||
| providing the flexibility required to ensure a bounded latency for | providing the flexibility required to ensure a bounded latency for | |||
| URLLC services. In downlink, the gNB can notify the eMBB UE about | URLLC services. In DL, the gNB can notify the eMBB UE about | |||
| preemption after it has happened, while in uplink there are two | preemption after it has happened, while in UL there are two | |||
| preemption mechanisms: special signaling to cancel eMBB transmission | preemption mechanisms: special signaling to cancel eMBB transmission | |||
| and URLLC dynamic power boost to suppress eMBB transmission. | and URLLC dynamic power boost to suppress eMBB transmission. | |||
| 6.4.4. Scheduling and QoS (MAC) | 6.4.4. Scheduling and QoS (MAC) | |||
| One integral part of the 5G system is the Quality of Service (QoS) | One integral part of the 5G system is the Quality of Service (QoS) | |||
| framework [TS23501]. QoS flows are set up by the 5G system for | framework [TS23501]. QoS flows are set up by the 5G system for | |||
| certain IP or Ethernet packet flows, so that packets of each flow | certain IP or Ethernet packet flows, so that packets of each flow | |||
| receive the same forwarding treatment (i.e., in scheduling and | receive the same forwarding treatment (i.e., in scheduling and | |||
| admission control). For example, QoS flows can be associated with | admission control). For example, QoS flows can be associated with | |||
| skipping to change at line 1774 ¶ | skipping to change at line 1775 ¶ | |||
| short transmission formats, sub-slot feedback reporting, and PUCCH | short transmission formats, sub-slot feedback reporting, and PUCCH | |||
| carrier switching. If needed to avoid HARQ round-trip time delays, | carrier switching. If needed to avoid HARQ round-trip time delays, | |||
| repeated transmissions can be also scheduled beforehand, to the cost | repeated transmissions can be also scheduled beforehand, to the cost | |||
| of reduced spectral efficiency. | of reduced spectral efficiency. | |||
| In dynamic DL scheduling, transmission can be initiated immediately | In dynamic DL scheduling, transmission can be initiated immediately | |||
| when DL data becomes available in the gNB. However, for dynamic UL | when DL data becomes available in the gNB. However, for dynamic UL | |||
| scheduling, when data becomes available but no UL resources are | scheduling, when data becomes available but no UL resources are | |||
| available yet, the UE indicates the need for UL resources to the gNB | available yet, the UE indicates the need for UL resources to the gNB | |||
| via a (single bit) scheduling request message in the UL control | via a (single bit) scheduling request message in the UL control | |||
| channel. When thereupon UL resources are scheduled to the UE, the UE | channel. When UL resources are scheduled, the UE can transmit its | |||
| can transmit its data and may include a buffer status report that | data and may include a buffer status report that indicates the exact | |||
| indicates the exact amount of data per logical channel still left to | amount of data per logical channel still left to be sent. More UL | |||
| be sent. More UL resources may be scheduled accordingly. To avoid | resources may be scheduled accordingly. To avoid the latency | |||
| the latency introduced in the scheduling request loop, UL radio | introduced in the scheduling request loop, UL radio resources can | |||
| resources can also be pre-scheduled. | also be pre-scheduled. | |||
| In particular, for periodical traffic patterns, the pre-scheduling | In particular, for periodical traffic patterns, the pre-scheduling | |||
| can rely on the scheduling features DL Semi-Persistent Scheduling | can rely on the scheduling features DL Semi-Persistent Scheduling | |||
| (SPS) and UL Configured Grant (CG). With these features, | (SPS) and UL Configured Grant (CG). With these features, | |||
| periodically recurring resources can be assigned in DL and UL. | periodically recurring resources can be assigned in DL and UL. | |||
| Multiple parallels of those configurations are supported in order to | Multiple parallels of those configurations are supported in order to | |||
| serve multiple parallel traffic flows of the same UE. | serve multiple parallel traffic flows of the same UE. | |||
| To support QoS enforcement in the case of mixed traffic with | To support QoS enforcement in the case of mixed traffic with | |||
| different QoS requirements, several features have recently been | different QoS requirements, several features have recently been | |||
| introduced. This way, e.g., different periodical critical QoS flows | introduced. These features allow different periodical critical QoS | |||
| can be served, together with best-effort transmissions by the same | flows to be served, together with best-effort transmissions, by the | |||
| UE. These features (partly Release 16) include the following: | same UE. These features include the following: | |||
| * UL logical channel transmission restrictions, allowing logical | * UL logical channel transmission restrictions, allowing logical | |||
| channels of certain QoS to only be mapped to intended UL resources | channels of certain QoS to only be mapped to intended UL resources | |||
| of a certain frequency carrier, slot length, or CG configuration. | of a certain frequency carrier, slot length, or CG configuration. | |||
| * intra-UE preemption and multiplexing, allowing critical UL | * intra-UE preemption and multiplexing, allowing critical UL | |||
| transmissions to either preempt non-critical transmissions or be | transmissions to either preempt non-critical transmissions or be | |||
| multiplexed with non-critical transmissions keeping different | multiplexed with non-critical transmissions keeping different | |||
| reliability targets. | reliability targets. | |||
| skipping to change at line 1851 ¶ | skipping to change at line 1852 ¶ | |||
| by scheduled traffic [IEEE802.1Qbv] may be used to achieve bounded | by scheduled traffic [IEEE802.1Qbv] may be used to achieve bounded | |||
| low latency. The TSN tool for time synchronization is the | low latency. The TSN tool for time synchronization is the | |||
| generalized Precision Time Protocol (gPTP) [IEEE802.1AS], which | generalized Precision Time Protocol (gPTP) [IEEE802.1AS], which | |||
| provides reliable time synchronization that can be used by end | provides reliable time synchronization that can be used by end | |||
| stations and by other TSN tools (e.g., scheduled traffic | stations and by other TSN tools (e.g., scheduled traffic | |||
| [IEEE802.1Qbv]). High availability, as a result of ultra- | [IEEE802.1Qbv]). High availability, as a result of ultra- | |||
| reliability, is provided for data flows by the Frame Replication and | reliability, is provided for data flows by the Frame Replication and | |||
| Elimination for Reliability (FRER) mechanism [IEEE802.1CB]. | Elimination for Reliability (FRER) mechanism [IEEE802.1CB]. | |||
| 3GPP Release 16 includes integration of 5G with TSN, i.e., specifies | 3GPP Release 16 includes integration of 5G with TSN, i.e., specifies | |||
| functions for the 5G System (5GS) to deliver TSN streams such that | functions for the 5G System (5GS) to deliver TSN streams so that | |||
| the meet their QoS requirements. A key aspect of the integration is | their QoS requirements are met. A key aspect of the integration is | |||
| the 5GS appears from the rest of the network as a set of TSN bridges, | that, from the rest of the network, the 5GS appears as a set of TSN | |||
| in particular, one virtual bridge per User Plane Function (UPF) on | bridges (in particular, one virtual bridge per User Plane Function | |||
| the user plane. The 5GS includes TSN Translator (TT) functionality | (UPF) on the user plane). The 5GS includes TSN Translator (TT) | |||
| for the adaptation of the 5GS to the TSN bridged network and for | functionality for the adaptation of the 5GS to the TSN bridged | |||
| hiding the 5GS internal procedures. The 5GS provides the following | network and for hiding the 5GS internal procedures. The 5GS provides | |||
| components: | the following components: | |||
| 1. interface to TSN controller, as per [IEEE802.1Qcc] for the fully | 1. interface to TSN controller, as per [IEEE802.1Qcc] for the fully | |||
| centralized configuration model | centralized configuration model | |||
| 2. time synchronization via reception and transmission of gPTP PDUs | 2. time synchronization via reception and transmission of gPTP PDUs | |||
| [IEEE802.1AS] | [IEEE802.1AS] | |||
| 3. low latency, hence, can be integrated with scheduled traffic | 3. low latency, which allows integration with scheduled traffic | |||
| [IEEE802.1Qbv] | [IEEE802.1Qbv] | |||
| 4. reliability, hence, can be integrated with FRER [IEEE802.1CB] | 4. reliability, which allows integration with FRER [IEEE802.1CB] | |||
| 3GPP Release 17 [TS23501] introduced enhancements to generalize | 3GPP Release 17 [TS23501] introduced enhancements to generalize | |||
| support for TSC beyond TSN. This includes IP communications to | support for TSC beyond TSN. This includes IP communications to | |||
| provide time-sensitive services (e.g., to Video, Imaging, and Audio | provide time-sensitive services (e.g., to Video, Imaging, and Audio | |||
| for Professional Applications (VIAPA)). The system model of 5G | for Professional Applications (VIAPA)). The system model of 5G | |||
| acting as a "TSN bridge" in Release 16 has been reused to enable the | acting as a "TSN bridge" in Release 16 has been reused to enable the | |||
| 5GS acting as a "TSC node" in a more generic sense (which includes | 5GS acting as a "TSC node" in a more generic sense (which includes | |||
| TSN bridge and IP node). In the case of TSC that does not involve | TSN bridge and IP node). In the case of TSC that does not involve | |||
| TSN, requirements are given via exposure interfaces, and the control | TSN, requirements are given via exposure interfaces, and the control | |||
| plane provides the service based on QoS and time synchronization | plane provides the service based on QoS and time synchronization | |||
| skipping to change at line 1933 ¶ | skipping to change at line 1934 ¶ | |||
| |I/O+--+ TSN +------+DS|UE+---+RAN+-+UPF|NW+------+ TSN +----+ | |I/O+--+ TSN +------+DS|UE+---+RAN+-+UPF|NW+------+ TSN +----+ | |||
| |dev| |bridge| | . |TT| | | | | |TT| . | |bridge| | |dev| |bridge| | . |TT| | | | | |TT| . | |bridge| | |||
| +---+ +------+ | . +--+--+ +---+ +---+--+ . | +------+ | +---+ +------+ | . +--+--+ +---+ +---+--+ . | +------+ | |||
| | +..........................+ | | | +..........................+ | | |||
| +------------------------------+ | +------------------------------+ | |||
| <----------------- end-to-end Ethernet -------------------> | <----------------- end-to-end Ethernet -------------------> | |||
| Figure 7: 5G - TSN Integration | Figure 7: 5G - TSN Integration | |||
| NR supports accurate reference time synchronization in 1us accuracy | NR supports accurate reference time synchronization in 1 µs accuracy | |||
| level. Since NR is a scheduled system, an NR UE and a gNB are | level. Since NR is a scheduled system, an NR UE and a gNB are | |||
| tightly synchronized to their OFDM symbol structures. A 5G internal | tightly synchronized to their OFDM symbol structures. A 5G internal | |||
| reference time can be provided to the UE via broadcast or unicast | reference time can be provided to the UE via broadcast or unicast | |||
| signaling, associating a known OFDM symbol to this reference clock. | signaling, associating a known OFDM symbol to this reference clock. | |||
| The 5G internal reference time can be shared within the 5G network | The 5G internal reference time can be shared within the 5G network | |||
| (i.e., radio and core network components). Release 16 has introduced | (i.e., radio and core network components). Release 16 has introduced | |||
| interworking with gPTP for multiple time domains, where the 5GS acts | interworking with gPTP for multiple time domains, where the 5GS acts | |||
| as a virtual gPTP time-aware system and supports the forwarding of | as a virtual gPTP time-aware system and supports the forwarding of | |||
| gPTP time synchronization information between end stations and | gPTP time synchronization information between end stations and | |||
| bridges through the 5G user plane TTs. These account for the | bridges through the 5G user plane TTs. These account for the | |||
| residence time of the 5GS in the time synchronization procedure. One | residence time of the 5GS in the time synchronization procedure. One | |||
| special option is when the 5GS internal reference time is not only | special option is when the 5GS internal reference time is not only | |||
| used within the 5GS, but also to the rest of the devices in the | used within the 5GS, but also to the rest of the devices in the | |||
| deployment, including connected TSN bridges and end stations. | deployment, including connected TSN bridges and end stations. | |||
| Release 17 includes further improvements (i.e., methods for | Release 17 includes further improvements (i.e., methods for | |||
| propagation delay compensation in RAN), further improving the | propagation delay compensation in RAN), further improving the | |||
| accuracy for time synchronization over the air, as well as the | accuracy for time synchronization over the air, as well as the | |||
| possibility for the TSN grandmaster clock to reside on the UE side. | possibility for the TSN grandmaster clock to reside on the UE side. | |||
| More extensions and flexibility were added to the time | More extensions and flexibility were added to the time | |||
| synchronization service, making it general for TSC, with additional | synchronization service, making it general for TSC and providing | |||
| support of other types of clocks and time distribution such as | additional support for other types of clocks and time distribution | |||
| boundary clock, transparent clock peer-to-peer, and transparent clock | such as boundary clocks and transparent clocks (both peer-to-peer and | |||
| end-to-end, aside from the time-aware system used for TSN. | end-to-end) aside from the time-aware system used for TSN. | |||
| Additionally, it is possible to use internal access stratum signaling | Additionally, it is possible to use internal access stratum signaling | |||
| to distribute timing (and not the usual (g)PTP messages), for which | to distribute timing (and not the usual (g)PTP messages), for which | |||
| the required accuracy can be provided by the AF [TS23501]. The same | the required accuracy can be provided by the AF [TS23501]. The same | |||
| time synchronization service is expected to be further extended and | time synchronization service is expected to be further extended and | |||
| enhanced in Release 18 to support Timing Resiliency (according to | enhanced in Release 18 to support Timing Resiliency (according to | |||
| study item [SP211634]), where the 5G system can provide a backup or | study item [SP211634]), where the 5G system can provide a backup or | |||
| alternative timing source for the failure of the local GNSS source | alternative timing source for the failure of the local GNSS source | |||
| (or other primary timing source) used by the vertical. | (or other primary timing source) used by the vertical. | |||
| IETF DetNet is the technology to support time-sensitive | IETF DetNet is the technology to support time-sensitive | |||
| communications at the IP layer. 3GPP Release 18 includes a study | communications at the IP layer. 3GPP Release 18 includes a study | |||
| [TR2370046] on interworking between 5G and DetNet. Along the TSC | [TR2370046] on interworking between 5G and DetNet. Along the TSC | |||
| framework introduced for Release 17, the 5GS acts as a DetNet node | framework introduced for Release 17, the 5GS acts as a DetNet node | |||
| for the support of DetNet; see Figure 7.1-1 in [TR2370046]. The | for the support of DetNet; see Figure 7.1-1 in [TR2370046]. The | |||
| study provides details on how the 5GS is exposed by the Time | study provides details on how the 5GS is exposed by the Time | |||
| Sensitive Communication and Time Synchronization Function (TSCTSF) to | Sensitive Communication and Time Synchronization Function (TSCTSF) to | |||
| the DetNet controller as a router on a per-UPF granularity (similar | the DetNet controller as a router on a per-UPF granularity (similarly | |||
| to the per-UPF Virtual TSN Bridge granularity shown in Figure 11). | to the per-UPF Virtual TSN Bridge granularity shown in Figure 7). In | |||
| In particular, it lists the parameters that are provided by the | particular, it lists the parameters that are provided by the TSCTSF | |||
| TSCTSF to the DetNet controller. The study also includes how the | to the DetNet controller. The study also includes how the TSCTSF | |||
| TSCTSF maps DetNet flow parameters to 5G QoS parameters. Note that | maps DetNet flow parameters to 5G QoS parameters. Note that TSN is | |||
| TSN is the primary subnetwork technology for DetNet. Thus, the work | the primary subnetwork technology for DetNet. Thus, the work on | |||
| on DetNet over TSN, e.g., [RFC9023], can be leveraged via the TSN | DetNet over TSN, e.g., [RFC9023], can be leveraged via the TSN | |||
| support built in 5G. | support built in 5G. | |||
| Redundancy architectures were specified in order to provide | Redundancy architectures were specified in order to provide | |||
| reliability against any kind of failure on the radio link or nodes in | reliability against any kind of failure on the radio link or nodes in | |||
| the RAN and the core network. Redundant user plane paths can be | the RAN and the core network. Redundant user plane paths can be | |||
| provided based on the dual connectivity architecture, where the UE | provided based on the dual connectivity architecture, where the UE | |||
| sets up two PDU sessions towards the same data network, and the 5G | sets up two PDU sessions towards the same data network, and the 5G | |||
| system makes the paths of the two PDU sessions independent as | system makes the paths of the two PDU sessions independent as | |||
| illustrated in Figure 9. There are two PDU sessions involved in the | illustrated in Figure 8. There are two PDU sessions involved in the | |||
| solution: The first spans from the UE via gNB1 to UPF1, acting as the | solution: The first spans from the UE via gNB1 to UPF1, acting as the | |||
| first PDU session anchor, while the second spans from the UE via gNB2 | first PDU session anchor, while the second spans from the UE via gNB2 | |||
| to UPF2, acting as second the PDU session anchor. | to UPF2, acting as second the PDU session anchor. | |||
| The independent paths may continue beyond the 3GPP network. | The independent paths may continue beyond the 3GPP network. | |||
| Redundancy Handling Functions (RHFs) are deployed outside of the 5GS, | Redundancy Handling Functions (RHFs) are deployed outside of the 5GS, | |||
| i.e., in Host A (the device) and in Host B (the network). RHF can | i.e., in Host A (the device) and in Host B (the network). RHF can | |||
| implement replication and elimination functions as per [IEEE802.1CB] | implement replication and elimination functions as per [IEEE802.1CB] | |||
| or the Packet Replication, Elimination, and Ordering Functions | or the Packet Replication, Elimination, and Ordering Functions | |||
| (PREOF) of IETF DetNet [RFC8655]. | (PREOF) of IETF DetNet [RFC8655]. | |||
| skipping to change at line 2020 ¶ | skipping to change at line 2021 ¶ | |||
| +........+ + gNB2 +--N3--+ UPF2 |--N6--+ | | +........+ + gNB2 +--N3--+ UPF2 |--N6--+ | | |||
| +------+ +------+ +------+ | +------+ +------+ +------+ | |||
| Figure 8: Reliability with Single UE | Figure 8: Reliability with Single UE | |||
| An alternative solution is that multiple UEs per device are used for | An alternative solution is that multiple UEs per device are used for | |||
| user plane redundancy as illustrated in Figure 9. Each UE sets up a | user plane redundancy as illustrated in Figure 9. Each UE sets up a | |||
| PDU session. The 5GS ensures that the PDU sessions of the different | PDU session. The 5GS ensures that the PDU sessions of the different | |||
| UEs are handled independently internal to the 5GS. There is no | UEs are handled independently internal to the 5GS. There is no | |||
| single point of failure in this solution, which also includes RHF | single point of failure in this solution, which also includes RHF | |||
| outside of the 5G system, e.g., as per the FRER or PREOF | outside of the 5G system, e.g., as per FRER [IEEE802.1CB] or PREOF | |||
| specifications. | [RFC8655] specifications. | |||
| +.........+ | +.........+ | |||
| . Device . | . Device . | |||
| . . | . . | |||
| . +----+ . +------+ +------+ +------+ | . +----+ . +------+ +------+ +------+ | |||
| . | UE +-----+ gNB1 +--N3--+ UPF1 |--N6--+ | | . | UE +-----+ gNB1 +--N3--+ UPF1 |--N6--+ | | |||
| . +----+ . +------+ +------+ | | | . +----+ . +------+ +------+ | | | |||
| . . | DN | | . . | DN | | |||
| . +----+ . +------+ +------+ | | | . +----+ . +------+ +------+ | | | |||
| . | UE +-----+ gNB2 +--N3--+ UPF2 |--N6--+ | | . | UE +-----+ gNB2 +--N3--+ UPF2 |--N6--+ | | |||
| . +----+ . +------+ +------+ +------+ | . +----+ . +------+ +------+ +------+ | |||
| . . | . . | |||
| +.........+ | +.........+ | |||
| Figure 9: Reliability with Dual UE | Figure 9: Reliability with Dual UE | |||
| Note that the abstraction provided by the RHF and the location of the | Note that the abstraction provided by the RHF and the location of the | |||
| RHF being outside of the 5G system make 5G equally supporting | RHF outside of the 5G system allow 5G to support integration for | |||
| integration for reliability with both FRER of TSN and PREOF of | reliability with both TSN FRER [IEEE802.1CB] and DetNet PREOF | |||
| DetNet, as they both rely on the same concept. | [RFC8655], as they both rely on the same concept. | |||
| 7. L-Band Digital Aeronautical Communications System (LDACS) | 7. L-Band Digital Aeronautical Communications System (LDACS) | |||
| One of the main pillars of the modern Air Traffic Management (ATM) | One of the main pillars of the modern Air Traffic Management (ATM) | |||
| system is the existence of a communication infrastructure that | system is the existence of a communication infrastructure that | |||
| enables efficient aircraft guidance and safe separation in all phases | enables efficient aircraft guidance and safe separation in all phases | |||
| of flight. Although current systems are technically mature, they | of flight. Although current systems are technically mature, they | |||
| suffer from the VHF band's increasing saturation in high-density | suffer from the VHF band's increasing saturation in high-density | |||
| areas and the limitations posed by analog radio. Therefore, aviation | areas and the limitations posed by analog radio. Therefore, aviation | |||
| (globally and in the European Union (EU) in particular) strives for a | (globally and in the European Union (EU) in particular) strives for a | |||
| sustainable modernization of the aeronautical communication | sustainable modernization of the aeronautical communication | |||
| infrastructure. | infrastructure. | |||
| In the long term, ATM communication shall transition from analog VHF | In the long term, ATM communication shall transition from analog VHF | |||
| voice and VDL Mode 2 communication to more spectrum-efficient digital | voice and VHF Digital Link (VDL) Mode 2 communication to more | |||
| data communication. The European ATM Master Plan foresees this | spectrum-efficient digital data communication. The European ATM | |||
| transition to be realized for terrestrial communications by the | Master Plan foresees this transition to be realized for terrestrial | |||
| development and implementation of the L-band Digital Aeronautical | communications by the development and implementation of the L-band | |||
| Communications System (LDACS). | Digital Aeronautical Communications System (LDACS). | |||
| LDACS has been designed with applications related to the safety and | LDACS has been designed with applications related to the safety and | |||
| regularity of the flight in mind. It has therefore been designed as | regularity of the flight in mind. It has therefore been designed as | |||
| a deterministic wireless data link (as far as possible). | a deterministic wireless data link (as far as possible). | |||
| It is a secure, scalable, and spectrum-efficient data link with | It is a secure, scalable, and spectrum-efficient data link with | |||
| embedded navigation capability; thus, it is the first truly | embedded navigation capability; thus, it is the first truly | |||
| integrated Communications, Navigation, and Surveillance (CNS) system | integrated Communications, Navigation, and Surveillance (CNS) system | |||
| recognized by the International Civil Aviation Organization (ICAO). | recognized by the International Civil Aviation Organization (ICAO). | |||
| During flight tests, the LDACS capabilities have been successfully | During flight tests, the LDACS capabilities have been successfully | |||
| skipping to change at line 2106 ¶ | skipping to change at line 2107 ¶ | |||
| simulations, indicating that LDACS can fulfill the identified | simulations, indicating that LDACS can fulfill the identified | |||
| requirements [GRA11]. | requirements [GRA11]. | |||
| LDACS standardization within the framework of the ICAO started in | LDACS standardization within the framework of the ICAO started in | |||
| December 2016. The ICAO standardization group has produced an | December 2016. The ICAO standardization group has produced an | |||
| initial Standards and Recommended Practices (SARPs) document | initial Standards and Recommended Practices (SARPs) document | |||
| [ICAO18]. The SARPs document defines the general characteristics of | [ICAO18]. The SARPs document defines the general characteristics of | |||
| LDACS. | LDACS. | |||
| Up to now, the LDACS standardization has been focused on the | Up to now, the LDACS standardization has been focused on the | |||
| development of the physical layer and the data link layer; only | development of the Physical (PHY) layer and the data link layer; only | |||
| recently have higher layers come into the focus of the LDACS | recently have higher layers come into the focus of the LDACS | |||
| development activities. There is currently no "IPv6 over LDACS" | development activities. There is currently no "IPv6 over LDACS" | |||
| specification; however, SESAR2020 has started the testing of | specification; however, SESAR2020 has started the testing of | |||
| IPv6-based LDACS testbeds. The IPv6 architecture for the | IPv6-based LDACS testbeds. The IPv6 architecture for the | |||
| aeronautical telecommunication network is called the Future | aeronautical telecommunication network is called the Future | |||
| Communications Infrastructure (FCI). FCI shall support QoS, | Communications Infrastructure (FCI). FCI shall support QoS, | |||
| diversity, and mobility under the umbrella of the "multi-link | diversity, and mobility under the umbrella of the "multi-link | |||
| concept". This work is conducted by the ICAO WG-I Working Group. | concept". This work is conducted by the ICAO WG-I Working Group. | |||
| In addition to standardization activities, several industrial LDACS | In addition to standardization activities, several industrial LDACS | |||
| skipping to change at line 2133 ¶ | skipping to change at line 2134 ¶ | |||
| LDACS will become one of several wireless access networks connecting | LDACS will become one of several wireless access networks connecting | |||
| aircraft to the Aeronautical Telecommunications Network (ATN). The | aircraft to the Aeronautical Telecommunications Network (ATN). The | |||
| LDACS access network contains several ground stations, each of which | LDACS access network contains several ground stations, each of which | |||
| provides one LDACS radio cell. The LDACS air interface is a cellular | provides one LDACS radio cell. The LDACS air interface is a cellular | |||
| data link with a star topology connecting aircraft to ground stations | data link with a star topology connecting aircraft to ground stations | |||
| with a full duplex radio link. Each ground station is the | with a full duplex radio link. Each ground station is the | |||
| centralized instance controlling all air-ground communications within | centralized instance controlling all air-ground communications within | |||
| its radio cell. | its radio cell. | |||
| The user data rate of LDACS is 315 kbit/s to 1428 kbit/s on the | The user data rate of LDACS is 315 kbit/s to 1428 kbit/s on the | |||
| forward link and 294 kbit/s to 1390 kbit/s on the reverse link, | forward link (FL) and 294 kbit/s to 1390 kbit/s on the reverse link | |||
| depending on coding and modulation. Due to strong interference from | (RL), depending on coding and modulation. Due to strong interference | |||
| legacy systems in the L-band, the most robust coding and modulation | from legacy systems in the L-band, the most robust coding and | |||
| should be expected for initial deployment, i.e., 315 kbit/s on the | modulation should be expected for initial deployment, i.e., 315 kbit/ | |||
| forward link and 294 kbit/s on the reverse link. | s on the FL and 294 kbit/s on the RL. | |||
| In addition to the communications capability, LDACS also offers a | In addition to the communications capability, LDACS also offers a | |||
| navigation capability. Ranging data, similar to DME (Distance | navigation capability. Ranging data, similar to DME (Distance | |||
| Measuring Equipment), is extracted from the LDACS communication links | Measuring Equipment), is extracted from the LDACS communication links | |||
| between aircraft and LDACS ground stations. This results in LDACS | between aircraft and LDACS ground stations. This results in LDACS | |||
| providing an APNT (Alternative Position, Navigation and Timing) | providing an APNT (Alternative Position, Navigation and Timing) | |||
| capability to supplement the existing on-board GNSS (Global | capability to supplement the existing on-board GNSS (Global | |||
| Navigation Satellite System) without the need for additional | Navigation Satellite System) without the need for additional | |||
| bandwidth. Operationally, there will be no difference for pilots | bandwidth. Operationally, there will be no difference for pilots | |||
| whether the navigation data are provided by LDACS or DME. This | whether the navigation data are provided by LDACS or DME. This | |||
| skipping to change at line 2211 ¶ | skipping to change at line 2212 ¶ | |||
| As LDACS is a ground-based digital communications system for flight | As LDACS is a ground-based digital communications system for flight | |||
| guidance and communications related to safety and regularity of | guidance and communications related to safety and regularity of | |||
| flight, time-bounded deterministic arrival times for safety critical | flight, time-bounded deterministic arrival times for safety critical | |||
| messages are a key feature for its successful deployment and rollout. | messages are a key feature for its successful deployment and rollout. | |||
| 7.4.1. System Architecture | 7.4.1. System Architecture | |||
| Up to 512 Aircraft Stations (ASes) communicate to an LDACS Ground | 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 | 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 | the forward link (FL). Via an Access-Router (AC-R), GSs connect the | |||
| LDACS subnetwork to the global Aeronautical Telecommunications | LDACS subnetwork to the global Aeronautical Telecommunications | |||
| Network (ATN) to which the corresponding Air Traffic Services (ATS) | Network (ATN) to which the corresponding Air Traffic Services (ATS) | |||
| and Aeronautical Operational Control (AOC) end systems are attached. | and Aeronautical Operational Control (AOC) end systems are attached. | |||
| 7.4.2. Overview of the Radio Protocol Stack | 7.4.2. Overview of the Radio Protocol Stack | |||
| The protocol stack of LDACS is implemented in the AS and GS; it | The protocol stack of LDACS is implemented in the AS and GS; it | |||
| consists of the physical (PHY) layer with five major functional | consists of the Physical (PHY) layer with five major functional | |||
| blocks above it. Four are placed in the data link layer (DLL) of the | blocks above it. Four are placed in the data link layer (DLL) of the | |||
| AS and GS: | AS and GS: | |||
| 1. Medium Access Layer (MAC), | 1. Medium Access Layer (MAC), | |||
| 2. Voice Interface (VI), | 2. Voice Interface (VI), | |||
| 3. Data Link Service (DLS), and | 3. Data Link Service (DLS), and | |||
| 4. LDACS Management Entity (LME). | 4. LDACS Management Entity (LME). | |||
| skipping to change at line 2294 ¶ | skipping to change at line 2295 ¶ | |||
| | | | | |||
| ((*)) | ((*)) | |||
| FL/RL radio channels | FL/RL radio channels | |||
| separated by | separated by | |||
| frequency division duplex | frequency division duplex | |||
| Figure 10: LDACS Protocol Stack in AS and GS | Figure 10: LDACS Protocol Stack in AS and GS | |||
| 7.4.3. Radio (PHY) | 7.4.3. Radio (PHY) | |||
| The physical layer provides the means to transfer data over the radio | The PHY layer provides the means to transfer data over the radio | |||
| channel. The LDACS ground station supports bidirectional links to | channel. The LDACS ground station supports bidirectional links to | |||
| multiple aircraft under its control. The forward link direction | multiple aircraft under its control. The FL direction (which is | |||
| (which is ground to air) and the reverse link direction (which is air | ground to air) and the RL direction (which is air to ground) are | |||
| to ground) are separated by frequency division duplex. Forward link | separated by frequency division duplex. FL and RL use a 500 kHz | |||
| and reverse link use a 500 kHz channel each. The ground station | channel each. The ground station transmits a continuous stream of | |||
| transmits a continuous stream of OFDM symbols on the forward link. | OFDM symbols on the FL. In the RL, different aircrafts are separated | |||
| In the reverse link, different aircrafts are separated in time and | in time and frequency using a combination of Orthogonal Frequency- | |||
| frequency using a combination of Orthogonal Frequency-Division | Division Multiple Access (OFDMA) and Time-Division Multiple-Access | |||
| Multiple Access (OFDMA) and Time-Division Multiple-Access (TDMA). | (TDMA). Thus, aircraft transmit discontinuously on the RL with radio | |||
| Thus, aircraft transmit discontinuously on the reverse link with | bursts sent in precisely defined transmission opportunities allocated | |||
| radio bursts sent in precisely defined transmission opportunities | by the ground station. The most important service on the PHY layer | |||
| allocated by the ground station. The most important service on the | of LDACS is the PHY time framing service, which indicates that the | |||
| PHY layer of LDACS is the PHY time framing service, which indicates | PHY layer is ready to transmit in a given slot and indicates PHY | |||
| that the PHY layer is ready to transmit in a given slot and indicates | layer framing and timing to the MAC time framing service. LDACS does | |||
| PHY layer framing and timing to the MAC time framing service. LDACS | not support beam-forming or Multiple Input Multiple Output (MIMO). | |||
| does not support beam-forming or Multiple Input Multiple Output | ||||
| (MIMO). | ||||
| 7.4.4. Scheduling, Frame Structure, and QoS (MAC) | 7.4.4. Scheduling, Frame Structure, and QoS (MAC) | |||
| The data link layer provides the necessary protocols to facilitate | The data link layer provides the necessary protocols to facilitate | |||
| concurrent and reliable data transfer for multiple users. The LDACS | concurrent and reliable data transfer for multiple users. The LDACS | |||
| data link layer is organized in two sublayers: the medium access | data link layer is organized in two sublayers: the medium access | |||
| sublayer and the logical link control sublayer. The medium access | sublayer and the logical link control sublayer. The medium access | |||
| sublayer manages the organization of transmission opportunities in | sublayer manages the organization of transmission opportunities in | |||
| slots of time and frequency. The logical link control sublayer | slots of time and frequency. The logical link control sublayer | |||
| provides acknowledged point-to-point logical channels between the | provides acknowledged point-to-point logical channels between the | |||
| skipping to change at line 2399 ¶ | skipping to change at line 2398 ¶ | |||
| has to be requested with a resource request message stating the | has to be requested with a resource request message stating the | |||
| requested amount of resources and class of service. The ground | requested amount of resources and class of service. The ground | |||
| station performs resource scheduling on the basis of these requests | station performs resource scheduling on the basis of these requests | |||
| and grants resources with resource allocation messages. Resource | and grants resources with resource allocation messages. Resource | |||
| request and allocation messages are exchanged over dedicated | request and allocation messages are exchanged over dedicated | |||
| contention-free control channels. | contention-free control channels. | |||
| LDACS has two mechanisms to request resources from the scheduler in | LDACS has two mechanisms to request resources from the scheduler in | |||
| the ground station. Resources can either be requested "on demand" or | the ground station. Resources can either be requested "on demand" or | |||
| permanently allocated by a LDACS ground station with a given class of | permanently allocated by a LDACS ground station with a given class of | |||
| service. On the forward link, this is done locally in the ground | service. On the FL, this is done locally in the ground station; on | |||
| station; on the reverse link, a dedicated contention-free control | the RL, a dedicated contention-free control channel is used (the | |||
| channel is used (the Dedicated Control Channel (DCCH); roughly 83 | Dedicated Control Channel (DCCH); roughly 83 bits every 60 ms). A | |||
| bits every 60 ms). A resource allocation is always announced in the | resource allocation is always announced in the control channel of the | |||
| control channel of the forward link (Common Control Channel (CCCH); | FL (Common Control Channel (CCCH); variable sized). Due to the | |||
| variable sized). Due to the spacing of the reverse link control | spacing of the RL control channels of every 60 ms, a medium access | |||
| channels of every 60 ms, a medium access delay in the same order of | delay in the same order of magnitude is to be expected. | |||
| magnitude is to be expected. | ||||
| Resources can also be requested "permanently". The permanent | Resources can also be requested "permanently". The permanent | |||
| resource request mechanism supports requesting recurring resources at | resource request mechanism supports requesting recurring resources at | |||
| given time intervals. A permanent resource request has to be | given time intervals. A permanent resource request has to be | |||
| canceled by the user (or by the ground station, which is always in | canceled by the user (or by the ground station, which is always in | |||
| control). User data transmissions over LDACS are therefore always | control). User data transmissions over LDACS are therefore always | |||
| scheduled by the ground station, while control data uses statically | scheduled by the ground station, while control data uses statically | |||
| (i.e., at net entry) allocated recurring resources (DCCH and CCCH). | (i.e., at net entry) allocated recurring resources (DCCH and CCCH). | |||
| The current specification documents specify no scheduling algorithm. | The current specification documents specify no scheduling algorithm. | |||
| However, performance evaluations so far have used strict priority | However, performance evaluations so far have used strict priority | |||
| scheduling and round robin for equal priorities for simplicity. In | scheduling and round robin for equal priorities for simplicity. In | |||
| the current prototype implementations, LDACS classes of service are | the current prototype implementations, LDACS classes of service are | |||
| thus realized as priorities of medium access and not as flows. Note | thus realized as priorities of medium access and not as flows. Note | |||
| that this can starve out low-priority flows. However, this is not | that this can starve out low-priority flows. However, this is not | |||
| seen as a big problem since safety-related messages always go first | seen as a big problem since safety-related messages always go first | |||
| in any case. Scheduling of reverse link resources is done in | in any case. Scheduling of RL resources is done in physical Protocol | |||
| physical Protocol Data Units (PDU) of 112 bits (or larger if more | Data Units (PDU) of 112 bits (or larger if more aggressive coding and | |||
| aggressive coding and modulation is used). Scheduling on the forward | modulation is used). Scheduling on the FL is done byte wise since | |||
| link is done byte wise since the forward link is transmitted | the FL is transmitted continuously by the ground station. | |||
| continuously by the ground station. | ||||
| In order to support diversity, LDACS supports handovers to other | In order to support diversity, LDACS supports handovers to other | |||
| ground stations on different channels. Handovers may be initiated by | ground stations on different channels. Handovers may be initiated by | |||
| the aircraft (break before make) or by the ground station (make | the aircraft (break before make) or by the ground station (make | |||
| before break). Beyond this, FCI diversity shall be implemented by | before break). Beyond this, FCI diversity shall be implemented by | |||
| the multi-link concept. | the multi-link concept. | |||
| 8. IANA Considerations | 8. IANA Considerations | |||
| This document has no IANA actions. | This document has no IANA actions. | |||
| skipping to change at line 2565 ¶ | skipping to change at line 2562 ¶ | |||
| coap-03>. | coap-03>. | |||
| [IEEE802.15.4] | [IEEE802.15.4] | |||
| IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE | IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE | |||
| Std 802.15.4-2015, DOI 10.1109/IEEESTD.2016.7460875, | Std 802.15.4-2015, DOI 10.1109/IEEESTD.2016.7460875, | |||
| <https://doi.org/10.1109/IEEESTD.2016.7460875>. | <https://doi.org/10.1109/IEEESTD.2016.7460875>. | |||
| [IEEE802.11] | [IEEE802.11] | |||
| IEEE, "IEEE Standard for Information Technology -- | IEEE, "IEEE Standard for Information Technology -- | |||
| Telecommunications and Information Exchange between | Telecommunications and Information Exchange between | |||
| Systems - Local and Metropolitan Area Networks -- Specific | Systems Local and Metropolitan Area Networks -- Specific | |||
| Requirements - Part 11: Wireless LAN Medium Access Control | Requirements Part 11: Wireless LAN Medium Access Control | |||
| (MAC) and Physical Layer (PHY) Specifications", IEEE | (MAC) and Physical Layer (PHY) Specifications", IEEE | |||
| Std 802.11-2020, DOI 10.1109/IEEESTD.2021.9363693, 2020, | Std 802.11-2024, DOI 10.1109/IEEESTD.2025.10979691, 2024, | |||
| <https://ieeexplore.ieee.org/document/9363693>. | <https://ieeexplore.ieee.org/document/10979691>. | |||
| [IEEE802.11ax] | [IEEE802.11ax] | |||
| IEEE, "IEEE Standard for Information Technology -- | IEEE, "IEEE Standard for Information Technology -- | |||
| Telecommunications and Information Exchange between | Telecommunications and Information Exchange between | |||
| Systems Local and Metropolitan Area Networks -- Specific | Systems Local and Metropolitan Area Networks -- Specific | |||
| Requirements Part 11: Wireless LAN Medium Access Control | Requirements Part 11: Wireless LAN Medium Access Control | |||
| (MAC) and Physical Layer (PHY) Specifications Amendment 1: | (MAC) and Physical Layer (PHY) Specifications Amendment 1: | |||
| Enhancements for High-Efficiency WLAN", IEEE Std 802.11ax- | Enhancements for High-Efficiency WLAN", IEEE Std 802.11ax- | |||
| 2021, DOI 10.1109/IEEESTD.2021.9442429, 2021, | 2021, DOI 10.1109/IEEESTD.2021.9442429, 2021, | |||
| <https://ieeexplore.ieee.org/document/9442429>. | <https://ieeexplore.ieee.org/document/9442429>. | |||
| skipping to change at line 2841 ¶ | skipping to change at line 2838 ¶ | |||
| [IEEE802.1Qcc] | [IEEE802.1Qcc] | |||
| IEEE, "IEEE Standard for Local and metropolitan area | IEEE, "IEEE Standard for Local and metropolitan area | |||
| networks -- Bridges and Bridged Networks -- Amendment 31: | networks -- Bridges and Bridged Networks -- Amendment 31: | |||
| Stream Reservation Protocol (SRP) Enhancements and | Stream Reservation Protocol (SRP) Enhancements and | |||
| Performance Improvements", IEEE Std 802.1Qcc-2018, | Performance Improvements", IEEE Std 802.1Qcc-2018, | |||
| DOI 10.1109/IEEESTD.2018.8514112, | DOI 10.1109/IEEESTD.2018.8514112, | |||
| <https://ieeexplore.ieee.org/document/8514112>. | <https://ieeexplore.ieee.org/document/8514112>. | |||
| [IEEE802.3] | [IEEE802.3] | |||
| IEEE, "IEEE Standard for Ethernet", IEEE Std 802.3-2018, | IEEE, "IEEE Standard for Ethernet", IEEE Std 802.3-2022, | |||
| DOI 10.1109/IEEESTD.2018.8457469, | DOI 10.1109/IEEESTD.2022.9844436, | |||
| <https://ieeexplore.ieee.org/document/8457469>. | <https://ieeexplore.ieee.org/document/9844436>. | |||
| [TSN5G] 5G-ACIA, "Integration of 5G with Time-Sensitive Networking | [TSN5G] 5G-ACIA, "Integration of 5G with Time-Sensitive Networking | |||
| for Industrial Communications", 5G-ACIA White Paper, | for Industrial Communications", 5G-ACIA White Paper, | |||
| <https://5g-acia.org/whitepapers/integration-of-5g-with- | <https://5g-acia.org/whitepapers/integration-of-5g-with- | |||
| time-sensitive-networking-for-industrial-communications>. | time-sensitive-networking-for-industrial-communications>. | |||
| [MAE18] Maeurer, N. and A. Bilzhause, "A Cybersecurity | [MAE18] Maeurer, N. and A. Bilzhause, "A Cybersecurity | |||
| Architecture for the L-band Digital Aeronautical | Architecture for the L-band Digital Aeronautical | |||
| Communications System (LDACS)", 2018 IEEE/AIAA 37th | Communications System (LDACS)", 2018 IEEE/AIAA 37th | |||
| Digital Avionics Systems Conference (DASC), pp. 1-10, | Digital Avionics Systems Conference (DASC), pp. 1-10, | |||
| skipping to change at line 2982 ¶ | skipping to change at line 2979 ¶ | |||
| Mallory Knodel, Ron Bonica, Ketan Talaulikar, Éric Vyncke, and Carlos | Mallory Knodel, Ron Bonica, Ketan Talaulikar, Éric Vyncke, and Carlos | |||
| J. Bernardos. | J. Bernardos. | |||
| Contributors | Contributors | |||
| This document aggregates articles from authors specialized in each | This document aggregates articles from authors specialized in each | |||
| technology. Beyond the main authors listed on the front page, the | technology. Beyond the main authors listed on the front page, the | |||
| following contributors proposed additional text and refinements that | following contributors proposed additional text and refinements that | |||
| improved the document. | improved the document. | |||
| * Georgios Z. Papadopoulos contributed to the TSCH section. | * Georgios Z. Papadopoulos contributed to Section 5 ("IEEE 802.15.4 | |||
| Time-Slotted Channel Hopping (TSCH)"). | ||||
| * Nils Maeurer and Thomas Graeupl contributed to the LDACS section. | * Nils Maeurer and Thomas Graeupl contributed to Section 7 ("L-Band | |||
| Digital Aeronautical Communications System (LDACS)"). | ||||
| * Torsten Dudda, Alexey Shapin, and Sara Sandberg contributed to the | * Torsten Dudda, Alexey Shapin, and Sara Sandberg contributed to | |||
| 5G section. | Section 6 ("5G"). | |||
| * Rocco Di Taranto contributed to the Wi-Fi section. | * Rocco Di Taranto contributed to Section 4 ("IEEE 802.11"). | |||
| * Rute Sofia contributed to the Introduction and Terminology | * Rute Sofia contributed to Section 1 ("Introduction") and Section 2 | |||
| sections. | ("Terminology"). | |||
| Authors' Addresses | Authors' Addresses | |||
| Pascal Thubert (editor) | Pascal Thubert (editor) | |||
| Independent | ||||
| 06330 Roquefort-les-Pins | 06330 Roquefort-les-Pins | |||
| France | France | |||
| Email: pascal.thubert@gmail.com | Email: pascal.thubert@gmail.com | |||
| Dave Cavalcanti | Dave Cavalcanti | |||
| Intel Corporation | Intel Corporation | |||
| 2111 NE 25th Ave | 2111 NE 25th Ave | |||
| Hillsboro, OR 97124 | Hillsboro, OR 97124 | |||
| United States of America | United States of America | |||
| Phone: 503 712 5566 | Phone: 503 712 5566 | |||
| End of changes. 87 change blocks. | ||||
| 270 lines changed or deleted | 270 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. | ||||