# Assessing a TSN simulator with hardware measurements

Quentin Bailleul

► To cite this version:

Quentin Bailleul. Assessing a TSN simulator with hardware measurements. 13th European Congress of Embedded Real Time Systems (ERTS), Feb 2026, Toulouse, France. 10.82331/ERTS.2026.11. hal-05513479

HAL Id: hal-05513479

https://hal.science/hal-05513479v1

Submitted on 16 Feb 2026

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
Assessing a TSN simulator with hardware measurements

Quentin Bailleul¹

¹ IRT Saint Exupéry, Toulouse, France
quentin.bailleul@irt-saintexupery.com

ABSTRACT

To meet the new needs of deterministic networks, the IEEE has proposed an extension to Ethernet called Time-Sensitive Networking (TSN). Among other things, this extension makes it possible to achieve low latency performance with availability equivalent to or better than current solutions, to unify high-speed networks and real-time field buses, and is based on open, multi-industry standards. Nevertheless, this extension introduces a certain complexity (e.g. interaction between mechanisms, search for the optimal configuration, ...) which needs to be studied. To achieve this goal with a low investment in time and hardware, simulation is the ideal tool. But for the results to be meaningful, we need to ensure that the simulation behavior is close to that of the hardware. So in this paper, I characterize the behavior of a TSN switch and use these characterization results to calibrate the behavior of a simulated switch. After calibration, I obtained an average root mean square error of less than 1% between the simulated and real latency distributions. The simulator source code resulting from this work is distributed freely [8].

KEYWORDS

TSN, Simulation, Hardware characterization

1. INTRODUCTION

Today's network architecture cannot cope with diversification of flows and their constraints. Thus, real-time Ethernet solutions have been designed to bring much higher bandwidth and advanced quality of service (QoS) policies. Promising solutions are the standards proposed by the IEEE Time-Sensitive Networking (TSN) task group. Indeed, TSN bring deterministic, low-latency, and reliable communication over standard Ethernet networks.

Simulation is a powerful tool to evaluate TSN especially at a lower cost, on larger network and by a greater number of researchers. However a consequent part of TSN is the temporal determinism. Thus, it is important that the simulation accurately reproduce the temporal behavior of the TSN hardware to ensure confidence in the results obtained using such simulator.

We did this work for the synchronization protocol of TSN to
accurately simulate the synchronization precision in [9]. In

this paper I extend, this work to other TSN mechanisms of
interest for the critical embedded networks.

Thus, I propose to carry out a series of experiments on a hard-
ware switch to determine the temporal characteristics specific
to each TSN mechanism while also capturing the limitations in
terms of hardware resources used to instance the TSN mecha-
nism. These characteristics are then used to calibrate a simula-
tor. Following this calibration, an average Root Mean Squared
Error (RMSE) of 0.82% was measured across several scenar-
ios between the crossing latency distribution of the simulated
switch and the hardware switch.

This realistic simulator is available to the community [8] under
the GNU GPLv2 license. Although the simulator is calibrated
for the hardware at our disposal, the proposed experimental
protocol can be used on other hardware to calibrate the simu-
lator for any hardware.

This article is organized as follows. Section 2 presents TSN, the state of the art and discusses latency in network devices. Section 3 describes the simulator used and the changes made to achieve the objective. Experiments are described and discussed in Section 4. And finally section 5 concludes.

2. CONTEXT

This section describes the TSN mechanisms envisaged to meet
the needs of critical embedded systems and then discusses the
state of the art and presents the latency that I will focus on in
the remainder.

2.1. TSN overview

Time-Sensitive Networking is an IEEE task group which pro-
pose enhancements to Ethernet in order to make it capable
of providing guarantees for heterogeneous flows. They have
proposed more than twenty standards describing new mecha-
nisms. These mechanisms can be grouped into four categories:
synchronization, latency control, reliability and resource man-
agement. To avoid interoperability problems and limit the
scope of options by industrial domain, TSN also proposes pro-
files. In this paper, I will focus on the two profiles made for
the embedded network : P802.1DG for automotive embedded
networks and P802.1DP for aerospace embedded networks. In
this two profiles the following mechanisms are selected to an-
swer the needs of this two industrial domains.

Generalized Precision Time Protocol (gPTP), proposed in IEEE 802.1AS [5], is a synchronization protocol based on Precision Time Protocol (PTP). This mechanism enables network devices to share a common clock with sub-microsecond preci-

<footnote>Quentin Bailleul. This is an open-access article distributed under the terms of the Creative Commons Attribution 4.0 License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited.</footnote>
sion. It can be used by application running on the end sta-
tion or by synchronous TSN mechanism like the Time-Aware
Shaper (TAS).

