What is the TSN protocol? Definition, features and comparison with AFDX

In critical systems, not all network traffic has the same requirements. A supervision flow, a video stream, a real-time command, sensor data or diagnostic information will not tolerate the same levels of latency, jitter or packet loss.

Historically, standard Ethernet was designed to transport data efficiently, but not to guarantee strict deterministic behavior on its own. This is precisely the role of TSN: to bring synchronization, prioritization, reservation and traffic control mechanisms to Ethernet in order to better manage real-time communications.

TSN is now a major topic for industrial networks, autonomous vehicles, embedded systems, aerospace platforms, defense infrastructures and distributed computing systems. It makes it possible to consider a more converged Ethernet infrastructure, capable of carrying both critical and non-critical traffic over the same network, provided that the network is properly designed, configured and validated.

TSN stands for Time-Sensitive Networking. It is not a single protocol, but a set of standards developed within IEEE 802.1 to bring determinism to Ethernet networks.

The purpose of TSN is to enable the transport of time-sensitive data with:

• Bounded latency;
• Reduced jitter;
• Improved time synchronization between devices;
• Fine-grained priority management;
• Reduced packet loss;
• Better coexistence between critical and standard traffic flows.

In other words, TSN turns Ethernet into a more predictable communication medium for real-time applications, while remaining within the Ethernet ecosystem.

In many embedded or industrial systems, networks must manage several types of data in parallel: real-time commands, video, supervision, maintenance, diagnostics, cybersecurity, recording, sensor data, application flows or inter-computer communications.

Without time-aware control mechanisms, these flows may compete with each other. This can result in variable delays, unpredictable queues or packet loss in congestion scenarios.

TSN addresses this issue by introducing traffic scheduling and control logic. The objective is not simply to increase Ethernet bandwidth, but to ensure that the most time-sensitive flows are transmitted at the right moment, with controlled network behavior.

This is particularly relevant in environments where network communication is part of the operational behavior of the system: industrial automation, robotics, vehicles, defense, aerospace, real-time video processing, mission systems or edge computing platforms.

TSN brings together several IEEE standards. Not all of them are necessarily used in every project. The selection depends on latency, synchronization, safety, redundancy and certification requirements.

Time Synchronization: IEEE 802.1AS

Synchronization is one of the core foundations of TSN. It allows network devices to share a common time reference.

With IEEE 802.1AS, switches, computers, sensors and end devices can be aligned to a shared time base. This synchronization is essential when the network must open precise transmission windows or coordinate critical flows.

Without reliable synchronization, it becomes difficult to ensure that priority packets are transmitted exactly when expected.

Time-Aware Traffic Scheduling: IEEE 802.1Qbv

IEEE 802.1Qbv introduces the principle of the Time-Aware Shaper. The network can open or close transmission queues according to a defined schedule.

In practical terms, some flows are allocated reserved time slots. During these windows, they can be transmitted without being disturbed by less critical traffic.

This mechanism is particularly useful for cyclic communications, real-time commands or latency-controlled exchanges.

Flow Regulation and Control: IEEE 802.1Qci

IEEE 802.1Qci enables per-stream ingress policing. It can filter, limit or block flows that do not comply with the expected behavior.

This function is important to prevent a faulty, misconfigured or compromised device from disrupting the entire network. It therefore contributes to infrastructure robustness, especially in critical systems.

Frame Replication and Redundancy: IEEE 802.1CB

IEEE 802.1CB enables frames to be duplicated over multiple network paths, with duplicate frames eliminated at the destination.

The objective is to improve availability: if one path fails, a copy of the frame may still arrive through another path. This approach is valuable for systems where communication continuity is essential.

Prioritization and Traffic Shaping

TSN also relies on prioritization, queuing and shaping mechanisms to better organize data transmission.

This makes it possible to allow several types of traffic to coexist on the same network:

• Real-time flows;
• Video streams;
• Control flows;
• Supervision traffic;
• Diagnostic data;
• Standard IT traffic.

This is precisely where TSN delivers value: network convergence. It helps reduce the need for multiple separate networks while maintaining control over critical flows.

Yes, TSN can be implemented in an Ethernet network, but not simply through a general software update or by adding a standard switch. The network devices and end systems involved must support the TSN functions required by the project.

A TSN implementation generally requires:

• TSN-compatible switches;
• Compatible network interface cards or end devices;
• Controlled time synchronization;
• Precise configuration of critical flows;
• Latency and network path analysis;
• Validation of behavior under real operating conditions;
• A redundancy strategy if required by the application;
• Complete documentation for projects subject to qualification or certification.

TSN is therefore not just an option to activate. It is a network design choice.

In practice, the first step is to identify time-sensitive flows: which data must be deterministic? What maximum latency is acceptable? Which flows can tolerate delay? Which devices must be synchronized? Which network paths are critical? Which failure scenarios must be covered?

Based on this analysis, it becomes possible to define the TSN functions that are actually required. Not every project needs the full TSN feature set.

This approach really comes into its own with ruggedised network equipment such as the QUARTZ ruggedised Ethernet switch, which we offer in a specific version with TSN support. Indeed, the Quartz-TSN version incorporates TSN features such as IEEE 802.1AS, IEEE 802.1Qav, IEEE 802.1Qbv, IEEE 802.1Qci and IEEE 802.1CB.

