Digging into the Details: Time Sensitive Networking (TSN)

October 242017
Digging into the Details: Time Sensitive Networking (TSN)

By Bill Lydon, Editor, Automation.com

Time Sensitive Networking (TSN) has been seemingly on fire as a hot topic at nearly every conference I have attended over the last 18 months. With the promise of connecting all devices in a single unifying network from sensor to enterprise, it’s small wonder why TSN is on the tip of everyone’s tongue. 

A unifying open network is not a new idea; this was the focus of the MAP (Manufacturing Automation Protocol) standard launched in 1982 and supported by 21 vendors by 1985.   MAP was not successful for a number of reasons: it was complex, the technology needed to support it was leading edge (some would say bleeding edge) and unreliable.  Yet the efforts of the past have helped shape the TSN effort, as the goals being promoted for TSN are similar for integration of real time industrial control, IT, OT, video, and data communications in general.  

I recently had the opportunity to discuss TSN with Belden’s Stephan Kehrer, who since 2012 has worked in the Future Technologies department within Belden’s Industrial IT platform. He has devoted himself to the analysis and evaluation of new and future technologies in the area of industrial communication. Stephan’s responsibilities include patent management, research projects and representing Belden in standardization committees. He is a member of various task forces of the IEEE 802 and IEC, with a specific focus on time-sensitive networking.

Belden’s Stephan Kehrer who is a member of various task forces including IEEE 802 is on the topic of time-sensitive networking (TSN) provded information on the standard.


Question: What is the status of the IEEE standard?

Kehrer: First of all, it has to be noted, that TSN is not one standard, but rather a family of standards. Essentially it is a toolbox with the standards serving as individual tools, each catering to a specific aspect or requirement of deterministic and reliable communication. As different standardization projects of the TSN family of standards have started at different times in the past, they are in different states of completion. Several of the TSN standards are already out and published, many others are close to completion and some are just being started.

That being said, the standards that are already published do provide the core functionality of TSN, including:

Time Sync

To achieve this goal, devices in the network first need to operate on a common, synchronized time base. This synchronization is provided by either IEEE 802.1AS-2011 or IEEE 1588. A revision of IEEE 802.1AS is currently in standardization.

Latency & Jitter

To achieve the goals of a low bounded latency and jitter there are different standards within the TSN family: scheduled traffic, frame preemption and different scheduling mechanisms. Scheduling is provided by the published standard IEEE 802.1Qbv-2015, frame preemption by the published standards IEEE 802.1Qbu-2016 and IEEE 802.3br-2016 and for traffic shaping IEEE 802.1Qav-2009 is available. More shaping mechanisms for different application requirements are currently being specified in the TSN Task Group. For additional robustness in TSN networks, there are filtering and policing mechanisms provided by the already available draft standard IEEE 802.1Qci-2017 and static redundancy will be offered by IEEE 802.1CB, which is in the final stages of standardization.

Editor’s Note: Shaping in TSN refers to scheduling and traffic shaping, methods that adjust data streams based on timing requirements.


Question: In what timeframe is it likely to be approved?

Kehrer: As already mentioned, there are quite a few standards that, together, comprise the TSN standards family. As work on some of the standards is just being started, it will still take some time until the very last of the standards from the TSN family is finished. However, the standards that are now just being started are mostly offering different ways to achieve goals already addressed in current standards or standardization projects, e.g. shaping of traffic. Therefore there is no need to wait for these standards to be finished, in order to start working with TSN. The existing standards can already be used with substantial benefit, with subsequent new standards offering additional functionality or alternative mechanisms to meet specific application needs.

That being said, the standards providing the mechanisms that are required for deterministic low latency traffic with IEEE 802.1 and IEEE 802.3 based standard Ethernet are already available today. Work on some improvements and additional mechanisms for special application needs will still be done for some years to come.


Question: How will the central network manager handle traffic from multiple protocols on the same network?  (Ex:  PROFINET, EtherNET/IP (CIP), video traffic, business systems, etc.)

Kehrer: The central network manager is a logical instance that has a global view on the network. It will know the devices in the network, their capabilities, links and link speeds with which the devices are connected and so on. This knowledge of the network topology and device capabilities of the devices on the network, together with additional application specific knowledge regarding communication relations and requirements between end devices, allows the central network manager to determine and specify the data streams within the network. This allows for an optimal utilization of the network and the coexistence of different types of traffic, i.e. real-time traffic, shaped traffic and best-effort traffic. As TSN is a technology providing communication at the data link layer (layer 2 of the OSI model), all higher layer protocols utilizing TSN for communication can be handled by the central network manager. In fact, the coexistence of the different classes of network traffic in one converged network is one of the great advantages, TSN has to offer.


Question: Will there be a vendor-neutral network traffic manager supplied by IEEE or other standards organizations?

Kehrer: As IEEE 802.1, the group where the TSN Task Group is located within the IEEE standardization organization is focusing on OSI layer 2, there will most likely be no standardized simple network traffic manager supplied by the IEEE TSN Task group. However, there are several other organizations that are currently looking at TSN and how to best use it within different areas like industrial or automotive. Whether these organizations will provide a vendor neutral simple network manager, or not, remains to be seen. At the very least, the goal of these organizations is to provide a standardized interface for a network manager. This way the manager can be chosen from the solutions of different vendors and easily incorporated in a network.


Scenarios for TSN Success

Scenario #1: I have a PLC with 30 points of data that I want to be sent to 4 other PLC’s for closed loop control every 10 milliseconds +/- 0.5 milliseconds maximum deviation. If I understand TSN correctly, a TSN network MUST have a central network manager to function.  Each node needs to notify the central network manager each steam of data it wants to schedule. 

