Basic Principles of 1588 ACR

1588 ACR aims to synchronize frequencies of clock clients (clients) with those of clock servers (servers).

1588 ACR sends Layer 3 unicast packets to establish a clock link between a client and a server to exchange 1588v2 messages. 1588 ACR obtains a clock offset by comparing timestamps carried in the 1588v2 messages, which enables the client to synchronize frequencies with the server.

Process of 1588 ACR Clock Synchronization

1588 ACR implements clock (frequency) synchronization by adjusting time differences between the time when the server sends 1588v2 messages and the time when the client receives the 1588v2 messages over a link that is established after negotiations. The detailed process is described as follows:

1588 ACR clock synchronization is implemented in two modes: one-way mode and two-way mode.

One-way mode
Figure 1 Clock synchronization in one-way mode
1. The server sends the client 1588v2 messages at t1 and t1' and time-stamps the messages with t1 and t1'.
2. The client receives the 1588v2 messages at t2 and t2' and time-stamps the messages with t2 and t2'.
t1 and t1' are the clock time of the server, and t2 and t2' are the clock time of the client.

By comparing the sending time on the server and the receiving time on the client, 1588 ACR calculates a frequency offset between the server and client and then implements frequency synchronization. For example, if the result of the formula (t2 - t1)/(t2' - t1') is 1, frequencies on the server and client are the same; if not, the frequency of the client needs to be adjusted so that it is the same as the frequency of the server.
Two-way mode
Figure 2 Clock synchronization in two-way mode
1. The server clock sends a 1588 sync packet carrying a timestamp t1 to the client server at t1.
2. The client server receives a 1588 sync packet from the server clock at t2.
3. The client clock sends a 1588 delay_req packet to the server clock at t3.
4. The server clock receives the 1588 delay_req packet from the client clock at t4, and sends a delay_resp packet to the slave clock.

The same calculation method is used in two-way and one-way modes. t1 and t2 are compared with t3 and t4. A group of data with less jitter is used for calculation. In the same network conditions, the clock signals with less jitter in one direction can be traced, which is more precise than clock signal tracing in one direction. The two-way mode has a better frequency recovery accuracy and higher reliability than the one-way mode. If adequate bandwidth is provided, using clock synchronization in two-way mode is recommended for frequency synchronization when deploying 1588 ACR.

Layer 3 Unicast Negotiation Mechanism

Layer 3 unicast negotiations can be enabled to carry out 1588 ACR frequency synchronization as required. The principle of Layer 3 unicast negotiations is as follows:

A client initiates a negotiation with a server in the server list by sending a request to the server. After receiving the request, the server replies with an authorization packet, implementing a 2-way handshake. After the handshake is complete, the client and server exchange Layer 3 unicast packets to set up a clock link, and then exchange 1588v2 messages over the link to achieve frequency synchronization.

Dual Server Protection Mechanism

1588 ACR supports the configuration of double servers. Dual server protection is performed as follows:

After triggering a negotiation with one server, a client periodically queries the negotiation result. If the client detects that the negotiation fails, it automatically negotiates with another server. Alternatively, if the client successfully synchronizes with one server and detects that the negotiation status changes due to a server failure, the client automatically negotiates with another server. This dual server protection mechanism ensures uninterrupted communications between the server and the client.

When only one server is configured, the client re-attempts to negotiate with the server after a negotiation failure. This allows a client to renegotiate with a server that is only temporarily unavailable in certain situations, such as when the server fails and then recovers or when the server is restarted.

Duration Mechanism

On a 1588 ACR client, you can configure a duration for Announce, Sync and delay_resp packets. The duration value is carried in the TLV field of a packet for negotiating signaling and sent to a server.

Generally, the client sends a packet to renegotiate with the server before the duration times out so that the server can continue to provide the client with synchronization services.

If the link connected to the client goes Down or fails, the client cannot renegotiate with the server. When the duration times out, the server stops sending Sync packets to the client.