idnits 2.17.1 draft-ietf-raw-technologies-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 6 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 885: '... the 6TiSCH LLN MUST be swapped into ...' RFC 2119 keyword, line 947: '...he configuration MUST enable correlate...' RFC 2119 keyword, line 949: '...n a'AND'relation MUST be configurable ...' RFC 2119 keyword, line 959: '... transmissions SHOULD NOT be attempt...' RFC 2119 keyword, line 964: '... any of branches MUST be attempted reg...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (3 August 2021) is 996 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-raw-architecture-00 == Outdated reference: A later version (-12) exists of draft-ietf-roll-nsa-extension-10 == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-10 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RAW P. Thubert, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Informational D. Cavalcanti 5 Expires: 4 February 2022 Intel 6 X. Vilajosana 7 Universitat Oberta de Catalunya 8 C. Schmitt 9 Research Institute CODE, UniBwM 10 J. Farkas 11 Ericsson 12 3 August 2021 14 Reliable and Available Wireless Technologies 15 draft-ietf-raw-technologies-04 17 Abstract 19 This document presents a series of recent technologies that are 20 capable of time synchronization and scheduling of transmission, 21 making them suitable to carry time-sensitive flows with high 22 reliability and availability. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 4 February 2022. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. On Scheduling . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1. Benefits of Scheduling on Wires . . . . . . . . . . . . . 5 61 3.2. Benefits of Scheduling on Wireless . . . . . . . . . . . 5 62 4. IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.1. Provenance and Documents . . . . . . . . . . . . . . . . 6 64 4.2. 802.11ax High Efficiency (HE) . . . . . . . . . . . . . . 8 65 4.2.1. General Characteristics . . . . . . . . . . . . . . . 8 66 4.2.2. Applicability to deterministic flows . . . . . . . . 10 67 4.3. 802.11be Extreme High Throughput (EHT) . . . . . . . . . 11 68 4.3.1. General Characteristics . . . . . . . . . . . . . . . 12 69 4.3.2. Applicability to deterministic flows . . . . . . . . 12 70 4.4. 802.11ad and 802.11ay (mmWave operation) . . . . . . . . 13 71 4.4.1. General Characteristics . . . . . . . . . . . . . . . 14 72 4.4.2. Applicability to deterministic flows . . . . . . . . 14 73 5. IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . 14 74 5.1. Provenance and Documents . . . . . . . . . . . . . . . . 14 75 5.2. TimeSlotted Channel Hopping . . . . . . . . . . . . . . . 16 76 5.2.1. General Characteristics . . . . . . . . . . . . . . . 16 77 5.2.2. Applicability to Deterministic Flows . . . . . . . . 18 78 6. 5G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 79 6.1. Provenance and Documents . . . . . . . . . . . . . . . . 32 80 6.2. General Characteristics . . . . . . . . . . . . . . . . . 34 81 6.3. Deployment and Spectrum . . . . . . . . . . . . . . . . . 35 82 6.4. Applicability to Deterministic Flows . . . . . . . . . . 36 83 6.4.1. System Architecture . . . . . . . . . . . . . . . . . 36 84 6.4.2. Overview of The Radio Protocol Stack . . . . . . . . 38 85 6.4.3. Radio (PHY) . . . . . . . . . . . . . . . . . . . . . 39 86 6.4.4. Scheduling and QoS (MAC) . . . . . . . . . . . . . . 41 87 6.4.5. Time-Sensitive Networking (TSN) Integration . . . . . 43 88 6.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 46 89 7. L-band Digital Aeronautical Communications System . . . . . . 47 90 7.1. Provenance and Documents . . . . . . . . . . . . . . . . 48 91 7.2. General Characteristics . . . . . . . . . . . . . . . . . 49 92 7.3. Deployment and Spectrum . . . . . . . . . . . . . . . . . 50 93 7.4. Applicability to Deterministic Flows . . . . . . . . . . 50 94 7.4.1. System Architecture . . . . . . . . . . . . . . . . . 51 95 7.4.2. Overview of The Radio Protocol Stack . . . . . . . . 51 96 7.4.3. Radio (PHY) . . . . . . . . . . . . . . . . . . . . . 52 97 7.4.4. Scheduling, Frame Structure and QoS (MAC) . . . . . . 53 98 7.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 55 99 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 100 9. Security Considerations . . . . . . . . . . . . . . . . . . . 56 101 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 56 102 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 56 103 12. Normative References . . . . . . . . . . . . . . . . . . . . 56 104 13. Informative References . . . . . . . . . . . . . . . . . . . 57 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66 107 1. Introduction 109 When used in math or philosophy, the term "deterministic" generally 110 refers to a perfection where all aspect are understood and 111 predictable. A perfectly Deterministic Network would ensure that 112 every packet reach its destination following a predetermined path 113 along a predefined schedule to be delivered at the exact due time. 114 In a real and imperfect world, a Deterministic Network must highly 115 predictable, which is a combination of reliability and availability. 116 On the one hand the network must be reliable, meaning that it will 117 perform as expected for all packets and in particular that it will 118 always deliver the packet at the destination in due time. On the 119 other hand, the network must be available, meaning that it is 120 resilient to any single outage, whether the cause is a software, a 121 hardware or a transmission issue. 123 RAW (Reliable and Available Wireless) is an effort to provide 124 Deterministic Networking on across a path that include a wireless 125 physical layer. Making Wireless Reliable and Available is even more 126 challenging than it is with wires, due to the numerous causes of loss 127 in transmission that add up to the congestion losses and the delays 128 caused by overbooked shared resources. In order to maintain a 129 similar quality of service along a multihop path that is composed of 130 wired and wireless hops, additional methods that are specific to 131 wireless must be leveraged to combat the sources of loss that are 132 also specific to wireless. 134 Such wireless-specific methods include per-hop retransmissions (HARQ) 135 and P2MP overhearing whereby multiple receivers are scheduled to 136 receive the same transmission, which balances the adverse effects of 137 the transmission losses that are experienced when a radio is used as 138 pure P2P. Those methods are collectively referred to as Packet 139 (hybrid) ARQ, Replication, Elimination and Ordering (PAREO) functions 140 in the "Reliable and Available Wireless Architecture/Framework" 141 [I-D.ietf-raw-architecture]. 143 2. Terminology 145 This specification uses several terms that are uncommon on protocols 146 that ensure bets effort transmissions for stochastics flows, such as 147 found in the traditional Internet and other statistically multiplexed 148 packet networks. 150 ARQ: Automatic Repeat Request, enabling an acknowledged transmission 151 and retries. ARQ is a typical model at Layer-2 on a wireless 152 medium. It is typically avoided end-to-end on deterministic flows 153 because it introduces excessive indetermination in latency, but a 154 limited number of retries within a bounded time may be used over a 155 wireless link and yet respect end-to-end constraints. 157 Availability: Availability is a measure of the relative amount of 158 time where a path operates in stated condition, in other words 159 (uptime)/(uptime+downtime). 161 Available: That is exempt of unscheduled outage, the expectation for 162 a network being that the flow is maintained in the face of any 163 single breakage. 165 Deterministic Networking We refer to section 2 of [RFC8557] for this 166 term. 168 FEC: Forward error correction, sending redundant coded data to help 169 the receiver recover transmission errors without the delays 170 incurred with ARQ. 172 HARQ: Hybrid ARQ, a combination of FEC and ARQ. 174 PCE: Path Computation Element. 176 PREOF : DetNet Packet Replication, Elimination and Ordering 177 Functions. 179 PAREO: Packet (hybrid) ARQ, Replication, Elimination and Ordering. 180 PAREO is a superset Of DetNet's PREOF that includes radio-specific 181 techniques such as short range broadcast, MUMIMO, constructive 182 interference and overhearing, which can be leveraged separately or 183 combined to increase the reliability. 185 Reliability: Reliability is a measure of the probability that an 186 item will perform its intended function for a specified interval 187 under stated conditions. For RAW, the service that is expected is 188 delivery within a bounded latency and a failure is when the packet 189 is either lost or delivered too late. 191 Track: A networking graph that can be used as a "path" to transport 192 RAW packets with equivalent treatment; a Track may fork and rejoin 193 to enable the PAREO operations. 195 3. On Scheduling 197 The operations of a Deterministic Network often rely on precisely 198 applying a tight schedule, in order to avoid collision loss and 199 guarantee the worst-case time of delivery. To achieve this, there 200 must be a shared sense of time throughout the network. The sense of 201 time is usually provided by the lower layer and is not in scope for 202 RAW. 204 3.1. Benefits of Scheduling on Wires 206 A network is reliable when the statistical effects that affect the 207 packet transmission are eliminated. This involves maintaining at all 208 time the amount of critical packets within the physical capabilities 209 of the hardware and that of the radio medium. This is achieved by 210 controlling the use of time-shared resources such as CPUs and 211 buffers, by shaping the flows and by scheduling the time of 212 transmission of the packets that compose the flow at every hop. 214 Equipment failure, such as an access point rebooting, a broken radio 215 adapter, or a permanent obstacle to the transmission, is a secondary 216 source of packet loss. When a breakage occurs, multiple packets are 217 lost in a row before the flows are rerouted or the system may 218 recover. This is not acceptable for critical applications such as 219 related to safety. A typical process control loop will tolerate an 220 occasional packet loss, but a loss of several packets in a row will 221 cause an emergency stop (e.g., after 4 packets lost, within a period 222 of 1 second). 224 Network Availability is obtained by making the transmission resilient 225 against hardware failures and radio transmission losses due to 226 uncontrolled events such as co-channel interferers, multipath fading 227 or moving obstacles. The best results are typically achieved by 228 pseudo randomly cumulating all forms of diversity, in the spatial 229 domain with replication and elimination, in the time domain with ARQ 230 and diverse scheduled transmissions, and in the frequency domain with 231 frequency hopping or channel hopping between frames. 233 3.2. Benefits of Scheduling on Wireless 235 In addition to the benefits listed in Section 3.1, scheduling 236 transmissions provides specific value to the wireless medium. 238 On the one hand, scheduling avoids collisions between scheduled 239 transmissions and can ensure both time and frequency diversity 240 between retries in order to defeat co-channel interference from un- 241 controlled transmitters as well as multipath fading. Transmissions 242 can be scheduled on multiple channels in parallel, which enables to 243 use the full available spectrum while avoiding the hidden terminal 244 problem, e.g., when the next packet in a same flow interferes on a 245 same channel with the previous one that progressed a few hops 246 farther. 248 On the other hand, scheduling optimizes the bandwidth usage: compared 249 to classical Collision Avoidance techniques, there is no blank time 250 related to inter-frame space (IFS) and exponential back-off in 251 scheduled operations. A minimal Clear Channel Assessment may be 252 needed to comply with the local regulations such as ETSI 300-328, but 253 that will not detect a collision when the senders are synchronized. 254 And because scheduling allows a time-sharing operation, there is no 255 limit to the ratio of isolated critical traffic. 257 Finally, scheduling plays a critical role to save energy. In IOT, 258 energy is the foremost concern, and synchronizing sender and listener 259 enables to always maintain them in deep sleep when there is no 260 scheduled transmission. This avoids idle listening and long 261 preambles and enables long sleep periods between traffic and 262 resynchronization, allowing battery-operated nodes to operate in a 263 mesh topology for multiple years. 265 4. IEEE 802.11 267 4.1. Provenance and Documents 269 With an active portfolio of nearly 1,300 standards and projects under 270 development, IEEE is a leading developer of industry standards in a 271 broad range of technologies that drive the functionality, 272 capabilities, and interoperability of products and services, 273 transforming how people live, work, and communicate. 275 The IEEE 802 LAN/MAN Standards Committee (SC) develops and maintains 276 networking standards and recommended practices for local, 277 metropolitan, and other area networks, using an open and accredited 278 process, and advocates them on a global basis. The most widely used 279 standards are for Ethernet, Bridging and Virtual Bridged LANs 280 Wireless LAN, Wireless PAN, Wireless MAN, Wireless Coexistence, Media 281 Independent Handover Services, and Wireless RAN. An individual 282 Working Group provides the focus for each area. Standards produced 283 by the IEEE 802 SC are freely available from the IEEE GET Program 284 after they have been published in PDF for six months. 286 The IEEE 802.11 Wireless LAN (WLAN) standards define the underlying 287 MAC and PHY layers for the Wi-Fi technology. Wi-Fi/802.11 is one of 288 the most successful wireless technologies, supporting many 289 application domains. While previous 802.11 generations, such as 290 802.11n and 802.11ac, have focused mainly on improving peak 291 throughput, more recent generations are also considering other 292 performance vectors, such as efficiency enhancements for dense 293 environments in 802.11ax, latency, reliability and enhancements 294 supporting Time-Sensitive Networking (TSN) [IEEE802.1TSN] 295 capabilities in P802.11be. 297 IEEE Std 802.11-2012 introduced support for TSN time synchronization 298 based on IEEE 802.1AS over 802.11 Timing Measurement protocol. IEEE 299 Std 802.11-2016 extended the 802.1AS operation over 802.11 Fine 300 Timing Measurement (FTM), as well as the Stream Reservation Protocol 301 (IEEE 802.1Qat). 802.11 WLANs can also be part of a 802.1Q bridged 302 networks with enhancements enabled by the 802.11ak amendment now 303 retroffitted in IEEE Std 802.11-2020. Traffic classification based 304 on 802.1Q VLAN tags is also supported in 802.11. Other 802.1 TSN 305 capabilities such as 802.1Qbv and 802.1CB, which are media agnostic, 306 can already operate over 802.11. The IEEE Std 802.11ax-2021 adds new 307 scheduling capabilities that can enhance the timeliness performance 308 in the 802.11 MAC and achieve lower bounded latency. The IEEE 309 802.11be is undergoing efforts to enhance the support for 802.1 TSN 310 capabilities especially related to worst-case latency, reliability 311 and availability. The IEEE 802.11 working group has been working in 312 collaboration with the IEEE 802.1 working group for several years 313 extending some 802.1 features over 802.11. As with any wireless 314 media, 802.11 imposes new constraints and restrictions to TSN-grade 315 QoS, and tradeoffs between latency and reliability guarantees must be 316 considered as well as managed deployment requirements. An overview 317 of 802.1 TSN capabilities and challenges for their extensions to 318 802.11 are discussed in [Cavalcanti_2019]. 320 Wi-Fi Alliance (WFA) is the worldwide network of companies that 321 drives global Wi-Fi adoption and evolution through thought 322 leadership, spectrum advocacy, and industry-wide collaboration. The 323 WFA work helps ensure that Wi-Fi devices and networks provide users 324 the interoperability, security, and reliability they have come to 325 expect. 327 The following [IEEE Std 802.11] specifications/certifications are 328 relevant in the context of reliable and available wireless services 329 and support for time-sensitive networking capabilities: 331 Time Synchronization: IEEE802.11-2016 with IEEE802.1AS; WFA TimeSync 332 Certification. 334 Congestion Control: IEEE Std 802.11-2016 Admission Control; WFA 335 Admission Control. 337 Security: WFA Wi-Fi Protected Access, WPA2 and WPA3. 339 Interoperating with IEEE802.1Q bridges: IEEE Std 802.11-2020 340 incorporating 802.11ak. 342 Stream Reservation Protocol (part of [IEEE Std 802.1Qat]): AIEEE802. 343 11-2016 345 Scheduled channel access: IEEE802.11ad Enhancements for very high 346 throughput in the 60 GHz band [IEEE Std 802.11ad]. 348 802.11 Real-Time Applications: Topic Interest Group (TIG) ReportDoc 349 [IEEE_doc_11-18-2009-06]. 351 In addition, major amendments being developed by the IEEE802.11 352 Working Group include capabilities that can be used as the basis for 353 providing more reliable and predictable wireless connectivity and 354 support time-sensitive applications: 356 IEEE 802.11ax D4.0: Enhancements for High Efficiency (HE). [IEEE Std 357 802.11ax] 359 IEEE 802.11be Extreme High Throughput (EHT). [IEEE 802.11be WIP] 361 IEE 802.11ay Enhanced throughput for operation in license-exempt 362 bands above 45 GHz. [IEEE Std 802.11ay] 364 The main 802.11ax and 802.11be capabilities and their relevance to 365 RAW are discussed in the remainder of this document. 367 4.2. 802.11ax High Efficiency (HE) 369 4.2.1. General Characteristics 371 The next generation Wi-Fi (Wi-Fi 6) is based on the IEEE802.11ax 372 amendment [IEEE Std 802.11ax], which includes new capabilities to 373 increase efficiency, control and reduce latency. Some of the new 374 features include higher order 1024-QAM modulation, support for uplink 375 multi-user MIMO, OFDMA, trigger-based access and Target Wake time 376 (TWT) for enhanced power savings. The OFDMA mode and trigger-based 377 access enable the AP, after reserving the channel using the clear 378 channel assessment procedure for a given duration, to schedule multi- 379 user transmissions, which is a key capability required to increase 380 latency predictability and reliability for time-sensitive flows. 381 802.11ax can operate in up to 160 MHz channels and it includes 382 support for operation in the new 6 GHz band, which is expected to be 383 open to unlicensed use by the FCC and other regulatory agencies 384 worldwide. 386 4.2.1.1. Multi-User OFDMA and Trigger-based Scheduled Access 388 802.11ax introduced a new orthogonal frequency-division multiple 389 access (OFDMA) mode in which multiple users can be scheduled across 390 the frequency domain. In this mode, the Access Point (AP) can 391 initiate multi-user (MU) Uplink (UL) transmissions in the same PHY 392 Protocol Data Unit (PPDU) by sending a trigger frame. This 393 centralized scheduling capability gives the AP much more control of 394 the channel in its Basic Service Set (BSS) and it can remove 395 contention between associated stations for uplink transmissions, 396 therefore reducing the randomness caused by CSMA-based access between 397 stations within the same BSS. The AP can also transmit 398 simultaneously to multiple users in the downlink direction by using a 399 Downlink (DL) MU OFDMA PPDU. In order to initiate a contention free 400 Transmission Opportunity (TXOP) using the OFDMA mode, the AP still 401 follows the typical listen before talk procedure to acquire the 402 medium, which ensures interoperability and compliance with unlicensed 403 band access rules. However, 802.11ax also includes a multi-user 404 Enhanced Distributed Channel Access (MU-EDCA) capability, which 405 allows the AP to get higher channel access priority than other 406 devices in its BSS. 408 4.2.1.2. Improved PHY Robustness 410 The 802.11ax PHY can operate with 0.8, 1.6 or 3.2 microsecond guard 411 interval (GI). The larger GI options provide better protection 412 against multipath, which is expected to be a challenge in industrial 413 environments. The possibility to operate with smaller resource units 414 (e.g. 2 MHz) enabled by OFDMA also helps reduce noise power and 415 improve SNR, leading to better packet error rate (PER) performance. 417 802.11ax supports beamforming as in 802.11ac, but introduces UL MU 418 MIMO, which helps improve reliability. The UL MU MIMO capability is 419 also enabled by the trigger based access operation in 802.11ax. 421 4.2.1.3. Support for 6GHz band 423 The 802.11ax specification [IEEE Std 802.11ax] includes support for 424 operation in the new 6 GHz band. Given the amount of new spectrum 425 available as well as the fact that no legacy 802.11 device (prior 426 802.11ax) will be able to operate in this new band, 802.11ax 427 operation in this new band can be even more efficient. 429 4.2.2. Applicability to deterministic flows 431 TSN capabilities, as defined by the IEEE 802.1 TSN standards, provide 432 the underlying mechanism for supporting deterministic flows in a 433 Local Area Network (LAN). The 802.11 working group has incorporated 434 support for absolute time synchronization to extend the TSN 802.1AS 435 protocol so that time-sensitive flow can experience precise time 436 synchronization when operating over 802.11 links. As IEEE 802.11 and 437 IEEE 802.1 TSN are both based on the IEEE 802 architecture, 802.11 438 devices can directly implement TSN capabilities without the need for 439 a gateway/translation protocol. Basic features required for 440 operation in a 802.1Q LAN are already enabled for 802.11. Some TSN 441 capabilities, such as 802.1Qbv, can already operate over the existing 442 802.11 MAC SAP [Sudhakaran2021]. Nevertheless, the IEEE 802.11 MAC/ 443 PHY requires further extensions to improve the operation of IEEE 444 802.1 TSN features and achieve better performance metrics 445 [Cavalcanti1287]. 447 TSN capabilities supported over 802.11 (which also extends to 448 802.11ax), include: 450 1. 802.1AS based Time Synchronization (other time synchronization 451 techniques may also be used) 453 2. Interoperating with IEEE802.1Q bridges 455 3. Time-sensitive Traffic Stream Classification 457 The existing 802.11 TSN capabilities listed above, and the 802.11ax 458 OFDMA and AP-controlled access within a BSS provide a new set of 459 tools to better serve time-sensitive flows. However, it is important 460 to understand the tradeoffs and constraints associated with such 461 capabilities, as well as redundancy and diversity mechanisms that can 462 be used to provide more predictable and reliable performance. 464 4.2.2.1. 802.11 Managed network operation and admission control 466 Time-sensitive applications and TSN standards are expected to operate 467 under a managed network (e.g. industrial/enterprise network). Thus, 468 the Wi-Fi operation must also be carefully managed and integrated 469 with the overall TSN management framework, as defined in the 470 [IEEE8021Qcc] specification. 472 Some of the random-access latency and interference from legacy/ 473 unmanaged devices can be reduced under a centralized management mode 474 as defined in [IEEE8021Qcc]. 476 Existing traffic stream identification, configuration and admission 477 control procedures defined in [IEEE Std 802.11] QoS mechanism can be 478 re-used. However, given the high degree of determinism required by 479 many time-sensitive applications, additional capabilities to manage 480 interference and legacy devices within tight time-constraints need to 481 be explored. 483 4.2.2.2. Scheduling for bounded latency and diversity 485 As discussed earlier, the [IEEE Std 802.11ax] OFDMA mode introduces 486 the possibility of assigning different RUs (frequency resources) to 487 users within a PPDU. Several Resource Unit (RU) sizes are defined in 488 the specification (26, 52, 106, 242, 484, 996 subcarriers). In 489 addition, the AP can also decide on MCS and grouping of users within 490 a given OFMDA PPDU. Such flexibility can be leveraged to support 491 time-sensitive applications with bounded latency, especially in a 492 managed network where stations can be configured to operate under the 493 control of the AP, in a controlled environment (which contains only 494 devices operating on the unlicensed band installed by the facility 495 owner and where unexpected interference from other systems and/or 496 radio access technologies only sporadically happens), or in a 497 deployment where channel/link redundancy is used to reduce the impact 498 of unmanaged devices/interference. 500 When the network in lightly loaded, it is possible to achieve 501 latencies under 1 msec when Wi-Fi is operated in contention-based 502 (i.e., without OFDMA) mode. It is also has been shown that it is 503 possible to achieve 1 msec latencies in controlled environment with 504 higher efficiency when multi-user transmissions are used (enabled by 505 OFDMA operation) [Cavalcanti_2019]. Obviously, there are latency, 506 reliability and capacity tradeoffs to be considered. For instance, 507 smaller RUs result in longer transmission durations, which may impact 508 the minimal latency that can be achieved, but the contention latency 509 and randomness elimination in an interference-free environment due to 510 multi-user transmission is a major benefit of the OFDMA mode. 512 The flexibility to dynamically assign RUs to each transmission also 513 enables the AP to provide frequency diversity, which can help 514 increase reliability. 516 4.3. 802.11be Extreme High Throughput (EHT) 517 4.3.1. General Characteristics 519 The ongoing [IEEE 802.11be WIP] project is the next major 802.11 520 amendment (after IEEE Std 802.11ax-2021) for operation in the 2.4, 5 521 and 6 GHz bands. 802.11be is expected to include new PHY and MAC 522 features and it is targeting extremely high throughput (at least 30 523 Gbps), as well as enhancements to worst case latency and jitter. It 524 is also expected to improve the integration with 802.1 TSN to support 525 time-sensitive applications over Ethernet and Wireless LANs. 527 The 802.11be Task Group started its operation in May 2019, therefore, 528 detailed information about specific features is not yet available. 529 Only high level candidate features have been discussed so far, 530 including: 532 1. 320MHz bandwidth and more efficient utilization of non-contiguous 533 spectrum. 535 2. Multi-band/multi-channel aggregation and operation. 537 3. 16 spatial streams and related MIMO enhancements. 539 4. Multi-Access Point (AP) Coordination. 541 5. Enhanced link adaptation and retransmission protocol, e.g. 542 Hybrid Automatic Repeat Request (HARQ). 544 6. Any required adaptations to regulatory rules for the 6 GHz 545 spectrum. 547 4.3.2. Applicability to deterministic flows 549 The 802.11 Real-Time Applications (RTA) Topic Interest Group (TIG) 550 provided detailed information on use cases, issues and potential 551 solution directions to improve support for time-sensitive 552 applications in 802.11. The RTA TIG report [IEEE_doc_11-18-2009-06] 553 was used as input to the 802.11be project scope. 555 Improvements for worst-case latency, jitter and reliability were the 556 main topics identified in the RTA report, which were motivated by 557 applications in gaming, industrial automation, robotics, etc. The 558 RTA report also highlighted the need to support additional TSN 559 capabilities, such as time-aware (802.1Qbv) shaping and packet 560 replication and elimination as defined in 802.1CB. 562 802.11be is expected to build on and enhance 802.11ax capabilities to 563 improve worst case latency and jitter. Some of the enhancement areas 564 are discussed next. 566 4.3.2.1. Enhanced scheduled operation for bounded latency 568 In addition to the throughput enhancements, 802.11be will leverage 569 the trigger-based scheduled operation enabled by 802.11ax to provide 570 efficient and more predictable medium access. 802.11be is expected to 571 include enhancements to reduce overhead and enable more efficient 572 operation in managed network deployments [IEEE_doc_11-19-0373-00]. 574 4.3.2.2. Multi-AP coordination 576 Multi-AP coordination is one of the main new candidate features in 577 802.11be. It can provide benefits in throughput and capacity and has 578 the potential to address some of the issues that impact worst case 579 latency and reliability. Multi-AP coordination is expected to 580 address the contention due to overlapping Basic Service Sets (OBSS), 581 which is one of the main sources of random latency variations. 582 802.11be can define methods to enable better coordination between 583 APs, for instance, in a managed network scenario, in order to reduce 584 latency due to unmanaged contention. 586 Several multi-AP coordination approaches have been discussed with 587 different levels of complexities and benefits, but specific 588 coordination methods have not yet been defined. 590 4.3.2.3. Multi-band operation 592 802.11be will introduce new features to improve operation over 593 multiple bands and channels. By leveraging multiple bands/channels, 594 802.11be can isolate time-sensitive traffic from network congestion, 595 one of the main causes of large latency variations. In a managed 596 802.11be network, it should be possible to steer traffic to certain 597 bands/channels to isolate time-sensitive traffic from other traffic 598 and help achieve bounded latency. 600 4.4. 802.11ad and 802.11ay (mmWave operation) 601 4.4.1. General Characteristics 603 The IEEE 802.11ad amendment defines PHY and MAC capabilities to 604 enable multi-Gbps throughput in the 60 GHz millimeter wave (mmWave) 605 band. The standard addresses the adverse mmWave signal propagation 606 characteristics and provides directional communication capabilities 607 that take advantage of beamforming to cope with increased 608 attenuation. An overview of the 802.11ad standard can be found in 609 [Nitsche_2015] . 611 The IEEE 802.11ay is currently developing enhancements to the 612 802.11ad standard to enable the next generation mmWave operation 613 targeting 100 Gbps throughput. Some of the main enhancements in 614 802.11ay include MIMO, channel bonding, improved channel access and 615 beamforming training. An overview of the 802.11ay capabilities can 616 be found in [Ghasempour_2017] 618 4.4.2. Applicability to deterministic flows 620 The high data rates achievable with 802.11ad and 802.11ay can 621 significantly reduce latency down to microsecond levels. Limited 622 interference from legacy and other unlicensed devices in 60 GHz is 623 also a benefit. However, directionality and short range typical in 624 mmWave operation impose new challenges such as the overhead required 625 for beam training and blockage issues, which impact both latency and 626 reliability. Therefore, it is important to understand the use case 627 and deployment conditions in order to properly apply and configure 628 802.11ad/ay networks for time sensitive applications. 630 The 802.11ad standard includes a scheduled access mode in which the 631 central controller, after contending and reserving the channel for a 632 dedicated period, can allocate to stations contention-free service 633 periods. This scheduling capability is also available in 802.11ay, 634 and it is one of the mechanisms that can be used to provide bounded 635 latency to time-sensitive data flows in interference-free scenarios. 636 An analysis of the theoretical latency bounds that can be achieved 637 with 802.11ad service periods is provided in [Cavalcanti_2019]. 639 5. IEEE 802.15.4 641 5.1. Provenance and Documents 643 The IEEE802.15.4 Task Group has been driving the development of low- 644 power low-cost radio technology. The IEEE802.15.4 physical layer has 645 been designed to support demanding low-power scenarios targeting the 646 use of unlicensed bands, both the 2.4 GHz and sub GHz Industrial, 647 Scientific and Medical (ISM) bands. This has imposed requirements in 648 terms of frame size, data rate and bandwidth to achieve reduced 649 collision probability, reduced packet error rate, and acceptable 650 range with limited transmission power. The PHY layer supports frames 651 of up to 127 bytes. The Medium Access Control (MAC) sublayer 652 overhead is in the order of 10-20 bytes, leaving about 100 bytes to 653 the upper layers. IEEE802.15.4 uses spread spectrum modulation such 654 as the Direct Sequence Spread Spectrum (DSSS). 656 The Timeslotted Channel Hopping (TSCH) mode was added to the 2015 657 revision of the IEEE802.15.4 standard [IEEE Std 802.15.4]. TSCH is 658 targeted at the embedded and industrial world, where reliability, 659 energy consumption and cost drive the application space. 661 At the IETF, the 6TiSCH Working Group (WG) [TiSCH] deals with best 662 effort operation of IPv6 [RFC8200] over TSCH. 6TiSCH has enabled 663 distributed scheduling to exploit the deterministic access 664 capabilities provided by TSCH. The group designed the essential 665 mechanisms to enable the management plane operation while ensuring 666 IPv6 is supported. Yet the charter did not focus to providing a 667 solution to establish end to end Tracks while meeting quality of 668 service requirements. 6TiSCH, through the RFC8480 [RFC8480] defines 669 the 6P protocol which provides a pairwise negotiation mechanism to 670 the control plane operation. The protocol supports agreement on a 671 schedule between neighbors, enabling distributed scheduling. 6P goes 672 hand-in-hand with a Scheduling Function (SF), the policy that decides 673 how to maintain cells and trigger 6P transactions. The Minimal 674 Scheduling Function (MSF) [RFC9033] is the default SF defined by the 675 6TiSCH WG; other standardized SFs can be defined in the future. MSF 676 extends the minimal schedule configuration, and is used to add child- 677 parent links according to the traffic load. 679 Time sensitive networking on low power constrained wireless networks 680 have been partially addressed by ISA100.11a [ISA100.11a] and 681 WirelessHART [WirelessHART]. Both technologies involve a central 682 controller that computes redundant paths for industrial process 683 control traffic over a TSCH mesh. Moreover, ISA100.11a introduces 684 IPv6 capabilities with a Link-Local Address for the join process and 685 a global unicast addres for later exchanges, but the IPv6 traffic 686 typically ends at a local application gateway and the full power of 687 IPv6 for end-to-end communication is not enabled. Compared to that 688 state of the art, work at the IETF and in particular at RAW could 689 provide additional techniques such as optimized P2P routing, PAREO 690 functions, and end-to-end secured IPv6/CoAP connectivity. 692 The 6TiSCH architecture [RFC9030] identifies different models to 693 schedule resources along so-called Tracks (see Section 5.2.2.2) 694 exploiting the TSCH schedule structure however the focus at 6TiSCH is 695 on best effort traffic and the group was never chartered to produce 696 standard work related to Tracks. 698 Useful References include: 700 1. IEEE Std 802.15.4: "IEEE Std 802.15.4, Part. 15.4: Wireless 701 Medium Access Control (MAC) and Physical Layer (PHY) 702 Specifications for Low-Rate Wireless Personal Area Networks" 703 [IEEE Std 802.15.4]. The latest version at the time of this 704 writing is dated year 2015. 706 2. Morell, A. , Vilajosana, X. , Vicario, J. L. and Watteyne, T. 707 (2013), Label switching over IEEE802.15.4e networks. Trans. 708 Emerging Tel. Tech., 24: 458-475. doi:10.1002/ett.2650" 709 [morell13]. 711 3. De Armas, J., Tuset, P., Chang, T., Adelantado, F., Watteyne, T., 712 Vilajosana, X. (2016, September). Determinism through path 713 diversity: Why packet replication makes sense. In 2016 714 International Conference on Intelligent Networking and 715 Collaborative Systems (INCoS) (pp. 150-154). IEEE. [dearmas16]. 717 4. X. Vilajosana, T. Watteyne, M. Vucinic, T. Chang and K. S. 718 J. Pister, "6TiSCH: Industrial Performance for IPv6 Internet-of- 719 Things Networks," in Proceedings of the IEEE, vol. 107, no. 6, 720 pp. 1153-1165, June 2019. [vilajosana19]. 722 5.2. TimeSlotted Channel Hopping 724 5.2.1. General Characteristics 726 As a core technique in IEEE802.15.4, TSCH splits time in multiple 727 time slots that repeat over time. A set of timeslots constructs a 728 Slotframe (see Section 5.2.2.1.4). For each timeslot, a set of 729 available frequencies can be used, resulting in a matrix-like 730 schedule (see Figure 1). 732 timeslot offset 733 | 0 1 2 3 4 | 0 1 2 3 4 | Nodes 734 +------------------------+------------------------+ +-----+ 735 | | | | | | | | | | | | C | 736 CH-1 | EB | | |C->B| | EB | | |C->B| | | | 737 | | | | | | | | | | | +-----+ 738 +-------------------------------------------------+ | 739 | | | | | | | | | | | | 740 CH-2 | | |B->C| |B->A| | |B->C| |B->A| +-----+ 741 | | | | | | | | | | | | B | 742 +-------------------------------------------------+ | | 743 ... +-----+ 744 | 745 +-------------------------------------------------+ | 746 | | | | | | | | | | | +-----+ 747 CH-15| |A->B| | | | |A->B| | | | | A | 748 | | | | | | | | | | | | | 749 +-------------------------------------------------+ +-----+ 750 ch. 751 offset 753 Figure 1: Slotframe example with scheduled cells between nodes A, 754 B and C 756 This schedule represents the possible communications of a node with 757 its neighbors, and is managed by a Scheduling Function such as the 758 Minimal Scheduling Function (MSF) [RFC9033]. Each cell in the 759 schedule is identified by its slotoffset and channeloffset 760 coordinates. A cell's timeslot offset indicates its position in 761 time, relative to the beginning of the slotframe. A cell's channel 762 offset is an index which maps to a frequency at each iteration of the 763 slotframe. Each packet exchanged between neighbors happens within 764 one cell. The size of a cell is a timeslot duration, between 10 to 765 15 milliseconds. An Absolute Slot Number (ASN) indicates the number 766 of slots elapsed since the network started. It increments at every 767 slot. This is a 5 byte counter that can support networks running for 768 more than 300 years without wrapping (assuming a 10 ms timeslot). 769 Channel hopping provides increased reliability to multi-path fading 770 and external interference. It is handled by TSCH through a channel 771 hopping sequence referred as macHopSeq in the IEEE802.15.4 772 specification. 774 The Time-Frequency Division Multiple Access provided by TSCH enables 775 the orchestration of traffic flows, spreading them in time and 776 frequency, and hence enabling an efficient management of the 777 bandwidth utilization. Such efficient bandwidth utilization can be 778 combined to OFDM modulations also supported by the IEEE802.15.4 779 standard [IEEE Std 802.15.4] since the 2015 version. 781 TSCH networks operate in ISM bands in which the spectrum is shared by 782 different coexisting technologies. Regulations such as FCC, ETSI and 783 ARIB impose duty cycle regulations to limit the use of the bands but 784 yet interference may constraint the probability to deliver a packet. 785 Part of these reliability challenges are addressed at the MAC 786 introducing redundancy and diversity, thanks to channel hopping, 787 scheduling and ARQ policies. Yet, the MAC layer operates with a 788 1-hop vision, being limited to local actions to mitigate 789 underperforming links. 791 In the RAW context, low power reliable networks should address non- 792 critical control scenarios such as Class 2 and monitoring scenarios 793 such as Class 4 defined by the RFC5673 [RFC5673]. As a low power 794 technology targeting industrial scenarios radio transducers provide 795 low data rates (typically between 50kbps to 250kbps) and robust 796 modulations to trade-off performance to reliability. TSCH networks 797 are organized in mesh topologies and connected to a backbone. 798 Latency in the mesh network is mainly influenced by propagation 799 aspects such as interference. ARQ methods and redundancy techniques 800 such as replication and elimination should be studied to provide the 801 needed performance to address deterministic scenarios. 803 5.2.2. Applicability to Deterministic Flows 805 Nodes in a TSCH network are tightly synchronized. This enables to 806 build the slotted structure and ensure efficient utilization of 807 resources thanks to proper scheduling policies. Scheduling is a key 808 to orchestrate the resources that different nodes in a Track or a 809 path are using. Slotframes can be split in resource blocks reserving 810 the needed capacity to certain flows. Periodic and bursty traffic 811 can be handled independently in the schedule, using active and 812 reactive policies and taking advantage of overprovisionned cells to 813 measu reth excursion. Along a Track, resource blocks can be chained 814 so nodes in previous hops transmit their data before the next packet 815 comes. This provides a tight control to latency along a Track. 816 Collision loss is avoided for best effort traffic by 817 overprovisionning resources, giving time to the management plane of 818 the network to dedicate more resources if needed. 820 5.2.2.1. Centralized Path Computation 822 In a controlled environment, a 6TiSCH device usually does not place a 823 request for bandwidth between itself and another device in the 824 network. Rather, an Operation Control System (OCS) invoked through 825 an Human/Machine Interface (HMI) iprovides the Traffic Specification, 826 in particular in terms of latency and reliability, and the end nodes, 827 to a Path Computation element (PCE). With this, the PCE computes a 828 Track between the end nodes and provisions every hop in the Track 829 with per-flow state that describes the per-hop operation for a given 830 packet, the corresponding timeSlots, and the flow identification to 831 recognize which packet is placed in which Track, sort out duplicates, 832 etc. In Figure 2, an example of Operational Control System and HMI 833 is depicted. 835 For a static configuration that serves a certain purpose for a long 836 period of time, it is expected that a node will be provisioned in one 837 shot with a full schedule, which incorporates the aggregation of its 838 behavior for multiple Tracks. The 6TiSCH Architecture expects that 839 the programing of the schedule is done over CoAP as discussed in 840 "6TiSCH Resource Management and Interaction using CoAP" 841 [I-D.ietf-6tisch-coap]. 843 But an Hybrid mode may be required as well whereby a single Track is 844 added, modified, or removed, for instance if it appears that a Track 845 does not perform as expected for, say, Packet Delivery Ratio (PDR). 846 For that case, the expectation is that a protocol that flows along a 847 Track (to be), in a fashion similar to classical Traffic Engineering 848 (TE) [CCAMP], may be used to update the state in the devices. 6TiSCH 849 provides means for a device to negotiate a timeSlot with a neighbor, 850 but in general that flow was not designed and no protocol was 851 selected and it is expected that DetNet will determine the 852 appropriate end-to-end protocols to be used in that case. 854 Stream Management Entity 856 Operational Control System and HMI 858 -+-+-+-+-+-+-+ Northbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 860 PCE PCE PCE PCE 862 -+-+-+-+-+-+-+ Southbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 864 --- 6TiSCH------6TiSCH------6TiSCH------6TiSCH-- 865 6TiSCH / Device Device Device Device \ 866 Device- - 6TiSCH 867 \ 6TiSCH 6TiSCH 6TiSCH 6TiSCH / Device 868 ----Device------Device------Device------Device-- 870 Figure 2 872 5.2.2.1.1. Packet Marking and Handling 874 Section "Packet Marking and Handling" of [RFC9030] describes the 875 packet tagging and marking that is expected in 6TiSCH networks. 877 5.2.2.1.1.1. Tagging Packets for Flow Identification 879 For packets that are routed by a PCE along a Track, the tuple formed 880 by the IPv6 source address and a local RPLInstanceID is tagged in the 881 packets to identify uniquely the Track and associated transmit bundle 882 of timeSlots. 884 It results that the tagging that is used for a DetNet flow outside 885 the 6TiSCH LLN MUST be swapped into 6TiSCH formats and back as the 886 packet enters and then leaves the 6TiSCH network. 888 Note: The method and format used for encoding the RPLInstanceID at 889 6lo is generalized to all 6TiSCH topological Instances, which 890 includes Tracks. 892 5.2.2.1.1.2. Replication, Retries and Elimination 894 The 6TiSCH Architecture [RFC9030] leverages the Packet Replication, 895 Retries and Elimination (PRE) functions (PREF), the precursor to what 896 the RAW Architecture [I-D.ietf-raw-architecture] calls PAREO 897 functions. PREF establishes several paths in a network to provide 898 redundancy and parallel transmissions to bound the end-to-end delay. 899 Considering the scenario shown in Figure 3, many different paths are 900 possible for S to reach R. A simple way to benefit from this 901 topology could be to use the two independent paths via nodes A, C, E 902 and via B, D, F. But more complex paths are possible as well. 904 (A) (C) (E) 906 source (S) (R) (destination) 908 (B) (D) (F) 910 Figure 3: A Typical Ladder Shape with Two Parallel Paths Toward 911 the Destination 913 By employing a Packet Replication function, each node forwards a copy 914 of each data packet over two different branches. For instance, in 915 Figure 4, the source node S transmits the data packet to nodes A and 916 B, in two different timeslots within the same TSCH slotframe. 918 ===> (A) => (C) => (E) === 919 // \\// \\// \\ 920 source (S) //\\ //\\ (R) (destination) 921 \\ // \\ // \\ // 922 ===> (B) => (D) => (F) === 924 Figure 4: Packet Replication: S transmits twice the same data 925 packet, to its DP (A) and to its AP (B). 927 By employing Packet Elimination function once a node receives the 928 first copy of a data packet, it discards the subsequent copies. 929 Because the first copy that reaches a node is the one that matters, 930 it is the only copy that will be forwarded upward. 932 Considering that the wireless medium is broadcast by nature, any 933 neighbor of a transmitter may overhear a transmission. By employing 934 the Promiscuous Overhearing function, nodes will have multiple 935 opportunities to receive a given data packet. For instance, in 936 Figure 4, when the source node S transmits the data packet to node A, 937 node B may overhear this transmission. 939 6TiSCH expects elimination and replication of packets along a complex 940 Track, but has no position about how the sequence numbers would be 941 tagged in the packet. 943 As it goes, 6TiSCH expects that timeSlots corresponding to copies of 944 a same packet along a Track are correlated by configuration, and does 945 not need to process the sequence numbers. 947 The semantics of the configuration MUST enable correlated timeSlots 948 to be grouped for transmit (and respectively receive) with 949 a'OR'relations, and then a'AND'relation MUST be configurable between 950 groups. The semantics is that if the transmit (and respectively 951 receive) operation succeeded in one timeSlot in a'OR'group, then all 952 the other timeSLots in the group are ignored. Now, if there are at 953 least two groups, the'AND'relation between the groups indicates that 954 one operation must succeed in each of the groups. 956 On the transmit side, timeSlots provisioned for retries along a same 957 branch of a Track are placed a same'OR'group. The'OR'relation 958 indicates that if a transmission is acknowledged, then further 959 transmissions SHOULD NOT be attempted for timeSlots in that group. 960 There are as many'OR'groups as there are branches of the Track 961 departing from this node. Different'OR'groups are programmed for the 962 purpose of replication, each group corresponding to one branch of the 963 Track. The'AND'relation between the groups indicates that 964 transmission over any of branches MUST be attempted regardless of 965 whether a transmission succeeded in another branch. It is also 966 possible to place cells to different next-hop routers in a 967 same'OR'group. This allows to route along multi-path Tracks, trying 968 one next-hop and then another only if sending to the first fails. 970 On the receive side, all timeSlots are programmed in a same'OR'group. 971 Retries of a same copy as well as converging branches for elimination 972 are converged, meaning that the first successful reception is enough 973 and that all the other timeSlots can be ignored. 975 5.2.2.1.2. Topology and capabilities 977 6TiSCH nodes are usually IoT devices, characterized by very limited 978 amount of memory, just enough buffers to store one or a few IPv6 979 packets, and limited bandwidth between peers. It results that a node 980 will maintain only a small number of peering information, and will 981 not be able to store many packets waiting to be forwarded. Peers can 982 be identified through MAC or IPv6 addresses. 984 Neighbors can be discovered over the radio using mechanism such as 985 Enhanced Beacons, but, though the neighbor information is available 986 in the 6TiSCH interface data model, 6TiSCH does not describe a 987 protocol to pro-actively push the neighborhood information to a PCE. 988 This protocol should be described and should operate over CoAP. The 989 protocol should be able to carry multiple metrics, in particular the 990 same metrics as used for RPL operations [RFC6551]. 992 The energy that the device consumes in sleep, transmit and receive 993 modes can be evaluated and reported. So can the amount of energy 994 that is stored in the device and the power that it can be scavenged 995 from the environment. The PCE SHOULD be able to compute Tracks that 996 will implement policies on how the energy is consumed, for instance 997 balance between nodes, ensure that the spent energy does not exceeded 998 the scavenged energy over a period of time, etc... 1000 5.2.2.1.3. Schedule Management by a PCE 1002 6TiSCH supports a mixed model of centralized routes and distributed 1003 routes. Centralized routes can for example be computed by a entity 1004 such as a PCE [PCE]. Distributed routes are computed by RPL 1005 [RFC6550]. 1007 Both methods may inject routes in the Routing Tables of the 6TiSCH 1008 routers. In either case, each route is associated with a 6TiSCH 1009 topology that can be a RPL Instance topology or a Track. The 6TiSCH 1010 topology is indexed by a Instance ID, in a format that reuses the 1011 RPLInstanceID as defined in RPL. 1013 Both RPL and PCE rely on shared sources such as policies to define 1014 Global and Local RPLInstanceIDs that can be used by either method. 1015 It is possible for centralized and distributed routing to share a 1016 same topology. Generally they will operate in different slotFrames, 1017 and centralized routes will be used for scheduled traffic and will 1018 have precedence over distributed routes in case of conflict between 1019 the slotFrames. 1021 5.2.2.1.4. SlotFrames and Priorities 1023 A slotFrame is the base object that a PCE needs to manipulate to 1024 program a schedule into an LLN node. Elaboration on that concept can 1025 be fond in section "SlotFrames and Priorities" of [RFC9030] 1027 IEEE802.15.4 TSCH avoids contention on the medium by formatting time 1028 and frequencies in cells of transmission of equal duration. In order 1029 to describe that formatting of time and frequencies, the 6TiSCH 1030 architecture defines a global concept that is called a Channel 1031 Distribution and Usage (CDU) matrix; a CDU matrix is a matrix of 1032 cells with an height equal to the number of available channels 1033 (indexed by ChannelOffsets) and a width (in timeSlots) that is the 1034 period of the network scheduling operation (indexed by slotOffsets) 1035 for that CDU matrix. The size of a cell is a timeSlot duration, and 1036 values of 10 to 15 milliseconds are typical in 802.15.4 TSCH to 1037 accommodate for the transmission of a frame and an acknowledgement, 1038 including the security validation on the receive side which may take 1039 up to a few milliseconds on some device architecture. 1041 The frequency used by a cell in the matrix rotates in a pseudo-random 1042 fashion, from an initial position at an epoch time, as the matrix 1043 iterates over and over. 1045 A CDU matrix is computed by the PCE, but unallocated timeSlots may be 1046 used opportunistically by the nodes for classical best effort IP 1047 traffic. The PCE has precedence in the allocation in case of a 1048 conflict. 1050 In a given network, there might be multiple CDU matrices that operate 1051 with different width, so they have different durations and represent 1052 different periodic operations. It is recommended that all CDU 1053 matrices in a 6TiSCH domain operate with the same cell duration and 1054 are aligned, so as to reduce the chances of interferences from 1055 slotted-aloha operations. The PCE MUST compute the CDU matrices and 1056 shared that knowledge with all the nodes. The matrices are used in 1057 particular to define slotFrames. 1059 A slotFrame is a MAC-level abstraction that is common to all nodes 1060 and contains a series of timeSlots of equal length and precedence. 1061 It is characterized by a slotFrame_ID, and a slotFrame_size. A 1062 slotFrame aligns to a CDU matrix for its parameters, such as number 1063 and duration of timeSlots. 1065 Multiple slotFrames can coexist in a node schedule, i.e., a node can 1066 have multiple activities scheduled in different slotFrames, based on 1067 the precedence of the 6TiSCH topologies. The slotFrames may be 1068 aligned to different CDU matrices and thus have different width. 1069 There is typically one slotFrame for scheduled traffic that has the 1070 highest precedence and one or more slotFrame(s) for RPL traffic. The 1071 timeSlots in the slotFrame are indexed by the SlotOffset; the first 1072 cell is at SlotOffset 0. 1074 The 6TiSCH architecture introduces the concept of chunks ([RFC9030]) 1075 to operate such spectrum distribution for a whole group of cells at a 1076 time. The CDU matrix is formatted into a set of chunks, each of them 1077 identified uniquely by a chunk-ID, see Figure 5. The PCE MUST 1078 compute the partitioning of CDU matrices into chunks and shared that 1079 knowledge with all the nodes in a 6TiSCH network. 1081 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 1082 chan.Off. 0 |chnkA|chnkP|chnk7|chnkO|chnk2|chnkK|chnk1| ... |chnkZ| 1083 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 1084 chan.Off. 1 |chnkB|chnkQ|chnkA|chnkP|chnk3|chnkL|chnk2| ... |chnk1| 1085 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 1086 ... 1087 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 1088 chan.Off. 15 |chnkO|chnk6|chnkN|chnk1|chnkJ|chnkZ|chnkI| ... |chnkG| 1089 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 1090 0 1 2 3 4 5 6 M 1092 Figure 5: CDU matrix Partitioning in Chunks 1094 The appropriation of a chunk can be requested explicitly by the PCE 1095 to any node. After a successful appropriation, the PCE owns the 1096 cells in that chunk, and may use them as hard cells to set up Tracks. 1097 Then again, 6TiSCH did not propose a method for chunk definition and 1098 a protocol for appropriation. This is to be done at RAW. 1100 5.2.2.2. 6TiSCH Tracks 1102 A Track at 6TiSCH is the application to wireless of the concept of a 1103 path in the "Detnet architecture" [RFC8655]. A Track can follow a 1104 simple sequence of relay nodes or can be structured as a more complex 1105 Destination Oriented Directed Acyclic Graph (DODAG) to a unicast 1106 destination. Along a Track, 6TiSCH nodes reserve the resources to 1107 enable the efficient transmission of packets while aiming to optimize 1108 certain properties such as reliability and ensure small jitter or 1109 bounded latency. The Track structure enables Layer-2 forwarding 1110 schemes, reducing the overhead of taking routing decisions at the 1111 Layer-3. 1113 Serial Tracks can be understood as the concatenation of cells or 1114 bundles along a routing path from a source towards a destination. 1115 The serial Track concept is analogous to the circuit concept where 1116 resources are chained through the multi-hop topology. For example, A 1117 bundle of Tx Cells in a particular node is paired to a bundle of Rx 1118 Cells in the next hop node following a routing path. 1120 Whereas scheduling ensures reliable delivery in bounded time along 1121 any Track, high availability requires the application of PAREO 1122 functions along a more complex DODAG Track structure. A DODAG has 1123 forking and joining nodes where the concepts such as Replication and 1124 Elimination can be exploited. Spatial redundancy increases the 1125 oveall energy consumption in the network but improves significantly 1126 the availability of the network as well as the packet delivery ratio. 1127 A Track may also branch off and rejoin, for the purpose of the so- 1128 called Packet Replication and Elimination (PRE), over non congruent 1129 branches. PRE may be used to complement layer-2 Automatic Repeat 1130 reQuest (ARQ) and receiver-end Ordering to form the PAREO functions. 1131 PAREO functions enable to meet industrial expectations in PDR within 1132 bounded delivery time over a Track that includes wireless links, even 1133 when the Track extends beyond the 6TiSCH network. 1135 The RAW Track described in the RAW Architecture 1136 [I-D.ietf-raw-architecture] inherits directly from that model. RAW 1137 extends the graph beyond a DODAG as long as a given packet cannot 1138 loop within the Track. 1140 +-----+ 1141 | IoT | 1142 | G/W | 1143 +-----+ 1144 ^ <---- Elimination 1145 | | 1146 Track branch | | 1147 +-------+ +--------+ Subnet Backbone 1148 | | 1149 +--|--+ +--|--+ 1150 | | | Backbone | | | Backbone 1151 o | | | router | | | router 1152 +--/--+ +--|--+ 1153 o / o o---o----/ o 1154 o o---o--/ o o o o o 1155 o \ / o o LLN o 1156 o v <---- Replication 1157 o 1159 Figure 6: End-to-End deterministic Track 1161 In the example above (see Figure 6), a Track is laid out from a field 1162 device in a 6TiSCH network to an IoT gateway that is located on a 1163 IEEE802.1 TSN backbone. 1165 The Replication function in the field device sends a copy of each 1166 packet over two different branches, and a PCE schedules each hop of 1167 both branches so that the two copies arrive in due time at the 1168 gateway. In case of a loss on one branch, hopefully the other copy 1169 of the packet still makes it in due time. If two copies make it to 1170 the IoT gateway, the Elimination function in the gateway ignores the 1171 extra packet and presents only one copy to upper layers. 1173 At each 6TiSCH hop along the Track, the PCE may schedule more than 1174 one timeSlot for a packet, so as to support Layer-2 retries (ARQ). 1175 It is also possible that the field device only uses the second branch 1176 if sending over the first branch fails. 1178 In current deployments, a TSCH Track does not necessarily support PRE 1179 but is systematically multi-path. This means that a Track is 1180 scheduled so as to ensure that each hop has at least two forwarding 1181 solutions, and the forwarding decision is to try the preferred one 1182 and use the other in case of Layer-2 transmission failure as detected 1183 by ARQ. 1185 Methods to implement complex Tracks are described in 1186 [I-D.papadopoulos-paw-pre-reqs] and complemented by extensions to the 1187 RPL routing protocol in [I-D.ietf-roll-nsa-extension] for best effort 1188 traffic, but a centralized routing technique such as promoted in 1189 DetNet is still missing. 1191 5.2.2.2.1. Track Scheduling Protocol 1193 Section "Schedule Management Mechanisms" of the 6TiSCH architecture 1194 describes 4 paradigms to manage the TSCH schedule of the LLN nodes: 1195 Static Scheduling, neighbor-to-neighbor Scheduling, remote monitoring 1196 and scheduling management, and Hop-by-hop scheduling. The Track 1197 operation for DetNet corresponds to a remote monitoring and 1198 scheduling management by a PCE. 1200 Early work at 6TiSCH on a data model and a protocol to program the 1201 schedule in the 6TiSCH device was never concluded as the group 1202 focussed on best effort traffic. This work would be revived by RAW: 1204 The 6top interface document [RFC8480] (to be reopened at RAW) was 1205 intended to specify the generic data model that can be used to 1206 monitor and manage resources of the 6top sublayer. Abstract 1207 methods were suggested for use by a management entity in the 1208 device. The data model also enables remote control operations on 1209 the 6top sublayer. 1211 [I-D.ietf-6tisch-coap] (to be reopened at RAW) was intended to 1212 define a mapping of the 6top set of commands, which is described 1213 in RFC 8480, to CoAP resources. This allows an entity to interact 1214 with the 6top layer of a node that is multiple hops away in a 1215 RESTful fashion. 1217 [I-D.ietf-6tisch-coap] also defined a basic set CoAP resources and 1218 associated RESTful access methods (GET/PUT/POST/DELETE). The 1219 payload (body) of the CoAP messages is encoded using the CBOR 1220 format. The PCE commands are expected to be issued directly as 1221 CoAP requests or to be mapped back and forth into CoAP by a 1222 gateway function at the edge of the 6TiSCH network. For instance, 1223 it is possible that a mapping entity on the backbone transforms a 1224 non-CoAP protocol such as PCEP into the RESTful interfaces that 1225 the 6TiSCH devices support. 1227 5.2.2.2.2. Track Forwarding 1229 By forwarding, this specification means the per-packet operation that 1230 allows to deliver a packet to a next hop or an upper layer in this 1231 node. Forwarding is based on pre-existing state that was installed 1232 as a result of the routing computation of a Track by a PCE. The 1233 6TiSCH architecture supports three different forwarding model, G-MPLS 1234 Track Forwarding (TF), 6LoWPAN Fragment Forwarding (FF) and IPv6 1235 Forwarding (6F) which is the classical IP operation [RFC9030]. The 1236 DetNet case relates to the Track Forwarding operation under the 1237 control of a PCE. 1239 A Track is a unidirectional path between a source and a destination. 1240 In a Track cell, the normal operation of IEEE802.15.4 Automatic 1241 Repeat-reQuest (ARQ) usually happens, though the acknowledgment may 1242 be omitted in some cases, for instance if there is no scheduled cell 1243 for a retry. 1245 Track Forwarding is the simplest and fastest. A bundle of cells set 1246 to receive (RX-cells) is uniquely paired to a bundle of cells that 1247 are set to transmit (TX-cells), representing a layer-2 forwarding 1248 state that can be used regardless of the network layer protocol. 1249 This model can effectively be seen as a Generalized Multi-protocol 1250 Label Switching (G-MPLS) operation in that the information used to 1251 switch a frame is not an explicit label, but rather related to other 1252 properties of the way the packet was received, a particular cell in 1253 the case of 6TiSCH. As a result, as long as the TSCH MAC (and 1254 Layer-2 security) accepts a frame, that frame can be switched 1255 regardless of the protocol, whether this is an IPv6 packet, a 6LoWPAN 1256 fragment, or a frame from an alternate protocol such as WirelessHART 1257 or ISA100.11a. 1259 A data frame that is forwarded along a Track normally has a 1260 destination MAC address that is set to broadcast - or a multicast 1261 address depending on MAC support. This way, the MAC layer in the 1262 intermediate nodes accepts the incoming frame and 6top switches it 1263 without incurring a change in the MAC header. In the case of 1264 IEEE802.15.4, this means effectively broadcast, so that along the 1265 Track the short address for the destination of the frame is set to 1266 0xFFFF. 1268 A Track is thus formed end-to-end as a succession of paired bundles, 1269 a receive bundle from the previous hop and a transmit bundle to the 1270 next hop along the Track, and a cell in such a bundle belongs to at 1271 most one Track. For a given iteration of the device schedule, the 1272 effective channel of the cell is obtained by adding a pseudo-random 1273 number to the channelOffset of the cell, which results in a rotation 1274 of the frequency that used for transmission. The bundles may be 1275 computed so as to accommodate both variable rates and 1276 retransmissions, so they might not be fully used at a given iteration 1277 of the schedule. The 6TiSCH architecture provides additional means 1278 to avoid waste of cells as well as overflows in the transmit bundle, 1279 as follows: 1281 In one hand, a TX-cell that is not needed for the current iteration 1282 may be reused opportunistically on a per-hop basis for routed 1283 packets. When all of the frame that were received for a given Track 1284 are effectively transmitted, any available TX-cell for that Track can 1285 be reused for upper layer traffic for which the next-hop router 1286 matches the next hop along the Track. In that case, the cell that is 1287 being used is effectively a TX-cell from the Track, but the short 1288 address for the destination is that of the next-hop router. It 1289 results that a frame that is received in a RX-cell of a Track with a 1290 destination MAC address set to this node as opposed to broadcast must 1291 be extracted from the Track and delivered to the upper layer (a frame 1292 with an unrecognized MAC address is dropped at the lower MAC layer 1293 and thus is not received at the 6top sublayer). 1295 On the other hand, it might happen that there are not enough TX-cells 1296 in the transmit bundle to accommodate the Track traffic, for instance 1297 if more retransmissions are needed than provisioned. In that case, 1298 the frame can be placed for transmission in the bundle that is used 1299 for layer-3 traffic towards the next hop along the Track as long as 1300 it can be routed by the upper layer, that is, typically, if the frame 1301 transports an IPv6 packet. The MAC address should be set to the 1302 next-hop MAC address to avoid confusion. It results that a frame 1303 that is received over a layer-3 bundle may be in fact associated to a 1304 Track. In a classical IP link such as an Ethernet, off-Track traffic 1305 is typically in excess over reservation to be routed along the non- 1306 reserved path based on its QoS setting. But with 6TiSCH, since the 1307 use of the layer-3 bundle may be due to transmission failures, it 1308 makes sense for the receiver to recognize a frame that should be re- 1309 Tracked, and to place it back on the appropriate bundle if possible. 1310 A frame should be re-Tracked if the Per-Hop-Behavior group indicated 1311 in the Differentiated Services Field in the IPv6 header is set to 1312 Deterministic Forwarding, as discussed in Section 5.2.2.1.1. A frame 1313 is re-Tracked by scheduling it for transmission over the transmit 1314 bundle associated to the Track, with the destination MAC address set 1315 to broadcast. 1317 There are 2 modes for a Track, transport mode and tunnel mode. 1319 5.2.2.2.2.1. Transport Mode 1321 In transport mode, the Protocol Data Unit (PDU) is associated with 1322 flow-dependant meta-data that refers uniquely to the Track, so the 1323 6top sublayer can place the frame in the appropriate cell without 1324 ambiguity. In the case of IPv6 traffic, this flow identification is 1325 transported in the Flow Label of the IPv6 header. Associated with 1326 the source IPv6 address, the Flow Label forms a globally unique 1327 identifier for that particular Track that is validated at egress 1328 before restoring the destination MAC address (DMAC) and punting to 1329 the upper layer. 1331 | ^ 1332 +--------------+ | | 1333 | IPv6 | | | 1334 +--------------+ | | 1335 | 6LoWPAN HC | | | 1336 +--------------+ ingress egress 1337 | 6top | sets +----+ +----+ restores 1338 +--------------+ dmac to | | | | dmac to 1339 | TSCH MAC | brdcst | | | | self 1340 +--------------+ | | | | | | 1341 | LLN PHY | +-------+ +--...-----+ +-------+ 1342 +--------------+ 1344 Figure 7: Track Forwarding, Transport Mode 1346 5.2.2.2.2.2. Tunnel Mode 1348 In tunnel mode, the frames originate from an arbitrary protocol over 1349 a compatible MAC that may or may not be synchronized with the 6TiSCH 1350 network. An example of this would be a router with a dual radio that 1351 is capable of receiving and sending WirelessHART or ISA100.11a frames 1352 with the second radio, by presenting itself as an Access Point or a 1353 Backbone Router, respectively. 1355 In that mode, some entity (e.g. PCE) can coordinate with a 1356 WirelessHART Network Manager or an ISA100.11a System Manager to 1357 specify the flows that are to be transported transparently over the 1358 Track. 1360 +--------------+ 1361 | IPv6 | 1362 +--------------+ 1363 | 6LoWPAN HC | 1364 +--------------+ set restore 1365 | 6top | +dmac+ +dmac+ 1366 +--------------+ to|brdcst to|nexthop 1367 | TSCH MAC | | | | | 1368 +--------------+ | | | | 1369 | LLN PHY | +-------+ +--...-----+ +-------+ 1370 +--------------+ | ingress egress | 1371 | | 1372 +--------------+ | | 1373 | LLN PHY | | | 1374 +--------------+ | | 1375 | TSCH MAC | | | 1376 +--------------+ | dmac = | dmac = 1377 |ISA100/WiHART | | nexthop v nexthop 1378 +--------------+ 1380 Figure 8: Track Forwarding, Tunnel Mode 1382 In that case, the flow information that identifies the Track at the 1383 ingress 6TiSCH router is derived from the RX-cell. The dmac is set 1384 to this node but the flow information indicates that the frame must 1385 be tunneled over a particular Track so the frame is not passed to the 1386 upper layer. Instead, the dmac is forced to broadcast and the frame 1387 is passed to the 6top sublayer for switching. 1389 At the egress 6TiSCH router, the reverse operation occurs. Based on 1390 metadata associated to the Track, the frame is passed to the 1391 appropriate link layer with the destination MAC restored. 1393 5.2.2.2.2.3. Tunnel Metadata 1395 Metadata coming with the Track configuration is expected to provide 1396 the destination MAC address of the egress endpoint as well as the 1397 tunnel mode and specific data depending on the mode, for instance a 1398 service access point for frame delivery at egress. If the tunnel 1399 egress point does not have a MAC address that matches the 1400 configuration, the Track installation fails. 1402 In transport mode, if the final layer-3 destination is the tunnel 1403 termination, then it is possible that the IPv6 address of the 1404 destination is compressed at the 6LoWPAN sublayer based on the MAC 1405 address. It is thus mandatory at the ingress point to validate that 1406 the MAC address that was used at the 6LoWPAN sublayer for compression 1407 matches that of the tunnel egress point. For that reason, the node 1408 that injects a packet on a Track checks that the destination is 1409 effectively that of the tunnel egress point before it overwrites it 1410 to broadcast. The 6top sublayer at the tunnel egress point reverts 1411 that operation to the MAC address obtained from the tunnel metadata. 1413 5.2.2.2.2.4. OAM 1415 An Overview of Operations, Administration, and Maintenance (OAM) 1416 Tools [RFC7276] provides an overwiew of the existing tooling for OAM 1417 [RFC6291]. Tracks are complex paths and new tooling is necessary to 1418 manage them, with respect to load control, timing, and the Packet 1419 Replication and Elimination Functions (PREF). 1421 An example of such tooling can be found in the context of BIER 1422 [RFC8279] and more specifically BIER Traffic Engineering 1423 [I-D.ietf-bier-te-arch] (BIER-TE): 1424 [I-D.thubert-bier-replication-elimination] leverages BIER-TE to 1425 control the process of PREF, and to provide traceability of these 1426 operations, in the deterministic dataplane, along a complex Track. 1427 For the 6TiSCH type of constrained environment, 1428 [I-D.thubert-6lo-bier-dispatch] enables an efficient encoding of the 1429 BIER bitmap within the 6LoRH framework. 1431 6. 5G 1433 6.1. Provenance and Documents 1435 The 3rd Generation Partnership Project (3GPP) incorporates many 1436 companies whose business is related to cellular network operation as 1437 well as network equipment and device manufacturing. All generations 1438 of 3GPP technologies provide scheduled wireless segments, primarily 1439 in licensed spectrum which is beneficial for reliability and 1440 availability. 1442 In 2016, the 3GPP started to design New Radio (NR) technology 1443 belonging to the fifth generation (5G) of cellular networks. NR has 1444 been designed from the beginning to not only address enhanced Mobile 1445 Broadband (eMBB) services for consumer devices such as smart phones 1446 or tablets but is also tailored for future Internet of Things (IoT) 1447 communication and connected cyber-physical systems. In addition to 1448 eMBB, requirement categories have been defined on Massive Machine- 1449 Type Communication (M-MTC) for a large number of connected devices/ 1450 sensors, and Ultra-Reliable Low-Latency Communication (URLLC) for 1451 connected control systems and critical communication as illustrated 1452 in Figure 9. It is the URLLC capabilities that make 5G a great 1453 candidate for reliable low-latency communication. With these three 1454 corner stones, NR is a complete solution supporting the connectivity 1455 needs of consumers, enterprises, and public sector for both wide area 1456 and local area, e.g. indoor deployments. A general overview of NR 1457 can be found in [TS38300]. 1459 enhanced 1460 Mobile Broadband 1461 ^ 1462 / \ 1463 / \ 1464 / \ 1465 / \ 1466 / 5G \ 1467 / \ 1468 / \ 1469 / \ 1470 +-----------------+ 1471 Massive Ultra-Reliable 1472 Machine-Type Low-Latency 1473 Communication Communication 1475 Figure 9: 5G Application Areas 1477 As a result of releasing the first NR specification in 2018 (Release 1478 15), it has been proven by many companies that NR is a URLLC-capable 1479 technology and can deliver data packets at 10^-5 packet error rate 1480 within 1ms latency budget [TR37910]. Those evaluations were 1481 consolidated and forwarded to ITU to be included in the [IMT2020] 1482 work. 1484 In order to understand communication requirements for automation in 1485 vertical domains, 3GPP studied different use cases [TR22804] and 1486 released technical specification with reliability, availability and 1487 latency demands for a variety of applications [TS22104]. 1489 As an evolution of NR, multiple studies have been conducted in scope 1490 of 3GPP Release 16 including the following two, focusing on radio 1491 aspects: 1493 1. Study on physical layer enhancements for NR ultra-reliable and 1494 low latency communication (URLLC) [TR38824]. 1496 2. Study on NR industrial Internet of Things (I-IoT) [TR38825]. 1498 In addition, several enhancements have been done on system 1499 architecture level which are reflected in System architecture for the 1500 5G System (5GS) [TS23501]. 1502 6.2. General Characteristics 1504 The 5G Radio Access Network (5G RAN) with its NR interface includes 1505 several features to achieve Quality of Service (QoS), such as a 1506 guaranteeably low latency or tolerable packet error rates for 1507 selected data flows. Determinism is achieved by centralized 1508 admission control and scheduling of the wireless frequency resources, 1509 which are typically licensed frequency bands assigned to a network 1510 operator. 1512 NR enables short transmission slots in a radio subframe, which 1513 benefits low-latency applications. NR also introduces mini-slots, 1514 where prioritized transmissions can be started without waiting for 1515 slot boundaries, further reducing latency. As part of giving 1516 priority and faster radio access to URLLC traffic, NR introduces 1517 preemption where URLLC data transmission can preempt ongoing non- 1518 URLLC transmissions. Additionally, NR applies very fast processing, 1519 enabling retransmissions even within short latency bounds. 1521 NR defines extra-robust transmission modes for increased reliability 1522 both for data and control radio channels. Reliability is further 1523 improved by various techniques, such as multi-antenna transmission, 1524 the use of multiple frequency carriers in parallel and packet 1525 duplication over independent radio links. NR also provides full 1526 mobility support, which is an important reliability aspect not only 1527 for devices that are moving, but also for devices located in a 1528 changing environment. 1530 Network slicing is seen as one of the key features for 5G, allowing 1531 vertical industries to take advantage of 5G networks and services. 1532 Network slicing is about transforming a Public Land Mobile Network 1533 (PLMN) from a single network to a network where logical partitions 1534 are created, with appropriate network isolation, resources, optimized 1535 topology and specific configuration to serve various service 1536 requirements. An operator can configure and manage the mobile 1537 network to support various types of services enabled by 5G, for 1538 example eMBB and URLLC, depending on the different customers' needs. 1540 Exposure of capabilities of 5G Systems to the network or applications 1541 outside the 3GPP domain have been added to Release 16 [TS23501]. Via 1542 exposure interfaces, applications can access 5G capabilities, e.g., 1543 communication service monitoring and network maintenance. 1545 For several generations of mobile networks, 3GPP has considered how 1546 the communication system should work on a global scale with billions 1547 of users, taking into account resilience aspects, privacy regulation, 1548 protection of data, encryption, access and core network security, as 1549 well as interconnect. Security requirements evolve as demands on 1550 trustworthiness increase. For example, this has led to the 1551 introduction of enhanced privacy protection features in 5G. 5G also 1552 employs strong security algorithms, encryption of traffic, protection 1553 of signaling and protection of interfaces. 1555 One particular strength of mobile networks is the authentication, 1556 based on well-proven algorithms and tightly coupled with a global 1557 identity management infrastructure. Since 3G, there is also mutual 1558 authentication, allowing the network to authenticate the device and 1559 the device to authenticate the network. Another strength is secure 1560 solutions for storage and distribution of keys fulfilling regulatory 1561 requirements and allowing international roaming. When connecting to 1562 5G, the user meets the entire communication system, where security is 1563 the result of standardization, product security, deployment, 1564 operations and management as well as incident handling capabilities. 1565 The mobile networks approach the entirety in a rather coordinated 1566 fashion which is beneficial for security. 1568 6.3. Deployment and Spectrum 1570 The 5G system allows deployment in a vast spectrum range, addressing 1571 use-cases in both wide-area as well as local networks. Furthermore, 1572 5G can be configured for public and non-public access. 1574 When it comes to spectrum, NR allows combining the merits of many 1575 frequency bands, such as the high bandwidths in millimeter Waves 1576 (mmW) for extreme capacity locally, as well as the broad coverage 1577 when using mid- and low frequency bands to address wide-area 1578 scenarios. URLLC is achievable in all these bands. Spectrum can be 1579 either licensed, which means that the license holder is the only 1580 authorized user of that spectrum range, or unlicensed, which means 1581 that anyone who wants to use the spectrum can do so. 1583 A prerequisite for critical communication is performance 1584 predictability, which can be achieved by the full control of the 1585 access to the spectrum, which 5G provides. Licensed spectrum 1586 guarantees control over spectrum usage by the system, making it a 1587 preferable option for critical communication. However, unlicensed 1588 spectrum can provide an additional resource for scaling non-critical 1589 communications. While NR is initially developed for usage of 1590 licensed spectrum, the functionality to access also unlicensed 1591 spectrum was introduced in 3GPP Release 16. 1593 Licensed spectrum dedicated to mobile communications has been 1594 allocated to mobile service providers, i.e. issued as longer-term 1595 licenses by national administrations around the world. These 1596 licenses have often been associated with coverage requirements and 1597 issued across whole countries, or in large regions. Besides this, 1598 configured as a non-public network (NPN) deployment, 5G can provide 1599 network services also to a non-operator defined organization and its 1600 premises such as a factory deployment. By this isolation, quality of 1601 service requirements, as well as security requirements can be 1602 achieved. An integration with a public network, if required, is also 1603 possible. The non-public (local) network can thus be interconnected 1604 with a public network, allowing devices to roam between the networks. 1606 In an alternative model, some countries are now in the process of 1607 allocating parts of the 5G spectrum for local use to industries. 1608 These non-service providers then have a choice of applying for a 1609 local license themselves and operating their own network or 1610 cooperating with a public network operator or service provider. 1612 6.4. Applicability to Deterministic Flows 1614 6.4.1. System Architecture 1616 The 5G system [TS23501] consists of the User Equipment (UE) at the 1617 terminal side, and the Radio Access Network (RAN) with the gNB as 1618 radio base station node, as well as the Core Network (CN). The core 1619 network is based on a service-based architecture with the central 1620 functions: Access and Mobility Management Function (AMF), Session 1621 Management Function (SMF) and User Plane Function (UPF) as 1622 illustrated in Figure 10. 1624 The gNB's main responsibility is the radio resource management, 1625 including admission control and scheduling, mobility control and 1626 radio measurement handling. The AMF handles the UE's connection 1627 status and security, while the SMF controls the UE's data sessions. 1628 The UPF handles the user plane traffic. 1630 The SMF can instantiate various Packet Data Unit (PDU) sessions for 1631 the UE, each associated with a set of QoS flows, i.e., with different 1632 QoS profiles. Segregation of those sessions is also possible, e.g., 1633 resource isolation in the RAN and in the CN can be defined (slicing). 1635 +----+ +---+ +---+ +---+ +---+ +---+ 1636 |NSSF| |NEF| |NRF| |PCF| |UDM| |AF | 1637 +--+-+ +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ 1638 | | | | | | 1639 Nnssf| Nnef| Nnrf| Npcf| Nudm| Naf| 1640 | | | | | | 1641 ---+------+-+-----+-+------------+--+-----+-+--- 1642 | | | | 1643 Nausf| Nausf| Nsmf| | 1644 | | | | 1645 +--+-+ +-+-+ +-+-+ +-+-+ 1646 |AUSF| |AMF| |SMF| |SCP| 1647 +----+ +++-+ +-+-+ +---+ 1648 / | | 1649 / | | 1650 / | | 1651 N1 N2 N4 1652 / | | 1653 / | | 1654 / | | 1655 +--+-+ +--+--+ +--+---+ +----+ 1656 | UE +---+(R)AN+--N3--+ UPF +--N6--+ DN | 1657 +----+ +-----+ ++----++ +----+ 1658 | | 1659 +-N9-+ 1661 Figure 10: 5G System Architecture 1663 To allow UE mobility across cells/gNBs, handover mechanisms are 1664 supported in NR. For an established connection, i.e., connected mode 1665 mobility, a gNB can configure a UE to report measurements of received 1666 signal strength and quality of its own and neighbouring cells, 1667 periodically or event-based. Based on these measurement reports, the 1668 gNB decides to handover a UE to another target cell/gNB. Before 1669 triggering the handover, it is hand-shaked with the target gNB based 1670 on network signalling. A handover command is then sent to the UE and 1671 the UE switches its connection to the target cell/gNB. The Packet 1672 Data Convergence Protocol (PDCP) of the UE can be configured to avoid 1673 data loss in this procedure, i.e., handle retransmissions if needed. 1674 Data forwarding is possible between source and target gNB as well. 1675 To improve the mobility performance further, i.e., to avoid 1676 connection failures, e.g., due to too-late handovers, the mechanism 1677 of conditional handover is introduced in Release 16 specifications. 1679 Therein a conditional handover command, defining a triggering point, 1680 can be sent to the UE before UE enters a handover situation. A 1681 further improvement introduced in Release 16 is the Dual Active 1682 Protocol Stack (DAPS), where the UE maintains the connection to the 1683 source cell while connecting to the target cell. This way, potential 1684 interruptions in packet delivery can be avoided entirely. 1686 6.4.2. Overview of The Radio Protocol Stack 1688 The protocol architecture for NR consists of the L1 Physical layer 1689 (PHY) and as part of the L2, the sublayers of Medium Access Control 1690 (MAC), Radio Link Control (RLC), Packet Data Convergence Protocol 1691 (PDCP), as well as the Service Data Adaption Protocol (SDAP). 1693 The PHY layer handles signal processing related actions, such as 1694 encoding/decoding of data and control bits, modulation, antenna 1695 precoding and mapping. 1697 The MAC sub-layer handles multiplexing and priority handling of 1698 logical channels (associated with QoS flows) to transport blocks for 1699 PHY transmission, as well as scheduling information reporting and 1700 error correction through Hybrid Automated Repeat Request (HARQ). 1702 The RLC sublayer handles sequence numbering of higher layer packets, 1703 retransmissions through Automated Repeat Request (ARQ), if 1704 configured, as well as segmentation and reassembly and duplicate 1705 detection. 1707 The PDCP sublayer consists of functionalities for ciphering/ 1708 deciphering, integrity protection/verification, re-ordering and in- 1709 order delivery, duplication and duplicate handling for higher layer 1710 packets, and acts as the anchor protocol to support handovers. 1712 The SDAP sublayer provides services to map QoS flows, as established 1713 by the 5G core network, to data radio bearers (associated with 1714 logical channels), as used in the 5G RAN. 1716 Additionally, in RAN, the Radio Resource Control (RRC) protocol, 1717 handles the access control and configuration signalling for the 1718 aforementioned protocol layers. RRC messages are considered L3 and 1719 thus transmitted also via those radio protocol layers. 1721 To provide low latency and high reliability for one transmission 1722 link, i.e., to transport data (or control signaling) of one radio 1723 bearer via one carrier, several features have been introduced on the 1724 user plane protocols for PHY and L2, as explained in the following. 1726 6.4.3. Radio (PHY) 1728 NR is designed with native support of antenna arrays utilizing 1729 benefits from beamforming, transmissions over multiple MIMO layers 1730 and advanced receiver algorithms allowing effective interference 1731 cancellation. Those antenna techniques are the basis for high signal 1732 quality and effectiveness of spectral usage. Spatial diversity with 1733 up to 4 MIMO layers in UL and up to 8 MIMO layers in DL is supported. 1734 Together with spatial-domain multiplexing, antenna arrays can focus 1735 power in desired direction to form beams. NR supports beam 1736 management mechanisms to find the best suitable beam for UE initially 1737 and when it is moving. In addition, gNBs can coordinate their 1738 respective DL and UL transmissions over the backhaul network keeping 1739 interference reasonably low, and even make transmissions or 1740 receptions from multiple points (multi-TRP). Multi-TRP can be used 1741 for repetition of data packet in time, in frequency or over multiple 1742 MIMO layers which can improve reliability even further. 1744 Any downlink transmission to a UE starts from resource allocation 1745 signaling over the Physical Downlink Control Channel (PDCCH). If it 1746 is successfully received, the UE will know about the scheduled 1747 transmission and may receive data over the Physical Downlink Shared 1748 Channel (PDSCH). If retransmission is required according to the HARQ 1749 scheme, a signaling of negative acknowledgement (NACK) on the 1750 Physical Uplink Control Channel (PUCCH) is involved and PDCCH 1751 together with PDSCH transmissions (possibly with additional 1752 redundancy bits) are transmitted and soft-combined with previously 1753 received bits. Otherwise, if no valid control signaling for 1754 scheduling data is received, nothing is transmitted on PUCCH 1755 (discontinuous transmission - DTX),and the base station upon 1756 detecting DTX will retransmit the initial data. 1758 An uplink transmission normally starts from a Scheduling Request (SR) 1759 - a signaling message from the UE to the base station sent via PUCCH. 1760 Once the scheduler is informed about buffer data in UE, e.g., by SR, 1761 the UE transmits a data packet on the Physical Uplink Shared Channel 1762 (PUSCH). Pre-scheduling not relying on SR is also possible (see 1763 following section). 1765 Since transmission of data packets require usage of control and data 1766 channels, there are several methods to maintain the needed 1767 reliability. NR uses Low Density Parity Check (LDPC) codes for data 1768 channels, Polar codes for PDCCH, as well as orthogonal sequences and 1769 Polar codes for PUCCH. For ultra-reliability of data channels, very 1770 robust (low spectral efficiency) Modulation and Coding Scheme (MCS) 1771 tables are introduced containing very low (down to 1/20) LDPC code 1772 rates using BPSK or QPSK. Also, PDCCH and PUCCH channels support 1773 multiple code rates including very low ones for the channel 1774 robustness. 1776 A connected UE reports downlink (DL) quality to gNB by sending 1777 Channel State Information (CSI) reports via PUCCH while uplink (UL) 1778 quality is measured directly at gNB. For both uplink and downlink, 1779 gNB selects the desired MCS number and signals it to the UE by 1780 Downlink Control Information (DCI) via PDCCH channel. For URLLC 1781 services, the UE can assist the gNB by advising that MCS targeting 1782 10^-5 Block Error Rate (BLER) are used. Robust link adaptation 1783 algorithms can maintain the needed level of reliability considering a 1784 given latency bound. 1786 Low latency on the physical layer is provided by short transmission 1787 duration which is possible by using high Subcarrier Spacing (SCS) and 1788 the allocation of only one or a few Orthogonal Frequency Division 1789 Multiplexing (OFDM) symbols. For example, the shortest latency for 1790 the worst case in DL can be 0.23ms and in UL can be 0.24ms according 1791 to (section 5.7.1 in [TR37910]). Moreover, if the initial 1792 transmission has failed, HARQ feedback can quickly be provided and an 1793 HARQ retransmission is scheduled. 1795 Dynamic multiplexing of data associated with different services is 1796 highly desirable for efficient use of system resources and to 1797 maximize system capacity. Assignment of resources for eMBB is 1798 usually done with regular (longer) transmission slots, which can lead 1799 to blocking of low latency services. To overcome the blocking, eMBB 1800 resources can be pre-empted and re-assigned to URLLC services. In 1801 this way, spectrally efficient assignments for eMBB can be ensured 1802 while providing flexibility required to ensure a bounded latency for 1803 URLLC services. In downlink, the gNB can notify the eMBB UE about 1804 pre-emption after it has happened, while in uplink there are two pre- 1805 emption mechanisms: special signaling to cancel eMBB transmission and 1806 URLLC dynamic power boost to suppress eMBB transmission. 1808 6.4.4. Scheduling and QoS (MAC) 1810 One integral part of the 5G system is the Quality of Service (QoS) 1811 framework [TS23501]. QoS flows are setup by the 5G system for 1812 certain IP or Ethernet packet flows, so that packets of each flow 1813 receive the same forwarding treatment, i.e., in scheduling and 1814 admission control. QoS flows can for example be associated with 1815 different priority level, packet delay budgets and tolerable packet 1816 error rates. Since radio resources are centrally scheduled in NR, 1817 the admission control function can ensure that only those QoS flows 1818 are admitted for which QoS targets can be reached. 1820 NR transmissions in both UL and DL are scheduled by the gNB 1821 [TS38300]. This ensures radio resource efficiency, fairness in 1822 resource usage of the users and enables differentiated treatment of 1823 the data flows of the users according to the QoS targets of the 1824 flows. Those QoS flows are handled as data radio bearers or logical 1825 channels in NR RAN scheduling. 1827 The gNB can dynamically assign DL and UL radio resources to users, 1828 indicating the resources as DL assignments or UL grants via control 1829 channel to the UE. Radio resources are defined as blocks of OFDM 1830 symbols in spectral domain and time domain. Different lengths are 1831 supported in time domain, i.e., (multiple) slot or mini-slot lengths. 1832 Resources of multiple frequency carriers can be aggregated and 1833 jointly scheduled to the UE. 1835 Scheduling decisions are based, e.g., on channel quality measured on 1836 reference signals and reported by the UE (cf. periodical CSI reports 1837 for DL channel quality). The transmission reliability can be chosen 1838 in the scheduling algorithm, i.e., by link adaptation where an 1839 appropriate transmission format (e.g., robustness of modulation and 1840 coding scheme, controlled UL power) is selected for the radio channel 1841 condition of the UE. Retransmissions, based on HARQ feedback, are 1842 also controlled by the scheduler. If needed to avoid HARQ round-trip 1843 time delays, repeated transmissions can be also scheduled beforehand, 1844 to the cost of reduced spectral efficiency. 1846 In dynamic DL scheduling, transmission can be initiated immediately 1847 when DL data becomes available in the gNB. However, for dynamic UL 1848 scheduling, when data becomes available but no UL resources are 1849 available yet, the UE indicates the need for UL resources to the gNB 1850 via a (single bit) scheduling request message in the UL control 1851 channel. When thereupon UL resources are scheduled to the UE, the UE 1852 can transmit its data and may include a buffer status report, 1853 indicating the exact amount of data per logical channel still left to 1854 be sent. More UL resources may be scheduled accordingly. To avoid 1855 the latency introduced in the scheduling request loop, UL radio 1856 resources can also be pre-scheduled. 1858 In particular for periodical traffic patterns, the pre-scheduling can 1859 rely on the scheduling features DL Semi-Persistent Scheduling (SPS) 1860 and UL Configured Grant (CG). With these features, periodically 1861 recurring resources can be assigned in DL and UL. Multiple parallels 1862 of those configurations are supported, in order to serve multiple 1863 parallel traffic flows of the same UE. 1865 To support QoS enforcement in the case of mixed traffic with 1866 different QoS requirements, several features have recently been 1867 introduced. This way, e.g., different periodical critical QoS flows 1868 can be served together with best effort transmissions, by the same 1869 UE. Among others, these features (partly Release 16) are: 1) UL 1870 logical channel transmission restrictions allowing to map logical 1871 channels of certain QoS only to intended UL resources of a certain 1872 frequency carrier, slot-length, or CG configuration, and 2) intra-UE 1873 pre-emption, allowing critical UL transmissions to pre-empt non- 1874 critical transmissions. 1876 When multiple frequency carriers are aggregated, duplicate parallel 1877 transmissions can be employed (beside repeated transmissions on one 1878 carrier). This is possible in the Carrier Aggregation (CA) 1879 architecture where those carriers originate from the same gNB, or in 1880 the Dual Connectivity (DC) architecture where the carriers originate 1881 from different gNBs, i.e., the UE is connected to two gNBs in this 1882 case. In both cases, transmission reliability is improved by this 1883 means of providing frequency diversity. 1885 In addition to licensed spectrum, a 5G system can also utilize 1886 unlicensed spectrum to offload non-critical traffic. This version of 1887 NR is called NR-U, part of 3GPP Release 16. The central scheduling 1888 approach applies also for unlicensed radio resources, but in addition 1889 also the mandatory channel access mechanisms for unlicensed spectrum, 1890 e.g., Listen Before Talk (LBT) are supported in NR-U. This way, by 1891 using NR, operators have and can control access to both licensed and 1892 unlicensed frequency resources. 1894 6.4.5. Time-Sensitive Networking (TSN) Integration 1896 The main objective of Time-Sensitive Networking (TSN) is to provide 1897 guaranteed data delivery within a guaranteed time window, i.e., 1898 bounded low latency. IEEE 802.1 TSN [IEEE802.1TSN] is a set of open 1899 standards that provide features to enable deterministic communication 1900 on standard IEEE 802.3 Ethernet [IEEE802.3]. TSN standards can be 1901 seen as a toolbox for traffic shaping, resource management, time 1902 synchronization, and reliability. 1904 A TSN stream is a data flow between one end station (Talker) to 1905 another end station (Listener). In the centralized configuration 1906 model, TSN bridges are configured by the Central Network Controller 1907 (CNC) [IEEE802.1Qcc] to provide deterministic connectivity for the 1908 TSN stream through the network. Time-based traffic shaping provided 1909 by Scheduled Traffic [IEEE802.1Qbv] may be used to achieve bounded 1910 low latency. The TSN tool for time synchronization is the 1911 generalized Precision Time Protocol (gPTP) [IEEE802.1AS]), which 1912 provides reliable time synchronization that can be used by end 1913 stations and by other TSN tools, e.g., Scheduled Traffic 1914 [IEEE802.1Qbv]. High availability, as a result of ultra-reliability, 1915 is provided for data flows by the Frame Replication and Elimination 1916 for Reliability (FRER) [IEEE802.1CB] mechanism. 1918 3GPP Release 16 includes integration of 5G with TSN, i.e., specifies 1919 functions for the 5G System (5GS) to deliver TSN streams such that 1920 the meet their QoS requirements. A key aspect of the integration is 1921 the 5GS appears from the rest of the network as a set of TSN bridges, 1922 in particular, one virtual bridge per User Plane Function (UPF) on 1923 the user plane. The 5GS includes TSN Translator (TT) functionality 1924 for the adaptation of the 5GS to the TSN bridged network and for 1925 hiding the 5GS internal procedures. The 5GS provides the following 1926 components: 1928 1. interface to TSN controller, as per [IEEE802.1Qcc] for the fully 1929 centralized configuration model 1931 2. time synchronization via reception and transmission of gPTP PDUs 1932 [IEEE802.1AS] 1934 3. low latency, hence, can be integrated with Scheduled Traffic 1935 [IEEE802.1Qbv] 1937 4. reliability, hence, can be integrated with FRER [IEEE802.1CB] 1938 Figure 10 shows an illustration of 5G-TSN integration where an 1939 industrial controller (Ind Ctrlr) is connected to industrial Input/ 1940 Output devices (I/O dev) via 5G. The 5GS can directly transport 1941 Ethernet frames since Release 15, thus, end-to-end Ethernet 1942 connectivity is provided. The 5GS implements the required interfaces 1943 towards the TSN controller functions such as the CNC, thus adapts to 1944 the settings of the TSN network. A 5G user plane virtual bridge 1945 interconnects TSN bridges or connect end stations, e.g., I/O devices 1946 to the network. Note that the introduction of 5G brings flexibility 1947 in various aspects, e.g., more flexible network topology because a 1948 wireless hop can replace several wireline hops thus significantly 1949 reduce the number of hops end-to-end. [ETR5GTSN] dives more into the 1950 integration of 5G with TSN. 1952 +------------------------------+ 1953 | 5G System | 1954 | +---+| 1955 | +-+ +-+ +-+ +-+ +-+ |TSN|| 1956 | | | | | | | | | | | |AF |......+ 1957 | +++ +++ +++ +++ +++ +-+-+| . 1958 | | | | | | | | . 1959 | -+---+---++--+-+-+--+-+- | . 1960 | | | | | | +--+--+ 1961 | +++ +++ +++ +++ | | TSN | 1962 | | | | | | | | | | |Ctrlr+.......+ 1963 | +++ +++ +++ +++ | +--+--+ . 1964 | | . . 1965 | | . . 1966 | +..........................+ | . . 1967 | . Virtual Bridge . | . . 1968 +---+ | . +--+--+ +---+ +---+--+ . | +--+---+ . 1969 |I/O+----------------+DS|UE+---+RAN+-+UPF|NW+------+ TSN +----+ . 1970 |dev| | . |TT| | | | | |TT| . | |bridge| | . 1971 +---+ | . +--+--+ +---+ +---+--+ . | +------+ | . 1972 | +..........................+ | . +-+-+-+ 1973 | | . | Ind | 1974 | +..........................+ | . |Ctrlr| 1975 | . Virtual Bridge . | . +-+---+ 1976 +---+ +------+ | . +--+--+ +---+ +---+--+ . | +--+---+ | 1977 |I/O+--+ TSN +------+DS|UE+---+RAN+-+UPF|NW+------+ TSN +----+ 1978 |dev| |bridge| | . |TT| | | | | |TT| . | |bridge| 1979 +---+ +------+ | . +--+--+ +---+ +---+--+ . | +------+ 1980 | +..........................+ | 1981 +------------------------------+ 1983 <----------------- end-to-end Ethernet -------------------> 1985 Figure 11: 5G - TSN Integration 1987 NR supports accurate reference time synchronization in 1us accuracy 1988 level. Since NR is a scheduled system, an NR UE and a gNB are 1989 tightly synchronized to their OFDM symbol structures. A 5G internal 1990 reference time can be provided to the UE via broadcast or unicast 1991 signaling, associating a known OFDM symbol to this reference clock. 1992 The 5G internal reference time can be shared within the 5G network, 1993 i.e., radio and core network components. For the interworking with 1994 gPTP for multiple time domains, the 5GS acts as a virtual gPTP time- 1995 aware system and supports the forwarding of gPTP time synchronization 1996 information between end stations and bridges through the 5G user 1997 plane TTs. These account for the residence time of the 5GS in the 1998 time synchronization procedure. One special option is when the 5GS 1999 internal reference time in not only used within the 5GS, but also to 2000 the rest of the devices in the deployment, including connected TSN 2001 bridges and end stations. 2003 Redundancy architectures were specified in order to provide 2004 reliability against any kind of failure on the radio link or nodes in 2005 the RAN and the core network, Redundant user plane paths can be 2006 provided based on the dual connectivity architecture, where the UE 2007 sets up two PDU sessions towards the same data network, and the 5G 2008 system makes the paths of the two PDU sessions independent as 2009 illustrated in Figure 13. There are two PDU sessions involved in the 2010 solution: the first spans from the UE via gNB1 to UPF1, acting as the 2011 first PDU session anchor, while the second spans from the UE via gNB2 2012 to UPF2, acting as second the PDU session anchor. The independent 2013 paths may continue beyond the 3GPP network. Redundancy Handling 2014 Functions (RHFs) are deployed outside of the 5GS, i.e., in Host A 2015 (the device) and in Host B (the network). RHF can implement 2016 replication and elimination functions as per [IEEE802.1CB] or the 2017 Packet Replication, Elimination, and Ordering Functions (PREOF) of 2018 IETF Deterministic Networking (DetNet) [RFC8655]. 2020 +........+ 2021 . Device . +------+ +------+ +------+ 2022 . . + gNB1 +--N3--+ UPF1 |--N6--+ | 2023 . ./+------+ +------+ | | 2024 . +----+ / | | 2025 . | |/. | | 2026 . | UE + . | DN | 2027 . | |\. | | 2028 . +----+ \ | | 2029 . .\+------+ +------+ | | 2030 +........+ + gNB2 +--N3--+ UPF2 |--N6--+ | 2031 +------+ +------+ +------+ 2033 Figure 12: Reliability with Single UE 2035 An alternative solution is that multiple UEs per device are used for 2036 user plane redundancy as illustrated in Figure 13. Each UE sets up a 2037 PDU session. The 5GS ensures that those PDU sessions of the 2038 different UEs are handled independently internal to the 5GS. There 2039 is no single point of failure in this solution, which also includes 2040 RHF outside of the 5G system, e.g., as per FRER or as PREOF 2041 specifications. 2043 +.........+ 2044 . Device . 2045 . . 2046 . +----+ . +------+ +------+ +------+ 2047 . | UE +-----+ gNB1 +--N3--+ UPF1 |--N6--+ | 2048 . +----+ . +------+ +------+ | | 2049 . . | DN | 2050 . +----+ . +------+ +------+ | | 2051 . | UE +-----+ gNB2 +--N3--+ UPF2 |--N6--+ | 2052 . +----+ . +------+ +------+ +------+ 2053 . . 2054 +.........+ 2056 Figure 13: Reliability with Dual UE 2058 Note that the abstraction provided by the RHF and the location of the 2059 RHF being outside of the 5G system make 5G equally supporting 2060 integration for reliability both with FRER of TSN and PREOF of DetNet 2061 as they both rely on the same concept. 2063 Note also that TSN is the primary subnetwork technology for DetNet. 2064 Thus, the DetNet over TSN work, e.g., [I-D.ietf-detnet-ip-over-tsn], 2065 can be leveraged via the TSN support built in 5G. 2067 6.5. Summary 2069 5G technology enables deterministic communication. Based on the 2070 centralized admission control and the scheduling of the wireless 2071 resources, licensed or unlicensed, quality of service such as latency 2072 and reliability can be guaranteed. 5G contains several features to 2073 achieve ultra-reliable and low latency performance, e.g., support for 2074 different OFDM numerologies and slot-durations, as well as fast 2075 processing capabilities and redundancy techniques that lead to 2076 achievable latency numbers of below 1ms with reliability guarantees 2077 up to 99.999%. 2079 5G also includes features to support Industrial IoT use cases, e.g., 2080 via the integration of 5G with TSN. This includes 5G capabilities 2081 for each TSN component, latency, resource management, time 2082 synchronization, and reliability. Furthermore, 5G support for TSN 2083 can be leveraged when 5G is used as subnet technology for DetNet, in 2084 combination with or instead of TSN, which is the primary subnet for 2085 DetNet. In addition, the support for integration with TSN 2086 reliability was added to 5G by making DetNet reliability also 2087 applicable, thus making 5G DetNet ready. Moreover, providing IP 2088 service is native to 5G. 2090 Overall, 5G provides scheduled wireless segments with high 2091 reliability and availability. In addition, 5G includes capabilities 2092 for integration to IP networks. 2094 7. L-band Digital Aeronautical Communications System 2096 One of the main pillars of the modern Air Traffic Management (ATM) 2097 system is the existence of a communication infrastructure that 2098 enables efficient aircraft guidance and safe separation in all phases 2099 of flight. Although current systems are technically mature, they are 2100 suffering from the VHF band's increasing saturation in high-density 2101 areas and the limitations posed by analogue radio. Therefore, 2102 aviation globally and the European Union (EU) in particular, strives 2103 for a sustainable modernization of the aeronautical communication 2104 infrastructure. 2106 In the long-term, ATM communication shall transition from analogue 2107 VHF voice and VDL2 communication to more spectrum efficient digital 2108 data communication. The European ATM Master Plan foresees this 2109 transition to be realized for terrestrial communications by the 2110 development and implementation of the L-band Digital Aeronautical 2111 Communications System (LDACS). LDACS shall enable IPv6 based air- 2112 ground communication related to the safety and regularity of the 2113 flight. The particular challenge is that no new frequencies can be 2114 made available for terrestrial aeronautical communication. It was 2115 thus necessary to develop procedures to enable the operation of LDACS 2116 in parallel with other services in the same frequency band. 2118 7.1. Provenance and Documents 2120 The development of LDACS has already made substantial progress in the 2121 Single European Sky ATM Research (SESAR) framework, and is currently 2122 being continued in the follow-up program, SESAR2020 [RIH18]. A key 2123 objective of the SESAR activities is to develop, implement and 2124 validate a modern aeronautical data link able to evolve with aviation 2125 needs over long-term. To this end, an LDACS specification has been 2126 produced [GRA19] and is continuously updated; transmitter 2127 demonstrators were developed to test the spectrum compatibility of 2128 LDACS with legacy systems operating in the L-band [SAJ14]; and the 2129 overall system performance was analyzed by computer simulations, 2130 indicating that LDACS can fulfill the identified requirements 2131 [GRA11]. 2133 LDACS standardization within the framework of the International Civil 2134 Aviation Organization (ICAO) started in December 2016. The ICAO 2135 standardization group has produced an initial Standards and 2136 Recommended Practices (SARPs) document [ICAO18]. The SARPs document 2137 defines the general characteristics of LDACS. The ICAO 2138 standardization group plans to produce an ICAO technical manual - the 2139 ICAO equivalent to a technical standard - within the next years. 2140 Generally, the group is open to input from all sources and develops 2141 LDACS in the open. 2143 Up to now the LDACS standardization has been focused on the 2144 development of the physical layer and the data link layer, only 2145 recently have higher layers come into the focus of the LDACS 2146 development activities. There is currently no "IPv6 over LDACS" 2147 specification; however, SESAR2020 has started the testing of 2148 IPv6-based LDACS testbeds. The IPv6 architecture for the 2149 aeronautical telecommunication network is called the Future 2150 Communications Infrastructure (FCI). FCI shall support quality of 2151 service, diversity, and mobility under the umbrella of the "multi- 2152 link concept". This work is conducted by ICAO working group WG-I. 2154 In addition to standardization activities several industrial LDACS 2155 prototypes have been built. One set of LDACS prototypes has been 2156 evaluated in flight trials confirming the theoretical results 2157 predicting the system performance [GRA18][SCH19]. 2159 7.2. General Characteristics 2161 LDACS will become one of several wireless access networks connecting 2162 aircraft to the Aeronautical Telecommunications Network (ATN). The 2163 LDACS access network contains several ground stations, each of them 2164 providing one LDACS radio cell. The LDACS air interface is a 2165 cellular data link with a star-topology connecting aircraft to 2166 ground-stations with a full duplex radio link. Each ground-station 2167 is the centralized instance controlling all air-ground communications 2168 within its radio cell. 2170 The user data rate of LDACS is 315 kbit/s to 1428 kbit/s on the 2171 forward link, and 294 kbit/s to 1390 kbit/s on the reverse link, 2172 depending on coding and modulation. Due to strong interference from 2173 legacy systems in the L-band, the most robust coding and modulation 2174 SHOULD be expected for initial deployment i.e. 315/294 kbit/s on the 2175 forward/reverse link, respectively. 2177 In addition to the communications capability, LDACS also offers a 2178 navigation capability. Ranging data, similar to DME (Distance 2179 Measuring Equipment), is extracted from the LDACS communication links 2180 between aircraft and LDACS ground stations. This results in LDACS 2181 providing an APNT (Alternative Position, Navigation and Timing) 2182 capability to supplement the existing on-board GNSS (Global 2183 Navigation Satellite System) without the need for additional 2184 bandwidth. Operationally, there will be no difference for pilots 2185 whether the navigation data are provided by LDACS or DME. This 2186 capability was flight tested and proven during the MICONAV flight 2187 trials in 2019 [BAT19]. 2189 In previous works and during the MICONAV flight campaign in 2019, it 2190 was also shown, that LDACS can be used for surveillance capability. 2191 Filip et al. [FIL19] shown passive radar capabilities of LDACS and 2192 Automatic Dependence Surveillance - Contract (ADS-C) was demonstrated 2193 via LDACS during the flight campaign 2019 [SCH19]. 2195 Since LDACS has been mainly designed for air traffic management 2196 communication it supports mutual entity authentication, integrity and 2197 confidentiality capabilities of user data messages and some control 2198 channel protection capabilities [MAE18], [MAE191], [MAE192], [MAE20]. 2200 Overall this makes LDACS the world's first truly integrated CNS 2201 system and is the worldwide most mature, secure, terrestrial long- 2202 range CNS technology for civil aviation. 2204 7.3. Deployment and Spectrum 2206 LDACS has its origin in merging parts of the B-VHF [BRA06], B-AMC 2207 [SCH08], TIA-902 (P34) [HAI09], and WiMAX IEEE 802.16e technologies 2208 [EHA11]. In 2007 the spectrum for LDACS was allocated at the World 2209 Radio Conference (WRC). 2211 It was decided to allocate the spectrum next to Distance Measuring 2212 Equipment (DME), resulting in an in-lay approach between the DME 2213 channels for LDAC [SCH14]. 2215 LDACS is currently being standardized by ICAO and several roll-out 2216 strategies are discussed: 2218 The LDACS data link provides enhanced capabilities to existing 2219 Aeronautical communications infrastructure enabling them to better 2220 support user needs and new applications. The deployment scalability 2221 of LDACS allows its implementation to start in areas where most 2222 needed to Improve immediately the performance of already fielded 2223 infrastructure. Later the deployment is extended based on 2224 operational demand. An attractive scenario for upgrading the 2225 existing VHF communication systems by adding an additional LDACS data 2226 link is described below. 2228 When considering the current VDL Mode 2 infrastructure and user base, 2229 a very attractive win-win situation comes about, when the 2230 technological advantages of LDACS are combined with the existing VDL 2231 mode 2 infrastructure. LDACS provides at least 50 time more capacity 2232 than VDL Mode 2 and is a natural enhancement to the existing VDL Mode 2233 2 business model. The advantage of this approach is that the VDL 2234 Mode 2 infrastructure can be fully reused. Beyond that, it opens the 2235 way for further enhancements which can increase business efficiency 2236 and minimize investment risk. [ICAO19] 2238 7.4. Applicability to Deterministic Flows 2240 As LDACS is a ground-based digital communications system for flight 2241 guidance and communications related to safety and regularity of 2242 flight, time-bounded deterministic arrival times for safety critical 2243 messages are a key feature for its successful deployment and roll- 2244 out. 2246 7.4.1. System Architecture 2248 Up to 512 Aircraft Station (AS) communicate to an LDACS Ground 2249 Station (GS) in the Reverse Link (RL). GS communicate to AS in the 2250 Forward Link (FL). Via an Access-Router (AC-R) GSs connect the LDACS 2251 sub-network to the global Aeronautical Telecommunications Network 2252 (ATN) to which the corresponding Air Traffic Services (ATS) and 2253 Aeronautical Operational Control (AOC) end systems are attached. 2255 7.4.2. Overview of The Radio Protocol Stack 2257 The protocol stack of LDACS is implemented in the AS and GS: It 2258 consists of the Physical Layer (PHY) with five major functional 2259 blocks above it. Four are placed in the Data Link Layer (DLL) of the 2260 AS and GS: (1) Medium Access Layer (MAC), (2) Voice Interface (VI), 2261 (3) Data Link Service (DLS), and (4) LDACS Management Entity (LME). 2262 The last entity resides within the Sub-Network Layer: Sub-Network 2263 Protocol (SNP). The LDACS network is externally connected to voice 2264 units, radio control units, and the ATN Network Layer. 2266 Figure 14 shows the protocol stack of LDACS as implemented in the AS 2267 and GS. 2269 IPv6 Network Layer 2270 | 2271 | 2272 +------------------+ +----+ 2273 | SNP |--| | Sub-Network 2274 | | | | Layer 2275 +------------------+ | | 2276 | | LME| 2277 +------------------+ | | 2278 | DLS | | | Logical Link 2279 | | | | Control Layer 2280 +------------------+ +----+ 2281 | | 2282 DCH DCCH/CCCH 2283 | RACH/BCCH 2284 | | 2285 +--------------------------+ 2286 | MAC | Medium Access 2287 | | Layer 2288 +--------------------------+ 2289 | 2290 +--------------------------+ 2291 | PHY | Physical Layer 2292 +--------------------------+ 2293 | 2294 | 2295 ((*)) 2296 FL/RL radio channels 2297 separated by 2298 Frequency Division Duplex 2300 Figure 14: LDACS protocol stack in AS and GS 2302 7.4.3. Radio (PHY) 2304 The physical layer provides the means to transfer data over the radio 2305 channel. The LDACS ground-station supports bi-directional links to 2306 multiple aircraft under its control. The forward link direction (FL; 2307 ground-to-air) and the reverse link direction (RL; air-to-ground) are 2308 separated by frequency division duplex. Forward link and reverse 2309 link use a 500 kHz channel each. The ground-station transmits a 2310 continuous stream of OFDM symbols on the forward link. In the 2311 reverse link different aircraft are separated in time and frequency 2312 using a combination of Orthogonal Frequency-Division Multiple-Access 2313 (OFDMA) and Time-Division Multiple-Access (TDMA). Aircraft thus 2314 transmit discontinuously on the reverse link with radio bursts sent 2315 in precisely defined transmission opportunities allocated by the 2316 ground-station. The most important service on the PHY layer of LDACS 2317 is the PHY time framing service, which indicates that the PHY layer 2318 is ready to transmit in a given slot and to indicate PHY layer 2319 framing and timing to the MAC time framing service. LDACS does not 2320 support beam-forming or Multiple Input Multiple Output (MIMO). 2322 7.4.4. Scheduling, Frame Structure and QoS (MAC) 2324 The data-link layer provides the necessary protocols to facilitate 2325 concurrent and reliable data transfer for multiple users. The LDACS 2326 data link layer is organized in two sub-layers: The medium access 2327 sub-layer and the logical link control sub-layer. The medium access 2328 sub-layer manages the organization of transmission opportunities in 2329 slots of time and frequency. The logical link control sub-layer 2330 provides acknowledged point-to-point logical channels between the 2331 aircraft and the ground-station using an automatic repeat request 2332 protocol. LDACS supports also unacknowledged point-to-point channels 2333 and ground-to-air broadcast. Before going more into depth about the 2334 LDACS medium access, the frame structure of LDACS is introduced: 2336 The LDACS framing structure for FL and RL is based on Super-Frames 2337 (SF) of 240 ms duration. Each SF corresponds to 2000 OFDM symbols. 2338 The FL and RL SF boundaries are aligned in time (from the view of the 2339 GS). 2341 In the FL, an SF contains a Broadcast Frame of duration 6.72 ms (56 2342 OFDM symbols) for the Broadcast Control Channel (BCCH), and four 2343 Multi-Frames (MF), each of duration 58.32 ms (486 OFDM symbols). 2345 In the RL, each SF starts with a Random Access (RA) slot of length 2346 6.72 ms with two opportunities for sending RL random access frames 2347 for the Random Access Channel (RACH), followed by four MFs. These 2348 MFs have the same fixed duration of 58.32 ms as in the FL, but a 2349 different internal structure 2351 Figure 15 and Figure 16 illustrate the LDACS frame structure. 2353 ^ 2354 | +------+------------+------------+------------+------------+ 2355 | FL | BCCH | MF | MF | MF | MF | 2356 F +------+------------+------------+------------+------------+ 2357 r <---------------- Super-Frame (SF) - 240ms ----------------> 2358 e 2359 q +------+------------+------------+------------+------------+ 2360 u RL | RACH | MF | MF | MF | MF | 2361 e +------+------------+------------+------------+------------+ 2362 n <---------------- Super-Frame (SF) - 240ms ----------------> 2363 c 2364 y 2365 | 2366 ----------------------------- Time ------------------------------> 2367 | 2369 Figure 15: SF structure for LDACS 2371 ^ 2372 | +-------------+------+-------------+ 2373 | FL | DCH | CCCH | DCH | 2374 F +-------------+------+-------------+ 2375 r <---- Multi-Frame (MF) - 58.32ms --> 2376 e 2377 q +------+---------------------------+ 2378 u RL | DCCH | DCH | 2379 e +------+---------------------------+ 2380 n <---- Multi-Frame (MF) - 58.32ms --> 2381 c 2382 y 2383 | 2384 -------------------- Time ------------------> 2385 | 2387 Figure 16: MF structure for LDACS 2389 This fixed frame structure allows for a reliable and dependable 2390 transmission of data. Next, the LDACS medium access layer is 2391 introduced: 2393 LDACS medium access is always under the control of the ground-station 2394 of a radio cell. Any medium access for the transmission of user data 2395 has to be requested with a resource request message stating the 2396 requested amount of resources and class of service. The ground- 2397 station performs resource scheduling on the basis of these requests 2398 and grants resources with resource allocation messages. Resource 2399 request and allocation messages are exchanged over dedicated 2400 contention-free control channels. 2402 LDACS has two mechanisms to request resources from the scheduler in 2403 the ground-station. Resources can either be requested "on demand" 2404 with a given class of service. On the forward link, this is done 2405 locally in the ground-station, on the reverse link a dedicated 2406 contention-free control channel is used (Dedicated Control Channel 2407 (DCCH); roughly 83 bit every 60 ms). A resource allocation is always 2408 announced in the control channel of the forward link (Common Control 2409 Channel (CCCH); variable sized). Due to the spacing of the reverse 2410 link control channels of every 60 ms, a medium access delay in the 2411 same order of magnitude is to be expected. 2413 Resources can also be requested "permanently". The permanent 2414 resource request mechanism supports requesting recurring resources in 2415 given time intervals. A permanent resource request has to be 2416 canceled by the user (or by the ground-station, which is always in 2417 control). User data transmissions over LDACS are therefore always 2418 scheduled by the ground-station, while control data uses statically 2419 (i.e. at net entry) allocated recurring resources (DCCH and CCCH). 2420 The current specification documents specify no scheduling algorithm. 2421 However performance evaluations so far have used strict priority 2422 scheduling and round robin for equal priorities for simplicity. In 2423 the current prototype implementations LDACS classes of service are 2424 thus realized as priorities of medium access and not as flows. Note 2425 that this can starve out low priority flows. However, this is not 2426 seen as a big problem since safety related message always go first in 2427 any case. Scheduling of reverse link resources is done in physical 2428 Protocol Data Units (PDU) of 112 bit (or larger if more aggressive 2429 coding and modulation is used). Scheduling on the forward link is 2430 done Byte-wise since the forward link is transmitted continuously by 2431 the ground-station. 2433 In order to support diversity, LDACS supports handovers to other 2434 ground-stations on different channels. Handovers may be initiated by 2435 the aircraft (break-before-make) or by the ground-station (make- 2436 before-break). Beyond this, FCI diversity shall be implemented by 2437 the multi-link concept. 2439 7.5. Summary 2441 LDACS has been designed with applications related to the safety and 2442 regularity of the flight in mind. It has therefore been designed as 2443 a deterministic wireless data link (as far as possible). 2445 It is a secure, scalable and spectrum efficient data link with 2446 embedded navigation capability and thus, is the first truly 2447 integrated CNS system recognized by ICAO. During flight tests the 2448 LDACS capabilities have been successfully demonstrated. A viable 2449 roll-out scenario has been developed which allows gradual 2450 introduction of LDACS with immediate use and revenues. Finally, ICAO 2451 is developing LDACS standards to pave the way for a successful roll- 2452 out in the near future. 2454 8. IANA Considerations 2456 This specification does not require IANA action. 2458 9. Security Considerations 2460 Most RAW technologies integrate some authentication or encryption 2461 mechanisms that were defined outside the IETF. 2463 10. Contributors 2465 This document aggregates articles from authors specialized in each 2466 technologies. Beyond the main authors listed in the front page, the 2467 following contributors proposed additional text and refinement that 2468 improved the documertn greatly! 2470 Georgios Z. Papadopoulos: Contributed to the TSCH section. 2472 Nils Mäurer: Contributed to the LDACS section. 2474 Thomas Gräupl: Contributed to the LDACS section. 2476 Janos Farkas, Torsten Dudda, Alexey Shapin, and Sara Sandberg: Contr 2477 ibuted to the 5G section. 2479 Rocco Di Taranto: Contributed to the Wi-Fi section 2481 11. Acknowledgments 2483 Many thanks to the participants of the RAW WG where a lot of the work 2484 discussed here happened. 2486 12. Normative References 2488 [RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH 2489 Operation Sublayer (6top) Protocol (6P)", RFC 8480, 2490 DOI 10.17487/RFC8480, November 2018, 2491 . 2493 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2494 (IPv6) Specification", STD 86, RFC 8200, 2495 DOI 10.17487/RFC8200, July 2017, 2496 . 2498 [RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T. 2499 Phinney, "Industrial Routing Requirements in Low-Power and 2500 Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October 2501 2009, . 2503 [RFC8557] Finn, N. and P. Thubert, "Deterministic Networking Problem 2504 Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019, 2505 . 2507 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 2508 "Deterministic Networking Architecture", RFC 8655, 2509 DOI 10.17487/RFC8655, October 2019, 2510 . 2512 [RFC9030] Thubert, P., Ed., "An Architecture for IPv6 over the Time- 2513 Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", 2514 RFC 9030, DOI 10.17487/RFC9030, May 2021, 2515 . 2517 [RFC9033] Chang, T., Ed., Vučinić, M., Vilajosana, X., Duquennoy, 2518 S., and D. Dujovne, "6TiSCH Minimal Scheduling Function 2519 (MSF)", RFC 9033, DOI 10.17487/RFC9033, May 2021, 2520 . 2522 13. Informative References 2524 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 2525 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 2526 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 2527 Low-Power and Lossy Networks", RFC 6550, 2528 DOI 10.17487/RFC6550, March 2012, 2529 . 2531 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 2532 and D. Barthel, "Routing Metrics Used for Path Calculation 2533 in Low-Power and Lossy Networks", RFC 6551, 2534 DOI 10.17487/RFC6551, March 2012, 2535 . 2537 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 2538 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 2539 Acronym in the IETF", BCP 161, RFC 6291, 2540 DOI 10.17487/RFC6291, June 2011, 2541 . 2543 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 2544 Weingarten, "An Overview of Operations, Administration, 2545 and Maintenance (OAM) Tools", RFC 7276, 2546 DOI 10.17487/RFC7276, June 2014, 2547 . 2549 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 2550 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 2551 Explicit Replication (BIER)", RFC 8279, 2552 DOI 10.17487/RFC8279, November 2017, 2553 . 2555 [I-D.ietf-raw-architecture] 2556 Thubert, P., Papadopoulos, G. Z., and L. Berger, "Reliable 2557 and Available Wireless Architecture/Framework", Work in 2558 Progress, Internet-Draft, draft-ietf-raw-architecture-00, 2559 12 July 2021, . 2562 [I-D.ietf-roll-nsa-extension] 2563 Koutsiamanis, R., Papadopoulos, G., Montavont, N., and P. 2564 Thubert, "Common Ancestor Objective Function and Parent 2565 Set DAG Metric Container Extension", Work in Progress, 2566 Internet-Draft, draft-ietf-roll-nsa-extension-10, 29 2567 October 2020, . 2570 [I-D.papadopoulos-paw-pre-reqs] 2571 Papadopoulos, G., Koutsiamanis, R., Montavont, N., and P. 2572 Thubert, "Exploiting Packet Replication and Elimination in 2573 Complex Tracks in LLNs", Work in Progress, Internet-Draft, 2574 draft-papadopoulos-paw-pre-reqs-01, 25 March 2019, 2575 . 2578 [I-D.thubert-bier-replication-elimination] 2579 Thubert, P., Eckert, T., Brodard, Z., and H. Jiang, "BIER- 2580 TE extensions for Packet Replication and Elimination 2581 Function (PREF) and OAM", Work in Progress, Internet- 2582 Draft, draft-thubert-bier-replication-elimination-03, 3 2583 March 2018, . 2586 [I-D.thubert-6lo-bier-dispatch] 2587 Thubert, P., Brodard, Z., Jiang, H., and G. Texier, "A 2588 6loRH for BitStrings", Work in Progress, Internet-Draft, 2589 draft-thubert-6lo-bier-dispatch-06, 28 January 2019, 2590 . 2593 [I-D.ietf-bier-te-arch] 2594 Eckert, T., Cauchie, G., and M. Menth, "Tree Engineering 2595 for Bit Index Explicit Replication (BIER-TE)", Work in 2596 Progress, Internet-Draft, draft-ietf-bier-te-arch-10, 9 2597 July 2021, . 2600 [I-D.ietf-6tisch-coap] 2601 Sudhaakar, R. S. and P. Zand, "6TiSCH Resource Management 2602 and Interaction using CoAP", Work in Progress, Internet- 2603 Draft, draft-ietf-6tisch-coap-03, 9 March 2015, 2604 . 2607 [IEEE Std 802.15.4] 2608 IEEE standard for Information Technology, "IEEE Std 2609 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 2610 and Physical Layer (PHY) Specifications for Low-Rate 2611 Wireless Personal Area Networks". 2613 [IEEE Std 802.11] 2614 IEEE standard for Information Technology, "IEEE Standard 2615 802.11 - IEEE Standard for Information Technology - 2616 Telecommunications and information exchange between 2617 systems Local and metropolitan area networks - Specific 2618 requirements - Part 11: Wireless LAN Medium Access Control 2619 (MAC) and Physical Layer (PHY) Specifications.", 2620 . 2622 [IEEE Std 802.11ax] 2623 IEEE standard for Information Technology, "802.11ax: 2624 Enhancements for High Efficiency WLAN", 2021, 2625 . 2627 [IEEE Std 802.11ay] 2628 IEEE standard for Information Technology, "802.11ay: 2629 Enhanced throughput for operation in license-exempt bands 2630 above 45 GHz", 2021, 2631 . 2633 [IEEE Std 802.11ad] 2634 "802.11ad: Enhancements for very high throughput in the 60 2635 GHz band", 2012, 2636 . 2638 [IEEE 802.11be WIP] 2639 IEEE standard for Information Technology, "802.11be: 2640 Extreme High Throughput PAR", 2641 . 2644 [IEEE Std 802.1Qat] 2645 "802.1Qat: Stream Reservation Protocol". 2647 [IEEE8021Qcc] 2648 IEEE standard for Information Technology, "802.1Qcc: IEEE 2649 Standard for Local and Metropolitan Area Networks--Bridges 2650 and Bridged Networks -- Amendment 31: Stream Reservation 2651 Protocol (SRP) Enhancements and Performance Improvements". 2653 [Cavalcanti_2019] 2654 Dave Cavalcanti et al., "Extending Time Distribution and 2655 Timeliness Capabilities over the Air to Enable Future 2656 Wireless Industrial Automation Systems, the Proceedings of 2657 IEEE", June 2019. 2659 [Nitsche_2015] 2660 Thomas Nitsche et al., "IEEE 802.11ad: directional 60 GHz 2661 communication for multi-Gigabit-per-second Wi-Fi", 2662 December 2014. 2664 [Ghasempour_2017] 2665 Yasaman Ghasempour et al., "802.11ay: Next-Generation 60 2666 GHz Communications for 100 Gb/s Wi-Fi", December 2017. 2668 [IEEE_doc_11-18-2009-06] 2669 IEEE standard for Information Technology, "802.11 Real- 2670 Time Applications (RTA) Topic Interest Group (TIG) 2671 Report", November 2018. 2673 [IEEE_doc_11-19-0373-00] 2674 Kevin Stanton et Al., "Time-Sensitive Applications Support 2675 in EHT", March 2019. 2677 [morell13] Antoni Morell et al., "Label switching over IEEE802.15.4e 2678 networks", April 2013. 2680 [dearmas16] 2681 Jesica de Armas et al., "Determinism through path 2682 diversity: Why packet replication makes sense", September 2683 2016. 2685 [vilajosana19] 2686 Xavier Vilajosana et al., "6TiSCH: Industrial Performance 2687 for IPv6 Internet-of-Things Networks", June 2019. 2689 [ISA100.11a] 2690 ISA/IEC, "ISA100.11a, Wireless Systems for Automation, 2691 also IEC 62734", 2011, . 2695 [WirelessHART] 2696 www.hartcomm.org, "Industrial Communication Networks - 2697 Wireless Communication Network and Communication Profiles 2698 - WirelessHART - IEC 62591", 2010. 2700 [PCE] IETF, "Path Computation Element", 2701 . 2703 [CCAMP] IETF, "Common Control and Measurement Plane", 2704 . 2706 [TiSCH] IETF, "IPv6 over the TSCH mode over 802.15.4", 2707 . 2709 [RIH18] Rihacek, C., Haindl, B., Fantappie, P., Pierattelli, S., 2710 Gräupl, T., Schnell, M., and N. Fistas, "L-band Digital 2711 Aeronautical Communications System (LDACS) Activities in 2712 SESAR2020", Proceedings of the Integrated Communications 2713 Navigation and Surveillance Conference (ICNS) Herndon, VA, 2714 USA, April 2018. 2716 [GRA19] Gräupl, T., Rihacek, C., and B. Haindl, "LDACS A/G 2717 Specification", SESAR2020 PJ14-02-01 D3.3.010, February 2718 2019. 2720 [SAJ14] Sajatovic, M., Günzel, H., and S. Müller, "WA04 D22 Test 2721 Report for Assessing LDACS1 Transmitter Impact upon DME/ 2722 TACAN Receivers", April 2014. 2724 [GRA11] Gräupl, T. and M. Ehammer, "L-DACS1 Data Link Layer 2725 Evolution of ATN/IPS", Proceedings of the 30th IEEE/AIAA 2726 Digital Avionics Systems Conference (DASC) Seattle, WA, 2727 USA, October 2011. 2729 [ICAO18] International Civil Aviation Organization (ICAO), "L-Band 2730 Digital Aeronautical Communication System (LDACS)", 2731 International Standards and Recommended Practices Annex 10 2732 - Aeronautical Telecommunications, Vol. III - 2733 Communication Systems, July 2018. 2735 [GRA18] al., T. G. E., "L-band Digital Aeronautical Communications 2736 System (LDACS) flight trials in the national German 2737 project MICONAV", Proceedings of the Integrated 2738 Communications, Navigation, Surveillance Conference 2739 (ICNS) Herndon, VA, USA, April 2018. 2741 [SCH19] Schnell, M., "DLR tests digital communications 2742 technologies combined with additional navigation functions 2743 for the first time", 3 March 2019, 2744 . 2747 [TR37910] "3GPP TR 37.910, Study on self evaluation towards IMT-2020 2748 submission", 2749 . 2752 [TR38824] "3GPP TR 38.824, Study on physical layer enhancements for 2753 NR ultra-reliable and low latency case (URLLC)", 2754 . 2757 [TR38825] "3GPP TR 38.825, Study on NR industrial Internet of Things 2758 (IoT)", 2759 . 2762 [TS22104] "3GPP TS 22.104, Service requirements for cyber-physical 2763 control applications in vertical domains", 2764 . 2767 [TR22804] "3GPP TR 22.804, Study on Communication for Automation in 2768 Vertical domains (CAV)", 2769 . 2772 [TS23501] "3GPP TS 23.501, System architecture for the 5G System 2773 (5GS)", 2774 . 2777 [TS38300] "3GPP TS 38.300, NR Overall description", 2778 . 2781 [IMT2020] "ITU towards IMT for 2020 and beyond", 2782 . 2785 [I-D.ietf-detnet-ip-over-tsn] 2786 Varga, B., Farkas, J., Malis, A. G., and S. Bryant, 2787 "Deterministic Networking (DetNet) Data Plane: IP over 2788 IEEE 802.1 Time-Sensitive Networking (TSN)", Work in 2789 Progress, Internet-Draft, draft-ietf-detnet-ip-over-tsn- 2790 07, 19 February 2021, 2791 . 2794 [IEEE802.1TSN] 2795 IEEE 802.1, "Time-Sensitive Networking (TSN) Task Group", 2796 . 2798 [IEEE802.1AS] 2799 IEEE, "IEEE Standard for Local and metropolitan area 2800 networks -- Timing and Synchronization for Time-Sensitive 2801 Applications", IEEE 802.1AS-2020, 2802 . 2805 [IEEE802.1CB] 2806 IEEE, "IEEE Standard for Local and metropolitan area 2807 networks -- Frame Replication and Elimination for 2808 Reliability", DOI 10.1109/IEEEStd2017.8091139, IEEE 2809 802.1CB-2017, 2810 . 2812 [IEEE802.1Qbv] 2813 IEEE, "IEEE Standard for Local and metropolitan area 2814 networks -- Bridges and Bridged Networks -- Amendment 25: 2815 Enhancements for Scheduled Traffic", IEEE 802.1Qbv-2015, 2816 . 2818 [IEEE802.1Qcc] 2819 IEEE, "IEEE Standard for Local and metropolitan area 2820 networks -- Bridges and Bridged Networks -- Amendment 31: 2821 Stream Reservation Protocol (SRP) Enhancements and 2822 Performance Improvements", IEEE 802.1Qcc-2018, 2823 . 2825 [IEEE802.3] 2826 IEEE, "IEEE Standard for Ethernet", IEEE 802.3-2018, 2827 . 2829 [ETR5GTSN] Farkas, J., Varga, B., Miklos, G., and J. Sachs, "5G-TSN 2830 integration meets networking requirements for industrial 2831 automation", Ericsson Technology Review, Volume 9, No 7, 2832 August 2019, . 2836 [MAE18] Maeurer, N. and A. Bilzhause, "A Cybersecurity 2837 Architecture for the L-band Digital Aeronautical 2838 Communications System (LDACS)", IEEE 37th Digital Avionics 2839 Systems Conference (DASC), pp. 1-10, London, UK , 2017. 2841 [MAE191] Maeurer, N. and C. Schmitt, "Towards Successful 2842 Realization of the LDACS Cybersecurity Architecture: An 2843 Updated Datalink Security Threat- and Risk Analysis", IEEE 2844 Integrated Communications, Navigation and Surveillance 2845 Conference (ICNS), pp. 1-13, Herndon, VA, USA , 2019. 2847 [ICAO19] International Civil Aviation Organization (ICAO), "TLDACS 2848 White Paper–A Roll-out Scenario", Working Paper 2849 COMMUNICATIONS PANEL-DATA COMMUNICATIONS INFRASTRUCTURE 2850 WORKING GROUP, Montreal, Canada , October 2019. 2852 [MAE192] Maeurer, N., Graeupl, T., and C. Schmitt, "Evaluation of 2853 the LDACS Cybersecurity Implementation", IEEE 38th Digital 2854 Avionics Systems Conference (DACS), pp. 1-10, San Diego, 2855 CA, USA , September 2019. 2857 [MAE20] Maeurer, N., Graeupl, T., and C. Schmitt, "Comparing 2858 Different Diffie-Hellman Key Exchange Flavors for LDACS", 2859 IEEE 39th Digital Avionics Systems Conference (DACS), pp. 2860 1-10, San Diego, CA, USA , October 2019. 2862 [FIL19] Filip-Dhaubhadel, A. and D. Shutin, "LDACS- Based Non- 2863 Cooperative Surveillance Multistatic Radar Design and 2864 Detection Coverage Assessment", IEEE 38th Digital Avionics 2865 Systems Conference (DACS), pp. 1-10, San Diego, CA, USA , 2866 September 2019. 2868 [BAT19] Battista, G., Osechas, O., Narayanan, S., Crespillo, O.G., 2869 Gerbeth, D., Maeurer, N., Mielke, D., and T. Graeupl, 2870 "Real-Time Demonstration of Integrated Communication and 2871 Navigation Services Using LDACS", IEEE Integrated 2872 Communications, Navigation and Surveillance Conference 2873 (ICNS), pp. 1-12, Herndon, VA, USA , 2019. 2875 [BRA06] Brandes, S., Schnell, M., Rokitansky, C.H., Ehammer, M., 2876 Graeupl, T., Steendam, H., Guenach, M., Rihacek, C., and 2877 B. Haindl, "B-VHF -Selected Simulation Results and Final 2878 Assessment", IEEE 25th Digital Avionics Systems Conference 2879 (DACS), pp. 1-12, New York, NY, USA , September 2019. 2881 [SCH08] Schnell, M., Brandes, S., Gligorevic, S., Rokitansky, 2882 C.H., Ehammer, M., Graeupl, T., Rihacek, C., and M. 2883 Sajatovic, "B-AMC - Broadband Aeronautical Multi-carrier 2884 Communications", IEEE 8th Integrated Communications, 2885 Navigation and Surveillance Conference (ICNS), pp. 1-13, 2886 New York, NY, USA , April 2008. 2888 [HAI09] Haindl, B., Rihacek, C., Sajatovic, M., Phillips, B., 2889 Budinger, J., Schnell, M., Kamiano, D., and W. Wilson, 2890 "Improvement of L-DACS1 Design by Combining B-AMC with P34 2891 and WiMAX Technologies", IEEE 9th Integrated 2892 Communications, Navigation and Surveillance Conference 2893 (ICNS), pp. 1-8, New York, NY, USA , May 2009. 2895 [EHA11] Ehammer, M. and T. Graeupl, "AeroMACS - An Airport 2896 Communications System", IEEE 30th Digital Avionics Systems 2897 Conference (DACS), pp. 1-16, New York, NY, USA , September 2898 2011. 2900 [SCH14] Schnell, M., Epple, U., Shutin, D., and N. 2901 Schneckenburger, "LDACS: Future Aeronautical 2902 Communications for Air- Traffic Management", IEEE 2903 Communications Magazine, 52(5), 104-110 , 2017. 2905 [Cavalcanti1287] 2906 Cavalcanti, D., Venkatesan, G., Cariou, L., and C. 2907 Vordeiro, "TSN support in 802.11 and potential extensions 2908 for TGbe", 2019, 2909 . 2911 [Sudhakaran2021] 2912 Sudhakaran, S., Montgomery, K., Kashef, M., Cavalcanti, 2913 D., and R. Candell, "Wireless Time Sensitive Networking 2914 for Industrial Collaborative Robotic Workcells", 17th IEEE 2915 International Conference on Factory Communication Systems 2916 (WFCS) , 2021, 2917 . 2919 Authors' Addresses 2921 Pascal Thubert (editor) 2922 Cisco Systems, Inc 2923 Building D 2924 45 Allee des Ormes - BP1200 2925 06254 MOUGINS - Sophia Antipolis 2926 France 2928 Phone: +33 497 23 26 34 2929 Email: pthubert@cisco.com 2931 Dave Cavalcanti 2932 Intel Corporation 2933 2111 NE 25th Ave 2934 Hillsboro, OR, 97124 2935 United States of America 2937 Phone: 503 712 5566 2938 Email: dave.cavalcanti@intel.com 2940 Xavier Vilajosana 2941 Universitat Oberta de Catalunya 2942 156 Rambla Poblenou 2943 08018 Barcelona Catalonia 2944 Spain 2946 Email: xvilajosana@uoc.edu 2948 Corinna Schmitt 2949 Research Institute CODE, UniBwM 2950 Werner-Heisenberg-Weg 39 2951 85577 Neubiberg 2952 Germany 2954 Email: corinna.schmitt@unibw.de 2955 Janos Farkas 2956 Ericsson 2957 Budapest 2958 Magyar tudosok korutja 11 2959 1117 2960 Hungary 2962 Email: janos.farkas@ericsson.com