IN2C: TSN Industrial IoT Framework

• IN2C is a simulation framework that models TSN-enabled industrial IoT networks with synchronized production cells and a centralized infrastructure.
• It evaluates the impact of FRER, achieving zero packet loss and sub-millisecond recovery during realistic fault injection scenarios.
• The framework highlights trade-offs by demonstrating that enhanced resilience can lead to 2–3× increased link utilization and potential timing impacts on high-bandwidth flows.

IN2C, short for Industrial Network with TSN-enabled Cells, is a scenario-driven simulation framework for evaluating resilient Time-Sensitive Networking (TSN) in industrial IoT environments. It is implemented in OMNeT++ using the INET framework, extended with TSN-specific modules, and models a smart-factory network with two synchronized production cells connected to a centralized infrastructure. Its central purpose is to study how TSN mechanisms behave under realistic failures, especially when Frame Replication and Elimination for Redundancy (FRER) is enabled. In the reported evaluation, FRER eliminates packet loss and achieves submillisecond recovery, but at the cost of 2–3× higher link utilization and, for some high-bandwidth flows, degraded timing predictability (Seliem et al., 15 Jul 2025).

1. Concept and motivation

IN2C was introduced to address a gap in the evaluation of TSN for industrial systems. The motivating observation is that TSN is increasingly adopted to satisfy strict latency, jitter, and reliability requirements, yet its fault tolerance is difficult to assess under realistic failure conditions. Prior work is described as focusing mainly on scheduling, latency, or isolated failure events, whereas IN2C was designed to model a more complete factory-like environment with synchronized cells, mixed industrial traffic, and controlled failures (Seliem et al., 15 Jul 2025).

The framework is therefore positioned not as a generic network simulator, but as a fault-oriented experimental environment for deterministic industrial Ethernet. The industrial rationale is explicit: modern IIoT and smart manufacturing systems require communication that is not only low-latency and low-jitter, but also highly available under faults. Traditional Ethernet does not provide the deterministic timing and failover behavior required for control loops, sensor-actuator interactions, inspection streams, SCADA traffic, and HMI supervision. IN2C evaluates how TSN mechanisms address those requirements in a realistic topology rather than in idealized or static settings (Seliem et al., 15 Jul 2025).

2. Network architecture and system model

The IN2C topology models a smart factory composed of two synchronized production cells and a centralized infrastructure. Each production cell contains a sensing unit, control unit / PLC, actuating unit, robot arm, and inspection system. The centralized infrastructure includes SCADA, HMI, an Edge unit, surveillance cameras, and quality-control switches. Communication is organized through a hierarchical TSN network with cell-level switches and backbone aggregation switches (Seliem et al., 15 Jul 2025).

At the cell level, each production cell uses two TSN-capable switches, exemplified as SwitchA_X and SwitchB_X. The core network includes centralSwitch_1, centralSwitch_2, and centralSwitch_3, while qcSwitch_1 and qcSwitch_2 connect quality-control and supervisory components. This design is explicitly modular and fault-tolerant. Devices in each production cell are dual-homed through the two local switches, and the backbone offers multiple forwarding options toward the centralized infrastructure. The link configuration uses 1 Gbps links in the backbone and 100 Mbps links at the edges, matching the deployment assumptions studied in the paper (Seliem et al., 15 Jul 2025).

All nodes are modeled as TSN-enabled through INET’s TsnDevice and TsnSwitch abstractions. The framework supports configurable traffic generation, stream encoding and decoding, shaping, policing, and redundancy logic. The event-driven workflow is described in six steps: initialize topology, clocks, applications, and stream mappings; generate periodic or event-driven UDP traffic; schedule and shape traffic using TSN mechanisms; inject failures using XML scripts; recover using FRER if enabled; and record delay, jitter, packet loss, and recovery time (Seliem et al., 15 Jul 2025).

3. Modeled TSN mechanisms

IN2C integrates the principal TSN mechanisms needed for deterministic and resilient industrial networking. Time synchronization is implemented with IEEE 802.1AS gPTP using a dedicated masterClock. The synchronization model is a propagation chain in which the master clock distributes time, switches forward synchronization downstream, and end devices align their local oscillators to a shared time base. This common time reference is foundational for deterministic transmission timing (Seliem et al., 15 Jul 2025).

Traffic regulation is modeled through traffic shaping and prioritization. The paper states that IN2C uses an always-open gate schedule together with credit-based shaping per port. Forwarding is summarized conceptually as filtering packets by PCP and stream ID, applying shaping parameters such as idle slope and burst control, and dispatching when the gate is open. The framework also represents heterogeneous priority structure through example PCP assignments: 6 for control and sensing, 5 for inspection and robot status, 2 for camera surveillance, and 4, 3, 1 for supervisory or lower-priority flows (Seliem et al., 15 Jul 2025).

The switches additionally perform per-stream filtering and policing. At ingress, streams are identified by source, destination, and PCP, then metered, policed, and shaped to enforce bandwidth and burst constraints. This is essential for mixed-criticality industrial traffic in which critical control flows must be isolated from less stringent traffic classes (Seliem et al., 15 Jul 2025).

