Time-Sensitive Networking (TSN): A Guide to Deterministic Ethernet

Time sensitive networking (TSN) is a set of IEEE 802.1 standards that add determinism to standard Ethernet: bounded, guaranteed latency and tightly controlled jitter for the traffic that needs it, on the same network and hardware that carries everything else. It exists because control, motion, sensor and safety traffic increasingly share a network with ordinary data, and that critical traffic cannot tolerate the variable delay of best-effort Ethernet.

TSN lets time-critical and best-effort traffic coexist on one converged network while still guaranteeing that the critical streams arrive on time. It does this with four ingredients: a shared clock in every device, a schedule that reserves transmission windows, a way to stop long frames getting in the way, and redundancy that survives a broken link without a recovery pause.

This guide sets out the TSN standards with their numbers and what each one does, explains how the time-aware shaper works with a worked timing example, compares TSN with PTP, a standard managed switch and fieldbus, and covers the configuration models, the industrial protocols that run over TSN, and the hardware you need at every hop. It ends with a checklist, examples from our range and answers to the questions engineers ask most.

TSN is not one standard but a toolbox maintained by the IEEE 802.1 Time-Sensitive Networking task group. Most of the individual amendments have since been rolled into the base bridging standard, IEEE 802.1Q, so a datasheet may list either the amendment name or simply 802.1Q. The table lists the parts industrial buyers meet most often, with the year each amendment was first published.

TSN grew out of Audio Video Bridging (AVB), which used 802.1AS and the credit-based shaper to carry synchronized audio and video. Industrial and automotive users added the scheduling, preemption and redundancy needed for control traffic. If you want the background on clock synchronization itself, our white paper on IEEE 1588 for machine vision covers the protocol that 802.1AS is built on.

Standard Ethernet is best-effort: it forwards frames as quickly as it can, but under load a critical frame can sit behind a long bulk-data frame, and the delay varies from one moment to the next. For email or file transfer that is invisible; for a motion controller, a safety interlock or a sensor-fusion loop it is unacceptable, because those systems need to know that a packet will arrive within a fixed, repeatable window.

Historically that meant separate, purpose-built networks: a fieldbus or a proprietary real-time Ethernet for control, and an ordinary network for everything else. TSN brings the guarantee onto standard Ethernet, so one network can carry both the deterministic control traffic and everything else, with standard silicon and standard tools.

Why priority alone is not enough

A managed switch with quality of service already puts urgent traffic in a higher-priority queue. That helps, but it is still best-effort under contention. A switch cannot stop sending a frame once it has started, so a critical frame that arrives just after a maximum-size best-effort frame has begun must wait for it to finish. On a Gigabit link that wait is about 12 µs per hop; on a 100 Mbit/s link it is about 123 µs. Across several hops, with queues of variable depth, the worst case adds up and is hard to predict. TSN removes that uncertainty by scheduling when each class may transmit.

The time-aware shaper divides time on each port into a repeating cycle. A gate control list says, for each slice of the cycle, which queue gates are open. In the simplest industrial schedule there are two windows: a protected window in which only the critical queue may transmit, and an open window for everything else. Because every device shares the same clock, the protected windows line up hop by hop, and a critical frame forwarded inside its window never waits behind other traffic.

Just before each protected window sits a guard band, during which no new best-effort frame may start. Without preemption, the guard band has to be as long as the largest frame that could be in flight. With preemption it shrinks to the smallest piece of a frame that cannot be split, which returns most of that time to best-effort traffic.

Worked example: a 500 µs control cycle on Gigabit Ethernet

Take a machine with a 500 µs control cycle on a Gigabit network, where the controller sends a cyclic frame to each drive and every drive replies within the cycle. The figures are illustrative; real schedules come from the configuration tool.

The point of the example is the bound. However busy the best-effort side becomes, the control frames see the same delay every cycle. The overall latency is the sum of known parts: forwarding delay in each switch, the cable, and the position of the window in the cycle. Published industrial demonstrations show cycle times well under a millisecond on Gigabit links, but the achievable figure depends on the number of hops, the traffic mix and the devices.

