Pith. sign in

REVIEW 4 major objections 5 minor 12 references

Resilient Time-Sensitive Networking for Industrial IoT: Configuration and Fault-Tolerance Evaluation

T0 review · 4 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read FRER-based redundancy in TSN eliminates packet loss and recovers from link and cell failures in under a millisecond, at the price of 2-3x link utilization.

desk verdict A reproducible TSN simulation testbed with honest, but unsurprising, FRER findings; needs buffer/seed/recovery-metric fixes before the lossless headline is trustworthy. read the letter →

arxiv 2507.11250 v1 pith:AIB2K5TU submitted 2025-07-15 cs.NI

Mohamed Seliem , Dirk Pesch , Utz Roedig , Cormac Sreenan This is my paper · ORCID
classification cs.NI
keywords Time-SensitiveNetworkingFrameReplicationandEliminationforRedundancy(FRER)IndustrialIoTfaulttolerancenetworkresiliencelinkfailuresimulationevaluationdeterministic
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper sets out to show how Time-Sensitive Networking (TSN) behaves under realistic factory failures, and what redundancy costs. Using the IN2C simulation framework—a model of two synchronized production cells feeding centralized SCADA, edge, and HMI infrastructure—the authors inject timed link and cell disconnections and compare TSN running with and without Frame Replication and Elimination for Redundancy (FRER). The headline result is that FRER removes packet loss entirely and restores delivery in under a millisecond, while unprotected streams lose 20-26% of packets and only recover once the broken link is repaired. The paper also shows the price: protected links run 2-3x higher utilization, and for high-rate inspection video FRER can introduce heavy latency tails. A sympathetic reader would take away that FRER is a powerful but not free resilience tool, best reserved for critical low-volume flows.

What carries the argument

The load-bearing mechanism is IEEE 802.1CB Frame Replication and Elimination for Redundancy (FRER), configured through the IN2C framework's StreamRedundancyConfigurator. FRER duplicates each protected stream onto disjoint forwarding paths at the sender and eliminates duplicates at the receiver, so when a link or cell fails the first valid replica still arrives—no rerouting signaling or recovery timer is involved. Supporting machinery includes gPTP time synchronization from a master clock, always-open gate schedules with credit-based shaping, per-stream PCP-based filtering, and XML-driven fault scripts that disconnect and restore Ethernet gates at precise simulation times.

What would settle it

Compare the four fault scenarios against a physical TSN switch testbed or the hardware-aligned TSN simulator cited as [5], measuring median latency, packet loss, recovery time, and link utilization; if FRER-protected streams show nonzero loss, recovery times above one millisecond, or overhead well outside 2-3x, the paper's quantitative claim would be overturned, even if its qualitative trade-off remains.

Watch

Extended reading notes

Core claim

The paper's central discovery is that pre-placed stream duplication, not reactive rerouting, is what makes TSN fault-tolerant in the sub-millisecond regime. In the modeled two-cell industrial network, a link failure between SwitchA_1 and SwitchB_1 causes 20.2% packet loss on the sensing/control stream without redundancy and a 2-second recovery; with FRER, the same stream loses no packets and recovers in under a millisecond. A cell-level disconnection that severs centralSwitch_2 from SCADA and the Edge unit costs 26.3% of inspection packets without protection, versus zero with FRER. The price is bandwidth: redundant forwarding pushes utilization on shared core links to roughly two to three times the unprotected level, and the high-rate inspection stream sees latency spikes up to 879 µs and wide jitter under FRER, indicating that duplication can overload congested segments. The paper therefore establishes both the benefit and the boundary condition of FRER in bandwidth-constrained industrial TSNs.

Load-bearing premise

The entire quantitative argument rests on the IN2C simulator's TSN models—gPTP synchronization, credit-based shaping, and IEEE 802.1CB FRER—faithfully matching real switch behavior, even though the paper does not validate these numbers against physical hardware or the hardware-aligned simulation models it cites.

Editorial extensions