TAS is a latency control mechanism proposed in IEEE 802.1Qbv
[2]. It works by time-allocating access to the medium (like
Time Division Multiple Access (TDMA)). This allocation re-
sponds to a schedule, called the Gate Control List (GCL). This
GCL describes which FIFO of the output port has access to
the medium and for how long. This mechanism is suitable
for the transmission of synchronous flows and enables them to
achieve very low latencies since there is no waiting in the FI-
FOs if access to the medium is given at the moment when the
frame is available for transmission. For optimal performance,
however, this mechanism relies on network-wide synchroniza-
tion using gPTP.

The other latency control mechanism found in the profiles con-
sidered in this work is the Credit-Based Shaper (CBS). CBS,
described in IEEE 802.1Qav [1], is used to constrain the band-
width usage per FIFO using a token bucket. In practice, a
frame in a FIFO subject to CBS can only be transmitted if the
credit (i.e. the tokens) is positive or zero. When a frame is
transmitted, the credit is consumed in proportion to the size
of the frame. The credit is recharged over time at a config-
urable rate, called IddleSlope. This mechanism increases the
latency of flows submitted to it in order to leave transmission
opportunities (i.e. reduce latency) for lower-priority flows.

In the reliability group we find two standards: IEEE 802.1CB
[3] and IEEE 802.1Qci [4]. IEEE 802.1CB defines two mech-
anisms. The first is called Stream Identification. It links a
frame passing through a network device to a flow (or a stream)
with an internal identifier, called a stream handle, using an
identification function. The stream handle is then used by sev-
eral TSN mechanisms to select which policy to apply to it.
A number of identification functions are proposed to enable
association according to the various fields in the frame (e.g.
source MAC address with VlanId or destination MAC address
with VlanId). Some of these functions also have the ability
to edit the frame to change certain fields such as the priority
(PCP), VlanId or destination address of the Ethernet header.
The second mechanism proposed by this standard is Frame
Replication and Elimination For Redundancy (FRER). It al-
lows a frame to be replicated in multiple copies at a definite
point in the network and then eliminated at another point in
the network. This mechanism makes it possible to take advan-
tage of multiple paths between two points in the network to
increase robustness to faults that could prevent the transport
of a frame on one or more paths. Replication or elimination is
performed or not according to the stream handle.

IEEE 802.1Qci describes a mechanism called Per-Stream Fil-
tering and Policing (PSFP). This mechanism checks that a
flow (identified by a stream handle) complies with a network
usage contract. If the contract is violated, the frames can be
discarded to prevent the propagation of errors (e.g. babbling
idiot) to the rest of the network. A contract contains infor-
mation such as the maximum frame size, an amount of usable
bandwidth (verified using token buckets) and a temporal trans-
mission profile (verified using a mechanism similar to TAS).

Resource management mechanisms will not be discussed in

this article, as they focus on configuration rather than temporal
performance.

## 2.2. Related works

There are several types of simulation solution for TSN net-
works. [10] or [14] are two stand-alone, specialized libraries
for studying a given TSN mechanism (FRER and gPTP re-
spectively). This type of library is generally available soon
after a new mechanism is proposed by the IEEE TSN working
group, making them ideal for an initial study of the mecha-
nism. On the other hand, this type of library lacks the means
to study interaction with other TSN mechanisms due to their
standalone aspect.

To solve this last issues, frameworks implementing multiple
TSN mechanisms, like INET framework [11] for OMNeT++,
are proposed. This complete frameworks are very interesting
to study mechanism interaction.

Another option is commercially available simulators such as
the RTaW-Pegase [15] simulator. These tools are ideal for the
industrial context due to their stability, but are limited for re-
search due to the closeness of the solution. For example, such
closure makes it difficult to modify the mechanism’s behavior
to test a possible evolution of the mechanism.

All these solutions are interesting for studying the operation
of the TSN mechanism (i.e. functional studies), but do not en-
able realistic simulation of physical TSN devices. Initial work
in this direction was carried out in [9] to extend the library
made in [14] for the TSN synchronization mechanism using
hardware measurement to calibrate simulated devices. In the
end, we obtained an RMSE of 3ns between the simulated syn-
chronization precision and the hardware-measured synchro-
nization precision. In this paper, I extend this work to the set of
TSN mechanisms being considered for future mission-critical
embedded networks.

## 2.3. Latencies in network devices

Several durations must be taken into account in the simulation
of an Ethernet network, as listed below.

* The transmission time of a frame, which is linked to the size of the frame and the speed of the link.

* The propagation time on the link, which depends on the length and the type of link used (e.g. copper or optical fiber).

* The processing time between the reception of a frame by a switch input port and its entry into the FIFO on the switch output port.

