Deterministic Ethernet Communication for Time-sensitive Applications - Part 2

Author: Jonas Gesch

Job Title: Field Application Engineer
 

Feature Introduction – TSN Part 2

Introduction

In Part 1 of this series, we examined the fundamental challenges of standard store-and-forward Layer 2 Ethernet switches in hard real-time industrial applications and introduced Time-Sensitive Networking (TSN) as a group of standards that extend conventional Ethernet with deterministic communication capabilities. Unlike standard best-effort Ethernet, where queuing delays and network congestion introduce unpredictable latency and jitter, TSN defines high-priority streams and provides them with mechanisms required to deliver bounded latency, precise timing, and reliable delivery for time-critical traffic while allowing standard Ethernet traffic to coexist on the same physical infrastructure. 

We also established that time-scheduled TSN features require a unified, nanosecond-level time reference across all network nodes. This foundation is provided by IEEE 802.1AS (gPTP), which uses hardware-level timestamping, Peer-to-Peer link delay (Pdelay) measurements, and local clock drift compensation (Neighbor Rate Ratio) to achieve strict nanosecond-level clock synchronization across Time-Aware Switches and end-stations. 

If you are interested in learning more about the basic concept of TSN and how gPTP is able to synchronize all devices in the TSN network to a shared reference time with nanosecond-level accuracy, it is worth looking up Part 1 of this article series first before returning to Part 2.

Achieving Determinism with TSN Standards
The strength of TSN does not stem from any individual standard, but rather from how these standards interoperate with each other. With gPTP, TAS, Frame Preemption and PSFP working together, it is possible to achieve deterministic communication, while FRER adds seamless reliability. The simplified TSN data path in Figure 1 that was introduced in Part 1 illustrates at which points in the switch architecture these features operate. As a frame enters a TSN switch, IEEE 802.1Qci Per-Stream Filtering and Policing (PSFP) validates that the traffic conforms to configured stream policies, such as TAS scheduling, before it enters the ingress queue. IEEE 802.1CB Frame Replication and Elimination for Reliability (FRER) removes duplicate frames received from redundant paths and, when required, replicates outgoing frames to provide seamless redundancy across multiple network paths. After traversing the switch fabric, frames are placed into egress queues where the IEEE 802.1Qbv Time-Aware Shaper (TAS) controls queue gates to schedule transmissions into precisely defined transmission windows that rely on highly accurate gPTP time synchronization. Finally, IEEE 802.1Qbu Frame Preemption operates at the MAC layer, further optimizing TAS by allowing the temporary interruption of lower-priority Ethernet frame transmissions so that time-critical traffic can be forwarded with minimal additional latency.
 

 

With the overall TSN concept and architecture established, Part 2 examines each of these mechanisms in detail, explaining how TAS, Frame Preemption, PSFP, and FRER work together to transform standard Ethernet switching into a deterministic communication platform capable of meeting the stringent timing and reliability requirements of modern industrial real-time networks.

IEEE 802.1Qbv TAS – Scheduling High-Priority TSN Streams
Although IEEE 802.1AS gPTP synchronizes clocks across the network, synchronization alone does not improve the determinism of a network. This is why the Time-Aware Shaper (TAS) is responsible for the precise scheduling of data transmission for high-priority TSN streams. Just like a high-speed train would be guaranteed priority at a railroad crossing (see Figure 2), TAS guarantees that the high-priority traffic can pass through the switch quickly while halting best-effort transmissions to prevent any delays. Since gPTP precisely synchronizes the system clock of all TSN-capable devices to a common time reference, the Time-Aware Switches can coordinate the transmission of frames and know exactly when high-priority traffic is scheduled to arrive.
 

 

TAS achieves this precise level of control by placing gates at the end of each egress queue that can be either in an open or closed state, much like the barriers at the railroad crossing. Ethernet switches implementing IEEE 802.1Q typically provide eight egress queues per port that are assigned to different priority levels according to eight PCP classes. Frames placed in one of the egress queues can only be transmitted if the corresponding gate is opened. The times at which gates for each of the queues open or close are defined in a Gate Control List (GCL) as seen in Figure 3 which is repeated in a fixed cycle.  
 

