Five Minute Facts About Packet Timing
By Doug Arnold.
The Precision Time Protocol Telecom Profile for Frequency Synchronization was created by International Telecommunication Union, or ITU, for the transferring precise frequency through a packet switched network which does not have any support for PTP. Don’t let the name fool you though, you can transfer time as well as frequency with this profile.
Lets look at the name. It is a profile of IEEE 1588. It is developed for telecommunications, but has been used in other systems as well, for example power grids, which have traditionally made use of telecom network technology to connect all of the sub-stations to the monitoring and control centers. Why does the title indicate only frequency transfer when it could be used for time transfer? The answer is that the ITU committee which specified the profile realized that the ability to transfer time with an accuracy on the order of 1 us is limited when the switches and routers do not have PTP support. Typically time transfer accuracy on the order of 1us can be achieved through about five busy routers/managed switches when these devices lack PTP support, i.e. they are not boundary clocks or transparent clocks. Some typical telecom applications are shown below.
Figure 2. PTP synchronizing small cells
The details of the profile are described in the document G.8265.1, which is available at the agreeable price of free from the ITU. The profile exclusively uses unicast mode PTP, and end to end delay measurement. All messages are sent as UDP/IP packets. The only allowed device types are ordinary clocks which are either always slaves or always masters. For many telecom applications they would rather get a fault condition than allow one of the slaves to try to synchronize the network. The allowed values of message rates are shown below.
|Message||Minimum rate||Maximum rate||Negotiated grant interval|
|Announce||1 every 16 seconds||8/second||60-1000 seconds (default 300)|
|Sync||1 every 16 seconds||128/second||60-1000 seconds (default 300)|
|Delay Request||1 every 16 seconds||128/second||60-1000 seconds (default 300)|
Note that the message rates are much higher than is normally employed in PTP networks. The reason is the assumption that connecting devices are switches and routers which do not have PTP support. In such devices sync messages and delay request messages often sit in queues. If the queuing delay in one direction is shorter than another direction, this results in an error in the calculated difference between the master and slave clocks. To overcome this Telecom Profile slaves sort through many sync and delay request messages to find the “lucky packets” with little or no queuing delay. Such non-linear servo-loop filters are critical since the delay variation through a network tend to look like the probability density below.
Figure 3. Distribution of delays through a network with queuing
Note that the highly queued packets can have a delays which are an order of magnitude longer than ones with little of no queuing. For this reason slaves do not want to simply average the delays, since the unlucky packets which give the worst measure of the master slave clock difference would dominate the average. So the reason for the large message rates is to make sure that there will be some which do not experience a lot of queuing delay which the slave servo algorithm can make use of.
The ITU is currently at work on a profile for time transfer where it is assumed that all switches and routers in between the master and slave include PTP support. When the infrastructure gets to the point where this is true, then it will be easier to achieve precise time transfer. In the mean time keep looking for those lucky packets.