2013 IEEE 18th International Workshop on Computer Aided Modeling and Design of Communication Links and Networks (CAMAD)
Efficient and Precise Simulation Model of
Synchronization Clocks in Packet Networks
Zdenek Chaloupka, Nayef Alsindi, James Aweya
Etisalat British Telecom Innovation Centre (EBTIC), Khalifa University of Science, Technology and Research, UAE
{zdenek.chaloupka, nayef.alsindi, jarnes.aweya}@kustar.ac.ae
Abstract-As packet technologies like Ethernet and IP are
becoming the dominant in modern telecommunication networks,
clock frequency and time synchronization over packet networks
is an active area of research. Packet networks are asynchronous
by design so frequency and time synchronization with sub­
microsecond precision is a demanding task due to packet delay
variations. A design of proper algorithms, that
telecommunication requirements, usually involves simulations
over long period of time with nanoseconds resolution. Such
precise and long-term simulation of synchronization performance
is challenging, because of the vast amount of computer resources
involved. This paper describes a simulation model that is both,
efficient and highly precise. The model is able to simulate
algorithms behavior over long period of time (tens of hours)
while the computation time remains within interval of few
minutes.
Index Terms- clocks, frequency synchronization, IEEE 1588
PTP, time synchronization
I. INTRODUCTION
P attractive
ACKET based technologies (e.g. IP, Ethernet) are becoming
alternatives to traditional Time-Division
MUltiplexing (TDM) technologies, because of their higher
efficiency with significantly less capital involved. The recent
advances in high-speed switching/forwarding made it possible
to build networks with joint voice, video and data
transmissions.
Current TDM networks are designed with respect to the
synchronization requirements of the voice/data services. Thus,
the TDM networks have embedded tlmmg transfer
capabilities. Contrarily, packet networks such as Ethernet and
IP are asynchronous and do not have such aptitude. In order to
be able to substitute TDM networks with packet networks (and
packet technologies) for telecommunication services, timing
transfer and synchronization have to be provided by other
means. Two commonly used protocols for timing distribution
are the IEEE 1588 Precision Time Protocol (PTP) [1] and the
Network Time Protocol (NTP) [2]. As the time and frequency
synchronization technologies and devices are subject to
stringent demands that require sub-microsecond precision [3]
we are primarily targeting the IEEE 1588 PTP protocol,
because it provides better resolution (sub-nanosecond [1]) than
NTP (millisecond [2]), although the definition of our
simulation model should be easily transferred to a different
timing distribution protocol (e.g. NTP). Generally,
978-1-4673-4919-2/13/$31.00 ©2013 IEEE
synchronization solutions have to be tested in compliance with
standard [3] for long-term based stability. Such tests are
usually performed over tens of hours of running time, however
it would be convenient to obtain the simulation results in few
minutes.
meet the This paper describes a simple and effective IEEE 1588 PTP
model that provides a precise simulation of long time periods
(tens of hours) in few minutes of computer time. Such model
is essential for delivery of stable and reliable synchronization
solutions for packet networks.
A. Literature Review
In [4] a simulation tool for analysis of clock
synchronization in communication networks was presented.
The model of clock synchronization was based on substitution
of Master/Slave clocks, Phase-Locked Loop (PLL) and
forward/backward paths by a transfer function. As it is
preferred to have full control over PLL design without the
need for deriving mathematical models, this method is not
suitable. The authors in [5] investigated forwarding and
queuing process of individual packets in a simple packet
network. With simulation sampling period of 1/-ls and
simulation time of 5s the model required packet sampling rate
to be 20.000 per second in order to get exploitable results.
Such packate sampling rate is unrealistic (refer to settings of
standardized synchronization protocol [1]) and the model
sampling period is inadequate (we require sub-microsecond
resolution). In [6] Q. Yujuan derived model for OPNET
Modeler based on NTP, but the paper didn't give any
specifications regarding the clock precision settings. [7]
studied the performance of IEEE 1588 PTP protocol with
transparent clocks. A combination of Matlab and PROFINET
tool was used for simulation. Although the results presented
are with sub-microsecond precision, the simulation run times
were very short (60 seconds). The paper didn't provide any
information about simulation model. In [8] T. Kunz et al.
presented clock synchronization in WSN, where the sensor
clock sampling time is based on 32.767 kHz oscilator which
brings time resolution of approximately 31 f.!S and thus the
model does not fulfill the stringent sub-microsecond resolution
requirements [3]. Another IEEE 1588 PTP simulation
experiment was carried out in [9]. Authors implemented and
simulated complete IEEE 1588 PTP protocol in OMNeT++
simulator and investigated the behavior of end-to-end clock
synchronization in packet networks. The paper lacks detailed
79
 2013 IEEE 18th International Workshop on Computer Aided Modeling and Design of Communication Links and Networks (CAMAD)

