Home5GTSN over 5G and Wi-Fi – how wireless TSN will be designed, deployed, managed

TSN over 5G and Wi-Fi – how wireless TSN will be designed, deployed, managed

There is a burgeoning consensus that Time Sensitive Networking (TSN) and wireless capabilities will combine to unlock standards-based, scalable, and highly flexible use cases. Resting on the foundation of open standards as defined in IEEE 802.1, TSN-based industrial networks will be able not only to manage automated operations, but to digest and react to data from multiple systems in real-time.

In this renaissance of highly transparent, digitally observable production pipelines, discrete systems, factories, and suppliers will be able to share real-time information across all segments of the network, both wired and wireless. This flow of time-sensitive data will fuel enhanced AI decision-making, greater efficiency, and expanding customization capabilities, among a whole host of other benefits.

For the moment, wireless TSN (WTSN) over Wi-Fi and 5G is in the early stages. But analysis of TSN capabilities and use cases in current 5G and Wi-Fi systems, as well related market requirements, by organisations including the Avnu Alliance, 5G-ACIA, and Wireless Broadband Alliance (WBA) has resulted in an emerging portrait of how the first WTSN applications will be manifest.

We have a fairly realistic idea of what TSN capabilities and applications will be supported by wireless systems at roll-out, as well as of how hybrid wired/wireless TSN networks will be designed and managed. In short, we have enough information to begin preparing for the arrival of WTSN in earnest.

TSN DOMAINS

TSN applications don’t require the 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. As we discuss expected WTSN capabilities below, it is assumed they will be supported throughout the TSN domain, but not the entire enterprise network.

Figure: Examples of CUC and CNC Wired and Wireless TSN domains

Alternatively, a TSN-capable LAN may be deployed as a standalone network. As WTSN applications emerge, they will primarily be segments of a larger TSN domain with both wired and wireless links.

The IEEE 802.1Qcc specification defines the network configuration and management models for TSN domains. Industrial applications primarily use a centralized model, where all endpoints are managed by a central user configuration device (CUC). A centralized network configuration (CNC) device handles scheduling and path management, configuring the TSN bridges.

A distributed system does not have such ‘god boxes’. All endpoints and network devices share status, scheduling, and so on with each other directly; this model is useful in professional audio/video (AV) applications.

TSN FEATURES

The most mature TSN features align nicely with the current market requirements for wireless applications and are likely to be implemented in the first round of WTSN products to hit the market. These include:

Time synchronization 

The ability to synchronize to a primary clock across the network, defined for TSN domains under IEEE 1588/802.1AS. Highly accurate time synchronization is necessary to support deterministic behavior. It’s also used to support other critical TSN mechanisms, including traffic scheduling, filtering, and policing. All TSN bridges must share a common application of ‘time’ – support for 802.1AS is a minimum requirement for a TSN-capable system, including WTSN systems.

In industrial use cases particularly, most applications call for multiple redundant reference clocks to increase reliability. However, it’s not necessarily a requirement that all nodes have the capability to house the primary clock. For most wireless applications, the reference clock can reside in the wired network.

Time synchronization accuracy across wireless links is expected to be on the order of 1µsec. 5G and Wi-Fi networks are demonstrably capable of meeting this bar. Extending TSN time synchronization over Wi-Fi has already been defined in 802.1As and 802.11 specifications. Support for TSN time distribution across 5G is defined in 3GPP Release 16.

Traffic shaping

The ability to prioritize traffic and allocate network resources based on time and traffic class is another foundational requirement for all TSN capable networks. In WTSN applications, traffic-shaping based on the 802.1Qbv (time-aware shaper) specification has been the initial focus for wireless systems, 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.

Industrial applications will rely on 802.1Qbv. This standard defines a set of time gates to control the queues associated with traffic classes on a TSN bridge. The system creates protected windows for critical time traffic during which any other interfering traffic is blocked. This approach was designed to support deterministic applications.

Figure: 802.1Qbv Gate Control Concept

In industrial applications, wireless segments will be required to support 802.1Qbv. Wireless systems within the TSN domain must be able to identify, prioritize, and deliver time-critical data within the appropriate time window.

Redundancy

Many safety critical TSN applications require both bounded latency and guaranteed delivery. To deliver on those two potentially conflicting objectives, the 802.1CB Frame Replication and Elimination for Reliability (FRER) standard was developed. According to 802.1CB, critical data is replicated on multiple streams travelling different network paths.

One link in the path may fail, but it’s highly unlikely that all of them will. The source devices attach a redundancy tag (R-TAG) to the link layer data frame before sending. Relays and endpoints use this tag to identify and eliminate redundant frames, keeping the network clear of unnecessary traffic.