However, simply closing and opening the gates at the scheduled time is not enough to guarantee delay-free transmission of high-priority frames. Even if the TAS gates for best-effort traffic have already closed, a frame that is mid-transmission can still cause delay due to head-of-line blocking for high-priority traffic as demonstrated in Figure 4. To make sure that no best-effort frame is still being transmitted when the high-priority traffic gate opens, TAS adds a guard band period immediately before opening it. During this guard band time, active best-effort transmissions can still be completed, but no new transmissions are allowed to be started. To ensure that all remaining transmissions are completed during the guard band time, its duration is set according to the maximum allowed payload size referred to as Maximum Service Data Unit (Max SDU). 
 

Using a sufficient guard band period guarantees transmission priority for TSN streams and improves determinism at the cost of higher delays for best-effort traffic. Depending on the configured TAS parameters and network utilization, this can become a significant issue, even leading to priority starvation for best-effort traffic.¹  As a solution, Frame Preemption offers a mechanism to reduce bandwidth waste caused by the guard band without compromising hard real-time performance.

 

Why TAS (IEEE 802.1Qbv) Matters:  
• Guaranteed bounded latency: Schedules dedicated contention-free transmission windows for high-priority traffic to minimize delay and jitter.
• Protects critical control loops: Guarantees nanosecond-level timing for time-critical motion control, PLC-to-PLC communication, and robotics.
• Mixed-priority network convergence: Allows the use of the same physical network infrastructure for critical real-time communication and standard best-effort Ethernet traffic.

IEEE 802.1Qbu Frame Preemption – Solving the Guard Band Problem
As discussed in the previous section, TAS uses a mechanism called the guard band to ensure that no frame transmissions are active once a high-priority TAS gate opens to prevent head-of-line blocking for time-critical frames. However, as shown in Figure 5, whenever the guard band is active or the best-effort gates are closed and no high-priority frames are being transmitted, the egress port remains idle which reduces the overall usable bandwidth. This effect gets worse with an increased Max SDU parameter, faster cycle times or more high-priority gate open operations per cycle, eventually leading to bandwidth starvation and massive delays for best-effort traffic.

 

 

Frame Preemption is a TSN mechanism specifically designed to mitigate the negative effects of the TAS guard band on bandwidth utilization. It ensures that high-priority traffic can pass immediately with minimal delay by temporarily interrupting best-effort traffic, much like an emergency vehicle is granted priority over normal road traffic at a traffic light. Depending on the egress queue, Frame Preemption classifies traffic into normal preemptible frames and express frames² , with the latter usually being part of high-priority streams. It guarantees low latency for the express frames while significantly reducing the required guard band period, which in turn increases the usable bandwidth for best-effort traffic consisting of normal frames. Figure 6 shows how Frame Preemption achieves this with the example of a best-effort preemptible frame from Switch A starting to transmit to Switch B shortly before a high-priority express frame is being queued. Frame Preemption allows the express frame to interrupt the active transmission, causing the preemptible frame to be split into frame fragments. After sending out the entire express frame, the remaining preempted fragment continues transmitting. The receiving Switch B then reassembles the fragments received from Switch A into the full preemptible frame at the ingress port. Finally, the reassembled frame is queued into the ingress buffer after the HP frame.

When Frame Preemption is enabled, the TAS guard band can be automatically reduced to the time required to complete a minimum fragment size of 64 bytes plus overhead. Compared to 1522 bytes for a standard Ethernet frame, this results in saving more than 90% of bandwidth that would otherwise be wasted by the guard band. While the IEEE 802.1Qbu standard defines the high-level management mechanisms, it also relies on support at the physical MAC level, which is defined in IEEE 802.3br. Since the preemptible frames need to be reassembled by the receiver after being fragmented during the transmission, both the sending and the receiving switches need to provide hardware support for Frame Preemption and enable it in the configuration, which is usually verified with the IEEE 802.3br Link Verification protocol via LLDP³ . 

