PTP over HSR

PTP

Precision Time Protocol (IEEE 1588)

HSR

High-availability Seamless Redundancy

BMCA

Best Master Clock Algorithm

TC

Transparent Clock

OC

Ordinary Clock

BC

Boundary Clock

P2P

Peer-to-peer delay mechanism

LREA/B

Link Redundancy Entity A / B

DUT

Device Under Test

SLAVE

Active PTP slave port state

PASSIVE_SLAVE

Passive redundant PTP slave port state

This document describes support for running Precision Time Protocol (PTP) over High-availability Seamless Redundancy (HSR) networks.

The implementation enables reliable and deterministic IEEE 1588 operation in HSR topologies, ensuring correct clock selection, synchronization, and transparent clock behavior in the presence of redundant network paths.

PTP over HSR is compliant with IEEE 1588 and aligned with redundancy concepts defined in IEC 62439-3.

1. Overview

HSR networks provide zero-loss redundancy by transmitting frames over two independent paths. When running PTP over HSR, special care is required to avoid incorrect clock selection, duplicate processing of messages, or unstable synchronization behavior.

PTP over HSR addresses these challenges by making PTP operation aware of HSR redundancy, while preserving interoperability with non-redundant PTP devices.

2. Key properties

PTP over HSR provides the following properties:

  • Deterministic synchronization behavior over redundant paths

  • Robust clock selection in the presence of duplicated PTP information

  • Independent handling of the two HSR legs (LREA and LREB)

  • Fast and stable behavior during link failures or recovery

  • Compatibility with standard IEEE 1588 profiles and message formats

3. Clock selection (BMCA)

In HSR networks, equivalent PTP information may be received over multiple redundant paths. PTP over HSR ensures that this does not lead to ambiguous or unstable clock selection.

Clock selection follows the standard IEEE 1588 BMCA rules, extended with redundancy-aware behavior. When two redundant paths present equivalent clock datasets, the system deterministically selects the path that provides the best synchronization quality.

Path quality is evaluated using runtime reception characteristics, allowing the system to prefer the path with the most stable and reliable lock while continuously monitoring the alternative path.

This approach avoids oscillation between redundant paths and ensures consistent BMCA decisions.

4. Synchronization behavior

At any given time, only one HSR leg is used for active synchronization.

A leg with fewer missed SYNC messages is considered to provide higher synchronization quality, while a leg with an increasing number of missed SYNC messages is considered degraded. This information is used as an additional criterion during clock selection to deterministically prefer the most reliable path and to trigger fast, stable failover when the active leg becomes unreliable.

The selected leg operates as the active PTP slave and is responsible for disciplining the local clock.

The non-selected leg enters a dedicated PASSIVE_SLAVE state.

The PASSIVE_SLAVE state has the following properties:

  • Does not discipline the clock

  • Does not generate synchronization state

  • Does not influence the current synchronization lock

  • Continues to participate in clock selection decisions

  • Remains immediately available for failover

This separation ensures stable synchronization while maintaining full redundancy awareness.

5. Transparent clock support

PTP over HSR supports transparent clock (TC) operation in HSR networks.

PTP messages are forwarded between HSR legs in a redundancy-aware manner, preserving correct timing behavior across the network.

6. Supported features

The following table summarizes supported PTP features when running over HSR:

Role

Clock type

Delay mechanism

Supported

Ordinary Clock

1-step

Peer-to-peer

Yes

Ordinary Clock

2-step

Peer-to-peer

Yes

Transparent Clock

2-step

Peer-to-peer

Yes

Boundary Clock

No

7. Configuration

PTP over HSR is enabled by running ptp4l on the HSR interface and enabling redundancy support in the configuration file.

Example command:

$ ptp4l -f /tmp/ptp.cfg -i hsr0 -m -l7

7.1. Ordinary Clock (OC)

Example configuration for running ptp4l as an Ordinary Clock over HSR:

[hsr0]
redundancy                   1
delay_mechanism              P2P
network_transport            L2

[eth0]
redundancy                   1
redundancy_master_interface  hsr0
redundancy_slave_number      1

delay_mechanism              P2P
network_transport            L2
fault_reset_interval         0

[eth1]
redundancy                   1
redundancy_master_interface  hsr0
redundancy_slave_number      2

delay_mechanism              P2P
network_transport            L2
fault_reset_interval         0

7.2. Transparent Clock (TC)

Example configuration for running ptp4l as a Transparent Clock over HSR:

[global]
clock_type                   P2P_TC
delay_mechanism              P2P