Fault tolerance is provided through IEEE 802.1CB FRER. In redundancy mode, selected streams are replicated over disjoint paths, and the receiver accepts the first valid copy while eliminating duplicates. IN2C uses the StreamRedundancyConfigurator to enable FRER in redundancy scenarios. The mechanism is studied precisely because it changes failure behavior: without FRER, a path failure interrupts delivery; with FRER, duplicate frames continue to arrive through alternate paths, enabling zero packet loss and sub-millisecond failover, though with additional bandwidth overhead and possible jitter effects (Seliem et al., 15 Jul 2025).

4. Fault injection methodology and evaluated scenarios

Faults in IN2C are injected through XML-based ScenarioManager scripts. Files such as linkfailure.xml and cellfailure.xml define timed events that disconnect and reconnect Ethernet gates between modules. This makes failures deterministic, repeatable, and aligned across simulation runs. Although the framework supports link and node failures, the reported evaluation uses link-level disruptions rather than physical node crashes, in order to emulate practical industrial faults such as cable damage or malfunctioning aggregation links or switches (Seliem et al., 15 Jul 2025).

The study evaluates four scenarios, grouped into two fault cases with and without redundancy:

Scenario	Fault case	Redundancy
S1A1	link failure between SwitchA_1 and SwitchB_1	no FRER
S1A2	link failure between SwitchA_1 and SwitchB_1	with FRER
S2A1	disconnect centralSwitch_2 from Edge unit and SCADA	no FRER
S2A2	disconnect centralSwitch_2 from Edge unit and SCADA	with FRER

The timing is fixed per scenario. In S1, the fault occurs at 4 s, recovery occurs at 6 s, and total runtime is 10 s. In S2, the fault occurs at 2 s, recovery occurs at 3 s, and total runtime is 5 s. These scenarios correspond, respectively, to a mid-cell link failure and a wider cell-disconnection event (Seliem et al., 15 Jul 2025).

5. Quantitative behavior under failure and recovery

The principal quantitative comparison is between non-redundant TSN and FRER-enabled TSN in terms of packet loss and recovery time. The paper reports the following values:

Scenario	Loss	Recovery
S1A1	20.2%	2.0 s
S1A2	0.0%	< 1 ms
S2A1	26.3%	1.0 s
S2A2	0.0%	< 1 ms

The corresponding packet counts are also given explicitly: S1A1 has 1,337 sent, 270 lost, and 1,067 received; S1A2 has 1,331 sent, 0 lost, and 1,331 received; S2A1 has 75,096 sent, 19,776 lost, and 55,320 received; and S2A2 has 75,126 sent, 0 lost, and 75,126 received. The contrast is direct: non-redundant TSN loses packets during failures and only recovers after the fault clears, whereas FRER provides seamless failover with effectively instantaneous recovery (Seliem et al., 15 Jul 2025).

The delay and jitter results are more nuanced. For the S1 control stream (Sensing_1 → Control_1), S1A1 reports median latency 24.01 μs, mean 18.93 μs, and jitter standard deviation 6.29 μs; S1A2 reports median latency 29.81 μs, mean 27.43 μs, and jitter standard deviation 8.13 μs. This indicates that FRER slightly increases latency, attributed in the paper to duplicate handling and buffering, but preserves bounded behavior during failure (Seliem et al., 15 Jul 2025).

For the S2 inspection stream (Inspection_2 → Edge unit), the results show the main limitation of indiscriminate redundancy. S2A1 has median latency 51.28 μs, peaks over 90 μs, and jitter standard deviation 17.32 μs. S2A2 has median latency 45.99 μs, mean 63.27 μs, latency up to 879 μs, and jitter ranging from −224 to +224 μs. The paper identifies this as the key nuance: FRER eliminates packet loss, but for a high-bandwidth inspection stream it can worsen timing predictability because redundancy creates congestion and path imbalance in the core (Seliem et al., 15 Jul 2025).

6. Bandwidth cost, design tradeoffs, and deployment significance

The link-utilization analysis shows the cost of resilience. In the non-redundant S1 case, utilization remains around 4–5% until failure, then drops to zero during disconnection. With FRER in S1A2, duplicate traffic raises utilization on selected links to about 13–15%, with another path around 5%, and the direct path around 2%. In S2A2, the high-rate inspection flow pushes some links close to 100% utilization even in fault-free operation. The paper summarizes the resulting bandwidth penalty as a 2–3× increase in link utilization in some cases (Seliem et al., 15 Jul 2025).

This leads to the paper’s most important design conclusion: FRER is not universally beneficial for all traffic classes. A common simplification is to treat redundancy as an unconditional improvement. The reported results do not support that view. Instead, they indicate that FRER is most appropriate for critical low-volume control flows where losslessness and sub-millisecond recovery dominate, whereas indiscriminate replication of high-rate or bursty traffic, such as inspection video, can create heavy-tailed delay and large jitter excursions (Seliem et al., 15 Jul 2025).

The practical implications given in the paper are correspondingly selective. Redundancy should be topology-aware; duplicated paths should avoid congestion-prone shared core links; capacity planning must account for duplication overhead; and FRER should be combined with shaping, policing, and VLAN isolation to prevent duplicate traffic from destabilizing other flows. The paper also suggests adaptive redundancy, where FRER is enabled only when flow criticality or link health justifies it. In this sense, IN2C functions as a decision-support framework for resilient industrial TSN design rather than as an argument for universal replication. The work also contrasts FRER with legacy protection mechanisms such as STP, RSTP, and ERPS, which are described as too slow for TSN deadlines (Seliem et al., 15 Jul 2025).