---
title: 'IN2C: TSN Industrial IoT Framework'
url: https://www.emergentmind.com/topics/in2c
type: topic
---

# IN2C: TSN Industrial IoT Framework

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 [2507.11250].

## 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 [2507.11250].

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 [2507.11250].

## 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 [2507.11250].

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 [2507.11250].

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** [2507.11250].

## 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 [2507.11250].

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 [2507.11250].

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 [2507.11250].

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 [2507.11250].

## 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 [2507.11250].

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** [2507.11250].

## 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 [2507.11250].

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 [2507.11250].

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 [2507.11250].

## 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 [2507.11250].

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 [2507.11250].

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 [2507.11250].

Source: https://www.emergentmind.com/topics/in2c