A TSN network has to be told which streams exist, what bandwidth and latency each needs, and which path it takes. IEEE 802.1Qcc defines three ways to do that, and which one a product supports affects how the system is engineered and commissioned.

In practice, many industrial projects today configure schedules with the switch or controller vendor’s engineering tool, which plays the CNC role. Network design still matters: VLANs separate traffic types, and the priority code point in the VLAN tag is how frames are mapped to TSN queues.

It is easy to conflate these. IEEE 1588 PTP, and its TSN profile 802.1AS, provides timing: synchronized clocks. Timing alone does not guarantee delivery. A standard managed switch can prioritize traffic with QoS, but prioritization is still best-effort under contention. TSN adds the scheduling, preemption and redundancy that turn high priority into guaranteed within a bound. For how PTP itself works, including grandmaster, boundary and transparent clocks and the delay measurement behind sub-microsecond accuracy, see our explainer on Precision Time Protocol.

Ring protocols and spanning tree still have a place on TSN networks for the best-effort side; our FAQs on network redundancy and RSTP explain the recovery times involved. Crucially, TSN has to be supported end to end: every switch in the critical path must be TSN-capable, which is why the switch hardware matters. Our guides to managed vs unmanaged switches and Layer 2 vs Layer 3 switches cover the rest of the switching decision.

Gradually, and mostly by carrying the same protocols over a converged network rather than replacing them outright. TSN is a set of Layer 2 mechanisms; it does not define the application protocol. The automation protocols are being adapted to run over it, so the device behavior engineers know stays the same while the network underneath becomes standard Ethernet with guarantees.

Our FAQs on OPC UA and EtherNet/IP cover those protocols, and the white paper on OPC UA vs MQTT explains where each sits in an IIoT architecture. For new plants, TSN means one cable and one switch family for control, vision and IT traffic. For existing plants, the fieldbus stays in place until the next major refit, and gateways bridge the two.

TSN started in professional audio and video and in industrial automation, and has spread to any domain that wants to converge real-time control onto Ethernet. The common thread is convergence: replacing several single-purpose networks with one deterministic Ethernet backbone.

In vehicles, many of those links run over single-pair Ethernet, and how automotive-grade single-pair Ethernet is moving into industrial and edge AI computers covers that physical layer. In machine vision, scheduled traffic keeps GigE Vision camera triggers and image transfers from interfering with control. In substations, TSN sits alongside IEC 61850 process bus traffic, where the timing requirements are already strict.

Three things must line up: the switches, the network interfaces in the end devices, and the software stack. A TSN-capable switch in the middle cannot help a computer that timestamps in software and transmits whenever its driver decides to.

A network interface card with TSN support can add the capability to an existing computer, provided the operating system and drivers support it. In our range, the Vecow PE-6004 card uses four Intel I226-IT controllers with IEEE 1588, 802.1AS, 802.1Qav and 802.1Qbv support. Computers such as the Vecow SPC-7100 and the EMBC-5000 3.5 inch SBC carry an Intel I225-IT 2.5GbE port with TSN support, and many of our Intel industrial PCs list TSN and TCC on their Intel I225 or I226 ports.

Where this fits in our range

Deterministic networks need TSN-capable switches throughout, and for rugged and defense systems those switches also have to survive the environment. The Diamond Systems EPS-9600 family brings TSN and IEEE 1588 PTP to a board-level, −40 to +85 °C switch with eight Gigabit copper ports and two 10G SFP+ sockets. Its TSN builds fit a ZL30732B TSN clock and bring out a PTP/PPS signal. Diamond Systems designs and builds the board; we supply it. The same switching technology is used inside Diamond’s fully built rugged Ethernet switches, and our article on how a military Ethernet switch is built shows how a board-level core becomes a sealed system. For OEM designs that need the switching core on their own carrier, see our guide to embedded Ethernet switch modules. Browse our industrial Ethernet switches for the wider range.

Four products from our catalog with TSN support, from a switch board to the computers and the card at the end of the link. Figures are from each product’s page.