Dear author, the following contents are excerpts from your papers. They are editable.

(Due to the lack of relevant professional knowledge, our editors cannot complete a complete entry by summarizing your paper, so if you are interested in this work. you may need to write some contents by yourself. A good entry will better present your ideas, research and results to other scholars. Readers will also be able to access your paper directly through entries.)

1. Introduction

There are many applications of time synchronization in the IoT (Internet of Things) and IIoT (Industrial Internet of Things). In a smart factory, the production robots which work together on a production line must be synchronized precisely. Exact time synchronization is also important when multiple motors move one mechanical load [1,2] or, in general, when drives work together [3]. In a smart power plant or in the area of energy supply, time synchronization is of decisive importance both for the analysis of blackouts and for controlling the stability of the power grid [4].

In addition, time synchronization is essential for communication based on TDMA (Time Division Multiple Access). TDMA is used, e.g., in real-time networks. Each device is given an exclusive transmission time slot. Compliance with these time slots prevents collisions. The better the devices are synchronized, the more precisely the time slots can be adhered. Consequently, the available bandwidth can be utilized better [5]. However, if the devices are inaccurately synchronized, slack times must be inserted to guarantee that only one device is transmitting at a specific point in time. This leads to unused bandwidth. TDMA methods are used in practice in many real-time Ethernet protocols such as Ethernet Powerlink or SERCOS III. Furthermore, wireless real-time communication is typically based on TDMA [6]. In addition to real-time networks, TMDA is also used in WSNs (Wireless Sensor Networks). Here, the sensor nodes communicate, e.g., only for a short time period and otherwise remain in a sleep mode to save energy [7,8].

Another application of time synchronization is distributed data acquisition. An example is the nuclear fusion experiment W7-X (Wendelstein 7-X). The W7-X experiment has a relatively large spatial expansion as the diameter of the vacuum vessel is approximately 16 meters. Above all, it is a highly dynamic system (magnetically enclosed plasma). Both the control of the system and the scientific evaluation of the experiments require measurement timestamps with accuracies in the range of nanoseconds [9]. Measured parameters are, e.g., temperature, electron density, and plasma properties [10]. These requirements also apply to similar large-scale experiments such as the particle accelerators at CERN (European Organization for Nuclear Research) [11]. Another example of distributed data acquisition as an application of time synchronization is the interconnection of several radio telescopes in order to achieve a significantly higher resolution. If several such telescopes are distributed over different continents, the data needs to be timestamped precisely in order to be fused in postprocessing. With this method, the Event Horizon Telescope could for the first time take a picture of the direct vicinity of a black hole [12]. Another example is the observation of the stability of bridges, stadiums, and high-rise buildings using wireless sensors. Here, a synchronization accuracy of at least 120 μs is required to enable detecting vibrations [13].

In general, time synchronization enables ensuring the sequence of events [5]. Therefore, it is also essential for the financial world and online trading as the sequence of transactions is particularly important here [5]. Time synchronization is also important for distributed databases to ensure consistency as well as to optimize throughput and latency [5].

2. Time Synchronization Protocols

This section deals with existing protocols for time synchronization. These primarily relate to wired networks. Table 1 shows a tabular overview of this.

Table 1. Overview of protocols for time synchronization. It shows their standard compatibility (SC), the estimation method used, the accuracy, as well as conditions and restrictions (MV = mean value, RTT = round-trip time, KF = Kalman filter, and PLL = phase-locked loop).

2.1. NTP

The Network Time Protocol (NTP) [47] is standard-compliant, uses the RTT (round-trip time) as estimator, and has an accuracy of approximately 1 ms. It is also the most commonly used synchronization protocol on the Internet. NTP is a pure SW protocol, so that no changes are required at the lower network layers. NTP clients send packets to the NTP server at certain times and wait for the response. The packet’s RTT can be calculated from the time the response was received. From this, in turn, the latency can be estimated assuming symmetrical packet delays. An accuracy of approximately 1 ms can be achieved on the Internet with this protocol. On the network level, there is a hierarchical structure of participating servers. The advantage is that large networks can be synchronized more efficiently with several servers and the load on the server is reduced. However, the accuracy decreases in this case due to the propagation of errors along the hierarchy. NTP is not suitable for real-time IIoT applications due to its limited accuracy, which decreases even further when delay variations occur [46].

2.2. PTP

The Precision Time Protocol (PTP) [48,55,56] specified in IEEE 1588 is standard-compliant. It uses the RTT or a simple sum as an estimator and achieves an accuracy below 1 μs. However, PTP requires specialized HW to achieve this accuracy (at least on the end nodes). Since there are three versions of PTP, these should be briefly classified here. The first version was PTPv1 1588-2002 [56]. The next version, PTPv2 or 1588-2008 [48], has no compatibility with PTPv1. The latest version, 1588-2019 or PTPv2.1, however, is fully downward compatible with PTPv2. PTP is designed to allow precise synchronization between devices. It is available as both a HW and a SW version. PTP synchronization begins with determining the device which has the most stable and accurate time. The node with the reference time (the so-called grandmaster clock) is selected using the Best Master Clock Algorithm (BMCA). Reference times are then sent to the slaves, which compare them with their own time. Slaves respond to the master with their own times at regular intervals. The delay from the master to the slave and the delay from the slave to the master can be determined from the timestamps in the messages in order to be able to synchronize the slaves. In the best case, the HW variant achieves an accuracy in the nanosecond range. The existing SW version uses timestamps from the application layer and, with a HW-supported reference time, achieves an accuracy of the order of microseconds. However, PTP assumes that the network delay is constant and symmetrical. Therefore, delay variations reduce the accuracy of PTP, as measured for example in [57,58] and simulated by the authors of this work in [59]. Such variations can occur when switches do not support PTP at the Media Access Control (MAC) layer. Good descriptions of PTP and an accuracy analysis can be found in [1,58,60]. Of all the synchronization protocols that use HW timestamps, PTP is the most widely used protocol. Consequently, the IEEE-TSN committee used PTP to derive gPTP (Generalized Precision Time Protocol) as a TSN substandard. The left side of Figure 1 shows an example of a PTP network, and Figure 2 shows PTP’s message exchange and delay estimation using RTT.