Why Frame Preemption Matters:  
• Interrupting preemptible traffic: High-priority frames can preempt active best-effort transmissions.
• Eliminates head-of-line blocking: Prevents large best-effort or Jumbo frames from delaying time-critical Express frames at switch egress ports.
• Minimizes bandwidth loss: Shrinks the TAS guard band window from full-frame transmission times (1522 bytes) down to a minimal 64-byte fragment window.
• Enables ultra-short TAS cycle times: Allows network architects to configure microsecond-level GCL cycle times without starving lower-priority background traffic.


IEEE 802.1Qci PSFP – Enforcing Traffic Scheduling at Port Ingress
Even perfectly scheduled networks remain vulnerable to disruptions if end stations fail to follow their assigned schedules. The primary purpose of Per Stream Filtering and Policing (PSFP) is to protect critical network traffic from being overwhelmed by rogue devices, malfunctioning ‘babbling idiots’, or cyber threats that inject traffic outside of their allocated schedule or bandwidth. Incoming frames are first associated with a TSN stream or stream collection based on their configured stream identification parameters. PSFP then matches the identified stream to its assigned stream filter and evaluates whether the frame is allowed to enter the ingress queue. Any frames that violate at least one of the filter criteria are either silently dropped or cause the entire stream to be blocked as a protection measure.⁴

A stream filter consists of a combination of 3 filtering mechanisms:
1. Max SDU Size Check
The filter simply ensures that the size of any received frames is within the specified Max SDU limit. 
2. Stream Gates
The stream gate is used in combination with TAS scheduling. Similar to how the TAS gates control when streams are allowed to transmit frames from the egress queue, stream gates control the timing at which individual streams are allowed to be received into the ingress queue. The scheduled times of the TAS gate and stream gate therefore need to be coordinated with each other while factoring in the peer delay.
3. Flow Meter
Uses token-bucket rate limiting to ensure that the streams remain within an allocated bandwidth.
 

 

Why PSFP Matters:  
• Reliable real-time communication: Ensures that real-time and background traffic comply with their time slots scheduled by IEEE 802.1Qbv TAS.
• Prevents ingress queue overflow: Keeps input buffer space free for time-critical frames in case of traffic bursts.
• Isolates malfunctions: Prevents non-compliant or rogue traffic from impacting other TSN streams. 

 

IEEE 802.1CB FRER – Zero-Recovery-Time Redundancy
While the previously discussed features all focus on increasing determinism for time-critical communication, even near-perfect determinism breaks down immediately if a single link failure can interrupt communication. For this reason, the TSN standard group includes Frame Replication and Elimination for Reliability (FRER), which provides seamless redundancy for TSN streams. It functions somewhat independently from the aforementioned standards since it is not a time-scheduled TSN feature and provides multiple redundant transmission paths in a Layer 2 network while relying on the underlying network topology or loop prevention mechanisms. Most common fast-failover redundancy protocols like RSTP or ERPS allow recovery times lasting from 50 milliseconds up to 6 seconds, during which any packets transmitted on the other side of a link failure are usually lost. In contrast, FRER provides zero-failover-time redundancy for TSN streams by replicating frames onto multiple redundant physical paths. Should one of the physical links fail, the replicated packets will still be received over the redundant path(s) without any of them being lost or dropped. This is especially important for devices requiring extreme reliability like controllers which rely on strictly scheduled, consistent communication and that can’t tolerate any missing frames.
Figure 8 demonstrates how FRER can be applied on individual TSN streams between a talker (source) node and a listener (destination) node or on stream collections consisting of multiple streams. Since TSN streams are unidirectional by design, FRER also only operates in one direction from a talker to a listener. FRER operates either directly in the talker/listener end-stations if they support it natively or in neighboring edge switches. The switch connected to the talker replicates ingress frames from the talker’s TSN stream. During replication, FRER adds an R-Tag to each frame containing an incrementing sequence number. After the packets traverse the redundant paths through the network, the switch connected to the listener then performs the frame elimination. Of all ingress frames with matching sequence numbers, only the frame that arrived first is added to the ingress queue (see Page 1, Figure 1). Any following frame is considered to be a replica and will automatically be dropped without occupying switch buffer memory. The switches along the redundant paths between the packet replication and elimination do not take part in the FRER mechanism.
 

 

