![\"T-BC](\"/static/acca3378002c5cfdf373c54934d6216b/ptp-pts-t-bc.svg\")
Learn about the new Partial Timing Support (PTS) feature in StarlingX, enabling unicast PTP\nsynchronization over Layer 3 networks.
\nThe StarlingX community continues to expand the platform's precision timing capabilities. Following\nthe introduction of multi-instance PTP configurations,\nredundant timing sources,\nand O-RAN PTP notifications,\nthe StarlingX 12.0 release introduces Partial Timing Support (PTS) to enable unicast\nPTP time distribution over Layer 3 IP networks.
\nIn the earlier StarlingX PTP blog posts, we explored configurations based on the ITU-T G.8275.1\ntelecom profile. G.8275.1 uses Layer 2 multicast PTP, meaning that every node in the timing path\nmust directly participate in PTP and be connected at the Ethernet layer. This is referred to as\nFull Timing Support (FTS) because the entire network is timing-aware.
\nHowever, not all network deployments have this luxury. In many real-world scenarios, PTP nodes need\nto synchronize across Layer 3 boundaries via routers, across VLANs, or over wide area\nnetworks where intermediate nodes do not participate in timing. This is where Partial Timing Support\ncomes in.
\nPTS corresponds to the ITU-T G.8275.2 telecom profile. Instead of relying on L2 multicast,\nG.8275.2 uses unicast PTP messages transported over IPv4 or IPv6. A PTP node configured for PTS\nestablishes direct unicast sessions with specific grandmaster clocks, requesting timing information\nthrough unicast negotiation. This allows timing distribution across networks where not all\nintermediate nodes are PTP-aware.
\nPTS addresses several important deployment scenarios:
\nStarlingX supports two primary PTS deployment models: Telecom Boundary Clock (T-BC) and Telecom\nGrandmaster (T-GM).
\nIn this configuration, a StarlingX node acts as a boundary clock that receives time from a remote\ngrandmaster over unicast IPv6 (G.8275.2) and distributes it to local downstream nodes over L2\n(G.8275.1).
\n
The upstream NIC receives timing from the remote grandmaster via unicast and passes a 1PPS signal\nto the downstream NIC, which then distributes time to local nodes using the traditional L2\nmulticast profile. This hybrid approach is particularly useful for edge sites that need to\nsynchronize with a central timing source but distribute time locally using G.8275.1.
\nIn this configuration, a StarlingX node with a local GNSS receiver acts as a grandmaster, serving\ntime to remote clients over unicast IPv6.
\n![\"T-GM](\"/static/41915243a60b2f32a31a0fc62fbd2556/ptp-pts-t-gm.svg\")
In this topology, the node derives its timing from a connected GNSS antenna and advertises time\nover unicast to remote clients. The remote clients configure their own unicast master tables\npointing to this node's address. This enables a centralized grandmaster to serve accurate time to\ngeographically distributed nodes without requiring PTP support on the intermediate network\ninfrastructure.
\nThe central concept in PTS configuration is the unicast master table. A unicast master table\ndefines the set of upstream grandmaster addresses that a PTP client node will contact to request\ntime. Each table specifies:
\nMultiple grandmaster entries within a single table provide redundancy — if one grandmaster becomes\nunreachable, the node can acquire time from another.
\nPTS deployments use a distinct set of PTP profile parameters compared to G.8275.1. The most\nnotable differences include:
\ninhibit_announce to suppress multicast announce\nmessages, and master ports use unicast_listen to accept incoming unicast requestsOne of the strengths of StarlingX's PTS implementation is the ability to configure mixed transport\nmodes within a single ptp4l instance. An upstream interface can operate over unicast IPv6 while a\ndownstream interface operates over L2 within the same instance. This simplifies the\ndeployment of boundary clocks that bridge PTS and FTS network segments.
\nPTS builds on the multi-instance PTP framework that has been available since StarlingX 7.0.\nIt integrates with:
\nIf you're interested in deploying PTS in your StarlingX environment, the\nofficial documentation\nprovides step-by-step configuration procedures for both T-BC and T-GM deployments, including\ncomplete CLI examples and generated configuration file references.
\nPrerequisites for a PTS deployment include:
\nPartial Timing Support is a significant addition to StarlingX's timing portfolio. By enabling\nunicast PTP over IP networks, it opens up deployment scenarios that were previously only achievable\nwith dedicated timing appliances or fully PTP-aware network infrastructure. Whether you're\nconnecting remote edge sites to a central timing source or distributing time across a routed\nnetwork, PTS provides the flexibility to deploy precise timing where it's needed.
\nThe StarlingX community continues to advance the platform's timing capabilities. Stay tuned for\nfuture enhancements to PTP support, including improvements to servo tuning for PTS networks and\nexpanded monitoring capabilities.
\nIf you would like to learn more about the project and get involved check the\nwebsite for more information or\ndownload the code and start to experiment with the platform.
","frontmatter":{"date":"2026/09/29","title":"Partial Timing Support - Unicast PTP in StarlingX","author":"Cole Walker"}}},"pageContext":{"id":"22d0254d-3bf6-50e2-8dc1-88bed4032a9b"}},"staticQueryHashes":[]}