Figure 1. Example of a Precision Time Protocol (PTP) network and a Generalized Precision Time Protocol (gPTP) network: M marks that the corresponding Ethernet port is in the master role, and S marks the slave role. (We created the diagrams on our own based on [48,49]).

Figure 2. PTP’s message exchange and delay estimation using RTT. The master starts by sending a Sync message and timestamps the sending moment as t1. The slave timestamps the receiving moment as t2. The master sends a Follow_Up message, if it cannot embed t1 directly into the Sync message. The slave sends a Delay_Req message and timestamps the sending moment as t3. The master timestamps the receiving moment as t4. Afterwards, the master sends a Delay_Resp message, which comprises t4. The slave estimates the delay as [(t2−t1)+(t4−t3)]/2) assuming a symmetric delay (tms=tsm). (We created the diagrams on our own based on [48]).

2.3. gPTP

gPTP or IEEE 802.1AS [49,61] is standard-compliant. It uses the RTT or a simple sum as an estimator and achieves an accuracy below 1μs, but it is limited to 7 hops [49]. However, gPTP requires a specialized HW. In contrast to PTP, it requires this not only on the end nodes but also on the switches (Although gPTP itself is a standard, it massively improves the complexity of Ethernet’s MAC layer. Therefore, we still refer to it as specialized HW). The authors of [62,63,64,65] give a good overview of the gPTP standard, which is part of a series of standards originally developed by the Audio/Video Bridging (AVB) task group. In 2012, this group was renamed TSN. The aim of the TSN group is to develop an open standard for Ethernet-based real-time communication. In particular, they focus on the timing and synchronization, the reservation of resources and queues, as well as data forwarding. Basically, the synchronization of gPTP is similar to PTP. A modified version of PTP’s BMCA is used. Each port of a so-called time-sensitive system measures the delay to its neighbors in a way that is similar to PTP. A bridge or an end station that meets the requirements of IEEE 802.1AS is referred to as a time-sensitive system. All nodes in the network (bridges and end stations) must be such time-sensitive systems. gPTP is a so-called PTP profile. As a result, a PTP implementation can be compliant with gPTP if it supports the gPTP profile. However, this is not required because a PTP implementation is considered to be standard-compliant if it supports the default PTP profile. The support of further PTP profiles (e.g., gPTP) is optional. In contrast to PTP, gPTP is also specified for wireless networks [49]. The right side of Figure 1 shows an example of a gPTP network.

2.4. PTCP

PTCP (Precision Transparent Clock Protocol) [50,51] is standard-compliant. It uses the RTT or a simple sum as an estimator and achieves an accuracy below 1 μs. However, PTCP requires specialized HW on switches and end nodes. PTCP is used for synchronization in the real-time Ethernet protocol PROFINET and, just like PROFINET, is standardized in IEC 61784-2 [50]. PTCP is also based on PTP. The most important difference is the use of “transparent clocks”. In contrast to PTP, direct neighbors are not synchronized, but only the end nodes with the master are synchronized. This is achieved as the switches compensate the time between receiving the Ethernet frame at the input port and sending the frame at the output port (by adapting the timestamps). These so-called “transparent clocks” have the advantage that the synchronization accuracy remains high even over many hops. In [52], PTPC is extended with a Kalman filter as an estimator. The standard compliance is retained.

2.5. SyncE

Another protocol is Synchronous Ethernet (SyncE) or ITU-T G.8262 [53]. SyncE is actually a real-time Ethernet protocol. Strictly speaking, however, it also offers a synchronization functionality for the frequency or skew. For frequency synchronization, the clock signal is transmitted at the physical (PHY) layer and the devices synchronize using phase-locked loops (PLLs). The achievable frequency accuracy is ±4 ppm. SyncE does not correct the offset. In [54], however, an extension of SyncE to include such an offset correction is suggested. The procedure is then no longer compliant with SyncE, but it was submitted to the ITD-T as an extension proposal.

2.6. Summary of Existing Time Synchronization Protocols

NTP is the most widely used protocol, as is does not need any special HW. PTP achieves a much higher precision than NTP by using a special HW at least on the end nodes. As PTP assumes the network delay to be constant and symmetrical, delay variations can reduce its accuracy. This is, e.g., experimentally shown in [57,58] and simulated by the author of this work in [59]. Such variations might occur, if non-PTP switches are used in the network (note that this fully complies with the PTP specification). The gPTP protocol (part of the TSN standards) demands special HW on all end notes and switches. Therefore, the delay in a gPTP network can be assumed to be constant. One benefit of gPTP and PTP regarding robustness is that both use the BMCA. The BMCA adaptively chooses a new reference clock if the original one fails.

This entry is adapted from the peer-reviewed paper 10.3390/iot1020023