ClockSynchronization.md 3.17 KB
Newer Older
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Clock Synchronization
========================

This document outlines the XML representation of clock synchronization, as defined by the IEEE XMPP IoT Working Group. The XML representation is modelled using
an annotated XML Schema:

| Sensor Data                                                     ||
| ------------|----------------------------------------------------|
| Namespace:  | urn:ieee:iot:synchronization:1.0                   |
| Schema:     | [Synchronization.xsd](Schemas/Synchronization.xsd) |


Motivation and design goal
----------------------------

The method of clock synchronization described hee, is designed with the following goals in mind:

* Entities are connected *ad hoc* in a global federated network.

* It should be possible for each entity in the network to estimate the difference of its internal clock with respect to the internal clock of any other entity
to a relative high degree of accuracy.

* The method should allow for varying latency in the network.

* The method should allow for varying latency between different nodes in the network.


Process
------------------------

The Synchronization namespace only defines one simple element: `clock`, which is an element of the simple type `xs:dateTime`. The client sends its time
Peter Waher's avatar
Peter Waher committed
32 33
(in UTC) ct<sub>1</sub> to the clock source, who immediately responds with a `clock` element of its own, with its time (in UTC) st. When the client receives the response,
it notes its own time again (in UTC) ct<sub>2</sub>.
34 35 36

![Clock Synchronization](Diagrams/Synchronization.png)

Peter Waher's avatar
Peter Waher committed
37 38 39
Δt<sub>1</sub>=st-ct<sub>1</sub> is given variation in the network and operating system processes approximately
equal to the latency in the network l plus the difference between the client and souce clocks Δt. The response, which travels in the other direction, can be used to
to calculate Δt<sub>2</sub>=ct<sub>2</sub>-st which is approximately equal to the latency in the network l minus the difference between the client and souce clocks Δt.
Peter Waher's avatar
Peter Waher committed
40 41
The latency l is therefore approximately half of Δt<sub>1</sub>+Δt<sub>2</sub>. The difference in clocks Δt is approximately half of Δt<sub>1</sub>-Δt<sub>2</sub>.

Peter Waher's avatar
Peter Waher committed
42 43 44
To decrease the variation of network and process activity, an average value over a time window should be used. The internal clocks of the client and server can be
considered much more stable than the latency in the network. The bulk of the variance in the measured l and Δt can therefore be attributed to variance in the network,
as well as concurrent processes and loads on the client and clock source.
45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62

Examples
------------------

A simple clock difference request can look as follows:

	<iq type='get' id='3' to='source@server/resource'>
		<clock xmlns='urn:ieee:iot:synchronization:1.0'>2018-07-01T12:31:07.1627163Z</clock>
	</iq>

The source responds:

	<iq id='3' type='result' to='client@server/resource' from='source@waher.se/resource'>
		<clock xmlns='urn:ieee:iot:synchronization:1.0'>2018-07-01T12:31:07.2642974Z</clock>
	</iq>

**Note**: The `xs:dateTime` data type allows for arbitrary resoulution of the seconds part. In this example, a resolution of 100 ns has been used,
conforming to the capabilities of systems having an on-board high-resolution clock.