Next-Generation Onboard Network Design: How TSN and HSR Deliver Zero-Loss, Deterministic Train Networks

Key takeaways

• HSR (High-availability Seamless Redundancy) sends two identical frame copies around a ring in opposite directions at the same time, so when one path fails the other has already arrived — there is no switchover event and no packet loss to begin with.
• This is a fundamentally different redundancy model from Ring protocols like O-Ring, which detect a break first and then switch — a process that can misfire under the vibration rolling stock experiences in normal operation.
• TSN (Time-Sensitive Networking) adds deterministic, low-jitter delivery on top of that redundant backbone, through time synchronization (802.1AS), scheduled gating (802.1Qbv), stream filtering and policing (802.1Qci), frame preemption (802.3br/802.1Qbu), and frame replication and elimination (802.1CB / FRER).
• A 10 Gigabit Ethernet backbone gives next-generation onboard networks the headroom to carry converged CCTV, passenger information, TCMS control traffic, and diagnostic data on one physical infrastructure without one flow starving another.
• TSN capabilities can be rolled out incrementally — starting with confirming PTP time lock, then adding stream identification, PSFP, TAS, frame preemption, and FRER as each project needs them, rather than configuring everything at once.
• Every TSN function exposes live status counters (Oper Gate state, PSFP flow-meter counts, FRER passed/discarded/lost counters) so the redundancy and determinism can be verified on-screen, not just claimed on a spec sheet.

Why does next-generation rolling stock need a new onboard network architecture?

Onboard networks are carrying more traffic than they used to. Higher-resolution CCTV, richer passenger information displays, train control and management system (TCMS) data, and remote diagnostics increasingly share the same physical backbone. That combination raises two separate requirements at once: the network has to move more data without any one flow crowding out another, and it has to keep critical control and safety traffic flowing with no interruption — including through the vibration, coupling, and re-marshalling that are a normal part of rail operations. Meeting both requirements calls for redundancy and traffic determinism that are designed in at the protocol level, rather than added on top of a best-effort network.

What is HSR, and how is it different from Ring-based redundancy?

HSR — High-availability Seamless Redundancy, defined in IEC 62439-3 — takes a different approach to redundancy than ring protocols such as O-Ring. Every HSR node sends two identical copies of each frame at the same time, one clockwise and one counter-clockwise around the ring. The destination node keeps whichever copy arrives first and silently discards the duplicate; the source node recognizes and discards its own frame once it has circled all the way back, which is what keeps the ring from flooding itself. Because both copies are already travelling before any fault occurs, there is nothing to detect and nothing to switch when a link does fail — the surviving copy was already on its way.

                                 Figure 1. HSR sends two copies simultaneously in opposite directions. When one path breaks, the other has already arrived — no switchover event, no packet loss.

[Alt text for CMS image field — not part of body copy] Diagram of HSR ring redundancy showing a source node sending two identical frame copies clockwise and counter-clockwise, with the destination node keeping the first arrival and discarding the duplicate, and a fault scenario where the surviving copy still arrives with zero packet loss.

This is the key distinction from a protocol like O-Ring, which is described in ORing's onboard network design guide referenced under Related Resources below: O-Ring relies on a millisecond-level health-check packet to detect that a link has broken, and only then switches its backup port to forwarding. That detect-then-switch sequence is exactly what makes O-Ring sensitive to the brief packet loss vehicle vibration can cause — the protocol has to decide whether a break has actually occurred. HSR removes that decision point entirely, because both paths are already carrying traffic before any fault happens.

Why does a next-generation onboard backbone need 10 Gigabit Ethernet?

As CCTV resolution rises, passenger information systems add richer media, and TCMS, PIS, and diagnostic data increasingly converge onto a single onboard network, 1 Gigabit links become a bottleneck for the busiest backbone segments — particularly the trunk links between vehicle-level switches carrying traffic aggregated from an entire consist. A 10G backbone gives that aggregated traffic enough headroom that ordinary video and data flows don't compete with each other for bandwidth, and it gives TSN's traffic-shaping functions, such as TAS and Frame Preemption, more room to schedule around, rather than working against an already-saturated 1G link.

What is TSN, and what does it add on top of a redundant backbone?

TSN — Time-Sensitive Networking — is a family of IEEE 802.1 standards that make standard Ethernet deterministic: capable of guaranteeing when a critical frame will arrive, not just that it will arrive eventually. On next-generation onboard switches, TSN brings several capabilities together, each backed by a specific standard:

Together, TAS and Frame Preemption give deterministic, low-jitter delivery for time-critical control traffic; PSFP contains a misbehaving or overloaded source before it can affect anything else on the network; FRER adds zero-interruption redundancy for the most critical streams; and 802.1AS keeps every device's clock aligned closely enough for all of the above to function as designed.

How should you roll out TSN capabilities on a next-generation switch?

TSN does not need to be switched on all at once. On ORing's upcoming next-generation TSN railway switch series, every function is configured from a single Web GUI "TSN" menu, and a project can add capabilities one at a time as its requirements call for them:

                                   Figure 2. Recommended TSN rollout order — add one capability at a time as the project requires.

