TechnologySeptember 10, 2018
Industrial wireless TSN roadmap: looking at the path forward
Wired TSN for industrial use is gaining acceptance but the next challenges developing seamless, wireless Time-Sensitive Networking capabilities. This article explores leveraging the existing industrial wired TSN design for wireless TSN, and thoughts on a roadmap for wireless TSN in the industrial environment.
Wireless communication in industrial communication systems is beneficial for many obvious reasons including reduced wiring cost and complexity as well as enabling mobility.
However, because industrial systems involve life-critical control systems that may be lethal if they become unstable, approaches toward adopting wireless communication tend to be very conservative. It should be clear that reliability is sine qua non, regardless of whether communication is wired or wireless.
The term “wireless” in this document is used in the broadest possible sense and includes free-space optical, Li-Fi, Bluetooth, 802.11g/n etc., small (nano or pico) cells: 3G, 4G, LTE, and includes anything else that involves information transfer using the electromagnetic spectrum, including various forms of visible and invisible light, i.e. free-space optical.
Note that Li-Fi stands for Light Fidelity. It is a wireless, bidirectional, optical form of communication that leverages unused visible spectrum reducing load on radio spectrum. Data is transmitted using light whose intensity varies faster than the human eye can detect. Li-Fi uses LED bulbs with a transceiver, and data transmission can be faster than is possible with Wi-Fi.
Industrial systems are comprised of large, complex infrastructure equipment that evolves slowly relative to consumer market devices. Thus, given that wired TSN is undergoing deployment into industrial systems, wired TSN should leverage and integrate seamlessly with wireless TSN. The Theory of Operation for wired TSN should be used to leverage equipment, skill, and development to increase “pull” for wireless into industrial systems.
This document is not about developing new technology for wireless TSN, but rather pulling existing wireless technologies under the TSN umbrella and developing a common Theory of Operation. It is designed to be top-down rather than bottom-up and sketches a roadmap for integrating wireless communication into industrial systems and identifies standards and technology gaps.
Looking at the roadmap
The roadmap for integrating wireless TSN into industrial TSN systems takes a conservative, phased approach allowing confidence in reliability of wireless TSN to be gradually increased.
The phases are:
- Wireless Configuration of Wired TSN
- Hybrid Wired-Wireless Time Synchronization
- Wireless TSN Scheduling
- Wireless Redundancy for Wired TSN
- Wireless TSN Switch Deployment
Each wireless technology would proceed through these phases and NETCONF/YANG management of all phases is mandatory.
Wireless configuration of Wired TSN
This phase simply implements wireless communication to configure existing wired TSN. This is confined to actions taken by the Centralized Network Configurator (CNC) and the Centralized User Configuration (CUC) processes, including configuration of TSN schedules. These are actions that take place before a system becomes operational and while reliability issues would be an annoyance, they have no life-critical impact because this is configuration, not operation. It is assumed that wireless configuration can communicate with all required hosts in the TSN network.
The use case for this phase is that a field engineer may utilize a wireless tablet to change the network configuration or retrieve diagnostic information. Augmented reality may be considered at this point as another wireless TSN application. For example, the field engineer may see virtual gauges, status, and other information overlaid on the real equipment as the information becomes relevant to the current task.
This phase is relatively easy and straight-forward; there appears to be no technical or standardization gap in this phase. It should be noted that cybersecurity remains critical in a wireless system, as equipment can be moved and replaced without accessing physical connections.
Wireless time synchronization
The next phase is to integrate wireless gPTP with wired gPTP such that the wireless portion of a hybrid wired-wireless can rely upon reliable wired time synchronization. The concept for this phase of wireless TSN is that all wireless channels have the benefit of reliable time synchronization.
Thus, this phase uses the wired node as an access point with a wired clock and wireless devices may synchronize with it. Wireless devices not on the wired network may use Timing Measurement or Fine Timing Measurement to synchronize; deterministic networking is not considered until Phase 3.
Using Timing Measurement (TM) for wireless synchronization is defined in Clause 12 of the IEEE 802.1AS-2011 specification. Fine Timing Measurement (FTM) is defined in the IEEE 802.11- 2016 specification, and synchronization using FTM is described in the IEEE 802.1AS-Rev draft, which is expected to be finalized in 2018.
The gaps in this phase are the following. Can the wireless devices use wireless gPTP to synchronize tightly enough with devices that use wired gPTP time synchronization? Is it feasible to use GNSS only (wired GNSS grandmaster and GNSS for each wireless device) and not require 802.1AS wireless support?
Using wireless time synchronization, master clocks must be wired interfaces and wireless interfaces should be slaves in this phase. However, this does not preclude testing with a GNSS receiver enabling a wired or wireless gateway to become a grandmaster.
Wireless TSN scheduling
Wireless TSN interfaces must support the semantics of IEEE 802.1Qbv; deterministic traffic is required for industrial systems, so this will be mandatory. This phase simply ensures that 802.1Qbv scheduling is implemented in wireless TSN interfaces.
This article is agnostic as to the specific wireless technologies used. However, the point of TSN is to control message transmission time. Thus, wireless TSN interfaces must be able to implement an 802.1Qbv schedule compliant with the IEEE 802.1Qbv standard, with no other transmission except that specified by the schedule. The CNC will ensure that no collisions take place and the wireless system will benefit greatly from this.
Such a wireless system, having the benefit of wired time synchronization and a deterministic schedule from the CNC, will eliminate data traffic frame collisions on the network. It is recognized that surround networks and the environment can still cause interference, affecting determinism. Note that industrial systems tend to use only scheduled (TT) and best effort (BE) traffic types; rate constrained (RC) traffic offers no apparent benefit for control system communication now. Note that this does not preclude audio/video from being added to a control network if it is certain not to impact reliability.
The fact there are no wireless frame collisions as part of TSN data traffic is significant and helps enable the wireless system to be deterministic. In the presence of competing wireless systems and other sources of electromagnetic interference (EMI), determinism can be defined as a function of bit error rate. In other words, there is some predictability to the environment, and a suitable channel sounding process has been completed.
There are multiple gaps in this phase:
Can the wireless interface implement IEEE 802.1Qbv? There are many wireless scheduling approaches already and some may be extended to implement 802.1Qbv. This document does not intend to specify how at this point.
Can the wireless interface be configured by the CNC just like a wired interface? This requires the use of NETCONF/YANG.
How will synchronization error affect 802.1Qbv performance? Timing Measurement provides accuracy in the low microseconds, so guard bands would need to be larger than for Fine Timing Measurement solutions, where wireless synchronization may be as accurate as current wired synchronization.
For evaluation purposes, and to make the math easy, we will assume Wi-Fi traffic is being sent at 100 Mbps. Network traffic at 100 Mbps takes 80 nanoseconds per byte (1,000,000,000 ns/sec / (100,000,000 bits/sec / 8 bytes/bit)). A maximum 10 microsecond error in synchronization between two wireless devices requires the equivalent of an extra 125 bytes of data between windows where devices don’t transmit (10 μs * 1000 ns/μs / 80 ns/byte) to avoid collisions. For windows 100 microseconds long (enough for 1250 bytes of data and headers), there would be up to 10,000 windows scheduling approaches already and some may be extended to implement 802.1Qbv. This document does not intend to specify how at this point.
Can the wireless interface be configured by the CNC just like a wired interface? This requires the use of NETCONF/YANG.
How will synchronization error affect 802.1Qbv performance? Timing Measurement provides accuracy in the low microseconds, so guard bands would need to be larger than for Fine Timing Measurement solutions, where wireless synchronization may be as accurate as current wired synchronization.
Wireless channel characteristics are hidden behind IEEE 802.1Qbv. For example, retries must occur during the scheduled transmission window and not past the point of usefulness. However, there are no known wireless implementations yet.
Wireless redundancy for Wired TSN
Note that Phases 2 and 3 are validation steps and not yet requiring deployment. In Phase 4, deployment of the wireless system from Phase 3 occurs, but only in the form of increasing reliability via adding redundant communication channels. As a reminder, this is a conservative approach in which wireless TSN is being introduced gradually to industrial systems and earning its trust along the way. Any of the redundant TSN paths may be wireless.
IEEE 802.1CB is the standard for wired TSN reliability. In this phase, some of the redundant channels now include wireless TSN.
The gap in this phase is, of course:
Can wireless TSN interfaces can be seamlessly integrated into IEEE 802.1CB? Initial indications are that IEEE 802.1CB should work fine with wireless. However, 802.1CB can cause packets to be delivered out of order, so either endpoints need to deal with that or switches need to buffer packets long enough to put them back in order.
Given wireless retransmission, the potential need for buffering, determinism, etc. should be carefully analyzed in any design.
Wireless TSN Switch Deployment
In this final phase, wireless TSN is deployed between switches. In other words, wireless communication is now deployed anywhere within a wired TSN network.
The result of the final phase is full integration of wireless TSN that meets wired TSN reliability and performance requirements. A fully wireless TSN system could be deployed using the same CNC and CUC as the wired network.
The IEEE 802.1Qbz and 802.11ak standards allow wireless bridging that is interoperable with wired bridging. Currently, a wireless device is only expected to be connected to one Access Point and any bridging is done in proprietary ways. Those standards would allow for a standardized way to intermingle wired and wireless bridges.
Cybersecurity
Ensuring cybersecurity is a requirement in life-critical control systems for which industrial TSN will provide communication, both wired and wireless. While TSN is more complex than plain Ethernet and thus, presumably more difficult to attack, the argument that this makes TSN inherently secure is false. Each phase of this roadmap must consider cybersecurity tradeoffs with TSN performance including the cybersecurity impact upon latency, jitter, non-determinism, and cost.
Availability and authentication are the most important information assurance aspects for industrial systems. Confidentiality is generally of lower importance.
Cybersecurity within industrial systems, which depends upon authentication and sometimes encryption, is currently insecure. This is because both authentication and encryption depend upon the distribution of a “key” that is required to either authenticate a user or decrypt a message. Because all cybersecurity mechanisms are based upon the common, shared secret known as a key, key generation, distribution, and lies at the heart of cybersecurity and is the only issue addressed in this roadmap. The specific use of keys, that is, the cybersecurity applications required, may vary widely and are determined by specific wireless applications and threat environments.
Private key exchange is the most secure form of key use, however it is subject to the problem of securely transmitting keys to message recipients. Public key exchange attempts to solve this by trading-off security. Public key exchange uses two pairs of keys, a public and private key where only the public key needs to be exchanged and a private key is derived from the public key. Unfortunately, the cost of public key exchange is that it is not provably secure and it is possible, given enough computing power, for anyone to derive the private key from the public key. This has forced public key exchange to continuously increase key length to maintain a reasonable sense of security.
However, this continual key length increase reduces resources and is not sustainable in the long term. Thus, critical industrial components are insecure in a large part because management and distribution of keys is an insecure process. Once an adversary obtains a key and can decrypt messages, the system is no longer secure. Thus, while it is recognized that keys are only one aspect of cybersecurity, they are the foundation upon which all other cybersecurity mechanisms rest.
Because keys and their secure distribution are fundamental to cybersecurity, this roadmap requires the ability to use symmetric keys and AES ciphers or stronger for all the proposed phases of this roadmap. Use of public key exchange mechanisms may be included if necessary, but is discouraged and expected to be phased out.
Industrial key distribution systems typically include mechanisms such as pre-installed keys, Diffie- Hellman, elliptic-curve, and the emerging quantum key distribution (QKD).
Pre-installed keys may be installed by the vendor during device manufacture. They suffer from an inability to be automatically updated once the device is placed in the field. Diffie-Hellman and elliptic- curve are widely used, but known to be insecure (Adrian, D. et al., 2015) and this roadmap discourages their use. Quantum key distribution is an emerging technology that solves the above problems but is still in its early commercial stages.
Use of the IEEE P1913 keychain YANG model is recommended for TSN because it has precise timestamps for each key and includes features for use with QKD. It enables keys to be managed with key lifetimes that are on the order of Ethernet frame transmission times in gigabit Ethernet networks.
This road map attempts to provide a solid foundation for key distribution as part of its vision, but does not attempt to specify wireless cybersecurity applications. It is recognized that there are several general vulnerabilities in TSN including time synchronization, the CNC and device configuration, and manipulation of IEEE 802.1Qbv schedules.
It is also important to note that there are TSN standards that can be used to enhance cybersecurity over wireless connections. For example, the IEEE 802.1Qci-2017 standard enables a bridge to detect whether or not some systems in a network are conforming to behaviors agreed to by configuration and/or protocol exchanges. These policing and filtering functions can be used to prevent the distribution of network traffic that is disruptive or unexpected, and can improve security by isolating sections of a network in well-defined ways.
Conclusion
There is a myriad of wireless technologies at various stages of maturity including Wi-Fi, 6LoWPAN, IEEE 802.11g, IEEE 802.11n, IEEE 802.11ac and above, MIMO technologies, cognitive radio, etc. This article is agnostic regarding the specific radio technology or technologies used. It is only required that they meet the progressively challenging requirements for each phase.
As noted, industrial systems are primarily focused upon deterministic communication for control systems. Therefore, only scheduled (TT) and best effort (BE) traffic are of interest.
It is understood that a wireless TSN system will likely be effectively slower than the equivalent wired TSN system. Retransmission to improve reliability may be one reason for longer latency in wireless TSN channels. Careful thought in combining this aspect with IEEE 802.1CB should be considered. However, longer latency of wireless TSN is unlikely to be a problem in many industrial applications. The most critical problem is reliability with determinism; a message must reach its destination within its scheduled period.
This document is to be considered a request for comments; constructive corrections, ideas, and comments are very welcome by the author. Please contact [email protected] with comments.
Appendix A – Synchronization
As an alternative to using 802.1AS synchronization, it is possible to use GNSS receivers for wireless synchronization. This makes sense for a widely distributed network, where satellite synchronization is likely to be more accurate than synchronizing time over a network connection. However, there are concerns with using GNSS receivers for a TSN network:
- How feasible is it that all end-devices will be using GNSS and have clear satellite reception?
- Is GNSS with 802.1Qbv as likely to be supported as 802.1AS with 802.1Qbv?
- How do you ensure that switches and Access Points using wired time have the same time base as wireless devices using GNSS (needed for 802.1Qbv support)?
One possibility for using GNSS receivers is that the wired (or wireless) grandmaster would be using GNSS time, which would allow for a mix of both as needed.
An additional timing consideration is that the devices on the network may not all need the correct time, just the same time. For protocols such as 802.1Qbv, the only requirement is that the grandmaster distributes the same time to everyone. If all the devices think the year is 1990, they can still work correctly – if they think it is the same time in the year 1990. More fundamentally, the 802.1Qbv schedules must start from the same epoch and remain synchronized.