wilamowski-b-m-irwin-j-d-industrial-communication-systems-2011

18-2 Industrial Communication Systems
Master
Slave
T 2
M
Δ 1 = Δ
Delay request
T 2
S
T 3
M
Delay response
Δ 2 = Δ
T 3
S
T 4
S
T 5
M
Sync packets
Δ 2 = Δ
T 6
S
T 5
M
Master time
Slave time
FIGURE 18.1
packets.pdf).
Synchronization packets and round-trip delay measurement (1588_Sync_DelayRequResp_
real time for communication [Sauter2005, Brennan2005,Hansson2005]. IEEE 1588 synchronizes
clocks in a master/slave fashion, whereas the master is the node with the highest accuracy. The accuracy
class (also called stratum in version 1) can of course be the same at every node in the network (e.g.,
same oscillator type used). However, in the case where the stratum is the same, a unique node identifier
(layer 2 MAC address in the Ethernet case) is used to favor one node. The master election follows a certain
message-based election algorithm and ends up with the decision which node should be the master
for the next synchronization process. After a proper master is elected, synchronization can take place.
The synchronization process in IEEE 1588 networks is organized in two stages. A so-called delay
request delay response process measures the round-trip delay, to determine the packet delay between
master and slave. This is done upon initiation by the slave with a telegram, which is returned by the
master with the local timestamp of reception. In addition, the master regularly sends out synchronization
packets. Again, these packets are sent in a two-stage process. The first set of packets is timestamped
with an estimation of the sending time. The actual sending time (which obviously can only be known
after completing the transmission) is sent with a so-called follow-up packet. Figure 18.1 shows this synchronization
principle. A detailed description of this process together with implementation issues can
be found in [Eidson2006].
18.3 IEEE 1588 System Model
The starting point of the protocol specified in IEEE 1588 is a distributed system of nodes. The medium as
such is not relevant for the protocol. As shown in Figure 18.2 in general, the position of the ingress message
timestamp point and the egress timestamp point are not required to be identical, since two different
© 2011 by Taylor and Francis Group, LLC