[Alt text for CMS image field — not part of body copy] Diagram of the recommended six-step TSN rollout order: confirm PTP lock, define stream identification, configure PSFP, configure TAS, enable frame preemption, and add FRER for critical applications.

• Step 1 — Confirm PTP (802.1AS) time synchronization is Locked. The built-in PTP Check safeguard automatically holds later schedule changes until this is true.
• Step 2 — Define Stream Identification rules (by VLAN, MAC address, or protocol) so the switch knows which flows TSN should manage.
• Step 3 — Configure PSFP to isolate and police any source that needs to be filtered or rate-limited.
• Step 4 — Configure the TAS Gate Control List to open a scheduled transmission window for time-critical traffic.
• Step 5 — Enable Frame Preemption where latency needs to be pushed even lower.
• Step 6 — Add FRER for applications that cannot tolerate any interruption at all.

How can you verify that TSN and HSR redundancy are actually working?

Rather than relying on a spec sheet claim, each of these functions exposes a live status page under the switch's Monitor / TSN menu, with real counters: the TAS status page shows the Oper Gate state and the currently active Cycle Time and Base Time, plus a Config Change Error counter that records any failed schedule update; the PSFP Flow Meter and Stream Filter pages show live pass/police/discard counts per stream, which can be demonstrated by deliberately overloading one stream and watching it get isolated without affecting the rest of the traffic; the FRER Recovery status reports passed, discarded, out-of-order, and lost frame counts together with Latent Error Detection, so pulling a cable live and watching the lost-frame counter stay at zero is a direct, on-screen demonstration of zero-loss redundancy; and the Frame Preemption status page's Verify Status field (succeeded / failed / indeterminate) confirms both ends of a link actually negotiated preemption support, rather than assuming it from the spec sheet alone.

Where does this architecture apply beyond rolling stock?

The same combination of deterministic TSN traffic handling and zero-loss HSR redundancy applies wherever a network carries both control-critical and best-effort traffic on shared infrastructure: factory automation and multi-axis motion control, smart manufacturing environments converging OT control networks with IT monitoring and MES data, and power substation automation, where FRER's zero-interruption redundancy is particularly well suited to protection and monitoring systems. Onboard rail and rolling stock networks remain one of the environments where both halves of this architecture — deterministic TSN scheduling and zero-loss HSR redundancy — matter at the same time, because vibration, high traffic convergence, and safety-relevant control data are all present together.

Which ORing products support this architecture?

ORing has announced a next-generation TSN railway switch series combining TSN and HSR Ring redundancy with 10 Gigabit Ethernet uplinks, PoE++ (IEEE 802.3bt) for powering onboard devices, and IEC 62443-4-2 SL2-aligned security in line with the EU Cyber Resilience Act. This series is being shown at InnoTrans 2026 (Berlin, September 22–25, Hall 4.1, Booth 255), with general availability targeted for mid-2027. As this series has not yet been released, specific model numbers and final specifications are not included in this article and remain subject to R&D confirmation — contact ORing's engineering team for the current roadmap and to discuss a configuration for your project.

Frequently asked questions

Is HSR the same thing as Ring redundancy such as O-Ring?

No. Ring protocols like O-Ring detect a break first (typically via a millisecond-level health-check packet) and then switch a backup port to forwarding — a detect-then-switch sequence that takes a brief but real amount of time and can be triggered by transient conditions like vibration. HSR sends two copies of every frame in both directions simultaneously, so the surviving copy has already arrived by the time a fault occurs. There is no detection step and no switchover event to trigger.

Does HSR redundancy cause any packet loss when a link fails?

No — that is the defining property of HSR. Because both frame copies are already in flight before any fault occurs, a single link failure does not interrupt delivery at all; the destination simply receives the surviving copy as usual. This is different from redundancy mechanisms that recover quickly after a fault but still involve a brief interruption while they do.

Do you need to enable every TSN feature to see a benefit?

No. TSN functions can be enabled incrementally — see "How should you roll out TSN capabilities on a next-generation switch?" above. A project can start with PTP time synchronization and Stream Identification, and add PSFP, TAS, Frame Preemption, or FRER only for the traffic types that need them.

Can TSN and HSR be used together on the same network?

Yes. HSR provides zero-loss path redundancy at the ring level, while TSN's TAS, PSFP, and Frame Preemption functions manage how traffic is scheduled and prioritized on top of that redundant backbone. FRER, part of the same 802.1CB standard family as HSR, can additionally be applied to specific critical streams that need path-level redundancy outside the HSR ring itself.

What bandwidth does a 10G onboard backbone actually support?

A 10 Gigabit Ethernet backbone link provides roughly ten times the throughput of a 1 Gigabit link on the same trunk segment, which is the headroom next-generation onboard networks need as CCTV resolution, passenger information content, and converged TCMS/diagnostic data volumes continue to grow on a shared backbone. See "Why does a next-generation onboard backbone need 10 Gigabit Ethernet?" above.

Related resources

• Train Onboard Network Design Guide: Why Ring Redundancy Fails on Rolling Stock (and What Works Instead)
• What is HSR/PRP?
• What is Time-Sensitive Networking (TSN)?
• 9000 Series Switches: S12 Security-Enhanced Firmware Installation Guide