Compared to other zero-recovery-time redundancy protocols like HSR/PRP which operate on all data traffic, FRER is configured individually per stream. This allows for granular control over which critical data streams are replicated and how often, avoiding unnecessary bandwidth usage due to replication of data traffic that does not require zero-failover-time redundancy. There is also significantly less additional hardware needed when designing a redundant network architecture with FRER compared to PRP, which requires full device redundancy with separate networks.⁵
In practice, FRER is typically used in combination with another redundancy protocol that supports multiple VLAN instances like MSTP or ERPS. For example, background data traffic can be protected from causing uncontrolled loops with MSTP while mission-critical TSN streams use FRER instead. Consequently, it is crucial to exclude the FRER VLAN from being blocked by MSTP, which is why the background traffic ring protection protocol needs to support per-VLAN instances. Otherwise, all redundant FRER paths except one would automatically be blocked and FRER would be rendered ineffective.


Why FRER Matters:
• Zero-Recovery-Time Failover: Transmits identical frame copies over multiple redundant physical paths to ensure seamless communication with no packet loss on link failure.
• Granular Stream-Level Replication: Preserves bandwidth by applying redundancy strictly to mission-critical TSN streams rather than duplicating all network traffic.
• Transparent Intermediate Forwarding: Allows switches along the redundant path to forward R-Tagged frames without requiring native FRER hardware support or processing overhead.
• Coexistence with Ring Protocols: Integrates smoothly alongside multi-instance loop-prevention protocols (e.g., MSTP or ERPS) by placing FRER traffic on dedicated unblocked VLANs.


Summary

The utilization of standardized features like gPTP, TAS, Frame Preemption, PSFP, and FRER provides TSN with the capability to transform standard Ethernet into a deterministic, fault-tolerant network architecture. By addressing clock synchronization, traffic scheduling, queue blocking, traffic policing, and link failures within a single store-and-forward switch pipeline, TSN enables mission-critical control loops and high-bandwidth background traffic to safely share the same physical infrastructure. As a result, this technology allows for more uniform network architectures and further contributes to enabling IT/OT convergence in factory automation and industrial AIoT networks.
To see how these standards are implemented in industrial hardware, explore Volktek’s industrial TSN switch portfolio, including the 9561-8GT4XS-TSN and the btPoE-enabled 9561-8GP4XS-TSN.

FAQ
Q1: Can standard legacy Ethernet devices be used in a TSN network?
Answer: Yes. Non-TSN Ethernet traffic is treated as best-effort and processed using standard store-and-forward behavior alongside high-priority TSN streams. However, to guarantee real-time bounded latency end-to-end, every switch along that specific TSN stream’s path must be TSN-capable. Placing a non-TSN legacy switch in the middle of a stream path introduces unmanaged queuing jitter and breaks gPTP time synchronization.

Q2: Do all TSN features require clock synchronization with IEEE 802.1AS gPTP?
Answer: No, not all TSN features are dependent on high-precision clock synchronization with IEEE 802.1AS gPTP. For example, FRER and Frame Preemption can be deployed independently from gPTP and PSFP only partially relies on clock synchronization for stream gate filters. However, to achieve deterministic communication, gPTP is indispensable since all time-scheduled TSN features like TAS depend on a highly accurate shared network time. 

Q3: How does TSN achieve deterministic bounded latency?
Answer: Deterministic bounded latency for TSN streams is enabled by a combination of multiple standards. IEEE 802.1Qbv TAS uses the high-precision clock signal and Pdelay measurements provided by IEEE 802.1AS gPTP to schedule contention-free transmission windows for high-priority streams at the egress queues. IEEE 802.1Qci then enforces compliance with those transmission windows on the ingress side of the switch.

