Symmetricom Telecom Profile_Webinar


Published on

1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Symmetricom Telecom Profile_Webinar

  1. 1. The PTP Telecom Profile for Frequency Synchronization Tim Frost Symmetricom, Inc., February 2012Confidential © Copyright 2012
  2. 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 ProtectionConfidential © Copyright 2012 2
  3. 3. PTP (Precision Time Protocol) DefinedConfidential © Copyright 2012 3
  4. 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.2Confidential © Copyright 2012 4
  5. 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 operatorsConfidential © Copyright 2012 5
  6. 6. The Nature of Packet TimingConfidential © Copyright 2012 6
  7. 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 instantsPayload 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 DelayConfidential © Copyright 2012 7 (header, payload and footer) Variation
  8. 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 1Confidential © Copyright 2012 8
  9. 9. Precision Time Protocol (PTP) • PTP defines an exchange of timed messages over a packet networkMaster 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. 10. Frequency Synchronization ArchitectureConfidential © Copyright 2012 10
  11. 11. Frequency Synchronization ArchitectureG.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 = 60Confidential © Copyright 2012 11 ◊ Maximum number of SSUs (k) in total chain = 10
  12. 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 SlaveConfidential © Copyright 2012 12
  13. 13. The PTP Telecom Profile for Frequency (G.8265.1)Confidential © Copyright 2012 13
  14. 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 practicesConfidential © Copyright 2012 14
  15. 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 itselfConfidential © Copyright 2012 15
  16. 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 EquipmentConfidential © Copyright 2012 16
  17. 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 110Confidential © Copyright 2012 17
  18. 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 networksConfidential © Copyright 2012 18
  19. 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 failsConfidential © Copyright 2012 19
  20. 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 performanceConfidential © Copyright 2012 20
  21. 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 undefinedConfidential © Copyright 2012 21
  22. 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 GrandmastersConfidential © Copyright 2012 22 Separate PTP domains
  23. 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 switchConfidential © Copyright 2012 23
  24. 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. 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 2010Confidential © Copyright 2012 25
  26. 26. Thank You Tim Frost Principal Technologist, Symmetricom, Inc. Email: Symmetricom, Inc. 2300 Orchard Parkway San Jose, CA 95131-1017 Tel: +1 408-428-7907 Fax: +1 408-428-6960Confidential © Copyright 2012 26