* The waiting time in the FIFO of an output port, which is linked to the QoS policy in place.

In this article I focus on the third one. I will refer to this as
technological latency in the following. In existing solution, it
is simulated using a constant duration or sometimes a variable
duration between two bounds.

Technological latency is related to the forwarding process, de-
scribed in Figure 1, undergone by a frame between its entry
and its exit from the switch and its hardware implementa-
tion. In this paper, I intend, among other things, to measure
this duration experimentally and quantify the impact of adding
TSN mechanisms (CBS, TAS, Stream identification, FRER
and PSFP) to this process in order to represent it as well as
possible in the simulator.

<figure><img src="image_2.png" /><figcaption>Figure 1. The Ethernet forwarding process as described in [6]</figcaption></figure>

3. TSN SIMULATION AND MODEL EXTENSIONS

In this section, I present the TSN simulator used in the remainder of this paper and the changes made to approach the temporal behavior and reflect the limitations in terms of hardware resources of the different TSN mechanisms described above.

**3.1. Simulator**

The simulator I use is an in-house-developed simulator based
on ns-3 [13]. It implement a set of Ethernet features as de-
scribed in the IEEE 802.3-2022[7] and IEEE 802.1Q-2022[6]
standards (e.g. 100Base-Tx and 1000Base-T, full-duplex link,
Q-Tagged frame). However, this set of features is limited to
functionality of interest for embedded networks. (e.g. static
forwarding table). On the TSN side, it support CBS, TAS,
FRER, PSFP and gPTP as described in their respective stan-
dards.

The choice to developed an in-house simulator was motivated
by other ongoing works on safety and cyber-security that are
outside the scope of this paper.

3.2. Latency control and reliability mechanisms extensions

To achieve the goal of representativeness, I have made two
types of changes to the CBS, TAS, Stream Identification, FRER
and PSFP implementation. The first of these changes is the
addition of a means of configuring and simulating the techno-
logical latency introduced on a per-TSN mechanism basis. For
two TSN mechanisms, these means were implemented at the
sub-function level of the mechanism, as discussed in section
4, in order to obtain the level of control needed to accurately

reproduce the latency measured experimentally.

The second change is the addition of configurable minimum
and maximum value for each type of material ressource (eg.
number of GCL entries) to prevent the instantiation of less or
more resources in the simulator than are available on the actual
hardware. These limitations are detailed later in this paper.

Furthermore, to simplify the use of the results of this paper, a
new object class representing the switch I use in the following
has also been added. This object is preconfigured with all the
temporal characteristics and hardware limitations determined
in the remainder.

3.3. Synchronization mechanism extensions

The evolutions that are needed to accurately simulate gPTP
and the experimental calibration protocol will not be detailed
in the remainder. The changes and experimental protocol are
extensively detailed in [9].

4. EXPERIMENTATIONS

This section presents the experimental study. It is divided into
three parts. The first part deals with hardware limitations, the
second part discusses the evaluation of technological latency,
and the third part presents a comparison between the results
obtained on the hardware and those obtained with the post-
calibration simulator.

**4.1. Hardware limitations**

To offer a realistic simulation of TSN, it is important to cap-
ture the hardware limitation aspect. Indeed, the hardware re-
sources of network devices are not infinite. For example, it
is not possible to instantiate an 500 PSFP stream filters or a
500-entry GCL on most physical switches. Thus, without tak-
ing these limitations into account in the simulator, it would
be possible for a user to instantiate unrealistic switch config-
urations. Such configurations could lead to results, proposed
methods, or recommendations that would not be reproducible
in an industrial context.

Based on the documentation for the Microchip EVB-LAN9668
switch used in this article, I have listed in Table 1 the set
of limitations concerning the mechanisms implemented in the
simulator.

In addition to these numerical limitations, the stream identi-
fication mechanism implements only two of the five identifi-
cation functions specified in the standard. The implemented
functions are the null stream identification function and the
source MAC and VLAN ID identification function.

4.2. Technological latency evaluation

4.2.1. Experimental setup and protocol

