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