The PTP Telecom Profiles for

Frequency, Phase and Time

Synchronization

Tim Frost
Symmetricom, Inc.,
May 2013

Confidential Copyright 2013

Agenda
Introduction to Precision Time Protocol (PTP)

PTP Messages
Impairments to Packet Timing
Timing Support Elements (boundary and transparent clocks)
PTP Profiles

PTP Telecom Profile for Frequency (G.8265.1)

Objectives and Design Features

Source Traceability
Multicast vs. Unicast messages
Rate of Timing Messages
Master Selection and Protection

PTP Telecom Profiles for Time and Phase

Full Timing Support (G.8275.1)
Partial Timing Support (G.8275.2)
Confidential Copyright 2013

Introduction to Precision Time Protocol (PTP)

Confidential Copyright 2013

What is the Precision Time Protocol (PTP)?

Protocol for distributing precise time and
frequency over packet networks
Defined in IEEE Standard 1588
First version (2002) targeted LAN applications
Second version (2008) expanded applicability
to cover telecommunications networks
Third version now under discussion

Time is carried in event messages

transmitted from a Grandmaster Clock to a
Slave Clock and vice versa
Runs over Ethernet and/or IP networks
Commonly referred to as:
PTP (Precision Time Protocol) or PTP v.2
IEEE1588-2008 or IEEE1588 v.2
Confidential Copyright 2013

Precision Time Protocol (PTP)

PTP defines an exchange of timed messages over a packet network
Master Clock Time

Slave Clock Time

Sync message

t1

Follow_Up message
containing accurate
value of t1 (if required)

Data at Slave
Clock
t2

(t1), t2

t 1, t 2
Delay_Req message

t3

t 1, t 2, t 3

Delay_Resp message
containing value of t4

Confidential Copyright 2013

Master frequency determined by comparison

of timestamps in the event message flows
e.g. comparison of t1 to t2 over multiple sync
messages, or t3 to t4 in delay_req messages

Time offset calculation requires all four

timestamps:
Slave time offset = (t1 t2) + (t4 t3)
2
assumes symmetrical delays
(i.e. the forward path delay is equal to the
reverse path delay)

t4

time

Each event message flow (sync, delay_req)

is a packet timing signal

Time offset error = fwd. delay rev. delay

2
t 1, t 2, t 3, t 4

Packet Timing Impairments

Network Stack

PTP

PTP

UDP

UDP

IP

Timestamp
generation

Ethernet

Hardware timestamp
generation eliminates
protocol stack delays

Timestamp
generation

IP
Ethernet

Physical

Network Stack

Slave Clock

Master Clock

Physical

Network

Confidential Copyright 2013

Receive
queue

Receive
queue

Receive
queue

Transmit
queue

Transmit
queue

Transmit
queue

Switching
Element

Switching
Element

Switching
Element
6

Boundary Clock
PTP Boundary Clock
Switch/Router
Local Clock

PTP
Slave

PTP
Master
Switch function

PTP messages

PTP messages

A router or switch that contains an embedded PTP slave and PTP

master, linked to the same local clock
The PTP slave terminates the PTP traffic from the PTP
Grandmaster, and synchronizes its local clock to the GM
This local clock is used in turn to drive a new PTP master function
Confidential Copyright 2013

End to End Transparent Clocks

PTP E2E Transparent Clock
Switch/Router
Residence Time Bridge

Modify
correction
field

Switch function

PTP messages

Arrival Time

PTP messages

Departure Time

Measures time of packet arrival and packet departure

Adds the difference (known as residence time) to a correction
field in the packet header
At the slave, the value of the correction field represents the
total delay in each of the switches along the route
Confidential Copyright 2013

Peer to Peer Transparent Clocks

nsparent Clock
h/Router

Peer-to-Peer
messages

PTP P2P Transparent Clock

Switch/Router

Time Bridge

Peer-to-Peer
messages

PTP P2P Trans

Switch/R

Residence Time Bridge

function

Residence Tim

Switch function

PTP sync messages

Departure Time

Arrival Time

Switch fun

PTP sync messages

Departure Time

Arrival Time

Peer to peer messages measure the round trip link delay