The experimental setup I propose consists of a switch with
four end stations connected by 1Gb/s links, two Ethernet Test
Access Points (TAPs) and an one Pulse Per Second (1PPS)
generator, as shown in Figure 2. The switch (Microchip EVB-
LAN9668) is considered as a black box. The four end stations
are hosted on the same desktop PC (ubuntu 22.04) using a 4-
port Intel I225 network card. They are used to transmit frames
<table><caption>Table 1. List of hardware limitations</caption><thead><tr><th></th><th>Minimum</th><th>Maximum</th></tr></thead><tbody><tr><td colspan="3"><em>Miscellaneous</em></td></tr><tr><td>Number of port</td><td>N/A</td><td>8</td></tr><tr><td>Link speed</td><td>10Mb/s</td><td>1Gb/s</td></tr><tr><td>Number of FIFOs per port</td><td>N/A</td><td>8</td></tr><tr><td colspan="3"><em>Ethernet</em></td></tr><tr><td>Entry in the forwarding table</td><td>0</td><td>64</td></tr><tr><td colspan="3"><em>CBS</em></td></tr><tr><td>Iddle slope</td><td>0.1Mb/s</td><td>3.282Gb/s</td></tr><tr><td colspan="3"><em>TAS</em></td></tr><tr><td>GCL size</td><td>0</td><td>256</td></tr><tr><td>GCL cycle duration</td><td>1ns</td><td>999999999ns</td></tr><tr><td>GCL time interval</td><td>1ns</td><td>999999999ns</td></tr><tr><td colspan="3"><em>Stream identification</em></td></tr><tr><td>Stream identification instances</td><td>0</td><td>127</td></tr><tr><td colspan="3"><em>PSFP</em></td></tr><tr><td>Stream filter instances</td><td>0</td><td>176</td></tr><tr><td>Stream gate instances</td><td>0</td><td>176</td></tr><tr><td>Stream gate GCL size</td><td>0</td><td>4</td></tr><tr><td>Flow meter instances</td><td>0</td><td>240</td></tr><tr><td colspan="3"><em>FRER</em></td></tr><tr><td>FRER instances</td><td>0</td><td>99</td></tr><tr><td>History size for vector recovery algorithm</td><td>1</td><td>32</td></tr><tr><td>Reset timer for recovery algorithms</td><td>1ms</td><td>4.095s</td></tr><tr><td>Test timer for latent error detection</td><td>1s</td><td>86400s</td></tr><tr><td>Reset timer for latent error detection</td><td>1s</td><td>86400s</td></tr></tbody></table>

to stimulate the switch. The two TAPs (Profishark 1G+) are used to capture and timestamp frames from ES1 to ES2. They are synchronized using the 1PPS signal emitted by a Meinberg MicroSync HR. Thanks to this synchronization, the time taken for a frame to pass through the switch can be measured accurately if it passes through both TAPs.

<figure><img src="image_3.png" /><figcaption>Figure 2. Experimental setup with continuous lines representing Ethernet link and dashed lines representing PPS links.</figcaption></figure>

Frames are generated using the trafgen utility [12]. Trafgen can be used to forge frames in a very efficient way to approximate real-time or high-speed behavior. Each frame can be identified by the destination address, VlanId and a frame number present in the Ethernet payload.

A series of measurements is broken down into several phases. Each phase corresponds to a different traffic profile. Each group of phase is designed to test the influence of a given parameter. The phases are summarized below.

* Phase 1.1 → 1.2: Study of the influence of frame size from 42 bytes to 1500 bytes.

* Phase 2.1 → 2.2: Study of the influence of the emission period from 1s to 10µs (i.e. link saturation).

* Phase 3.1 → 3.8: Study of the influence of frame priority from 7 to 0.

* Phase 4.1 → 4.2: Study of the influence of frame burst size from 1 to 200 frames.

* Phase 5.1 → 5.3: Study of the influence of interference flows on the same output port but of different source port and priority with a period of 10µs.

* Phase 6.1 → 6.2: Study of the influence of flows passing through the switch in the opposite direction to the flow under study and with a period of 10µs.

* Phase 7.1 → 7.2: Study of the influence of flows passing through the switch using different ports than the flow under study and with a period of 10µs.

* Phase 8.1 → 8.2: Study of the influence of multicast

In each phase, 5000 frames of the flow under study are sent to achieve a sufficient statistical representativeness. For the burst phase (i.e. phase 4.2), 5000 bursts are sent and only the latency of the last received frame is logged. More details on the phase parameters will be provided in the following section.

Intermediate phases can easily be added to study in detail variations in switch crossing latency. However, adding phases greatly increases the duration of an experiment. Unless otherwise specified, the frames of the flow under study are sent every 100 ms. Thus, for an experiment that captures 5000 frames, each intermediate phase extends the duration of the experiment by 8.3 minutes. Therefore, I will use the phase list presented above to perform an initial analysis. If variations in transit time are observed between two phases, intermediate phases could be added to investigate these changes.

A series of measurements is made for each switch configuration. These configurations were created to characterize the switch up to its hardware limits. The configurations studied are as follows:

* Configuration 1.1 → 1.2: Ethernet with strict priority with varying forwarding table size from 6 to 64.

* Configuration 2.1: CBS with iddleSlope varying from 1Gb/s to 1Mb/s for FIFO 7 to 1 and no CBS on FIFO 0

