Industry Article

The Fundamentals of Time-Sensitive Networking

Learn about the benefits of time-sensitive networking (TSN) and how engineers use it to ensure that an industrial system is ready for the future. This article focuses on three members of the set of TSN standards.

Different technology domains have their own set of unique requirements when it comes to predictability and time-sensitivity, which can present challenges for system designers looking to transmit data on a shared connection. Low latency and reduced time delays must be taken into account when utilizing a shared network. Fortunately, there is a solution to this challenge — time-sensitive networking (TSN). TSN sits on top of standard Ethernet and defines a set of standards for enabling system designers to use an Ethernet network to transmit IT and OT data on a shared connection. 

In this article, learn about the benefits of time-sensitive networking and how engineers use it to ensure that an industrial system is ready for the future. This article focuses on three members of the set of TSN standards, explains them in detail, and mentions a few devices that incorporate time-sensitive networking features into their hardware.


What is Time-Sensitive Networking?

In distributed systems with many devices, such as a modern factory floor, the connected devices might have very different needs and potentially conflicting goals for communicating with other components in a network. One way to look at the transmitted data is to view it in the context of information technology (IT) and operational technology (OT) domains. 

Operational technology traffic, such as machine control data and sensor values, typically requires the network to behave predictably. Communication in this domain requires fixed time delays, low latency, and low jitter. On the other hand, information technology traffic is data such as e-mail traffic and firmware updates, for example. Here, the timing constraints are not of utmost importance, and the communication is typically best-effort. 

While IT traffic typically requires more bandwidth, the data doesn’t need to reach the destination within a given timeframe. Instead, the overall throughput is what typically matters. For OT, on the other hand, missing data at a certain point in time can lead to failures, and therefore the data must reach its destination within certain hard real-time constraints.

Sometimes, engineers solve this problem by maintaining two separate networks — one for OT traffic and the other for IT infrastructure. TSN (time-sensitive networking) is a set of standards that build upon standard Ethernet, allowing OT and IT traffic to share the same network respecting each domain’s individual needs. TSN adds determinism to Ethernet by reducing network delays and lowering the latency between endpoints, ensuring that individual packets can reach their destination on time.


TSN Standards

As mentioned, TSN is a set of standards that sit on top of Ethernet. Each standard describes a different functionality, and system designers may choose to combine standards to tailor the network more towards their requirements. The following table gives an overview of the TSN standards (This article discusses 802.1AS, 802.1CB, and 802.1Qbv):


Figure 1. Some of the TSN standards have industrial use-cases. 


Timing and Synchronization for Time-Sensitive Applications with 802.1AS

The TSN standards originated from the precision time protocol (PTP, IEEE1588®). The main idea behind PTP is to synchronize the clocks of distributed machines within a network. PTP utilizes a clock-distribution tree, and typically there’s also a grandmaster, which is the source of all the timing. This grandmaster receives the time from a high-precision source — for example, a high precision GPS clock. The slave nodes within the network synchronize their local time to the time of a master node in a point-to-point fashion.

PTP served as the base for the TSN standards, and gPTP is part of the 802.1AS standard. PTP and gPTP share a lot of common terminologies, but there are also a few key differences. One such difference is that PTP sits on the transport layer of the OSI layer model, and it, therefore, permits many different underlying transportation methods. Other differences between gPTP and PTP are summarized in the diagram below. Newer revisions of gPTP bring back the ability to use one-step timestamps. Lastly, gPTP requires peer-to-peer delay mechanisms and expects all devices to be syntonized, which means that they have a standard frequency base and that all clocks are running at the same rate.


The differences between PTP and gPTP. 

Figure 2. The differences between PTP and gPTP. 


Engineers can employ the 802.1AS standard to synchronize tasks in a machine or across an industrial network. This article later introduces a synchronized motor control example that makes use of 802.1AS.


Creating Redundant Networks with 802.1CB