Q4: How does the TAS guard band affect high-priority TSN streams and background traffic?
Answer: The TAS standard introduces a guard band before any high-priority transmission window during which no new best-effort transmissions are allowed to begin. The guard band is sized according to the time required to send the maximum allowed frame size, ensuring that any best-effort transmission will conclude before the end of the guard band period so that the high-priority frame can be transmitted without interference.

Q5: Which frames can have their transmissions interrupted by Frame Preemption?
Answer: Unlike other TSN features, whether a frame is preemptible or not is not directly determined by it being classified as best-effort traffic or part of a high-priority stream. Instead, the egress queues themselves can be configured to be preemptible. Usually frames from high-priority TSN streams will be queued into non-preemptible queues while best-effort traffic uses preemptible queues.

Q6: How is FRER different from other ring redundancy protocols like RSTP, ERPS, or MRP?
Answer: RSTP, ERPS and MRP are commonly used ring redundancy protocols that provide fast recovery in case of a link failure. However, they require a recovery time ranging from 50 milliseconds to 6 seconds (depending on topology and protocol configuration) during which packets can be lost. In a deterministic industrial network with hard real-time requirements, even a few missed packets can lead to failures and downtime, which is why FRER ensures zero-failover-time recovery by replicating frames onto multiple redundant paths. Another difference is that FRER is configured on a per-stream basis instead of operating on the whole network.

Q7: Why should I use FRER instead of HSR?
Answer: HSR is another ring redundancy protocol that uses packet duplication to provide zero-failover-time recovery. Unlike FRER, which is configured per-stream, HSR is applied on all network traffic and doubles the bandwidth usage as a result. In comparison, FRER can conserve bandwidth by only replicating the mission-critical data traffic that requires zero-failover-time recovery and use a different ring redundancy protocol like MSTP or ERPS for background traffic.
 

About Volktek
Volktek Corporation is a Taiwan-based manufacturer specializing in industrial Ethernet networking solutions with more than three decades of experience in supporting industrial automation, building management systems, maritime, transportation, energy, and critical infrastructure applications. Volktek focuses on delivering reliable, secure, and easy-to-deploy networking products that operate consistently in harsh industrial environments.
With in-house design, manufacturing, and quality control, Volktek supports customers worldwide through the full product lifecycle – from system design and deployment to long-term operation and technical support. Our portfolio emphasizes robustness, long product availability, and practical security features to help customers build resilient and future-ready OT networks.
 

---

¹. L. Maile, D. Voitlein, A. Arestova, A. S. Alshra'a, K.-S. J. Hielscher, and R. German, "On the Effect of TSN Forwarding Mechanisms on Best-Effort Traffic.", Proceedings of the 2024 12th International Conference on Computer and Communications Management (ICCCM '24), ACM, July 2024. 
https://doi.org/10.1145/3688268.3688283
². Rob Hulsebos, "TSN Technology: Ethernet Frame Preemption, Part 1.", Industrial Ethernet. May 2021.
https://industrialethernet.net/technology/tsn/tsn-technology-ethernet-frame-preemption/
³. L. Winkel, M.J. Teener, "Joint Tutorial IEEE 802.3brTF Interspersing express traffic (IET) and IEEE 802.1 Time sensitive Networking (TSN)", IEEE 802.org, March 2015, Berlin.
https://www.ieee802.org/3/br/public/Tutorial2_Berlin/8023-IET-TF-1501-Winkel-Tutorial-20150115_r06.pdf
⁴. L. Leonardi., L. Lo Bello, G. Patti, "Combining Earliest Deadline First Scheduling with Scheduled Traffic Support in Automotive TSN-Based Networks." Applied System Innovation, 2022. 
https://doi.org/10.3390/asi5060125
⁵. G. Ditzel, "The Comparison/Contrast of TSN Frame Replication and Elimination for Reliability (FRER) and Parallel Redundancy Protocol (PRP)", ODVA 2020 Industry Conference & 20th Annual Meeting, March 4, 2020
https://www.odva.org/wp-content/uploads/2020/05/2020-ODVA-Conference_TSN_FRER_PRP_Ditzel_Final.pdf