* Configuration 3.1 → 3.4: TAS with varying gate duration (from 15µs to 100ms), number of GCL entry (from 1 to 256) and gate state.

* Configuration 4.1 → 4.3: Stream identification with configuration varying from 127 instances on the switch input port to 127 instances on the switch output port and from null stream identification function to source MAC and VLAN ID identification function.

* Configuration 5.1 → 5.2: FRER with configuration varying from 99 replication instances to 99 elimination instances.

* Configuration 6.1: PSFP with 176 stream filter, stream gate and flow meter instances.
For configuration 5.2, which investigates elimination with FRER, replication is performed by another switch that is introduced on the link between ES1 and TAP1.

Each series of measurements is run by a Python script which starts by triggering the generation of the flows and the measurement instruments. Once it has captured enough frames, it stops the generation of the flows and the measurement instruments, then analyses the captures made by the two TAPs to compute the crossing times of the different frames of the flow under study, then saves these times in a .json file for future analysis before moving on to the next phase. These results are discussed in the next subsection.

Note that to quantify and deduce the bias introduced by our
measuring instruments, a reference experiment was carried out
by removing the switch and making a direct connection be-
tween TAP1 and TAP2 as well as ES3 and ES4.

4.2.2. Results

Let's start with the reference experiment. I measured latency
following a normal distribution with a mean of 382 ns and a
standard deviation of 4 ns, regardless of the phase. An exam-
ple of this experimental distribution is illustrated in Figure 3
for phase 3.3. In the rest of this article, the results presented
are obtained after deducting the average latency introduced by
the measuring devices and the transmission time of the frame
at the switch output port.

<figure><img src="image_4.png" /><figcaption>Figure 3. Distribution of crossing latency between the two TAPs during phase 3.3</figcaption></figure>

Next, let's examine the first configuration (i.e., the strict pri-
ority configuration) in detail. Figure 4 shows that the latency
distribution is uniform between 2.37µs and 2.66µs for phases
1.2, 2.1, 2.2, 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 3.7, 3.8, 4.1, 5.1, 6.1,
6.2, 7.1, 7.2, and 8.1. Based on these results, I can conclude
that frame period, frame priority, and flows that use different
output ports or the same ports but in opposite directions do not
impact technological latency. However, the phases not listed
above show differences, which are discussed below.

The first difference concerns the influence of packet size, as
highlighted in Figure 5. Indeed, I note that when transmit-
ting 64-byte frames (i.e., phase 1.1), the technological latency
is greater by 20 ns than when transmitting 1500-byte frames

<figure><img src="image_5.png" /><figcaption>Figure 4. Distribution of switch crossing latency with the configuration 1.1</figcaption></figure>

(i.e., phase 1.2). This first surprising result is very difficult
to explain without detailed knowledge of the hardware imple-
mentation of this switch.

<figure><img src="image_6.png" /><figcaption>Figure 5. Distribution of switch crossing latency for phases
1.1 and 1.2 with the configuration 1.1</figcaption></figure>

The second difference lies in the influence of bursts, as shown
in Figure 6. As a reminder, in phase 4.1 (respectively 4.2), a
single frame (respectively 200 frames) of 1500 bytes is sent
every 100 ms. Despite the change in distribution, we note that
the minimum and maximum latencies measured remain the
same between the two phases. Unfortunately, without more
detailed knowledge of the hardware implementation, I also
cannot explain this change.

Another difference is observed when the output port is shared
with a concurrent flow coming from ES3, as illustrated in Fig-
ure 7. The first phase of this series (i.e., phase 5.1) is the con-
trol experiment for this series of phases, in which ES1 trans-
mits a 1500-byte frame every 100 ms to ES2 without disrup-
tion. Phase 5.2 adds to phase 5.1 the transmission of the lower
priority 1500-byte frame every 10µs by ES3 to ES2. Phase
5.3 differs from phase 5.2 in that it uses a higher priority for
the interfering flow than for the flow under study. However,
on our desktop computer, trafgen approaches the 1 Gb/s band-
<figure><img src="image_7.png" /><figcaption>Figure 6. Distribution of switch crossing latency for phases 4.1 and 4.2 with the configuration 1.1</figcaption></figure>

width usage mark without actually reaching it, meaning that the link is not completely saturated and some lower priority frames can still get through. Furthermore, since the disruption comes from only one port, the FIFO concerned at the output port never has time to accumulate more than one packet from the disruptive flow. This phenomenon can be clearly seen in the distributions for phases 5.2 and 5.3 in the Figure 7. Indeed, there is an increase in latency of up to 11.943µs, approaching the worst possible case of 12.160µs, which is caused by waiting for the end of the current packet transmission. Thus, even if a distortion in the distribution is observed, I can conclude that the disturbances do not affect the technological latency of the device under study.