Link delay and residence time added to the correction field
At the slave, the value of the correction field represents the
total delay from master to slave
Doesnt require delay_request/response messages
Confidential Copyright 2013

What is a PTP Profile?

What is a profile?
Profiles were introduced in IEEE1588-2008, to allow other standards
bodies to tailor PTP to particular applications
Profiles contain a defined combination of options and attribute
values, aimed at supporting a given application
Allows inter-operability between equipment designed for that
purpose

PTP Telecom Profile for Frequency (G.8265.1) published Oct. 2010

Supports frequency synchronization over telecoms networks
Main use-case is the synchronization of cellular basestations

The G.8265.1 PTP Telecom Profile enables the deployment of

PTP-based frequency synchronization by telecoms operators
Confidential Copyright 2013

10

PTP Telecom Profiles for Time/Phase

ITU working on two new PTP Telecom Profiles:
G.8275.1 Full Timing Support
G.8275.2 Partial Timing Support

Both profiles target accurate time/phase distribution

G.8275.1 is aimed at new build networks
Requires boundary clocks at every node in the network

G.8275.2 is aimed at operation over existing networks

Permits boundary or transparent clocks, but not required
Boundary clocks placed at strategic locations to reduce noise

Main target use case is the time/phase requirements of mobile

cellular TDD and LTE-A systems
Target accuracy is time synchronization to within 1.5s
Confidential Copyright 2013

11

The PTP Telecom Profile for Frequency (G.8265.1)

Confidential Copyright 2013

12

Prime Objectives
To permit the distribution of frequency using PTP over existing
managed, wide-area, packet-based telecoms networks
To allow interoperability with existing synchronization networks
(such as SyncE and SDH)
To define message rates and parameter values consistent with
frequency distribution to the required performance for telecom
applications
To allow the synchronization network to be designed and
configured in a fixed arrangement
To enable protection schemes to be constructed in accordance
with standard telecom network practices

Confidential Copyright 2013

13

Key design decisions

No on-path support, (e.g. boundary and transparent clocks),
because these are not generally available in existing networks
IPv4 was adopted as the network layer due to its ubiquity, rather
than operation over Ethernet or other lower-layer protocols
The PTP Announce message was adapted to carry the Quality
Level (QL) indications defined in G.781, for continuity with
SONET/SDH and SyncE synchronization status messaging.
Unicast transmission was adopted over multicast, since it could
be guaranteed to work over wide-area telecoms networks
BMCA (Best Master Clock Algorithm) was replaced by static
provisioning, allowing the synchronization flow to be planned,
rather than dynamically adjusting itself
Confidential Copyright 2013

14

Source Traceability
Encodes QL values in the clockClass field of the Announce message
Provides end-to-end traceability of the reference source along the
synchronization chain
Informs the slave clock (and subsequent devices) of the quality of the
timing source
Allows the timing chain to be managed in a similar way to existing
synchronization networks
End-to-End Source Traceability
SSM: QL-PRC [0010]

clockClass: QL-PRC [84]

PTP
GM
PRC

Physical Layer
Synchronization Network

Confidential Copyright 2013

PTP
Grandmaster

SSM: QL-PRC

PTP
Slave
Packet Network

PTP Slave

End
Equipment
15

Multicast vs. Unicast

Unicast facilitates the use of distributed masters
Each master-slave communication path becomes a separate PTP
domain
Allows easier planning of the synchronization network
Redundancy strategy can be carefully managed

Unicast packets propagate uniformly through the network

Multicast requires packet replication at each switch or router
Replication process adds variable delay

Multicast harder to provision for network operators

Upstream multicast often not supported in telecom networks

Confidential Copyright 2013

16

Unicast Registration
Master only provides Unicast service

Master

Slave

No multicast announce messages sent

Slave is manually configured with the IP

address of one or more masters
Slave requests Master to provide unicast
service at a specified rate
Requests Announce service first, to verify
quality of the master
If within capacity limits, Master responds
with service grant acknowledgements
Slave requests Sync and Delay_Request
service only if master quality is sufficient

Grants are limited duration

Requests must be periodically repeated
Frees up master resources if slave fails
Confidential Copyright 2013

17

Rate of Timing Messages

The rate of timing messages required is dependent on several factors
Amount of noise in the network

Local oscillator stability