If this is right

  • Control loops carried over FRER-protected streams can survive link and cell failures with zero packet loss and sub-millisecond recovery, supporting lossless failover for industrial automation.
  • Unprotected TSN streams lose 20-26% of their packets during comparable failures and only resume after repair, so loss-sensitive flows in converged factory networks need redundancy.
  • Network capacity planning must budget 2-3x bandwidth on links that carry duplicated streams, including under nominal operation, not just during faults.
  • High-rate or bursty streams such as inspection video can suffer heavier tails and jitter under FRER when shared core links approach saturation, so redundancy should be applied selectively.
  • The IN2C framework's XML-driven fault injection provides a reusable way to evaluate other failure scenarios, redundancy policies, and scheduling options for TSN deployments.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • I infer that the practical design rule emerging from this trade-off is per-flow redundancy: protect only streams with strict loss and latency constraints, and keep high-bandwidth inspection traffic on single paths with spare capacity, unless excess bandwidth is provisioned.
  • The large jitter tail observed for the inspection stream under FRER suggests a testable extension: placing redundant trees so they avoid sharing congestion-prone core links should remove most of the variability, and this can be checked directly in IN2C or a hardware testbed.
  • If the simulator's quantitative behavior is confirmed by hardware validation, the 2-3x overhead ratio could be used as a rule-of-thumb cost estimate when comparing FRER against alternatives like MPLS-TP fast reroute or scheduled-traffic-based redundancy.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper presents IN2C, an OMNeT++/INET-based TSN simulation framework for industrial IoT networks, modeling two synchronized production cells connected to centralized infrastructure. It implements gPTP synchronization, credit-based shaping, per-stream filtering, and FRER, together with XML-driven fault injection for link and node failures. Four fault scenarios are evaluated—link failure and cell disconnection, each with and without FRER—and the paper reports end-to-end latency, jitter, packet loss, link utilization, and recovery time. The headline claims are that FRER eliminates packet loss and provides sub-millisecond recovery, at the cost of 2–3x higher link utilization.

Significance. The open-source release of the framework, the modular scenario-driven fault injection, and the explicit comparison of FRER versus non-redundant operation are strengths that could make IN2C a reusable testbed for TSN fault-tolerance studies. The qualitative trade-off direction—FRER removes loss and adds bandwidth overhead, with possible jitter under saturation—is plausible and follows from the described mechanisms. However, the quantitative results are not validated against hardware or hardware-aligned models, the loss-free claims depend on unstated buffer assumptions, and no statistical confidence is reported. With those caveats, the paper is a useful engineering contribution but its specific numerical conclusions should be treated with caution.

major comments (4)
  1. [Section V-D, Table V, Fig. 8] The 0.0% packet loss reported for S2A2 in Table V is not robust without specifying switch queue capacities. Section V-D and Fig. 8 show the Inspection_2 to centralSwitch_3 link at near-saturation (≈100%) utilization due to FRER duplication, yet 75,126 packets are delivered with zero loss. Zero loss under sustained saturation is only possible if egress queues can absorb arbitrarily large bursts; the paper never states the queue capacity or buffer limits for the TsnSwitch modules. INET's default packet queue often uses packetCapacity=-1 (unbounded), so the lossless result may be an artifact of the buffer model rather than a property of FRER. Please specify queue capacities and rerun the scenarios with finite, realistic buffer sizes, and report whether zero loss persists.
  2. [Section V-C, Table V, Abstract] The recovery-time claim is internally inconsistent and unsupported. Table V lists recovery as '< 1 ms' for both FRER scenarios, but the body text in Section V-C states that 'FRER enables zero recovery time via data-plane replication' and describes 'instantaneous failover.' The abstract promises 'submillisecond recovery,' but recovery time is never defined as a metric, and no recovery-time measurement is reported anywhere. Please define how recovery time is measured (e.g., time from fault injection to first successfully delivered packet on the redundant path), report actual measured values, and align the terminology across the abstract, Table V, and the body text.
  3. [Section V-B, V-C] All quantitative results appear to come from a single simulation run per scenario: there is no mention of multiple seeds, confidence intervals, or statistical testing. Statements such as 'jitter remains controlled (std 8.13µs)' for S1A2 and 'the tail becomes pronounced—latency reaches up to 879µs' for S2A2 are point estimates from one run and cannot support comparative conclusions. Given that OMNeT++ simulations are stochastic (clock drift, traffic timing, queueing), please run multiple replications with different random seeds, report means and confidence intervals, and perform at least a basic sensitivity analysis on key parameters such as traffic intervals or failure times.
  4. [Section V-A, reference [5]] The paper cites [5] as a hardware-aligned approach to improving TSN simulation accuracy in OMNeT++, but no comparison is made between IN2C's timing and loss behavior and either that model or physical TSN hardware. Since the contribution is a quantitative evaluation (e.g., median 29.81µs latency, jitter statistics, sub-millisecond recovery), the fidelity of the INET-based gPTP, shaping, and FRER implementations is load-bearing. Please provide validation evidence or explicitly temper the precision of the quantitative claims to what the simulation can support without such validation.
minor comments (5)
  1. [Section IV, Algorithm 1] Algorithm 1 says 'Configure clock with drift model,' but no oscillator drift parameters are specified anywhere in the paper; please either provide the drift configuration or remove this line.
  2. [Section V-D, Fig. 7 caption] The caption 'Links utilization for the Sensing_1 → Control_1' is ambiguous; the surrounding text describes utilization on SwitchA_1 → SwitchB_1, centralSwitch_1 → SwitchB_1, and the direct path. Please clarify which links are plotted in Fig. 7.
  3. [Table II, Section IV] The configuration uses an 'always-open gate schedule' for TAS, meaning time-aware scheduling is effectively disabled. This is intentional and stated in the text, but the abstract and contributions should make clear that the evaluation covers shaping, filtering, and FRER without TAS gate control, to avoid overclaiming the set of TSN mechanisms exercised.
  4. [Table III] For 'Camera Surveillance' the table lists a '330 µs' period alongside '30 FPS'; a 30 FPS stream has an inter-frame interval of about 33.3 ms, not 330 µs. Please check the units and correct if this is not a typo.
  5. [Reference [13]] The code repository is cited as a GitHub URL; for reproducibility, please consider archiving the exact version used in this study (e.g., via Zenodo) and citing the archived version with a persistent identifier.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the reported trade-offs are measured simulation outputs, not fitted parameters or results forced by self-citation.

full rationale

The paper's central claims—zero packet loss with FRER under the investigated single failures, increased link utilization, and the latency/jitter trade-offs—are all recorded outcomes of an OMNeT++/INET simulation model. They are not derived from an equation whose inputs already contain the result, and no parameter is fitted to a subset of the data and then renamed as a prediction. The two self-citations are non-load-bearing: [1] is only cited as the origin of the two-cell industrial topology, and [13] is the publicly released implementation used to run the experiments; neither is used as an authority to force the reported numbers or to rule out alternative explanations. The zero-loss behavior is indeed inherent to IEEE 802.1CB FRER in a single-fault scenario, but the paper presents it as an observed simulation outcome rather than as a novel analytical derivation, and the accompanying overhead and jitter observations are emergent from the configured topology and traffic. No uniqueness theorem is imported from the authors' prior work, and no ansatz is smuggled in via citation. Concerns about unbounded simulator buffers or the unmeasured definition of 'submillisecond recovery' are correctness and validation risks, not circularity.

Assumptions & free parameters 5 free parameters · 3 assumptions · 0 invented entities

The central claims depend on hand-chosen traffic intervals, link speeds, fault timings, and the fidelity of the INET TSN implementation. No new physical entities are introduced, and no parameters are fitted to data; the numbers are simulation inputs, not outputs of a regression.

free parameters (5)
  • Sensing stream interval = 7.5 ms
    Chosen by hand to represent cyclic sensor-to-PLC reporting; the sent/received packet counts and loss percentages scale directly with this interval.
  • Inspection stream interval = 66 microseconds
    Chosen to model high-rate camera-to-edge traffic; it determines the near-saturation utilization and consequent jitter in scenario S2.
  • Failure injection times = 2 s and 4 s, with 1 s and 2 s durations
    Manually chosen fault timings; the non-redundant loss rate and recovery time are trivially equal to these durations.
  • PCP-to-priority mapping = 6 for control, 5 for sensing/inspection, 2 for cameras
    Hand-assigned priority classes; affect queueing behavior and relative latency but are not tuned to match a target result.
  • Link speeds = 1 Gbps backbone, 100 Mbps edge
    Standard industrial link assumptions; utilization percentages depend directly on these capacities.