<figure><img src="image_8.png" /><figcaption>Figure 7. Distribution of switch crossing latency for phases 5.1, 5.2 and 5.3 with the configuration 1.1</figcaption></figure>

Finally, the last difference observed in the first configuration is when using multicast frames, as highlighted in Figure 8. In phase 8.1, a 1500-byte frame is sent to ES2. In phase 8.2, this same frame is sent to two additional destinations (i.e., ES3 and ES4). Following the addition of these new destinations, a distribution shift of + 63 ns is measured.

Now that I have detailed the results of the base configuration, let's look at the base configuration with a forwarding table of

<figure><img src="image_9.png" /><figcaption>Figure 8. Distribution of switch crossing latency for phases 8.1 and 8.2 with the configuration 1.1</figcaption></figure>

maximum size (i.e., Configuration 1.2). With this configuration, the flow of interest is placed at the end of the switching table in order to quantify the impact of traversing the entire table. However, a comparison between the results obtained for the basic configuration and this configuration highlights the absence of any quantifiable impact on technological latency, regardless of the phase. One such comparison is illustrated in Figure 9 for phase 2.2.

<figure><img src="image_10.png" /><figcaption>Figure 9. Distribution of switch crossing latency for configuration 1.1 and 1.2 during phase 2.2</figcaption></figure>

Next, let's focus on TSN latency control mechanisms, starting with CBS (i.e., Configuration 2.1). The results of the comparison between the results obtained for the CBS configuration and the basic configuration can be divided into two categories. The first category concerns all phases where credit recharge is fast enough not to impact frame transmission. For phases that fall into this category, such as phase 3.4 illustrated in Figure 10, we observe that adding CBS reduces technological latency. Indeed, I measure an average reduction of 25 ns for the lower bound and 9 ns for the upper bound of the distribution compared to configuration 1.1. This surprising result is also difficult to explain without precise knowledge of the hardware implementation of this switch. The other category concerns phases where the crossing latency is impacted by the credit
recharge waiting time. Nevertheless, the results obtained are the expected results when using this mechanism. Let's take the example of phase 4.2, illustrated in Figure 11. The results obtained still indicate a reduction in minimum latency compared to configuration 1.1, but this time the distribution is much more extended to the right. However, this new distribution corresponds to what is expected for this CBS configuration.

<figure><img src="image_11.png" /><figcaption>Figure 10. Distribution of switch crossing latency for configuration 1.1 and 2.1 during phase 3.4</figcaption></figure>

<figure><img src="image_12.png" /><figcaption>Figure 11. Distribution of switch crossing latency for configuration 1.1 and 2.1 during phase 4.2</figcaption></figure>

On the TAS side, the results can also be divided into two categories. The first category concerns the three configurations using TAS, which should not delay frames because the gates are always open. Configuration 3.1 implements a TAS with a single entry in the GCL that always opens all gates for 15µs on the port going to ES2. Configuration 3.2 uses the same configuration but with an opening time of 1s. Configuration 3.3 implements a 256-entry configuration with all gates open for 1ms. With these configurations, I note that the duration of the entries in the GCL does not modify the technological latency, as illustrated in Figure 12.

The second category of results concerns configuration 3.4. This configuration is based on configuration 3.3 with the open and

close gate states. For example, the gate of FIFO 7 is open half the time. The impact can be seen in phase 3.1, as illustrated in Figure 13. In this example, we can see that a frame has a latency between the minimum technological latency and the maximum frame waiting time between two door openings (i.e., 1 ms) at some frames, as they are already present in the FIFO. As expected, there is an increase in the switch crossing time, but this is entirely explainable by the schedule used. Thus, the change in gate state does not add any notable delay other than the previously mentioned delay to the technological latency.

<figure><img src="image_13.png" /><figcaption>Figure 12. Distribution of switch crossing latency for configurations 1.1, 3.1, 3.2 and 3.3 during phase 3.6</figcaption></figure>

<figure><img src="image_14.png" /><figcaption>Figure 13. Distribution of switch crossing latency for configuration 1.1 and 3.4 during phase 3.1</figcaption></figure>

Now that we have seen the latency control mechanisms, let's look at the robustness mechanism, starting with stream identification. Figure 14 shows that using the null identification function (i.e., configuration 4.1 or 4.2) reduces the switch crossing time. On average, I measured a reduction of 9 ns in the lower bound and 13 ns in the upper bound of the distribution compared to configuration 1.1. We also note that this behavior is not observed when the MAC source and VLAN ID identification function is used (i.e., configuration 4.3). As with CBS, this surprising result cannot be explained without precise information on the hardware implementation of this switch.
<figure><img src="image_15.png" /><figcaption>Figure 14. Distribution of switch crossing latency for configuration 1.1, 4.1, 4.2 and 3.4 during phase 3.2</figcaption></figure>