The 802.1CB standard allows system designers to create redundant communication streams over a network. A typical application is in a ring-topology network with multiple devices. Communication between devices is replicated and sent around each direction on the ring. If there is a break in the ring at any point, all devices will still be able to communicate with each other with no lost packets and without any delay incurred by a retransmission algorithm.  


A ring topology diagram with message redundancy.

Figure 3. A ring topology diagram with message redundancy.


Whenever a device (the talker) wants to communicate with another device (the listener) in the ring, it will send duplicate messages in different directions. This feature is implemented in hardware so that the TSN enabled switch duplicates the packet and inserts a redundancy tag that includes a header that identifies replicated stream and includes a sequence ID to allow the receiver to discard duplicates that it receives. The TSN-capable hardware in the listener receives the packets from both directions on the ring and detects the first unique packet. It then automatically discards any duplicate packets arriving later that use the same sequence ID. 

Offloading these tasks to the TSN capable hardware simplifies software development since it removes the need for complicated retransmission algorithms.

To use 802.1CB, the system designers must identify what traffic streams to replicate through the TSN capable switches. A few different methods exist, but at the core of each of them, the network switch replicates messages that match a predetermined pattern (e.g., all messages going to a device with a certain MAC address). 


Combining OT and IT traffic on a Single Network with 802.1Qbv

The 802.1Qbv standard utilizes a time-aware shaper, which is implemented on the egress port (outgoing port) of an Ethernet switch or standalone Ethernet controller within an SoC. The time-aware shaper determines when traffic can go out to the wire. The standard defines eight queues for different traffic streams and software configures these queues using a gate control list.


A schematic example of an 802.1Qbv schedule.

Figure 4. A schematic example of an 802.1Qbv schedule. The schedule contains two separate time regions (grey and blue) to separately transmit OT and IT data.


The gate control list sets the schedule at which the gates open to drain the traffic out of the queues. These lists are versatile and allow multiple gates to be open or closed simultaneously. It's also possible to set a unique time interval for each step through the schedule.

Each software application running on the device assigns traffic to a different queue, depending on the priority level of that application or the data it is transmitting. The mapping can happen by protocol, destination port, and certain traffic types (e.g., PTP over UDP).  All of the devices on a network are synchronized and managed, ensuring that critical data streams will not collide on the network and that they meet their real-time requirements.

The TSN hardware also automatically enforces a guard-band before each timeslot. This ensures that transmission of a large packet is not started right before a gate transition. Otherwise, a low-priority packet transmission might run over a higher-priority timeslot. The hardware inspects each packet before transmit, and if it can’t complete a packet during the current timeslot, the hardware will hold it until the next timeslot for this traffic class is available.


Software Enablement For Time-Sensitive Networking

NXP provides several software tools for utilizing the TSN features in the Layerscape® LS1028A and other microprocessors.


Open Source Software

For those who prefer open-source development platforms, NXP offers tsntool to configure all of the TSN features in the LS1028A, or alternatively, developers can use the tc command that is a part of the Linux iproute2 suite of utilities. Tc can configure the time aware shapers and steer application traffic to the different traffic queues. gPTP is supported through the ptp4l package.


Audio Video Bridging (AVB) and Time-Sensitive Networking (TSN) Stack 

NXP also offers a portable AVB/TSN stack that can run on both microprocessors and microcontrollers, providing an option for developers who need to deploy TSN over a scalable set of platforms.

The 802.1Qbv discussion above mentioned the Layerscape LS1028A software development kit (SDK) as one way to upload a gate control list to a TSN-capable Ethernet controller. The LS1028A is an applications processor based on two Arm® Cortex®-A72 cores that typically run Linux® OS or a different high-level OS or real-time operating system. 

The LS1028A includes a TSN-capable Ethernet controller as well as an integrated network switch that supports TSN. Furthermore, the LS1028A applications processor supports various security features such as cryptographic engines and a trust architecture. Besides, the device also incorporates 3D graphics acceleration and monitor support via DisplayPort (DP).

