A beginner's guide to selecting the right TSN switch for your system

First a little perspective:

Not all TSN switches are the same, similar to how all Bluetooth devices are not the same. In Bluetooth, some devices can play audio over wireless, some can transfer files, some can facilitate hands-free call, some can do multiple or all; the function lies in the profiles and Bluetooth is an umbrella standard defining them all. Similarly is the term TSN or Time Sensitive Networking. It is the collection of standards defining time-synchronized and low latency streaming services for a time critical network.

So What is TSN:

In simple terms, TSN augments the OSI Layer 2 (DLL) rules and functionalities to make Ethernet communication deterministic; and if you have worked on Ethernet for real-time network requirements, you realize how useful this can be; no more writing a custom DLL/LLC or traffic scheduler, and no more agonizing and running a thousand simulations to get the events and timings synchronized, or sometimes even creating a special MAC to offload network processing load; but I digress.

The spec:

Thus, TSN is not a monolithic standard governing every device specification, rather it is defined by a collection of inter-dependent and independent standards, which are added as part of existing IEEE 802.1 (the standard for LAN/WAN/MAN) and 802.3 (the standard for Ethernet) specification. Just selecting TSN does not mean all of the defined standards are supported by a device.

So, in this article, we are going to take a look at what are the different aspects of TSN standards and their impact on your system. If you are looking to deploy a TSN system or benchmark the system, this article helps you to choose a device that best suits your needs.

The standards:

Broadly, the collection of standards for TSN as part of 802.1 include 802.1Qav, 802.1AS-Rev, 802.1Qbu, 802.1Qbv, 802.1Qcc, 802.1Qci and 802.1CB.

What does this mean?

The standards listed above are followed or used based on the use case and design of the system. Not every device support all of the standards.

At the risk of stating a cliche of an example; let’s take a use case of a typical machine environment. Typically there are two types of traffic here, i.e. one for IT infra e.g. system diagnostics data, maintenance data, ERP data, etc., and one for the OT infra, e.g. the PLCs and sensors in the machines. These two traffic have different purpose and requirement and thus there are usually two different Ethernet backbones/networks for IT and OT traffic. The IT backbone connects the normal nodes in the network and carries bulk/stream data and the OT backbone connects the automation nodes and carries the real-time deterministic data.

With the standards defined in TSN, the IT and OT traffic can be converged into the same Ethernet backbone. The data traffic traversing across the network hierarchy (i.e. vertical data or IT traffic), does not have stringent timeline (i.e. they are not time critical), rather need better bandwidth allocation control. In this case traffic shaper (802.1 Qbv) shall be used. The OT data traffic (i.e. horizontal data) such as safety systems etc., require timely delivery with bounded latency and minimum jitter. In this case 802.1-AS, 801.Qbv shall be used.

From the application stand point, as the rule of thumb the typical standards used for respective domains are:

• Automotive – 802.1AS, 802.1Qbv
• Audio/Video (media streaming) - 802.1Qav
• Control systems - 802.1Qbv

So far so good, now how to select a device?

While selecting a device for your system, there are a few criteria you must evaluate in your system:

1. Is there multiple types of network traffic? All the traffic in the network are not time critical. The critical traffic is distinguished based on the tolerance level. The IT traffic (e.g. Best effort traffic) is not time critical but OT (e.g. Isochronous) traffic is. For exhausting list of traffic types visit: this site
2. Fastest data sampling rate: The number of samples per second for the most time critical data source.
3. Latency: The minimum amount of time to transmit a packet in the network, for different types of traffic.
4. Jitter: The maximum tolerable time variation in the latency of the time critical data transmission i.e. how deterministic the system is. This is will be typically determined by your OT traffic.
5. Bandwidth: The amount of data transmitted per second. This will be typically determined by your IT traffic.
6. Network size: Number of physical network devices and interconnections.

First step is to ask is 'do I need a TSN switch' ?

If any of the criteria above applies to your system, you need a time sensitive switch. When a greater number of devices participating in the same network require time synchronization and deterministic communication a standard Ethernet switches is replaced by TSN-capable switch that integrates the network nodes in a single network.

Next, which TSN hardware/switch suits my Application?

Currently, there are a number of TSN switch device manufacturers and players in the market.

From our experiments with TSN switches, we created a list of items below which you need to look for in the switch specification, while buying one:

1. Back to standards: Check what are the standards supported by the TSN switch. The best suit for

• Medium sized network to handle IT and OT traffic(let say < 30 nodes) - a switch with 802.1 AS, Qbv, Qav is sufficient. Since you dont need a lot of centralized configuration management and these type of switches are more straight forward to deploy.
• Large size network to handle complex network architecture with multiple hierachies (let say > 500 nodes) 802.1 AS, Qbv, Qav, Qat, Qch, and Qci is needed. Here the deployment and managing complexity increases interms on configuring the switches in each stratum layer

2. 802.1AS and IEEE1588 support:

• 802.1AS and IEEE1588 are not compatible. It requires a special hardware for bridging.
• All the devices in the TSN network shall speak in the same protocol(802.1AS or IEEE 1588)
• The benefits of TSN 802.1AS over IEEE 1588 profiles is accuracy and scalability.

3. RTC clock support- An RTC maintains the timestamp of the devices even after a power cycle

• Use case: In a larger network or topology; the TSN devices require the clock to be synchronized with a central master TSN switch(grandmaster). Every time a device in the network reboots, its clocks are synchronized to the central master. When the time difference between the devices are higher, the setup time is higher. In the absence of an RTC the device clocks revert back to epoch time after each power cycle which increases the network boot up time.
• Alternative to on-board RTC, an external I2C RTC clock (e.g. DS3231 RTC module with I2C interface) can help.

4. Real time performance – RT kernel support

• Most of the TSN switches in the market support Linux distribution. But not all distributions support RT kernel; if the data is produced at lower cycle time(higher frequency), the generic community kernel of the Linux distro does not promise time guarantee.

5. Netconf/Yang model for TSN configuration support

• In a fully centralized network configuration model, the TSN switches on-premise need to be configured using remote CUC network and avoid direct terminal access to the TSN switch. So, the TSN switch with 802.1Qcc support will be appropriate for this use case.

Finally, If you are buying a TSN switch, choose one that will accommodate your current needs and future expansion. Hope this guide helps you to define a list of criteria for your system, and match with the TSN device specification. We will update this guide as we continue with our experiments in our test rack on OPC UA TSN space.

Footnote:

We would appreciate your thoughts on the guide and whether it addresses your use case. Reach us at [email protected] or +91 900 399 9064

If you are interested in OPCUA and TSN related testing and benchmarks, below are two of our earlier posts which may be a good read for you:

opcuatsnadoption #s1: OPCUA Pub/Sub benchmarking:

opcuatsnadoption #s2: OPCUA Pub/Sub round trip time benchmarking: