Time synchronization is a fundamental requirement for TSN-based networks. On the one hand, synchronized time is required for many TSN mechanisms such as the schedule-based sending of data according to 802.1Qbv. On the other hand, time is also required for the distributed applications implemented using TSN. In the simplest case, this can be the generation of a time stamp for measurement data or the high-precision synchronization of a physical application, for example that of several machine axes.

As different as the applications are, as different are their requirements for the accuracy of the synchronization: For a sensor for process monitoring, it may well be sufficient to ensure that it transmits in the first millisecond of a 10 ms cycle.
For highly dynamic axes of a precision machine, synchronization in the lower nanosecond range is required.

In TSN networks, the Precision Time Protocol (PTP) is used for this purpose, which is defined in IEEE 1588 and the IEEE 802.1AS standard based on it. PTP enables synchronization of all nodes in the network
with an accuracy of less than 1 μs.
Typically, however, the synchronization accuracy is significantly better, usually even below 50 ns.

PTP Basics

Figure 1: The synchronization hierarchy of a TSN network.

© NetTimeLogic

PTP builds a synchronization tree by exchanging 'announce' frames - the information about qualities and priorities of the respective node - and the best-master clock algorithm.
Ultimately, this results in a synchronization hierarchy (Figure 1) in which the time source - called the PTP grandmaster (GM) - is at the top and the time sinks - called PTP slaves (OC) - are at the bottom of the respective branch. The nodes in between are PTP-capable switches (PTP boundary clocks), each of which assumes the role of a time sink (PTP slave) on one port and the role of a time source (PTP master) on the other ports. This means that each PTP connection is a point-to-point connection in accordance with the 802.1AS standard.

Each PTP connection synchronizes the two end points, the slave and the master, according to the same principle. Both the phase between the two participants and the drift due to differing frequencies of the clocks are determined and compensated for.

In order to be able to compensate the phase, both the difference between the local clocks and the latency of the cable connection must be known. To do this, the latency (delay) between two PTP nodes is first determined using a mechanism based on so-called 'Peer Delay Messages' (P2P).
With the knowledge of the latency, the actual phase error (offset) can now be determined using time-stamped messages. Successive measurements are used to determine the frequency error - the drift. How the individual parameters - delay, phase error and drift - are determined is defined in the standard.
How the measured phase and frequency errors are compensated is not defined in the standard and is implementation-specific. This can be done abruptly or using sophisticated control algorithms.

The quality of the synchronization

Figure 2: Timestamp inaccuracy at different levels of the network stack.

© NetTimeLogic

The achievable accuracy depends heavily on the stability of the time source, the topology and the resulting number of hierarchies in the PTP synchronization tree. In addition, there is also the expected system-related error per node in the hierarchy (timestamp granularity, duration of stay, oscillator stability). And finally, of course, the accuracy depends on the implementation of the end node to be synchronized (timestamp granularity, filter and control parameters, oscillator stability).

The synchronization hierarchy in Figure 1 shows that the achievable accuracy decreases with an increasing number of levels (hops) between the time source and time sink. This is mainly due to the timestamp accuracy in the individual hops and the calculations based on them, as well as the stability of the oscillators. In principle, PTP does not determine how a timestamp of a packet is taken, but it does determine when a timestamp is taken. This is exactly when the start-of-frame delimiter (SFD) leaves or reaches the cable at the respective node. How the corresponding time stamps are generated depends on the implementation. There are also different levels where timestamps can be taken (see Figure 2 above). In the lower levels, the time stamping takes place in hardware, in the upper levels in software.

Put simply, the higher the layer in the OSI model, the more error-prone the timestamp. Hardware support is necessary to achieve a synchronization accuracy of <1 μs. This also applies because the timestamp is only one of three crucial parts required for highly accurate synchronization and its benefits. The timestamps are ultimately based on a time, which must be adjusted accordingly in phase and frequency, which is the second crucial part: an adjustable clock.

The more accurately the clock can be regulated, the more accurate the time stamps and, accordingly, the more accurate the calculations of the new control parameters. In this context, however, the accuracy of the control also depends very much on the oscillator stability of the clock source for the clock. It is therefore useless if the frequency of the clock is controlled with a resolution of around 1 ppb (1 ns/s), but the clock source has a jitter of 10 ppm (10 μs/s).

Fortunately, many low-cost crystal oscillators with 50 ppm - at constant temperature and vibration - are also very frequency-stable (<10 ppb). The absolute frequency error is irrelevant here, as this can simply be regulated away. It is therefore purely a question of frequency stability. To achieve acceptable accuracy with less stable oscillators, the frame rate can be increased. This means that a node can readjust more often and drift less far away than at lower rates, but at the expense of the network load. The third and final crucial piece of the puzzle is the ability to use the high-precision clock. This involves either triggering time-controlled events (phases and cycles in TSN, synchronous sampling of ADCs, synchronous control of motors or OPC-UA frame triggers) or providing events with the high-precision clock with a time stamp (such as asynchronous events for central correlation). As with timestamps, the more hardware support, the more precise.

The implementation options

Figure 3: The block diagrams of a HW-SW-Co solution and an FPGA solution.

© NetTimeLogic

In principle, implementation is possible as a pure software, combined hardware-software or pure hardware solution. For endpoints that only perform non-time-critical tasks in a TSN network, for example a visualization or monitoring application, a software-only solution may be sufficient.
For TSN networks with the requirement of a synchronization accuracy <1 μs and thus the network infrastructure as well as the affected endpoints, there are de facto only two possible approaches (Figure 3): Software with hardware (SW-HW co-solution) or a pure hardware solution (FPGA solution).

The SW-HW co-solution

In a SW-HW co-solution, everything time-critical is usually solved in hardware and everything non-time-critical in software. A widespread example of this is the PTP solution with ptp4l. ptp4l is an open source protocol stack implementation for Linux according to IEEE 1588/IEEE 802.1AS. ptp4l handles everything to do with PTP frame sending/receiving, the protocol algorithms, including the evaluation of the time stamps and calculation of the control parameters for the clock. However, the actual time stamps come from dedicated hardware - for example network cards - which provide the time stamps via the socket API. In most cases, there is also a controllable clock on the same dedicated hardware - the time stamps come from a clock - which is addressed by ptp4l via the PHC API. This solves the problem of timestamps and adjustable clocks.

The point is that the high-precision time is now available on the network card, but apart from PTP it is actually useless there, except for the hardware-specific features, which are manufacturer-specific. This now requires ptp4l-specific tools (phc2sys), for example to track the system clock of the PTP clock (PHC clock) and generate synchronous events or take timestamps. This results in two additional sources of inaccuracy, firstly when synchronizing the system clock and secondly during event generation and time stamping, which can be very CPU load-dependent. In order to achieve high precision, a real-time OS is actually required here. In addition to ptp4l, there are other commercial PTP stacks which also support non-Linux systems, for example, and can then also be used on MCUs.