assumptions (3)
  • domain assumption INET's TSN modules correctly implement IEEE 802.1AS, 802.1Qbv, 802.1Qci, and 802.1CB
    Section IV states that nodes are built from INET's TsnDevice/TsnSwitch templates and that FRER, filtering, and shaping are enabled; the fidelity of the entire evaluation rests on the correctness of these open-source models.
  • domain assumption The simulated two-cell topology is representative of real industrial IIoT deployments
    Section III describes the network as 'a realistic smart factory,' but no industrial partner data or real topology validation is provided.
  • domain assumption Disjoint redundant paths exist and are correctly configured for FRER in scenarios S1A2 and S2A2
    Section V.A describes enabling FRER via StreamRedundancyConfigurator; if path diversity were absent or misconfigured, the zero-loss result would not hold.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Resilient Time-Sensitive Networking for Industrial IoT: Configuration and Fault-Tolerance Evaluation." pith.science (2026). https://pith.science/paper/AIB2K5TU

@misc{pith2026250711250,
  author       = {Pith},
  title        = {Pith review of: Resilient Time-Sensitive Networking for Industrial IoT: Configuration and Fault-Tolerance Evaluation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/AIB2K5TU}},
  note         = {Machine review of arXiv:2507.11250}
}
read the original abstract

Time-Sensitive Networking (TSN) is increasingly adopted in industrial systems to meet strict latency, jitter, and reliability requirements. However, evaluating TSN's fault tolerance under realistic failure conditions remains challenging. This paper presents IN2C, a modular OMNeT++/INET-based simulation framework that models two synchronized production cells connected to centralized infrastructure. IN2C integrates core TSN features, including time synchronization, traffic shaping, per-stream filtering, and Frame Replication and Elimination for Redundancy (FRER), alongside XML-driven fault injection for link and node failures. Four fault scenarios are evaluated to compare TSN performance with and without redundancy. Results show that FRER eliminates packet loss and achieves submillisecond recovery, though with 2-3x higher link utilization. These findings offer practical guidance for deploying TSN in bandwidth-constrained industrial environments.

Figures

Figures reproduced from arXiv: 2507.11250 by the authors.

