Synchronization with IEEE 1588 PTP. Terasync. Part 3

Considerable efforts were made in order to adopt the PTP for the synchronization of telecom networks. IEEE 1588 version 2 was developed with the changes that were supposed to increase the synchronization quality to the levels that will be acceptable for the telecom (sub-microsecond). Extensive testing of the solutions based on this protocol was performed by the major equipment vendors in the last few years.

However, there is no mass adoption of this protocol in the market as an actual working solution that provides sub-microsecond phase accuracy. It simply fails to perform adequately in too many scenarios. PTP was originally designed for use in a dedicated network with a specialized hardware, which is different from the hardware that is used for the general-purpose networks worldwide.

Some of the reasons for the performance problems are described below.

One of the basic assumptions for the protocol is that there is a hardware time-stamping mechanism in every network node, and this node serves as a "boundary clock". In this way the different delay is accounted for when propagating between the nodes. This assumption is not true in the existing networks, and it is unlikely that the current infrastructure will be replaced just to support this specific function.

Another assumption is the symmetric delay between the master and the slave clocks. This is obviously not true for the existing cloud type of networks, where theoretically every packet can go by a different route, thus rendering this assumption invalid. When the path is asymmetric, a constant time error is introduced. Furthermore, as the routes vary, this time error also changes, adding to the channel delay variation. Although this issue can be mitigated with MPLS, there is no immediate solution that makes this problem to go away completely.

As the assumptions mentioned above are not correct, the PDV of the protocol synchronization packets is high as in any packet network, as we’ve already discussed. Therefore, the synchronization algorithm must be designed in order to overcome this variation, which brings us back to the root of the problem - the lack of an appropriate theoretical model.

Anyway, even if some practical model valid for a specific network is assumed (as is done in the industry), the algorithm still requires processing of the PDV for a long time – in order of magnitude of tenth of  minutes or even more. In order to be successful with this analysis, a local oscillator that is stable for this period of time is needed, and it means that using of a high quality oven controlled quartz oscillator is mandatory. Such oscillator is very expensive, it costs about two orders of magnitude more than a simple uncompensated quartz crystal, so the price of every node increases drastically.

Using of lower quality oscillator and shorter analysis time leads to increase of numbers of situations where the performance will be insufficient.

Additionally, there is no security mechanism in the protocol. The data is transferred as unencrypted UDP packets over IP, and anyone can spoof the network with bogus packets, thus disrupting or taking control over the synchronization.

It is well-known already that the possible use of PTP protocol for the telecom synchronization is limited. It can be and is used for synchronization of FDD scheme, as the complexity in this case is minimal. But the inherent problems described above make PTP perspectives for TDD synchronization obscure. Obviously it can be used with a limited number of hops, but there is a problem to define this limit. There are reports of the various equipment vendors about successful experiments, but the test conditions are usually too artificial, and the ability for expanding the use in a broader scope is questionable.