TSN (Time-Sensitive Networking) is gaining momentum as a scalable, standards-based solution for deterministic time-sensitive applications, including industrial automation, real time audio and video transmission automotive networks, and safety critical applications. TSN capable networks will be able to manage automated operations while reacting to inputs from multiple sources in real time, creating highly transparent, digitally observable systems. Time-sensitive data can enable enhanced AI decision-making, greater efficiency, and expanding customization capabilities. That kind of potential shouldn’t be tied down—many applications would benefit greatly from the flexibility and physical freedom of wireless connectivity.
"We can derive a reasonable prediction of which TSN capabilities and applications will be initially supported over wireless."
Dave Cavalcanti, Intel.
Fortunately, analysis from multiple independent industry stakeholders has concluded that TSN can be extended over wireless segments. The Avnu Alliance, 5G-ACIA, Wireless Broadband Alliance (WBA) and others have taken a close look at current TSN, Wi-Fi, and 5G capabilities. They’ve also collected data about projected use cases and market requirements. From this information, we can derive a reasonable prediction of which TSN capabilities and applications will be initially supported over wireless. We also have enough information about how wireless segments will be integrated into TSN domains and managed to begin planning for this future.
TSN domains
TSN applications require significant reserved bandwidth to ensure guaranteed data delivery. Though time-sensitive data can coexist with other data on a Local Area Network, in reality, it’s likely to be impractical in most cases for an entire enterprise network to be TSN-capable. More likely, the time-sensitive applications will reside within a TSN domain, a protected subset of the network wherein all devices are TSN-capable. We can assume the same will hold for WTSN (Wireless Time-Sensitive Networking) segments: they will be supported throughout the extension of the TSN domain from wired to wireless medium.
"As WTSN applications emerge, they will primarily be segments of a larger TSN domain with both wired and wireless links."
Dave Cavalcanti, Intel.
Of course, there may also be stand-alone TSN capable LANs. In the case of touring concert productions for instance, the entire production network consists of devices transmitting and receiving time-sensitive data. As WTSN applications emerge, they will primarily be segments of a larger TSN domain with both wired and wireless links.
Network configuration models for TSN will depend on the application at hand. The IEEE 802.1Qcc specification defines the network configuration and management models for TSN. Industrial applications will primarily use a centralized model, where all endpoints are managed by a central user configuration device (CUC). A Centralized Network Configuration (CNC) device will handle scheduling and path management, configuring the TSN bridges. Live media TSN applications use a distributed model, which doesn’t have any such “god boxes.” In these systems, endpoints and network devices share status, scheduling, etc. with each other directly. There may also be a combination of decentralized device configuration and centralized resource management in hybrid models.
WTSN network planning
TSN requires careful planning. At the design stage, the network and traffic engineers must define traffic profiles, determine capacity requirements, and select and configure TSN capabilities. When extending TSN over a wireless segment, they must also determine the physical coverage area, conducting a site survey to determine the number and location of wireless access points and base stations. For wireless segments especially, line-of-sight obstructions must be accounted for at this stage.
Access to WTSN segments—and indeed, the entire TSN network—should be managed by a central authority. Only authorized devices capable of implementing and complying with the TSN capabilities required to provide the time synchronization and determinism benefits for time-critical applications can be permitted on the network. This could include any combination of time-critical and best-effort devices; they don’t all necessarily need time-critical performance, but they do have to all play by the rules.
WTSN features and functional requirements
TSN is a highly customizable technology, with industry-specific profiles still under development in many application domains. Still, some degree of consensus has emerged around features that are useful and required across TSN implementations: time synchronization, traffic shaping, and redundancy. These features are among the most mature in the current TSN toolset; when wireless TSN emerges, it will have to meet basic requirements for all three.
Time Synchronization, defined for TSN domains under the IEEE 802.1AS profile of IEEE 1588 PTP (Precision Time Protocol), is the ability to synchronize to a primary clock across the network. Time sync is a foundational requirement for deterministic networks, supporting a number of other features, including traffic scheduling, filtering, and policing. All TSN bridges must share a common definition of “time” – which applies to any WTSN segments as well. In industrial use cases particularly, most applications call for multiple redundant reference clocks to increase reliability. However, it’s not generally required for all nodes have the capability to house the primary clock. For most wireless applications, the reference clock can reside in the wired network.
Based on analysis of market requirement, we expect time sync accuracy requirements of approximately 1µsec will address the majority of wireless applications. 5G and Wi-Fi networks have shown they can meet this bar. Extending TSN time synchronization over Wi-Fi has already been defined in IEEE 802.1As and 802.11 specifications, and support for TSN time distribution across 5G is defined in 3GPP Release 16.
Traffic shaping
TSN can guarantee the bounded delivery of time-sensitive information by prioritizing the data into traffic classes and allocating bandwidth accordingly. Traffic-shaping based on the IEEE 802.1Qbv (time-aware shaper) specification has been the initial focus for WTSN and is likely to be supported. Other traffic shaping approaches, such as 802.1Qav (credit-based shaper) may also be considered, depending on the use case.
802.1Qbv defines a set of time gates to control the queues associated with traffic classes on a TSN bridge. The system creates protected windows for time-critical traffic during which any other interfering traffic is blocked. Wireless systems within the TSN domain must be able to identify, prioritize, and deliver time-critical data within the appropriate time window.
Redundancy
Bandwidth allocation alone can’t guarantee delivery with high reliability, if there is a chance that the link or devices may fail. The IEEE 802.1CB Frame Replication and Elimination for Reliability (FRER) standard was developed to increase reliability against potential link and device failures. FRER replicates critical data on multiple streams travelling different network paths. It also attaches a redundancy tag (R-TAG) to the link layer data frame. One or more links may fail, and the data will still be delivered. If multiple frames of the same data arrive at the same endpoint or relay, the device uses the R-TAG to identify and eliminate the redundant frames. Thus, FRER provides redundancy without unnecessarily clogging the network.
FRER is invisible to the MAC/PHY link, so it should be able to operate over wireless technology, but it does introduce a lot of additional traffic. WTSN networks will need to be able to support FRER, but it won’t be implemented in all cases—it’s most frequently required in safety-critical applications. This is likely to be an optional WTSN capability, activated based on an analysis of reliability requirements versus efficiency.
Using a physical Wi-Fi TSN bridge
Both Wi-Fi, including the latest Wi-Fi 6/6E, and 5G are considered capable of carrying WTSN network segments, but they will be integrated into the wired TSN network differently.
"Network managers will be able to add Wi-Fi segments to wired TSN using a physical Wi-Fi TSN bridge."
Dave Cavalcanti, Intel.
Wi-Fi, like Ethernet and TSN, is part of the larger IEEE 802 suite of standards for LANs. As such, wired and Wi-Fi TSN share the same protocol stack. Network managers will be able to add Wi-Fi segments to wired TSN using a physical Wi-Fi TSN bridge. TSN-capable Access Points will operate as bridges, with 802.11 Stations operating as TSN end devices. Wi-Fi 6 TSN will take advantage of scheduling and efficiency enhancements, as well as the operation in the new 6 GHz spectrum (Wi-Fi 6E) to meet the determinism required by WTSN applications.
5G and Ethernet are governed by different standards, meaning an interface will be required to incorporate 5G segments into a TSN domain. 3GPP Release 16 defines interfaces for allowing a 5GS system (5GS) to appear as a “virtual” TSN bridge. Release 16 provides a control plane interface to configure “virtual” TSN ports at the user plane. The virtual TSN bridge tunnels TSN traffic streams over the 5GS through defined TSN Translators at network (NS-TT) and device (DS-TT) sides. This solution uses existing 5G capabilities to meet TSN requirements for time synchronization, and deterministic delivery by leveraging 5G clock synchronization, scheduling, and URLLC capabilities.
Hybrid Wired-Wireless TSN configuration
The stochastic nature of wireless networking does present challenges for time-critical applications, as do the unavoidable performance variations introduced by radio wave interference, propagation effects, physical obstructions, mobility, and roaming. When incorporating WTSN segments, network engineers must consider and account for these factors. Under a hybrid configuration model, wireless-specific system details can be abstracted, much like in the virtual bridge model. This creates a “wireless-aware” system, allowing minimal changes to the wired TSN network to accommodate the wireless segments.
For example: 802.1Qbv calls for the system to schedule protected windows for the delivery of time-critical traffic. In a hybrid system, the CNC can define a schedule that completes wired transmissions as fast as possible, leaving more time for the less-dependable wireless links. This approach accounts for potential variations on the achievable wireless link speeds without requiring re-computing the overall network schedule.
Conclusion
WTSN isn’t going to arrive all at once as a fait accompli. As wireless networks evolve, more TSN capabilities will come online. As this evolution continues, ensuring the continued interoperability of TSN across wired and wireless network segments will be paramount. Avnu Alliance has been taking the lead on enabling integration and testing of TSN across wired and wireless systems. Ongoing work in Avnu includes detailed use case requirements, performance validation, and testing specifications.
The work Avnu has undertaken to assess the performance and structure of future WTSN systems should allow device manufacturers and network owners/managers to plan for the future, imagining even life-safety critical systems than can reliably operate with no wires attached.