Regarding FRER, two configurations are explored. Configuration 5.1 implements the replication part of FRER and configuration 5.2 implements the elimination part. The results are similar for all phases. An example of the results for phase 7.2 is given in Figure 15. There is a shift in the distribution to the left for configuration 5.1. However, this shift is entirely attributable to the use of the null identification function. For configuration 5.2, there is a shift of +75 ns. This delay primarily hides a negative part of 13 ns also related to the identification function used here. The positive shift of 88ns can be explained in part by the presence of the RTAG, amounting to 48ns (6 bytes transmission time at 1 Gb/s). The remaining 40ns seems to be due to the time overhead caused by the FRER function required for elimination.

<figure><img src="image_16.png" /><figcaption>Figure 15. Distribution of switch crossing latency for configuration 1.1, 5.1 and 5.2 during phase 7.2</figcaption></figure>

To round off this section, the implementation of PSFP (i.e., configuration 6.1) did not influence technological latency, regardless of the phase. However, there is a clear shift in the distribution, as illustrated in Figure 16 for phase 2.2. But, as with FRER, this is entirely attributable to the use of the null identification function required for PSFP to operate.

<figure><img src="image_17.png" /><figcaption>Figure 16. Distribution of switch crossing latency for configuration 1.1 and 6.1 during phase 2.2</figcaption></figure>

## 4.3. Post-calibration comparison

In this subsection, I compare the results previously obtained on the hardware with those obtained by the simulator after calibration using the data discussed in the previous subsections.

Firstly, taking hardware limitations into account allows the simulator to crash in order to avoid simulating unrealistic configurations for the hardware used in this study.

Next, regarding temporal representativeness, the configurations presented above were replayed after calibration. Three examples are given in Figures 17, 18, and 19. On these figure, we observe that the central part of the technological latency distribution is very well simulated despite the implementation of different TSN mechanisms. However, we note that as we approach the lower and upper limits, the difference is significant. Indeed, the distribution obtained with the simulator is a simple uniform distribution, whereas the distribution obtained on the hardware is smoother at the limits. This smoothing is partly due to TAPs, as illustrated in Figure 3. Nevertheless, I have chosen to keep this distribution conservative in the simulator, to guarantee the results at the limits, which is necessary for the critical embedded context in which this simulator is used. Furthermore, despite this difference at the limits, the average root mean square error (RMSE) is 0.82% between the simulated and measured technological latency distributions on the hardware, indicating that the temporal representativeness is significant following the calibration of the proposed simulation solution.

## 5. CONCLUSION

In this paper, I discussed the improvement of the representativeness of an open source TSN simulator [8] using measurements on real hardware. Such work will allow the simulator to be used to study TSN networks with several dozen of these switches at low cost while ensuring a temporal representativeness that is unmatched by other available simulators. Achieving this goal involved two phases.

The first of these phases is taking into account hardware limitations in terms of instantiation and configuration in the simulator. This then made it possible to prevent the simulation of
<figure><img src="image_18.png" /><figcaption>Figure 17. Comparison of the crossing latency distribution measured on the hardware switch versus the simulated switch with configuration 1.1 during phase 1.2</figcaption></figure>

<figure><img src="image_19.png" /><figcaption>Figure 19. Comparison of the crossing latency distribution measured on the hardware switch versus the simulated switch with configuration 4.2 during phase 3.8</figcaption></figure>

<figure><img src="image_20.png" /><figcaption>Figure 18. Comparison of the crossing latency distribution measured on the hardware switch versus the simulated switch with configuration 2.1 during phase 3.2</figcaption></figure>

configurations that were impossible on the hardware.

The second phase consisted of reproducing the latency measured on the hardware in the simulator. To achieve this goal, I characterized the technological latency of a hardware switch as well as the changes in this latency caused by the instantiation of TSN mechanisms. I measured variations in crossing latency between -25 ns and 40 ns depending on the instantiated mechanism. The data from this characterization was then fed back into the simulator. The results obtained in the simulation were then compared with the results obtained on the hardware. As a result of this calibration, an average RMSE of less than 1% was measured between the distribution of crossing latency of the simulated switch and the real switch.

Although these results are based on the device I have available, the proposed method is device-independent. Thus, it is possible to characterize other devices in order to calibrate their simulated versions.

This work also shows that simulating technological latency using a uniform distribution is very well suited to the hardware

at my disposal. Furthermore, since the changes in technological latency caused by the TSN mechanisms considered in this paper are on the order of a few nanoseconds, on this hardware, they can be neglected given the latencies involved in traversing a 1Gb/s network, which are more on the order of microseconds.