So, if I need to schedule a stream of data specifying 10 milliseconds +/- 0.5 milliseconds maximum deviation, data size, and destination addresses to receive this packet: 

  • How are source and destination identifiers defined?   
  • How are data types defined?   
  • How does the destination receiver determine what application in the receiving PLC should receive the message?


Kehrer: First of all, it has to be said that TSN does not necessarily require a central network manager. Network management is covered in IEEE P802.1Qcc which discusses three possible network management approaches. The three models are: a fully centralized model, a fully decentralized model and a partially centralized model.

Fully Centralized - In the fully centralized model, end devices communicate their requirements regarding streams directly towards the centralized management system over a user defined protocol. The centralized management then collects the information and uses them to compute the necessary schedule of streams in the network to satisfy those requirements and configures the network devices accordingly.

Fully Decentralized - The fully decentralized management approach is similar to the Stream Reservation Protocol that is already in existence with AVB (Audio Video Bridging) (http://avnu.org/faqs/ ) today. Talkers announce the streams they offer and Listeners can subscribe to them. The network then reserves the necessary resources and time slots along the way. Whether the stream’s requirements can be satisfied is detected and computed in a decentralized way within the network. No central management entity is necessary in this approach.

Partially Centralized - The partially centralized approach does make use of a centralized network manager. However, the data from the end devices is passed to the edge bridge closest to the end device over a standardized protocol and then forwarded to the central management system. There are valid application scenarios for each of these approaches.

As TSN is a pure Layer 2 communication protocol, specifics like data type definitions of the payload data or mapping of data to specific applications within the receiving PLC are not part of the TSN specification. TSN stream identification is defined in “IEEE P802.1CB - Draft Standard for Local and metropolitan area networks — Frame Replication and Elimination for Reliability”. It offers several different ways to identify streams, e.g. based on destination MAC address and VLAN identifier, source MAC address and VLAN identifiers and others. Stream Identification based on this standard is used to compute the flow of data for a specific stream through the network as well as handle redundant paths for seamless redundancy for fault-tolerance.


Scenario #2: I have a PLC with 500 I/O points and 2,000 register values with multiple timing requirements for data.  For example:

  • 30 points of data 4 other PLC’s for closed loop control every 10 milliseconds +/- 0.5 milliseconds maximum deviation
  • 100 points of data sent to 12 separate drives .5 milliseconds +/- 0.01 milliseconds maximum deviation
  • Balance of communication 100 milliseconds +/- 1.0 milliseconds maximum deviation

So I have three separate streams that need be scheduled by the application engineer in a TSN environment, coordinating the program at the destinations.  It would seem that the TSN message frame needs to have a “slot” to define the protocol being carried (i.e.: PROFINET, EtherNET/IP, OPC UA, SOAP, etc.)

Since there isn’t an industry-wide, network manager API/protocol standard, are the vendor applications of TSN at best a highly niched gated ecosystem?

Kehrer: As TSN is a layer 2 communication protocol, it can be used at networking layer 2 to transport different higher level industrial protocols, very similar as with Non-TSN Ethernet today. For example, the time slot for Ethernet frames is determined by their CoS (Class of Service) priority value in the VLAN tag. Through VLAN tagging, Ethertype, MAC addresses and the mapping of industrial automation applications to TSN stream IDs, protocols such as OPC UA can interface with the Layer 2 mechanisms. The basic architecture is exactly the same as with Ethernet today – with TSN providing more interfaces than just the Ethertype or MAC addresses to identify a higher layer protocol. The use of the new mechanisms is completely optional and can be phased in as the application requires.

The SERCOS Example

For example it has been shown by SERCOS and Hirschmann, in a demonstrator setup, that SERCOS III frames can be transported over a TSN network, mainly using a specific VLAN configuration. In this concrete demonstrator setup a SERCOS Softmaster was located remotely from the SERCOS III drives. The control data was transported from the Softmaster to the drives over a TSN Network consisting of Hirschmann RSPE35 switches with a TSN enabled firmware. The same holds true for most other industrial real-time Ethernet protocols. Therefore, TSN should not be regarded as a “highly niched gated ecosystem” but rather as an enabler for standardized real-time Ethernet, providing a common transport layer protocol for most of the existing vendor specific real-time Ethernet protocols that exist today, based on open IEEE standards.


Bill’s Thoughts & Observations

After the fascinating discussion with Kehrer, it is my view that TSN holds a lot of promise, but there’s still many open-ended issues.

There is hope that TSN will be adopted by the automotive industry, in order to drive down cost based on high volume consumption. This could be a major positive factor, but TSN is not the only network standard competing for vehicle applications and there is no clear winner at this point in time.

Networks in today’s automobiles are tightly-bounded, highly-defined applications with common use cases among thousands of cars and models.  Industrial automation applications and use cases, on the other hand, are unbounded with wide variations by industries and plants.   This is why I believe there needs to be a great deal more development efforts to create TSN standards and tools that can be easily used by industrial automation and control application engineers.

In discussions with various vendors, many seem to want to be the owner of the network manager that resides in the computer, a master PLC, network router, or other device.  It seems to me, like this could create vendor controller gated ecosystems. 

Fundamentally, any physical network has a finite bandwidth and the more data streams added to the network, the higher the increase of bandwidth utilizations.

In any TSN network configuration, when a device is added to the network, there is a latency time for the network to recast, which is currently unclear.

Regardless of the uncertain future, it will truly be interesting to watch how TSN evolves….


Related Articles