generic Precision Time Protocol (gPTP)
Overview
This gPTP stack supports the protocol and procedures as defined in the IEEE 802.1AS-2011 standard (Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks).
Supported features
The stack handles communications and state machines defined in the IEEE 802.1AS-2011 standard. Mandatory requirements for a full-duplex point-to-point link endpoint, as defined in Annex A of the standard, are supported.
The stack is in principle capable of handling communications on multiple network interfaces (also defined as “ports” in the standard) and thus act as a 802.1AS bridge. However, this mode of operation has not been validated on the Zephyr OS.
The stack can also operate as a statically configured time receiver on networks that follow the IEEE 802.1AS automotive profile, where no Announce messages are exchanged. See Static timeReceiver operation below.
Supported hardware
Although the stack itself is hardware independent, Ethernet frame timestamping support must be enabled in ethernet drivers.
Boards supported:
Native simulator - native_sim (only usable for simple testing, limited capabilities due to lack of hardware clock)
QEMU Emulation for X86 (emulated, limited capabilities due to lack of hardware clock)
Enabling the stack
The following configuration option must me enabled in prj.conf file.
Static timeReceiver operation
Networks built after the IEEE 802.1AS automotive profile (AVnu “Automotive Ethernet AVB Functional and Interoperability Specification”) use static port roles instead of the Best Master Clock Algorithm. A bridge on such a network transmits Sync and Follow_Up messages but no Announce messages, and is not required to answer Pdelay requests on its timeTransmitter ports. The default stack cannot synchronize to such a bridge: without a received Announce a port never reaches the time receiver (“slave”) role.
Enabling CONFIG_NET_GPTP_STATIC_TIME_RECEIVER configures the
node as a statically configured time receiver: BMCA and all Announce handling
are bypassed, every port is pinned to the time receiver role, asCapable is forced so
synchronization does not depend on the Pdelay measurement, and the local clock
is disciplined from the received Sync and Follow_Up messages alone. The node
never becomes grandmaster and never transmits Sync or Announce messages, even
if CONFIG_NET_GPTP_GM_CAPABLE is set. This mirrors the
linuxptp ptp4l automotive time receiver configuration (BMCA “noop”, clientOnly,
inhibit_announce, asCapable “true”, ignore_source_id). The standards analog of
disabling the BMCA this way is the external port configuration of IEEE
802.1AS-2020 (clause 10.3.14, derived from IEEE 1588-2019 clause 17.6.2).
Application interfaces
The following Application Interfaces as defined in section 9 of the standard are available:
ClockSourceTimeinterface (gptp_clk_src_time_invoke())ClockTargetPhaseDiscontinuityinterface (gptp_register_phase_dis_cb())ClockTargetEventCaptureinterface (gptp_event_capture())
Testing
The stack has been informally tested using the OpenAVnu gPTP and Linux ptp4l daemons. The gPTP sample application from the Zephyr source distribution can be used for testing.