Efficiency of clock servo algorithm

The Telecom Profile defines the range of message rates Masters and
Slaves should support
Message rates

Minimum

Maximum

Default

Announce

1 msg. every 16s

8 messages/s

1 msg. every 2s

Sync

1 msg. every 16s

128 messages/s

Not defined

Delay_Request

1 msg. every 16s

128 messages/s

Not defined

It is not expected that a slave will achieve the required performance at

all message rates
Slave must request the message rates needed to maintain performance
Confidential Copyright 2013

18

Packet Timing Signal Fail

Profile defines three types of signal failure:
PTSF-lossAnnounce, where the PTP Slave is no longer receiving
Announce messages from the GM
This means there is no traceability information for that master
Slave should switch to an alternative GM after a suitable timeout period

PTSF-lossSync, where the PTP Slave is no longer receiving timing

messages from the GM (i.e. Sync or Delay_Response messages)
This means there is no timing information for that master
Slave should switch to an alternative GM after a suitable timeout period

PTSF-unusable, where the PTP Slave is receiving timing messages

from the GM, but is unable to recover the clock frequency
This means there is no recoverable timing information for that master
Action is undefined
Confidential Copyright 2013

19

Master Selection and Protection

Telecom slave clock consists of several logical protocol instances,
each communicating with a different grandmaster
Selection process follows G.781 selection rules:
Availability, Traceability, Priority
PTP GM
1

PTP GM
2

PTP GM
N
Confidential Copyright 2013

Telecom
Slave Clock

Slave
Protocol
Instance 1

Slave
Protocol
Instance 2

Packet
Network

Slave
Protocol
Instance N
Separate PTP domains

G.781based
Master
Selection
Process

List of N
Grandmasters
20

Additional Protection Functions

Non-reversion function
Disables automatic reversion to original master after fault has been rectified

Wait-to-Restore Time
Defines the waiting period before switching back to the original highest priority
master, once the failure condition has been rectified

Forced traceability
If the PTP GM is connected to a reference by a signal with no SSM QL value, the
input can be manually forced to a suitable value

Output QL Hold-Off
Defines a waiting period following a change of QL in the incoming PTP
clockClass before forwarding to downstream equipment
Allows time for synchronization to a new reference

Output Squelch
Output clock signal of a PTP slave should be squelched in case of holdover
Only applies to signals that do not carry a QL value (e.g. a 2.048MHz unframed
timing signal)
Confidential Copyright 2013

21

The PTP Telecom Profiles for Time and Phase

Confidential Copyright 2013

22

Reference Points for Packet Timing (G.8271)

Reference
Point
A

Reference
Point
B

Reference
Point
C

PTP
GM

PRTC

PTP
Grandmaster

Reference
Point
D

Reference
Point
E

PTP
Slave

Packet Network

PTP Slave

End
Equipment

Packet Timing System

A: Time accuracy and stability at output of PRTC (defined in G.8272)

B: Packet timing interface at output of PTP GM
C: Packet timing interface at input to PTP Slave (defined in G.8271.1)
D: Time accuracy and stability to end application (defined in G.8271.1)
E: End application requirements (e.g. air interface time/frequency spec.)
Confidential Copyright 2013

23

G.8275.1 Full Timing Support Profile

Uses a boundary clock at every node in the chain between PTP
Grandmaster and PTP Slave
Reduces time error accumulation through the network
Boundary clocks defined with a filter bandwidth of 0.1Hz

Recommends the use of Synchronous Ethernet to syntonize each

boundary clock to a stable frequency
Defines Sync and Delay_Request message rate of 16 messages/s
Operates over a Layer 2 Ethernet network
Uses the Ethernet addresses identified in IEEE1588-2008 Annex F
Support of unicast IP has been proposed but not agreed (yet?)

Supports multiple active grandmasters for redundancy

Confidential Copyright 2013

24

Hypothetical Reference Model

Up to 10 BCs in a chain

Time Plane

Time reference
(PRTC)
PTP GM

PTP

EEC
SyncE

PTP BC
EEC
SyncE

PTP

PTP BC

PTP

EEC
SyncE

End Application
(e.g. eNodeB)
PTP BC
EEC
SyncE

PTP

