Six facts you should know about synchronization
The evolution of the mobile network and the ever-increasing demand for bandwidth are forcing operators to migrate their infrastructures to packet-based technology. This type of network infrastructure brings significant advantages, as well as numerous challenges. One of the challenges confronting mobile operators is the need to provide accurate synchronization to the base station in order to ensure proper hands-off calls, minimize dropped calls and provide proper billing.
The complexity of today’s network topology makes the deployment of synchronization very complicated, especially considering that it is affected by the configuration and number of switches, routers and other network elements that it must go through before reaching its destination.
The only way to prevent synchronization issues is to ensure that the network is properly built to carry the synchronization scheme, and this can only be achieved by testing the network during construction and deployment of synchronization services. The list below details some of the most important elements in synchronization networks.
- The major issue with PTP: It’s packet-based
As the synchronization packets used by precision time protocol (PTP) are forwarded within the network between the grand master and hosts, they are subject to all network events, including delay (latency), delay variation (packet jitter) and frame loss. Despite the best practice of applying high priority to synchronization flows, these synchronization packets will still experience congestion, in addition to possible routing and forwarding issues such as out-of-sequence packets and route flaps. This can have a serious impact on the synchronization signal generated by the clients, degrading the sync signal over time.
- PTP client vendors use a proprietary algorithm to generate the output clock
A major dependency for PTP slave performance is the algorithm used to synthesize the output clock. Typically, slave clocks will selectively use some packets for clock adjustments in order to avoid high variations in the clock output. Since each algorithm is proprietary, performance can vary for the same network conditions. This means that the synchronization generated by the client on the same network may differ from one vendor to another. It is therefore imperative to validate that the sync signal is within specifications prior to deploying it.
- PTP is not only about the “packet”
Although PTP is packet-based and the synchronization traffic is contained in the packets carried through the IP network, its ultimate goal is to provide a clock signal. The clock output from the PTP client is an analog signal. The metrics used to characterize that signal are not packet metrics such as delays, delay variations and bandwidth. Instead, metrics such as wander are used to validate the quality of the signal.
- The only way to see all sync issues is through long-term monitoring
As synchronization is deployed in the network, continuous monitoring is required due to the fact that network synchronization stability decays over time. Moreover, critical metrics such as wander only occur and become meaningful over a long period of time. Synchronization monitoring is necessary in order to monitor the health of the synchronization mechanism over the network, and to ensure quick and efficient reaction to synch failures within the network.
- The reference clock used is critical for accurate sync measurement
Measuring synchronization accuracy is almost entirely dependent upon the offset between significant events of the tested signal as compared to the same significant event of the reference clock. Accordingly, a key aspect of testing synchronization is the accuracy of the reference clock given that the measurement can only be as precise as the reference clock.
- SyncE requires all ports on the link to be enabled for SyncE
SyncE is a physical synchronization scheme in which synchronization is carried over the physical layer. The synchronization information is carried from port to port, and therefore requires that all ports on the synchronized path are enabled for SyncE. Any node on the path that is not SyncE-enabled will automatically break the synchronization from this node. This is an issue for network providers with a multitude of Ethernet ports between the primary synchronization unit and the edge device requiring synchronization, because all of the ports must be SyncE-enabled in order to synchronize to the edge.
If you are interested in learning more about synchronization, read the PTP Test Applications application note.
