An Inside Look at What Makes TSN Tick
In a previous blog, Changing the Face of Automation Networks with TSN, we talked about the what and why of Time-Sensitive Networking (TSN). Now that we have a good understanding of what it is and why it is used, we will focus on outlining how TSN works and what makes it tick.
How TSN works is described in a set of standards developed by the Institute of Electrical Electronics Engineers (IEEE). The standards are developed by the IEEE 802.1 working group and are organized in a set of individual specifications. Each document describes a distinct TSN function. IEEE 802, in general, breaks down every new technology into individual functions and then sets specifications for each function to make it more manageable.
The key to IEEE 802 and its success is simple – all technologies are in a perpetual renewal process. This is also the case for TSN: Some standards are finished, others are in progress (in specification) and some are on the to-do list (in preparation to start the specification). With that being said, this is a normal situation for Ethernet technology: Ethernet and TSN make up an ever-evolving and powerful ecosystem. Despite this continuous renewal, Ethernet’s commitment is to remain scalable and backward compatible – which is also achieved by TSN. These are the main reasons Ethernet and TSN have been and continue to be so successful.
TSN Functions and Standards
It is important to note, a device marketed as “TSN compatible” doesn’t necessarily support all TSN standards. This means that you can have some of the standards and not have others. For example, you can use the Time-Aware Scheduler with or without frame preemption and vice versa. Implementing both significantly increases performance, but it isn’t always necessary. Some devices operate just fine with only one of those functions.
Synchronizing Time Across the Network
The term “time-sensitive” is a dead giveaway that time plays a major role in TSN. The importance of having all devices on a network to agree to a set time makes sense. Just think about when you plan to meet a friend for lunch. If your clock shows 12:30 when your friend’s clock is set to noon, assuming you’re both “on time,” you’ll be a half hour early, or your friend will be a half hour late.
Likewise, with TSN, all devices and switches must be synchronized to ensure that everything arrives on time. For all devices in the network to coordinate their actions, such as scheduling Ethernet frame transmissions and opening and closing transmission gates, they must be operating on an agreed-upon time. Even the best scheduling schemes are ineffective if the devices aren’t executing them in sync.
Although time synchronization is essential, IEEE isn’t very strict about which time sync protocol is used. However, it’s important that all devices are compatible and can synchronize to each other. When purchasing TSN-enabled devices, also consider the quality of their time synchronization — the tighter and more precise the synchronization, the better. Lower quality synchronization requires network designs that leave larger margins for error, which reduces TSN performance.
Directing Traffic with Real-Time Scheduling
TSN uses several scheduling mechanisms to carefully coordinate communications across the network. Strict adherence to the schedule ensures that the individual communication flows with various priorities don’t interfere with one another. Interference would result in jitter, which would cause transmission delays in the Ethernet switch queues.
TSN specifies different traffic schedulers and shapers for various application scenarios. It is important to mention, that the number of network traffic management tools will very likely increase in the years to come, as larger TSN deployments will likely need tools to support the engineering of these networks.
Maintaining a Reliable Communication Stream
TSN is often referred to as deterministic Ethernet, which means the network is predictable. TSN synchronization and scheduling go a long way toward achieving deterministic Ethernet, but IEEE has additional standards to make scheduling more feasible and to maintain a reliable communication stream.
Network protocols are designed with resiliency in mind. Whether you’re exchanging email, downloading files or accessing web pages across a network, the transmissions must be reliable. This reliability is even more important for mission-critical communications on time-sensitive networks.
To prevent transmission failures, networks use various redundancy protocols, which all operate on the basis of the following principle: If one network cable or device fails, the redundancy protocol enables the network to automatically recover from the fault. Redundancy protocols work by using different secondary transmission paths through the network to maintain the communication while the primary path is being repaired. There are two general categories that are accepted with TSN: seamless redundancy and non-seamless (failover) redundancy.
- Seamless Redundancy: All network paths are used in parallel, so no disruption occurs if one path fails.
- Non-seamless (failover) redundancy: The protocol recovers the fault by switching from the primary path to the secondary path. Although this switch occurs quickly, it may result in a very brief disruption of communication.
Reserving Bandwidth Using Stream Registration
Stream registration involves reserving bandwidth for devices on the network, which provides the communication between these devices with a certain service guarantee. During an exchange between the two devices, one device is the talker, which publishes the stream, and the other is the listener, which receives the stream.
The switches in the network register the publication and reception of communication streams along the transmission paths. Registration ensures that the available network bandwidth is not overbooked. Switches can turn down the registration of new streams if the required bandwidth of a new stream would exceed the maximum available bandwidth on a device port.
White Paper: Time-Sensitive Networking
Webinar: The Magic of Real-Time Communication