The first benefit of TSN is predictability. In a conventional network, even when properly sized, behavior may vary depending on load, priorities and temporary congestion. With TSN, critical flows can be managed much more precisely.

The second benefit is network convergence. Instead of multiplying specialized buses or separate networks, TSN makes it possible to consider a common Ethernet network for several types of traffic, while maintaining different guarantees depending on their criticality.

The third benefit is standardization. TSN remains based on Ethernet and IEEE standards, which helps support interoperability compared with fully proprietary solutions.

The fourth benefit is scalability. In complex systems, it becomes possible to add devices, flows or functions, provided that the configuration and timing analysis are properly reviewed.

TSN does not automatically solve every network issue. It provides tools, but their effectiveness depends heavily on network design, configuration and validation.

Several limitations must be considered.

• First, interoperability may vary depending on the devices and profiles supported. Two products may both be described as TSN-compatible without supporting exactly the same functions.
• Second, configuration can be complex. Time scheduling, traffic flows, priorities, transmission windows, redundancy and control mechanisms must be coherent across the entire network.
• Finally, in critical domains, TSN must be assessed against safety, cybersecurity, qualification and certification requirements. The fact that a network is TSN-compatible does not automatically make it acceptable for an aerospace, defense or mission-critical application.

AFDX, or Avionics Full-Duplex Switched Ethernet, is a deterministic Ethernet implementation defined within the ARINC 664 Part 7 framework. It was designed to provide a deterministic network for avionics, with requirements specific to aerospace systems.

AFDX was developed for critical avionics communications. It relies on concepts such as Virtual Links, bandwidth limitation, network redundancy and policing within switches. AFDX communications notably use Virtual Links with Bandwidth Allocation Gaps, while AFDX switches perform filtering, policing, switching and monitoring functions.

TSN and AFDX therefore pursue a similar objective: making Ethernet more deterministic. However, they do not achieve this in the same way.

AFDX is a highly structured avionics profile, historically used in certified aerospace programs. TSN is a broader set of deterministic Ethernet standards used across multiple sectors, including industry, automotive, professional audio-video, aerospace, defense and embedded systems.

Short answer is: not automatically.

TSN can be considered a serious technology for new deterministic networks, including in aerospace. There is also an aerospace profile, IEEE 802.1DP, which brings together TSN standards to define deterministic Ethernet requirements applicable to mission and safety-critical systems.

However, replacing AFDX with TSN is not simply a matter of changing a switch or protocol. AFDX is already embedded in avionics designs, certification processes, computers, test tools, validation methods and system requirements.

In an existing program, AFDX therefore cannot simply be replaced by TSN without impact analysis, requalification, full validation and consideration of certification constraints.

For a new program, however, TSN can be studied as an alternative or a possible evolution, especially when the project seeks greater flexibility, more network convergence, higher data rates or better sharing of traffic flows.

The most accurate formulation is therefore: TSN can complement, compete with or inspire certain network designs historically addressed by AFDX, but it is not a universal and immediate replacement for AFDX.

TSN becomes relevant when a network must transport several types of traffic with different timing requirements.

It may be useful for:

• Distributed embedded systems;
• Defense platforms;
• Autonomous vehicles;
• Real-time industrial networks;
• Vision and video processing systems;
• Mission computers;
• Edge computing platforms;
• Networks requiring synchronization, redundancy and controlled latency.

TSN is particularly useful when the objective is to reduce the separation between critical and non-critical networks while maintaining fine control over data transmission.

AFDX remains relevant when the project belongs to an avionics context already structured around ARINC 664 Part 7.

This is especially the case when:

• The system ecosystem is already AFDX-based;
• Existing equipment uses AFDX End Systems;
• Certification requirements are built around AFDX;
• Test and validation tools are already qualified;
• Virtual Links and BAGs are central to the network design;
• The program requires continuity with an existing avionics platform.

In this context, migrating to TSN may be technically possible over the long term, but it is rarely straightforward in the short term.

TSN represents a major evolution of Ethernet for time-sensitive applications. It enables better device synchronization, critical flow scheduling, congestion limitation, abnormal behavior control and improved availability through redundancy.

However, TSN is not a magic solution. Its value depends on the quality of the network design, the actual support provided by devices, configuration, validation and the level of requirements of the target system.

Compared with AFDX, TSN opens up important perspectives, particularly for new generations of embedded and deterministic networks. It may represent an interesting alternative in some new projects, but it does not automatically replace an existing AFDX network, especially in certified avionics environments.

For critical applications, the right approach is therefore to start from the system need: latency, synchronization, redundancy, bandwidth, certification, environmental constraints, cybersecurity and lifecycle. This analysis determines whether TSN is relevant, whether it should complement an existing infrastructure, or whether it can form the basis of a new deterministic network.

• Discover the QUARTZ rugged Ethernet switch: A rugged networking solution designed for mission-critical environments, with a specific version incorporating TSN features.
• Understanding defence, aerospace and security applications: Find out how rugged embedded systems meet the demands of challenging operational environments.
• What is a ruggedised Ethernet switch? A supplementary guide to help you better understand the criteria for choosing a rugged switch: connectivity, environment, qualification, cybersecurity and lifecycle.
• Contact ECRIN Systems: Speak to our teams to explore the integration of a deterministic Ethernet infrastructure into your embedded system.