PTP TSC
EEC
SyncE

SyncE
frequency
distribution
networks

PRC
frequency
references
[PRCs may be separate or common]

Confidential Copyright 2013

Frequency Plane
25

Time Error Budget (G.8271.1)

Reference Points:

A, B

100 ns
(network asymmetry compensation)

D
400 ns
(holdover budget)

E
150 ns
(end equip.)

200 ns
(dynamic time error)

550 ns constant time error

(50 ns per node, 10 BCs + 1 slave)

100 ns
(PRTC)

Confidential Copyright 2013

1.5 s end-to-end budget

26

Component Recommendations
G.8271: Time and Phase Synchronization Aspects of Packet Networks
General aspects and concepts
Requirement categories (based on external standards, e.g. 3GPP)

G.8271.1: Network Limits for Time Synchronization in Packet Networks

Network performance limits at packet interfaces

G.8272: Primary Reference Time Clock (PRTC) Specification

Basic requirement: 100ns accuracy to UTC
Jitter/wander based on PRC specification (G.811)

G.8273.2: Telecom Boundary Clock (T-BC) Specification

Transfer function and model
Noise generation and tolerance

G.8275: Architecture for Time/Phase Distribution

Placement of boundary clocks and protection strategies

G.8275.1: Precision Time Protocol (PTP) Telecom Profile for

Time/Phase Synchronization
PTP Profile based on use of boundary clocks at every node

Confidential Copyright 2013

27

G.8275.2 Partial Timing Support Profile

Why a second time/phase profile?
Some service providers need to operate time/phase synchronisation over
existing networks
Reduces barriers to entry into LTE-A systems; dont need to build an
entirely new network
Allows operation over 3rd party network providers (given appropriate
quality guarantees)

Result: Partial Timing Support Profile

New ITU work item requested by four large service providers
Expected to be published in 2014

Key features:
Operates over existing switches and routers, using unicast IP
Uses boundary or transparent clocks where necessary to clean up time
signal as it passes through the network
Supports multiple active grandmasters for redundancy
Confidential Copyright 2013

28

For Further Reading

White Paper:
Synchronization for Next Generation Networks The PTP Telecom Profile, Symmetricom White Paper, April 2012

Primary References:
IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems, IEEE Std.
1588TM-2008, 24 July 2008
Precision Time Protocol Telecom Profile for Frequency Synchronization, ITU-T Recommendation G.8265.1, October 2010

Background Reading:
Synchronization Layer Functions, ITU-T Recommendation G.781, August 2008
Definitions and terminology for synchronization in packet networks, ITU-T Recommendation G.8260, August 2010
Timing and synchronization Aspects in Packet Networks, ITU-T Recommendation G.8261, April 2008
Architecture and Requirements for Packet-Based Frequency Delivery, ITU-T Recommendation G.8265, October 2010
Time and Phase Synchronization Aspects of Packet Networks, ITU-T Recommendation G.8271, February 2012
Timing characteristics of Primary Reference Time Clocks (PRTC), ITU-T Recommendation G.8272, November 2012

Under Development:
Network Limits for Time Synchronization in Packet Networks, ITU-T Draft Recommendation G.8271.1 (exp. Sep. 2013)
Timing characteristics of Telecom Boundary Clocks (T-BC), ITU-T Draft Recommendation G.8273.2 (exp. Sep. 2013)
Architecture for Time/Phase Distribution, ITU-T Draft Recommendation G.8275 (exp. Sep. 2013)
Precision Time Protocol (PTP) Telecom Profile for Time/Phase Synchronization using Full Timing Support, ITU-T Draft
Recommendation G.8275.1 (exp. Sep. 2013)
Precision Time Protocol (PTP) Telecom Profile for Time/Phase Synchronization using Partial Timing Support, ITU-T Draft
Recommendation G.8275.2 (exp. 2014)
Confidential Copyright 2013

29

Thank You
Tim Frost
Principal Technologist,
Symmetricom, Inc.
Email: tfrost@symmetricom.com

Symmetricom, Inc.
2300 Orchard Parkway
San Jose, CA 95131-1017
Tel: +1 408-428-7907
Fax: +1 408-428-6960

Confidential Copyright 2013

www.symmetricom.com

30