| < draft-thubert-raw-technologies-00.txt | draft-thubert-raw-technologies-01.txt > | |||
|---|---|---|---|---|
| RAW P. Thubert, Ed. | RAW P. Thubert, Ed. | |||
| Internet-Draft Cisco Systems | Internet-Draft Cisco Systems | |||
| Intended status: Informational May 21, 2019 | Intended status: Informational D. Cavalcanti | |||
| Expires: November 22, 2019 | Expires: December 8, 2019 Intel | |||
| X. Vilajosana | ||||
| Universitat Oberta de Catalunya | ||||
| June 6, 2019 | ||||
| Reliable and Available Wireless Technologies | Reliable and Available Wireless Technologies | |||
| draft-thubert-raw-technologies-00 | draft-thubert-raw-technologies-01 | |||
| Abstract | Abstract | |||
| This document presents a series of recent technologies that are | This document presents a series of recent technologies that are | |||
| capable of time synchronization and scheduling of transmission, | capable of time synchronization and scheduling of transmission, | |||
| making them suitable to carry time-sensitive flows with requirements | making them suitable to carry time-sensitive flows with requirements | |||
| of both reliable delivery in bounded time, and availability at all | of both reliable delivery in bounded time, and availability at all | |||
| times, regardless of packet transmission or individual equipement | times, regardless of packet transmission or individual equipement | |||
| failures. | failures. | |||
| skipping to change at page 1, line 35 ¶ | skipping to change at page 1, line 38 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on November 22, 2019. | This Internet-Draft will expire on December 8, 2019. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2019 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | described in the Simplified BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 3. On Scheduling . . . . . . . . . . . . . . . . . . . . . . . . 3 | 3. On Scheduling . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 3.1. Benefits of Scheduling on Wires . . . . . . . . . . . . . 4 | 3.1. Benefits of Scheduling on Wires . . . . . . . . . . . . . 4 | |||
| 3.2. Benefits of Scheduling on Wireless . . . . . . . . . . . 4 | 3.2. Benefits of Scheduling on Wireless . . . . . . . . . . . 4 | |||
| 4. tech X . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 4. IEEE 802 standards . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 4.1. Provenance and Documents . . . . . . . . . . . . . . . . 5 | 4.1. IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 4.2. General Characteristics . . . . . . . . . . . . . . . . . 5 | 4.1.1. Provenance and Documents . . . . . . . . . . . . . . 5 | |||
| 4.3. Applicability to deterministic flows . . . . . . . . . . 5 | 4.1.2. 802.11ax High Efficiency (HE) . . . . . . . . . . . . 7 | |||
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 | 4.1.3. 802.11be Extreme High Throughput (EHT) . . . . . . . 10 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 | 4.1.4. 802.11ad and 802.11ay (mmWave operation) . . . . . . 11 | |||
| 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 | 4.2. IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 4.2.1. Provenance and Documents . . . . . . . . . . . . . . 12 | |||
| 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 | 4.2.2. TimeSlotted Channel Hopping . . . . . . . . . . . . . 14 | |||
| 8.2. Informative References . . . . . . . . . . . . . . . . . 6 | 5. 3GPP standards . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | ||||
| 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 | ||||
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 | ||||
| 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 | ||||
| 9.2. Informative References . . . . . . . . . . . . . . . . . 17 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 | ||||
| 1. Introduction | 1. Introduction | |||
| When used in math or philosophy, the term "deterministic" generally | When used in math or philosophy, the term "deterministic" generally | |||
| refers to a perfection where all aspect are understood and | refers to a perfection where all aspect are understood and | |||
| predictable. A perfectly Deterministic Network would ensure that | predictable. A perfectly Deterministic Network would ensure that | |||
| every packet reach its destination following a predetermined path | every packet reach its destination following a predetermined path | |||
| along a predefined schedule to be delivered at the exact due time. | along a predefined schedule to be delivered at the exact due time. | |||
| In a real and imperfect world, a Deterministic Network must highly | In a real and imperfect world, a Deterministic Network must highly | |||
| predictable, which is a combination of reliability and availability. | predictable, which is a combination of reliability and availability. | |||
| On the one hand the network must be reliable, meaning that it will | On the one hand the network must be reliable, meaning that it will | |||
| perform as expected for all packets and in particular that it will | perform as expected for all packets and in particular that it will | |||
| always deliver the packet at the destination in due time. On the | always deliver the packet at the destination in due time. On the | |||
| other hand, the network must be available, meaning that it is | other hand, the network must be available, meaning that it is | |||
| resilient to any single outage, whether the cause is a software, a | resilient to any single outage, whether the cause is a software, a | |||
| hardware or a transmission issue. | hardware or a transmission issue. | |||
| RAW (Reliable and Available Wireless) is an effort to provide | RAW (Reliable and Available Wireless) is an effort to provide | |||
| Deterministic Networking on across a path that include a a wireless | Deterministic Networking on across a path that include a wireless | |||
| physical layer. Making Wireless Reliable and Available is even more | physical layer. Making Wireless Reliable and Available is even more | |||
| challenging than it is with wires, due to the numerous causes of loss | challenging than it is with wires, due to the numerous causes of loss | |||
| in transmission that add up to the congestion losses and the delays | in transmission that add up to the congestion losses and the delays | |||
| caused by overbooked shared resources. In order to maintain a | caused by overbooked shared resources. In order to maintain a | |||
| similar quality of service along a multihop path that is composed of | similar quality of service along a multihop path that is composed of | |||
| wired and wireless hops, additional methods that are specific to | wired and wireless hops, additional methods that are specific to | |||
| wireless must be leveraged to combat the sources of loss that are | wireless must be leveraged to combat the sources of loss that are | |||
| also specific to wireless. | also specific to wireless. | |||
| Such wireless-specific methods include per-hop retransmissions (HARQ) | Such wireless-specific methods include per-hop retransmissions (HARQ) | |||
| and P2MP overhearing whereby multiple receivers are scheduled to | and P2MP overhearing whereby multiple receivers are scheduled to | |||
| receive the same transmission, which balances the adverse effects of | receive the same transmission, which balances the adverse effects of | |||
| the transmission losses that are eperienced when a radio is used as | the transmission losses that are experienced when a radio is used as | |||
| pure P2P. | pure P2P. | |||
| 2. Terminology | 2. Terminology | |||
| This specification uses a number of terms that are uncommon on | This specification uses several terms that are uncommon on protocols | |||
| protocols that ensure bets effort transmissions for stochastics | that ensure bets effort transmissions for stochastics flows, such as | |||
| flows, such as found in the traditional Internet and other | found in the traditional Internet and other statistically multiplexed | |||
| statistically multiplexed packet networks. | packet networks. | |||
| Reliable: That consistently performs as expected, the expectation | Reliable: That consistently performs as expected, the expectation | |||
| for a network being to always deliver a packet in due time. | for a network being to always deliver a packet in due time. | |||
| Available: That is exempt of unscheduled outage, the expectation for | Available: That is exempt of unscheduled outage, the expectation for | |||
| a network being that the flow is maintained in the face of any | a network being that the flow is maintained in the face of any | |||
| single breakage. | single breakage. | |||
| PAREO (functions): the wireless extension of DetNet PREOF. PAREO | PAREO (functions): the wireless extension of DetNet PREOF. PAREO | |||
| functions include scheduled ARQ at selected hops, and expect | functions include scheduled ARQ at selected hops, and expect | |||
| the use of new operations like overhearing where available. | the use of new operations like overhearing where available. | |||
| Track: A DODAG oriented to a destination,and that enables Packet | Track: A DODAG oriented to a destination, and that enables Packet | |||
| ARQ, Replication, Elimination, and Ordering Functions. | ARQ, Replication, Elimination, and Ordering Functions. | |||
| ARQ: Automatic Repeat Request, enabling an acknowledged | ARQ: Automatic Repeat Request, enabling an acknowledged | |||
| transmission, which is the typical model at Layer-2 on a | transmission, which is the typical model at Layer-2 on a | |||
| wireless medium. | wireless medium. | |||
| HARQ: Forward error correction, sending redundant coded data to help | HARQ: Forward error correction, sending redundant coded data to help | |||
| the receiver recover transmission errors. | the receiver recover transmission errors. | |||
| HARQ: Hybrid ARQ, a combination of FEC and ARQ . | HARQ: Hybrid ARQ, a combination of FEC and ARQ. | |||
| 3. On Scheduling | 3. On Scheduling | |||
| The operations of a Deterministic Network often rely on precisely | The operations of a Deterministic Network often rely on precisely | |||
| applying a tight schedule, in order to avoid collision loss and | applying a tight schedule, in order to avoid collision loss and | |||
| guarantee the worst case time of delivery . To achieve this, there | guarantee the worst-case time of delivery. To achieve this, there | |||
| must be a shared sense of time throughout the network. The sense of | must be a shared sense of time throughout the network. The sense of | |||
| time is usually provided by the lower layer and is not in scope for | time is usually provided by the lower layer and is not in scope for | |||
| RAW. | RAW. | |||
| 3.1. Benefits of Scheduling on Wires | 3.1. Benefits of Scheduling on Wires | |||
| A network is reliable when the statistical effects that affect the | A network is reliable when the statistical effects that affect the | |||
| packet transmission are eliminated. This involves maintaining at all | packet transmission are eliminated. This involves maintaining at all | |||
| time the amount of critical packets within the physical capabilities | time the amount of critical packets within the physical capabilities | |||
| of the hardware and that of the radio medium. This is achieved by | of the hardware and that of the radio medium. This is achieved by | |||
| skipping to change at page 4, line 41 ¶ | skipping to change at page 4, line 50 ¶ | |||
| and diverse scheduled transmissions, and in the frequency domain with | and diverse scheduled transmissions, and in the frequency domain with | |||
| frequency hopping or channel hopping between frames. | frequency hopping or channel hopping between frames. | |||
| 3.2. Benefits of Scheduling on Wireless | 3.2. Benefits of Scheduling on Wireless | |||
| In addition to the benefits listed in Section 3.1, scheduling | In addition to the benefits listed in Section 3.1, scheduling | |||
| transmissions provides specific value to the wireless medium. | transmissions provides specific value to the wireless medium. | |||
| On the one hand, scheduling avoids collisions between scheduled | On the one hand, scheduling avoids collisions between scheduled | |||
| transmissions and can ensure both time and frequency diversity | transmissions and can ensure both time and frequency diversity | |||
| between retries in order to defeat co-channel interference from | between retries in order to defeat co-channel interference from un- | |||
| uncontroller transmitters as well as multipath fading. Transmissions | controlled transmitters as well as multipath fading. Transmissions | |||
| can be scheduled on multiple channels in parallel, which enables to | can be scheduled on multiple channels in parallel, which enables to | |||
| use the full available spectrum while avoiding the hidden terminal | use the full available spectrum while avoiding the hidden terminal | |||
| problem, e.g., when the next packet in a same flow interferes on a | problem, e.g., when the next packet in a same flow interferes on a | |||
| same channel with the previous one that progressed a few hops | same channel with the previous one that progressed a few hops | |||
| farther. | farther. | |||
| On the other hand, scheduling optimizes the bandwidth usage: compared | On the other hand, scheduling optimizes the bandwidth usage: compared | |||
| to classical Collision Avoidance techniques, there is no blank time | to classical Collision Avoidance techniques, there is no blank time | |||
| related to inter-frame space (IFS) and exponential back-off in | related to inter-frame space (IFS) and exponential back-off in | |||
| scheduled operations. A minimal Clear Channel Assessment may be | scheduled operations. A minimal Clear Channel Assessment may be | |||
| needed to comply with the local regulations such as ETSI 300-328, but | needed to comply with the local regulations such as ETSI 300-328, but | |||
| that will not detect a collision when the senders are synchronized. | that will not detect a collision when the senders are synchronized. | |||
| And because scheduling allows a time sharing operation, there is no | And because scheduling allows a time-sharing operation, there is no | |||
| limit to the ratio of isolated critical traffic. | limit to the ratio of isolated critical traffic. | |||
| Finally, scheduling plays a critical role to save energy. In IOT, | Finally, scheduling plays a critical role to save energy. In IOT, | |||
| energy is the foremost concern, and synchronizing sender and listener | energy is the foremost concern, and synchronizing sender and listener | |||
| enables to maintain them in deep sleep at all times when there is no | enables to always maintain them in deep sleep when there is no | |||
| scheduled transmission. This avoids idle listening and long | scheduled transmission. This avoids idle listening and long | |||
| preambles and enables long sleep periods between traffic and | preambles and enables long sleep periods between traffic and | |||
| resynchronization, allowing battery-operated nodes to operate in a | resynchronization, allowing battery-operated nodes to operate in a | |||
| mesh topology for multiple years. | mesh topology for multiple years. | |||
| 4. tech X | 4. IEEE 802 standards | |||
| 4.1. Provenance and Documents | With an active portfolio of nearly 1,300 standards and projects under | |||
| development, IEEE is a leading developer of industry standards in a | ||||
| broad range of technologies that drive the functionality, | ||||
| capabilities, and interoperability of products and services, | ||||
| transforming how people live, work, and communicate. | ||||
| 4.2. General Characteristics | The IEEE 802 LAN/MAN Standards Committee (SC) develops and maintains | |||
| networking standards and recommended practices for local, | ||||
| metropolitan, and other area networks, using an open and accredited | ||||
| process, and advocates them on a global basis. The most widely used | ||||
| standards are for Ethernet, Bridging and Virtual Bridged LANs | ||||
| Wireless LAN, Wireless PAN, Wireless MAN, Wireless Coexistence, Media | ||||
| Independent Handover Services, and Wireless RAN. An individual | ||||
| Working Group provides the focus for each area. Standards produced | ||||
| by the IEEE 802 SC are freely available from the IEEE GET Program | ||||
| after they have been published in PDF for six months. | ||||
| 4.3. Applicability to Deterministic Flows | 4.1. IEEE 802.11 | |||
| 5. IANA Considerations | 4.1.1. Provenance and Documents | |||
| The IEEE 802.11 LAN standards define the underlying MAC and PHY | ||||
| layers for the Wi-Fi technology. Wi-Fi/802.11 is one of the most | ||||
| successful wireless technologies, supporting many application | ||||
| domains. While previous 802.11 generations, such as 802.11n and | ||||
| 802.11ac, have focused mainly on improving peak throughput, more | ||||
| recent generations are also considering other performance vectors, | ||||
| such as efficiency enhancements for dense environments in 802.11ax, | ||||
| and latency and support for Time-Sensitive Networking (TSN) | ||||
| capabilities in 802.11be. | ||||
| IEEE 802.11 already supports some 802.1 TSN standards and it is | ||||
| undergoing efforts to support for other 802.1 TSN capabilities | ||||
| required to address the use cases that require time synchronization | ||||
| and timeliness (bounded latency) guarantees with high reliability and | ||||
| availability. The IEEE 802.11 working group has been working in | ||||
| collaboration with the IEEE 802.1 group for several years extending | ||||
| 802.1 features over 802.11. As with any wireless media, 802.11 | ||||
| imposes new constraints and restrictions to TSN-grade QoS, and | ||||
| tradeoffs between latency and reliability guarantees must be | ||||
| considered as well as managed deployment requirements. An overview | ||||
| of 802.1 TSN capabilities and their extensions to 802.11 are | ||||
| discussed in [Cavalcanti_2019]. | ||||
| Wi-Fi Alliance (WFA) is the worldwide network of companies that | ||||
| drives global Wi-Fi adoption and evolution through thought | ||||
| leadership, spectrum advocacy, and industry-wide collaboration. The | ||||
| WFA work helps ensure that Wi-Fi devices and networks provide users | ||||
| the interoperability, security, and reliability they have come to | ||||
| expect. | ||||
| The following IEEE 802.11 specifications/certifications are relevant | ||||
| in the context of reliable and available wireless services and | ||||
| support for time-sensitive networking capabilities: | ||||
| Time Synchronization: IEEE802.11-2016 with IEEE802.1AS; WFA TimeSync | ||||
| Certification. | ||||
| Congestion Control: IEEE802.11-2016 Admission Control; WFA Admission | ||||
| Control. | ||||
| Security: WFA Wi-Fi Protected Access, WPA2 and WPA3. | ||||
| Interoperating with IEEE802.1Q bridges: IEEE802.11ak. | ||||
| Stream Reservation Protocol (part of IEEE802.1Qat): | ||||
| AIEEE802.11-2016. | ||||
| Scheduled channel access: IEEE802.11ad Enhancements for very | ||||
| high throughput in the 60 GHz band [IEEE80211ad]. | ||||
| 802.11 Real-Time Applications: Topic Interest Group (TIG) | ||||
| ReportDoc [IEEE_doc_11-18-2009-06]. | ||||
| In addition, major amendments being developed by the IEEE802.11 | ||||
| Working Group include capabilities that can be used as the basis for | ||||
| providing more reliable and predictable wireless connectivity and | ||||
| support time-sensitive applications: | ||||
| IEEE 802.11ax D4.0: Enhancements for High Efficiency (HE). [IEEE802 | ||||
| 11ax] | ||||
| IEEE 802.11be Extreme High Throughput (EHT). [IEEE80211be] | ||||
| IEE 802.11ay Enhanced throughput for operation in license-exempt | ||||
| bands above 45 GHz. [IEEE80211ay] | ||||
| The main 802.11ax and 802.11be capabilities and their relevance to | ||||
| RAW are discussed in the remainder of this document. | ||||
| 4.1.2. 802.11ax High Efficiency (HE) | ||||
| 4.1.2.1. General Characteristics | ||||
| The next generation Wi-Fi (Wi-Fi 6) is based on the IEEE802.11ax | ||||
| amendment [IEEE80211ax], which includes new capabilities to increase | ||||
| efficiency, control and reduce latency. Some of the new features | ||||
| include higher order 1024-QAM modulation, support for uplink multi- | ||||
| user MIMO, OFDMA, trigger-based access and Target Wake time (TWT) for | ||||
| enhanced power savings. The OFDMA mode and trigger-based access | ||||
| enable scheduled operation, which is a key capability required to | ||||
| support deterministic latency and reliability for time-sensitive | ||||
| flows. 802.11ax can operate in up to 160 MHz channels and it includes | ||||
| support for operation in the new 6 GHz band, which is expected to be | ||||
| open to unlicensed use by the FCC and other regulatory agencies | ||||
| worldwide. | ||||
| 4.1.2.1.1. Multi-User OFDMA and Trigger-based Scheduled Access | ||||
| 802.11ax introduced a new orthogonal frequency-division multiple | ||||
| access (OFDMA) mode in which multiple users can be scheduled across | ||||
| the frequency domain. In this mode, the Access Point (AP) can | ||||
| initiate multi-user (MU) Uplink (UL) transmissions in the same PHY | ||||
| Protocol Data Unit (PPDU) by sending a trigger frame. This | ||||
| centralized scheduling capability gives the AP much more control of | ||||
| the channel, and it can remove contention between devices for uplink | ||||
| transmissions, therefore reducing the randomness caused by CSMA-based | ||||
| access between stations. The AP can also transmit simultaneously to | ||||
| multiple users in the downlink direction by using a Downlink (DL) MU | ||||
| OFDMA PPDU. In order to initiate a contention free Transmission | ||||
| Opportunity (TXOP) using the OFDMA mode, the AP still follows the | ||||
| typical listen before talk procedure to acquire the medium, which | ||||
| ensures interoperability and compliance with unlicensed band access | ||||
| rules. However, 802.11ax also includes a multi-user Enhanced | ||||
| Distributed Channel Access (MU-EDCA) capability, which allows the AP | ||||
| to get higher channel access priority. | ||||
| 4.1.2.1.2. Improved PHY Robustness | ||||
| The 802.11ax PHY can operate with 0.8, 1.6 or 3.2 microsecond guard | ||||
| interval (GI). The larger GI options provide better protection | ||||
| against multipath, which is expected to be a challenge in industrial | ||||
| environments. The possibility to operate with smaller resource units | ||||
| (e.g. 2 MHz) enabled by OFDMA also helps reduce noise power and | ||||
| improve SNR, leading to better packet error rate (PER) performance. | ||||
| 802.11ax supports beamforming as in 802.11ac, but introduces UL MU | ||||
| MIMO, which helps improve reliability. The UL MU MIMO capability is | ||||
| also enabled by the trigger based access operation in 802.11ax. | ||||
| 4.1.2.1.3. Support for 6GHz band | ||||
| The 802.11ax specification [IEEE80211ax] includes support for | ||||
| operation in the new 6 GHz band. Given the amount of new spectrum | ||||
| available as well as the fact that no legacy 802.11 device (prior | ||||
| 802.11ax) will be able to operate in this new band, 802.11ax | ||||
| operation in this new band can be even more efficient. | ||||
| 4.1.2.2. Applicability to deterministic flows | ||||
| TSN capabilities, as defined by the IEEE 802.1 TSN standards, provide | ||||
| the underlying mechanism for supporting deterministic flows in a | ||||
| Local Area Network (LAN). The 802.11 working group has already | ||||
| incorporated support for several TSN capabilities, so that time- | ||||
| sensitive flow can experience precise time synchronization and | ||||
| timeliness when operating over 802.11 links. TSN capabilities | ||||
| supported over 802.11 (which also extends to 802.11ax), include: | ||||
| 1. 802.1AS based Time Synchronization (other time synchronization | ||||
| techniques may also be used) | ||||
| 2. Interoperating with IEEE802.1Q bridges | ||||
| 3. Time-sensitive Traffic Stream identification | ||||
| The exiting 802.11 TSN capabilities listed above, and the 802.11ax | ||||
| OFDMA and scheduled access provide a new set of tools to better | ||||
| server time-sensitive flows. However, it is important to understand | ||||
| the tradeoffs and constraints associated with such capabilities, as | ||||
| well as redundancy and diversity mechanisms that can be used to | ||||
| provide more predictable and reliable performance. | ||||
| 4.1.2.2.1. 802.11 Managed network operation and admission control | ||||
| Time-sensitive applications and TSN standards are expected to operate | ||||
| under a managed network (e.g. industrial/enterprise network). Thus, | ||||
| the Wi-Fi operation must also be carefully managed and integrated | ||||
| with the overall TSN management framework, as defined in the IEEE | ||||
| Std. 802.1Qcc specification [IEEE8021Qcc]. | ||||
| Some of the random-access latency and interference from legacy/ | ||||
| unmanaged devices can be minimized under a centralized management | ||||
| mode as defined in IEEE Std. 802.1Qcc, in which admission control | ||||
| procedures are enforced. | ||||
| Existing traffic stream identification, configuration and admission | ||||
| control procedures defined in IEEE Std. 802.11 QoS mechanism can be | ||||
| re-used. However, given the high degree of determinism required by | ||||
| many time-sensitive applications, additional capabilities to manage | ||||
| interference and legacy devices within tight time-constraints need to | ||||
| be explored. | ||||
| 4.1.2.2.2. Scheduling for bounded latency and diversity | ||||
| As discussed earlier, the 802.11ax OFDMA mode introduces the | ||||
| possibility of assigning different RUs (frequency resources) to users | ||||
| within a PPDU. Several RU sizes are defined in the specification | ||||
| (26, 52, 106, 242, 484, 996 subcarriers). In addition, the AP can | ||||
| also decide on MCS and grouping of users within a given OFMDA PPDU. | ||||
| Such flexibility can be leveraged to support time-sensitive | ||||
| applications with bounded latency, especially in a managed network | ||||
| where stations can be configured to operate under the control of the | ||||
| AP. | ||||
| As shown in [Cavalcanti_2019], it is possible to achieve latencies in | ||||
| the order of 1msec with high reliability in an interference free | ||||
| environment. Obviously, there are latency, reliability and capacity | ||||
| tradeoffs to be considered. For instance, smaller Resource Units | ||||
| (RU)s result in longer transmission durations, which may impact the | ||||
| minimal latency that can be achieved, but the contention latency and | ||||
| randomness elimination due to multi-user transmission is a major | ||||
| benefit of the OFDMA mode. | ||||
| The flexibility to dynamically assign RUs to each transmission also | ||||
| enables the AP to provide frequency diversity, which can help | ||||
| increase reliability. | ||||
| 4.1.3. 802.11be Extreme High Throughput (EHT) | ||||
| 4.1.3.1. General Characteristics | ||||
| The 802.11be is the next major 802.11 amendment (after 802.11ax) for | ||||
| operation in the 2.4, 5 and 6 GHz bands. 802.11be is expected to | ||||
| include new PHY and MAC features and it is targeting extremely high | ||||
| throughput (at least 30 Gbps), as well as enhancements to worst case | ||||
| latency and jitter. It is also expected to improve the integration | ||||
| with 802.1 TSN to support time-sensitive applications over Ethernet | ||||
| and Wireless LANs. | ||||
| The 802.11be Task Group started its operation in May 2019, therefore, | ||||
| detailed information about specific features is not yet available. | ||||
| Only high level candidate features have been discussed so far, | ||||
| including: | ||||
| 1. 320MHz bandwidth and more efficient utilization of non- | ||||
| contiguous spectrum. | ||||
| 2. Multi-band/multi-channel aggregation and operation. | ||||
| 3. 16 spatial streams and related MIMO enhancements. | ||||
| 4. Multi-Access Point (AP) Coordination. | ||||
| 5. Enhanced link adaptation and retransmission protocol, e.g. | ||||
| Hybrid Automatic Repeat Request (HARQ). | ||||
| 6. Any required adaptations to regulatory rules for the 6 GHz | ||||
| spectrum. | ||||
| 4.1.3.2. Applicability to deterministic flows | ||||
| The 802.11 Real-Time Applications (RTA) Topic Interest Group (TIG) | ||||
| provided detailed information on use cases, issues and potential | ||||
| solution directions to improve support for time-sensitive | ||||
| applications in 802.11. The RTA TIG report [IEEE_doc_11-18-2009-06] | ||||
| was used as input to the 802.11be project scope. | ||||
| Improvements for worst-case latency, jitter and reliability were the | ||||
| main topics identified in the RTA report, which were motivated by | ||||
| applications in gaming, industrial automation, robotics, etc. The | ||||
| RTA report also highlighted the need to support additional TSN | ||||
| capabilities, such as time-aware (802.1Qbv) shaping and packet | ||||
| replication and elimination as defined in 802.1CB. | ||||
| 802.11be is expected to build on and enhance 802.11ax capabilities to | ||||
| improve worst case latency and jitter. Some of the enhancement areas | ||||
| are discussed next. | ||||
| 4.1.3.2.1. Enhanced scheduled operation for bounded latency | ||||
| In addition to the throughput enhancements, 802.11be will leverage | ||||
| the trigger-based scheduled operation enabled by 802.11ax to provide | ||||
| efficient and more predictable medium access. 802.11be is expected to | ||||
| include enhancements to reduce overhead and enable more efficient | ||||
| operation in managed network deployments [IEEE_doc_11-19-0373-00]. | ||||
| 4.1.3.2.2. Multi-AP coordination | ||||
| Multi-AP coordination is one of the main new candidate features in | ||||
| 802.11be. It can provide benefits in throughput and capacity and has | ||||
| the potential to address some of the issues that impact worst case | ||||
| latency and reliability. Multi-AP coordination is expected to | ||||
| address the contention due to overlapping Basic Service Sets (OBSS), | ||||
| which is one of the main sources of random latency variations. | ||||
| 802.11be can define methods to enable better coordination between | ||||
| APs, for instance, in a managed network scenario, in order to reduce | ||||
| latency due to unmanaged contention. | ||||
| Several multi-AP coordination approaches have been discussed with | ||||
| different levels of complexities and benefits, but specific | ||||
| coordination methods have not yet been defined. | ||||
| 4.1.3.2.3. Multi-band operation | ||||
| 802.11be will introduce new features to improve operation over | ||||
| multiple bands and channels. By leveraging multiple bands/channels, | ||||
| 802.11be can isolate time-sensitive traffic from network congestion, | ||||
| one of the main causes of large latency variations. In a managed | ||||
| 802.11be network, it should be possible to steer traffic to certain | ||||
| bands/channels to isolate time-sensitive traffic from other traffic | ||||
| and help achieve bounded latency. | ||||
| 4.1.4. 802.11ad and 802.11ay (mmWave operation) | ||||
| 4.1.4.1. General Characteristics | ||||
| The IEEE 802.11ad amendment defines PHY and MAC capabilities to | ||||
| enable multi-Gbps throughput in the 60 GHz millimeter wave (mmWave) | ||||
| band. The standard addresses the adverse mmWave signal propagation | ||||
| characteristics and provides directional communication capabilities | ||||
| that take advantage of beamforming to cope with increased | ||||
| attenuation. An overview of the 802.11ad standard can be found in | ||||
| [Nitsche_2015] . | ||||
| The IEEE 802.11ay is currently developing enhancements to the | ||||
| 802.11ad standard to enable the next generation mmWave operation | ||||
| targeting 100 Gbps throughput. Some of the main enhancements in | ||||
| 802.11ay include MIMO, channel bonding, improved channel access and | ||||
| beamforming training. An overview of the 802.11ay capabilities can | ||||
| be found in [Ghasempour_2017] | ||||
| 4.1.4.2. Applicability to deterministic flows | ||||
| The high data rates achievable with 802.11ad and 802.11ay can | ||||
| significantly reduce latency down to microsecond levels. Limited | ||||
| interference from legacy and other unlicensed devices in 60 GHz is | ||||
| also a benefit. However, directionality and short range typical in | ||||
| mmWave operation impose new challenges such as the overhead required | ||||
| for beam training and blockage issues, which impact both latency and | ||||
| reliability. Therefore, it is important to understand the use case | ||||
| and deployment conditions in order to properly apply and configure | ||||
| 802.11ad/ay networks for time sensitive applications. | ||||
| The 802.11ad standard include a scheduled access mode in which | ||||
| stations can be allocated contention-free service periods by a | ||||
| central controller. This scheduling capability is also available in | ||||
| 802.11ay, and it is one of the mechanisms that can be used to provide | ||||
| bounded latency to time-sensitive data flows. An analysis of the | ||||
| theoretical latency bounds that can be achieved with 802.11ad service | ||||
| periods is provided in [Cavalcanti_2019]. | ||||
| 4.2. IEEE 802.15.4 | ||||
| 4.2.1. Provenance and Documents | ||||
| The IEEE802.15.4 Task Group has been driving the development of low- | ||||
| power low-cost radio technology. The Timeslotted Channel Hopping | ||||
| mode, added to the 2015 revision of the IEEE802.15.4 standard | ||||
| [IEEE802154], is targeted at the embedded and industrial world, where | ||||
| reliability, energy consumption and cost drive the application space. | ||||
| The IEEE802.15.4 physical layer has been designed to support | ||||
| demanding low-power scenarios targeting the use of unlicensed bands, | ||||
| both the 2.4 GHz and sub GHz Industrial, Scientific and Medical (ISM) | ||||
| bands. This has imposed requirements in terms of frame size, data | ||||
| rate and bandwidth to achieve reduced collision probability, reduced | ||||
| packet error rate, and acceptable range with limited transmission | ||||
| power. The PHY layer supports frames of up to 127 bytes. The Medium | ||||
| Access Control (MAC) sublayer overhead is in the order of 10-20 | ||||
| bytes, leaving about 100 bytes to the upper layers. IEEE802.15.4 | ||||
| uses spread spectrum modulation such as the Direct Sequence Spread | ||||
| Spectrum (DSSS). | ||||
| IPv6 over TSCH is enabled by the work done at the 6TiSCH WG. 6TiSCH | ||||
| has enabled best effort distributed scheduling to exploit the | ||||
| deterministic access capabilities provided by TSCH. The group | ||||
| designed the essential mechanisms to enable the management plane | ||||
| operation while ensuring IPv6 is supported. Yet the charter did not | ||||
| focus to providing a solution to establish end to end tracks while | ||||
| meeting quality of service requirements. 6TiSCH, through the RFC8480 | ||||
| [RFC8480] defines the 6P protocol which provides a pairwise | ||||
| negotiation mechanism to the control plane operation. The protocol | ||||
| supports agreement on a schedule between neighbors, enabling | ||||
| distributed scheduling. 6P goes hand-in-hand with a Scheduling | ||||
| Function (SF), the policy that decides how to maintain cells and | ||||
| trigger 6P transactions. The Minimal Scheduling Function (MSF) | ||||
| [I-D.ietf-6tisch-msf] is the default SF defined by the 6TiSCH WG; | ||||
| other standardized SFs can be defined in the future. MSF extends the | ||||
| minimal schedule configuration, and is used to add child-parent links | ||||
| according to the traffic load. | ||||
| Time sensitive networking on low power constrained wireless networks | ||||
| have been addressed by ISA100.11a and WirelessHART. TODO | ||||
| The 6TiSCH architecture [I-D.ietf-6tisch-architecture] already | ||||
| identified different models to schedule resources along tracks | ||||
| exploiting the TSCH schedule structure however these models have not | ||||
| been standardized. A Track, in the 6TiSCH architecture is considered | ||||
| a directed path from a source 6TiSCH node to one or more | ||||
| destination(s) 6TiSCH node(s) through the 6TiSCH network. A Track in | ||||
| 6TiSCH is the implementation of the deterministic path in the Detnet | ||||
| architecture [I-D.ietf-detnet-architecture] . Along a Track, 6TiSCH | ||||
| nodes reserve the resources to enable the efficient transmission of | ||||
| packets while aiming to optimize certain properties such as | ||||
| reliability and ensure small jitter or bounded latency. The track | ||||
| structure enables Layer-2 forwarding schemes, reducing the overhead | ||||
| of taking routing decisions at the Layer-3. Serial Tracks can be | ||||
| understood as the concatenation of cells or bundles along a routing | ||||
| path from a node towards a destination. The serial track concept is | ||||
| analogous to the circuit concept where resources are chained through | ||||
| the multi-hop topology. For example, A bundle of Tx Cells in a | ||||
| particular node is paired to a bundle of Rx Cells in the next hop | ||||
| node following a routing path. More complex approaches are described | ||||
| in and complemented by extensions to the RPL routing protocol in | ||||
| [I-D.ietf-roll-nsa-extension]. Reliability measures are for example | ||||
| achieved by exploiting concepts such as Replication and Elimination. | ||||
| In them, packets at origin are replicated and transmitted along | ||||
| disjoint tracks. This redundancy measure exploiting track forwarding | ||||
| increases energy consumption of the network nodes but improves | ||||
| significantly the reliability of the network. | ||||
| Useful References include: | ||||
| 1. IEEE Std 802.15.4: "IEEE Std. 802.15.4, Part. 15.4: Wireless | ||||
| Medium Access Control (MAC) and Physical Layer (PHY) | ||||
| Specifications for Low-Rate Wireless Personal Area Networks" | ||||
| [IEEE802154]. The latest version at the time of this writing is | ||||
| dated year 2015. | ||||
| 2. Morell, A. , Vilajosana, X. , Vicario, J. L. and Watteyne, T. | ||||
| (2013), Label switching over IEEE802.15.4e networks. Trans. | ||||
| Emerging Tel. Tech., 24: 458-475. doi:10.1002/ett.2650" | ||||
| [morell13]. | ||||
| 3. De Armas, J., Tuset, P., Chang, T., Adelantado, F., Watteyne, | ||||
| T., Vilajosana, X. (2016, September). Determinism through path | ||||
| diversity: Why packet replication makes sense. In 2016 | ||||
| International Conference on Intelligent Networking and | ||||
| Collaborative Systems (INCoS) (pp. 150-154). IEEE. [dearmas16]. | ||||
| 4. X. Vilajosana, T. Watteyne, M. Vucinic, T. Chang and K. S. | ||||
| J. Pister, "6TiSCH: Industrial Performance for IPv6 Internet- | ||||
| of-Things Networks," in Proceedings of the IEEE, vol. 107, no. | ||||
| 6, pp. 1153-1165, June 2019. [vilajosana19]. | ||||
| 4.2.2. TimeSlotted Channel Hopping | ||||
| 4.2.2.1. General Characteristics | ||||
| As a core technique in IEEE802.15.4, TSCH splits time in multiple | ||||
| time slots that repeat over time. The structure is referred as a | ||||
| Slotframe. For each timeslot, a set of available frequencies can be | ||||
| used, resulting in a matrix-like schedule (see Fig. Figure 1). | ||||
| timeslot offset | ||||
| | 0 1 2 3 4 | 0 1 2 3 4 | Nodes | ||||
| +------------------------+------------------------+ +-----+ | ||||
| | | | | | | | | | | | | C | | ||||
| CH-1 | EB | | |C->B| | EB | | |C->B| | | | | ||||
| | | | | | | | | | | | +-----+ | ||||
| +-------------------------------------------------+ | | ||||
| | | | | | | | | | | | | | ||||
| CH-2 | | |B->C| |B->A| | |B->C| |B->A| +-----+ | ||||
| | | | | | | | | | | | | B | | ||||
| +-------------------------------------------------+ | | | ||||
| ... +-----+ | ||||
| | | ||||
| +-------------------------------------------------+ | | ||||
| | | | | | | | | | | | +-----+ | ||||
| CH-15| |A->B| | | | |A->B| | | | | A | | ||||
| | | | | | | | | | | | | | | ||||
| +-------------------------------------------------+ +-----+ | ||||
| ch. | ||||
| offset | ||||
| Figure 1: Slotframe example with scheduled cells between nodes A, B | ||||
| and C | ||||
| This schedule represents the possible communications of a node with | ||||
| its neighbors, and is managed by a Scheduling Function such as The | ||||
| Minimal Scheduling Function (MSF) [I-D.ietf-6tisch-msf]. Each cell | ||||
| in the schedule is identified by its slotoffset and channeloffset | ||||
| coordinates. A cell's timeslot offset indicates its position in | ||||
| time, relative to the beginning of the slotframe. A cell's channel | ||||
| offset is an index which maps to a frequency at each iteration of the | ||||
| slotframe. Each packet exchanged between neighbors happens within | ||||
| one cell. An Absolute Slot Number (ASN) indicates the number of | ||||
| slots elapsed since the network started. It increments at every | ||||
| slot. This is a 5 byte counter that can support networks running for | ||||
| more than 300 years without wrapping (assuming a 10 ms timeslot). | ||||
| Channel hopping provides increased reliability to multi-path fading | ||||
| and external interference. It is handled by TSCH through a channel | ||||
| hopping sequence referred as macHopSeq in the IEEE802.15.4 | ||||
| specification. | ||||
| The Time-Frequency Division Multiple Access provided by TSCH enables | ||||
| the orchestration of traffic flows, spreading them in time and | ||||
| frequency, and hence enabling an efficient management of the | ||||
| bandwidth utilization. Such efficient bandwidth utilization can be | ||||
| combined to OFDM modulations also supported by the IEEE802.15.4 | ||||
| standard [IEEE802154] since the 2015 version. | ||||
| In the RAW context, low power reliable networks should address non- | ||||
| critical control scenarios such as Class 2 and monitoring scenarios | ||||
| such as Class 4 defined by the RFC5673 [RFC5673]. As a low power | ||||
| technology targeting industrial scenarios radio transducers provide | ||||
| low data rates (typically between 50kbps to 250kbps) and robust | ||||
| modulations to trade-off performance to reliability. TSCH networks | ||||
| are organized in mesh topologies and connected to a backbone. | ||||
| Latency in the mesh network is mainly influenced by propagation | ||||
| aspects such as interference. ARQ methods and redundancy techniques | ||||
| such as replication and elimination should be studied to provide the | ||||
| needed performance to address deterministic scenarios. | ||||
| 4.2.2.2. Applicability to Deterministic Flows | ||||
| Nodes in a TSCH network are tightly synchronized. This enables to | ||||
| build the slotted structure an ensure efficient utilization of | ||||
| resources thranks to proper scheduling policies. Scheduling is a key | ||||
| to orchestrate the resources that different nodes in a track or path | ||||
| are using. Slotframes can be split in resource blocks reserving the | ||||
| needed capacity to certain needs. Periodic and bursty traffic can be | ||||
| handled independently in the schedule, using active and reactive | ||||
| policies and taking advantage of certain cell overprovision. Along a | ||||
| track, resource blocks can be chained so nodes in previous hops | ||||
| transmit their data before those that come later. This provides a | ||||
| tight control to latency along a track. Redundancy is achieved in a | ||||
| best effort manner by overprovision, giving time to the management | ||||
| plane of the network to request more resources if needed. -time | ||||
| synchronization - scheduling capabilities, discuss such things as | ||||
| Resource Units, time slots or resource blocks. Can we reserve | ||||
| periodic resources vs. ask each time, what precision can we get in | ||||
| latency control. - diversity scenarios, what's available, - gap | ||||
| analysis, e.g. discuss multihop, or what's missing how to do PAREO | ||||
| features. | ||||
| 5. 3GPP standards | ||||
| 6. IANA Considerations | ||||
| This specification does not require IANA action. | This specification does not require IANA action. | |||
| 6. Security Considerations | 7. Security Considerations | |||
| Most RAW technologies integrate some authentication or encryption | Most RAW technologies integrate some authentication or encryption | |||
| mechanisms that were defined outside the IETF. | mechanisms that were defined outside the IETF. | |||
| 7. Acknowledgments | 8. Acknowledgments | |||
| Many thanks to the participants of the RAW WG where a lot of the work | Many thanks to the participants of the RAW WG where a lot of the work | |||
| discussed here happened. | discussed here happened. | |||
| 8. References | 9. References | |||
| 8.1. Normative References | 9.1. Normative References | |||
| [I-D.ietf-6tisch-architecture] | [I-D.ietf-6tisch-architecture] | |||
| Thubert, P., "An Architecture for IPv6 over the TSCH mode | Thubert, P., "An Architecture for IPv6 over the TSCH mode | |||
| of IEEE 802.15.4", draft-ietf-6tisch-architecture-20 (work | of IEEE 802.15.4", draft-ietf-6tisch-architecture-20 (work | |||
| in progress), March 2019. | in progress), March 2019. | |||
| [I-D.ietf-detnet-architecture] | ||||
| Finn, N., Thubert, P., Varga, B., and J. Farkas, | ||||
| "Deterministic Networking Architecture", draft-ietf- | ||||
| detnet-architecture-13 (work in progress), May 2019. | ||||
| [RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T. | ||||
| Phinney, "Industrial Routing Requirements in Low-Power and | ||||
| Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October | ||||
| 2009, <https://www.rfc-editor.org/info/rfc5673>. | ||||
| [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 | [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 | |||
| (IPv6) Specification", STD 86, RFC 8200, | (IPv6) Specification", STD 86, RFC 8200, | |||
| DOI 10.17487/RFC8200, July 2017, | DOI 10.17487/RFC8200, July 2017, | |||
| <https://www.rfc-editor.org/info/rfc8200>. | <https://www.rfc-editor.org/info/rfc8200>. | |||
| 8.2. Informative References | [RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH | |||
| Operation Sublayer (6top) Protocol (6P)", RFC 8480, | ||||
| DOI 10.17487/RFC8480, November 2018, | ||||
| <https://www.rfc-editor.org/info/rfc8480>. | ||||
| 9.2. Informative References | ||||
| [Cavalcanti_2019] | ||||
| Dave Cavalcanti et al., "Extending Time Distribution and | ||||
| Timeliness Capabilities over the Air to Enable Future | ||||
| Wireless Industrial Automation Systems, the Proceedings of | ||||
| IEEE", June 2019. | ||||
| [dearmas16] | ||||
| Jesica de Armas et al., "Determinism through path | ||||
| diversity: Why packet replication makes sense", September | ||||
| 2016. | ||||
| [Ghasempour_2017] | ||||
| Yasaman Ghasempour et al., "802.11ay: Next-Generation 60 | ||||
| GHz Communications for 100 Gb/s Wi-Fi", December 2017. | ||||
| [I-D.ietf-6tisch-msf] | ||||
| Chang, T., Vucinic, M., Vilajosana, X., Duquennoy, S., and | ||||
| D. Dujovne, "6TiSCH Minimal Scheduling Function (MSF)", | ||||
| draft-ietf-6tisch-msf-03 (work in progress), April 2019. | ||||
| [I-D.ietf-roll-nsa-extension] | ||||
| Koutsiamanis, R., Papadopoulos, G., Montavont, N., and P. | ||||
| Thubert, "RPL DAG Metric Container Node State and | ||||
| Attribute object type extension", draft-ietf-roll-nsa- | ||||
| extension-01 (work in progress), March 2019. | ||||
| [IEEE80211] | [IEEE80211] | |||
| "IEEE Standard 802.11 - IEEE Standard for Information | "IEEE Standard 802.11 - IEEE Standard for Information | |||
| Technology - Telecommunications and information exchange | Technology - Telecommunications and information exchange | |||
| between systems Local and metropolitan area networks - | between systems Local and metropolitan area networks - | |||
| Specific requirements - Part 11: Wireless LAN Medium | Specific requirements - Part 11: Wireless LAN Medium | |||
| Access Control (MAC) and Physical Layer (PHY) | Access Control (MAC) and Physical Layer (PHY) | |||
| Specifications.". | Specifications.". | |||
| [IEEE80211ad] | ||||
| "802.11ad: Enhancements for very high throughput in the 60 | ||||
| GHz band". | ||||
| [IEEE80211ak] | ||||
| "802.11ak: Enhancements for Transit Links Within Bridged | ||||
| Networks", 2017. | ||||
| [IEEE80211ax] | ||||
| "802.11ax D4.0: Enhancements for High Efficiency WLAN". | ||||
| [IEEE80211ay] | ||||
| "802.11ay: Enhanced throughput for operation in license- | ||||
| exempt bands above 45 GHz". | ||||
| [IEEE80211be] | ||||
| "802.11be: Extreme High Throughput". | ||||
| [IEEE802154] | [IEEE802154] | |||
| IEEE standard for Information Technology, "IEEE Std. | IEEE standard for Information Technology, "IEEE Std. | |||
| 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) | 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) | |||
| and Physical Layer (PHY) Specifications for Low-Rate | and Physical Layer (PHY) Specifications for Low-Rate | |||
| Wireless Personal Area Networks". | Wireless Personal Area Networks". | |||
| Author's Address | [IEEE8021Qat] | |||
| "802.1Qat: Stream Reservation Protocol". | ||||
| [IEEE8021Qcc] | ||||
| "802.1Qcc: IEEE Standard for Local and Metropolitan Area | ||||
| Networks--Bridges and Bridged Networks -- Amendment 31: | ||||
| Stream Reservation Protocol (SRP) Enhancements and | ||||
| Performance Improvements". | ||||
| [IEEE_doc_11-18-2009-06] | ||||
| "802.11 Real-Time Applications (RTA) Topic Interest Group | ||||
| (TIG) Report", November 2018. | ||||
| [IEEE_doc_11-19-0373-00] | ||||
| Kevin Stanton et Al., "Time-Sensitive Applications Support | ||||
| in EHT", March 2019. | ||||
| [morell13] | ||||
| Antoni Morell et al., "Label switching over IEEE802.15.4e | ||||
| networks", April 2013. | ||||
| [Nitsche_2015] | ||||
| Thomas Nitsche et al., "IEEE 802.11ad: directional 60 GHz | ||||
| communication for multi-Gigabit-per-second Wi-Fi", | ||||
| December 2014. | ||||
| [vilajosana19] | ||||
| Xavier Vilajosana et al., "6TiSCH: Industrial Performance | ||||
| for IPv6 Internet-of-Things Networks", June 2019. | ||||
| Authors' Addresses | ||||
| Pascal Thubert (editor) | Pascal Thubert (editor) | |||
| Cisco Systems, Inc | Cisco Systems, Inc | |||
| Building D | Building D | |||
| 45 Allee des Ormes - BP1200 | 45 Allee des Ormes - BP1200 | |||
| MOUGINS - Sophia Antipolis 06254 | MOUGINS - Sophia Antipolis 06254 | |||
| FRANCE | FRANCE | |||
| Phone: +33 497 23 26 34 | Phone: +33 497 23 26 34 | |||
| Email: pthubert@cisco.com | Email: pthubert@cisco.com | |||
| Dave Cavalcanti | ||||
| Intel Corporation | ||||
| 2111 NE 25th Ave | ||||
| Hillsboro, OR 97124 | ||||
| USA | ||||
| Phone: 503 712 5566 | ||||
| Email: dave.cavalcanti@intel.com | ||||
| Xavier Vilajosana | ||||
| Universitat Oberta de Catalunya | ||||
| 156 Rambla Poblenou | ||||
| Barcelona, Catalonia 08018 | ||||
| Spain | ||||
| Email: xvilajosana@uoc.edu | ||||
| End of changes. 28 change blocks. | ||||
| 40 lines changed or deleted | 660 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||