{"id":"6d83d4ea-7924-4528-a98d-a21699679064","arxiv_id":"2507.11250","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":5,"one_line_summary":"In a simulated industrial TSN, redundant frame delivery achieves zero packet loss during failures at the cost of 2-3x link utilization and higher jitter for high-rate inspection traffic.","lead":"This paper presents IN2C, a simulation framework for testing how Time-Sensitive Networking in a two-cell factory handles link and node failures. In the simulated network, frame replication and elimination eliminates packet loss and recovers in under a millisecond, but it consumes two to three times more bandwidth on core links.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Zero-loss S2A2 result relies on unspecified switch queue capacity; near-saturated links with 0% loss suggest unbounded buffers, making 'FRER eliminates packet loss' a simulator artifact.","rationale":"The reader's weakest assumption targets external validity (no hardware calibration or comparison to hardware-aligned models). I agree that is a serious limitation. My concern is more internal: the paper's own reported saturation makes the zero-loss result suspicious without any statement of queue/buffer capacity. This is directly load-bearing for the 'FRER eliminates packet loss' claim because, if the INET queues are effectively unbounded, the 0% loss in S2A2 is an artifact of the simulator configuration, not evidence about FRER under realistic finite-memory switches. The public repository makes the proposed check cheap and decisive. The qualitative FRER cost/jitter trade-off would likely remain even if finite-buffer loss appears, so a conditional verdict is still appropriate; the paper should add finite-buffer experiments and report queue parameters before the lossless claim can be accepted generally. I therefore keep the reader's CONDITIONAL verdict unchanged, while adding this internal validity condition to the existing external validity condition.","tokens_in":9052,"tokens_out":7786,"duration_ms":99264,"concrete_test":"Inspect IN2C's .ini/.ned configuration for the packetCapacity parameter of TsnSwitch egress queues. Then rerun S2A2 with identical traffic and fault timing but with finite capacities, e.g., 100 and 1,000 packets per queue. If either run shows lost packets (received < sent) or unbounded latency growth, the zero-loss claim is an artifact of unbounded buffering and must be scoped to the specific buffer configuration. Also rerun S1A2 as a control to confirm the low-rate lossless result is buffer-independent.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim that FRER eliminates packet loss is not robust against a plausible simulator artifact. In the S2A2 scenario, Section V-D/Fig. 8 reports the Inspection_2→centralSwitch_3 link running near saturation (≈100%) due to FRER duplication, yet Table V records 0.0% loss over 75,126 packets. Zero loss under sustained saturation is only possible if the switch egress queues can absorb arbitrarily large bursts; the paper never specifies queue capacity or buffer limits for the TsnSwitch modules. INET's default packet queue often uses packetCapacity=-1 (unbounded), so with the published configuration, the 0.0% loss is guaranteed by the buffer model, not by FRER itself. Real TSN switches have finite shared memory and will drop or discard frames once queues overflow, so the headline 'FRER eliminates packet loss' may not survive finite-buffer conditions. The paper's own jitter tail (up to 879μs) signals queue buildup, making the lossless result depend exactly on the unspecified buffer depth. The secondary claim of 'submillisecond recovery' is also unsupported: recovery time is never defined as a metric, and the body text instead says FRER provides 'zero recovery time,' so the abstract's number is not measured.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":9280,"tokens_out":3875,"duration_ms":47985,"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":[{"comment":"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.","section":"Section V-D, Table V, Fig. 8"},{"comment":"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.","section":"Section V-C, Table V, Abstract"},{"comment":"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.","section":"Section V-B, V-C"},{"comment":"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.","section":"Section V-A, reference [5]"}],"minor_comments":[{"comment":"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.","section":"Section IV, Algorithm 1"},{"comment":"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.","section":"Section V-D, Fig. 7 caption"},{"comment":"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.","section":"Table II, Section IV"},{"comment":"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.","section":"Table III"},{"comment":"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.","section":"Reference [13]"}],"recommendation":"major_revision","confidential_remarks":"The paper is a solid simulation-study contribution that could be acceptable after revision. The main risk is that the headline 'FRER eliminates packet loss' is an artifact of unbounded buffers; specifying queue capacities and re-running is essential. The recovery-time definition and statistical rigor are also fixable within the manuscript's scope. I would not reject, but I would not accept in current form."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"You should know two things before reading. First, this is a competently built and honestly reported simulation study, not a breakthrough. Second, the headline claim that FRER eliminates packet loss is plausible but not yet solid, because the paper never specifies switch buffer limits and runs no multi-seed statistics. I'd send it to review, but I'd expect revision.\n\nWhat's genuinely useful here is the artifact. The IN2C framework is public, the configuration details are specific enough to reproduce, and the XML fault-injection workflow is a nice practical contribution for people doing OMNeT++ TSN work. The packet counts in Table V are internally consistent, and the qualitative direction of every effect — FRER prevents loss during faults, doubles or triples link utilization, and can turn a high-rate stream into a jittery one — follows from the configured mechanisms. The authors also explicitly say their overhead and jitter observations are consistent with Jover et al. and Cena et al., which is the right way to position an extension of known results.\n\nThe soft spots are real but proportionate. The simulation appears to be a single run per scenario. No seeds, no confidence intervals, no sensitivity analysis. That means the specific medians and loss percentages are not robust evidence; only the qualitative behavior is. Second, there is no validation against real TSN hardware or against the hardware-aligned INET models they cite as [5]. The chosen simulator defaults could easily shift the numbers. Third — and this is the concern I'd push hardest on — the paper never says what queue capacity the TsnSwitch modules use. In one scenario the Inspection_2→centralSwitch_3 link is near 100% utilization with FRER, yet the loss rate is 0.0%. If INET's default queue is unbounded, then that zero-loss result is guaranteed by the buffer model, not by FRER. The paper needs to either configure finite buffers or explain why they don't matter. This is a load-bearing issue for the 'eliminates packet loss' headline. Fourth, the abstract claims 'submillisecond recovery,' but recovery time is never defined as a metric. The body text says 'zero recovery time,' which is a different and cleaner claim; the abstract should match the body.\n\nWho is this for? Anyone building or extending OMNeT++ TSN simulations, especially for fault-tolerance evaluation. The paper gives a solid starting point and clear configuration guidance. It is not a paper that changes your mental model of FRER. With finite-buffer experiments, multi-seed runs, and a defined recovery metric, I'd be comfortable with it in a simulation or industrial-networking venue. As is, I'd still send it to a serious referee, but the referee should ask for those fixes.","headline":"A reproducible TSN simulation testbed with honest, but unsurprising, FRER findings; needs buffer/seed/recovery-metric fixes before the lossless headline is trustworthy.","tokens_in":9832,"tokens_out":2003,"would_cite":true,"duration_ms":27257,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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.","keywords":["Time-Sensitive Networking","Frame Replication and Elimination for Redundancy (FRER)","Industrial IoT","fault tolerance","network resilience","link failure","simulation evaluation","deterministic networking"],"falsifier":"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.","tokens_in":8831,"feed_emoji":"🏭","tokens_out":6575,"duration_ms":72969,"temperature":0.7,"pith_summary":"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.","feed_headline":"Simulated TSN redundancy: zero packet loss, sub-ms recovery","feed_subtitle":"Factory-network simulation shows 2-3x bandwidth cost for redundancy, so apply it selectively.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Supplies the two-production-cell industrial network model whose delay characteristics IN2C builds on.","marker":"[1]"},{"why":"Defines the TSN standard suite (gPTP, shaping, FRER) that the simulated mechanisms implement.","marker":"[2]"},{"why":"Provides the hardware-aligned TSN simulation accuracy baseline that would be needed to validate IN2C's quantitative results.","marker":"[5]"},{"why":"Establishes the robustness and reliability provided by TSN/DetNet redundancy, the conceptual basis for expecting FRER to protect streams.","marker":"[6]"},{"why":"Documents the fault-tolerance versus cost trade-off in redundant TSN that this paper's overhead results corroborate.","marker":"[11]"},{"why":"Is the public IN2C simulation framework and scenario configuration from which all reported numbers are produced.","marker":"[13]"}],"fun_headline_variants":["TSN redundancy: zero packet loss, sub-ms recovery, 2-3x bandwidth","FRER in TSN: no loss, sub-ms failover, but bandwidth doubles","Simulated industrial TSN: FRER vs rerouting, latency and cost","TSN fault-tolerance study: FRER kills loss, adds 2-3x link usage","FRER for TSN: lose no packets, recover in <1ms, pay in bandwidth"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["TSN redundancy: zero packet loss, sub-ms recovery, 2-3x bandwidth","FRER in TSN: no loss, sub-ms failover, but bandwidth doubles","Simulated industrial TSN: FRER vs rerouting, latency and cost","TSN fault-tolerance study: FRER kills loss, adds 2-3x link usage","FRER for TSN: lose no packets, recover in <1ms, pay in bandwidth"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000322,"raw_usage":{"total_tokens":1786,"prompt_tokens":898,"completion_tokens":888,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":514,"completion_tokens_details":{"reasoning_tokens":771}},"tokens_in":514,"tokens_out":888,"duration_ms":8838,"temperature":1.0,"reasoning_tokens":771,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T17:12:36.205951+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"Seliem, A","cited_arxiv_id":null,"evidence_quote":"Supplies the two-production-cell industrial network model whose delay characteristics IN2C builds on."},{"cited_title":"Farkas, L","cited_arxiv_id":null,"evidence_quote":"Defines the TSN standard suite (gPTP, shaping, FRER) that the simulated mechanisms implement."},{"cited_title":"Varga, J","cited_arxiv_id":null,"evidence_quote":"Establishes the robustness and reliability provided by TSN/DetNet redundancy, the conceptual basis for expecting FRER to protect streams."},{"cited_title":"Seliem, ”IN2C: Industrial Network with TSN-enabled Cells,” GitHub, 2024","cited_arxiv_id":null,"evidence_quote":"Is the public IN2C simulation framework and scenario configuration from which all reported numbers are produced."}],"review_version":1}