idnits 2.17.1 draft-thubert-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 5 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 820: '... the 6TiSCH LLN MUST be swapped into ...' RFC 2119 keyword, line 879: '...he configuration MUST enable correlate...' RFC 2119 keyword, line 881: '...n a'AND'relation MUST be configurable ...' RFC 2119 keyword, line 891: '... transmissions SHOULD NOT be attempt...' RFC 2119 keyword, line 896: '... any of branches MUST be attempted reg...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (18 May 2020) is 1439 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-28 == Outdated reference: A later version (-18) exists of draft-ietf-6tisch-msf-16 == Outdated reference: A later version (-09) exists of draft-pthubert-raw-architecture-01 == Outdated reference: A later version (-12) exists of draft-ietf-roll-nsa-extension-08 == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-07 == Outdated reference: A later version (-07) exists of draft-ietf-detnet-ip-over-tsn-02 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RAW P. Thubert, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Informational D. Cavalcanti 5 Expires: 19 November 2020 Intel 6 X. Vilajosana 7 Universitat Oberta de Catalunya 8 C. Schmitt 9 Research Institute CODE, UniBwM 10 J. Farkas 11 Ericsson 12 18 May 2020 14 Reliable and Available Wireless Technologies 15 draft-thubert-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 availbility. 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 19 November 2020. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. On Scheduling . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Benefits of Scheduling on Wires . . . . . . . . . . . . . 4 61 3.2. Benefits of Scheduling on Wireless . . . . . . . . . . . 5 62 4. IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.1. Provenance and Documents . . . . . . . . . . . . . . . . 6 64 4.2. 802.11ax High Efficiency (HE) . . . . . . . . . . . . . . 8 65 4.2.1. General Characteristics . . . . . . . . . . . . . . . 8 66 4.2.2. Applicability to deterministic flows . . . . . . . . 9 67 4.3. 802.11be Extreme High Throughput (EHT) . . . . . . . . . 10 68 4.3.1. General Characteristics . . . . . . . . . . . . . . . 10 69 4.3.2. Applicability to deterministic flows . . . . . . . . 11 70 4.4. 802.11ad and 802.11ay (mmWave operation) . . . . . . . . 12 71 4.4.1. General Characteristics . . . . . . . . . . . . . . . 12 72 4.4.2. Applicability to deterministic flows . . . . . . . . 13 73 5. IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . 13 74 5.1. Provenance and Documents . . . . . . . . . . . . . . . . 13 75 5.2. TimeSlotted Channel Hopping . . . . . . . . . . . . . . . 15 76 5.2.1. General Characteristics . . . . . . . . . . . . . . . 15 77 5.2.2. Applicability to Deterministic Flows . . . . . . . . 16 78 6. 5G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 79 6.1. Provenance and Documents . . . . . . . . . . . . . . . . 30 80 6.2. General Characteristics . . . . . . . . . . . . . . . . . 32 81 6.3. Deployment and Spectrum . . . . . . . . . . . . . . . . . 33 82 6.4. Applicability to Deterministic Flows . . . . . . . . . . 34 83 6.4.1. System Architecture . . . . . . . . . . . . . . . . . 34 84 6.4.2. Overview of The Radio Protocol Stack . . . . . . . . 36 85 6.4.3. Radio (PHY) . . . . . . . . . . . . . . . . . . . . . 37 86 6.4.4. Scheduling and QoS (MAC) . . . . . . . . . . . . . . 39 87 6.4.5. Time-Sensitive Networking (TSN) Integration . . . . . 41 88 6.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 44 89 7. L-band Digital Aeronautical Communications System . . . . . . 45 90 7.1. Provenance and Documents . . . . . . . . . . . . . . . . 45 91 7.2. General Characteristics . . . . . . . . . . . . . . . . . 46 92 7.3. Applicability to Deterministic Flows . . . . . . . . . . 47 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 94 9. Security Considerations . . . . . . . . . . . . . . . . . . . 48 95 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 48 96 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49 97 12. Normative References . . . . . . . . . . . . . . . . . . . . 49 98 13. Informative References . . . . . . . . . . . . . . . . . . . 49 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 101 1. Introduction 103 When used in math or philosophy, the term "deterministic" generally 104 refers to a perfection where all aspect are understood and 105 predictable. A perfectly Deterministic Network would ensure that 106 every packet reach its destination following a predetermined path 107 along a predefined schedule to be delivered at the exact due time. 108 In a real and imperfect world, a Deterministic Network must highly 109 predictable, which is a combination of reliability and availability. 110 On the one hand the network must be reliable, meaning that it will 111 perform as expected for all packets and in particular that it will 112 always deliver the packet at the destination in due time. On the 113 other hand, the network must be available, meaning that it is 114 resilient to any single outage, whether the cause is a software, a 115 hardware or a transmission issue. 117 RAW (Reliable and Available Wireless) is an effort to provide 118 Deterministic Networking on across a path that include a wireless 119 physical layer. Making Wireless Reliable and Available is even more 120 challenging than it is with wires, due to the numerous causes of loss 121 in transmission that add up to the congestion losses and the delays 122 caused by overbooked shared resources. In order to maintain a 123 similar quality of service along a multihop path that is composed of 124 wired and wireless hops, additional methods that are specific to 125 wireless must be leveraged to combat the sources of loss that are 126 also specific to wireless. 128 Such wireless-specific methods include per-hop retransmissions (HARQ) 129 and P2MP overhearing whereby multiple receivers are scheduled to 130 receive the same transmission, which balances the adverse effects of 131 the transmission losses that are experienced when a radio is used as 132 pure P2P. Those methods are collectively referred to as PAREO 133 functions in the "Reliable and Available Wireless Architecture/ 134 Framework" [I-D.pthubert-raw-architecture]. 136 2. Terminology 138 This specification uses several terms that are uncommon on protocols 139 that ensure bets effort transmissions for stochastics flows, such as 140 found in the traditional Internet and other statistically multiplexed 141 packet networks. 143 ARQ: Automatic Repeat Request, enabling an acknowledged transmission 144 and retries. ARQ is a typical model at Layer-2 on a wireless 145 medium. It is typically avoided end-to-end on deterministic flows 146 because it introduces excessive indetermination in latency, but a 147 limited number of retries within a bounded time may be used over a 148 wireless link and yet respect end-to-end constraints. 150 Available: That is exempt of unscheduled outage, the expectation for 151 a network being that the flow is maintained in the face of any 152 single breakage. 154 FEC: Forward error correction, sending redundant coded data to help 155 the receiver recover transmission errors without the delays 156 incurred with ARQ. 158 HARQ: Hybrid ARQ, a combination of FEC and ARQ. 160 PCE: Path Computation Element. 162 PAREO (functions): the wireless extension of DetNet PREOF. PAREO 163 functions include scheduled ARQ at selected hops, and expect the 164 use of new operations like overhearing where available. 166 Reliable: That consistently performs as expected, the expectation 167 for a network being to always deliver a packet in due time. 169 Track: A DODAG oriented to a destination, and that enables Packet 170 ARQ, Replication, Elimination, and Ordering Functions. 172 3. On Scheduling 174 The operations of a Deterministic Network often rely on precisely 175 applying a tight schedule, in order to avoid collision loss and 176 guarantee the worst-case time of delivery. To achieve this, there 177 must be a shared sense of time throughout the network. The sense of 178 time is usually provided by the lower layer and is not in scope for 179 RAW. 181 3.1. Benefits of Scheduling on Wires 183 A network is reliable when the statistical effects that affect the 184 packet transmission are eliminated. This involves maintaining at all 185 time the amount of critical packets within the physical capabilities 186 of the hardware and that of the radio medium. This is achieved by 187 controlling the use of time-shared resources such as CPUs and 188 buffers, by shaping the flows and by scheduling the time of 189 transmission of the packets that compose the flow at every hop. 191 Equipment failure, such as an access point rebooting, a broken radio 192 adapter, or a permanent obstacle to the transmission, is a secondary 193 source of packet loss. When a breakage occurs, multiple packets are 194 lost in a row before the flows are rerouted or the system may 195 recover. This is not acceptable for critical applications such as 196 related to safety. A typical process control loop will tolerate an 197 occasional packet loss, but a loss of several packets in a row will 198 cause an emergency stop (e.g., after 4 packets lost, within a period 199 of 1 second). 201 Network Availability is obtained by making the transmission resilient 202 against hardware failures and radio transmission losses due to 203 uncontrolled events such as co-channel interferers, multipath fading 204 or moving obstacles. The best results are typically achieved by 205 pseudo randomly cumulating all forms of diversity, in the spatial 206 domain with replication and elimination, in the time domain with ARQ 207 and diverse scheduled transmissions, and in the frequency domain with 208 frequency hopping or channel hopping between frames. 210 3.2. Benefits of Scheduling on Wireless 212 In addition to the benefits listed in Section 3.1, scheduling 213 transmissions provides specific value to the wireless medium. 215 On the one hand, scheduling avoids collisions between scheduled 216 transmissions and can ensure both time and frequency diversity 217 between retries in order to defeat co-channel interference from un- 218 controlled transmitters as well as multipath fading. Transmissions 219 can be scheduled on multiple channels in parallel, which enables to 220 use the full available spectrum while avoiding the hidden terminal 221 problem, e.g., when the next packet in a same flow interferes on a 222 same channel with the previous one that progressed a few hops 223 farther. 225 On the other hand, scheduling optimizes the bandwidth usage: compared 226 to classical Collision Avoidance techniques, there is no blank time 227 related to inter-frame space (IFS) and exponential back-off in 228 scheduled operations. A minimal Clear Channel Assessment may be 229 needed to comply with the local regulations such as ETSI 300-328, but 230 that will not detect a collision when the senders are synchronized. 231 And because scheduling allows a time-sharing operation, there is no 232 limit to the ratio of isolated critical traffic. 234 Finally, scheduling plays a critical role to save energy. In IOT, 235 energy is the foremost concern, and synchronizing sender and listener 236 enables to always maintain them in deep sleep when there is no 237 scheduled transmission. This avoids idle listening and long 238 preambles and enables long sleep periods between traffic and 239 resynchronization, allowing battery-operated nodes to operate in a 240 mesh topology for multiple years. 242 4. IEEE 802.11 244 4.1. Provenance and Documents 246 With an active portfolio of nearly 1,300 standards and projects under 247 development, IEEE is a leading developer of industry standards in a 248 broad range of technologies that drive the functionality, 249 capabilities, and interoperability of products and services, 250 transforming how people live, work, and communicate. 252 The IEEE 802 LAN/MAN Standards Committee (SC) develops and maintains 253 networking standards and recommended practices for local, 254 metropolitan, and other area networks, using an open and accredited 255 process, and advocates them on a global basis. The most widely used 256 standards are for Ethernet, Bridging and Virtual Bridged LANs 257 Wireless LAN, Wireless PAN, Wireless MAN, Wireless Coexistence, Media 258 Independent Handover Services, and Wireless RAN. An individual 259 Working Group provides the focus for each area. Standards produced 260 by the IEEE 802 SC are freely available from the IEEE GET Program 261 after they have been published in PDF for six months. 263 The IEEE 802.11 LAN standards define the underlying MAC and PHY 264 layers for the Wi-Fi technology. Wi-Fi/802.11 is one of the most 265 successful wireless technologies, supporting many application 266 domains. While previous 802.11 generations, such as 802.11n and 267 802.11ac, have focused mainly on improving peak throughput, more 268 recent generations are also considering other performance vectors, 269 such as efficiency enhancements for dense environments in 802.11ax, 270 and latency and support for Time-Sensitive Networking (TSN) 271 capabilities in 802.11be. 273 IEEE 802.11 already supports some 802.1 TSN standards and it is 274 undergoing efforts to support for other 802.1 TSN capabilities 275 required to address the use cases that require time synchronization 276 and timeliness (bounded latency) guarantees with high reliability and 277 availability. The IEEE 802.11 working group has been working in 278 collaboration with the IEEE 802.1 group for several years extending 279 802.1 features over 802.11. As with any wireless media, 802.11 280 imposes new constraints and restrictions to TSN-grade QoS, and 281 tradeoffs between latency and reliability guarantees must be 282 considered as well as managed deployment requirements. An overview 283 of 802.1 TSN capabilities and their extensions to 802.11 are 284 discussed in [Cavalcanti_2019]. 286 Wi-Fi Alliance (WFA) is the worldwide network of companies that 287 drives global Wi-Fi adoption and evolution through thought 288 leadership, spectrum advocacy, and industry-wide collaboration. The 289 WFA work helps ensure that Wi-Fi devices and networks provide users 290 the interoperability, security, and reliability they have come to 291 expect. 293 The following [IEEE Std. 802.11] specifications/certifications are 294 relevant in the context of reliable and available wireless services 295 and support for time-sensitive networking capabilities: 297 Time Synchronization: IEEE802.11-2016 with IEEE802.1AS; WFA TimeSync 298 Certification. 300 Congestion Control: IEEE802.11-2016 Admission Control; WFA Admission 301 Control. 303 Security: WFA Wi-Fi Protected Access, WPA2 and WPA3. 305 Interoperating with IEEE802.1Q bridges: [IEEE Std. 802.11ak]. 307 Stream Reservation Protocol (part of [IEEE Std. 802.1Qat]): 308 AIEEE802.11-2016 310 Scheduled channel access: IEEE802.11ad Enhancements for very high 311 throughput in the 60 GHz band [IEEE Std. 802.11ad]. 313 802.11 Real-Time Applications: Topic Interest Group (TIG) ReportDoc 314 [IEEE_doc_11-18-2009-06]. 316 In addition, major amendments being developed by the IEEE802.11 317 Working Group include capabilities that can be used as the basis for 318 providing more reliable and predictable wireless connectivity and 319 support time-sensitive applications: 321 IEEE 802.11ax D4.0: Enhancements for High Efficiency (HE). [IEEE 322 Std. 802.11ax] 324 IEEE 802.11be Extreme High Throughput (EHT). [IEEE 802.11be WIP] 326 IEE 802.11ay Enhanced throughput for operation in license-exempt 327 bands above 45 GHz. [IEEE 328 Std. 802.11ay] 330 The main 802.11ax and 802.11be capabilities and their relevance to 331 RAW are discussed in the remainder of this document. 333 4.2. 802.11ax High Efficiency (HE) 335 4.2.1. General Characteristics 337 The next generation Wi-Fi (Wi-Fi 6) is based on the IEEE802.11ax 338 amendment [IEEE Std. 802.11ax], which includes new capabilities to 339 increase efficiency, control and reduce latency. Some of the new 340 features include higher order 1024-QAM modulation, support for uplink 341 multi-user MIMO, OFDMA, trigger-based access and Target Wake time 342 (TWT) for enhanced power savings. The OFDMA mode and trigger-based 343 access enable scheduled operation, which is a key capability required 344 to support deterministic latency and reliability for time-sensitive 345 flows. 802.11ax can operate in up to 160 MHz channels and it includes 346 support for operation in the new 6 GHz band, which is expected to be 347 open to unlicensed use by the FCC and other regulatory agencies 348 worldwide. 350 4.2.1.1. Multi-User OFDMA and Trigger-based Scheduled Access 352 802.11ax introduced a new orthogonal frequency-division multiple 353 access (OFDMA) mode in which multiple users can be scheduled across 354 the frequency domain. In this mode, the Access Point (AP) can 355 initiate multi-user (MU) Uplink (UL) transmissions in the same PHY 356 Protocol Data Unit (PPDU) by sending a trigger frame. This 357 centralized scheduling capability gives the AP much more control of 358 the channel, and it can remove contention between devices for uplink 359 transmissions, therefore reducing the randomness caused by CSMA-based 360 access between stations. The AP can also transmit simultaneously to 361 multiple users in the downlink direction by using a Downlink (DL) MU 362 OFDMA PPDU. In order to initiate a contention free Transmission 363 Opportunity (TXOP) using the OFDMA mode, the AP still follows the 364 typical listen before talk procedure to acquire the medium, which 365 ensures interoperability and compliance with unlicensed band access 366 rules. However, 802.11ax also includes a multi-user Enhanced 367 Distributed Channel Access (MU-EDCA) capability, which allows the AP 368 to get higher channel access priority. 370 4.2.1.2. Improved PHY Robustness 372 The 802.11ax PHY can operate with 0.8, 1.6 or 3.2 microsecond guard 373 interval (GI). The larger GI options provide better protection 374 against multipath, which is expected to be a challenge in industrial 375 environments. The possibility to operate with smaller resource units 376 (e.g. 2 MHz) enabled by OFDMA also helps reduce noise power and 377 improve SNR, leading to better packet error rate (PER) performance. 379 802.11ax supports beamforming as in 802.11ac, but introduces UL MU 380 MIMO, which helps improve reliability. The UL MU MIMO capability is 381 also enabled by the trigger based access operation in 802.11ax. 383 4.2.1.3. Support for 6GHz band 385 The 802.11ax specification [IEEE Std. 802.11ax] includes support for 386 operation in the new 6 GHz band. Given the amount of new spectrum 387 available as well as the fact that no legacy 802.11 device (prior 388 802.11ax) will be able to operate in this new band, 802.11ax 389 operation in this new band can be even more efficient. 391 4.2.2. Applicability to deterministic flows 393 TSN capabilities, as defined by the IEEE 802.1 TSN standards, provide 394 the underlying mechanism for supporting deterministic flows in a 395 Local Area Network (LAN). The 802.11 working group has already 396 incorporated support for several TSN capabilities, so that time- 397 sensitive flow can experience precise time synchronization and 398 timeliness when operating over 802.11 links. TSN capabilities 399 supported over 802.11 (which also extends to 802.11ax), include: 401 1. 802.1AS based Time Synchronization (other time synchronization 402 techniques may also be used) 404 2. Interoperating with IEEE802.1Q bridges 406 3. Time-sensitive Traffic Stream identification 408 The exiting 802.11 TSN capabilities listed above, and the 802.11ax 409 OFDMA and scheduled access provide a new set of tools to better 410 server time-sensitive flows. However, it is important to understand 411 the tradeoffs and constraints associated with such capabilities, as 412 well as redundancy and diversity mechanisms that can be used to 413 provide more predictable and reliable performance. 415 4.2.2.1. 802.11 Managed network operation and admission control 417 Time-sensitive applications and TSN standards are expected to operate 418 under a managed network (e.g. industrial/enterprise network). Thus, 419 the Wi-Fi operation must also be carefully managed and integrated 420 with the overall TSN management framework, as defined in the 421 [IEEE8021Qcc] specification. 423 Some of the random-access latency and interference from legacy/ 424 unmanaged devices can be minimized under a centralized management 425 mode as defined in [IEEE8021Qcc], in which admission control 426 procedures are enforced. 428 Existing traffic stream identification, configuration and admission 429 control procedures defined in [IEEE Std. 802.11] QoS mechanism can be 430 re-used. However, given the high degree of determinism required by 431 many time-sensitive applications, additional capabilities to manage 432 interference and legacy devices within tight time-constraints need to 433 be explored. 435 4.2.2.2. Scheduling for bounded latency and diversity 437 As discussed earlier, the [IEEE Std. 802.11ax] OFDMA mode introduces 438 the possibility of assigning different RUs (frequency resources) to 439 users within a PPDU. Several RU sizes are defined in the 440 specification (26, 52, 106, 242, 484, 996 subcarriers). In addition, 441 the AP can also decide on MCS and grouping of users within a given 442 OFMDA PPDU. Such flexibility can be leveraged to support time- 443 sensitive applications with bounded latency, especially in a managed 444 network where stations can be configured to operate under the control 445 of the AP. 447 As shown in [Cavalcanti_2019], it is possible to achieve latencies in 448 the order of 1msec with high reliability in an interference free 449 environment. Obviously, there are latency, reliability and capacity 450 tradeoffs to be considered. For instance, smaller Resource Units 451 (RU)s result in longer transmission durations, which may impact the 452 minimal latency that can be achieved, but the contention latency and 453 randomness elimination due to multi-user transmission is a major 454 benefit of the OFDMA mode. 456 The flexibility to dynamically assign RUs to each transmission also 457 enables the AP to provide frequency diversity, which can help 458 increase reliability. 460 4.3. 802.11be Extreme High Throughput (EHT) 462 4.3.1. General Characteristics 464 The [IEEE 802.11be WIP]is the next major 802.11 amendment (after 465 [IEEE Std. 802.11ax]) for operation in the 2.4, 5 and 6 GHz bands. 466 802.11be is expected to include new PHY and MAC features and it is 467 targeting extremely high throughput (at least 30 Gbps), as well as 468 enhancements to worst case latency and jitter. It is also expected 469 to improve the integration with 802.1 TSN to support time-sensitive 470 applications over Ethernet and Wireless LANs. 472 The 802.11be Task Group started its operation in May 2019, therefore, 473 detailed information about specific features is not yet available. 474 Only high level candidate features have been discussed so far, 475 including: 477 1. 320MHz bandwidth and more efficient utilization of non-contiguous 478 spectrum. 480 2. Multi-band/multi-channel aggregation and operation. 482 3. 16 spatial streams and related MIMO enhancements. 484 4. Multi-Access Point (AP) Coordination. 486 5. Enhanced link adaptation and retransmission protocol, e.g. 487 Hybrid Automatic Repeat Request (HARQ). 489 6. Any required adaptations to regulatory rules for the 6 GHz 490 spectrum. 492 4.3.2. Applicability to deterministic flows 494 The 802.11 Real-Time Applications (RTA) Topic Interest Group (TIG) 495 provided detailed information on use cases, issues and potential 496 solution directions to improve support for time-sensitive 497 applications in 802.11. The RTA TIG report [IEEE_doc_11-18-2009-06] 498 was used as input to the 802.11be project scope. 500 Improvements for worst-case latency, jitter and reliability were the 501 main topics identified in the RTA report, which were motivated by 502 applications in gaming, industrial automation, robotics, etc. The 503 RTA report also highlighted the need to support additional TSN 504 capabilities, such as time-aware (802.1Qbv) shaping and packet 505 replication and elimination as defined in 802.1CB. 507 802.11be is expected to build on and enhance 802.11ax capabilities to 508 improve worst case latency and jitter. Some of the enhancement areas 509 are discussed next. 511 4.3.2.1. Enhanced scheduled operation for bounded latency 513 In addition to the throughput enhancements, 802.11be will leverage 514 the trigger-based scheduled operation enabled by 802.11ax to provide 515 efficient and more predictable medium access. 802.11be is expected to 516 include enhancements to reduce overhead and enable more efficient 517 operation in managed network deployments [IEEE_doc_11-19-0373-00]. 519 4.3.2.2. Multi-AP coordination 521 Multi-AP coordination is one of the main new candidate features in 522 802.11be. It can provide benefits in throughput and capacity and has 523 the potential to address some of the issues that impact worst case 524 latency and reliability. Multi-AP coordination is expected to 525 address the contention due to overlapping Basic Service Sets (OBSS), 526 which is one of the main sources of random latency variations. 527 802.11be can define methods to enable better coordination between 528 APs, for instance, in a managed network scenario, in order to reduce 529 latency due to unmanaged contention. 531 Several multi-AP coordination approaches have been discussed with 532 different levels of complexities and benefits, but specific 533 coordination methods have not yet been defined. 535 4.3.2.3. Multi-band operation 537 802.11be will introduce new features to improve operation over 538 multiple bands and channels. By leveraging multiple bands/channels, 539 802.11be can isolate time-sensitive traffic from network congestion, 540 one of the main causes of large latency variations. In a managed 541 802.11be network, it should be possible to steer traffic to certain 542 bands/channels to isolate time-sensitive traffic from other traffic 543 and help achieve bounded latency. 545 4.4. 802.11ad and 802.11ay (mmWave operation) 547 4.4.1. General Characteristics 549 The IEEE 802.11ad amendment defines PHY and MAC capabilities to 550 enable multi-Gbps throughput in the 60 GHz millimeter wave (mmWave) 551 band. The standard addresses the adverse mmWave signal propagation 552 characteristics and provides directional communication capabilities 553 that take advantage of beamforming to cope with increased 554 attenuation. An overview of the 802.11ad standard can be found in 555 [Nitsche_2015] . 557 The IEEE 802.11ay is currently developing enhancements to the 558 802.11ad standard to enable the next generation mmWave operation 559 targeting 100 Gbps throughput. Some of the main enhancements in 560 802.11ay include MIMO, channel bonding, improved channel access and 561 beamforming training. An overview of the 802.11ay capabilities can 562 be found in [Ghasempour_2017] 564 4.4.2. Applicability to deterministic flows 566 The high data rates achievable with 802.11ad and 802.11ay can 567 significantly reduce latency down to microsecond levels. Limited 568 interference from legacy and other unlicensed devices in 60 GHz is 569 also a benefit. However, directionality and short range typical in 570 mmWave operation impose new challenges such as the overhead required 571 for beam training and blockage issues, which impact both latency and 572 reliability. Therefore, it is important to understand the use case 573 and deployment conditions in order to properly apply and configure 574 802.11ad/ay networks for time sensitive applications. 576 The 802.11ad standard include a scheduled access mode in which 577 stations can be allocated contention-free service periods by a 578 central controller. This scheduling capability is also available in 579 802.11ay, and it is one of the mechanisms that can be used to provide 580 bounded latency to time-sensitive data flows. An analysis of the 581 theoretical latency bounds that can be achieved with 802.11ad service 582 periods is provided in [Cavalcanti_2019]. 584 5. IEEE 802.15.4 586 5.1. Provenance and Documents 588 The IEEE802.15.4 Task Group has been driving the development of low- 589 power low-cost radio technology. The IEEE802.15.4 physical layer has 590 been designed to support demanding low-power scenarios targeting the 591 use of unlicensed bands, both the 2.4 GHz and sub GHz Industrial, 592 Scientific and Medical (ISM) bands. This has imposed requirements in 593 terms of frame size, data rate and bandwidth to achieve reduced 594 collision probability, reduced packet error rate, and acceptable 595 range with limited transmission power. The PHY layer supports frames 596 of up to 127 bytes. The Medium Access Control (MAC) sublayer 597 overhead is in the order of 10-20 bytes, leaving about 100 bytes to 598 the upper layers. IEEE802.15.4 uses spread spectrum modulation such 599 as the Direct Sequence Spread Spectrum (DSSS). 601 The Timeslotted Channel Hopping (TSCH) mode was added to the 2015 602 revision of the IEEE802.15.4 standard [IEEE Std. 802.15.4]. TSCH is 603 targeted at the embedded and industrial world, where reliability, 604 energy consumption and cost drive the application space. 606 At the IETF, the 6TiSCH Working Group (WG) [TiSCH] deals with best 607 effort operation of IPv6 [RFC8200] over TSCH. 6TiSCH has enabled 608 distributed scheduling to exploit the deterministic access 609 capabilities provided by TSCH. The group designed the essential 610 mechanisms to enable the management plane operation while ensuring 611 IPv6 is supported. Yet the charter did not focus to providing a 612 solution to establish end to end Tracks while meeting quality of 613 service requirements. 6TiSCH, through the RFC8480 [RFC8480] defines 614 the 6P protocol which provides a pairwise negotiation mechanism to 615 the control plane operation. The protocol supports agreement on a 616 schedule between neighbors, enabling distributed scheduling. 6P goes 617 hand-in-hand with a Scheduling Function (SF), the policy that decides 618 how to maintain cells and trigger 6P transactions. The Minimal 619 Scheduling Function (MSF) [I-D.ietf-6tisch-msf] is the default SF 620 defined by the 6TiSCH WG; other standardized SFs can be defined in 621 the future. MSF extends the minimal schedule configuration, and is 622 used to add child-parent links according to the traffic load. 624 Time sensitive networking on low power constrained wireless networks 625 have been partially addressed by ISA100.11a [ISA100.11a] and 626 WirelessHART [WirelessHART]. Both technologies involve a central 627 controller that computes redundant paths for industrial process 628 control traffic over a TSCH mesh. Moreover, ISA100.11a introduces 629 IPv6 capabilities with a Link-Local Address for the join process and 630 a global unicast addres for later exchanges, but the IPv6 traffic 631 typically ends at a local application gateway and the full power of 632 IPv6 for end-to-end communication is not enabled. Compared to that 633 state of the art, work at the IETF and in particular at RAW could 634 provide additional techniques such as optimized P2P routing, PAREO 635 functions, and end-to-end secured IPv6/CoAP connectivity. 637 The 6TiSCH architecture [I-D.ietf-6tisch-architecture] identifies 638 different models to schedule resources along so-called Tracks (see 639 Section 5.2.2.2) exploiting the TSCH schedule structure however the 640 focus at 6TiSCH is on best effort traffic and the group was never 641 chartered to produce standard work related to Tracks. 643 Useful References include: 645 1. IEEE Std 802.15.4: "IEEE Std. 802.15.4, Part. 15.4: Wireless 646 Medium Access Control (MAC) and Physical Layer (PHY) 647 Specifications for Low-Rate Wireless Personal Area Networks" 648 [IEEE Std. 802.15.4]. The latest version at the time of this 649 writing is dated year 2015. 651 2. Morell, A. , Vilajosana, X. , Vicario, J. L. and Watteyne, T. 652 (2013), Label switching over IEEE802.15.4e networks. Trans. 653 Emerging Tel. Tech., 24: 458-475. doi:10.1002/ett.2650" 654 [morell13]. 656 3. De Armas, J., Tuset, P., Chang, T., Adelantado, F., Watteyne, T., 657 Vilajosana, X. (2016, September). Determinism through path 658 diversity: Why packet replication makes sense. In 2016 659 International Conference on Intelligent Networking and 660 Collaborative Systems (INCoS) (pp. 150-154). IEEE. [dearmas16]. 662 4. X. Vilajosana, T. Watteyne, M. Vucinic, T. Chang and K. S. 663 J. Pister, "6TiSCH: Industrial Performance for IPv6 Internet-of- 664 Things Networks," in Proceedings of the IEEE, vol. 107, no. 6, 665 pp. 1153-1165, June 2019. [vilajosana19]. 667 5.2. TimeSlotted Channel Hopping 669 5.2.1. General Characteristics 671 As a core technique in IEEE802.15.4, TSCH splits time in multiple 672 time slots that repeat over time. A set of timeslots constructs a 673 Slotframe (see Section 5.2.2.1.4). For each timeslot, a set of 674 available frequencies can be used, resulting in a matrix-like 675 schedule (see Figure 1). 677 timeslot offset 678 | 0 1 2 3 4 | 0 1 2 3 4 | Nodes 679 +------------------------+------------------------+ +-----+ 680 | | | | | | | | | | | | C | 681 CH-1 | EB | | |C->B| | EB | | |C->B| | | | 682 | | | | | | | | | | | +-----+ 683 +-------------------------------------------------+ | 684 | | | | | | | | | | | | 685 CH-2 | | |B->C| |B->A| | |B->C| |B->A| +-----+ 686 | | | | | | | | | | | | B | 687 +-------------------------------------------------+ | | 688 ... +-----+ 689 | 690 +-------------------------------------------------+ | 691 | | | | | | | | | | | +-----+ 692 CH-15| |A->B| | | | |A->B| | | | | A | 693 | | | | | | | | | | | | | 694 +-------------------------------------------------+ +-----+ 695 ch. 696 offset 698 Figure 1: Slotframe example with scheduled cells between nodes A, 699 B and C 701 This schedule represents the possible communications of a node with 702 its neighbors, and is managed by a Scheduling Function such as the 703 Minimal Scheduling Function (MSF) [I-D.ietf-6tisch-msf]. Each cell 704 in the schedule is identified by its slotoffset and channeloffset 705 coordinates. A cell's timeslot offset indicates its position in 706 time, relative to the beginning of the slotframe. A cell's channel 707 offset is an index which maps to a frequency at each iteration of the 708 slotframe. Each packet exchanged between neighbors happens within 709 one cell. The size of a cell is a timeslot duration, between 10 to 710 15 milliseconds. An Absolute Slot Number (ASN) indicates the number 711 of slots elapsed since the network started. It increments at every 712 slot. This is a 5 byte counter that can support networks running for 713 more than 300 years without wrapping (assuming a 10 ms timeslot). 714 Channel hopping provides increased reliability to multi-path fading 715 and external interference. It is handled by TSCH through a channel 716 hopping sequence referred as macHopSeq in the IEEE802.15.4 717 specification. 719 The Time-Frequency Division Multiple Access provided by TSCH enables 720 the orchestration of traffic flows, spreading them in time and 721 frequency, and hence enabling an efficient management of the 722 bandwidth utilization. Such efficient bandwidth utilization can be 723 combined to OFDM modulations also supported by the IEEE802.15.4 724 standard [IEEE Std. 802.15.4] since the 2015 version. 726 In the RAW context, low power reliable networks should address non- 727 critical control scenarios such as Class 2 and monitoring scenarios 728 such as Class 4 defined by the RFC5673 [RFC5673]. As a low power 729 technology targeting industrial scenarios radio transducers provide 730 low data rates (typically between 50kbps to 250kbps) and robust 731 modulations to trade-off performance to reliability. TSCH networks 732 are organized in mesh topologies and connected to a backbone. 733 Latency in the mesh network is mainly influenced by propagation 734 aspects such as interference. ARQ methods and redundancy techniques 735 such as replication and elimination should be studied to provide the 736 needed performance to address deterministic scenarios. 738 5.2.2. Applicability to Deterministic Flows 740 Nodes in a TSCH network are tightly synchronized. This enables to 741 build the slotted structure and ensure efficient utilization of 742 resources thanks to proper scheduling policies. Scheduling is a key 743 to orchestrate the resources that different nodes in a Track or a 744 path are using. Slotframes can be split in resource blocks reserving 745 the needed capacity to certain flows. Periodic and bursty traffic 746 can be handled independently in the schedule, using active and 747 reactive policies and taking advantage of overprovisionned cells to 748 measu reth excursion. Along a Track, resource blocks can be chained 749 so nodes in previous hops transmit their data before the next packet 750 comes. This provides a tight control to latency along a Track. 751 Collision loss is avoided for best effort traffic by 752 overprovisionning resources, giving time to the management plane of 753 the network to dedicate more resources if needed. 755 5.2.2.1. Centralized Path Computation 757 In a controlled environment, a 6TiSCH device usually does not place a 758 request for bandwidth between itself and another device in the 759 network. Rather, an Operation Control System (OCS) invoked through 760 an Human/Machine Interface (HMI) iprovides the Traffic Specification, 761 in particular in terms of latency and reliability, and the end nodes, 762 to a Path Computation element (PCE). With this, the PCE computes a 763 Track between the end nodes and provisions every hop in the Track 764 with per-flow state that describes the per-hop operation for a given 765 packet, the corresponding timeSlots, and the flow identification to 766 recognize which packet is placed in which Track, sort out duplicates, 767 etc. In Figure 2, an example of Operational Control System and HMI 768 is depicted. 770 For a static configuration that serves a certain purpose for a long 771 period of time, it is expected that a node will be provisioned in one 772 shot with a full schedule, which incorporates the aggregation of its 773 behavior for multiple Tracks. The 6TiSCH Architecture expects that 774 the programing of the schedule is done over CoAP as discussed in 775 "6TiSCH Resource Management and Interaction using CoAP" 776 [I-D.ietf-6tisch-coap]. 778 But an Hybrid mode may be required as well whereby a single Track is 779 added, modified, or removed, for instance if it appears that a Track 780 does not perform as expected for, say, Packet Delivery Ratio (PDR). 781 For that case, the expectation is that a protocol that flows along a 782 Track (to be), in a fashion similar to classical Traffic Engineering 783 (TE) [CCAMP], may be used to update the state in the devices. 6TiSCH 784 provides means for a device to negotiate a timeSlot with a neighbor, 785 but in general that flow was not designed and no protocol was 786 selected and it is expected that DetNet will determine the 787 appropriate end-to-end protocols to be used in that case. 789 Stream Management Entity 790 Operational Control System and HMI 792 -+-+-+-+-+-+-+ Northbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 794 PCE PCE PCE PCE 796 -+-+-+-+-+-+-+ Southbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 798 --- 6TiSCH------6TiSCH------6TiSCH------6TiSCH-- 799 6TiSCH / Device Device Device Device \ 800 Device- - 6TiSCH 801 \ 6TiSCH 6TiSCH 6TiSCH 6TiSCH / Device 802 ----Device------Device------Device------Device-- 804 Figure 2 806 5.2.2.1.1. Packet Marking and Handling 808 Section "Packet Marking and Handling" of 809 [I-D.ietf-6tisch-architecture] describes the packet tagging and 810 marking that is expected in 6TiSCH networks. 812 5.2.2.1.1.1. Tagging Packets for Flow Identification 814 For packets that are routed by a PCE along a Track, the tuple formed 815 by the IPv6 source address and a local RPLInstanceID is tagged in the 816 packets to identify uniquely the Track and associated transmit bundle 817 of timeSlots. 819 It results that the tagging that is used for a DetNet flow outside 820 the 6TiSCH LLN MUST be swapped into 6TiSCH formats and back as the 821 packet enters and then leaves the 6TiSCH network. 823 Note: The method and format used for encoding the RPLInstanceID at 824 6lo is generalized to all 6TiSCH topological Instances, which 825 includes Tracks. 827 5.2.2.1.1.2. Replication, Retries and Elimination 829 PRE establishes several paths in a network to provide redundancy and 830 parallel transmissions to bound the end-to-end delay. Considering 831 the scenario shown in Figure 3, many different paths are possible for 832 S to reach R. A simple way to benefit from this topology could be to 833 use the two independent paths via nodes A, C, E and via B, D, F. But 834 more complex paths are possible as well. 836 (A) (C) (E) 838 source (S) (R) (destination) 840 (B) (D) (F) 842 Figure 3: A Typical Ladder Shape with Two Parallel Paths Toward 843 the Destination 845 By employing a Packet Replication function, each node forwards a copy 846 of each data packet over two different branches. For instance, in 847 Figure 4, the source node S transmits the data packet to nodes A and 848 B, in two different timeslots within the same TSCH slotframe. 850 ===> (A) => (C) => (E) === 851 // \\// \\// \\ 852 source (S) //\\ //\\ (R) (destination) 853 \\ // \\ // \\ // 854 ===> (B) => (D) => (F) === 856 Figure 4: Packet Replication: S transmits twice the same data 857 packet, to its DP (A) and to its AP (B). 859 By employing Packet Elimination function once a node receives the 860 first copy of a data packet, it discards the subsequent copies. 861 Because the first copy that reaches a node is the one that matters, 862 it is the only copy that will be forwarded upward. 864 Considering that the wireless medium is broadcast by nature, any 865 neighbor of a transmitter may overhear a transmission. By employing 866 the Promiscuous Overhearing function, nodes will have multiple 867 opportunities to receive a given data packet. For instance, in 868 Figure 4, when the source node S transmits the data packet to node A, 869 node B may overhear this transmission. 871 6TiSCH expects elimination and replication of packets along a complex 872 Track, but has no position about how the sequence numbers would be 873 tagged in the packet. 875 As it goes, 6TiSCH expects that timeSlots corresponding to copies of 876 a same packet along a Track are correlated by configuration, and does 877 not need to process the sequence numbers. 879 The semantics of the configuration MUST enable correlated timeSlots 880 to be grouped for transmit (and respectively receive) with 881 a'OR'relations, and then a'AND'relation MUST be configurable between 882 groups. The semantics is that if the transmit (and respectively 883 receive) operation succeeded in one timeSlot in a'OR'group, then all 884 the other timeSLots in the group are ignored. Now, if there are at 885 least two groups, the'AND'relation between the groups indicates that 886 one operation must succeed in each of the groups. 888 On the transmit side, timeSlots provisioned for retries along a same 889 branch of a Track are placed a same'OR'group. The'OR'relation 890 indicates that if a transmission is acknowledged, then further 891 transmissions SHOULD NOT be attempted for timeSlots in that group. 892 There are as many'OR'groups as there are branches of the Track 893 departing from this node. Different'OR'groups are programmed for the 894 purpose of replication, each group corresponding to one branch of the 895 Track. The'AND'relation between the groups indicates that 896 transmission over any of branches MUST be attempted regardless of 897 whether a transmission succeeded in another branch. It is also 898 possible to place cells to different next-hop routers in a 899 same'OR'group. This allows to route along multi-path Tracks, trying 900 one next-hop and then another only if sending to the first fails. 902 On the receive side, all timeSlots are programmed in a same'OR'group. 903 Retries of a same copy as well as converging branches for elimination 904 are converged, meaning that the first successful reception is enough 905 and that all the other timeSlots can be ignored. 907 5.2.2.1.1.3. Differentiated Services Per-Hop-Behavior 909 Additionally, an IP packet that is sent along a Track uses the 910 Differentiated Services Per-Hop-Behavior Group called Deterministic 911 Forwarding, as described in 912 [I-D.svshah-tsvwg-deterministic-forwarding]. 914 5.2.2.1.2. Topology and capabilities 916 6TiSCH nodes are usually IoT devices, characterized by very limited 917 amount of memory, just enough buffers to store one or a few IPv6 918 packets, and limited bandwidth between peers. It results that a node 919 will maintain only a small number of peering information, and will 920 not be able to store many packets waiting to be forwarded. Peers can 921 be identified through MAC or IPv6 addresses. 923 Neighbors can be discovered over the radio using mechanism such as 924 Enhanced Beacons, but, though the neighbor information is available 925 in the 6TiSCH interface data model, 6TiSCH does not describe a 926 protocol to pro-actively push the neighborhood information to a PCE. 927 This protocol should be described and should operate over CoAP. The 928 protocol should be able to carry multiple metrics, in particular the 929 same metrics as used for RPL operations [RFC6551]. 931 The energy that the device consumes in sleep, transmit and receive 932 modes can be evaluated and reported. So can the amount of energy 933 that is stored in the device and the power that it can be scavenged 934 from the environment. The PCE SHOULD be able to compute Tracks that 935 will implement policies on how the energy is consumed, for instance 936 balance between nodes, ensure that the spent energy does not exceeded 937 the scavenged energy over a period of time, etc... 939 5.2.2.1.3. Schedule Management by a PCE 941 6TiSCH supports a mixed model of centralized routes and distributed 942 routes. Centralized routes can for example be computed by a entity 943 such as a PCE [PCE]. Distributed routes are computed by RPL 944 [RFC6550]. 946 Both methods may inject routes in the Routing Tables of the 6TiSCH 947 routers. In either case, each route is associated with a 6TiSCH 948 topology that can be a RPL Instance topology or a Track. The 6TiSCH 949 topology is indexed by a Instance ID, in a format that reuses the 950 RPLInstanceID as defined in RPL. 952 Both RPL and PCE rely on shared sources such as policies to define 953 Global and Local RPLInstanceIDs that can be used by either method. 954 It is possible for centralized and distributed routing to share a 955 same topology. Generally they will operate in different slotFrames, 956 and centralized routes will be used for scheduled traffic and will 957 have precedence over distributed routes in case of conflict between 958 the slotFrames. 960 5.2.2.1.4. SlotFrames and Priorities 962 A slotFrame is the base object that a PCE needs to manipulate to 963 program a schedule into an LLN node. Elaboration on that concept can 964 be fond in section "SlotFrames and Priorities" of 965 [I-D.ietf-6tisch-architecture] 966 IEEE802.15.4 TSCH avoids contention on the medium by formatting time 967 and frequencies in cells of transmission of equal duration. In order 968 to describe that formatting of time and frequencies, the 6TiSCH 969 architecture defines a global concept that is called a Channel 970 Distribution and Usage (CDU) matrix; a CDU matrix is a matrix of 971 cells with an height equal to the number of available channels 972 (indexed by ChannelOffsets) and a width (in timeSlots) that is the 973 period of the network scheduling operation (indexed by slotOffsets) 974 for that CDU matrix. The size of a cell is a timeSlot duration, and 975 values of 10 to 15 milliseconds are typical in 802.15.4 TSCH to 976 accommodate for the transmission of a frame and an acknowledgement, 977 including the security validation on the receive side which may take 978 up to a few milliseconds on some device architecture. 980 The frequency used by a cell in the matrix rotates in a pseudo-random 981 fashion, from an initial position at an epoch time, as the matrix 982 iterates over and over. 984 A CDU matrix is computed by the PCE, but unallocated timeSlots may be 985 used opportunistically by the nodes for classical best effort IP 986 traffic. The PCE has precedence in the allocation in case of a 987 conflict. 989 In a given network, there might be multiple CDU matrices that operate 990 with different width, so they have different durations and represent 991 different periodic operations. It is recommended that all CDU 992 matrices in a 6TiSCH domain operate with the same cell duration and 993 are aligned, so as to reduce the chances of interferences from 994 slotted-aloha operations. The PCE MUST compute the CDU matrices and 995 shared that knowledge with all the nodes. The matrices are used in 996 particular to define slotFrames. 998 A slotFrame is a MAC-level abstraction that is common to all nodes 999 and contains a series of timeSlots of equal length and precedence. 1000 It is characterized by a slotFrame_ID, and a slotFrame_size. A 1001 slotFrame aligns to a CDU matrix for its parameters, such as number 1002 and duration of timeSlots. 1004 Multiple slotFrames can coexist in a node schedule, i.e., a node can 1005 have multiple activities scheduled in different slotFrames, based on 1006 the precedence of the 6TiSCH topologies. The slotFrames may be 1007 aligned to different CDU matrices and thus have different width. 1008 There is typically one slotFrame for scheduled traffic that has the 1009 highest precedence and one or more slotFrame(s) for RPL traffic. The 1010 timeSlots in the slotFrame are indexed by the SlotOffset; the first 1011 cell is at SlotOffset 0. 1013 The 6TiSCH architecture introduces the concept of chunks 1014 ([I-D.ietf-6tisch-architecture]) to operate such spectrum 1015 distribution for a whole group of cells at a time. The CDU matrix is 1016 formatted into a set of chunks, each of them identified uniquely by a 1017 chunk-ID, see Figure 5. The PCE MUST compute the partitioning of CDU 1018 matrices into chunks and shared that knowledge with all the nodes in 1019 a 6TiSCH network. 1021 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 1022 chan.Off. 0 |chnkA|chnkP|chnk7|chnkO|chnk2|chnkK|chnk1| ... |chnkZ| 1023 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 1024 chan.Off. 1 |chnkB|chnkQ|chnkA|chnkP|chnk3|chnkL|chnk2| ... |chnk1| 1025 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 1026 ... 1027 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 1028 chan.Off. 15 |chnkO|chnk6|chnkN|chnk1|chnkJ|chnkZ|chnkI| ... |chnkG| 1029 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 1030 0 1 2 3 4 5 6 M 1032 Figure 5: CDU matrix Partitioning in Chunks 1034 The appropriation of a chunk can be requested explicitly by the PCE 1035 to any node. After a successful appropriation, the PCE owns the 1036 cells in that chunk, and may use them as hard cells to set up Tracks. 1037 Then again, 6TiSCH did not propose a method for chunk definition and 1038 a protocol for appropriation. This is to be done at RAW. 1040 5.2.2.2. 6TiSCH Tracks 1042 A Track at 6TiSCH is the application to wireless of the concept of a 1043 path in the Detnet architecture [I-D.ietf-detnet-architecture]. A 1044 Track can follow a simple sequence of relay nodes or can be 1045 structured as a more complex Destination Oriented Directed Acyclic 1046 Graph (DODAG) to a unicast destination. Along a Track, 6TiSCH nodes 1047 reserve the resources to enable the efficient transmission of packets 1048 while aiming to optimize certain properties such as reliability and 1049 ensure small jitter or bounded latency. The Track structure enables 1050 Layer-2 forwarding schemes, reducing the overhead of taking routing 1051 decisions at the Layer-3. 1053 Serial Tracks can be understood as the concatenation of cells or 1054 bundles along a routing path from a source towards a destination. 1055 The serial Track concept is analogous to the circuit concept where 1056 resources are chained through the multi-hop topology. For example, A 1057 bundle of Tx Cells in a particular node is paired to a bundle of Rx 1058 Cells in the next hop node following a routing path. 1060 Whereas scheduling ensures reliable delivery in bounded time along 1061 any Track, high availability requires the application of PAREO 1062 functions along a more complex DODAG Track structure. A DODAG has 1063 forking and joining nodes where the concepts such as Replication and 1064 Elimination can be exploited. Spatial redundancy increases the 1065 oveall energy consumption in the network but improves significantly 1066 the availability of the network as well as the packet delivery ratio. 1067 A Track may also branch off and rejoin, for the purpose of the so- 1068 called Packet Replication and Elimination (PRE), over non congruent 1069 branches. PRE may be used to complement layer-2 Automatic Repeat 1070 reQuest (ARQ) and receiver-end Ordering to form the PAREO functions. 1071 PAREO functions enable to meet industrial expectations in PDR within 1072 bounded delivery time over a Track that includes wireless links, even 1073 when the Track extends beyond the 6TiSCH network. 1075 +-----+ 1076 | IoT | 1077 | G/W | 1078 +-----+ 1079 ^ <---- Elimination 1080 | | 1081 Track branch | | 1082 +-------+ +--------+ Subnet Backbone 1083 | | 1084 +--|--+ +--|--+ 1085 | | | Backbone | | | Backbone 1086 o | | | router | | | router 1087 +--/--+ +--|--+ 1088 o / o o---o----/ o 1089 o o---o--/ o o o o o 1090 o \ / o o LLN o 1091 o v <---- Replication 1092 o 1094 Figure 6: End-to-End deterministic Track 1096 In the example above (see Figure 6), a Track is laid out from a field 1097 device in a 6TiSCH network to an IoT gateway that is located on a 1098 IEEE802.1 TSN backbone. 1100 The Replication function in the field device sends a copy of each 1101 packet over two different branches, and a PCE schedules each hop of 1102 both branches so that the two copies arrive in due time at the 1103 gateway. In case of a loss on one branch, hopefully the other copy 1104 of the packet still makes it in due time. If two copies make it to 1105 the IoT gateway, the Elimination function in the gateway ignores the 1106 extra packet and presents only one copy to upper layers. 1108 At each 6TiSCH hop along the Track, the PCE may schedule more than 1109 one timeSlot for a packet, so as to support Layer-2 retries (ARQ). 1110 It is also possible that the field device only uses the second branch 1111 if sending over the first branch fails. 1113 In current deployments, a TSCH Track does not necessarily support PRE 1114 but is systematically multi-path. This means that a Track is 1115 scheduled so as to ensure that each hop has at least two forwarding 1116 solutions, and the forwarding decision is to try the preferred one 1117 and use the other in case of Layer-2 transmission failure as detected 1118 by ARQ. 1120 Methods to implement complex Tracks are described in 1121 [I-D.papadopoulos-paw-pre-reqs] and complemented by extensions to the 1122 RPL routing protocol in [I-D.ietf-roll-nsa-extension] for best effort 1123 traffic, but a centralized routing technique such as promoted in 1124 DetNet is still missing. 1126 5.2.2.2.1. Track Scheduling Protocol 1128 Section "Schedule Management Mechanisms" of the 6TiSCH architecture 1129 describes 4 paradigms to manage the TSCH schedule of the LLN nodes: 1130 Static Scheduling, neighbor-to-neighbor Scheduling, remote monitoring 1131 and scheduling management, and Hop-by-hop scheduling. The Track 1132 operation for DetNet corresponds to a remote monitoring and 1133 scheduling management by a PCE. 1135 Early work at 6TiSCH on a data model and a protocol to program the 1136 schedule in the 6TiSCH device was never concluded as the group 1137 focussed on best effort traffic. This work would be revived by RAW: 1139 The 6top interface document [RFC8480] (to be reopened at RAW) was 1140 intended to specify the generic data model that can be used to 1141 monitor and manage resources of the 6top sublayer. Abstract 1142 methods were suggested for use by a management entity in the 1143 device. The data model also enables remote control operations on 1144 the 6top sublayer. 1146 [I-D.ietf-6tisch-coap] (to be reopened at RAW) was intended to 1147 define a mapping of the 6top set of commands, which is described 1148 in RFC 8480, to CoAP resources. This allows an entity to interact 1149 with the 6top layer of a node that is multiple hops away in a 1150 RESTful fashion. 1152 [I-D.ietf-6tisch-coap] also defined a basic set CoAP resources and 1153 associated RESTful access methods (GET/PUT/POST/DELETE). The 1154 payload (body) of the CoAP messages is encoded using the CBOR 1155 format. The PCE commands are expected to be issued directly as 1156 CoAP requests or to be mapped back and forth into CoAP by a 1157 gateway function at the edge of the 6TiSCH network. For instance, 1158 it is possible that a mapping entity on the backbone transforms a 1159 non-CoAP protocol such as PCEP into the RESTful interfaces that 1160 the 6TiSCH devices support. 1162 5.2.2.2.2. Track Forwarding 1164 By forwarding, this specification means the per-packet operation that 1165 allows to deliver a packet to a next hop or an upper layer in this 1166 node. Forwarding is based on pre-existing state that was installed 1167 as a result of the routing computation of a Track by a PCE. The 1168 6TiSCH architecture supports three different forwarding model, G-MPLS 1169 Track Forwarding (TF), 6LoWPAN Fragment Forwarding (FF) and IPv6 1170 Forwarding (6F) which is the classical IP operation 1171 [I-D.ietf-6tisch-architecture]. The DetNet case relates to the Track 1172 Forwarding operation under the control of a PCE. 1174 A Track is a unidirectional path between a source and a destination. 1175 In a Track cell, the normal operation of IEEE802.15.4 Automatic 1176 Repeat-reQuest (ARQ) usually happens, though the acknowledgment may 1177 be omitted in some cases, for instance if there is no scheduled cell 1178 for a retry. 1180 Track Forwarding is the simplest and fastest. A bundle of cells set 1181 to receive (RX-cells) is uniquely paired to a bundle of cells that 1182 are set to transmit (TX-cells), representing a layer-2 forwarding 1183 state that can be used regardless of the network layer protocol. 1184 This model can effectively be seen as a Generalized Multi-protocol 1185 Label Switching (G-MPLS) operation in that the information used to 1186 switch a frame is not an explicit label, but rather related to other 1187 properties of the way the packet was received, a particular cell in 1188 the case of 6TiSCH. As a result, as long as the TSCH MAC (and 1189 Layer-2 security) accepts a frame, that frame can be switched 1190 regardless of the protocol, whether this is an IPv6 packet, a 6LoWPAN 1191 fragment, or a frame from an alternate protocol such as WirelessHART 1192 or ISA100.11a. 1194 A data frame that is forwarded along a Track normally has a 1195 destination MAC address that is set to broadcast - or a multicast 1196 address depending on MAC support. This way, the MAC layer in the 1197 intermediate nodes accepts the incoming frame and 6top switches it 1198 without incurring a change in the MAC header. In the case of 1199 IEEE802.15.4, this means effectively broadcast, so that along the 1200 Track the short address for the destination of the frame is set to 1201 0xFFFF. 1203 A Track is thus formed end-to-end as a succession of paired bundles, 1204 a receive bundle from the previous hop and a transmit bundle to the 1205 next hop along the Track, and a cell in such a bundle belongs to at 1206 most one Track. For a given iteration of the device schedule, the 1207 effective channel of the cell is obtained by adding a pseudo-random 1208 number to the channelOffset of the cell, which results in a rotation 1209 of the frequency that used for transmission. The bundles may be 1210 computed so as to accommodate both variable rates and 1211 retransmissions, so they might not be fully used at a given iteration 1212 of the schedule. The 6TiSCH architecture provides additional means 1213 to avoid waste of cells as well as overflows in the transmit bundle, 1214 as follows: 1216 In one hand, a TX-cell that is not needed for the current iteration 1217 may be reused opportunistically on a per-hop basis for routed 1218 packets. When all of the frame that were received for a given Track 1219 are effectively transmitted, any available TX-cell for that Track can 1220 be reused for upper layer traffic for which the next-hop router 1221 matches the next hop along the Track. In that case, the cell that is 1222 being used is effectively a TX-cell from the Track, but the short 1223 address for the destination is that of the next-hop router. It 1224 results that a frame that is received in a RX-cell of a Track with a 1225 destination MAC address set to this node as opposed to broadcast must 1226 be extracted from the Track and delivered to the upper layer (a frame 1227 with an unrecognized MAC address is dropped at the lower MAC layer 1228 and thus is not received at the 6top sublayer). 1230 On the other hand, it might happen that there are not enough TX-cells 1231 in the transmit bundle to accommodate the Track traffic, for instance 1232 if more retransmissions are needed than provisioned. In that case, 1233 the frame can be placed for transmission in the bundle that is used 1234 for layer-3 traffic towards the next hop along the Track as long as 1235 it can be routed by the upper layer, that is, typically, if the frame 1236 transports an IPv6 packet. The MAC address should be set to the 1237 next-hop MAC address to avoid confusion. It results that a frame 1238 that is received over a layer-3 bundle may be in fact associated to a 1239 Track. In a classical IP link such as an Ethernet, off-Track traffic 1240 is typically in excess over reservation to be routed along the non- 1241 reserved path based on its QoS setting. But with 6TiSCH, since the 1242 use of the layer-3 bundle may be due to transmission failures, it 1243 makes sense for the receiver to recognize a frame that should be re- 1244 Tracked, and to place it back on the appropriate bundle if possible. 1245 A frame should be re-Tracked if the Per-Hop-Behavior group indicated 1246 in the Differentiated Services Field in the IPv6 header is set to 1247 Deterministic Forwarding, as discussed in Section 5.2.2.1.1. A frame 1248 is re-Tracked by scheduling it for transmission over the transmit 1249 bundle associated to the Track, with the destination MAC address set 1250 to broadcast. 1252 There are 2 modes for a Track, transport mode and tunnel mode. 1254 5.2.2.2.2.1. Transport Mode 1256 In transport mode, the Protocol Data Unit (PDU) is associated with 1257 flow-dependant meta-data that refers uniquely to the Track, so the 1258 6top sublayer can place the frame in the appropriate cell without 1259 ambiguity. In the case of IPv6 traffic, this flow identification is 1260 transported in the Flow Label of the IPv6 header. Associated with 1261 the source IPv6 address, the Flow Label forms a globally unique 1262 identifier for that particular Track that is validated at egress 1263 before restoring the destination MAC address (DMAC) and punting to 1264 the upper layer. 1266 | ^ 1267 +--------------+ | | 1268 | IPv6 | | | 1269 +--------------+ | | 1270 | 6LoWPAN HC | | | 1271 +--------------+ ingress egress 1272 | 6top | sets +----+ +----+ restores 1273 +--------------+ dmac to | | | | dmac to 1274 | TSCH MAC | brdcst | | | | self 1275 +--------------+ | | | | | | 1276 | LLN PHY | +-------+ +--...-----+ +-------+ 1277 +--------------+ 1279 Figure 7: Track Forwarding, Transport Mode 1281 5.2.2.2.2.2. Tunnel Mode 1283 In tunnel mode, the frames originate from an arbitrary protocol over 1284 a compatible MAC that may or may not be synchronized with the 6TiSCH 1285 network. An example of this would be a router with a dual radio that 1286 is capable of receiving and sending WirelessHART or ISA100.11a frames 1287 with the second radio, by presenting itself as an Access Point or a 1288 Backbone Router, respectively. 1290 In that mode, some entity (e.g. PCE) can coordinate with a 1291 WirelessHART Network Manager or an ISA100.11a System Manager to 1292 specify the flows that are to be transported transparently over the 1293 Track. 1295 +--------------+ 1296 | IPv6 | 1297 +--------------+ 1298 | 6LoWPAN HC | 1299 +--------------+ set restore 1300 | 6top | +dmac+ +dmac+ 1301 +--------------+ to|brdcst to|nexthop 1302 | TSCH MAC | | | | | 1303 +--------------+ | | | | 1304 | LLN PHY | +-------+ +--...-----+ +-------+ 1305 +--------------+ | ingress egress | 1306 | | 1307 +--------------+ | | 1308 | LLN PHY | | | 1309 +--------------+ | | 1310 | TSCH MAC | | | 1311 +--------------+ | dmac = | dmac = 1312 |ISA100/WiHART | | nexthop v nexthop 1313 +--------------+ 1315 Figure 8: Track Forwarding, Tunnel Mode 1317 In that case, the flow information that identifies the Track at the 1318 ingress 6TiSCH router is derived from the RX-cell. The dmac is set 1319 to this node but the flow information indicates that the frame must 1320 be tunneled over a particular Track so the frame is not passed to the 1321 upper layer. Instead, the dmac is forced to broadcast and the frame 1322 is passed to the 6top sublayer for switching. 1324 At the egress 6TiSCH router, the reverse operation occurs. Based on 1325 metadata associated to the Track, the frame is passed to the 1326 appropriate link layer with the destination MAC restored. 1328 5.2.2.2.2.3. Tunnel Metadata 1330 Metadata coming with the Track configuration is expected to provide 1331 the destination MAC address of the egress endpoint as well as the 1332 tunnel mode and specific data depending on the mode, for instance a 1333 service access point for frame delivery at egress. If the tunnel 1334 egress point does not have a MAC address that matches the 1335 configuration, the Track installation fails. 1337 In transport mode, if the final layer-3 destination is the tunnel 1338 termination, then it is possible that the IPv6 address of the 1339 destination is compressed at the 6LoWPAN sublayer based on the MAC 1340 address. It is thus mandatory at the ingress point to validate that 1341 the MAC address that was used at the 6LoWPAN sublayer for compression 1342 matches that of the tunnel egress point. For that reason, the node 1343 that injects a packet on a Track checks that the destination is 1344 effectively that of the tunnel egress point before it overwrites it 1345 to broadcast. The 6top sublayer at the tunnel egress point reverts 1346 that operation to the MAC address obtained from the tunnel metadata. 1348 5.2.2.2.2.4. OAM 1350 An Overview of Operations, Administration, and Maintenance (OAM) 1351 Tools [RFC7276] provides an overwiew of the existing tooling for OAM 1352 [RFC6291]. Tracks are complex paths and new tooling is necessary to 1353 manage them, with respect to load control, timing, and the Packet 1354 Replication and Elimination Functions (PREF). 1356 An example of such tooling can be found in the context of BIER 1357 [RFC8279] and more specifically BIER Traffic Engineering 1358 [I-D.ietf-bier-te-arch] (BIER-TE): 1359 [I-D.thubert-bier-replication-elimination] leverages BIER-TE to 1360 control the process of PREF, and to provide traceability of these 1361 operations, in the deterministic dataplane, along a complex Track. 1362 For the 6TiSCH type of constrained environment, 1363 [I-D.thubert-6lo-bier-dispatch] enables an efficient encoding of the 1364 BIER bitmap within the 6LoRH framework. 1366 6. 5G 1368 6.1. Provenance and Documents 1370 The 3rd Generation Partnership Project (3GPP) incorporates many 1371 companies whose business is related to cellular network operation as 1372 well as network equipment and device manufacturing. All generations 1373 of 3GPP technologies provide scheduled wireless segments, primarily 1374 in licensed spectrum which is beneficial for reliability and 1375 availability. 1377 In 2016, the 3GPP started to design New Radio (NR) technology 1378 belonging to the fifth generation (5G) of cellular networks. NR has 1379 been designed from the beginning to not only address enhanced Mobile 1380 Broadband (eMBB) services for consumer devices such as smart phones 1381 or tablets but is also tailored for future Internet of Things (IoT) 1382 communication and connected cyber-physical systems. In addition to 1383 eMBB, requirement categories have been defined on Massive Machine- 1384 Type Communication (M-MTC) for a large number of connected devices/ 1385 sensors, and Ultra-Reliable Low-Latency Communication (URLLC) for 1386 connected control systems and critical communication as illustrated 1387 in Figure 9. It is the URLLC capabilities that make 5G a great 1388 candidate for reliable low-latency communication. With these three 1389 corner stones, NR is a complete solution supporting the connectivity 1390 needs of consumers, enterprises, and public sector for both wide area 1391 and local area, e.g. indoor deployments. A general overview of NR 1392 can be found in [TS38300]. 1394 enhanced 1395 Mobile Broadband 1396 ^ 1397 / \ 1398 / \ 1399 / \ 1400 / \ 1401 / 5G \ 1402 / \ 1403 / \ 1404 / \ 1405 +-----------------+ 1406 Massive Ultra-Reliable 1407 Machine-Type Low-Latency 1408 Communication Communication 1410 Figure 9: 5G Application Areas 1412 As a result of releasing the first NR specification in 2018 (Release 1413 15), it has been proven by many companies that NR is a URLLC-capable 1414 technology and can deliver data packets at 10^-5 packet error rate 1415 within 1ms latency budget [TR37910]. Those evaluations were 1416 consolidated and forwarded to ITU to be included in the [IMT2020] 1417 work. 1419 In order to understand communication requirements for automation in 1420 vertical domains, 3GPP studied different use cases [TR22804] and 1421 released technical specification with reliability, availability and 1422 latency demands for a variety of applications [TS22104]. 1424 As an evolution of NR, multiple studies have been conducted in scope 1425 of 3GPP Release 16 including the following two, focusing on radio 1426 aspects: 1428 1. Study on physical layer enhancements for NR ultra-reliable and 1429 low latency communication (URLLC) [TR38824]. 1431 2. Study on NR industrial Internet of Things (I-IoT) [TR38825]. 1433 In addition, several enhancements have been done on system 1434 architecture level which are reflected in System architecture for the 1435 5G System (5GS) [TS23501]. 1437 6.2. General Characteristics 1439 The 5G Radio Access Network (5G RAN) with its NR interface includes 1440 several features to achieve Quality of Service (QoS), such as a 1441 guaranteeably low latency or tolerable packet error rates for 1442 selected data flows. Determinism is achieved by centralized 1443 admission control and scheduling of the wireless frequency resources, 1444 which are typically licensed frequency bands assigned to a network 1445 operator. 1447 NR enables short transmission slots in a radio subframe, which 1448 benefits low-latency applications. NR also introduces mini-slots, 1449 where prioritized transmissions can be started without waiting for 1450 slot boundaries, further reducing latency. As part of giving 1451 priority and faster radio access to URLLC traffic, NR introduces 1452 preemption where URLLC data transmission can preempt ongoing non- 1453 URLLC transmissions. Additionally, NR applies very fast processing, 1454 enabling retransmissions even within short latency bounds. 1456 NR defines extra-robust transmission modes for increased reliability 1457 both for data and control radio channels. Reliability is further 1458 improved by various techniques, such as multi-antenna transmission, 1459 the use of multiple frequency carriers in parallel and packet 1460 duplication over independent radio links. NR also provides full 1461 mobility support, which is an important reliability aspect not only 1462 for devices that are moving, but also for devices located in a 1463 changing environment. 1465 Network slicing is seen as one of the key features for 5G, allowing 1466 vertical industries to take advantage of 5G networks and services. 1467 Network slicing is about transforming a Public Land Mobile Network 1468 (PLMN) from a single network to a network where logical partitions 1469 are created, with appropriate network isolation, resources, optimized 1470 topology and specific configuration to serve various service 1471 requirements. An operator can configure and manage the mobile 1472 network to support various types of services enabled by 5G, for 1473 example eMBB and URLLC, depending on the different customers' needs. 1475 Exposure of capabilities of 5G Systems to the network or applications 1476 outside the 3GPP domain have been added to Release 16 [TS23501]. Via 1477 exposure interfaces, applications can access 5G capabilities, e.g., 1478 communication service monitoring and network maintenance. 1480 For several generations of mobile networks, 3GPP has considered how 1481 the communication system should work on a global scale with billions 1482 of users, taking into account resilience aspects, privacy regulation, 1483 protection of data, encryption, access and core network security, as 1484 well as interconnect. Security requirements evolve as demands on 1485 trustworthiness increase. For example, this has led to the 1486 introduction of enhanced privacy protection features in 5G. 5G also 1487 employs strong security algorithms, encryption of traffic, protection 1488 of signaling and protection of interfaces. 1490 One particular strength of mobile networks is the authentication, 1491 based on well-proven algorithms and tightly coupled with a global 1492 identity management infrastructure. Since 3G, there is also mutual 1493 authentication, allowing the network to authenticate the device and 1494 the device to authenticate the network. Another strength is secure 1495 solutions for storage and distribution of keys fulfilling regulatory 1496 requirements and allowing international roaming. When connecting to 1497 5G, the user meets the entire communication system, where security is 1498 the result of standardization, product security, deployment, 1499 operations and management as well as incident handling capabilities. 1500 The mobile networks approach the entirety in a rather coordinated 1501 fashion which is beneficial for security. 1503 6.3. Deployment and Spectrum 1505 The 5G system allows deployment in a vast spectrum range, addressing 1506 use-cases in both wide-area as well as local networks. Furthermore, 1507 5G can be configured for public and non-public access. 1509 When it comes to spectrum, NR allows combining the merits of many 1510 frequency bands, such as the high bandwidths in millimeter Waves 1511 (mmW) for extreme capacity locally, as well as the broad coverage 1512 when using mid- and low frequency bands to address wide-area 1513 scenarios. URLLC is achievable in all these bands. Spectrum can be 1514 either licensed, which means that the license holder is the only 1515 authorized user of that spectrum range, or unlicensed, which means 1516 that anyone who wants to use the spectrum can do so. 1518 A prerequisite for critical communication is performance 1519 predictability, which can be achieved by the full control of the 1520 access to the spectrum, which 5G provides. Licensed spectrum 1521 guarantees control over spectrum usage by the system, making it a 1522 preferable option for critical communication. However, unlicensed 1523 spectrum can provide an additional resource for scaling non-critical 1524 communications. While NR is initially developed for usage of 1525 licensed spectrum, the functionality to access also unlicensed 1526 spectrum was introduced in 3GPP Release 16. 1528 Licensed spectrum dedicated to mobile communications has been 1529 allocated to mobile service providers, i.e. issued as longer-term 1530 licenses by national administrations around the world. These 1531 licenses have often been associated with coverage requirements and 1532 issued across whole countries, or in large regions. Besides this, 1533 configured as a non-public network (NPN) deployment, 5G can provide 1534 network services also to a non-operator defined organization and its 1535 premises such as a factory deployment. By this isolation, quality of 1536 service requirements, as well as security requirements can be 1537 achieved. An integration with a public network, if required, is also 1538 possible. The non-public (local) network can thus be interconnected 1539 with a public network, allowing devices to roam between the networks. 1541 In an alternative model, some countries are now in the process of 1542 allocating parts of the 5G spectrum for local use to industries. 1543 These non-service providers then have a choice of applying for a 1544 local license themselves and operating their own network or 1545 cooperating with a public network operator or service provider. 1547 6.4. Applicability to Deterministic Flows 1549 6.4.1. System Architecture 1551 The 5G system [TS23501] consists of the User Equipment (UE) at the 1552 terminal side, and the Radio Access Network (RAN) with the gNB as 1553 radio base station node, as well as the Core Network (CN). The core 1554 network is based on a service-based architecture with the central 1555 functions: Access and Mobility Management Function (AMF), Session 1556 Management Function (SMF) and User Plane Function (UPF) as 1557 illustrated in Figure 10. 1559 The gNB's main responsibility is the radio resource management, 1560 including admission control and scheduling, mobility control and 1561 radio measurement handling. The AMF handles the UE's connection 1562 status and security, while the SMF controls the UE's data sessions. 1563 The UPF handles the user plane traffic. 1565 The SMF can instantiate various Packet Data Unit (PDU) sessions for 1566 the UE, each associated with a set of QoS flows, i.e., with different 1567 QoS profiles. Segregation of those sessions is also possible, e.g., 1568 resource isolation in the RAN and in the CN can be defined (slicing). 1570 +----+ +---+ +---+ +---+ +---+ +---+ 1571 |NSSF| |NEF| |NRF| |PCF| |UDM| |AF | 1572 +--+-+ +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ 1573 | | | | | | 1574 Nnssf| Nnef| Nnrf| Npcf| Nudm| Naf| 1575 | | | | | | 1576 ---+------+-+-----+-+------------+--+-----+-+--- 1577 | | | | 1578 Nausf| Nausf| Nsmf| | 1579 | | | | 1580 +--+-+ +-+-+ +-+-+ +-+-+ 1581 |AUSF| |AMF| |SMF| |SCP| 1582 +----+ +++-+ +-+-+ +---+ 1583 / | | 1584 / | | 1585 / | | 1586 N1 N2 N4 1587 / | | 1588 / | | 1589 / | | 1590 +--+-+ +--+--+ +--+---+ +----+ 1591 | UE +---+(R)AN+--N3--+ UPF +--N6--+ DN | 1592 +----+ +-----+ ++----++ +----+ 1593 | | 1594 +-N9-+ 1596 Figure 10: 5G System Architecture 1598 To allow UE mobility across cells/gNBs, handover mechanisms are 1599 supported in NR. For an established connection, i.e., connected mode 1600 mobility, a gNB can configure a UE to report measurements of received 1601 signal strength and quality of its own and neighbouring cells, 1602 periodically or event-based. Based on these measurement reports, the 1603 gNB decides to handover a UE to another target cell/gNB. Before 1604 triggering the handover, it is hand-shaked with the target gNB based 1605 on network signalling. A handover command is then sent to the UE and 1606 the UE switches its connection to the target cell/gNB. The Packet 1607 Data Convergence Protocol (PDCP) of the UE can be configured to avoid 1608 data loss in this procedure, i.e., handle retransmissions if needed. 1609 Data forwarding is possible between source and target gNB as well. 1610 To improve the mobility performance further, i.e., to avoid 1611 connection failures, e.g., due to too-late handovers, the mechanism 1612 of conditional handover is introduced in Release 16 specifications. 1614 Therein a conditional handover command, defining a triggering point, 1615 can be sent to the UE before UE enters a handover situation. A 1616 further improvement introduced in Release 16 is the Dual Active 1617 Protocol Stack (DAPS), where the UE maintains the connection to the 1618 source cell while connecting to the target cell. This way, potential 1619 interruptions in packet delivery can be avoided entirely. 1621 6.4.2. Overview of The Radio Protocol Stack 1623 The protocol architecture for NR consists of the L1 Physical layer 1624 (PHY) and as part of the L2, the sublayers of Medium Access Control 1625 (MAC), Radio Link Control (RLC), Packet Data Convergence Protocol 1626 (PDCP), as well as the Service Data Adaption Protocol (SDAP). 1628 The PHY layer handles signal processing related actions, such as 1629 encoding/decoding of data and control bits, modulation, antenna 1630 precoding and mapping. 1632 The MAC sub-layer handles multiplexing and priority handling of 1633 logical channels (associated with QoS flows) to transport blocks for 1634 PHY transmission, as well as scheduling information reporting and 1635 error correction through Hybrid Automated Repeat Request (HARQ). 1637 The RLC sublayer handles sequence numbering of higher layer packets, 1638 retransmissions through Automated Repeat Request (ARQ), if 1639 configured, as well as segmentation and reassembly and duplicate 1640 detection. 1642 The PDCP sublayer consists of functionalities for ciphering/ 1643 deciphering, integrity protection/verification, re-ordering and in- 1644 order delivery, duplication and duplicate handling for higher layer 1645 packets, and acts as the anchor protocol to support handovers. 1647 The SDAP sublayer provides services to map QoS flows, as established 1648 by the 5G core network, to data radio bearers (associated with 1649 logical channels), as used in the 5G RAN. 1651 Additionally, in RAN, the Radio Resource Control (RRC) protocol, 1652 handles the access control and configuration signalling for the 1653 aforementioned protocol layers. RRC messages are considered L3 and 1654 thus transmitted also via those radio protocol layers. 1656 To provide low latency and high reliability for one transmission 1657 link, i.e., to transport data (or control signaling) of one radio 1658 bearer via one carrier, several features have been introduced on the 1659 user plane protocols for PHY and L2, as explained in the following. 1661 6.4.3. Radio (PHY) 1663 NR is designed with native support of antenna arrays utilizing 1664 benefits from beamforming, transmissions over multiple MIMO layers 1665 and advanced receiver algorithms allowing effective interference 1666 cancellation. Those antenna techniques are the basis for high signal 1667 quality and effectiveness of spectral usage. Spatial diversity with 1668 up to 4 MIMO layers in UL and up to 8 MIMO layers in DL is supported. 1669 Together with spatial-domain multiplexing, antenna arrays can focus 1670 power in desired direction to form beams. NR supports beam 1671 management mechanisms to find the best suitable beam for UE initially 1672 and when it is moving. In addition, gNBs can coordinate their 1673 respective DL and UL transmissions over the backhaul network keeping 1674 interference reasonably low, and even make transmissions or 1675 receptions from multiple points (multi-TRP). Multi-TRP can be used 1676 for repetition of data packet in time, in frequency or over multiple 1677 MIMO layers which can improve reliability even further. 1679 Any downlink transmission to a UE starts from resource allocation 1680 signaling over the Physical Downlink Control Channel (PDCCH). If it 1681 is successfully received, the UE will know about the scheduled 1682 transmission and may receive data over the Physical Downlink Shared 1683 Channel (PDSCH). If retransmission is required according to the HARQ 1684 scheme, a signaling of negative acknowledgement (NACK) on the 1685 Physical Uplink Control Channel (PUCCH) is involved and PDCCH 1686 together with PDSCH transmissions (possibly with additional 1687 redundancy bits) are transmitted and soft-combined with previously 1688 received bits. Otherwise, if no valid control signaling for 1689 scheduling data is received, nothing is transmitted on PUCCH 1690 (discontinuous transmission - DTX),and the base station upon 1691 detecting DTX will retransmit the initial data. 1693 An uplink transmission normally starts from a Scheduling Request (SR) 1694 - a signaling message from the UE to the base station sent via PUCCH. 1695 Once the scheduler is informed about buffer data in UE, e.g., by SR, 1696 the UE transmits a data packet on the Physical Uplink Shared Channel 1697 (PUSCH). Pre-scheduling not relying on SR is also possible (see 1698 following section). 1700 Since transmission of data packets require usage of control and data 1701 channels, there are several methods to maintain the needed 1702 reliability. NR uses Low Density Parity Check (LDPC) codes for data 1703 channels, Polar codes for PDCCH, as well as orthogonal sequences and 1704 Polar codes for PUCCH. For ultra-reliability of data channels, very 1705 robust (low spectral efficiency) Modulation and Coding Scheme (MCS) 1706 tables are introduced containing very low (down to 1/20) LDPC code 1707 rates using BPSK or QPSK. Also, PDCCH and PUCCH channels support 1708 multiple code rates including very low ones for the channel 1709 robustness. 1711 A connected UE reports downlink (DL) quality to gNB by sending 1712 Channel State Information (CSI) reports via PUCCH while uplink (UL) 1713 quality is measured directly at gNB. For both uplink and downlink, 1714 gNB selects the desired MCS number and signals it to the UE by 1715 Downlink Control Information (DCI) via PDCCH channel. For URLLC 1716 services, the UE can assist the gNB by advising that MCS targeting 1717 10^-5 Block Error Rate (BLER) are used. Robust link adaptation 1718 algorithms can maintain the needed level of reliability considering a 1719 given latency bound. 1721 Low latency on the physical layer is provided by short transmission 1722 duration which is possible by using high Subcarrier Spacing (SCS) and 1723 the allocation of only one or a few Orthogonal Frequency Division 1724 Multiplexing (OFDM) symbols. For example, the shortest latency for 1725 the worst case in DL can be 0.23ms and in UL can be 0.24ms according 1726 to (section 5.7.1 in [TR37910]). Moreover, if the initial 1727 transmission has failed, HARQ feedback can quickly be provided and an 1728 HARQ retransmission is scheduled. 1730 Dynamic multiplexing of data associated with different services is 1731 highly desirable for efficient use of system resources and to 1732 maximize system capacity. Assignment of resources for eMBB is 1733 usually done with regular (longer) transmission slots, which can lead 1734 to blocking of low latency services. To overcome the blocking, eMBB 1735 resources can be pre-empted and re-assigned to URLLC services. In 1736 this way, spectrally efficient assignments for eMBB can be ensured 1737 while providing flexibility required to ensure a bounded latency for 1738 URLLC services. In downlink, the gNB can notify the eMBB UE about 1739 pre-emption after it has happened, while in uplink there are two pre- 1740 emption mechanisms: special signaling to cancel eMBB transmission and 1741 URLLC dynamic power boost to suppress eMBB transmission. 1743 6.4.4. Scheduling and QoS (MAC) 1745 One integral part of the 5G system is the Quality of Service (QoS) 1746 framework [TS23501]. QoS flows are setup by the 5G system for 1747 certain IP or Ethernet packet flows, so that packets of each flow 1748 receive the same forwarding treatment, i.e., in scheduling and 1749 admission control. QoS flows can for example be associated with 1750 different priority level, packet delay budgets and tolerable packet 1751 error rates. Since radio resources are centrally scheduled in NR, 1752 the admission control function can ensure that only those QoS flows 1753 are admitted for which QoS targets can be reached. 1755 NR transmissions in both UL and DL are scheduled by the gNB 1756 [TS38300]. This ensures radio resource efficiency, fairness in 1757 resource usage of the users and enables differentiated treatment of 1758 the data flows of the users according to the QoS targets of the 1759 flows. Those QoS flows are handled as data radio bearers or logical 1760 channels in NR RAN scheduling. 1762 The gNB can dynamically assign DL and UL radio resources to users, 1763 indicating the resources as DL assignments or UL grants via control 1764 channel to the UE. Radio resources are defined as blocks of OFDM 1765 symbols in spectral domain and time domain. Different lengths are 1766 supported in time domain, i.e., (multiple) slot or mini-slot lengths. 1767 Resources of multiple frequency carriers can be aggregated and 1768 jointly scheduled to the UE. 1770 Scheduling decisions are based, e.g., on channel quality measured on 1771 reference signals and reported by the UE (cf. periodical CSI reports 1772 for DL channel quality). The transmission reliability can be chosen 1773 in the scheduling algorithm, i.e., by link adaptation where an 1774 appropriate transmission format (e.g., robustness of modulation and 1775 coding scheme, controlled UL power) is selected for the radio channel 1776 condition of the UE. Retransmissions, based on HARQ feedback, are 1777 also controlled by the scheduler. If needed to avoid HARQ round-trip 1778 time delays, repeated transmissions can be also scheduled beforehand, 1779 to the cost of reduced spectral efficiency. 1781 In dynamic DL scheduling, transmission can be initiated immediately 1782 when DL data becomes available in the gNB. However, for dynamic UL 1783 scheduling, when data becomes available but no UL resources are 1784 available yet, the UE indicates the need for UL resources to the gNB 1785 via a (single bit) scheduling request message in the UL control 1786 channel. When thereupon UL resources are scheduled to the UE, the UE 1787 can transmit its data and may include a buffer status report, 1788 indicating the exact amount of data per logical channel still left to 1789 be sent. More UL resources may be scheduled accordingly. To avoid 1790 the latency introduced in the scheduling request loop, UL radio 1791 resources can also be pre-scheduled. 1793 In particular for periodical traffic patterns, the pre-scheduling can 1794 rely on the scheduling features DL Semi-Persistent Scheduling (SPS) 1795 and UL Configured Grant (CG). With these features, periodically 1796 recurring resources can be assigned in DL and UL. Multiple parallels 1797 of those configurations are supported, in order to serve multiple 1798 parallel traffic flows of the same UE. 1800 To support QoS enforcement in the case of mixed traffic with 1801 different QoS requirements, several features have recently been 1802 introduced. This way, e.g., different periodical critical QoS flows 1803 can be served together with best effort transmissions, by the same 1804 UE. Among others, these features (partly Release 16) are: 1) UL 1805 logical channel transmission restrictions allowing to map logical 1806 channels of certain QoS only to intended UL resources of a certain 1807 frequency carrier, slot-length, or CG configuration, and 2) intra-UE 1808 pre-emption, allowing critical UL transmissions to pre-empt non- 1809 critical transmissions. 1811 When multiple frequency carriers are aggregated, duplicate parallel 1812 transmissions can be employed (beside repeated transmissions on one 1813 carrier). This is possible in the Carrier Aggregation (CA) 1814 architecture where those carriers originate from the same gNB, or in 1815 the Dual Connectivity (DC) architecture where the carriers originate 1816 from different gNBs, i.e., the UE is connected to two gNBs in this 1817 case. In both cases, transmission reliability is improved by this 1818 means of providing frequency diversity. 1820 In addition to licensed spectrum, a 5G system can also utilize 1821 unlicensed spectrum to offload non-critical traffic. This version of 1822 NR is called NR-U, part of 3GPP Release 16. The central scheduling 1823 approach applies also for unlicensed radio resources, but in addition 1824 also the mandatory channel access mechanisms for unlicensed spectrum, 1825 e.g., Listen Before Talk (LBT) are supported in NR-U. This way, by 1826 using NR, operators have and can control access to both licensed and 1827 unlicensed frequency resources. 1829 6.4.5. Time-Sensitive Networking (TSN) Integration 1831 The main objective of Time-Sensitive Networking (TSN) is to provide 1832 guaranteed data delivery within a guaranteed time window, i.e., 1833 bounded low latency. IEEE 802.1 TSN [IEEE802.1TSN] is a set of open 1834 standards that provide features to enable deterministic communication 1835 on standard IEEE 802.3 Ethernet [IEEE802.3]. TSN standards can be 1836 seen as a toolbox for traffic shaping, resource management, time 1837 synchronization, and reliability. 1839 A TSN stream is a data flow between one end station (Talker) to 1840 another end station (Listener). In the centralized configuration 1841 model, TSN bridges are configured by the Central Network Controller 1842 (CNC) [IEEE802.1Qcc] to provide deterministic connectivity for the 1843 TSN stream through the network. Time-based traffic shaping provided 1844 by Scheduled Traffic [IEEE802.1Qbv] may be used to achieve bounded 1845 low latency. The TSN tool for time synchronization is the 1846 generalized Precision Time Protocol (gPTP) [IEEE802.1AS]), which 1847 provides reliable time synchronization that can be used by end 1848 stations and by other TSN tools, e.g., Scheduled Traffic 1849 [IEEE802.1Qbv]. High availability, as a result of ultra-reliability, 1850 is provided for data flows by the Frame Replication and Elimination 1851 for Reliability (FRER) [IEEE802.1CB] mechanism. 1853 3GPP Release 16 includes integration of 5G with TSN, i.e., specifies 1854 functions for the 5G System (5GS) to deliver TSN streams such that 1855 the meet their QoS requirements. A key aspect of the integration is 1856 the 5GS appears from the rest of the network as a set of TSN bridges, 1857 in particular, one virtual bridge per User Plane Function (UPF) on 1858 the user plane. The 5GS includes TSN Translator (TT) functionality 1859 for the adaptation of the 5GS to the TSN bridged network and for 1860 hiding the 5GS internal procedures. The 5GS provides the following 1861 components: 1863 1. interface to TSN controller, as per [IEEE802.1Qcc] for the fully 1864 centralized configuration model 1866 2. time synchronization via reception and transmission of gPTP PDUs 1867 [IEEE802.1AS] 1869 3. low latency, hence, can be integrated with Scheduled Traffic 1870 [IEEE802.1Qbv] 1872 4. reliability, hence, can be integrated with FRER [IEEE802.1CB] 1873 Figure 10 shows an illustration of 5G-TSN integration where an 1874 industrial controller (Ind Ctrlr) is connected to industrial Input/ 1875 Output devices (I/O dev) via 5G. The 5GS can directly transport 1876 Ethernet frames since Release 15, thus, end-to-end Ethernet 1877 connectivity is provided. The 5GS implements the required interfaces 1878 towards the TSN controller functions such as the CNC, thus adapts to 1879 the settings of the TSN network. A 5G user plane virtual bridge 1880 interconnects TSN bridges or connect end stations, e.g., I/O devices 1881 to the network. Note that the introduction of 5G brings flexibility 1882 in various aspects, e.g., more flexible network topology because a 1883 wireless hop can replace several wireline hops thus significantly 1884 reduce the number of hops end-to-end. [ETR5GTSN] dives more into the 1885 integration of 5G with TSN. 1887 +------------------------------+ 1888 | 5G System | 1889 | +---+| 1890 | +-+ +-+ +-+ +-+ +-+ |TSN|| 1891 | | | | | | | | | | | |AF |......+ 1892 | +++ +++ +++ +++ +++ +-+-+| . 1893 | | | | | | | | . 1894 | -+---+---++--+-+-+--+-+- | . 1895 | | | | | | +--+--+ 1896 | +++ +++ +++ +++ | | TSN | 1897 | | | | | | | | | | |Ctrlr+.......+ 1898 | +++ +++ +++ +++ | +--+--+ . 1899 | | . . 1900 | | . . 1901 | +..........................+ | . . 1902 | . Virtual Bridge . | . . 1903 +---+ | . +--+--+ +---+ +---+--+ . | +--+---+ . 1904 |I/O+----------------+DS|UE+---+RAN+-+UPF|NW+------+ TSN +----+ . 1905 |dev| | . |TT| | | | | |TT| . | |bridge| | . 1906 +---+ | . +--+--+ +---+ +---+--+ . | +------+ | . 1907 | +..........................+ | . +-+-+-+ 1908 | | . | Ind | 1909 | +..........................+ | . |Ctrlr| 1910 | . Virtual Bridge . | . +-+---+ 1911 +---+ +------+ | . +--+--+ +---+ +---+--+ . | +--+---+ | 1912 |I/O+--+ TSN +------+DS|UE+---+RAN+-+UPF|NW+------+ TSN +----+ 1913 |dev| |bridge| | . |TT| | | | | |TT| . | |bridge| 1914 +---+ +------+ | . +--+--+ +---+ +---+--+ . | +------+ 1915 | +..........................+ | 1916 +------------------------------+ 1918 <----------------- end-to-end Ethernet -------------------> 1920 Figure 11: 5G - TSN Integration 1922 NR supports accurate reference time synchronization in 1us accuracy 1923 level. Since NR is a scheduled system, an NR UE and a gNB are 1924 tightly synchronized to their OFDM symbol structures. A 5G internal 1925 reference time can be provided to the UE via broadcast or unicast 1926 signaling, associating a known OFDM symbol to this reference clock. 1927 The 5G internal reference time can be shared within the 5G network, 1928 i.e., radio and core network components. For the interworking with 1929 gPTP for multiple time domains, the 5GS acts as a virtual gPTP time- 1930 aware system and supports the forwarding of gPTP time synchronization 1931 information between end stations and bridges through the 5G user 1932 plane TTs. These account for the residence time of the 5GS in the 1933 time synchronization procedure. One special option is when the 5GS 1934 internal reference time in not only used within the 5GS, but also to 1935 the rest of the devices in the deployment, including connected TSN 1936 bridges and end stations. 1938 Redundancy architectures were specified in order to provide 1939 reliability against any kind of failure on the radio link or nodes in 1940 the RAN and the core network, Redundant user plane paths can be 1941 provided based on the dual connectivity architecture, where the UE 1942 sets up two PDU sessions towards the same data network, and the 5G 1943 system makes the paths of the two PDU sessions independent as 1944 illustrated in Figure 13. There are two PDU sessions involved in the 1945 solution: the first spans from the UE via gNB1 to UPF1, acting as the 1946 first PDU session anchor, while the second spans from the UE via gNB2 1947 to UPF2, acting as second the PDU session anchor. The independent 1948 paths may continue beyond the 3GPP network. Redundancy Handling 1949 Functions (RHFs) are deployed outside of the 5GS, i.e., in Host A 1950 (the device) and in Host B (the network). RHF can implement 1951 replication and elimination functions as per [IEEE802.1CB] or the 1952 Packet Replication, Elimination, and Ordering Functions (PREOF) of 1953 IETF Deterministic Networking (DetNet) [RFC8655]. 1955 +........+ 1956 . Device . +------+ +------+ +------+ 1957 . . + gNB1 +--N3--+ UPF1 |--N6--+ | 1958 . ./+------+ +------+ | | 1959 . +----+ / | | 1960 . | |/. | | 1961 . | UE + . | DN | 1962 . | |\. | | 1963 . +----+ \ | | 1964 . .\+------+ +------+ | | 1965 +........+ + gNB2 +--N3--+ UPF2 |--N6--+ | 1966 +------+ +------+ +------+ 1968 Figure 12: Reliability with Single UE 1970 An alternative solution is that multiple UEs per device are used for 1971 user plane redundancy as illustrated in Figure 13. Each UE sets up a 1972 PDU session. The 5GS ensures that those PDU sessions of the 1973 different UEs are handled independently internal to the 5GS. There 1974 is no single point of failure in this solution, which also includes 1975 RHF outside of the 5G system, e.g., as per FRER or as PREOF 1976 specifications. 1978 +.........+ 1979 . Device . 1980 . . 1981 . +----+ . +------+ +------+ +------+ 1982 . | UE +-----+ gNB1 +--N3--+ UPF1 |--N6--+ | 1983 . +----+ . +------+ +------+ | | 1984 . . | DN | 1985 . +----+ . +------+ +------+ | | 1986 . | UE +-----+ gNB2 +--N3--+ UPF2 |--N6--+ | 1987 . +----+ . +------+ +------+ +------+ 1988 . . 1989 +.........+ 1991 Figure 13: Reliability with Dual UE 1993 Note that the abstraction provided by the RHF and the location of the 1994 RHF being outside of the 5G system make 5G equally supporting 1995 integration for reliability both with FRER of TSN and PREOF of DetNet 1996 as they both rely on the same concept. 1998 Note also that TSN is the primary subnetwork technology for DetNet. 1999 Thus, the DetNet over TSN work, e.g., [I-D.ietf-detnet-ip-over-tsn], 2000 can be leveraged via the TSN support built in 5G. 2002 6.5. Summary 2004 5G technology enables deterministic communication. Based on the 2005 centralized admission control and the scheduling of the wireless 2006 resources, licensed or unlicensed, quality of service such as latency 2007 and reliability can be guaranteed. 5G contains several features to 2008 achieve ultra-reliable and low latency performance, e.g., support for 2009 different OFDM numerologies and slot-durations, as well as fast 2010 processing capabilities and redundancy techniques that lead to 2011 achievable latency numbers of below 1ms with reliability guarantees 2012 up to 99.999%. 2014 5G also includes features to support Industrial IoT use cases, e.g., 2015 via the integration of 5G with TSN. This includes 5G capabilities 2016 for each TSN component, latency, resource management, time 2017 synchronization, and reliability. Furthermore, 5G support for TSN 2018 can be leveraged when 5G is used as subnet technology for DetNet, in 2019 combination with or instead of TSN, which is the primary subnet for 2020 DetNet. In addition, the support for integration with TSN 2021 reliability was added to 5G by making DetNet reliability also 2022 applicable, thus making 5G DetNet ready. Moreover, providing IP 2023 service is native to 5G. 2025 Overall, 5G provides scheduled wireless segments with high 2026 reliability and availability. In addition, 5G includes capabilities 2027 for integration to IP networks. 2029 7. L-band Digital Aeronautical Communications System 2031 One of the main pillars of the modern Air Traffic Management (ATM) 2032 system is the existence of a communication infrastructure that 2033 enables efficient aircraft guidance and safe separation in all phases 2034 of flight. Although current systems are technically mature, they are 2035 suffering from the VHF band's increasing saturation in high-density 2036 areas and the limitations posed by analogue radio. Therefore, 2037 aviation globally and the European Union (EU) in particular, strives 2038 for a sustainable modernization of the aeronautical communication 2039 infrastructure. 2041 In the long-term, ATM communication shall transition from analogue 2042 VHF voice and VDL2 communication to more spectrum efficient digital 2043 data communication. The European ATM Master Plan foresees this 2044 transition to be realized for terrestrial communications by the 2045 development and implementation of the L-band Digital Aeronautical 2046 Communications System (LDACS). LDACS shall enable IPv6 based air- 2047 ground communication related to the safety and regularity of the 2048 flight. The particular challenge is that no new frequencies can be 2049 made available for terrestrial aeronautical communication. It was 2050 thus necessary to develop procedures to enable the operation of LDACS 2051 in parallel with other services in the same frequency band. 2053 7.1. Provenance and Documents 2055 The development of LDACS has already made substantial progress in the 2056 Single European Sky ATM Research (SESAR) framework, and is currently 2057 being continued in the follow-up program, SESAR2020 [RIH18]. A key 2058 objective of the SESAR activities is to develop, implement and 2059 validate a modern aeronautical data link able to evolve with aviation 2060 needs over long-term. To this end, an LDACS specification has been 2061 produced [GRA19] and is continuously updated; transmitter 2062 demonstrators were developed to test the spectrum compatibility of 2063 LDACS with legacy systems operating in the L-band [SAJ14]; and the 2064 overall system performance was analyzed by computer simulations, 2065 indicating that LDACS can fulfil the identified requirements [GRA11]. 2067 LDACS standardization within the framework of the International Civil 2068 Aviation Organization (ICAO) started in December 2016. The ICAO 2069 standardization group has produced an initial Standards and 2070 Recommended Practices (SARPs) document [ICAO18]. The SARPs document 2071 defines the general characteristics of LDACS. The ICAO 2072 standardization group plans to produce an ICAO technical manual - the 2073 ICAO equivalent to a technical standard - within the next years. 2074 Generally, the group is open to input from all sources and develops 2075 LDACS in the open. 2077 Up to now the LDACS standardization has been focused on the 2078 development of the physical layer and the data link layer, only 2079 recently have higher layers come into the focus of the LDACS 2080 development activities. There is currently no "IPv6 over LDACS" 2081 specification; however, SESAR2020 has started the testing of 2082 IPv6-based LDACS testbeds. The IPv6 architecture for the 2083 aeronautical telecommunication network is called the Future 2084 Communications Infrastructure (FCI). FCI shall support quality of 2085 service, diversity, and mobility under the umbrella of the "multi- 2086 link concept". This work is conducted by ICAO working group WG-I. 2088 In addition to standardization activities several industrial LDACS 2089 prototypes have been built. One set of LDACS prototypes has been 2090 evaluated in flight trials confirming the theoretical results 2091 predicting the system performance [GRA18][SCH19]. 2093 7.2. General Characteristics 2095 LDACS will become one of several wireless access networks connecting 2096 aircraft to the Aeronautical Telecommunications Network (ATN). The 2097 LDACS access network contains several ground stations, each of them 2098 providing one LDACS radio cell. The LDACS air interface is a 2099 cellular data link with a star-topology connecting aircraft to 2100 ground-stations with a full duplex radio link. Each ground-station 2101 is the centralized instance controlling all air-ground communications 2102 within its radio cell. A ground-station supports up to 512 aircraft. 2104 The LDACS air interface protocol stack defines two layers, the 2105 physical layer and the data link layer. 2107 The physical layer provides the means to transfer data over the radio 2108 channel. The LDACS ground-station supports bi-directional links to 2109 multiple aircraft under its control. The forward link direction (FL; 2110 ground-to-air) and the reverse link direction (RL; air-to-ground) are 2111 separated by frequency division duplex. Forward link and reverse 2112 link use a 500 kHz channel each. The ground-station transmits a 2113 continuous stream of OFDM symbols on the forward link. In the 2114 reverse link different aircraft are separated in time and frequency 2115 using a combination of Orthogonal Frequency-Division Multiple-Access 2116 (OFDMA) and Time-Division Multiple-Access (TDMA). Aircraft thus 2117 transmit discontinuously on the reverse link with radio bursts sent 2118 in precisely defined transmission opportunities allocated by the 2119 ground-station. LDACS does not support beam-forming or Multiple 2120 Input Multiple Output (MIMO). 2122 The data-link layer provides the necessary protocols to facilitate 2123 concurrent and reliable data transfer for multiple users. The LDACS 2124 data link layer is organized in two sub-layers: The medium access 2125 sub-layer and the logical link control sub-layer. The medium access 2126 sub-layer manages the organization of transmission opportunities in 2127 slots of time and frequency. The logical link control sub-layer 2128 provides acknowledged point-to-point logical channels between the 2129 aircraft and the ground-station using an automatic repeat request 2130 protocol. LDACS supports also unacknowledged point-to-point channels 2131 and ground-to-air broadcast. 2133 The user data rate of LDACS is 315 kbit/s to 1428 kbit/s on the 2134 forward link, and 294 kbit/s to 1390 kbit/s on the reverse link, 2135 depending on coding and modulation. Due to strong interference from 2136 legacy systems in the L-band, the most robust coding and modulation 2137 should be expected for initial deployment i.e. 315/294 kbit/s on the 2138 forward/reverse link, respectively. 2140 Since LDACS has been mainly designed for air traffic management 2141 communication it supports mutual entity authentication, integrity and 2142 confidentiality capabilities of user data messages and some control 2143 channel protection capabilities [MAE19]. 2145 7.3. Applicability to Deterministic Flows 2147 LDACS has been designed with applications related to the safety and 2148 regularity of the flight in mind. It has therefore been designed as 2149 a deterministic wireless data link (as far as possible). 2151 LDACS medium access is always under the control of the ground-station 2152 of a radio cell. Any medium access for the transmission of user data 2153 has to be requested with a resource request message stating the 2154 requested amount of resources and class of service. The ground- 2155 station performs resource scheduling on the basis of these requests 2156 and grants resources with resource allocation messages. Resource 2157 request and allocation messages are exchanged over dedicated 2158 contention-free control channels. 2160 LDACS has two mechanisms to request resources from the scheduler in 2161 the ground-station. Resources can either be requested "on demand" 2162 with a given class of service. On the forward link, this is done 2163 locally in the ground-station, on the reverse link a dedicated 2164 contention-free control channel is used (Dedicated Control Channel 2165 (DCCH); roughly 83 bit every 60 ms). A resource allocation is always 2166 announced in the control channel of the forward link (Common Control 2167 Channel (CCCH); variable sized). Due to the spacing of the reverse 2168 link control channels of every 60 ms, a medium access delay in the 2169 same order of magnitude is to be expected. 2171 Resources can also be requested "permanently". The permanent 2172 resource request mechanism supports requesting recurring resources in 2173 given time intervals. A permanent resource request has to be 2174 canceled by the user (or by the ground-station, which is always in 2175 control). User data transmissions over LDACS are therefore always 2176 scheduled by the ground-station, while control data uses statically 2177 (i.e. at net entry) allocated recurring resources (DCCH and CCCH). 2178 The current specification documents specify no scheduling algorithm. 2179 However performance evaluations so far have used strict priority 2180 scheduling and round robin for equal priorities for simplicity. In 2181 the current prototype implementations LDACS classes of service are 2182 thus realized as priorities of medium access and not as flows. Note 2183 that this can starve out low priority flows. However, this is not 2184 seen as a big problem since safety related message always go first in 2185 any case. Scheduling of reverse link resources is done in physical 2186 Protocol Data Units (PDU) of 112 bit (or larger if more aggressive 2187 coding and modulation is used). Scheduling on the forward link is 2188 done Byte-wise since the forward link is transmitted continuously by 2189 the ground-station. 2191 In order to support diversity, LDACS supports handovers to other 2192 ground-stations on different channels. Handovers may be initiated by 2193 the aircraft (break-before-make) or by the ground-station (make- 2194 before-break) if it is connected to an alternative ground-station via 2195 the same ground-station controller. Beyond this, FCI diversity shall 2196 be implemented by the multi-link concept. 2198 8. IANA Considerations 2200 This specification does not require IANA action. 2202 9. Security Considerations 2204 Most RAW technologies integrate some authentication or encryption 2205 mechanisms that were defined outside the IETF. 2207 10. Contributors 2209 Georgios Z. Papadopoulos: Contributed to the TSCH section. 2211 Nils Mäurer: Contributed to the LDACS section. 2213 Thomas Gräupl: Contributed to the LDACS section. 2215 Janos Farkas, Torsten Dudda, Alexey Shapin, and Sara Sandberg: 2216 Contributed to the 5G section. 2218 11. Acknowledgments 2220 Many thanks to the participants of the RAW WG where a lot of the work 2221 discussed here happened. 2223 12. Normative References 2225 [RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH 2226 Operation Sublayer (6top) Protocol (6P)", RFC 8480, 2227 DOI 10.17487/RFC8480, November 2018, 2228 . 2230 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2231 (IPv6) Specification", STD 86, RFC 8200, 2232 DOI 10.17487/RFC8200, July 2017, 2233 . 2235 [RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T. 2236 Phinney, "Industrial Routing Requirements in Low-Power and 2237 Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October 2238 2009, . 2240 [I-D.ietf-detnet-architecture] 2241 Finn, N., Thubert, P., Varga, B., and J. Farkas, 2242 "Deterministic Networking Architecture", Work in Progress, 2243 Internet-Draft, draft-ietf-detnet-architecture-13, 6 May 2244 2019, . 2247 [I-D.ietf-6tisch-architecture] 2248 Thubert, P., "An Architecture for IPv6 over the TSCH mode 2249 of IEEE 802.15.4", Work in Progress, Internet-Draft, 2250 draft-ietf-6tisch-architecture-28, 29 October 2019, 2251 . 2254 13. Informative References 2256 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 2257 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 2258 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 2259 Low-Power and Lossy Networks", RFC 6550, 2260 DOI 10.17487/RFC6550, March 2012, 2261 . 2263 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 2264 and D. Barthel, "Routing Metrics Used for Path Calculation 2265 in Low-Power and Lossy Networks", RFC 6551, 2266 DOI 10.17487/RFC6551, March 2012, 2267 . 2269 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 2270 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 2271 Acronym in the IETF", BCP 161, RFC 6291, 2272 DOI 10.17487/RFC6291, June 2011, 2273 . 2275 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 2276 Weingarten, "An Overview of Operations, Administration, 2277 and Maintenance (OAM) Tools", RFC 7276, 2278 DOI 10.17487/RFC7276, June 2014, 2279 . 2281 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 2282 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 2283 Explicit Replication (BIER)", RFC 8279, 2284 DOI 10.17487/RFC8279, November 2017, 2285 . 2287 [I-D.ietf-6tisch-msf] 2288 Chang, T., Vucinic, M., Vilajosana, X., Duquennoy, S., and 2289 D. Dujovne, "6TiSCH Minimal Scheduling Function (MSF)", 2290 Work in Progress, Internet-Draft, draft-ietf-6tisch-msf- 2291 16, 2 April 2020, 2292 . 2294 [I-D.pthubert-raw-architecture] 2295 Thubert, P. and G. Papadopoulos, "Reliable and Available 2296 Wireless Architecture/Framework", Work in Progress, 2297 Internet-Draft, draft-pthubert-raw-architecture-01, 2 2298 April 2020, . 2301 [I-D.ietf-roll-nsa-extension] 2302 Koutsiamanis, R., Papadopoulos, G., Montavont, N., and P. 2303 Thubert, "Common Ancestor Objective Function and Parent 2304 Set DAG Metric Container Extension", Work in Progress, 2305 Internet-Draft, draft-ietf-roll-nsa-extension-08, 27 March 2306 2020, . 2309 [I-D.papadopoulos-paw-pre-reqs] 2310 Papadopoulos, G., Koutsiamanis, R., Montavont, N., and P. 2311 Thubert, "Exploiting Packet Replication and Elimination in 2312 Complex Tracks in LLNs", Work in Progress, Internet-Draft, 2313 draft-papadopoulos-paw-pre-reqs-01, 25 March 2019, 2314 . 2317 [I-D.thubert-bier-replication-elimination] 2318 Thubert, P., Eckert, T., Brodard, Z., and H. Jiang, "BIER- 2319 TE extensions for Packet Replication and Elimination 2320 Function (PREF) and OAM", Work in Progress, Internet- 2321 Draft, draft-thubert-bier-replication-elimination-03, 3 2322 March 2018, . 2325 [I-D.thubert-6lo-bier-dispatch] 2326 Thubert, P., Brodard, Z., Jiang, H., and G. Texier, "A 2327 6loRH for BitStrings", Work in Progress, Internet-Draft, 2328 draft-thubert-6lo-bier-dispatch-06, 28 January 2019, 2329 . 2332 [I-D.ietf-bier-te-arch] 2333 Eckert, T., Cauchie, G., and M. Menth, "Tree Engineering 2334 for Bit Index Explicit Replication (BIER-TE)", Work in 2335 Progress, Internet-Draft, draft-ietf-bier-te-arch-07, 9 2336 March 2020, 2337 . 2339 [I-D.ietf-6tisch-coap] 2340 Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and 2341 Interaction using CoAP", Work in Progress, Internet-Draft, 2342 draft-ietf-6tisch-coap-03, 9 March 2015, 2343 . 2345 [I-D.svshah-tsvwg-deterministic-forwarding] 2346 Shah, S. and P. Thubert, "Deterministic Forwarding PHB", 2347 Work in Progress, Internet-Draft, draft-svshah-tsvwg- 2348 deterministic-forwarding-04, 30 August 2015, 2349 . 2352 [IEEE Std. 802.15.4] 2353 IEEE standard for Information Technology, "IEEE Std. 2354 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 2355 and Physical Layer (PHY) Specifications for Low-Rate 2356 Wireless Personal Area Networks". 2358 [IEEE Std. 802.11] 2359 "IEEE Standard 802.11 - IEEE Standard for Information 2360 Technology - Telecommunications and information exchange 2361 between systems Local and metropolitan area networks - 2362 Specific requirements - Part 11: Wireless LAN Medium 2363 Access Control (MAC) and Physical Layer (PHY) 2364 Specifications.". 2366 [IEEE Std. 802.11ak] 2367 "802.11ak: Enhancements for Transit Links Within Bridged 2368 Networks", 2017. 2370 [IEEE Std. 802.11ax] 2371 "802.11ax D4.0: Enhancements for High Efficiency WLAN". 2373 [IEEE Std. 802.11ay] 2374 "802.11ay: Enhanced throughput for operation in license- 2375 exempt bands above 45 GHz". 2377 [IEEE Std. 802.11ad] 2378 "802.11ad: Enhancements for very high throughput in the 60 2379 GHz band". 2381 [IEEE 802.11be WIP] 2382 "802.11be: Extreme High Throughput". 2384 [IEEE Std. 802.1Qat] 2385 "802.1Qat: Stream Reservation Protocol". 2387 [IEEE8021Qcc] 2388 "802.1Qcc: IEEE Standard for Local and Metropolitan Area 2389 Networks--Bridges and Bridged Networks -- Amendment 31: 2390 Stream Reservation Protocol (SRP) Enhancements and 2391 Performance Improvements". 2393 [Cavalcanti_2019] 2394 Dave Cavalcanti et al., "Extending Time Distribution and 2395 Timeliness Capabilities over the Air to Enable Future 2396 Wireless Industrial Automation Systems, the Proceedings of 2397 IEEE", June 2019. 2399 [Nitsche_2015] 2400 Thomas Nitsche et al., "IEEE 802.11ad: directional 60 GHz 2401 communication for multi-Gigabit-per-second Wi-Fi", 2402 December 2014. 2404 [Ghasempour_2017] 2405 Yasaman Ghasempour et al., "802.11ay: Next-Generation 60 2406 GHz Communications for 100 Gb/s Wi-Fi", December 2017. 2408 [IEEE_doc_11-18-2009-06] 2409 "802.11 Real-Time Applications (RTA) Topic Interest Group 2410 (TIG) Report", November 2018. 2412 [IEEE_doc_11-19-0373-00] 2413 Kevin Stanton et Al., "Time-Sensitive Applications Support 2414 in EHT", March 2019. 2416 [morell13] Antoni Morell et al., "Label switching over IEEE802.15.4e 2417 networks", April 2013. 2419 [dearmas16] 2420 Jesica de Armas et al., "Determinism through path 2421 diversity: Why packet replication makes sense", September 2422 2016. 2424 [vilajosana19] 2425 Xavier Vilajosana et al., "6TiSCH: Industrial Performance 2426 for IPv6 Internet-of-Things Networks", June 2019. 2428 [ISA100.11a] 2429 ISA/IEC, "ISA100.11a, Wireless Systems for Automation, 2430 also IEC 62734", 2011, . 2434 [WirelessHART] 2435 www.hartcomm.org, "Industrial Communication Networks - 2436 Wireless Communication Network and Communication Profiles 2437 - WirelessHART - IEC 62591", 2010. 2439 [PCE] IETF, "Path Computation Element", 2440 . 2442 [CCAMP] IETF, "Common Control and Measurement Plane", 2443 . 2445 [TiSCH] IETF, "IPv6 over the TSCH mode over 802.15.4", 2446 . 2448 [RIH18] Rihacek, C., Haindl, B., Fantappie, P., Pierattelli, S., 2449 Gräupl, T., Schnell, M., and N. Fistas, "L-band Digital 2450 Aeronautical Communications System (LDACS) Activities in 2451 SESAR2020", Proceedings of the Integrated Communications 2452 Navigation and Surveillance Conference (ICNS) Herndon, VA, 2453 USA, April 2018. 2455 [GRA19] Gräupl, T., Rihacek, C., and B. Haindl, "LDACS A/G 2456 Specification", SESAR2020 PJ14-02-01 D3.3.010, February 2457 2019. 2459 [SAJ14] Sajatovic, M., Günzel, H., and S. Müller, "WA04 D22 Test 2460 Report for Assessing LDACS1 Transmitter Impact upon DME/ 2461 TACAN Receivers", April 2014. 2463 [GRA11] Gräupl, T. and M. Ehammer, "L-DACS1 Data Link Layer 2464 Evolution of ATN/IPS", Proceedings of the 30th IEEE/AIAA 2465 Digital Avionics Systems Conference (DASC) Seattle, WA, 2466 USA, October 2011. 2468 [ICAO18] International Civil Aviation Organization (ICAO), "L-Band 2469 Digital Aeronautical Communication System (LDACS)", 2470 International Standards and Recommended Practices Annex 10 2471 - Aeronautical Telecommunications, Vol. III - 2472 Communication Systems, July 2018. 2474 [GRA18] al., T. G. E., "L-band Digital Aeronautical Communications 2475 System (LDACS) flight trials in the national German 2476 project MICONAV", Proceedings of the Integrated 2477 Communications, Navigation, Surveillance Conference 2478 (ICNS) Herndon, VA, USA, April 2018. 2480 [SCH19] Schnell, M., "DLR tests digital communications 2481 technologies combined with additional navigation functions 2482 for the first time", 3 March 2019, 2483 . 2486 [MAE19] Mäurer, N. and C. Schmitt, "DLR tests digital 2487 communications technologies combined with additional 2488 navigation functions for the first time", Proceedings of 2489 the Integrated Communications, Navigation, Surveillance 2490 Conference (ICNS) Washington D.C., USA, April 2019. 2492 [TR37910] "3GPP TR 37.910, Study on self evaluation towards IMT-2020 2493 submission", 2494 . 2497 [TR38824] "3GPP TR 38.824, Study on physical layer enhancements for 2498 NR ultra-reliable and low latency case (URLLC)", 2499 . 2502 [TR38825] "3GPP TR 38.825, Study on NR industrial Internet of Things 2503 (IoT)", 2504 . 2507 [TS22104] "3GPP TS 22.104, Service requirements for cyber-physical 2508 control applications in vertical domains", 2509 . 2512 [TR22804] "3GPP TR 22.804, Study on Communication for Automation in 2513 Vertical domains (CAV)", 2514 . 2517 [TS23501] "3GPP TS 23.501, System architecture for the 5G System 2518 (5GS)", 2519 . 2522 [TS38300] "3GPP TS 38.300, NR Overall description", 2523 . 2526 [IMT2020] "ITU towards IMT for 2020 and beyond", 2527 . 2530 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 2531 "Deterministic Networking Architecture", RFC 8655, 2532 DOI 10.17487/RFC8655, October 2019, 2533 . 2535 [I-D.ietf-detnet-ip-over-tsn] 2536 Varga, B., Farkas, J., Malis, A., and S. Bryant, "DetNet 2537 Data Plane: IP over IEEE 802.1 Time Sensitive Networking 2538 (TSN)", Work in Progress, Internet-Draft, draft-ietf- 2539 detnet-ip-over-tsn-02, 6 March 2020, 2540 . 2543 [IEEE802.1TSN] 2544 IEEE 802.1, "Time-Sensitive Networking (TSN) Task Group", 2545 . 2547 [IEEE802.1AS] 2548 IEEE, "IEEE Standard for Local and metropolitan area 2549 networks -- Timing and Synchronization for Time-Sensitive 2550 Applications", IEEE 802.1AS-2020, 2551 . 2554 [IEEE802.1CB] 2555 IEEE, "IEEE Standard for Local and metropolitan area 2556 networks -- Frame Replication and Elimination for 2557 Reliability", DOI 10.1109/IEEESTD.2017.8091139, IEEE 2558 802.1CB-2017, 2559 . 2561 [IEEE802.1Qbv] 2562 IEEE, "IEEE Standard for Local and metropolitan area 2563 networks -- Bridges and Bridged Networks -- Amendment 25: 2564 Enhancements for Scheduled Traffic", IEEE 802.1Qbv-2015, 2565 . 2567 [IEEE802.1Qcc] 2568 IEEE, "IEEE Standard for Local and metropolitan area 2569 networks -- Bridges and Bridged Networks -- Amendment 31: 2570 Stream Reservation Protocol (SRP) Enhancements and 2571 Performance Improvements", IEEE 802.1Qcc-2018, 2572 . 2574 [IEEE802.3] 2575 IEEE, "IEEE Standard for Ethernet", IEEE 802.3-2018, 2576 . 2578 [ETR5GTSN] Farkas, J., Varga, B., Miklos, G., and J. Sachs, "5G-TSN 2579 integration meets networking requirements for industrial 2580 automation", Ericsson Technology Review, Volume 9, No 7, 2581 August 2019, . 2585 Authors' Addresses 2587 Pascal Thubert (editor) 2588 Cisco Systems, Inc 2589 Building D 2590 45 Allee des Ormes - BP1200 2591 06254 MOUGINS - Sophia Antipolis 2592 France 2594 Phone: +33 497 23 26 34 2595 Email: pthubert@cisco.com 2597 Dave Cavalcanti 2598 Intel Corporation 2599 2111 NE 25th Ave 2600 Hillsboro, OR, 97124 2601 United States of America 2603 Phone: 503 712 5566 2604 Email: dave.cavalcanti@intel.com 2606 Xavier Vilajosana 2607 Universitat Oberta de Catalunya 2608 156 Rambla Poblenou 2609 08018 Barcelona Catalonia 2610 Spain 2612 Email: xvilajosana@uoc.edu 2614 Corinna Schmitt 2615 Research Institute CODE, UniBwM 2616 Werner-Heisenberg-Weg 28 2617 85577 Neubiberg 2618 Germany 2620 Email: corinna.schmitt@unibw.de 2622 Janos Farkas 2623 Ericsson 2624 Budapest 2625 Magyar tudosok korutja 11 2626 1117 2627 Hungary 2629 Email: janos.farkas@ericsson.com