The LS1028A can run open industrial Linux, which is specialized for industrial use-cases. This enables the device to function in real-time environments and run low-latency processing (with xenomai Linux). Furthermore, the device can execute bare-metal code on one core and Linux, for example, on the other.

Additionally, NXP provides open-source support for TSN as well as tools to configure it. Within the open industrial Linux, NXP provides open-source driver support for PTP. These drivers allow users to control the PTP hardware clock and time stamping.

Part of the upcoming synchronous motor control example utilizes the commercial NXP AVB stack, which is the earlier iteration of some of the discussed standards. NXP will add TSN support in the future.

As an alternative to the Layerscape LS1028A, the i.MX RT1170 crossover MCU is another NXP device that supports TSN. This dual-core crossover MCU features a Cortex-M7 core that’s capable of running up to 1 GHz, as well as an embedded Arm Cortex-M4 core clocked at 400 MHz. 

This crossover MCU pairs lots of typical MPU IOs with high-performance microcontroller cores, display capabilities, advanced security, and features a TSN-enabled Ethernet controller.


A Practical Example: Synchronous Motor Control with TSN

In the following practical example, two motors have plastic disks with slots cut out attached to them, which must work together synchronously so that the disks don’t crash into each other. To accomplish this, an i.MX RT1170 MCU executes the task of coordinating the entire system by employing its 802.1AS capable Ethernet controller.


A high-level overview of the synchronous motor control example.

Figure 5. A high-level overview of the synchronous motor control example. The i.MX RT1170 MCU ensures synchronous operation of the motors, the LS1028A-powered network bridges ensure time-critical data gets transmitted in a different time frame.


The motors are hooked up to separate controllers that receive packets from the main coordinator. This data tells the motors when to move.

Network bridges forward the traffic between the components. In this example, the bridges use Layerscape LS1028A application processors. These devices are capable of combining OT and IT traffic using the TSN 802.1Qbv standard. With this approach, the motor control data gets transmitted in a different time-frame compared to IT data, which is randomly generated data in this example.

As mentioned earlier, it's possible to combine the TSN standards to meet the requirements of a specific application. This example shows exactly that. The main controller uses 802.1AS to establish a synchronized time-base, while the switches implement 802.1Qbv to shape the network traffic to ensure that time-critical data gets transmitted within the given constraints. This ensures that the motors can operate synchronously and as fast as possible.


Time-Sensitive Networking for Shared Connections 

IT and OT data have conflicting requirements — IT traffic typically consists of more data than OT traffic, and best-effort communication usually suffices. OT traffic, on the other hand, is time-critical. Typically, strict timing, delay, and latency constraints apply. With TSN, system designers can use an Ethernet network to transmit IT and OT data on a shared connection.

802.1AS synchronizes multiple devices within a network with an accuracy that’s within nanoseconds. This feature is available on many Layerscape, i.MX, and i.MX RT crossover MCUs and open-source and turnkey commercial software are readily available to support TSN.

With 802.1CB, system designers can introduce fault-tolerance to their systems by adding redundancy to an Ethernet network. With TSN capable hardware, the redundancy features are offloaded to the hardware. Doing so results in less overhead in the application software. This feature is available on the Layerscape LS1028A, and open-source software and drivers are available as well.

802.1Qbv introduces time-aware shaping to standard Ethernet networks. It provides low latency and low jitter transport for time-sensitive Ethernet traffic streams, and it reserves bandwidth for specific applications. The OT and IT traffic share a single network. This feature is also available on several NXP processors, and open-source and turnkey commercial software is available.

As shown in the motor control example, the different standards can be combined to fit a particular application’s needs.

NXP’s community page provides a host of forums, examples, application notes, and other information on NXP processors that can enable time-sensitive networking to allow for shared data connections.

Industry Articles are a form of content that allows industry partners to share useful news, messages, and technology with All About Circuits readers in a way editorial content is not well suited to. All Industry Articles are subject to strict editorial guidelines with the intention of offering readers useful news, technical expertise, or stories. The viewpoints and opinions expressed in Industry Articles are those of the partner and not necessarily those of All About Circuits or its writers.