The PTP Telecom Profile for Frequency Synchronization

Tim Frost
Symmetricom, Inc., February 2012

Confidential Copyright 2012

Agenda
PTP (Precision Time Protocol) Defined The Nature of Packet Timing Frequency Synchronization Architecture
G.803 reference chain Packet Timing Architecture

The PTP Telecom Profile (G.8265.1)

Objectives and Design Features Traceability Multicast vs. Unicast messages Rate of Timing Messages Master Selection and Protection
Confidential Copyright 2012 2

PTP (Precision Time Protocol) Defined

Confidential Copyright 2012

What is the Precision Time Protocol (PTP)?

Protocol Specification 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

Time is carried in event messages transmitted from a Grandmaster Clock to a Slave Clock 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 2012 4

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 synchronization by telecoms operators
Confidential Copyright 2012 5

The Nature of Packet Timing

Confidential Copyright 2012

What is a Packet Timing Signal?

Conventional timing signal:
A nominally periodic signal, generated by a clock:
Significant instants

Timing jitter and wander

Packet timing signal:

A nominally periodic signal, generated by a packet master clock:
Significant instants

Payload F Payload Payload 4 4H 4H H

Payload F Payload Payload 4 4H 3H H

Payload F Payload Payload 4 4H 2H H Packet Delay Variation

Payload F Payload Payload 4 4H 1H H

Confidential Copyright 2012

(header, payload and footer)

Packets

Use of Timestamps
Packet timing signal:
A sequence of timed events, generated by a packet master clock:
Significant instants

TS = 8

TS = 4

TS = 1

Packets containing timestamps Reconstructed frequency:

Confidential Copyright 2012

Precision Time Protocol (PTP)

PTP defines an exchange of timed messages over a packet network
Master Clock Time t1 Sync message Slave Clock Time Data at Slave Clock t2 (t1), t2

Each event message flow (sync, delay_req) is a packet timing signal 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

Follow_Up message containing accurate value of t1 (if required)

t1, t2 Delay_Req message t3 t1, t2, t3

Time offset calculation requires all four timestamps:

Slave time offset = (t1 t2) + (t4 t3) 2

t4 Delay_Resp message containing value of t4

assumes symmetrical delays (i.e. the forward path delay is equal to the reverse path delay)
t1, t2, t3, t4

time
Confidential Copyright 2012

Time offset error = fwd. delay rev. delay 2

9

Frequency Synchronization Architecture

Confidential Copyright 2012

10

Frequency Synchronization Architecture

G.803 Synchronization Reference Chain:

PRC

SSU 1

Chain of up to 20 SECs*

SSU k-1

Chain of up to 20 SECs*

SSU k

Chain of up to 20 SECs*

NE

G.8261 Modified Reference Chain to include Synchronous Ethernet Clocks (EEC):

PRC

SSU 1

Chain of up to 20 EECs*

SSU k-1

Mixed Chain of up to 20 SECs & EECs*

SSU k

Mixed Chain of up to 20 SECs & EECs*

NE

G.8261 Modified Reference Chain to include Packet-Based Timing:

M

Packet Network

PRC

SSU 1

Chain of up to 20 EECs*

SSU k-1

PTP Master and Slave connected by packet network

SSU k

Mixed Chain of up to 20 SECs & EECs* Packet Network

NE

PRC

SSU 1

Chain of up to 20 EECs*

SSU k-1

Mixed Chain of up to 20 SECs & EECs*

SSU k
*

PTP Master and Slave connected by packet network

NE
11

Confidential Copyright 2012

Maximum

Maximum number of SECs or EECs in total chain = 60 number of SSUs (k) in total chain = 10

Packet Timing Architecture (G.8265)

General Packet Timing Architecture
PRC PRC Physical layer sync network Primary PTP GM PTP GM Secondary PTP GM PTP GM Protection Timing Flows PTP GM Primary PTP GM PTP Timing Flows

Packet Network Timing Protection

PRC

PTP Timing Flows

PTP Slave

PTP Slave

PTP Slave

Packet Network

PTP Slave

PTP Slave

Packet Network

PTP Slave
12

Confidential Copyright 2012

The PTP Telecom Profile for Frequency (G.8265.1)

Confidential Copyright 2012

13

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 2012

14

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 2012 15

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] SSM: QL-PRC

PTP GM PRC Physical Layer Synchronization Network PTP Grandmaster Packet Network

PTP Slave PTP Slave End Equipment

16

Confidential Copyright 2012

SSM QL value to PTP clockClass Mapping

ITU-T G.781 Network Options SSM QL value
0001 0000 0010 0111 0011 0100 0101 0110 1000 1001 1101 1010 1011 1100 1110 1111
Confidential Copyright 2012

(2M hierarchy)

Option I

(1.5M hierarchy) QL-PRS QL-STU

Option II

(6.3M hierarchy) QL-UNK

Option III

PTP clockClass value

80 82 84 86 88 90 92 94

QL-PRC QL-ST2 QL-SSU-A QL-TNC

decreasing quality, increasing clockClass

QL-SSU-B QL-ST3E QL-ST3 / QL-EEC2 QL-SEC / QL-EEC1 QL-SMC QL-PROV QL-DNU QL-DUS QL-SEC

96 98 100 102 104 106 108 110

17

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 2012

18

Unicast Registration
Master only provides Unicast service
No multicast announce messages sent
Master Slave

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 2012 19

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 Announce Sync Delay_Request Minimum 1 msg. every 16s 1 msg. every 16s 1 msg. every 16s Maximum 8 messages/s 128 messages/s 128 messages/s Default 1 msg. every 2s Not defined 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 2012 20

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 2012 21

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
Slave Protocol Instance 1

Telecom Slave Clock

G.781based Master Selection Process

PTP GM 2

Packet Network

Slave Protocol Instance 2

PTP GM N
Confidential Copyright 2012

Slave Protocol Instance N Separate PTP domains

List of N Grandmasters
22

Additional Protection Functions

Non-reversion function
By default, a slave should switch back to the original master once the failure condition has been rectified Optionally, this automatic reversion function can be disabled

Wait-to-Restore Time
Follows an initial protection switch, e.g. due to loss of traceability or signal failure Time waited before switching back to the original highest priority master, once the failure condition has been rectified Implies slaves must continually monitor the original master following a protection switch

Confidential Copyright 2012

23

Additional Traceability Functions

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
Applies to slave output timing signals that carry an SSM QL value (e.g. SyncE) Change of QL in the incoming PTP clockClass input should be delayed before being applied to the output Allows time for synchronization to a new reference Avoids any unecessary switching in downstream equipment

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

For Further Reading

White Paper:
Synchronization for Next Generation Networks The PTP Telecom Profile, Symmetricom White Paper, June 2011

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 Architecture of Transport Networks based on the Synchronous Digital Hierarchy (SDH), ITU-T Recommendation G.803, March 2000 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
Confidential Copyright 2012 25

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 2012

www.symmetricom.com

26