idnits 2.17.1 draft-thubert-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 5 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 807: '... the 6TiSCH LLN MUST be swapped into ...' RFC 2119 keyword, line 866: '...he configuration MUST enable correlate...' RFC 2119 keyword, line 868: '...n a'AND'relation MUST be configurable ...' RFC 2119 keyword, line 878: '... transmissions SHOULD NOT be attempt...' RFC 2119 keyword, line 883: '... any of branches MUST be attempted reg...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (6 January 2020) is 1571 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'IEEE80211' is defined on line 1677, but no explicit reference was found in the text == Unused Reference: 'IEEE80211ak' is defined on line 1685, but no explicit reference was found in the text == Unused Reference: 'IEEE80211ay' is defined on line 1692, but no explicit reference was found in the text == Unused Reference: 'IEEE8021Qat' is defined on line 1703, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-28 == Outdated reference: A later version (-18) exists of draft-ietf-6tisch-msf-10 == Outdated reference: A later version (-12) exists of draft-ietf-roll-nsa-extension-05 == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-05 Summary: 1 error (**), 0 flaws (~~), 10 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: 9 July 2020 Intel 6 X. Vilajosana 7 Universitat Oberta de Catalunya 8 C. Schmitt 9 Research Institute CODE, UniBwM 10 6 January 2020 12 Reliable and Available Wireless Technologies 13 draft-thubert-raw-technologies-04 15 Abstract 17 This document presents a series of recent technologies that are 18 capable of time synchronization and scheduling of transmission, 19 making them suitable to carry time-sensitive flows with high 20 reliability and availbility. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 9 July 2020. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. On Scheduling . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Benefits of Scheduling on Wires . . . . . . . . . . . . . 4 59 3.2. Benefits of Scheduling on Wireless . . . . . . . . . . . 5 60 4. IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. Provenance and Documents . . . . . . . . . . . . . . . . 5 62 4.2. 802.11ax High Efficiency (HE) . . . . . . . . . . . . . . 7 63 4.2.1. General Characteristics . . . . . . . . . . . . . . . 7 64 4.2.2. Applicability to deterministic flows . . . . . . . . 8 65 4.3. 802.11be Extreme High Throughput (EHT) . . . . . . . . . 10 66 4.3.1. General Characteristics . . . . . . . . . . . . . . . 10 67 4.3.2. Applicability to deterministic flows . . . . . . . . 11 68 4.4. 802.11ad and 802.11ay (mmWave operation) . . . . . . . . 12 69 4.4.1. General Characteristics . . . . . . . . . . . . . . . 12 70 4.4.2. Applicability to deterministic flows . . . . . . . . 12 71 5. IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . 13 72 5.1. Provenance and Documents . . . . . . . . . . . . . . . . 13 73 5.2. TimeSlotted Channel Hopping . . . . . . . . . . . . . . . 14 74 5.2.1. General Characteristics . . . . . . . . . . . . . . . 14 75 5.2.2. Applicability to Deterministic Flows . . . . . . . . 16 76 6. 3GPP Ultra-Reliable Low-Latency Communication . . . . . . . . 29 77 7. L-band Digital Aeronautical Communications System . . . . . . 30 78 7.1. Provenance and Documents . . . . . . . . . . . . . . . . 30 79 7.2. General Characteristics . . . . . . . . . . . . . . . . . 31 80 7.3. Applicability to Deterministic Flows . . . . . . . . . . 32 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 33 83 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33 84 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 85 12. Normative References . . . . . . . . . . . . . . . . . . . . 34 86 13. Informative References . . . . . . . . . . . . . . . . . . . 34 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 89 1. Introduction 91 When used in math or philosophy, the term "deterministic" generally 92 refers to a perfection where all aspect are understood and 93 predictable. A perfectly Deterministic Network would ensure that 94 every packet reach its destination following a predetermined path 95 along a predefined schedule to be delivered at the exact due time. 96 In a real and imperfect world, a Deterministic Network must highly 97 predictable, which is a combination of reliability and availability. 98 On the one hand the network must be reliable, meaning that it will 99 perform as expected for all packets and in particular that it will 100 always deliver the packet at the destination in due time. On the 101 other hand, the network must be available, meaning that it is 102 resilient to any single outage, whether the cause is a software, a 103 hardware or a transmission issue. 105 RAW (Reliable and Available Wireless) is an effort to provide 106 Deterministic Networking on across a path that include a wireless 107 physical layer. Making Wireless Reliable and Available is even more 108 challenging than it is with wires, due to the numerous causes of loss 109 in transmission that add up to the congestion losses and the delays 110 caused by overbooked shared resources. In order to maintain a 111 similar quality of service along a multihop path that is composed of 112 wired and wireless hops, additional methods that are specific to 113 wireless must be leveraged to combat the sources of loss that are 114 also specific to wireless. 116 Such wireless-specific methods include per-hop retransmissions (HARQ) 117 and P2MP overhearing whereby multiple receivers are scheduled to 118 receive the same transmission, which balances the adverse effects of 119 the transmission losses that are experienced when a radio is used as 120 pure P2P. 122 2. Terminology 124 This specification uses several terms that are uncommon on protocols 125 that ensure bets effort transmissions for stochastics flows, such as 126 found in the traditional Internet and other statistically multiplexed 127 packet networks. 129 ARQ: Automatic Repeat Request, enabling an acknowledged transmission 130 and retries. ARQ is a typical model at Layer-2 on a wireless 131 medium. It is typically avoided end-to-end on deterministic flows 132 because it introduces excessive indetermination in latency, but a 133 limited number of retries within a bounded time may be used over a 134 wireless link and yet respect end-to-end constraints. 136 Available: That is exempt of unscheduled outage, the expectation for 137 a network being that the flow is maintained in the face of any 138 single breakage. 140 FEC: Forward error correction, sending redundant coded data to help 141 the receiver recover transmission errors without the delays 142 incurred with ARQ. 144 HARQ: Hybrid ARQ, a combination of FEC and ARQ. 146 PCE: Path Computation Element. 148 PAREO (functions): the wireless extension of DetNet PREOF. PAREO 149 functions include scheduled ARQ at selected hops, and expect the 150 use of new operations like overhearing where available. 152 Reliable: That consistently performs as expected, the expectation 153 for a network being to always deliver a packet in due time. 155 Track: A DODAG oriented to a destination, and that enables Packet 156 ARQ, Replication, Elimination, and Ordering Functions. 158 3. On Scheduling 160 The operations of a Deterministic Network often rely on precisely 161 applying a tight schedule, in order to avoid collision loss and 162 guarantee the worst-case time of delivery. To achieve this, there 163 must be a shared sense of time throughout the network. The sense of 164 time is usually provided by the lower layer and is not in scope for 165 RAW. 167 3.1. Benefits of Scheduling on Wires 169 A network is reliable when the statistical effects that affect the 170 packet transmission are eliminated. This involves maintaining at all 171 time the amount of critical packets within the physical capabilities 172 of the hardware and that of the radio medium. This is achieved by 173 controlling the use of time-shared resources such as CPUs and 174 buffers, by shaping the flows and by scheduling the time of 175 transmission of the packets that compose the flow at every hop. 177 Equipment failure, such as an access point rebooting, a broken radio 178 adapter, or a permanent obstacle to the transmission, is a secondary 179 source of packet loss. When a breakage occurs, multiple packets are 180 lost in a row before the flows are rerouted or the system may 181 recover. This is not acceptable for critical applications such as 182 related to safety. A typical process control loop will tolerate an 183 occasional packet loss, but a loss of several packets in a row will 184 cause an emergency stop (e.g., after 4 packets lost, within a period 185 of 1 second). 187 Network Availability is obtained by making the transmission resilient 188 against hardware failures and radio transmission losses due to 189 uncontrolled events such as co-channel interferers, multipath fading 190 or moving obstacles. The best results are typically achieved by 191 pseudo randomly cumulating all forms of diversity, in the spatial 192 domain with replication and elimination, in the time domain with ARQ 193 and diverse scheduled transmissions, and in the frequency domain with 194 frequency hopping or channel hopping between frames. 196 3.2. Benefits of Scheduling on Wireless 198 In addition to the benefits listed in Section 3.1, scheduling 199 transmissions provides specific value to the wireless medium. 201 On the one hand, scheduling avoids collisions between scheduled 202 transmissions and can ensure both time and frequency diversity 203 between retries in order to defeat co-channel interference from un- 204 controlled transmitters as well as multipath fading. Transmissions 205 can be scheduled on multiple channels in parallel, which enables to 206 use the full available spectrum while avoiding the hidden terminal 207 problem, e.g., when the next packet in a same flow interferes on a 208 same channel with the previous one that progressed a few hops 209 farther. 211 On the other hand, scheduling optimizes the bandwidth usage: compared 212 to classical Collision Avoidance techniques, there is no blank time 213 related to inter-frame space (IFS) and exponential back-off in 214 scheduled operations. A minimal Clear Channel Assessment may be 215 needed to comply with the local regulations such as ETSI 300-328, but 216 that will not detect a collision when the senders are synchronized. 217 And because scheduling allows a time-sharing operation, there is no 218 limit to the ratio of isolated critical traffic. 220 Finally, scheduling plays a critical role to save energy. In IOT, 221 energy is the foremost concern, and synchronizing sender and listener 222 enables to always maintain them in deep sleep when there is no 223 scheduled transmission. This avoids idle listening and long 224 preambles and enables long sleep periods between traffic and 225 resynchronization, allowing battery-operated nodes to operate in a 226 mesh topology for multiple years. 228 4. IEEE 802.11 230 4.1. Provenance and Documents 232 With an active portfolio of nearly 1,300 standards and projects under 233 development, IEEE is a leading developer of industry standards in a 234 broad range of technologies that drive the functionality, 235 capabilities, and interoperability of products and services, 236 transforming how people live, work, and communicate. 238 The IEEE 802 LAN/MAN Standards Committee (SC) develops and maintains 239 networking standards and recommended practices for local, 240 metropolitan, and other area networks, using an open and accredited 241 process, and advocates them on a global basis. The most widely used 242 standards are for Ethernet, Bridging and Virtual Bridged LANs 243 Wireless LAN, Wireless PAN, Wireless MAN, Wireless Coexistence, Media 244 Independent Handover Services, and Wireless RAN. An individual 245 Working Group provides the focus for each area. Standards produced 246 by the IEEE 802 SC are freely available from the IEEE GET Program 247 after they have been published in PDF for six months. 249 The IEEE 802.11 LAN standards define the underlying MAC and PHY 250 layers for the Wi-Fi technology. Wi-Fi/802.11 is one of the most 251 successful wireless technologies, supporting many application 252 domains. While previous 802.11 generations, such as 802.11n and 253 802.11ac, have focused mainly on improving peak throughput, more 254 recent generations are also considering other performance vectors, 255 such as efficiency enhancements for dense environments in 802.11ax, 256 and latency and support for Time-Sensitive Networking (TSN) 257 capabilities in 802.11be. 259 IEEE 802.11 already supports some 802.1 TSN standards and it is 260 undergoing efforts to support for other 802.1 TSN capabilities 261 required to address the use cases that require time synchronization 262 and timeliness (bounded latency) guarantees with high reliability and 263 availability. The IEEE 802.11 working group has been working in 264 collaboration with the IEEE 802.1 group for several years extending 265 802.1 features over 802.11. As with any wireless media, 802.11 266 imposes new constraints and restrictions to TSN-grade QoS, and 267 tradeoffs between latency and reliability guarantees must be 268 considered as well as managed deployment requirements. An overview 269 of 802.1 TSN capabilities and their extensions to 802.11 are 270 discussed in [Cavalcanti_2019]. 272 Wi-Fi Alliance (WFA) is the worldwide network of companies that 273 drives global Wi-Fi adoption and evolution through thought 274 leadership, spectrum advocacy, and industry-wide collaboration. The 275 WFA work helps ensure that Wi-Fi devices and networks provide users 276 the interoperability, security, and reliability they have come to 277 expect. 279 The following IEEE 802.11 specifications/certifications are relevant 280 in the context of reliable and available wireless services and 281 support for time-sensitive networking capabilities: 283 Time Synchronization: IEEE802.11-2016 with IEEE802.1AS; WFA TimeSync 284 Certification. 286 Congestion Control: IEEE802.11-2016 Admission Control; WFA Admission 287 Control. 289 Security: WFA Wi-Fi Protected Access, WPA2 and WPA3. 291 Interoperating with IEEE802.1Q bridges: IEEE802.11ak. 293 Stream Reservation Protocol (part of IEEE802.1Qat): 294 AIEEE802.11-2016. 296 Scheduled channel access: IEEE802.11ad Enhancements for very high 297 throughput in the 60 GHz band [IEEE80211ad]. 299 802.11 Real-Time Applications: Topic Interest Group (TIG) ReportDoc 300 [IEEE_doc_11-18-2009-06]. 302 In addition, major amendments being developed by the IEEE802.11 303 Working Group include capabilities that can be used as the basis for 304 providing more reliable and predictable wireless connectivity and 305 support time-sensitive applications: 307 IEEE 802.11ax D4.0: Enhancements for High Efficiency (HE). [IEEE8021 308 1ax] 310 IEEE 802.11be Extreme High Throughput (EHT). [IEEE80211be] 312 IEE 802.11ay Enhanced throughput for operation in license-exempt 313 bands above 45 GHz. [IEEE8021 314 1ay] 316 The main 802.11ax and 802.11be capabilities and their relevance to 317 RAW are discussed in the remainder of this document. 319 4.2. 802.11ax High Efficiency (HE) 321 4.2.1. General Characteristics 323 The next generation Wi-Fi (Wi-Fi 6) is based on the IEEE802.11ax 324 amendment [IEEE80211ax], which includes new capabilities to increase 325 efficiency, control and reduce latency. Some of the new features 326 include higher order 1024-QAM modulation, support for uplink multi- 327 user MIMO, OFDMA, trigger-based access and Target Wake time (TWT) for 328 enhanced power savings. The OFDMA mode and trigger-based access 329 enable scheduled operation, which is a key capability required to 330 support deterministic latency and reliability for time-sensitive 331 flows. 802.11ax can operate in up to 160 MHz channels and it includes 332 support for operation in the new 6 GHz band, which is expected to be 333 open to unlicensed use by the FCC and other regulatory agencies 334 worldwide. 336 4.2.1.1. Multi-User OFDMA and Trigger-based Scheduled Access 338 802.11ax introduced a new orthogonal frequency-division multiple 339 access (OFDMA) mode in which multiple users can be scheduled across 340 the frequency domain. In this mode, the Access Point (AP) can 341 initiate multi-user (MU) Uplink (UL) transmissions in the same PHY 342 Protocol Data Unit (PPDU) by sending a trigger frame. This 343 centralized scheduling capability gives the AP much more control of 344 the channel, and it can remove contention between devices for uplink 345 transmissions, therefore reducing the randomness caused by CSMA-based 346 access between stations. The AP can also transmit simultaneously to 347 multiple users in the downlink direction by using a Downlink (DL) MU 348 OFDMA PPDU. In order to initiate a contention free Transmission 349 Opportunity (TXOP) using the OFDMA mode, the AP still follows the 350 typical listen before talk procedure to acquire the medium, which 351 ensures interoperability and compliance with unlicensed band access 352 rules. However, 802.11ax also includes a multi-user Enhanced 353 Distributed Channel Access (MU-EDCA) capability, which allows the AP 354 to get higher channel access priority. 356 4.2.1.2. Improved PHY Robustness 358 The 802.11ax PHY can operate with 0.8, 1.6 or 3.2 microsecond guard 359 interval (GI). The larger GI options provide better protection 360 against multipath, which is expected to be a challenge in industrial 361 environments. The possibility to operate with smaller resource units 362 (e.g. 2 MHz) enabled by OFDMA also helps reduce noise power and 363 improve SNR, leading to better packet error rate (PER) performance. 365 802.11ax supports beamforming as in 802.11ac, but introduces UL MU 366 MIMO, which helps improve reliability. The UL MU MIMO capability is 367 also enabled by the trigger based access operation in 802.11ax. 369 4.2.1.3. Support for 6GHz band 371 The 802.11ax specification [IEEE80211ax] includes support for 372 operation in the new 6 GHz band. Given the amount of new spectrum 373 available as well as the fact that no legacy 802.11 device (prior 374 802.11ax) will be able to operate in this new band, 802.11ax 375 operation in this new band can be even more efficient. 377 4.2.2. Applicability to deterministic flows 379 TSN capabilities, as defined by the IEEE 802.1 TSN standards, provide 380 the underlying mechanism for supporting deterministic flows in a 381 Local Area Network (LAN). The 802.11 working group has already 382 incorporated support for several TSN capabilities, so that time- 383 sensitive flow can experience precise time synchronization and 384 timeliness when operating over 802.11 links. TSN capabilities 385 supported over 802.11 (which also extends to 802.11ax), include: 387 1. 802.1AS based Time Synchronization (other time synchronization 388 techniques may also be used) 390 2. Interoperating with IEEE802.1Q bridges 392 3. Time-sensitive Traffic Stream identification 394 The exiting 802.11 TSN capabilities listed above, and the 802.11ax 395 OFDMA and scheduled access provide a new set of tools to better 396 server time-sensitive flows. However, it is important to understand 397 the tradeoffs and constraints associated with such capabilities, as 398 well as redundancy and diversity mechanisms that can be used to 399 provide more predictable and reliable performance. 401 4.2.2.1. 802.11 Managed network operation and admission control 403 Time-sensitive applications and TSN standards are expected to operate 404 under a managed network (e.g. industrial/enterprise network). Thus, 405 the Wi-Fi operation must also be carefully managed and integrated 406 with the overall TSN management framework, as defined in the IEEE 407 Std. 802.1Qcc specification [IEEE8021Qcc]. 409 Some of the random-access latency and interference from legacy/ 410 unmanaged devices can be minimized under a centralized management 411 mode as defined in IEEE Std. 802.1Qcc, in which admission control 412 procedures are enforced. 414 Existing traffic stream identification, configuration and admission 415 control procedures defined in IEEE Std. 802.11 QoS mechanism can be 416 re-used. However, given the high degree of determinism required by 417 many time-sensitive applications, additional capabilities to manage 418 interference and legacy devices within tight time-constraints need to 419 be explored. 421 4.2.2.2. Scheduling for bounded latency and diversity 423 As discussed earlier, the 802.11ax OFDMA mode introduces the 424 possibility of assigning different RUs (frequency resources) to users 425 within a PPDU. Several RU sizes are defined in the specification 426 (26, 52, 106, 242, 484, 996 subcarriers). In addition, the AP can 427 also decide on MCS and grouping of users within a given OFMDA PPDU. 428 Such flexibility can be leveraged to support time-sensitive 429 applications with bounded latency, especially in a managed network 430 where stations can be configured to operate under the control of the 431 AP. 433 As shown in [Cavalcanti_2019], it is possible to achieve latencies in 434 the order of 1msec with high reliability in an interference free 435 environment. Obviously, there are latency, reliability and capacity 436 tradeoffs to be considered. For instance, smaller Resource Units 437 (RU)s result in longer transmission durations, which may impact the 438 minimal latency that can be achieved, but the contention latency and 439 randomness elimination due to multi-user transmission is a major 440 benefit of the OFDMA mode. 442 The flexibility to dynamically assign RUs to each transmission also 443 enables the AP to provide frequency diversity, which can help 444 increase reliability. 446 4.3. 802.11be Extreme High Throughput (EHT) 448 4.3.1. General Characteristics 450 The 802.11be is the next major 802.11 amendment (after 802.11ax) for 451 operation in the 2.4, 5 and 6 GHz bands. 802.11be is expected to 452 include new PHY and MAC features and it is targeting extremely high 453 throughput (at least 30 Gbps), as well as enhancements to worst case 454 latency and jitter. It is also expected to improve the integration 455 with 802.1 TSN to support time-sensitive applications over Ethernet 456 and Wireless LANs. 458 The 802.11be Task Group started its operation in May 2019, therefore, 459 detailed information about specific features is not yet available. 460 Only high level candidate features have been discussed so far, 461 including: 463 1. 320MHz bandwidth and more efficient utilization of non-contiguous 464 spectrum. 466 2. Multi-band/multi-channel aggregation and operation. 468 3. 16 spatial streams and related MIMO enhancements. 470 4. Multi-Access Point (AP) Coordination. 472 5. Enhanced link adaptation and retransmission protocol, e.g. 473 Hybrid Automatic Repeat Request (HARQ). 475 6. Any required adaptations to regulatory rules for the 6 GHz 476 spectrum. 478 4.3.2. Applicability to deterministic flows 480 The 802.11 Real-Time Applications (RTA) Topic Interest Group (TIG) 481 provided detailed information on use cases, issues and potential 482 solution directions to improve support for time-sensitive 483 applications in 802.11. The RTA TIG report [IEEE_doc_11-18-2009-06] 484 was used as input to the 802.11be project scope. 486 Improvements for worst-case latency, jitter and reliability were the 487 main topics identified in the RTA report, which were motivated by 488 applications in gaming, industrial automation, robotics, etc. The 489 RTA report also highlighted the need to support additional TSN 490 capabilities, such as time-aware (802.1Qbv) shaping and packet 491 replication and elimination as defined in 802.1CB. 493 802.11be is expected to build on and enhance 802.11ax capabilities to 494 improve worst case latency and jitter. Some of the enhancement areas 495 are discussed next. 497 4.3.2.1. Enhanced scheduled operation for bounded latency 499 In addition to the throughput enhancements, 802.11be will leverage 500 the trigger-based scheduled operation enabled by 802.11ax to provide 501 efficient and more predictable medium access. 802.11be is expected to 502 include enhancements to reduce overhead and enable more efficient 503 operation in managed network deployments [IEEE_doc_11-19-0373-00]. 505 4.3.2.2. Multi-AP coordination 507 Multi-AP coordination is one of the main new candidate features in 508 802.11be. It can provide benefits in throughput and capacity and has 509 the potential to address some of the issues that impact worst case 510 latency and reliability. Multi-AP coordination is expected to 511 address the contention due to overlapping Basic Service Sets (OBSS), 512 which is one of the main sources of random latency variations. 513 802.11be can define methods to enable better coordination between 514 APs, for instance, in a managed network scenario, in order to reduce 515 latency due to unmanaged contention. 517 Several multi-AP coordination approaches have been discussed with 518 different levels of complexities and benefits, but specific 519 coordination methods have not yet been defined. 521 4.3.2.3. Multi-band operation 523 802.11be will introduce new features to improve operation over 524 multiple bands and channels. By leveraging multiple bands/channels, 525 802.11be can isolate time-sensitive traffic from network congestion, 526 one of the main causes of large latency variations. In a managed 527 802.11be network, it should be possible to steer traffic to certain 528 bands/channels to isolate time-sensitive traffic from other traffic 529 and help achieve bounded latency. 531 4.4. 802.11ad and 802.11ay (mmWave operation) 533 4.4.1. General Characteristics 535 The IEEE 802.11ad amendment defines PHY and MAC capabilities to 536 enable multi-Gbps throughput in the 60 GHz millimeter wave (mmWave) 537 band. The standard addresses the adverse mmWave signal propagation 538 characteristics and provides directional communication capabilities 539 that take advantage of beamforming to cope with increased 540 attenuation. An overview of the 802.11ad standard can be found in 541 [Nitsche_2015] . 543 The IEEE 802.11ay is currently developing enhancements to the 544 802.11ad standard to enable the next generation mmWave operation 545 targeting 100 Gbps throughput. Some of the main enhancements in 546 802.11ay include MIMO, channel bonding, improved channel access and 547 beamforming training. An overview of the 802.11ay capabilities can 548 be found in [Ghasempour_2017] 550 4.4.2. Applicability to deterministic flows 552 The high data rates achievable with 802.11ad and 802.11ay can 553 significantly reduce latency down to microsecond levels. Limited 554 interference from legacy and other unlicensed devices in 60 GHz is 555 also a benefit. However, directionality and short range typical in 556 mmWave operation impose new challenges such as the overhead required 557 for beam training and blockage issues, which impact both latency and 558 reliability. Therefore, it is important to understand the use case 559 and deployment conditions in order to properly apply and configure 560 802.11ad/ay networks for time sensitive applications. 562 The 802.11ad standard include a scheduled access mode in which 563 stations can be allocated contention-free service periods by a 564 central controller. This scheduling capability is also available in 565 802.11ay, and it is one of the mechanisms that can be used to provide 566 bounded latency to time-sensitive data flows. An analysis of the 567 theoretical latency bounds that can be achieved with 802.11ad service 568 periods is provided in [Cavalcanti_2019]. 570 5. IEEE 802.15.4 572 5.1. Provenance and Documents 574 The IEEE802.15.4 Task Group has been driving the development of low- 575 power low-cost radio technology. The IEEE802.15.4 physical layer has 576 been designed to support demanding low-power scenarios targeting the 577 use of unlicensed bands, both the 2.4 GHz and sub GHz Industrial, 578 Scientific and Medical (ISM) bands. This has imposed requirements in 579 terms of frame size, data rate and bandwidth to achieve reduced 580 collision probability, reduced packet error rate, and acceptable 581 range with limited transmission power. The PHY layer supports frames 582 of up to 127 bytes. The Medium Access Control (MAC) sublayer 583 overhead is in the order of 10-20 bytes, leaving about 100 bytes to 584 the upper layers. IEEE802.15.4 uses spread spectrum modulation such 585 as the Direct Sequence Spread Spectrum (DSSS). 587 The Timeslotted Channel Hopping (TSCH) mode was added to the 2015 588 revision of the IEEE802.15.4 standard [IEEE802154]. TSCH is targeted 589 at the embedded and industrial world, where reliability, energy 590 consumption and cost drive the application space. 592 At the IETF, the 6TiSCH Working Group (WG) [TiSCH] deals with best 593 effort operation of IPv6 [RFC8200] over TSCH. 6TiSCH has enabled 594 distributed scheduling to exploit the deterministic access 595 capabilities provided by TSCH. The group designed the essential 596 mechanisms to enable the management plane operation while ensuring 597 IPv6 is supported. Yet the charter did not focus to providing a 598 solution to establish end to end Tracks while meeting quality of 599 service requirements. 6TiSCH, through the RFC8480 [RFC8480] defines 600 the 6P protocol which provides a pairwise negotiation mechanism to 601 the control plane operation. The protocol supports agreement on a 602 schedule between neighbors, enabling distributed scheduling. 6P goes 603 hand-in-hand with a Scheduling Function (SF), the policy that decides 604 how to maintain cells and trigger 6P transactions. The Minimal 605 Scheduling Function (MSF) [I-D.ietf-6tisch-msf] is the default SF 606 defined by the 6TiSCH WG; other standardized SFs can be defined in 607 the future. MSF extends the minimal schedule configuration, and is 608 used to add child-parent links according to the traffic load. 610 Time sensitive networking on low power constrained wireless networks 611 have been partially addressed by ISA100.11a [ISA100.11a] and 612 WirelessHART [WirelessHART]. Both technologies involve a central 613 controller that computes redundant paths for industrial process 614 control traffic over a TSCH mesh. Moreover, ISA100.11a introduces 615 IPv6 capabilities with a Link-Local Address for the join process and 616 a global unicast addres for later exchanges, but the IPv6 traffic 617 typically ends at a local application gateway and the full power of 618 IPv6 for end-to-end communication is not enabled. Compared to that 619 state of the art, work at the IETF and in particular at RAW could 620 provide additional techniques such as optimized P2P routing, PAREO 621 functions, and end-to-end secured IPv6/CoAP connectivity. 623 The 6TiSCH architecture [I-D.ietf-6tisch-architecture] identifies 624 different models to schedule resources along so-called Tracks (see 625 Section 5.2.2.2) exploiting the TSCH schedule structure however the 626 focus at 6TiSCH is on best effort traffic and the group was never 627 chartered to produce standard work related to Tracks. 629 Useful References include: 631 1. IEEE Std 802.15.4: "IEEE Std. 802.15.4, Part. 15.4: Wireless 632 Medium Access Control (MAC) and Physical Layer (PHY) 633 Specifications for Low-Rate Wireless Personal Area Networks" 634 [IEEE802154]. The latest version at the time of this writing is 635 dated year 2015. 637 2. Morell, A. , Vilajosana, X. , Vicario, J. L. and Watteyne, T. 638 (2013), Label switching over IEEE802.15.4e networks. Trans. 639 Emerging Tel. Tech., 24: 458-475. doi:10.1002/ett.2650" 640 [morell13]. 642 3. De Armas, J., Tuset, P., Chang, T., Adelantado, F., Watteyne, T., 643 Vilajosana, X. (2016, September). Determinism through path 644 diversity: Why packet replication makes sense. In 2016 645 International Conference on Intelligent Networking and 646 Collaborative Systems (INCoS) (pp. 150-154). IEEE. [dearmas16]. 648 4. X. Vilajosana, T. Watteyne, M. Vucinic, T. Chang and K. S. 649 J. Pister, "6TiSCH: Industrial Performance for IPv6 Internet-of- 650 Things Networks," in Proceedings of the IEEE, vol. 107, no. 6, 651 pp. 1153-1165, June 2019. [vilajosana19]. 653 5.2. TimeSlotted Channel Hopping 655 5.2.1. General Characteristics 657 As a core technique in IEEE802.15.4, TSCH splits time in multiple 658 time slots that repeat over time. A set of timeslots constructs a 659 Slotframe (see Section 5.2.2.1.4). For each timeslot, a set of 660 available frequencies can be used, resulting in a matrix-like 661 schedule (see Figure 1). 663 timeslot offset 664 | 0 1 2 3 4 | 0 1 2 3 4 | Nodes 665 +------------------------+------------------------+ +-----+ 666 | | | | | | | | | | | | C | 667 CH-1 | EB | | |C->B| | EB | | |C->B| | | | 668 | | | | | | | | | | | +-----+ 669 +-------------------------------------------------+ | 670 | | | | | | | | | | | | 671 CH-2 | | |B->C| |B->A| | |B->C| |B->A| +-----+ 672 | | | | | | | | | | | | B | 673 +-------------------------------------------------+ | | 674 ... +-----+ 675 | 676 +-------------------------------------------------+ | 677 | | | | | | | | | | | +-----+ 678 CH-15| |A->B| | | | |A->B| | | | | A | 679 | | | | | | | | | | | | | 680 +-------------------------------------------------+ +-----+ 681 ch. 682 offset 684 Figure 1: Slotframe example with scheduled cells between nodes A, 685 B and C 687 This schedule represents the possible communications of a node with 688 its neighbors, and is managed by a Scheduling Function such as the 689 Minimal Scheduling Function (MSF) [I-D.ietf-6tisch-msf]. Each cell 690 in the schedule is identified by its slotoffset and channeloffset 691 coordinates. A cell's timeslot offset indicates its position in 692 time, relative to the beginning of the slotframe. A cell's channel 693 offset is an index which maps to a frequency at each iteration of the 694 slotframe. Each packet exchanged between neighbors happens within 695 one cell. The size of a cell is a timeslot duration, between 10 to 696 15 milliseconds. An Absolute Slot Number (ASN) indicates the number 697 of slots elapsed since the network started. It increments at every 698 slot. This is a 5 byte counter that can support networks running for 699 more than 300 years without wrapping (assuming a 10 ms timeslot). 700 Channel hopping provides increased reliability to multi-path fading 701 and external interference. It is handled by TSCH through a channel 702 hopping sequence referred as macHopSeq in the IEEE802.15.4 703 specification. 705 The Time-Frequency Division Multiple Access provided by TSCH enables 706 the orchestration of traffic flows, spreading them in time and 707 frequency, and hence enabling an efficient management of the 708 bandwidth utilization. Such efficient bandwidth utilization can be 709 combined to OFDM modulations also supported by the IEEE802.15.4 710 standard [IEEE802154] since the 2015 version. 712 In the RAW context, low power reliable networks should address non- 713 critical control scenarios such as Class 2 and monitoring scenarios 714 such as Class 4 defined by the RFC5673 [RFC5673]. As a low power 715 technology targeting industrial scenarios radio transducers provide 716 low data rates (typically between 50kbps to 250kbps) and robust 717 modulations to trade-off performance to reliability. TSCH networks 718 are organized in mesh topologies and connected to a backbone. 719 Latency in the mesh network is mainly influenced by propagation 720 aspects such as interference. ARQ methods and redundancy techniques 721 such as replication and elimination should be studied to provide the 722 needed performance to address deterministic scenarios. 724 5.2.2. Applicability to Deterministic Flows 726 Nodes in a TSCH network are tightly synchronized. This enables to 727 build the slotted structure and ensure efficient utilization of 728 resources thanks to proper scheduling policies. Scheduling is a key 729 to orchestrate the resources that different nodes in a Track or a 730 path are using. Slotframes can be split in resource blocks reserving 731 the needed capacity to certain flows. Periodic and bursty traffic 732 can be handled independently in the schedule, using active and 733 reactive policies and taking advantage of overprovisionned cells to 734 measu reth excursion. Along a Track, resource blocks can be chained 735 so nodes in previous hops transmit their data before the next packet 736 comes. This provides a tight control to latency along a Track. 737 Collision loss is avoided for best effort traffic by 738 overprovisionning resources, giving time to the management plane of 739 the network to dedicate more resources if needed. 741 5.2.2.1. Centralized Path Computation 743 In a controlled environment, a 6TiSCH device usually does not place a 744 request for bandwidth between itself and another device in the 745 network. Rather, an Operation Control System (OCS) invoked through 746 an Human/Machine Interface (HMI) iprovides the Traffic Specification, 747 in particular in terms of latency and reliability, and the end nodes, 748 to a Path Computation element (PCE). With this, the PCE computes a 749 Track between the end nodes and provisions every hop in the Track 750 with per-flow state that describes the per-hop operation for a given 751 packet, the corresponding timeSlots, and the flow identification to 752 recognize which packet is placed in which Track, sort out duplicates, 753 etc. In Figure 2, an example of Operational Control System and HMI 754 is depicted. 756 For a static configuration that serves a certain purpose for a long 757 period of time, it is expected that a node will be provisioned in one 758 shot with a full schedule, which incorporates the aggregation of its 759 behavior for multiple Tracks. The 6TiSCH Architecture expects that 760 the programing of the schedule is done over CoAP as discussed in 761 "6TiSCH Resource Management and Interaction using CoAP" 762 [I-D.ietf-6tisch-coap]. 764 But an Hybrid mode may be required as well whereby a single Track is 765 added, modified, or removed, for instance if it appears that a Track 766 does not perform as expected for, say, Packet Delivery Ratio (PDR). 767 For that case, the expectation is that a protocol that flows along a 768 Track (to be), in a fashion similar to classical Traffic Engineering 769 (TE) [CCAMP], may be used to update the state in the devices. 6TiSCH 770 provides means for a device to negotiate a timeSlot with a neighbor, 771 but in general that flow was not designed and no protocol was 772 selected and it is expected that DetNet will determine the 773 appropriate end-to-end protocols to be used in that case. 775 Stream Management Entity 777 Operational Control System and HMI 779 -+-+-+-+-+-+-+ Northbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 781 PCE PCE PCE PCE 783 -+-+-+-+-+-+-+ Southbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 785 --- 6TiSCH------6TiSCH------6TiSCH------6TiSCH-- 786 6TiSCH / Device Device Device Device \ 787 Device- - 6TiSCH 788 \ 6TiSCH 6TiSCH 6TiSCH 6TiSCH / Device 789 ----Device------Device------Device------Device-- 791 Figure 2 793 5.2.2.1.1. Packet Marking and Handling 795 Section "Packet Marking and Handling" of 796 [I-D.ietf-6tisch-architecture] describes the packet tagging and 797 marking that is expected in 6TiSCH networks. 799 5.2.2.1.1.1. Tagging Packets for Flow Identification 801 For packets that are routed by a PCE along a Track, the tuple formed 802 by the IPv6 source address and a local RPLInstanceID is tagged in the 803 packets to identify uniquely the Track and associated transmit bundle 804 of timeSlots. 806 It results that the tagging that is used for a DetNet flow outside 807 the 6TiSCH LLN MUST be swapped into 6TiSCH formats and back as the 808 packet enters and then leaves the 6TiSCH network. 810 Note: The method and format used for encoding the RPLInstanceID at 811 6lo is generalized to all 6TiSCH topological Instances, which 812 includes Tracks. 814 5.2.2.1.1.2. Replication, Retries and Elimination 816 PRE establishes several paths in a network to provide redundancy and 817 parallel transmissions to bound the end-to-end delay. Considering 818 the scenario shown in Figure 3, many different paths are possible for 819 S to reach R. A simple way to benefit from this topology could be to 820 use the two independent paths via nodes A, C, E and via B, D, F. But 821 more complex paths are possible as well. 823 (A) (C) (E) 825 source (S) (R) (destination) 827 (B) (D) (F) 829 Figure 3: A Typical Ladder Shape with Two Parallel Paths Toward 830 the Destination 832 By employing a Packet Replication function, each node forwards a copy 833 of each data packet over two different branches. For instance, in 834 Figure 4, the source node S transmits the data packet to nodes A and 835 B, in two different timeslots within the same TSCH slotframe. 837 ===> (A) => (C) => (E) === 838 // \\// \\// \\ 839 source (S) //\\ //\\ (R) (destination) 840 \\ // \\ // \\ // 841 ===> (B) => (D) => (F) === 843 Figure 4: Packet Replication: S transmits twice the same data 844 packet, to its DP (A) and to its AP (B). 846 By employing Packet Elimination function once a node receives the 847 first copy of a data packet, it discards the subsequent copies. 848 Because the first copy that reaches a node is the one that matters, 849 it is the only copy that will be forwarded upward. 851 Considering that the wireless medium is broadcast by nature, any 852 neighbor of a transmitter may overhear a transmission. By employing 853 the Promiscuous Overhearing function, nodes will have multiple 854 opportunities to receive a given data packet. For instance, in 855 Figure 4, when the source node S transmits the data packet to node A, 856 node B may overhear this transmission. 858 6TiSCH expects elimination and replication of packets along a complex 859 Track, but has no position about how the sequence numbers would be 860 tagged in the packet. 862 As it goes, 6TiSCH expects that timeSlots corresponding to copies of 863 a same packet along a Track are correlated by configuration, and does 864 not need to process the sequence numbers. 866 The semantics of the configuration MUST enable correlated timeSlots 867 to be grouped for transmit (and respectively receive) with 868 a'OR'relations, and then a'AND'relation MUST be configurable between 869 groups. The semantics is that if the transmit (and respectively 870 receive) operation succeeded in one timeSlot in a'OR'group, then all 871 the other timeSLots in the group are ignored. Now, if there are at 872 least two groups, the'AND'relation between the groups indicates that 873 one operation must succeed in each of the groups. 875 On the transmit side, timeSlots provisioned for retries along a same 876 branch of a Track are placed a same'OR'group. The'OR'relation 877 indicates that if a transmission is acknowledged, then further 878 transmissions SHOULD NOT be attempted for timeSlots in that group. 879 There are as many'OR'groups as there are branches of the Track 880 departing from this node. Different'OR'groups are programmed for the 881 purpose of replication, each group corresponding to one branch of the 882 Track. The'AND'relation between the groups indicates that 883 transmission over any of branches MUST be attempted regardless of 884 whether a transmission succeeded in another branch. It is also 885 possible to place cells to different next-hop routers in a 886 same'OR'group. This allows to route along multi-path Tracks, trying 887 one next-hop and then another only if sending to the first fails. 889 On the receive side, all timeSlots are programmed in a same'OR'group. 890 Retries of a same copy as well as converging branches for elimination 891 are converged, meaning that the first successful reception is enough 892 and that all the other timeSlots can be ignored. 894 5.2.2.1.1.3. Differentiated Services Per-Hop-Behavior 896 Additionally, an IP packet that is sent along a Track uses the 897 Differentiated Services Per-Hop-Behavior Group called Deterministic 898 Forwarding, as described in 899 [I-D.svshah-tsvwg-deterministic-forwarding]. 901 5.2.2.1.2. Topology and capabilities 903 6TiSCH nodes are usually IoT devices, characterized by very limited 904 amount of memory, just enough buffers to store one or a few IPv6 905 packets, and limited bandwidth between peers. It results that a node 906 will maintain only a small number of peering information, and will 907 not be able to store many packets waiting to be forwarded. Peers can 908 be identified through MAC or IPv6 addresses. 910 Neighbors can be discovered over the radio using mechanism such as 911 Enhanced Beacons, but, though the neighbor information is available 912 in the 6TiSCH interface data model, 6TiSCH does not describe a 913 protocol to pro-actively push the neighborhood information to a PCE. 914 This protocol should be described and should operate over CoAP. The 915 protocol should be able to carry multiple metrics, in particular the 916 same metrics as used for RPL operations [RFC6551]. 918 The energy that the device consumes in sleep, transmit and receive 919 modes can be evaluated and reported. So can the amount of energy 920 that is stored in the device and the power that it can be scavenged 921 from the environment. The PCE SHOULD be able to compute Tracks that 922 will implement policies on how the energy is consumed, for instance 923 balance between nodes, ensure that the spent energy does not exceeded 924 the scavenged energy over a period of time, etc... 926 5.2.2.1.3. Schedule Management by a PCE 928 6TiSCH supports a mixed model of centralized routes and distributed 929 routes. Centralized routes can for example be computed by a entity 930 such as a PCE [PCE]. Distributed routes are computed by RPL 931 [RFC6550]. 933 Both methods may inject routes in the Routing Tables of the 6TiSCH 934 routers. In either case, each route is associated with a 6TiSCH 935 topology that can be a RPL Instance topology or a Track. The 6TiSCH 936 topology is indexed by a Instance ID, in a format that reuses the 937 RPLInstanceID as defined in RPL. 939 Both RPL and PCE rely on shared sources such as policies to define 940 Global and Local RPLInstanceIDs that can be used by either method. 941 It is possible for centralized and distributed routing to share a 942 same topology. Generally they will operate in different slotFrames, 943 and centralized routes will be used for scheduled traffic and will 944 have precedence over distributed routes in case of conflict between 945 the slotFrames. 947 5.2.2.1.4. SlotFrames and Priorities 949 A slotFrame is the base object that a PCE needs to manipulate to 950 program a schedule into an LLN node. Elaboration on that concept can 951 be fond in section "SlotFrames and Priorities" of 952 [I-D.ietf-6tisch-architecture] 954 IEEE802.15.4 TSCH avoids contention on the medium by formatting time 955 and frequencies in cells of transmission of equal duration. In order 956 to describe that formatting of time and frequencies, the 6TiSCH 957 architecture defines a global concept that is called a Channel 958 Distribution and Usage (CDU) matrix; a CDU matrix is a matrix of 959 cells with an height equal to the number of available channels 960 (indexed by ChannelOffsets) and a width (in timeSlots) that is the 961 period of the network scheduling operation (indexed by slotOffsets) 962 for that CDU matrix. The size of a cell is a timeSlot duration, and 963 values of 10 to 15 milliseconds are typical in 802.15.4 TSCH to 964 accommodate for the transmission of a frame and an acknowledgement, 965 including the security validation on the receive side which may take 966 up to a few milliseconds on some device architecture. 968 The frequency used by a cell in the matrix rotates in a pseudo-random 969 fashion, from an initial position at an epoch time, as the matrix 970 iterates over and over. 972 A CDU matrix is computed by the PCE, but unallocated timeSlots may be 973 used opportunistically by the nodes for classical best effort IP 974 traffic. The PCE has precedence in the allocation in case of a 975 conflict. 977 In a given network, there might be multiple CDU matrices that operate 978 with different width, so they have different durations and represent 979 different periodic operations. It is recommended that all CDU 980 matrices in a 6TiSCH domain operate with the same cell duration and 981 are aligned, so as to reduce the chances of interferences from 982 slotted-aloha operations. The PCE MUST compute the CDU matrices and 983 shared that knowledge with all the nodes. The matrices are used in 984 particular to define slotFrames. 986 A slotFrame is a MAC-level abstraction that is common to all nodes 987 and contains a series of timeSlots of equal length and precedence. 988 It is characterized by a slotFrame_ID, and a slotFrame_size. A 989 slotFrame aligns to a CDU matrix for its parameters, such as number 990 and duration of timeSlots. 992 Multiple slotFrames can coexist in a node schedule, i.e., a node can 993 have multiple activities scheduled in different slotFrames, based on 994 the precedence of the 6TiSCH topologies. The slotFrames may be 995 aligned to different CDU matrices and thus have different width. 996 There is typically one slotFrame for scheduled traffic that has the 997 highest precedence and one or more slotFrame(s) for RPL traffic. The 998 timeSlots in the slotFrame are indexed by the SlotOffset; the first 999 cell is at SlotOffset 0. 1001 The 6TiSCH architecture introduces the concept of chunks 1002 ([I-D.ietf-6tisch-architecture]) to operate such spectrum 1003 distribution for a whole group of cells at a time. The CDU matrix is 1004 formatted into a set of chunks, each of them identified uniquely by a 1005 chunk-ID, see Figure 5. The PCE MUST compute the partitioning of CDU 1006 matrices into chunks and shared that knowledge with all the nodes in 1007 a 6TiSCH network. 1009 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 1010 chan.Off. 0 |chnkA|chnkP|chnk7|chnkO|chnk2|chnkK|chnk1| ... |chnkZ| 1011 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 1012 chan.Off. 1 |chnkB|chnkQ|chnkA|chnkP|chnk3|chnkL|chnk2| ... |chnk1| 1013 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 1014 ... 1015 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 1016 chan.Off. 15 |chnkO|chnk6|chnkN|chnk1|chnkJ|chnkZ|chnkI| ... |chnkG| 1017 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 1018 0 1 2 3 4 5 6 M 1020 Figure 5: CDU matrix Partitioning in Chunks 1022 The appropriation of a chunk can be requested explicitly by the PCE 1023 to any node. After a successful appropriation, the PCE owns the 1024 cells in that chunk, and may use them as hard cells to set up Tracks. 1025 Then again, 6TiSCH did not propose a method for chunk definition and 1026 a protocol for appropriation. This is to be done at RAW. 1028 5.2.2.2. 6TiSCH Tracks 1030 A Track at 6TiSCH is the application to wireless of the concept of a 1031 path in the Detnet architecture [I-D.ietf-detnet-architecture]. A 1032 Track can follow a simple sequence of relay nodes or can be 1033 structured as a more complex Destination Oriented Directed Acyclic 1034 Graph (DODAG) to a unicast destination. Along a Track, 6TiSCH nodes 1035 reserve the resources to enable the efficient transmission of packets 1036 while aiming to optimize certain properties such as reliability and 1037 ensure small jitter or bounded latency. The Track structure enables 1038 Layer-2 forwarding schemes, reducing the overhead of taking routing 1039 decisions at the Layer-3. 1041 Serial Tracks can be understood as the concatenation of cells or 1042 bundles along a routing path from a source towards a destination. 1043 The serial Track concept is analogous to the circuit concept where 1044 resources are chained through the multi-hop topology. For example, A 1045 bundle of Tx Cells in a particular node is paired to a bundle of Rx 1046 Cells in the next hop node following a routing path. 1048 Whereas scheduling ensures reliable delivery in bounded time along 1049 any Track, high availability requires the application of PAREO 1050 functions along a more complex DODAG Track structure. A DODAG has 1051 forking and joining nodes where the concepts such as Replication and 1052 Elimination can be exploited. Spatial redundancy increases the 1053 oveall energy consumption in the network but improves significantly 1054 the availability of the network as well as the packet delivery ratio. 1055 A Track may also branch off and rejoin, for the purpose of the so- 1056 called Packet Replication and Elimination (PRE), over non congruent 1057 branches. PRE may be used to complement layer-2 Automatic Repeat 1058 reQuest (ARQ) and receiver-end Ordering to form the PAREO functions. 1059 PAREO functions enable to meet industrial expectations in PDR within 1060 bounded delivery time over a Track that includes wireless links, even 1061 when the Track extends beyond the 6TiSCH network. 1063 +-----+ 1064 | IoT | 1065 | G/W | 1066 +-----+ 1067 ^ <---- Elimination 1068 | | 1069 Track branch | | 1070 +-------+ +--------+ Subnet Backbone 1071 | | 1072 +--|--+ +--|--+ 1073 | | | Backbone | | | Backbone 1074 o | | | router | | | router 1075 +--/--+ +--|--+ 1076 o / o o---o----/ o 1077 o o---o--/ o o o o o 1078 o \ / o o LLN o 1079 o v <---- Replication 1080 o 1082 Figure 6: End-to-End deterministic Track 1084 In the example above (see Figure 6), a Track is laid out from a field 1085 device in a 6TiSCH network to an IoT gateway that is located on a 1086 IEEE802.1 TSN backbone. 1088 The Replication function in the field device sends a copy of each 1089 packet over two different branches, and a PCE schedules each hop of 1090 both branches so that the two copies arrive in due time at the 1091 gateway. In case of a loss on one branch, hopefully the other copy 1092 of the packet still makes it in due time. If two copies make it to 1093 the IoT gateway, the Elimination function in the gateway ignores the 1094 extra packet and presents only one copy to upper layers. 1096 At each 6TiSCH hop along the Track, the PCE may schedule more than 1097 one timeSlot for a packet, so as to support Layer-2 retries (ARQ). 1098 It is also possible that the field device only uses the second branch 1099 if sending over the first branch fails. 1101 In current deployments, a TSCH Track does not necessarily support PRE 1102 but is systematically multi-path. This means that a Track is 1103 scheduled so as to ensure that each hop has at least two forwarding 1104 solutions, and the forwarding decision is to try the preferred one 1105 and use the other in case of Layer-2 transmission failure as detected 1106 by ARQ. 1108 Methods to implement complex Tracks are described in 1109 [I-D.papadopoulos-paw-pre-reqs] and complemented by extensions to the 1110 RPL routing protocol in [I-D.ietf-roll-nsa-extension] for best effort 1111 traffic, but a centralized routing technique such as promoted in 1112 DetNet is still missing. 1114 5.2.2.2.1. Track Scheduling Protocol 1116 Section "Schedule Management Mechanisms" of the 6TiSCH architecture 1117 describes 4 paradigms to manage the TSCH schedule of the LLN nodes: 1118 Static Scheduling, neighbor-to-neighbor Scheduling, remote monitoring 1119 and scheduling management, and Hop-by-hop scheduling. The Track 1120 operation for DetNet corresponds to a remote monitoring and 1121 scheduling management by a PCE. 1123 Early work at 6TiSCH on a data model and a protocol to program the 1124 schedule in the 6TiSCH device was never concluded as the group 1125 focussed on best effort traffic. This work would be revived by RAW: 1127 The 6top interface document [RFC8480] (to be reopened at RAW) was 1128 intended to specify the generic data model that can be used to 1129 monitor and manage resources of the 6top sublayer. Abstract 1130 methods were suggested for use by a management entity in the 1131 device. The data model also enables remote control operations on 1132 the 6top sublayer. 1134 [I-D.ietf-6tisch-coap] (to be reopened at RAW) was intended to 1135 define a mapping of the 6top set of commands, which is described 1136 in RFC 8480, to CoAP resources. This allows an entity to interact 1137 with the 6top layer of a node that is multiple hops away in a 1138 RESTful fashion. 1140 [I-D.ietf-6tisch-coap] also defined a basic set CoAP resources and 1141 associated RESTful access methods (GET/PUT/POST/DELETE). The 1142 payload (body) of the CoAP messages is encoded using the CBOR 1143 format. The PCE commands are expected to be issued directly as 1144 CoAP requests or to be mapped back and forth into CoAP by a 1145 gateway function at the edge of the 6TiSCH network. For instance, 1146 it is possible that a mapping entity on the backbone transforms a 1147 non-CoAP protocol such as PCEP into the RESTful interfaces that 1148 the 6TiSCH devices support. 1150 5.2.2.2.2. Track Forwarding 1152 By forwarding, this specification means the per-packet operation that 1153 allows to deliver a packet to a next hop or an upper layer in this 1154 node. Forwarding is based on pre-existing state that was installed 1155 as a result of the routing computation of a Track by a PCE. The 1156 6TiSCH architecture supports three different forwarding model, G-MPLS 1157 Track Forwarding (TF), 6LoWPAN Fragment Forwarding (FF) and IPv6 1158 Forwarding (6F) which is the classical IP operation 1159 [I-D.ietf-6tisch-architecture]. The DetNet case relates to the Track 1160 Forwarding operation under the control of a PCE. 1162 A Track is a unidirectional path between a source and a destination. 1163 In a Track cell, the normal operation of IEEE802.15.4 Automatic 1164 Repeat-reQuest (ARQ) usually happens, though the acknowledgment may 1165 be omitted in some cases, for instance if there is no scheduled cell 1166 for a retry. 1168 Track Forwarding is the simplest and fastest. A bundle of cells set 1169 to receive (RX-cells) is uniquely paired to a bundle of cells that 1170 are set to transmit (TX-cells), representing a layer-2 forwarding 1171 state that can be used regardless of the network layer protocol. 1172 This model can effectively be seen as a Generalized Multi-protocol 1173 Label Switching (G-MPLS) operation in that the information used to 1174 switch a frame is not an explicit label, but rather related to other 1175 properties of the way the packet was received, a particular cell in 1176 the case of 6TiSCH. As a result, as long as the TSCH MAC (and 1177 Layer-2 security) accepts a frame, that frame can be switched 1178 regardless of the protocol, whether this is an IPv6 packet, a 6LoWPAN 1179 fragment, or a frame from an alternate protocol such as WirelessHART 1180 or ISA100.11a. 1182 A data frame that is forwarded along a Track normally has a 1183 destination MAC address that is set to broadcast - or a multicast 1184 address depending on MAC support. This way, the MAC layer in the 1185 intermediate nodes accepts the incoming frame and 6top switches it 1186 without incurring a change in the MAC header. In the case of 1187 IEEE802.15.4, this means effectively broadcast, so that along the 1188 Track the short address for the destination of the frame is set to 1189 0xFFFF. 1191 A Track is thus formed end-to-end as a succession of paired bundles, 1192 a receive bundle from the previous hop and a transmit bundle to the 1193 next hop along the Track, and a cell in such a bundle belongs to at 1194 most one Track. For a given iteration of the device schedule, the 1195 effective channel of the cell is obtained by adding a pseudo-random 1196 number to the channelOffset of the cell, which results in a rotation 1197 of the frequency that used for transmission. The bundles may be 1198 computed so as to accommodate both variable rates and 1199 retransmissions, so they might not be fully used at a given iteration 1200 of the schedule. The 6TiSCH architecture provides additional means 1201 to avoid waste of cells as well as overflows in the transmit bundle, 1202 as follows: 1204 In one hand, a TX-cell that is not needed for the current iteration 1205 may be reused opportunistically on a per-hop basis for routed 1206 packets. When all of the frame that were received for a given Track 1207 are effectively transmitted, any available TX-cell for that Track can 1208 be reused for upper layer traffic for which the next-hop router 1209 matches the next hop along the Track. In that case, the cell that is 1210 being used is effectively a TX-cell from the Track, but the short 1211 address for the destination is that of the next-hop router. It 1212 results that a frame that is received in a RX-cell of a Track with a 1213 destination MAC address set to this node as opposed to broadcast must 1214 be extracted from the Track and delivered to the upper layer (a frame 1215 with an unrecognized MAC address is dropped at the lower MAC layer 1216 and thus is not received at the 6top sublayer). 1218 On the other hand, it might happen that there are not enough TX-cells 1219 in the transmit bundle to accommodate the Track traffic, for instance 1220 if more retransmissions are needed than provisioned. In that case, 1221 the frame can be placed for transmission in the bundle that is used 1222 for layer-3 traffic towards the next hop along the Track as long as 1223 it can be routed by the upper layer, that is, typically, if the frame 1224 transports an IPv6 packet. The MAC address should be set to the 1225 next-hop MAC address to avoid confusion. It results that a frame 1226 that is received over a layer-3 bundle may be in fact associated to a 1227 Track. In a classical IP link such as an Ethernet, off-Track traffic 1228 is typically in excess over reservation to be routed along the non- 1229 reserved path based on its QoS setting. But with 6TiSCH, since the 1230 use of the layer-3 bundle may be due to transmission failures, it 1231 makes sense for the receiver to recognize a frame that should be re- 1232 Tracked, and to place it back on the appropriate bundle if possible. 1233 A frame should be re-Tracked if the Per-Hop-Behavior group indicated 1234 in the Differentiated Services Field in the IPv6 header is set to 1235 Deterministic Forwarding, as discussed in Section 5.2.2.1.1. A frame 1236 is re-Tracked by scheduling it for transmission over the transmit 1237 bundle associated to the Track, with the destination MAC address set 1238 to broadcast. 1240 There are 2 modes for a Track, transport mode and tunnel mode. 1242 5.2.2.2.2.1. Transport Mode 1244 In transport mode, the Protocol Data Unit (PDU) is associated with 1245 flow-dependant meta-data that refers uniquely to the Track, so the 1246 6top sublayer can place the frame in the appropriate cell without 1247 ambiguity. In the case of IPv6 traffic, this flow identification is 1248 transported in the Flow Label of the IPv6 header. Associated with 1249 the source IPv6 address, the Flow Label forms a globally unique 1250 identifier for that particular Track that is validated at egress 1251 before restoring the destination MAC address (DMAC) and punting to 1252 the upper layer. 1254 | ^ 1255 +--------------+ | | 1256 | IPv6 | | | 1257 +--------------+ | | 1258 | 6LoWPAN HC | | | 1259 +--------------+ ingress egress 1260 | 6top | sets +----+ +----+ restores 1261 +--------------+ dmac to | | | | dmac to 1262 | TSCH MAC | brdcst | | | | self 1263 +--------------+ | | | | | | 1264 | LLN PHY | +-------+ +--...-----+ +-------+ 1265 +--------------+ 1267 Figure 7: Track Forwarding, Transport Mode 1269 5.2.2.2.2.2. Tunnel Mode 1271 In tunnel mode, the frames originate from an arbitrary protocol over 1272 a compatible MAC that may or may not be synchronized with the 6TiSCH 1273 network. An example of this would be a router with a dual radio that 1274 is capable of receiving and sending WirelessHART or ISA100.11a frames 1275 with the second radio, by presenting itself as an Access Point or a 1276 Backbone Router, respectively. 1278 In that mode, some entity (e.g. PCE) can coordinate with a 1279 WirelessHART Network Manager or an ISA100.11a System Manager to 1280 specify the flows that are to be transported transparently over the 1281 Track. 1283 +--------------+ 1284 | IPv6 | 1285 +--------------+ 1286 | 6LoWPAN HC | 1287 +--------------+ set restore 1288 | 6top | +dmac+ +dmac+ 1289 +--------------+ to|brdcst to|nexthop 1290 | TSCH MAC | | | | | 1291 +--------------+ | | | | 1292 | LLN PHY | +-------+ +--...-----+ +-------+ 1293 +--------------+ | ingress egress | 1294 | | 1295 +--------------+ | | 1296 | LLN PHY | | | 1297 +--------------+ | | 1298 | TSCH MAC | | | 1299 +--------------+ | dmac = | dmac = 1300 |ISA100/WiHART | | nexthop v nexthop 1301 +--------------+ 1303 Figure 8: Track Forwarding, Tunnel Mode 1305 In that case, the flow information that identifies the Track at the 1306 ingress 6TiSCH router is derived from the RX-cell. The dmac is set 1307 to this node but the flow information indicates that the frame must 1308 be tunneled over a particular Track so the frame is not passed to the 1309 upper layer. Instead, the dmac is forced to broadcast and the frame 1310 is passed to the 6top sublayer for switching. 1312 At the egress 6TiSCH router, the reverse operation occurs. Based on 1313 metadata associated to the Track, the frame is passed to the 1314 appropriate link layer with the destination MAC restored. 1316 5.2.2.2.2.3. Tunnel Metadata 1318 Metadata coming with the Track configuration is expected to provide 1319 the destination MAC address of the egress endpoint as well as the 1320 tunnel mode and specific data depending on the mode, for instance a 1321 service access point for frame delivery at egress. If the tunnel 1322 egress point does not have a MAC address that matches the 1323 configuration, the Track installation fails. 1325 In transport mode, if the final layer-3 destination is the tunnel 1326 termination, then it is possible that the IPv6 address of the 1327 destination is compressed at the 6LoWPAN sublayer based on the MAC 1328 address. It is thus mandatory at the ingress point to validate that 1329 the MAC address that was used at the 6LoWPAN sublayer for compression 1330 matches that of the tunnel egress point. For that reason, the node 1331 that injects a packet on a Track checks that the destination is 1332 effectively that of the tunnel egress point before it overwrites it 1333 to broadcast. The 6top sublayer at the tunnel egress point reverts 1334 that operation to the MAC address obtained from the tunnel metadata. 1336 5.2.2.2.2.4. OAM 1338 An Overview of Operations, Administration, and Maintenance (OAM) 1339 Tools [RFC7276] provides an overwiew of the existing tooling for OAM 1340 [RFC6291]. Tracks are complex paths and new tooling is necessary to 1341 manage them, with respect to load control, timing, and the Packet 1342 Replication and Elimination Functions (PREF). 1344 An example of such tooling can be found in the context of BIER 1345 [RFC8279] and more specifically BIER Traffic Engineering 1346 [I-D.ietf-bier-te-arch] (BIER-TE): 1347 [I-D.thubert-bier-replication-elimination] leverages BIER-TE to 1348 control the process of PREF, and to provide traceability of these 1349 operations, in the deterministic dataplane, along a complex Track. 1350 For the 6TiSCH type of constrained environment, 1351 [I-D.thubert-6lo-bier-dispatch] enables an efficient encoding of the 1352 BIER bitmap within the 6LoRH framework. 1354 6. 3GPP Ultra-Reliable Low-Latency Communication 1356 coming up 1358 7. L-band Digital Aeronautical Communications System 1360 One of the main pillars of the modern Air Traffic Management (ATM) 1361 system is the existence of a communication infrastructure that 1362 enables efficient aircraft guidance and safe separation in all phases 1363 of flight. Although current systems are technically mature, they are 1364 suffering from the VHF band's increasing saturation in high-density 1365 areas and the limitations posed by analogue radio. Therefore, 1366 aviation globally and the European Union (EU) in particular, strives 1367 for a sustainable modernization of the aeronautical communication 1368 infrastructure. 1370 In the long-term, ATM communication shall transition from analogue 1371 VHF voice and VDL2 communication to more spectrum efficient digital 1372 data communication. The European ATM Master Plan foresees this 1373 transition to be realized for terrestrial communications by the 1374 development and implementation of the L-band Digital Aeronautical 1375 Communications System (LDACS). LDACS shall enable IPv6 based air- 1376 ground communication related to the safety and regularity of the 1377 flight. The particular challenge is that no new frequencies can be 1378 made available for terrestrial aeronautical communication. It was 1379 thus necessary to develop procedures to enable the operation of LDACS 1380 in parallel with other services in the same frequency band. 1382 7.1. Provenance and Documents 1384 The development of LDACS has already made substantial progress in the 1385 Single European Sky ATM Research (SESAR) framework, and is currently 1386 being continued in the follow-up program, SESAR2020 [RIH18]. A key 1387 objective of the SESAR activities is to develop, implement and 1388 validate a modern aeronautical data link able to evolve with aviation 1389 needs over long-term. To this end, an LDACS specification has been 1390 produced [GRA19] and is continuously updated; transmitter 1391 demonstrators were developed to test the spectrum compatibility of 1392 LDACS with legacy systems operating in the L-band [SAJ14]; and the 1393 overall system performance was analyzed by computer simulations, 1394 indicating that LDACS can fulfil the identified requirements [GRA11]. 1396 LDACS standardization within the framework of the International Civil 1397 Aviation Organization (ICAO) started in December 2016. The ICAO 1398 standardization group has produced an initial Standards and 1399 Recommended Practices (SARPs) document [ICAO18]. The SARPs document 1400 defines the general characteristics of LDACS. The ICAO 1401 standardization group plans to produce an ICAO technical manual - the 1402 ICAO equivalent to a technical standard - within the next years. 1403 Generally, the group is open to input from all sources and develops 1404 LDACS in the open. 1406 Up to now the LDACS standardization has been focused on the 1407 development of the physical layer and the data link layer, only 1408 recently have higher layers come into the focus of the LDACS 1409 development activities. There is currently no "IPv6 over LDACS" 1410 specification; however, SESAR2020 has started the testing of 1411 IPv6-based LDACS testbeds. The IPv6 architecture for the 1412 aeronautical telecommunication network is called the Future 1413 Communications Infrastructure (FCI). FCI shall support quality of 1414 service, diversity, and mobility under the umbrella of the "multi- 1415 link concept". This work is conducted by ICAO working group WG-I. 1417 In addition to standardization activities several industrial LDACS 1418 prototypes have been built. One set of LDACS prototypes has been 1419 evaluated in flight trials confirming the theoretical results 1420 predicting the system performance [GRA18][SCH19]. 1422 7.2. General Characteristics 1424 LDACS will become one of several wireless access networks connecting 1425 aircraft to the Aeronautical Telecommunications Network (ATN). The 1426 LDACS access network contains several ground stations, each of them 1427 providing one LDACS radio cell. The LDACS air interface is a 1428 cellular data link with a star-topology connecting aircraft to 1429 ground-stations with a full duplex radio link. Each ground-station 1430 is the centralized instance controlling all air-ground communications 1431 within its radio cell. A ground-station supports up to 512 aircraft. 1433 The LDACS air interface protocol stack defines two layers, the 1434 physical layer and the data link layer. 1436 The physical layer provides the means to transfer data over the radio 1437 channel. The LDACS ground-station supports bi-directional links to 1438 multiple aircraft under its control. The forward link direction (FL; 1439 ground-to-air) and the reverse link direction (RL; air-to-ground) are 1440 separated by frequency division duplex. Forward link and reverse 1441 link use a 500 kHz channel each. The ground-station transmits a 1442 continuous stream of OFDM symbols on the forward link. In the 1443 reverse link different aircraft are separated in time and frequency 1444 using a combination of Orthogonal Frequency-Division Multiple-Access 1445 (OFDMA) and Time-Division Multiple-Access (TDMA). Aircraft thus 1446 transmit discontinuously on the reverse link with radio bursts sent 1447 in precisely defined transmission opportunities allocated by the 1448 ground-station. LDACS does not support beam-forming or Multiple 1449 Input Multiple Output (MIMO). 1451 The data-link layer provides the necessary protocols to facilitate 1452 concurrent and reliable data transfer for multiple users. The LDACS 1453 data link layer is organized in two sub-layers: The medium access 1454 sub-layer and the logical link control sub-layer. The medium access 1455 sub-layer manages the organization of transmission opportunities in 1456 slots of time and frequency. The logical link control sub-layer 1457 provides acknowledged point-to-point logical channels between the 1458 aircraft and the ground-station using an automatic repeat request 1459 protocol. LDACS supports also unacknowledged point-to-point channels 1460 and ground-to-air broadcast. 1462 The user data rate of LDACS is 315 kbit/s to 1428 kbit/s on the 1463 forward link, and 294 kbit/s to 1390 kbit/s on the reverse link, 1464 depending on coding and modulation. Due to strong interference from 1465 legacy systems in the L-band, the most robust coding and modulation 1466 should be expected for initial deployment i.e. 315/294 kbit/s on the 1467 forward/reverse link, respectively. 1469 Since LDACS has been mainly designed for air traffic management 1470 communication it supports mutual entity authentication, integrity and 1471 confidentiality capabilities of user data messages and some control 1472 channel protection capabilities [MAE19]. 1474 7.3. Applicability to Deterministic Flows 1476 LDACS has been designed with applications related to the safety and 1477 regularity of the flight in mind. It has therefore been designed as 1478 a deterministic wireless data link (as far as possible). 1480 LDACS medium access is always under the control of the ground-station 1481 of a radio cell. Any medium access for the transmission of user data 1482 has to be requested with a resource request message stating the 1483 requested amount of resources and class of service. The ground- 1484 station performs resource scheduling on the basis of these requests 1485 and grants resources with resource allocation messages. Resource 1486 request and allocation messages are exchanged over dedicated 1487 contention-free control channels. 1489 LDACS has two mechanisms to request resources from the scheduler in 1490 the ground-station. Resources can either be requested "on demand" 1491 with a given class of service. On the forward link, this is done 1492 locally in the ground-station, on the reverse link a dedicated 1493 contention-free control channel is used (Dedicated Control Channel 1494 (DCCH); roughly 83 bit every 60 ms). A resource allocation is always 1495 announced in the control channel of the forward link (Common Control 1496 Channel (CCCH); variable sized). Due to the spacing of the reverse 1497 link control channels of every 60 ms, a medium access delay in the 1498 same order of magnitude is to be expected. 1500 Resources can also be requested "permanently". The permanent 1501 resource request mechanism supports requesting recurring resources in 1502 given time intervals. A permanent resource request has to be 1503 canceled by the user (or by the ground-station, which is always in 1504 control). User data transmissions over LDACS are therefore always 1505 scheduled by the ground-station, while control data uses statically 1506 (i.e. at net entry) allocated recurring resources (DCCH and CCCH). 1507 The current specification documents specify no scheduling algorithm. 1508 However performance evaluations so far have used strict priority 1509 scheduling and round robin for equal priorities for simplicity. In 1510 the current prototype implementations LDACS classes of service are 1511 thus realized as priorities of medium access and not as flows. Note 1512 that this can starve out low priority flows. However, this is not 1513 seen as a big problem since safety related message always go first in 1514 any case. Scheduling of reverse link resources is done in physical 1515 Protocol Data Units (PDU) of 112 bit (or larger if more aggressive 1516 coding and modulation is used). Scheduling on the forward link is 1517 done Byte-wise since the forward link is transmitted continuously by 1518 the ground-station. 1520 In order to support diversity, LDACS supports handovers to other 1521 ground-stations on different channels. Handovers may be initiated by 1522 the aircraft (break-before-make) or by the ground-station (make- 1523 before-break) if it is connected to an alternative ground-station via 1524 the same ground-station controller. Beyond this, FCI diversity shall 1525 be implemented by the multi-link concept. 1527 8. IANA Considerations 1529 This specification does not require IANA action. 1531 9. Security Considerations 1533 Most RAW technologies integrate some authentication or encryption 1534 mechanisms that were defined outside the IETF. 1536 10. Contributors 1538 Georgios Z. Papadopoulos: Contributed to the TSCH section. 1540 Nils Mäurer: Contributed to the LDACS section. 1542 Thomas Gräupl: Contributed to the LDACS section. 1544 11. Acknowledgments 1546 Many thanks to the participants of the RAW WG where a lot of the work 1547 discussed here happened. 1549 12. Normative References 1551 [RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH 1552 Operation Sublayer (6top) Protocol (6P)", RFC 8480, 1553 DOI 10.17487/RFC8480, November 2018, 1554 . 1556 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1557 (IPv6) Specification", STD 86, RFC 8200, 1558 DOI 10.17487/RFC8200, July 2017, 1559 . 1561 [RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T. 1562 Phinney, "Industrial Routing Requirements in Low-Power and 1563 Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October 1564 2009, . 1566 [I-D.ietf-detnet-architecture] 1567 Finn, N., Thubert, P., Varga, B., and J. Farkas, 1568 "Deterministic Networking Architecture", Work in Progress, 1569 Internet-Draft, draft-ietf-detnet-architecture-13, 6 May 1570 2019, . 1573 [I-D.ietf-6tisch-architecture] 1574 Thubert, P., "An Architecture for IPv6 over the TSCH mode 1575 of IEEE 802.15.4", Work in Progress, Internet-Draft, 1576 draft-ietf-6tisch-architecture-28, 29 October 2019, 1577 . 1580 13. Informative References 1582 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1583 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1584 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1585 Low-Power and Lossy Networks", RFC 6550, 1586 DOI 10.17487/RFC6550, March 2012, 1587 . 1589 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 1590 and D. Barthel, "Routing Metrics Used for Path Calculation 1591 in Low-Power and Lossy Networks", RFC 6551, 1592 DOI 10.17487/RFC6551, March 2012, 1593 . 1595 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 1596 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 1597 Acronym in the IETF", BCP 161, RFC 6291, 1598 DOI 10.17487/RFC6291, June 2011, 1599 . 1601 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 1602 Weingarten, "An Overview of Operations, Administration, 1603 and Maintenance (OAM) Tools", RFC 7276, 1604 DOI 10.17487/RFC7276, June 2014, 1605 . 1607 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1608 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 1609 Explicit Replication (BIER)", RFC 8279, 1610 DOI 10.17487/RFC8279, November 2017, 1611 . 1613 [I-D.ietf-6tisch-msf] 1614 Chang, T., Vucinic, M., Vilajosana, X., Duquennoy, S., and 1615 D. Dujovne, "6TiSCH Minimal Scheduling Function (MSF)", 1616 Work in Progress, Internet-Draft, draft-ietf-6tisch-msf- 1617 10, 13 December 2019, 1618 . 1620 [I-D.ietf-roll-nsa-extension] 1621 Koutsiamanis, R., Papadopoulos, G., Montavont, N., and P. 1622 Thubert, "Common Ancestor Objective Functions and Parent 1623 Set DAG Metric Container Extension", Work in Progress, 1624 Internet-Draft, draft-ietf-roll-nsa-extension-05, 4 1625 November 2019, . 1628 [I-D.papadopoulos-paw-pre-reqs] 1629 Papadopoulos, G., Koutsiamanis, R., Montavont, N., and P. 1630 Thubert, "Exploiting Packet Replication and Elimination in 1631 Complex Tracks in LLNs", Work in Progress, Internet-Draft, 1632 draft-papadopoulos-paw-pre-reqs-01, 25 March 2019, 1633 . 1636 [I-D.thubert-bier-replication-elimination] 1637 Thubert, P., Eckert, T., Brodard, Z., and H. Jiang, "BIER- 1638 TE extensions for Packet Replication and Elimination 1639 Function (PREF) and OAM", Work in Progress, Internet- 1640 Draft, draft-thubert-bier-replication-elimination-03, 3 1641 March 2018, . 1644 [I-D.thubert-6lo-bier-dispatch] 1645 Thubert, P., Brodard, Z., Jiang, H., and G. Texier, "A 1646 6loRH for BitStrings", Work in Progress, Internet-Draft, 1647 draft-thubert-6lo-bier-dispatch-06, 28 January 2019, 1648 . 1651 [I-D.ietf-bier-te-arch] 1652 Eckert, T., Cauchie, G., and M. Menth, "Traffic 1653 Engineering for Bit Index Explicit Replication (BIER-TE)", 1654 Work in Progress, Internet-Draft, draft-ietf-bier-te-arch- 1655 05, 1 November 2019, 1656 . 1658 [I-D.ietf-6tisch-coap] 1659 Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and 1660 Interaction using CoAP", Work in Progress, Internet-Draft, 1661 draft-ietf-6tisch-coap-03, 9 March 2015, 1662 . 1664 [I-D.svshah-tsvwg-deterministic-forwarding] 1665 Shah, S. and P. Thubert, "Deterministic Forwarding PHB", 1666 Work in Progress, Internet-Draft, draft-svshah-tsvwg- 1667 deterministic-forwarding-04, 30 August 2015, 1668 . 1671 [IEEE802154] 1672 IEEE standard for Information Technology, "IEEE Std. 1673 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 1674 and Physical Layer (PHY) Specifications for Low-Rate 1675 Wireless Personal Area Networks". 1677 [IEEE80211] 1678 "IEEE Standard 802.11 - IEEE Standard for Information 1679 Technology - Telecommunications and information exchange 1680 between systems Local and metropolitan area networks - 1681 Specific requirements - Part 11: Wireless LAN Medium 1682 Access Control (MAC) and Physical Layer (PHY) 1683 Specifications.". 1685 [IEEE80211ak] 1686 "802.11ak: Enhancements for Transit Links Within Bridged 1687 Networks", 2017. 1689 [IEEE80211ax] 1690 "802.11ax D4.0: Enhancements for High Efficiency WLAN". 1692 [IEEE80211ay] 1693 "802.11ay: Enhanced throughput for operation in license- 1694 exempt bands above 45 GHz". 1696 [IEEE80211ad] 1697 "802.11ad: Enhancements for very high throughput in the 60 1698 GHz band". 1700 [IEEE80211be] 1701 "802.11be: Extreme High Throughput". 1703 [IEEE8021Qat] 1704 "802.1Qat: Stream Reservation Protocol". 1706 [IEEE8021Qcc] 1707 "802.1Qcc: IEEE Standard for Local and Metropolitan Area 1708 Networks--Bridges and Bridged Networks -- Amendment 31: 1709 Stream Reservation Protocol (SRP) Enhancements and 1710 Performance Improvements". 1712 [Cavalcanti_2019] 1713 Dave Cavalcanti et al., "Extending Time Distribution and 1714 Timeliness Capabilities over the Air to Enable Future 1715 Wireless Industrial Automation Systems, the Proceedings of 1716 IEEE", June 2019. 1718 [Nitsche_2015] 1719 Thomas Nitsche et al., "IEEE 802.11ad: directional 60 GHz 1720 communication for multi-Gigabit-per-second Wi-Fi", 1721 December 2014. 1723 [Ghasempour_2017] 1724 Yasaman Ghasempour et al., "802.11ay: Next-Generation 60 1725 GHz Communications for 100 Gb/s Wi-Fi", December 2017. 1727 [IEEE_doc_11-18-2009-06] 1728 "802.11 Real-Time Applications (RTA) Topic Interest Group 1729 (TIG) Report", November 2018. 1731 [IEEE_doc_11-19-0373-00] 1732 Kevin Stanton et Al., "Time-Sensitive Applications Support 1733 in EHT", March 2019. 1735 [morell13] Antoni Morell et al., "Label switching over IEEE802.15.4e 1736 networks", April 2013. 1738 [dearmas16] 1739 Jesica de Armas et al., "Determinism through path 1740 diversity: Why packet replication makes sense", September 1741 2016. 1743 [vilajosana19] 1744 Xavier Vilajosana et al., "6TiSCH: Industrial Performance 1745 for IPv6 Internet-of-Things Networks", June 2019. 1747 [ISA100.11a] 1748 ISA/IEC, "ISA100.11a, Wireless Systems for Automation, 1749 also IEC 62734", 2011, . 1753 [WirelessHART] 1754 www.hartcomm.org, "Industrial Communication Networks - 1755 Wireless Communication Network and Communication Profiles 1756 - WirelessHART - IEC 62591", 2010. 1758 [PCE] IETF, "Path Computation Element", 1759 . 1761 [CCAMP] IETF, "Common Control and Measurement Plane", 1762 . 1764 [TiSCH] IETF, "IPv6 over the TSCH mode over 802.15.4", 1765 . 1767 [RIH18] Rihacek, C., Haindl, B., Fantappie, P., Pierattelli, S., 1768 Gräupl, T., Schnell, M., and N. Fistas, "L-band Digital 1769 Aeronautical Communications System (LDACS) Activities in 1770 SESAR2020", Proceedings of the Integrated Communications 1771 Navigation and Surveillance Conference (ICNS) Herndon, VA, 1772 USA, April 2018. 1774 [GRA19] Gräupl, T., Rihacek, C., and B. Haindl, "LDACS A/G 1775 Specification", SESAR2020 PJ14-02-01 D3.3.010, February 1776 2019. 1778 [SAJ14] Sajatovic, M., Günzel, H., and S. Müller, "WA04 D22 Test 1779 Report for Assessing LDACS1 Transmitter Impact upon DME/ 1780 TACAN Receivers", April 2014. 1782 [GRA11] Gräupl, T. and M. Ehammer, "L-DACS1 Data Link Layer 1783 Evolution of ATN/IPS", Proceedings of the 30th IEEE/AIAA 1784 Digital Avionics Systems Conference (DASC) Seattle, WA, 1785 USA, October 2011. 1787 [ICAO18] International Civil Aviation Organization (ICAO), "L-Band 1788 Digital Aeronautical Communication System (LDACS)", 1789 International Standards and Recommended Practices Annex 10 1790 - Aeronautical Telecommunications, Vol. III - 1791 Communication Systems, July 2018. 1793 [GRA18] al., T. G. E., "L-band Digital Aeronautical Communications 1794 System (LDACS) flight trials in the national German 1795 project MICONAV", Proceedings of the Integrated 1796 Communications, Navigation, Surveillance Conference 1797 (ICNS) Herndon, VA, USA, April 2018. 1799 [SCH19] Schnell, M., "DLR tests digital communications 1800 technologies combined with additional navigation functions 1801 for the first time", 3 March 2019, 1802 . 1805 [MAE19] Mäurer, N. and C. Schmitt, "DLR tests digital 1806 communications technologies combined with additional 1807 navigation functions for the first time", Proceedings of 1808 the Integrated Communications, Navigation, Surveillance 1809 Conference (ICNS) Washington D.C., USA, April 2019. 1811 Authors' Addresses 1813 Pascal Thubert (editor) 1814 Cisco Systems, Inc 1815 Building D 1816 45 Allee des Ormes - BP1200 1817 06254 MOUGINS - Sophia Antipolis 1818 France 1820 Phone: +33 497 23 26 34 1821 Email: pthubert@cisco.com 1823 Dave Cavalcanti 1824 Intel Corporation 1825 2111 NE 25th Ave 1826 Hillsboro, OR, 97124 1827 United States of America 1829 Phone: 503 712 5566 1830 Email: dave.cavalcanti@intel.com 1831 Xavier Vilajosana 1832 Universitat Oberta de Catalunya 1833 156 Rambla Poblenou 1834 08018 Barcelona Catalonia 1835 Spain 1837 Email: xvilajosana@uoc.edu 1839 Corinna Schmitt 1840 Research Institute CODE, UniBwM 1841 Werner-Heisenberg-Weg 28 1842 85577 Neubiberg 1843 Germany 1845 Email: corinna.schmitt@unibw.de