[hsr0]
redundancy                   1
delay_mechanism              P2P
network_transport            L2

[eth0]
redundancy                   1
redundancy_master_interface  hsr0
redundancy_slave_number      1

delay_mechanism              P2P
network_transport            L2
fault_reset_interval         0

[eth1]
redundancy                   1
redundancy_master_interface  hsr0
redundancy_slave_number      2

delay_mechanism              P2P
network_transport            L2
fault_reset_interval         0

8. Testing

This section describes recommended test setups for validating PTP over HSR operation and verifying correct synchronization and redundancy behavior.

8.1. Ordinary Clock (OC) testing

When testing PTP over HSR in Ordinary Clock mode, a two-device setup is used.

Two devices under test (DUTs) are connected in an HSR ring. Each DUT operates as an HSR node with two ring ports, forming a closed loop.

ASCII topology:

          (ring link)
   +-----------------------+
   |                       |
   |  LREA           LREA  |
+--+--+                 +--+--+
| DUT |                 | DUT |
|  A  |                 |  B  |
+--+--+                 +--+--+
   |  LREB           LREB  |
   |                       |
   +-----------------------+
          (ring link)

Configuration:

  • Both DUTs are configured using the Ordinary Clock (OC) configuration example shown in the Configuration section

  • The same configuration is applied to both DUTs

Verification:

  • Verify synchronization by observing ptp4l output and confirming that offsetFromMaster converges toward zero and remains stable

  • Observe the PTP port states on each DUT:

    • One HSR leg should be in SLAVE state

    • The other HSR leg should be in PASSIVE_SLAVE state

  • Unplug the cable corresponding to the SLAVE port and verify that:

    • The PASSIVE_SLAVE port transitions to SLAVE

    • Synchronization remains stable

    • offsetFromMaster does not show large transients

Example ptp4l output:

ptp4l[122.522]: eth0 assuming the PASSIVE_SLAVE role
ptp4l[122.536]: eth1 assuming the SLAVE role
ptp4l[124.001]: master offset        -12 s2 freq   -3 path delay     198
ptp4l[125.001]: master offset         -8 s2 freq   -1 path delay     197
ptp4l[126.001]: master offset         -5 s2 freq    0 path delay     197

In this output, the master offset field corresponds to offsetFromMaster.

This validates redundancy-aware synchronization and deterministic failover behavior.

8.2. Transparent Clock (TC) testing

When testing PTP over HSR in Transparent Clock mode, a three-device setup is used.

Two endpoint devices (DUT A and DUT C) are connected through an intermediate device (DUT B), which operates as an HSR Transparent Clock.

ASCII topology:

                 (direct link)
   +--------------------------------------+
   |                                      |
   |   LREA                        LREA   |
+--+--+                                +--+--+
| DUT |                                | DUT |
|  A  |                                |  C  |
+--+--+                                +--+--+
   |   LREB      (link via TC)     LREB   |
   |              +--------+              |
   +--------------+ DUT B  +--------------+
            LREA  |  (TC)  |  LREB
                  +--------+

Configuration:

  • DUT A and DUT C are configured as Ordinary Clocks using the OC configuration example shown in the Configuration section

  • DUT B is configured as a Transparent Clock using the TC configuration example shown in the Configuration section

Verification:

  • Verify synchronization by observing ptp4l output on DUT A and DUT C and confirming that offsetFromMaster converges toward zero and remains stable

  • Observe the PTP port states on DUT A and DUT C:

    • One HSR leg should be in SLAVE state

    • The other HSR leg should be in PASSIVE_SLAVE state

  • If the SLAVE port already corresponds to the path flowing through the Transparent Clock, no further action is required

  • Otherwise, unplug the cable corresponding to the SLAVE port between the end DUTs to enforce that PTP traffic flows through DUT B (TC)

  • After enforcing TC forwarding, verify that:

    • The PASSIVE_SLAVE port transitions to SLAVE

    • Sync remains stable while flowing through the Transparent Clock

    • offsetFromMaster remains stable without large transients

Example ptp4l output:

ptp4l[122.522]: eth0 assuming the PASSIVE_SLAVE role
ptp4l[122.536]: eth1 assuming the SLAVE role
ptp4l[124.001]: master offset        -12 s2 freq   -3 path delay     198
ptp4l[125.001]: master offset         -8 s2 freq   -1 path delay     197
ptp4l[126.001]: master offset         -5 s2 freq    0 path delay     197

In this output, the master offset field corresponds to offsetFromMaster.

This validates correct synchronization behavior when PTP traffic is routed through an HSR Transparent Clock.