Figure: Frame Replication and Elimination for Reliability from wired to wireless TSN.

FRER is invisible to the MAC/PHY link, so it should be able to operate over wireless technology. Still, it does introduce a lot of additional traffic to the network. The tradeoff between efficiency/capacity and reliability needs to be considered case by case. Redundancy is likely to be an optional capability used primarily in safety critical systems.

WTSN PLANNING 

Wireless networks that support TSN capabilities must be carefully planned, and coverage requirements and traffic profiles must be presented at the planning stage. Network and traffic engineering are performed at this state to properly select and configure TSN capabilities (time aware scheduling, for example). Coverage and site surveys may also be used to determine the required infrastructure (the number of access points/base stations, for example).

It is expected access to TSN-capable wireless networks will be managed by a central authority that can ensure access policies are enforced. Only authorized devices shall be able to access a TSN-capable wireless network. Authorized devices that access a TSN-capable wireless network may include devices with any combination of time-sensitive and best effort applications.

Not all authorized devices may require time-critical performance, but they all must implement and comply with the TSN capabilities required to provide the time synchronization and determinism benefits for time-critical applications.

WTSN ROLLOUT

Given the recent advances and features available in IEEE 802.11 (802.11ax/Wi-Fi 6/6E) and 5G, these two technologies are considered as candidates to enable TSN capabilities and integrate with wired Ethernet-based TSN. There are a few ways in which WTSN can be implemented in a network, which may be used depending on the wireless technology and overall network and TSN management capabilities.

Physical WTSN bridge

This model is applicable when both wired and wireless devices implement the same TSN reference protocol stack. In this case, both 802.3 (Ethernet) and 802.11 (Wi-Fi) share the same protocol stack. TSN-capable Access Points operate as wireless TSN bridges between wired and wireless domains, and 802.11 Stations (STAs/clients) operate as TSN end devices.

Virtual TSN bridge

Since 5G and Ethernet are governed by different standards, an interface will be required to incorporate 5G network segments into a wired domain. 3GPP Release 16 defines interfaces for allowing a 5GS system (5GS) to appear as a ‘virtual’ TSN bridge, providing a control plan interface and TSN ports at the user plane.

The virtual TSN bridge tunnels TSN traffic stream 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, traffic shaping, and redundancy – 5G clock synchronization, scheduling, and URLLC respectively.

Figure: “Virtual” TSN bridge concept and integration model with TSN

Hybrid Wired-WTSN 

It is well known that wireless communication is subject to performance variations due to random factors, such as propagation effects, interference, obstructions, mobility, and interference. It is important for TSN configuration to be aware of and consider certain wireless characteristics in the overall network management. A hybrid configuration model allows the TSN configuration to abstract certain wireless system specific details as in the virtual model while considering expected dynamics in wireless links to optimize the end-to-end network operation.

One important benefit of this model is to minimize changes in the wired part of the network by being wireless-aware. For instance, when scheduling protected windows (part of 802.1Qbv) as time-critical flow starting in the wired domain and ending with a wireless link, the CNC can define a schedule that completes wired transmissions as fast as possible and leaves more time for the wireless links to account for potential variations on the achievable link speeds without requiring re-computing the overall network schedule.

WTSN CONCLUSIONS

There is still work to be done to make wireless TSN a reality. Extending seamless operation and interoperability from wired to wireless TSN domains is going to be a significant technological challenge; this work is currently underway across various standardization groups and industry consortia. 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. As wireless networks evolve, they are expected to increase in TSN supporting capabilities, especially in resiliency to meet anticipated market requirements for industrial and other use cases.

By better understanding the fundamental benefits and role that TSN plays on a network, and how models for rolling TSN onto wireless networks, stakeholders can begin planning now for the inevitable, untethering the IoT and other time-sensitive applications from its wired infrastructure.

About Dave Cavalcanti

Dave Cavalcanti received his PhD in computer science and engineering in 2006 from the University of Cincinnati. He is currently Principal Engineer at Intel Corporation where he develops next generation wireless connectivity and networking technologies and their applications in autonomous, time-sensitive systems. He leads Intel Lab’s research on wireless Time-Sensitive Networking (WTSN) and industry activities to enable determinism in future wireless technologies, including next generation Wi-Fi and beyond 5G systems. He is Senior Member of the IEEE and serves as the chair of the Wireless TSN working group in the Avnu Alliance.

Previous post
The IoT mother lode? Qualcomm bundles 5G, Wi-Fi 6 into seven new edge-AI units
Next post
MultiTech buys Radio Bridge in LoRaWAN-based IoT sensor and services tie-up