The ITU has now formally approved the first version of G.8273.4, the standard defining the performance of the Partial Timing Support (PTS) clocks. This is an important milestone in the development of this technology.

So what is a Partial Timing Support clock? The PTP protocol defines two functions, “boundary clocks” and “transparent clocks”, to help deal with variable delays through the network. In a packet network, all packets are subject to delay as they pass through the network. This delay is caused by waiting for transmission in nodes as they pass through the network, and varies from packet to packet. This is known as “packet delay variation” or PDV.

This much like cars on a road network – at some junctions, the traffic lights will be green and the car can keep moving, at others, a red light means the car has to wait in a queue until the light turns green again. In a packet network, a boundary clock is equivalent to stopping the clock when the car arrives at a junction, and starting it again when it leaves. A transparent clock doesn’t stop the clock, but it measures the time spent queuing at the junction, so that at the end of the journey the total time spent queuing is known.

You may also like ...
	New standards and profiles are defining Assisted Partial Timing Support (APTS) and Partial Timing Support (PTS). Whether you are in the planning, deployment or optimization phase of APTS and PTS, use our Field Test Plan to get you seamlessly through your journey.

Up to now, the standards have concentrated on the case where all nodes in the network contain either a boundary clock or transparent clock function. This mean that all nodes in the network (i.e. switches or routers) have to contain that function. We call this being “PTP-aware”. However many networks do not contain PTP-aware nodes, and operators don’t want to have to swap out all their equipment to replace it with PTP-aware equipment.

Partial Timing Support clocks are the solution to this. They are capable of handling the PDV generated by PTP-unaware nodes. While clocks with this functionality have been available for some years and are already being deployed in the network, it is only now that the performance requirements of these clock type has been standardised. This will be welcome news to operators who have been struggling to deploy this technology, and haven’t had an appropriate reference standard to rely on. The release of this standard allows them to test to known limits and verify that the equipment they are deploying will meet their needs.

Tim Frost
Strategic Technology Manager