Figure 1
Figure 1. Industrial TSN Network with Two Production Cells [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. TSN based Industrial Network of Two Production Cells (IN2C). [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 4
Figure 4. Active FRER to provide cell failure protection. [PITH_FULL_IMAGE:figures/full_fig_p005_4.png] view at source ↗
Figures from the paper (2 more)
Figure 5
Figure 5. Figure 5: End to End latency and Jitter, Sensing 1/Control 1 stream, comparison while handling link failure. later restore Ethernet gates between modules. No node-level failures are used; instead, link-level disruptions emulate practical fault cases such as cable damage or aggre…
Figure 7
Figure 7. Figure 7: Links utilization for the Sensing_1 → Control_1. For the Sensing_1 → Control_1 stream (S1), which transmits every 7.5 ms on average, the S1A1 configuration experiences 270 lost packets during the 2-second link fail￾ure—yielding a 20.2% loss rate. Recovery is purely rea…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

12 extracted references · 8 canonical work pages

  1. [5]

    H. -H. Liu et al., ”Improving TSN Simulation Accuracy in OMNeT++: A Hardware-Aligned Approach,” in IEEE Access, vol. 12, pp. 79937- 79956, 2024, doi: 10.1109/ACCESS.2024.3410109

    arXiv 2024

  2. [1]

    Seliem, A

    M. Seliem, A. Zahran and D. Pesch, ”Delay Analysis of TSN Based Industrial Networks With Preemptive Traffic Using Network Calculus,” 2023 IFIP Networking Conference (IFIP Networking), Barcelona, Spain, 2023, pp. 1-9, doi: 10.23919/IFIPNetworking57963.2023.10186400

    work page arXiv 2023

  3. [2]

    Farkas, L

    J. Farkas, L. L. Bello and C. Gunther, ”Time-Sensitive Networking Standards,” in IEEE Communications Standards Magazine, vol. 2, no. 2, pp. 20-21, JUNE 2018, doi: 10.1109/MCOMSTD.2018.8412457. keywords: Special issues and sections;Sensitivity analysis;Time mea- surement;Telecommunication traffic;Mission critical systems,

    work page arXiv 2018

  4. [3]

    Lo Bello and W

    L. Lo Bello and W. Steiner, ”A Perspective on IEEE Time-Sensitive Networking for Industrial Communication and Automation Systems,” in Proceedings of the IEEE, vol. 107, no. 6, pp. 1094-1120, June 2019, doi: 10.1109/JPROC.2019.2905334

    arXiv 2019

  5. [4]

    Libing Deng, Guoqi Xie, Hong Liu, Yunbo Han, Renfa Li, and Keqin Li. 2022. A Survey of Real-Time Ethernet Modeling and Design Methodologies: From A VB to TSN. ACM Comput. Surv. 55, 2, Article 31 (February 2023), 36 pages. https://doi.org/10.1145/3487330

    work page doi:10.1145/3487330 2022

  6. [6]

    Varga, J

    B. Varga, J. Farkas, F. Fejes, J. Ansari, I. Moldov ´an and M. M ´at´e, ”Robustness and Reliability Provided by Deterministic Packet Net- works (TSN and DetNet),” in IEEE Transactions on Network and Service Management, vol. 20, no. 3, pp. 2309-2318, Sept. 2023, doi: 10.1109/TNSM.2023.3284590

    work page arXiv 2023

  7. [7]

    Z. Zhou, J. Lee, M. S. Berger, S. Park and Y . Yan, ”Simulating TSN traffic scheduling and shaping for future automotive Ethernet,” in Journal of Communications and Networks, vol. 23, no. 1, pp. 53-62, Feb. 2021, doi: 10.23919/JCN.2021.000001

    work page arXiv 2021

  8. [8]

    and Heffernan, D

    Trifonov, H. and Heffernan, D. (2023), ”OPC UA TSN: a next- generation network for Industry 4.0 and IIoT”, International Journal of Pervasive Computing and Communications, V ol. 19 No. 3, pp. 386-411. https://doi.org/10.1108/IJPCC-07-2021-0160

    work page doi:10.1108/ijpcc-07-2021-0160 2023

Show all 12 references
  1. [9]

    G. Li, S. Wang, Y . Huang, T. Huang, Y . Cui and Z. Xiong, ”Optimizing Fault-Tolerant Time-Aware Flow Scheduling in TSN-5G Networks,” in IEEE Transactions on Mobile Computing, vol. 24, no. 4, pp. 3441-3455, April 2025, doi: 10.1109/TMC.2024.3510604

    2025

  2. [11]

    Jover, M

    M. Jover, M. Barranco, J. Naranjo, J. Proenza and A. Ballesteros, ”Characterizing the Tradeoff between Fault Tolerance and Cost of Redundant TSN Networks,” 2024 IEEE 29th International Conference on Emerging Technologies and Factory Automation (ETFA), Padova, Italy, 2024, pp. ...

    2024

  3. [12]

    G. Cena, S. Scanzio, D. Cavalcanti and V . Frascolla, ”Seamless Re- dundancy for High Reliability Wi-Fi,” 2023 IEEE 19th International Conference on Factory Communication Systems (WFCS), Pavia, Italy, 2023, pp. 1-4, doi: 10.1109/WFCS57264.2023.10144228

    2023

  4. [13]

    Seliem, ”IN2C: Industrial Network with TSN-enabled Cells,” GitHub, 2024

    M. Seliem, ”IN2C: Industrial Network with TSN-enabled Cells,” GitHub, 2024. [Online]. Available: https://github.com/MohamedSeliem/ IN2C. [Accessed: June. 19, 2025]

    2024

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.