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