Content uploaded by Junhui Jiang
Author content
All content in this area was uploaded by Junhui Jiang on Oct 13, 2019
Content may be subject to copyright.
A Simulation Model for Time-sensitive Networking
(TSN) with Experimental Validation
Junhui Jiang, Yuting Li, Seung Ho Hong∗,
Mengmeng Yu
Department of Electronic Systems Engineering
Hanyang University
Ansan, Korea
0229ender@gmail.com, yuting2427@gmail.com
shhong@hanyang.ac.kr∗ymm929@gmail.com
Aidong Xu
Key Laboratory of Networked
Control Systems
Shenyang Institute of Automation
Chinese Academy of Sciences
Shenyang, China
xad@sia.cn
Min Wei
National Industrial IoT
International Cooperation Base
Chongqing University of Posts
and Telecommunications
Chongqing, China
weimin@cqupt.edu.cn
Abstract—Industrial communication requires highly reliable
networks with hard temporal constraints. Thus, the IEEE 802.1
Task Group proposed a promising technology, namely, time-
sensitive networking (TSN), to complement the determinism and
real-time (RT) capabilities of Ethernet via a set of enhanced IEEE
standards. To explore the feasibility and applicability of TSN,
we developed a simulation model for TSN using a module-based
design method. Our TSN-compliant modules implement time-
based traffic scheduling functionality to guarantee the determin-
istic and RT transmission of time-triggered traffic. We validated
the developed modules by comparing the end-to-end simulation
latencies to those measured in a real-world TSN testbed. The
results of this evaluation validate the proposed simulation model
and show that it conforms tightly to the TSN specifications and
faithfully matches the real-world testbed.
Index Terms—Time-sensitive networking, TSN simulation
model, TSN testbed, real-time communication, latency measure-
ment
I. INTRODUCTION
In modern industrial automation, robust determinism and
real-time (RT) performance are mandatory for process control
and manufacturing systems. However, the traditional Ethernet
[1] system cannot satisfy the RT requirements due to the
randomized media access and the best-effort (BE) forwarding
mechanism. Although several RT extensions to Ethernet have
been proposed, e.g., EtherCAT, PROFINET, SERCOS III,
and TT Ethernet, dedicated, expensive, and vendor-compliant
devices are required to achieve the best possible RT properties.
Hence, they lack interoperability and compatibility, which has
crippled the development of industrial automation. Such solu-
tions, which do not comply with the constraints imposed by the
standards, separate the RT communication markets. Also, this
is inconsistent with the basic concept of the industrial Internet
of Things (IoT), i.e., a standard, open, and interconnected
network.
To address these issues, the IEEE 802.1 Task Group [2]
is attempting to enable RT and deterministic capabilities
for Ethernet via a set of enhanced standards, namely, time-
sensitive networking (TSN). As the name suggests, the concept
of “time” is the most significant aspect of TSN. The IEEE
802.1AS-rev [3], an advanced profile for the Precision Time
Protocol, is adopted for TSN, so that a global sense of time
can be shared across all networking elements. Benefit from
time synchronization at nanosecond precision, the time-aware
shaper (TAS) defined in IEEE 802.1Qbv [4] is able to construct
high-accuracy time-slots for relaying frames. The TAS is
located at the egress of TSN devices (end-point and switch)
and schedules traffic by operating the gate of the priority
queue so that traffic can be transmitted in specific time-slots.
Furthermore, time-slot assignment and transmission decisions
are arbitrated by a predefined cyclic schedule, referred to as the
gate control list (GCL). The time-based routing is fixed within
deterministic schedules so that it can guarantee predictable de-
livery for RT applications in industrial manufacturing. TSN is
a typical IEEE-compliant and vendor-independent technology,
thus facilitating the convergence of information technology
and operational technology for industrial IoT. Moreover, TSN
is not only applied to the industrial domain, but is also useful
for other disciplines that require hard RT communication, such
as aerospace, smart grids, and intelligent vehicles.
To date, although TSN standards are still under devel-
opment, hard RT and robust deterministic capabilities have
already been realized due to the existence of mature time
synchronization [3] and traffic scheduling [4]. The Industrial
Internet Consortium has announced the successful implemen-
tation of a TSN testbed. Centralized and automated configu-
ration architecture has also been proposed for TSN [5]. This
implementation is used to confirm the performance of TSN
standards. However, few recent studies have focused on build-
ing simulations related to TSN [6][7]. A simulation to demon-
strate the deterministic performance of scheduled traffic in an
Audio-Video-Bridging network, rather than a TSN network,
based on the concepts of TAS and GCL, was developed in
[6]. An industrial simulation framework for investigating non-
time-based components for frame preemption was proposed in
[7]. However, the authors of this paper ignored the effects of
time synchronization, which is the most significant feature of
TSN. In our previous work [8], we modeled a TSN-enabled
switch to schedule time-triggered (TT) traffic using GCL. The
robust deterministic features of TT traffic were achieved under
high loads. However, the end devices were not equipped with
978-1-7281-0302-0/19/$31.00 ©2019 IEEE 153
Legends:
Label 1: Configuration module. Label 2: TAS module. Label 3: Queue module. Label 4: Transmission module.
Label 1-1: An instance of GCL. Label 2-1: Gate operation function.
Label 1-2: Read GCL function. Label 2-2: Timer function.
Label 1-3: Classify data function. Label 2-3: Transmission Selection.
Fig. 1. Modular structure and implementation of the time-sensitive networking (TSN) modules installed at the egress of the end device or switch.
TSN functionality, and therefore the end devices and switches
in the TSN network could not cooperate with each other under
a global schedule.
In this study, we developed a fully TSN-compliant simu-
lation model and investigated its validity using a real-world
testbed. Our main motivations and contributions are:
1) We developed a TSN simulation using a module-based
method to integrate both the end device and switch,
in which network traffic is scheduled under a GCL
configuration.
2) The data latencies obtained from the simulation model
were compared to those measured in the real-world
testbed. The comparison shows that the differences were
insignificant. Thus, the simulation model and experiment
were in good agreement.
3) Simulation is an efficient tool for exploring the technical
feasibility of TSN applications, and is also much more
economical to develop an experimental model of a large-
scale TSN ecosystem by connecting it to the real-world
networks using hardware-in-the-loop (HIL) simulations.
4) Our simulation model can be used to validate TSN
related research, e.g., when designing traffic scheduling
algorithms and synthesizing GCL [9, 10].
The rest of this paper is organized as follows. In Section II,
we introduce the background material on TSN, the modular
structure of the TSN model, and the detailed development
procedure. We elaborate on the real-world implementation of
the TSN testbed and TSN simulation setup in Section III. The
proposed simulation model is evaluated and validated by com-
paring the latency results with those of measurements taken
from the experimental testbed in Section IV. We conclude the
paper in Section V.
II. DE VE LO PM EN T OF T HE TSN SIMULATION MODEL
In this section, we introduce the development of the TSN
simulation model from two perspectives. Specifically, we
introduce concepts related to the TSN simulation model (i.e.,
TAS and GCL) in Part A, whereas in Part B, the modular
structure and implementation details of the TSN model will
be described.
A. Background
IEEE 802.1Qbv proposed time scheduling functionality,
TAS, which is the most important component of TSN for
guaranteeing deterministic and RT transmission. Based on the
eight priority queues defined in IEEE 802.1Q, TAS can sched-
ule traffic by controlling the corresponding time-aware gate of
each queue. Such time-sensitive gate operation requires strict
time synchronization [3] and an ordered list of gate operations,
namely a GCL. The specific description and functionality of
TAS and GCL will be detailed in Part B of this section.
In this study, we developed a TSN simulation model based
154
on a modular discrete network simulator OMNET++ [11]. In
particular, we developed an IEEE 802.1Qbv-compliant TAS
and its configuration interface from scratch. These are the two
most significant aspects of TSN functionality.
B. Implementation Details
The modular structure of the simulation model is shown
on the left-hand side of Fig. 1, and an implementation of the
TSN modules are shown on the right-hand side, as a mapping
to the left-hand side. The legend of each label is presented
below Fig. 1. The proposed modular structure consists of four
modules, i.e., “Configuration,” “Time-Aware Shaper (TAS),”
“Queue,” and “Transmission”.
In general, the “Configuration” module obtains input pa-
rameters from an ordered list of gate operations (i.e., GCL);
then, the obtained parameters [i.e., the time interval (Ti) and
gate state (GSi)] can be used by the “TAS” module, where i
denotes the row number of the GCL. Based on the value of the
parameter GSi, the “TAS” can operate the corresponding gates
of the priority queues of the module “Queue” and transmit the
traffic during a specific Ti. Meanwhile, the module “Queue”
will cache the traffic into different priority queues as soon
as the traffic arrives. The traffic will be stored inside the
queue until the state of the corresponding gate is set to open.
Afterwards, the internal traffic of that queue is forwarded to
the physical media by the “Transmission” module.
Based on this four-module structure, we implement the
TSN simulation model, as shown on the right side of Fig.
1. The implementation of each module will be detailed in the
following subsections.
a) Configuration Module:We defined our GCL as
shown in Label 1-1, which is fully compliant with IEEE
802.1Qbv. The GCL contains two parameters, GSiand Ti,
where idenotes the row number of the GCL. GSiis listed in
the right-hand column, and denotes the “Gate State”, which
has an 8-bit value. Each bit represents the gate state of one
of the priority queues: open “1” or closed “0”; the most
(least) significant bit corresponds to queue 7 (queue 0). For
example, GS1“0000 0001” means that the gate of queue 0
is open, while the others are closed. The parameter “Time
Interval” on the left-hand side of Label 1-1, represents the
time duration required to execute the gate operation for the
gates to remain opened or closed according to a given GSi. To
obtain the input GCL configuration parameters, we developed
an interface called “Read GCL Function,” as shown in Label
1-2, which can receive input file streams and obtain all of the
entries from the GCL. Then “Classify Data Function” (shown
in Label 1-3) will classify the obtained parameters into three
categories according to the data type, i.e., Ti(float type), GSi
(string type), and the length of the GCL, L (integer type).
Afterwards, three kinds of parameters will be passed into the
“TAS” module (shown in Label 2), which is responsible for
traffic scheduling.
b) TAS Module:The most prominent feature of the
TAS is that it transmits different classes of traffic during
individual time-slots, i.e., sufficient idle channels are reserved
Fig. 2. Flowchart of the time-aware shaper (TAS) procedure.
to guarantee the deterministic delivery of TT traffic, without
competing with non-time-critical traffic. Such a mechanism
can be realized by operating time-aware gates for the queues
under the GCL configuration. To better understand the pro-
cedure used to develop the TAS, we will first introduce
the key functionality of the TAS (refer to Label 2 of Fig.
1), including “Timer”, “Gate Operation” and “Transmission
Selection”, which are represented by Labels 2-1, 2-2, and 2-3,
respectively.
The “Timer” and “Gate Operation” can execute the GCL
and perform the gate operation following the sequence of each
row (indexed by i). Specifically, the “Timer” calculates the
operation time-instant (OTi) first; then, “Gate Operation” is
triggered by the “Timer” at each OTito change the GSi(open
or closed) of the priority queues inside the “Queue” module.
When the current state of the queue’s gate is set to open,
“Transmission Selection” will forward the internal traffic to
the “Transmission” module. For instance, at OT2(shown by
Label 2-1), the “Timer” launches the “Gate Operation” with
155
the parameter specified by the third row of the GCL, i.e.,
GS3“0010 0000”. According to GS3, the “Gate Operation”
opens the gate of queue 5 (Q5), and then the “Transmission
Selection” sends the internal TT traffic to the “Transmission”
module during T3(i.e., from OT2to OT3), while the other
queues hold their queue traffic until the corresponding gate is
set to open.
To better understand the implementation details of each
function described in Label 2 of Fig. 1, we present a flowchart
specifying each step in Fig. 2.
Step 1 initializes index ito 1, i.e., the TAS executes the
GCL from the first row. Then, Step 1 receives the values of
GSi, Ti, and L from the “Configuration” module. Note that the
index ialways represents the step of the execution procedure
throughout this flowchart.
Step 2 executes the “Timer” function to trigger the “Gate
Operation” function at each OTito execute the GCL. Initially,
OTiand the current simulation time-instant (CT) are set to
zero. Specifically, Step 2.1 calculates the OTiby summing
OTi−1and Ti. Step 2.2 updates the CT by obtaining the
simulation running time through an application programming
interface (API) called “simTime,” which is provided by OM-
NET++. Accordingly, CT will increase continuously with the
simulation running process. Step 2.3 compares the values of
CT and OT; if they are equal, the “Gate Operation” function
will be triggered; otherwise, it returns to Step 2.2.
Step 3 is activated at OTi, examines the current states of
each gate associated with the eight queues, then stores the
values of gate state (open “1” or closed “0”) in an 8-bit string
called the current gate state (CGSi). Step 3.1 compares the
CGSiwith the 8-bit GSiobtained from the GCL; if they are
different, Step 3.2 will set the CGSito the GSi;otherwise, it
jumps directly to Step 4.
Step 4 forwards the queued traffic to the “Transmission”
module if the CGSiof that queue is set to open. Otherwise,
it will hold the traffic until the corresponding gate is set to
open.
Step 5 maintains the cycle time for the gate operation.
Basically, once Tihas elapsed since the previous gate opera-
tion, the next entry in the GCL will be executed. Specifically,
λiis initialized to Ti, and then λidecreases by Tick (one
nanosecond), which is the smallest time unit that can be
recognized by this simulation model. Then, Step 5.1 evaluates
whether the cycle for the current gate operation has terminated,
i.e., the loop will continue if λihas not decreased to zero;
otherwise, Step 5.2 will be executed. In Step 5.2, the index
iof the current GCL is increased by 1. Afterwards, Step
5.3 examines whether iis greater than L (the maximum row
number of the GCL). If true, iwill be reset to zero; otherwise,
“Timer” and “Gate Operation” will execute the next entry of
GCL (i.e., the same procedure will be repeated from Step 2.1).
c) Queue Module:The module “Queue” in Fig. 1 is
adopted from the CoRE4INET-Framework [12], which is used
to store the different traffic classes in their corresponding
priority queues. As shown in Label 3, the module “Queue”
consists of eight priority queues corresponding to eight traffic
Fig. 3. An instance of the profile (omnetpp.ini) for OMNET++.
TABLE I
TRA FFIC PARAMETERS
Source Destination Transmission
interval Priority Payload size
(bytes)
TSN Talker 1 TSN Listener 1 10 ms 5 50
TSN Talker 2 TSN Listener 2 10 ms 5 100
TSN Talker 3 TSN Listener 3 10 ms 5 200
TSN Talker 4 TSN Listener 4 10 ms 5 300
TG TR [1 µs, 100 ms] 0 1, 500
classes, where the priority is from seven (highest) to zero
(lowest). For example, TT traffic with priority five can be
queued in queue 5 (Q5), and the lowest-priority BE traffic
is stored in queue 0 (Q0). Afterwards, the traffic inside the
queue will be scheduled and forwarded by the “TAS” module.
d) Transmission Module:To forward the scheduled
traffic to the egress, we use a “Transmission” module based on
the INET-framework, which executes a MAC-relay function,
as shown in Label 4 of Fig. 1. Specifically, the traffic from
the upper layer will be handled by the MAC-relay function,
which identifies the mapping between the egress and the MAC
address; then, the traffic is forwarded to the egress.
It should be noted that the developed TSN functionality
can easily be extended and executed using the omnetpp.ini
configuration file provided by OMNET++. As shown in Fig.
3, based on the omnetpp.ini configuration file, both the TSN
end device and the switch can enable the “TAS” module by
setting “true” and allocating the attendant input information
(i.e., GCL). Using the developed TSN modules, alternative,
even complex, TSN network topologies can easily be deployed
with minimal effort. This will greatly promote the progress of
TSN development by serving as an effective verification tool.
III. EXP ER IM EN TAL IMPLEMENTATION AND SIMULATION
SET UP
First, we implemented a real-world TSN testbed from
scratch to validate the developed TSN simulation model. Then,
we deployed a simulation network model, including the four
TSN modules introduced in Section II, that maps to the
experimental testbed.
A. TSN Testbed Implementation and Measurement
To validate the developed TSN simulation model, we im-
plemented a real-world TSN testbed, as shown in Fig. 4. In
general, two TSN switches are connected directly: TSN Switch
1 is connected to the source hosts, i.e., four TSN Talkers and
a traffic generator (TG), whereas TSN Switch 2 is connected
to the destination hosts, including four TSN Listeners and a
traffic receiver (TR). The traffic streams sent from different
156
Fig. 4. The hardware implementation of TSN testbed.
sources (i.e., TG and four TSN Talkers) share a single egress
of TSN Switch 1, and the routing of the point-to-point streams
are shown by dotted lines with different colors (i.e., green,
orange, pink, purple, and grey). The light blue lines indicate
that GCLs are used to configure the TSN Talkers and switches.
The Central Network Controller (CNC) is standardized for
centrally configuring TAS in the TSN devices (switch or end-
point) [2]. Herein, CNC is implemented with Cisco software
application with the purposed of computing GCLs for the real-
world TSN testbed.
The characteristics of the traffic generated by the four
TSN Talkers and the TG are presented in Table I. To be
specific, four TT traffic streams sent from TSN Talkers to
TSN Listeners have the same transmission interval (10 ms),
a priority of 5, and different payload sizes. The TG sends
a varying amount of BE traffic to the TR by adjusting the
transmission interval, i.e., 100 ms, 10 ms, 1 ms, 100 µs, 10
µs, and 1 µs. Thus, the link between the two TSN switches,
which is shared by all traffic, will be stressed by the varying
amount of BE traffic. After the minimum interval (i.e., 1 µs) is
specified, the 1Gb/s-link will be fully utilized by the 1 Gbit of
BE traffic. This is considered the worst-case scenario, and it is
apparent that without effective traffic scheduling functionality
(e.g., if a pure Ethernet mechanism is used), a huge amount
of BE traffic may potentially interfere with the TT traffic.
We use this worst-case scenario to compare the latencies
of the developed TSN simulation model with a real-world
TSN testbed, so that we can validate the simulation model
and examine whether the developed simulation functionality
satisfies the RT and deterministic requirements.
For the hardware implementation, we adopt two Cisco
Industrial Ethernet (IE 4K) switches to act as TSN switches to
perform traffic scheduling under the GCL configuration. We
integrate a Raspberry PI with an analog device (AD module)
[13] via Ethernet to serve as the TSN Talker and Listener. The
Raspberry PI is responsible for sending and receiving traffic,
while the AD module is used as the TSN agent, which provides
the TSN functionality (i.e., time synchronization and traffic
scheduling) for the Raspberry PI and converts Ethernet frames
Fig. 5. TSN simulation topology.
to TSN frames, and vice versa. The AD module is limited by
the link access speed, i.e., 100 Mb/s [13]. Hence, we set the
link rate to 100 Mb/s (i.e., the black lines shown in Fig. 4)
and the rest of the red lines to 1 Gb/s. In other words, all
of the links connected to the AD module should not exceed
100 Mb/s. We employ a Linux personal computer (PC) to
run the Cisco CNC to compute the GCLs. The configurations
(i.e., input and output) of the Cisco CNC are specified in next
section. Moreover, we use open-source software [14] to run
the TG on the Linux PC and generate a massive amount of
BE traffic to be handled by the TR, thus establishing a high
load scenario and even the worst case.
To compare the simulation results with the experimental
results measured on the real-world TSN testbed, we adopt an
in-line Ethernet measurement device called ProfiShark 1G+
[15] to measure the end-to-end latency (TE2E) from the TSN
Talker to the TSN Listener. For the measurement setup, we use
two ProfiShark 1G+ devices and deploy them at the egress
of the TSN Talkers and the ingress of the TSN Listeners,
respectively. The TT traffic sent out from the egress of the
TSN Talker will be timestamped initially, then timestamped
again when it arrives at the ingress of the TSN Listeners. The
difference between these two timestamps is taken as the TE2E.
B. TSN Simulation Setup
We evaluate and validate our TSN simulation model by
building an identical simulated topology as the presented
TSN testbed. As shown in Fig. 5, two TSN switches are
interconnected, four TSN Talkers (i.e., source hosts) send TT
traffic to four TSN Listeners (i.e., destination hosts), and there
is one TG and its TR. The traffic routings are indicated by the
dotted lines shown in Fig. 5 and the traffic parameters are
presented in Table I, as well as the line speed (i.e., red line
“1 Gb/s” and black line “100 Mb/s”), which we use to setup
the simulation. These values are exactly the same as the those
of the TSN testbed. Also, we input identical GCLs (refer to
the light blue line) from those of the Cisco CNC of the TSN
testbed into the simulation model. Recall that the GCL is a
gate operation list that is used to schedule traffic by operating
157
TABLE II
GCLS OB TAIN ED FRO M CIS CO CNC
Schedule (µs)
TSN Talker TSN Switch 1 TSN Switch 2
TOpen TClose TOpen TC lose TOpen TClose
TT Traffic 1
TSN Talker 1
654 667 688 816
119 248
TT Traffic 2
TSN Talker 2
668 680 719 847
250 379
TT Traffic 3
TSN Talker 3
682 694 718 846
381 509
TT Traffic 4
TSN Talker 4
696 708 830 958
511 640
priority queues, and the GCL entries can be obtained using
the “Configuration” simulation module, which is detailed in
Section II.
IV. EVALUATION RESULTS AND DISCUSSIONS
In this section, we evaluate the numerical results obtained
from the simulation and compare them with those measured
using the TSN testbed to validate the proposed TSN simulation
model. As mentioned previously, we use the CNC Cisco
software package to specify valid GCLs for our simulation
and testbed. We configure the Cisco CNC using the following
setup.
Cisco CNC inputs:
•Physical topology: We build the virtual physical topology
using the web user interface provided by Cisco CNC,
which matches the topology of the experiment (Fig. 4)
and simulation (Fig. 5) exactly.
•Stream parameters: The TT traffic specifications shown in
Table I are required by Cisco CNC to compute the GCL,
i.e., the payload size, priority, transmission interval, and
source and destination of each TT stream.
•Constraint: The maximum allowable latency from the
TSN Talker to the TSN Listener, which has a default
value of 1 ms, is set automatically by Cisco CNC.
Hence, the TE2Eof all scheduled TT traffic streams in
the simulation and experiment must be lower than the
maximum allowable latency, i.e., 1 ms.
Based on the inputs described above, the Cisco CNC com-
putes the effective schedules (GCLs) and assigns dedicated
time-slots for transmitting each TT traffic stream. The output
from Cisco CNC is summarized in Table II, which shows
the specific schedules for the TT traffic, including the time-
instant at which the transmission window for TT traffic is
opened (TOpen) and closed (TC lose) at each hop (i.e., four
TSN Talkers and two TSN switches). The schedules generated
by Cisco CNC are required to have the same hyperperiod, of
10 ms, because the four TT traffic streams have the same
transmission interval (i.e., 10 ms). In our case, the TT traffic
and BE traffic are assigned to queue 5 (Q5) and queue 0 (Q0),
respectively. During the dedicated Tifor scheduling TT traffic,
the GSifor the eight priority queues are set to “0010 0000”,
which means that only Q5 is open to the transmission of TT
(a) Time-slots allocation for time-triggered (TT) traffic.
(b) Time-slots allocation at TSN Switch 1.
Fig. 6. Illustration of time-slots allocation in Table II.
traffic, while the other queues hold the BE traffic until Q0 is
opened, i.e., when the TT traffic transmission is completed.
To isolate TT traffic from others and thus guarantee sufficient
idle bandwidth, a guard band (GB) is introduced by IEEE
802.1Qbv [4] and should be reserved before the slots for the
TT traffic is assigned. The GSiis set to “0000 0000” during
the GB period, which means that all of the gates of the eight
priority queues are closed to guarantee that the link is idle
at the beginning of the TT traffic transmission. All of the
remaining time-slots, except those for TT traffic and GB, are
allocated for BE traffic transmission.
To facilitate understanding of how the time-slots are as-
signed in Table II, we present Fig. 6, which shows the slots
allocated for TT and BE traffic. In general, Fig. 6 (a) shows
the time-slots allocation for each TT traffic stream transmitted
by the TSN Talkers and switches, while Fig. 6 (b) shows the
time-slots allocation for all scheduled traffic at the same egress
of TSN Switch 1.
As shown in Fig. 6 (a), there are four timelines illustrating
the schedules of each TT traffic stream, and each timeline
contains three boxes to indicate the time-slot allocation at
the four TSN Talkers, TSN Switch 1 and TSN Switch 2. In
each time box, the time-instants of the opening (TOpen) and
closing (TClose ) of the TT traffic transmission windows are
shown in different colored fonts, i.e., blue for TOpen and red
for TClose . Based on the global schedules (i.e., GCLs), which
are computed by the Cisco CNC, the TSN Talkers generate
TT traffic [refer to light blue arrows in Fig. 6 (a)] as soon
as the transmission window is set to open, at TOpen, which
is conducive to minimizing the TE2E. Four dedicated time-
slots are allocated to the same egress as TSN Switch 1 to
transmit TT traffic sent from the four TSN Talkers. The four
time-slots are allocated continuously and do not overlap, thus
avoiding interference due to the transmission of other traffic.
The four TSN Listeners are connected to the four individual
egress ports of TSN Switch 2. Hence, the time-slots allocation
can be overlapped at different egresses.
158
Fig. 7. End-to-end latency (TE2E) comparison: numerical and experimental results.
Fig. 8. Simulation TE2Ecomparison: TT traffic and best-effort (BE) traffic.
As shown in Fig. 6 (b), the slots are allocated to schedule
both TT and BE traffic within one hyperperiod (i.e., 10 ms),
at the egress of TSN Switch 1. Specifically, the time-slots
of the four TT traffic streams (red box) last from 654 µs to
708 µs, as indicated in Table II. Before the TT time-slots, a
GB (black box) is allocated for the length of time it takes to
transmit a maximum-sized Ethernet frame [4], i.e., 13 µs in
the case of a transmission rate of 1 Gb/s. The rest time of the
slots, indicated by the light blue boxes, is fully utilized by the
BE traffic. All of the GCLs are repeated after a hyperperiod
lasting 10 ms. The developed simulation model and testbed are
fully compliant with TSN standards. Thus, the TSN schedule
(i.e., GCLs) summarized in Table II can be deployed in the
TSN simulation model and the real-world TSN testbed with
minimal effort. Afterwards, we measured the TE2Ebetween
the TSN Talker and TSN Listener.
We calculated the TE2Eof four TT traffic streams and BE
traffic obtained in both the simulation and the experimental
testbed using equation (1),
TE2E=TDestination −TSour ce (1)
where TSource and TD estination are the timestamps obtained
at the egress of the TSN Talker (or TG) and the ingress of the
TSN Listener (or TR), respectively. We measured the TE2Eof
the TSN simulation model and the TSN testbed, taken from
1,000 packets under the worst case (i.e. the interval of BE
traffic is set to 1 µs). The respective latencies (TE2E) are
plotted in Fig. 7. We also averaged the latency results and
present them in Table III.
As shown in Fig. 7, the TE2Eresults of the simulation
TABLE III
MEA N LATEN CY BA SE D ON TH E RE SULT S SHOW N IN FI G. 7.
Statistic TT Traffic 1 TT Traffic 2 TT Traffic 3 TT Traffic 4
Mean (µs)
Experiment 569.195 469.163 338.155 319.15
Simulation 569 469 338 319
159
(red lines) overlap with those of the experiment (blue lines).
Meanwhile, the difference between the average latency (see
Table III) of the simulation and the experiment is trivial. The
results of this comparison demonstrate that the developed TSN
simulation model is in good agreement with the real-world
TSN testbed.
To further verify RT and deterministic transmission of TSN,
we also evaluated the TE2Eof the proposed TSN simulation
model while varying the amount of BE traffic through the
simulation network. The mean latencies of 1,000 packets of
TT and BE traffic were analyzed using the proposed TSN
simulation model. These are plotted as a double Y-axis line
graph in Fig. 8, where the left-hand Y-axis shows the latency
of the TT traffic in µs, and the right-hand Y-axis shows the la-
tency of the BE traffic. The X-axis represents the transmission
interval of the BE traffic and has the same logarithmic scale
as the right-hand Y-axis. When the transmission interval of
the BE traffic is set to exceed 100 µs, the traffic has constant
latency because the link is sufficiently idle. As the amount
of BE traffic increases (i.e., the transmission interval is set
to less than 100 µs), the TE2Eof the BE traffic increases
almost exponentially. However, the TE2Eof the four TT traffic
switches is never disturbed by the BE traffic sent by the TG;
thus, the latency remains constant in this case. The results of
this evaluation confirm that our simulation model conforms
well to the TSN specifications. Even under the worst-case
scenario; when the link is fully utilized by the BE traffic
with a 1 µs interval, the developed TSN functionality is still
able to properly schedule the TT traffic and satisfy the robust
deterministic and RT requirements (i.e., the TE2Eis less than
the maximum allowable latency of 1 ms, as defined in Section
III-B).
The results of this evaluation confirm that the developed
TSN simulation model meets the TSN specifications and
matches the measurement results obtained from a real-world
TSN testbed. Hence, the validated TSN simulation model can
be used as an effective verification tool for exploring the
technical feasibility of TSN applications further.
V. CONCLUSIONS AND FUTURE WORK
We developed a TSN simulation model using a module-
design method, and implemented TSN functionality to sched-
ule traffic under configurations defined in terms of GCLs. We
detailed the time-slot allocation for all traffic based on the
GCLs output by Cisco CNC. The developed simulation model
has been carefully evaluated and validated by comparing the
simulation results with the measurements obtained from a
real-world TSN testbed. Our analytical results confirm that
the presented simulation modules tightly conform to the TSN
specifications of deterministic and RT communication with
ultra-low jitter and are consistent with the results obtained
from a real-world TSN testbed. Hence, the validated TSN
simulation model is an effective verification tool for further
exploring the technical feasibility of TSN-based applications.
In the future, we will extend the current TSN model to a
HIL simulation by adopting the “cScheduler” interface from
the OMNeT++ library. Such an interface will allow us to
use PCAP (Packet Capture Library) [16] and raw sockets to
exchange packets between the simulation and real devices; the
details of this interface are provided in Chapter 17 of [17].
Hence, we can connect hundreds of TSN simulation nodes to
a real device-limited network. This means that we will be able
to implement and evaluate a large-scale TSN ecosystem in our
future research.
ACKNOWLEDGMENTS
This work was supported under three foundations,
two of which are the international cooperation program
(Korea-China) managed by the National Research Foun-
dation of Korea (NRF-2016K2A9A2A11938310 and NRF-
2018K1A3A1A61026320), the other is National Key R&D
Program of China (2017YFE0123000).
REFERENCES
[1] IEEE, “802.3 Standard for Ethernet,” 2015.
[2] “Time-Sensitive Networking Task Group,” IEEE 802.1, 2016. [Online].
Available: http://www.ieee802.org/1/pages/tsn.html.
[3] “P802.1AS-Rev – Timing and Synchronization for Time-
Sensitive Applications,” IEEE 802.1. [Online]. Available:
https://1.ieee802.org/tsn/802-1as-rev/.
[4] “802.1Qbv - Enhancements for Scheduled Traffic,” IEEE 802.1. [On-
line]. Available: http://www.ieee802.org/1/pages/802.1bv.html
[5] P. Didier and J. Fontaine, ”Results, Insights and Best Practices from
IIC Testbeds: Time-Sensitive Networking Testbed”, IIC Journal of
Innovation, 2017.
[6] C. Park, J. Lee, T. Tan, and S. Park, ”Simulation of scheduled traffic
for the IEEE 802.1 time sensitive networking,” in Information Science
and Applications (ICISA) 2016: Springer, 2016, pp. 75-83.
[7] P. Heise, F. Geyer, R. Obermaisser, ”TSimNet: An industrial time
sensitive networking simulation framework based on OMNeT++”, Proc.
IEEE/IFIP Int. Conf. New Tech. Mobility Security (NTMS) 2016, pp.
1-5.
[8] J. Jiang, Y. Li, S. H. Hong, A. Xu, and K. Wang, ”A Time-sensitive Net-
working (TSN) Simulation Model Based on OMNET++,” in 2018 IEEE
International Conference on Mechatronics and Automation (ICMA),
2018, pp. 643-648.
[9] R. Oliver, S. Craciunas and W. Steiner, ”IEEE 802.1Qbv Gate Control
List Synthesis Using Array Theory Encoding”, in 2018 IEEE Real-Time
and Embedded Technology and Applications Symposium (RTAS), 11-13
April, 2018.
[10] L. Zhao, P. Pop and S. Craciunas, ”Worst-Case Latency Analysis for
IEEE 802.1Qbv Time Sensitive Networks Using Network Calculus”,
IEEE Access, vol. 6, pp. 41803-41815, 2018.
[11] ”OMNeT++ Discrete Event Simulator”, 2018. [Online]. Available:
https://omnetpp.org/.
[12] ”CoRe4INET Framework”, 2018. [Online]. Available:
https://core4inet.core-rg.de.
[13] ”TSN Evaluation Kit Quick Start Guide”, Analog Device, 2017.
[Online]. Available: https://www.analog.com/media/en/technical-
documentation/user-guides/tsn-evaluation-kit-quickstart-guide.pdf.
[14] S. P., Ostinato Packet Generator, 2019. [Online]. Available:
https://ostinato.org/.
[15] ”PROFISHARK 1G+ Datasheet”, Profitap, 2018. [Online]. Avail-
able: https://www.profitap.com/wp-content/uploads/ProfiShark-1G-Plus-
Datasheet.pdf.
[16] ”Manpage of PCAP.” [Online]. Available:
http://www.tcpdump.org/manpages/pcap.3pcap.html.
[17] “OMNeT++ Simulation Manual.” [Online]. Available:
https://www.omnetpp.org/doc/omnetpp/manual/.
160
Powered by TCPDF (www.tcpdf.org)
