This document provides an overview of the PTP Telecom Profile for Frequency Synchronization (G.8265.1). It defines key aspects of the profile including its objectives to enable frequency distribution over packet networks, use of unicast messaging, support for traceability of timing sources, and master selection and protection schemes aligned with telecom network practices. The profile tailors PTP to meet timing accuracy needs for telecom applications over managed packet networks.

1. The PTP Telecom Profile for Frequency
Synchronization
Tim Frost
Symmetricom, Inc.,
February 2012
Confidential © Copyright 2012

2. 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

3. PTP (Precision Time Protocol) Defined
Confidential © Copyright 2012 3

4. 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

5. 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

6. The Nature of Packet Timing
Confidential © Copyright 2012 6

7. 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 4 4 H H H
F Payload 4
Payload Payload 4 4 H H H
F Payload 3
Payload Payload 4 4 H H H
F Payload 2
Payload Payload 4 4 H H H
F Payload 1
Payload
Packets Packet Delay
Confidential © Copyright 2012 7
(header, payload and footer) Variation

8. Use of Timestamps
• Packet timing signal:
– A sequence of timed events, generated by a packet master clock:
Significant instants
F TS = 8 H F TS = 4 H F TS = 1 H
Packets containing timestamps
Reconstructed frequency:
9 8 7 6 5 4 3 2 1
Confidential © Copyright 2012 8

9. Precision Time Protocol (PTP)
• PTP defines an exchange of timed messages over a packet network
Master Clock Time Slave Clock Time • Each “event message” flow (sync,
delay_req) is a packet timing signal
t1 Sync message
Data at
Slave Clock
• Master frequency determined by
comparison of timestamps in the event
Follow_Up message t2 (t1), t2 message flows
containing accurate • e.g. comparison of t1 to t2 over multiple
value of t1 (if required)
sync messages, or t3 to t4 in delay_req
messages
t1, t2
• Time offset calculation requires all four
Delay_Req message t3 t1, t2, t3 timestamps:
• Slave time offset = (t1 – t2) + (t4 – t3)
2
t4
Delay_Resp message
• assumes symmetrical delays
containing value of t4 (i.e. the forward path delay is equal to the
reverse path delay)
t1, t2, t3, t4
• Time offset error = fwd. delay – rev. delay
time 2
Confidential © Copyright 2012 9

10. Frequency Synchronization Architecture
Confidential © Copyright 2012 10

11. Frequency Synchronization Architecture
G.803 Synchronization Reference Chain:
Chain of up to Chain of up to Chain of up to
PRC SSU 1 SSU k-1◊ SSU k◊ NE
20 SECs* 20 SECs* 20 SECs*
G.8261 Modified Reference Chain to include Synchronous Ethernet Clocks (EEC):
Chain of up to Mixed Chain of up to Mixed Chain of up to
PRC SSU 1 SSU k-1◊ SSU k◊ NE
20 EECs* 20 SECs & EECs* 20 SECs & EECs*
G.8261 Modified Reference Chain to include Packet-Based Timing:
Packet
M
Network S
Chain of up to PTP Master and Slave connected Mixed Chain of up
PRC SSU 1 SSU k-1◊ SSU k◊ NE
20 EECs* by packet network to 20 SECs & EECs*
Packet
M S
Network
Chain of up to Mixed Chain of up PTP Master and Slave connected
PRC SSU 1 SSU k-1◊ SSU k◊ NE
20 EECs* to 20 SECs & EECs* by packet network
* Maximum number of SECs or EECs in total chain = 60
Confidential © Copyright 2012 11
◊ Maximum number of SSUs (k) in total chain = 10

12. Packet Timing Architecture (G.8265)
• General Packet Timing Architecture • Packet Network Timing Protection
PRC PRC
PRC
Physical layer
sync network
Primary
Primary PTP PTP PTP GM
Secondary
PTP GM GM PTP Timing Flows PTP GM PTP GM PTP Timing Flows
GM
Protection
PTP PTP
Timing Flows
Slave Slave
Packet Network PTP Packet Network PTP
PTP Slave PTP Slave
Slave Slave
Confidential © Copyright 2012 12

13. The PTP Telecom Profile for Frequency (G.8265.1)
Confidential © Copyright 2012 13

14. 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

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

16. 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 PTP
GM Slave
PRC Physical Layer PTP Packet Network PTP Slave End
Synchronization Network Grandmaster Equipment
Confidential © Copyright 2012 16

17. SSM QL value to PTP clockClass Mapping
ITU-T G.781 Network Options
PTP clockClass
SSM QL value Option I Option II Option III value
(2M hierarchy) (1.5M hierarchy) (6.3M hierarchy)
0001 QL-PRS 80
0000 QL-STU QL-UNK 82
0010 QL-PRC 84
0111 QL-ST2 86
0011 88
decreasing
0100 QL-SSU-A QL-TNC 90
quality,
0101 92
0110 94 increasing
1000 QL-SSU-B 96 clockClass
1001 98
1101 QL-ST3E 100
1010 QL-ST3 / QL-EEC2 102
1011 QL-SEC / QL-EEC1 QL-SEC 104
1100 QL-SMC 106
1110 QL-PROV 108
1111 QL-DNU QL-DUS 110
Confidential © Copyright 2012 17

18. 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

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

20. 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 2012 20

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

22. 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
Slave Telecom
PTP GM
1
Protocol
Instance 1
Slave Clock
G.781-
Slave based
PTP GM Packet
Protocol Master
2 Network Instance 2 Selection
Process
Slave
PTP GM
Protocol List of N
N Instance N
Grandmasters
Confidential © Copyright 2012 22
Separate PTP domains

23. 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

24. 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

25. 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

26. 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