Are we on time?

Time synchronization is a crucial component of modern, digital networks such as LTE/5G mobile networks, smart grid transportation networks, or motion-controlled networks used in robotics or distributed printing. When properly synchronized, all network and transmission devices will operate at the correct time and correct order at accuracy measured in nanoseconds.

It is Coordinated Universal Time (UTC), formerly known by many as Greenwich Mean Time (GMT), that would be used as a world primary time standard to which all clocks should be synchronized and as such would provide the same time of the day. The following are two common ways to obtain the precision time to the telecommunication networks:

1. the direct use of on-premises appliance-based atomic clock deployed with quartz and/or rubidium oscillator and UTC synced through GNSS (Global Navigation Satellite System) connectivity
2. GNSS based reference clock delivered through an SFP with a built-in GNSS receiver pluggable to a network node As such, this device (appliance or network node above mentioned) becomes a reference clock for the whole or partial network to which clocks of all other network elements will be synchronized.

Before describing the mechanism of synchronization of various clocks in the network let stake a look at different types of clocks as defined by the PTP protocol. The “clock” itself refers to every node in the network “participating in the PTP that is capable of providing a measurement of the passage of time”.

A clock that we have already described as the one to provide the time reference for the whole or partial network (PTP domain) is called a Grandmaster (or Master) clock (MC). Slave clock (SC), on the other hand, is the clock that is being synchronized by the Grandmaster clock. Both mentioned clocks are referred to as Ordinary clocks (OC), clocks with a single PTP port within a domain.

Boundary clock, on the other hand, has multiple PTP ports in a domain and as such may serve as a Master clock and Slave clock.

Transparent clock (TC) has neither master nor slave role in the network but is capable to measure the time for PTP message to transit the node and providing this info to the node receiving this PTP message in order for this “delay” to be taken into account.

Synchronization of boundary and slave clocks in the PTP domain to the master clock is taking place in several phases.

Best Master Clock Mechanism At first, each clock in the network has to choose the best master for itself through the Best master clock mechanism. Each master clock is defined by the set of attributes such as clock class, accuracy, stability, and, in addition, administratively defined priorities. Every clock continuously compares, in a specific order, these attributes as received from two or more master clocks to select the best one to which it will be synchronized. As the result, all PTP ports of a clock will be either in Master, Slave, or Passive (neither Master nor does it sync to a master) state.

As a result, a master-slave clock hierarchy will be established in the network.

Delay request-response mechanism Synchronization of the ordinary or boundary clocks is performed by exchanging PTP messages on the path between two clocks (master and slave), recording and sharing times when those messages were sent/received and calculating timing offset and path delays between master and slave.

As seen in Picture 4 the master sends a Sync message to the slave with t1, the time when Sync message was sent from the master stamped within. Another implementation could send t1 timestamp in a separate message called Follow_Up. The slave receives Sync message at time t2, and calculates propagation time from master to itself as t2-t1. Furtherafter, the slave sends Delay_Req message at recorded time t3. Upon receiving this message at time t4, the master responds to the slave with Delay_Resp message sharing time t4 with the slave. Times t3 and t4 are used by the slave to calculate propagation time from the slave to the master which might be different from the firstly calculated propagation time from the master to the slave with times t1 and t2. Upon periodically exchanging above mentioned messages slave clock is capable of computing the offset from the master clock and propagation time between master and slave clocks. This implementation is called delay request-response mechanism.

The peer delay mechanism

Opposite to the delay request-response mechanism in which link propagation time measurement is initiated by slave upon receiving Sync message from the master, peer delay mechanism independently measures the link propagation time between two PTP nodes. In order for clock 1, Port 1 to compute propagation delay between port 1 and port 2 it initiates Pdelay_Req message. Port 2 will record the time t2 upon this message was received and will initiate Pdelay_req message at time t3. Both times, t2 and t3 (or the difference between t3 and t2) will be sent to Port 1 within Pdelay_req message (or Pdelay_Resp Follow up message). With recorded time t4 of received Pdelay_Resp message, Port 1 has all information needed to calculate link propagation time between two ports and use it in the calculation when computing the clock offset.

Transparent clock

We have already mentioned Transparent clock (TC), a node that is neither master nor slave. As transparent clocks are physically positioned in the network on the path between master and slave (see Picture 2) they, as well as any other node for that matter, introduce delay to a packet on its path during the time it is processed within a node, between an ingress and egress port. Transparent clocks have however the capability to measure this residence time PTP packet spend in the node, and relay it within PTP event message towards slave clock to take it into calculation for more accurate synchronization. If there are more transparent clocks on the path between master and slave clock transition times are accumulated within PTP message.

Based on the synchronization process transparent clocks are divided into two groups: end-to-end (E2E) transparent clocks that implement delay request-response and peer-to-peer (P2P) transparent clocks that implement peer delay mechanisms. As required by peer delay mechanism P2P transparent clocks have an additional capability of measuring link propagation time which is also added into PTP message along with residence time.

PTP Design and support

Implementation of PTP protocol today in modern telecommunication networks is necessary weather it is a deployment of mission- critical transportation network or telecom LTE network for instance. In addition to a wide range of supported protocols and technologies, their support for both E2E and P2P transparent clocks make them ideal choice for building a robust and secure access network layer of networks that could not experience even a slightest degradation of time synchronization between master and slave clocks.

In the following example of a transportation network core, access and edge network layers are build on Nokia IP/MPLS technology providing also PTP supported clocks such as master and boundary clocks. In order for LTE units that act as slave clocks to be fully synchronized with master clocks access layer is built with specific OmniSwitch nodes providing full support for IP technology and transparent clock mechanisms as described in this article.