information about simulation running times, and the
simulation was clearly aimed to show real time behavior.
Thus, long time simulations are impractical with such model.
In [10] a simulation model for clock synchronization based
on IEEE 1588 PTP protocol was derived. The model is based
on mathematical representation of the clocks, thus high
precision is granted. However, the paper is focused more on
PLL behavior than model efficiency and implementation,
though the simulation run times (12000s) are longer than in
any other reviewed paper.
In this paper we extended the work presented in [10]. Our
main contributions are as follows:
1) We extended the model definition presented in [10] to a
more general case (see Section II).
2) A discussion on the model's precision is completely
omitted in [10]. This paper gives a thorough discussion on
the model precision in Section III.
3) A design of the model and its effectiveness (in terms of
simulation speed) are not discussed in [10]. An easy-to­
understand design of the model as well as the
performance evaluation of the model (see Section III) is
revealed in this paper.
The reminder of this paper is organized as follows. Section
II derives a simulation model with respect to the IEEE 1588
PTP protocol. Section III investigates the model precision and
effectiveness. Finally, Section IV highlights the conclusions
drawn from the work and discusses future work.
subscript refers to the PTP protocol timestamps generated by a
Master (Tj, T-I) or Slave (T2' T3) clock. Variables that change
discretely with respect to a set of message exchange are
denoted as Tj[n] and Tj[n+l], where the former is n-th and
latter (n+1)-th discrete state related to the n-th and (n+1)-th set
of messages respectively. Lower case letter t stands for
reference (ideal) time. Capital N refers to number of observed
set of PTP messages. Tpck is SYNC message send interval
always measured by a Master clock. Superscript M, S next to a
variable denotes that the variable is clocked by the Master,
Slave counter respectively. Other symbols are explained next
to the equation that uses them.
Slave Clock Master Clock Ideal Time
T,[nl
T2[nl
c
(;j
<I
CS[n+11
--

T2[n+11
�__ :' i\)_:ii
+1
--:(::n:: S y-;n�
th�s. c I T,[n+11
II. SIMULATION MODEL

Let us first define the basic synchronization terminology

and assumptions used throughout the paper. We refer to a
Fig. I. IEEE 1588 PTP protocol flow with a relation between Slave clock,
reference or ideal time as to a universal time that exist at all Master clock and ideal time.
physical locations, but may not be known to any system
The PTP protocol defines a set of messages that are sent
component. We will use the terms ideal and reference time
between the Master and Slave device. The set of messages
interchangeabIy.
consists of SYNC, (FOLLOW_UP), DELAY_REQ,
A Master clock time is the local time at a Master site,
DELAY_RESP. The Fig. 1 depicts the messages flow between
measured by a Master's clock counter. Similarly, a Slave
the Master and Slave device. The Master device periodically
clock time is the local time at a Slave site, measured by a
sends SYNC messages (sending time period Tpck is
Slave's clock counter. Note that the Master and Slave clock
configurable and can vary from 1 packet per 2 seconds to
times (measured by counters) usually differs and both clocks
maximum 128 packets per second [1]).
may differ from ideal time.
The SYNC message is dispatched from the Master device at
Without loss of generality we can assume the following
some time Tj[n] with timestamp embedded in the packet or
facts. The ideal time is common reference for both, the Master
sent subsequently in FOLLOW_UP message. Note that we do
and Slave clocks. We will use the common reference to define
not require simulation of the FOLLOW_UP message, as its
the relation between the time at the Master and Slave site. The
only purpose is to deliver SYNC message dispatching
relation between ideal time and the Master (Slave) clock
timestamp. The timestamp of the n-th SYNC packet is defined
counter is deterministic and specified by a counter's running
as
frequency denoted 1M lfs). Parameters of the local counter (i.e.
driving frequency, offset) either remain constant or their
dependency on common reference time is known. (1)

A. IEEE 1588 PTP Model Derivation

As was mentioned in Section I we focus solely on IEEE
1588 PTP protocol, however the model definition could be
extrapolated to other synchronization protocols (see [10]).
With respect to the Fig. 1 we will use the following symbol
notation logic throughout this paper: capital T with numeric
The initial time Tj[O] at which the first SYNC message is
dispatched can be completely arbitrary. The reference time at
which the n-th timestamp was dispatched is denoted as tR,n
(see Fig. 1 for details). Every two consecutive SYNC packet
timestamps are distant by a constant time Tpck measured by the
Master's clock, however the same interval measured by ideal

80
 2013 IEEE 18th International Workshop on Computer Aided Modeling and Design of Communication Links and Networks (CAMAD)

time (denoted fit) doesn't have to be a constant (refer to Fig.

2). If the Master's clock counter frequency 1M is exact, that
means clock doesn't drift from ideal time, fit equals Tpck for all
n as assumed in [10]. However in general, fit may differ from
Tpck. That is our extension of the definition brought in [10]. An
example of the network synchronization setup where Master's
clock can drift from ideal time is depicted on the Fig. 3 (refer
to [1] for more details).

• • • •
1 1 1 1

r r 1
• 1 1 1 Messages
1 1 1 1
I 1 1 1
Tp,' Tp,' Tpc'
I
I
1
1
1
1
1
1 Fig. 3. An example of synchronization setup in packet network using
I I I I i boundary clocks; M, S stands for Master, Slave respectively. Boundary
� �
1 I I
• ...
1'.,["] I 1'., [II + I] " 1'.,[II] I 1'.,[11+2] I Master clocks may be skewed from the ideal time due to limited
I I I Ideal •lime precision of the Master's counter oscillator.
IR,n tR,n+1 tR,n+2 tR,n+3
The Slave device receives SYNC message at time T2[n]
• • • •
1
•
1
I.
1
1 •
1
1 measured by the Slave's clock counter CS. Every timestamp T2

r
I 1 : 1 1
I 1 : 1 1
is delayed behind the time of SYNC message transmission by a
Tp,'
1 : 1 1
Tp,'
I
1 1 : 1 1
I 1 1
i
I
IiI 1
i
I
I
�
I
forward delay 8, that is the time spent to travel the distance
1'.,[11]=1'.,[0] 1'.,[0] between the Master and Slave device. We define timestamp T2
Ideal lime
T",.
I
=

IR,n tR,n+1 tR,n+2
Fig. 2. A relation between the ideal time (dash dot), the Master
(dotted) and Slave (dash) clocks. The upper case is for inaccurate
Master (faster than the ideal time).
The bottom part of the Fig. 2 reflects the situation when the
Master clock is aligned with ideal time. Thus, the constant
Tpck. measured by the Master clock, equals fi" measured by the
ideal time. Contrarily in the upper part of the Fig. 2, fit
measured by the ideal time is changing for each packet. As we
assume the frequency of the Master's clock counter to be
known, computation of fit for ideal time is as follows
j�
'TpCk' n =l..N.
fi,[n]=tR,n-tR,n_l =
j�[n]
We assume that the reference frequency IR is constant
whereas the Master's frequency 1M can change between
consecutive packets, hence the discrete notation. Similarly to
(2), the amount of time that passes between two consecutive
SYNC messages at the Slave clock site is exactly specified by
a ratio between the reference and Slave clock's frequency and
time between two consecutive SYNC messages measured by
ideal time (see Fig. 1), that is
Hence, we can define the Slave's clock counter time as
•
tR,n+3 . . . .
(5)
i[n] is the forward delay measured by the Slave clock.
Upon receiving the SYNC message the Slave device sends
DELAY_REQ message at time Tj[n]. Timestamp Tj is delayed
behind T2 by a processing delay A[n],
� [n]=T2 [n] + AS [n]= CS [n] + £s [n] + AS [n]. (6)
The Master device receives DELAY_REQ message at time
T�[n], that is delayed behind TI by a sum of the forward,
processing and backward delays (measured by the Master
(2)
clock). We define T� as follows
T4 [n]= T., [n] + £M [n] + AM [n] + yM [n]. (7)
The Master device responses with DELAY_RESP message
that carries timestamp T-I back to the Slave device. At this
stage the Slave device possesses a complete set of timestamps
{h h Tj, T�}.
Let us assume for this moment that the forward/backward
and processing delays were measured by the ideal time (refer
to next chapter for details). In order to use these delay values
in (5)-(7) we need to convert them into the Master/Slave clock
(3) time representation. Similarly to (2) or (3), the time that passes
for the Master/Slave clock with respect to ideal time is exactly
given by the ratio between the Master/Slave clock frequency
and the reference frequency. We can write

(4)
(8)

The initial time CS[O] at which the first SYNC message is

dispatched by the Master is bound to the initial time TI[O] (see
Substituting quantity lfI[n] by the forward/backward or
Fig. 1 for details).
processing delays measured by the ideal time we obtain their
representation in Master/Slave clock time.

81
 2013 IEEE 18th International Workshop on Computer Aided Modeling and Design of Communication Links and Networks (CAMAD)

B. Model Block Design

In previous chapter we derived equations for the timestamp E[n)
...
, ljJ[n)
message exchange between the Master and Slave clock, but es
the simulation model is still incomplete as models of the � �clock
T.
...
stamp
forward, backward and processing delays are unknown. � � ref. clock �
T2[n
The forward and backward path delays are by-products of
network routing mechanisms placed between the Master and E[n)+A[n)
...
Slave device [12]. Every packet traveling from the Master to , ljJ[n)
es
the Slave device experiences a different delay according to the clock
...
,
...
actual network load along the path. A direct simulation of such T. stamp
network path with all its components is a non-trivial task. �� ref. clock �
T3[n
Fortunately, the packet delay generated by a network under
E[n)+A[n)+y[n)
certain load can be characterized as a random process [12]. ... T1[n
- , ljJ[n)
That means we can generate a packet delay from a certain eM j!,.
,
clock
...
,
distribution (discuss [12] on distribution type) that
T.
...
stamp
ref. clock
.. ,
characterizes a distinct network load. Similarly, the PTP ,
T4[n
application's processing delay can be modeled as a random Fig. 5. Simulink design of the PTP message generator. Inner structure
process. Since the processing delay variation (microseconds) of each block is depicted on the Fig. 4.
is considered to be lower than the forward/backward path
delays (hundreds of microseconds) by at least two orders, the
exact statistical characteristic of processing delay is not III. SIMULATION MODEL PRECISION AND PERFORMANCE

required. The processing delay can be simulated by one of the
well-known distributions (e.g. normal distribution).
The above definition of statistical characteristics of
forward/backward and processing delays gives us full control
over the model variables as the generation of a random
variable from known probability distribution
straightforward. Since the generation of the random variables
is independent on the Master/Slave clock, the generated delay
values are measured by ideal time, hence (8) applies.
The model was implemented in Matlab Simulink R2012a
because Matlab itself is simply not efficient with loops.
Anyway, we suppose that the simplicity of the derived model
makes it easy to implement in any programming language.
Simulink block design for the generation of the timestamps is
on the Fig. 4.
Taking into account (1)-(8) the maximum time precision of
Simulink model is limited only by a numerical resolution of
variables inside the model. The obvious precision bottlenecks
are the frequency division (3), (8) and integration (4). If we
use system with 8byte floating representation maximum
is attainable resolution is T53 (i.e. 1.12x 10.16) second. To
confirm the sub-nanosecond resolution of the proposed model
its precision was tested as follows. We set the forward,
backward and processing delays to zero. The initial offset of
the Master and Slave clock is zero, the Master clock is
considered equal to the ideal time (i.e. the!R equals!M[n] for
each n) and Is is arbitrary. Hence the relation between
timestamps of the Master and Slave clock can be written as
r; [ n] + £ [ n]= (1 + a [ n]). T2 [ n] + () [ n]. (9)

clock
fM,S---� As mentioned above the variables c and e are set to zero in
fR (9). The variable a (called skew) is defined as a ratio between
the Master and Slave clock frequency, that is

Plain clock

Timestamp a[n]=fM [nLl. (10)

ljJ[n) T[n)
Fig. 4. Simulink design of the Master/Slave clock (upper part) and
generator of timestamps (bottom part).
For generation of the timestamp T2, T3 we substitute
variable If! with {c}, {c + y} respectively and feed the block
with proper clock frequency (is). For generation of the
timestamps h T� we substitute variable If! with {O}, {c + A +
y} respectively and feed the block with clock frequencY!M.
Simulink block that generates the IEEE 1588 PTP set of
messages is depicted on Fig. 5.
fs [n]
From (9) and (10) we can see that unless there is a round off
error (introduced by (3), (4) and (10)) the left side of (9) has to
be equal to its right side for each n. Thus, the actual time error
of the model can be obtained by subtracting the left side of (9)
from its right side, that is
e[ n]= (1 a [ n]). T2 [ n]
+ - r; [ n J. (11)
The results are depicted on the Fig. 6. We used two Slave
clock frequencies that differ from the Master clock by 10 and
20 parts per million (ppm). In order to increase the probability

82
 2013 IEEE 18th International Workshop on Computer Aided Modeling and Design of Communication Links and Networks (CAMAD)

of rounding error we also used the Tpck constant with long

70 ,---�----�---,
fractional part by setting the packet per second interval to 17
,
(i.e. Tpek 1/17). Referring to Fig. 6 it is obvious that the error
=
60 ,
,
,
,
,
,
introduced by rounding is much smaller (i.e. sub-nanosecond)
C
than the noise added by forward/backward delay variations 15O
that are in order of tens of microseconds (refer to [10], [12]). Ql
,

The showed time error has an increasing tendency as a natural � 40 , -12h

c ,

result of error accumulation in (4), however the model is still 2 , ·· ···24h

Q; 30
,
, - - -72h
able to keep sub-nanosecond precision even during long-term "5 ,
c. ,
runs (tens of hours). � 20 ,
,
,
()
,
,
,
10
-10ppm, 16packets/s
... 20ppm, 16packets/s
O L---�-
20 40 60 80
---�--�
100
2 Packets per second
Fig. 7. Simulation model performance for different setting of packets per
second and simulation time. Legend refers to the simulation run time.

IV. CONCLUSIONS

We've designed a simple and effective IEEE 1588 PTP

_1 L-------L---�--�--�
o 20 40 60 80
Time elapsed [hours]
Fig. 6. The time error for a different setup of the Slave clock skew and
SYNC period Tpck.
Since the shortest synchronization period is 7.8ms (128
messages per second) we obtained an efficient simulation
model while maintaining the sub-nanosecond precision,
because we can generate long time periods of data with
sample rate at maximum 128Hz, while common simulators
with nanosecond step precision have sampling rates at 109Hz
order. This brings us the required memory and speed
efficiency. In order to evaluate the simulation model's
performance we measured the computer run time for three
different simulation times (12124/72hours), each measurement
repeated for four distinct SYNC packet periods (16/32/64/96
packets per second). The Fig. 7 shows the simulation results.
Let us define a computational efficiency ratio as
Era! Rt!S!, where R, is the computer run time and SI is the
=
simulation time. Our simulation model clearly outperforms the
model presented in [4], as computation efficiency ratio Era! of
their model was at best 0.03 and at worse 0.13 whereas our
model achieves Era, at worst 0.02 (for 128 packets/s) and at
best 0.0024 (at rate 16 packets/s). Another performance
improvement will most likely be achieved if the model is
implemented in C/C++ or similar low level programming
language. It should be noted that Simulink is strictly
sequential (no parallelism whatsoever), so it uses only one
core (one thread) of CPU. The tests were performed on mobile
processor Intel Core i7 with 2.3GHz speed.
simulation model that is able to simulate long periods of time
with sub-nanosecond precision while maintaining reasonable
computer run time. The performance test showed that at the
worst case we achieved computation efficiency ratio of 0.02
and at best 0.0024, depending on the number of packets sent
per second. Thus a simulation of 12 hours requires at worst
14.4minutes (128 packets/s) and at best 1.7minutes (16
packets/s) of the computer time.
The future work is to utilize our simulation model for heavy
testing of time/frequency synchronization algorithms.
REFERENCES
[I] IEEE Standard for a Precision Clock Synchronization Protocol for
Networked Measurement and Control Systems, IEEE Std. 1588-2008.
[2] D. L. Mills, "Internet time synchronization: the Network Time
Protocol," IEEE Trans. on Communications, vol. 39, no. 10, pp. 1482-
1493, Oct. 1991.
[3] Timing and Synchronization Aspects in Packet Networks", ITU-T
G.8261, April 2008.
[4] M. A. Bueva et aI., "Modeling Technique and a Simulation Tool for
Analysis of Clock Synchronization in Communication Networks," in
CAMAD, 2006, pp. 85-92.
[5] A. Vallat, D. Schneuwly, "Clock Synchronization in
Telecommunications via PTP (IEEE 1588)," in IEEE FCS, 2007, pp.
334-41.
[6] Q. Yujuan, L. Guixiong, "Drifting Clock Model for Network Simulation
in Time Synchronization," in ICICIC, 2008, pp. 385.
[7] R. L. Scheiterer et aI. , "Synchronization Performance of the Precision
Time Protocol in the Face of Slave Frequency Drift," in IEEE CASA,
2008, pp. 554-59.
[8] T. Kunz, E. McKnight-MacNeil, "Clock Synchronization in WSN:
Simulation vs. Implementation," in IWCMC, 2011, pp. 980-85.
[9] Y. Liu, C. Yang, "OMNeT++ Based Modeling and Simulation of the
IEEE 1588 PTP Clock," in ICECE, 2011, pp. 4602-05.
[10] I. Hadzi6, D. R. Morgan, Z. Sayeed, "A Synchronization Algorithm for
Packet MANs," IEEE Trans. on Communications, vol. 59, no. 4, pp.
1142-53, Apr. 20II.
[II] S. B. Moon, P. Skelly, D. Towsley, "Estimation and Removal of Clock
Skew from Network Delay Measurements," in INFOCOM, 1999, pp.
227-34.
[12] I. Hadzi6, D. R. Morgan, "Adaptive Packet Selection for Clock
Recovery," in ISPCS, 2010, pp. 42-47.

83