This paper also illustrated the difficulty of explaining certain temporal phenomena without information on the hardware implementation.

The next step in this work is the characterization of FPGA-based switches, which, given their lower performance, should lead to greater latency changes, as well as the characterization of end stations to enable the simulation of a representative end-to-end network.

## ACKNOWLEDGMENT

The authors thank all the people and industrial partners involved in the EDEN2 project. This work is supported by the French Research Agency (ANR) and by industrial partners of IRT Saint Exupéry : Airbus Operations, Asterios Technologies, ISAE-SUPAERO, KNDS, Safran Electronics and Defence, Thales Avionics, Thales Research & Technology and Viveris.

## REFERENCES

[1] IEEE Standard for Local and metropolitan area networks- Virtual Bridged Local Area Networks Amendment 12: Forwarding and Queuing Enhancements for Time-Sensitive Streams. IEEE Std 802.1Qav-2009 (Amendment to IEEE Std 802.1Q-2005), pages 1-72, 2010. doi: 10.1109/IEEESTD.2010.8684664.

[2] IEEE Standard for Local and metropolitan area networks – Bridges and Bridged Networks - Amendment 25: Enhancements for Scheduled Traffic. IEEE Std 802.1Qbv-2015 (Amendment to IEEE Std 802.1Q-2014 as amended by IEEE Std 802.1Qca-2015, IEEE Std 802.1Qcd-2015, and IEEE Std 802.1Q-2014/Cor 1-2015), pages 1-57, 2016. doi: 10.1109/IEEESTD.2016.8613095.
[3] IEEE Standard for Local and metropolitan area networks–Frame Replication and Elimination for Reliability. IEEE Std 802.1CB-2017, pages 1–102, 2017. doi: 10.1109/IEEESTD.2017.8091139.

[4] IEEE Standard for Local and metropolitan area networks–Bridges and Bridged Networks–Amendment 28: Per-Stream Filtering and Policing. IEEE Std 802.1Qci-2017 (Amendment to IEEE Std 802.1Q-2014 as amended by IEEE Std 802.1Qca-2015, IEEE Std 802.1Qcd-2015, IEEE Std 802.1Q-2014/Cor 1-2015, IEEE Std 802.1Qbv-2015, IEEE Std 802.1Qbu-2016, and IEEE Std 802.1Qbz-2016), pages 1–65, 2017. doi: 10.1109/IEEESTD.2017.8064221.

[5] IEEE Standard for Local and Metropolitan Area Networks–Timing and Synchronization for Time-Sensitive Applications. IEEE Std 802.1AS-2020 (Revision of IEEE Std 802.1AS-2011), pages 1–421, 2020. doi: 10.1109/IEEESTD.2020.9121845.

[6] IEEE Standard for Local and Metropolitan Area Networks–Bridges and Bridged Networks. IEEE Std 802.1Q-2022 (Revision of IEEE Std 802.1Q-2018), pages 1–2163, 2022. doi: 10.1109/IEEESTD.2022.10004498.

[7] IEEE Standard for Ethernet. IEEE Std 802.3-2022 (Revision of IEEE Std 802.3-2018), pages 1–7025, 2022. doi: 10.1109/IEEESTD.2022.9844436.

[8] Quentin Bailleul. Eden-sim. URL https://sahara.irt-saintexupery.com/embedded-systems/eden-sim.

[9] Quentin Bailleul, Katia Jaffrès-Runser, Jean-Luc Scharbarg, and Philippe Cuenot. Assessing a precise gPTP simulator with IEEE802.1AS hardware measurements. In *11th European Congress on Embedded Real-Time Systems (ERTS 2022)*, 2022.

[10] Peter Heise, Fabien Geyer, and Roman Obermaisser. TSimNet: An industrial time sensitive networking simulation framework based on OMNeT++. In *2016 8th IFIP International Conference on New Technologies, Mobility and Security (NTMS)*, pages 1–5. IEEE, 2016.

[11] INET. INET framework, 2022. URL https://inet.omnetpp.org/2022-06-15-tsn-released.html.

[12] Netsniff ng contributors. Netsniff-ng. URL http://netsniff-ng.org/.

[13] ns 3 contributors. ns-3. URL https://www.nsnam.org/.

[14] Henning Puttnies, Peter Danielis, Enkhtuvshin Janchivnyambuu, and Dirk Timmermann. A Simulation Model of IEEE 802.1 AS gPTP for Clock Synchronization in OMNeT++. In *OMNeT++*, pages 63–72, 2018.

[15] RTaW. RTaW-Pegase. URL https://www.realtimeatwork.com/rtaw-pegase/.