Basic Timing & Synchronization GPS, NTP and PTP/IEEE 1588

Basic Timing & Synchronization GPS, NTP and PTP/IEEE 1588
dB Levels, Inc. IEEE 1588 Tutorial Basic Timing & Synchronization GPS, NTP and PTP/IEEE 1588

Mini Glossary GPS - Global Positioning System, is a satellite navigation system consisting of 24 satellites have atomic clocks that are accurate to within a billionth of a second – 1ns. UTC or Coordinated Universal Time - A high precision atomic time standard that is used as a time reference for many Internet and WWW applications. Specified in ITU-R TF Accuracy - A measure of how closely the frequency generated by the standard corresponds to its assigned value (e.g., the atomic transition frequency for an atomic standard). A measurement of a 100-Hz frequency that is accurate to the sixth decimal place is said to be accurate to 1 part in 108, 0.1 parts per billion, or to have 10−8 accuracy. Precision - A measure of the repeatability of a frequency measurement. It is generally expressed in terms of a standard deviation of the measurement. Stability - A measure of the maximum deviation of the standard’s frequency when operating over a specified parameter range. Holdover - The mode that a clock enters into when it loses connectivity with an input reference. While in holdover, the clock uses stored data to control its output and its stability depends on the stability of its internal oscillator. Jitter - deviation of a time signal from its ideal point in time. Wander - Wander is a phase variation at slow frequency of DC to 10Hz. It requires wider measurement range than Jitter. (The required range is at least 1 x 109 ns according to ITU-T Rec. O.172.). BITS – Building Integrated Timing System – A standard for distributing a precision clock among telecommunications equipment . TIE – Time Interval Error - The variation in time delay of a given timing signal with respect to an ideal timing signal over a particular time period. TDEV - a measure of how much the phase (in time units) of a clock could change over an interval of duration T assuming that any systemmatic (i.e. constant) frequency offset has been removed. MTIE – Maximum Time Interval Error – A measure of the worst case phase variation of a signal with respect to a perfect signal over a given period of time. PDV – Packet Delay Variation - The variation in the amount of Latency among Packets being received, has an impact on jitter and wander for Pseudowire implementations. ACR – Adaptive Clock Recovery – method of recovering frequency from the arrival rate of packets, not recommended in heavily loaded or best effort networks. 2 2

Timing & Synchronization 101
Confidential 3

Synchronization Schemes
Reference Isochronous - same frequency, out of phase A Asynchronous – out of frequency, out of phase B Synchronous – same frequency, same phase C 4 4

How is timing used in network equipment?
Received Signal Timeslots A reference timing source provides a precise clock that is used for framing and timeslot inference in network elements Imperfect timing can cause buffer underflow and overflow conditions leading to frame slips RX TX F4 Data F3 F2 F1 5 5

Generic Block Diagram of a Clock
VCXO 6 6

Time Interval Error (TIE)
7 7

Frequency and Phase Relationship between frequency and phase: ω=dФ/dt
Frequency is the slope in the phase plot 8 8

Analysis from phase: MTIE
9 9

Analysis from phase: TDEV
TDEV(t) is the rms of filtered TIE, where the bandpass filter (BPF) is centred on a frequency of 0.42/t. 10 10

Synchronization Analysis (MTIE)
Both MTIE and TDEV are measures of wander over ranges of values from very short-term wander to long-term wander MTIE is a peak detector: shows largest phase swings for various observation time windows 11 11

Synchronization Analysis (TDEV)
TDEV is a highly averaged, “rms” type of calculation showing values over a range of integration times 12 12

Synchronization Hierarchy in North America
Stratum 1 Most accurate clock sources in the network Frequency accuracy: ±0.01 ppb to UTC Used in Network Gateways S1 S1 Stratum 2 Receive sync signals from multiple sources, good holdover capability Frequency accuracy: ± 16 ppb Used in Central Offices S2 S2 S2 S2 Stratum 3 Receive sync signals from multiple sources, reasonable holdover capability Frequency accuracy: ± 4.6 ppm Used in local offices S3 S3 S3 S3 S3 Stratum 4 Receive sync signals from multiple sources, Tolerable holdover capability for CPE applications Frequency accuracy: ± 32 ppm Used in CPEs, Set-top boxes, etc. S4 S4 S4 S4 13 13

ITU-T Sync Reference Chain
PRC G.812 Type I G.813 Number of G.813 clocks £ 20 Number of G.812 type I clocks £ 10 G.813 G.812 Type I G.813 Total number of G.813 clocks in a synchronization trail should not exceed 60 14 14

Clock Types SDH SONET PRC PRS Decreasing Accuracy SSU BITS SEC SMC 15
Primacy Reference Clock Primacy Reference Source Decreasing Accuracy SSU BITS Synchronization Supply Unit Building Integrated Timing Source SEC SMC SDH Equipment Clock SONET Minimum Clock 15 15

Timing is critical PRC SSU SEC Backbone Ring STM-16 Transit Ring STM-4/16 Local Exchange Ring STM-1/4 MAN ADM Digital switching equipment must be synchronized to avoid slips Slips have a major impact on circuit-switched services SONET and SDH technologies of the 1990s put stringent requirements on network synchronization IWF Remote Terminal TDM to Packet Central Office Packet to TDM IP Network f T1/E1 Network synchronization plays an important role in next generation packet switched networks too 16 16

The Next Generation Network
Predominantly IP-based Access networks owned by different service providers Networks provide transit as well as access Timing is required at points where legacy networks meet IP networks and for QoS assurance across the entire network Wireless Service Provider’s IP Network Synchronization required IP Transit Network Broadband Wireline Service Provider’s IP Network PSTN Service Provider’s IP Network Local Exchange Reproduced from ATIS NGN Framework 17 17

NGN applications rely on time and frequency synchronization
WEB Services Content Distribution Parlay/OSA SIP Apps SCP Service Profiles AAA Messaging Session Control Dynamic Service Data (Presence, Location) WiMAX Existing PSTN M a n a g e m e n t DSL Cable Core IP Centric Network Access CPE Existing Mobile UMTS Edge Existing Internet GigE Broadband Interconnect Access Network Resources Existing Internet NGN Core v1.1, Reproduced from ATIS Time synchronization required Frequency synchronization required 18 18

Service-specific Synchronization Requirements
Source: Cisco 19 19

Examples of applications that need precise time and frequency
Distributed database transaction journaling and logging (Time-of-day) Stock market buy and sell orders (Time-of-day) Secure document timestamps (with cryptographic certification) (Time-of-day) Aviation traffic control and position reporting (Time-of-day) Radio and TV programming launch and monitoring (Time-of-day, frequency) Intruder detection, location and reporting (Time-of-day) Multimedia synchronization for real-time teleconferencing (Time-of-day, frequency) Network monitoring, measurement and control time (Frequency) Early detection of failing network infrastructure devices (Time-of-day, frequency) Differentiated services traffic engineering (Time-of-day, frequency) Distributed network gaming and training (Time-of-day) 20 20

Next Generation Sync Requirements
< 100 ppb (part per billion) One-way Video IPTV One-way Video HDTV < 500 ppb (part per billion) One-way Video MPEG < 50 ppb (part per billion) Two-way Video < 100 ppm (part per million) Ethernet Best Effort < 32 ppm (part per million) Voice SYNCHRONIZATION REQUIREMENT APPLICATION Real-Time Applications Mobile Sync Requirements Wireless System Frequency Synchronization Phase (Time) Synchronization UMTS +/- 50 ppb Not required CDMA2000 (US, Asia, 3GPP2) +/- 3 µs (+/- 10 µs worst case) WCDMA (3GPP, Europe, Asia) and GSM +/ µs between Reference and BTS; +/- 2.5 µs between basestations Pico RBS (WCDMA and GSM) +/- 100 ppb +/- 3µs Femtocells Mobile WiMAX +/- 2.5 µs down to +/- 1.0 µs for some WiMAX profiles Source: Vodafone & others 21

How does PTP compare to NTP?
Attribute PTP NTP Accuracy Sub-microsecond accuracy. Nanosecond accuracy with good oscillator Millisecond accuracy. Brilliant achieves sub-microsecond accuracy using hardware implementation Network topology Version-1 suitable for LANs only. Version-2 is under development for WANs Has been designed for use in public networks and can be used across WANs Synchronization mechanism Single Grandmaster “pushes” time to one or more slaves in a multicast mode NTP client regularly polls one or more NTP servers Redundancy Version 2 supports multiple clock sources running a best-master selection algorithm Built-in redundancy through multiple clock sources (NTP servers) Security Hash codes and improved clock selection mechanism in v2 prevents security risks Cryptographic security mechanism Applications Military and aerospace, industrial automation (synchronization of CNC systems, sensors, actuators, etc.), telecommunications (synchronization of base stations), home networking (standard for Audio-video-bridging) Enterprise IT applications, synchronization of computers in the home network, IPTV related applications (DRM), generic time-stamping applications in a variety of industries 22 22

Standards Bodies ITSF - International Telecom Sync Forum
ITU-T - International Telecommunication Union ANSI - American National Standards Institute ATIS - Alliance for Telecommunications Industry Solutions IEEE - Institute of Electrical and Electronics Engineers Bellcore/Telcordia - NIST - National Institute of Standards and Technology IETF - Internet Engineering Task Force TicToc BOF – timing and frequency distribution over IP BOF

Applicable Standards ITU-T G.811: Timing Characteristics of Primary Reference Clocks ITU-T G.812: Timing requirements of slave clocks suitable for use as node clocks in synchronization networks ITU-T G.813: Timing characteristics of SDH equipment slave clocks (SEC) ITU-T G.823: The control of jitter and wander within digital networks which are based on the kbit/s hierarchy (i.e. E1) ITU-T G.824: The control of jitter and wander within digital networks which are based on the kbit/s hierarchy (i.e. T1) Draft ITU-T Recommendation G.8261/Y Timing and synchronization aspects in packet networks – formally G.pactiming GR-1244-CORE, Clocks for the Synchronized Network: Common Generic Criteria Generic Requirements GR-378-CORE, Building Integrated Timing Systems GR-378-CORE, Timing Signal Generator Generic Requirements (supersedes above) GR-436-core: Digital Network Synchronization Plan GR-499-core: Transport Systems Generic Requirements (TSGR): Common Requirements GR-253-CORE, SONET Transport Systems: Common Generic Requirements GR-2830-CORE: Primary Reference Sources: Generic Criteria ANSI T : Synchronization Interface Standard DTI: DOCSIS Timing Interface Specification PTPv1 – 2002: uSec accurate timestamps and distribution PTPv2 – 2008???: sub nSec accurate, correction (offsets) for asymmetric topologies, redundancy, etc. NTP - Network Time Protocol: (NTPv3, RFC 1305, Obsoletes: RFC-1119, RFC-1059, RFC-958), (SNPTv4, RFC 2030, Obsoletes RFC 1769) ITU-R TF.460-4: STANDARD-FREQUENCY AND TIME-SIGNAL EMISSIONS 24 24

ITU-T Synchronization Standards
ITU-T Recommendation G.803 (2000), Architecture of transport networks based on the synchronous digital hierarchy (SDH). ITU-T Recommendation G.810 (1996), Definitions and terminology for synchronization networks. ITU-T Recommendation G.811 (1997), Timing characteristics of primary reference clocks. ITU-T Recommendation G.812 (1998), Timing requirements of slave clocks suitable for use as node clocks in synchronization networks. ITU-T Recommendation G.813 (1996), Timing characteristics of SDH equipment slave clocks (SEC). ITU-T Recommendation G.823 (2000), The control of jitter and wander within digital networks which are based on the 2048 kbit/s hierarchy. ITU-T Recommendation G.824 (2000), The control of jitter and wander within digital networks which are based on the 1544 kbit/s hierarchy. 25 25

North American Synchronization Standards
ANSI T1-101: Synchronization Interface Standard Bellcore GR-253-core: Synchronous Optical Network (SONET) Transport Systems: Common Generic Criteria Bellcore GR-1244-core: Clocks for the Synchronized Network: Common Generic Criteria Bellcore GR-436-core: Digital Network Synchronization Plan Bellcore GR-378-core: Generic Requirements for Timing Signal Generators Bellcore GR-499-core: Transport Systems Generic Requirements (TSGR): Common Requirements 26 26

NGN Timing Standards IETF IEEE ITU-T 27 27 1985 1988 1989 1992 2006
NTPv0 RFC958 NTPv1 RFC1059 NTPv2 RFC1119 NTPv3 RFC1305 NTPv4 Work In progress Evolution from Time Protocol and ICMP Timestamp message Specification of protocol, algorithms state variables and operational modes Management of clients, authentication based on 64-bit DES Sanity checks for lost or corrupted packets, clock algorithm improved, new peering algorithm Improved algorithm, security enhancements 2002 2007 IEEE 1588v1 1588v2 Initial release for Industrial Automation, T&M Enhanced for telecom applications, nanosecond accuracy Feb 2008 Network modeling Feb 2008 Synchronous Ethernet G.8262 G. pacmod Apr 2004 ITU-T Question 13 Oct 2003 G. pactiming G. paclock G. Paclock. bis 2008 Profile for telecom Study Group 15 Timing and Synchronization aspects of Packet Networks Sep 2004 G.8261 Y.1361 Network reference model for timing over IP networks 27 27

Clock Recovery Methods over Packet
Network Synchronous Operation: network-synchronous operation by using a PRS/PRC traceable network derived clock or a local PRS/PRC as the service clock. In effect, the TDM signal is “retimed”. The clock accuracy of ingress TDM clock (clk1) must be PRS/PRC traceable, otherwise the use of a network clock reference in the egress IWF (i.e. clk3) will cause jitter buffer overflow/underflow events in the egress IWF. Differential Clock Recovery: The principle of operation of any differential method is based on the availability of “equal” clock references at the ingress and egress IWFs. The difference between the service clock and the reference clock is encoded and transmitted across the packet network.The service clock is recovered on the far end of the packet network making use of the “equal” reference clock. Synchronous Residual Time Stamp (SRTS) is an example of this family of methods. Differential methods can support the plesiochronous circuit timing (also known as asynchronous circuit timing) mode whereby the TDM service clock can have an offset from PRS/PRC provided it is within defined limits. Correct timing in the output TDM signal implies that the clocks generating the TDM signal (clk1) and retiming (clk4) the TDM signal must have the same long term frequency (or within the PRS/PRC limits) otherwise jitter buffer overflow/underflow events will be generated in the egress IWF and the destination TDM NE may experience slips. It is easy to show that wander (and frequency inaccuracy) in the egress TDM signal (clk4) is directly related to the relative wander between the reference clocks clk2 and clk3. Figure 5 shows that the references come from two distinct PRS/PRC units though obviously they could be the same. If the synchronization trail between clk2 and the PRS/PRC and that of clk3 and the PRS/PRC has a “common” node, that node could be in holdover without adversely impacting the differential mode of operation. Adaptive Clock Recovery: In Adaptive Clock Recovery (ACR) methods, timing is recovered based on the inte-rarrival time of the packets or on the fill level of the jitter buffer. Adaptive methods can support the plesiochronous circuit timing mode whereby the TDM service clock can have an offset from PRS/PRC provided it is within defined limits. If the transit time across the packet network of the packets varies, also known as packet delay variation (PDV) or time-delay variation (TDV), the clock recovery process is affected. In particular, PDV, on a short-term basis, is indistinguishable from a change in the phase/frequency of the service clock and/or the local oscillator. Consequently ACR implementations require high quality oscillators and apply filtering corresponding to bandwidths of the order of milli-hertz (mHz) (time constants of the order of 1,000s). However, if a network clock reference is not available, then ACR is the only available method for service clock recovery. There are several causes of delay variation including the following that are covered in G.8261: • Random delay variation (e.g. queuing delays) • Low frequency delay variations (e.g. day/night traffic patterns) • Systematic delay variation (e.g. transmission window) • Routing changes (e.g. network re-configuration) • Congestion effects (e.g. network overload) Since the performance of adaptive clock recovery is very dependent upon PDV, it is recommended for use only when the PDV can be tightly controlled.

Synchronous Ethernet Point-to-point distribution of timing signals in Ethernet environments Synchronize the Ethernet physical layer as currently done in SONET/SDH Packetize Synchronization Status Messaging protocol (SSMoETH) Bring carrier-grade telecom-quality clocks to Ethernet switches Maintain SONET/SDH network synchronization principles & guidelines Implementation conformant with IEEE specification High-level definition part of ITU-T G.8261 clause 8.1.1 Specification to be established within ITU-T G.pacmod & G.paclock Point to point – i.e. all network elements must support in order to be effective frequency distribution mechanism Frequency only, no sense of phase or Time of Day (ToD) 29 29

Synchronization in the IWF
Figure 15/G IWF synchronization functions (Packet to TDM direction) 30 30

Synchronization Techniques
Frequency transfer Network Synchronous Differential Clock Recovery Adaptive Clock Recovery Synchronous Ethernet Time transfer NTP – Network Time Protocol v4 IEEE 1588v2 (also known as Precision Time Protocol, PTP) 31 31

Network Synchronous Operation
Figure 6/G.8261 – Example of Network Synchronous Operation PRC Traceable network clock is used as a service clock Implies that PRC traceable clock is available at both ends Reference signals at IWF must comply with G.823 and G.824 32 32

Synchronization Challenges in the IP Backhaul Network
IWF Remote Terminal TDM to Packet MSC Packet to TDM IP Network f T1/E1 IWF: Interworking Function Synchronization path is broken Traditional synchronization techniques are not available IP Networks introduce complexities to data traffic flow Different upstream and downstream paths Time varying delays Asymmetric delays Synchronization must include both frequency and phase: Frequency only Synchronous Ethernet Adaptive Clock Recovery (ACR) Frequency and Phase GPS-based timing that provides T1 retiming capabilities Differential clock recovery – NTP & IEEE 1588 (PTP) The interworking function at the interface between an Access network and an IP network introduces several complexities. Timing is one of the key issues. The, two interworking functions on either side of the IP network must be timed with a common reference frequency reference. In the case of a legacy network, the timing information was conveyed in the frame structure of the signal over a backhaul link However in the next generation network, the backhaul is provided by an IP network and the synchronization path is broken. So Traditional synchronization techniques do not work anymore IP backhaul introduces several complexities to data traffic flow. The upstream and downstream paths may have different packet delays The path maybe asymmetric The delay characteristics are unpredictable. Any mechanism that is used to transfer time across the network must be able to cope with these issues. In the next generation network, synchronization is achieved by using GPS points where timing is required (a phase relationship between ends), or by using packet based synchronization techniques ( for frequency accuracy ). NTP and PTP are two popular packet based timing mechanisms which convey both phase and frequency accuracy. NextGen timing and sync distribution methods must include time and phase in addition to frequency

Adaptive Clock Recovery
Figure 8/G.8261 – Example of Adaptive Method Timing is recovered based on the inter-arrival time of the packets or on the fill level of the jitter buffer Service clock is preserved 34 34

Adaptive Clock Recovery (ACR) issues
Proprietary – non standard, requires “bookend” approach Frequency only – no sense of phase Unpredictable wander, can’t be filtered out No measurement of differential delay, handoffs a challenge Recovery from network perturbations (e.g. fiber cut, re-route, traffic loading) also a challenge No way to prevent instantaneous phase jumps Jitter buffer adds to latency – lowers user QOE Buffer overruns and underruns cause packet and data loss Point to point – multiplexing/aggregation a challenge No Global reference for time/sync – no visibility of timing loops and islands Additional PWE on network degrades sync performance Even with PWE as highest priority traffic, it is self-interfering PWE packets tend to “clump” Better local oscillators actually exacerbate the problem – the tighter the freq control, the more the wander: Amp <= Ts * BWpwe / BWlink

Differential Clock Recovery
Figure 7/G.8261 – Example of Differential Method Distributes Global time. phase and frequency based on Primary Clock Reference Preserves service clock – frequency and phase difference from Global reference Hierarchical distribution from global reference prevents timing loops Synchronization Status Messaging (SSM) – manageability and traceability Scalable, supports point-to-point, point-to-multipoint, multipoint and broadcast services. Signals at IWF comply with ITU G.823 and G.824 sync requirements Standards-based – IEEE1588v2, NTP Differential Clock Recovery distributes phase and absolute time, not just frequency 36 36

PTP/NTP Timing Recovery
Global clock reference – GPS based Understanding of time, freq and phase No tendency of timing packets to “clump” – can be staggered to ensure no impact to wander characteristics Timing updates are negligible BW, not traffic dependent Standards compliant – IEEE 1588, NTP Internal algorithms are proprietary, but multiple vendors’ servers and clients are interoperable, unlike ACR and PWE equipment Brilliant servers are more accurate than competitors, leading to better timing and sync at the edge Better time, sync and phase mean better QOE

NTP overview Network Time Protocol (NTP) synchronizes clocks of hosts and routers in the Internet The NTP architecture, protocol and algorithms have been evolved over the last two decades. Currently NTP Version 4 is being developed Well-tested and widely-deployed protocol NIST estimates million NTP servers and clients deployed in the Internet and its tributaries all over the world. Every Windows/XP has an NTP client NTP provides nominal accuracies of low tens of milliseconds on WANs, submilliseconds on LANs, and submicroseconds using a precision time source such as a cesium oscillator or GPS receiver Current implementations are primarily software-based. Non-deterministic delays in networking stacks contribute to significant timing inaccuracy

NTP overview Network Time Protocol (NTP) synchronizes clocks of hosts and routers in the Internet The NTP architecture, protocol and algorithms have been evolved over the last two decades. Currently NTP Version 4 is being developed Well-tested and widely-deployed protocol NIST estimates million NTP servers and clients deployed in the Internet and its tributaries all over the world. Every Windows/XP has an NTP client NTP provides nominal accuracies of low tens of milliseconds on WANs, submilliseconds on LANs, and submicroseconds using a precision time source such as a cesium oscillator or GPS receiver Current implementations are primarily software-based. Non-deterministic delays in networking stacks contribute to significant timing inaccuracy 39 39

NTP Stratum Levels Hierarchical layering of clocks based on number of hops from primary reference source Stratum 1 servers are synchronized with a GPS source Stratum 2 servers use client/server mode to synchronize with up to six Stratum 1 servers and symmetric mode to synchronize with other servers on the same stratum level Stratum 4 clocks work in client mode to synchronize with servers in Stratum 3 Stratum 1 S1 S1 Stratum 2 S2 S2 S2 S2 Stratum 3 S3 S3 S3 S3 S3 Stratum 4 S4 S4 S4 S4 NTP Stratum levels are not the same as ITU-T Stratum levels! Next Generation Network Services require ITU-T Stratum level synchronization 40 40

NTP Protocol Overview Key Assumptions: Clock offset: Round-trip delay:
Client Server Clock offset: [(T2 – T1) + (T4 – T3)] / 2 Round-trip delay: (T4 – T1) – (T3 – T2) Client sends request at T1 = 10:15:00 T1 Server receives request at T2 = 10:15:12 T2 Server sends response at T2 = 10:15:15 T3 Client receives response at T2 = 10:15:30 T4 Key Assumptions: Network delay is symmetric in both directions One-way delay is half of round-trip delay Client and server clocks drift at the same rate

NTP Protocol Overview Clock offset: Round-trip delay: Key Assumptions:
Client Server Clock offset: [(T2 – T1) + (T4 – T3)] / 2 (2 + 4) / 2 = 3 seconds Round-trip delay: (T4 – T1) – (T3 – T2) 19 – 3 = 16 seconds Client sends request at T1 = 10:15:00 T1 Server receives request at T2 = 10:15:12 T2 Server sends response at T2 = 10:15:15 T3 Client receives response at T2 = 10:15:19 T4 Key Assumptions: Network delay is symmetric in both directions One-way delay is half of round-trip delay Client and server clocks drift at the same rate 42 42

IEEE1588 Overview IEEE 1588 (commonly known as Precision Time Protocol, PTP) was ratified as a standard in September 2002 Provides timing for the control of distributed applications Version 1 of the protocol used for applications in Industrial automation Test and measurement Electric power Military Residential (Audio-Video Bridging) Version 2 developed for telecom applications Early adopters include Vodafone, T-Mobile, etc. 43 43

Enhancements to IEEE 1588v2 IEEE 1588v2 meets accuracy requirements for Telecom applications High refresh rates up to 64 messages per second Correction field for asymmetric measurements Several modes supported Broad-cast, Multi-cast and Uni-cast are permitted Smaller message length to conserve bandwidth – 72 octets (44 for 1588v2 payload) Multiple Master Clock selection methods Manual, Semi-automatic, Fully-automatic Transparent Clocks to reduce accumulation of timing errors across network elements in cascaded topologies Enhanced security Configurable network in combination with Best Master Clock algorithm for GrandMaster HASH codes 44

IEEE1588 Protocol Overview
The Slave collects the time values t1, t2, t3, t4 during a transaction and calculates final offset (o) between Master and Slave clocks canceling out network delay (d) as follows: t2 –t1 = o + d t4 - t3 = -o + d o = (t2 + t3 – t1 – t4) / 2 d = (t2 – t1 + t4 – t3) / 2

PTP overview - Sync Master Slave 46 46
Sent at 1001 s Received at s Slave Master sends ‘SYNC’ message at seconds. Timestamp in packet shows 1001, but the packet is actually sent out at seconds. Slave clock is not synchronized. Slave receives the packet at 1015 seconds local time PTP UDP IP MAC PHY MII 1001 SYNC 1001 SYNC SYNC 1001 1001 SYNC 1003 1015 Tm = 1000s Ts = 1010s 1001: SYNC 1015: SYNC 46 46

PTP overview – Follow Up
Master Sent at 1004 s Received at s Slave Master sends ‘SYNC’ message at 1001 seconds. Timestamp in packet shows 1001, but the packet is actually sent out at 1003 seconds. Slave clock is not synchronized. Slave receives the packet at 1015 seconds local time PTP UDP IP MAC PHY MII 1003 FOLLOW UP 1003 FOLLOW UP Master sends ‘FOLLOW UP’ message with actual time of transmission of the SYNC message, i.e seconds FOLLOW UP 1003 1003 FOLLOW UP 1018 1001: SYNC Offset = 1015 – 1003 – Unknown line delay = 12 – Unknown line delay 1015: SYNC 1003: FOLLOW UP 1018: FOLLOW UP Adjusted slave time = 1018 – 12 – Unknown line delay = 1006 – Unknown line delay 47 47

PTP overview – Delay Request
Master Received at 1013 s Sent at s Slave Master sends ‘SYNC’ message at 1001 seconds. Timestamp in packet shows 1001, but the packet is actually sent out at 1003 seconds. Slave clock is not synchronized. Slave receives the packet at 1015 seconds local time PTP UDP IP MAC PHY MII 1009 DELAY REQ 1009 DELAY REQ Master sends ‘FOLLOW UP’ message with actual time of transmission of the SYNC message, i.e seconds DELAY REQ 1009 Slave tries to determine unknown line delay by sending a ‘DELAY REQ’ message to the master 1009 DELAY REQ 1012 1010 1001: SYNC Offset = 1015 – 1003 – Unknown line delay = 12 – Unknown line delay 1015: SYNC 1003: FOLLOW UP 1018: FOLLOW UP Adjusted slave time = 1018 – 12 – Unknown line delay = 1006 – Unknown line delay 1010: DELAY REQ 1012: DELAY REQ 48 48

PTP overview – Delay Response
Master Sent at 1014 s Received at s Slave Master sends ‘SYNC’ message at 1001 seconds. Timestamp in packet shows 1001, but the packet is actually sent out at 1003 seconds. Slave clock is not synchronized. Slave receives the packet at 1015 seconds local time PTP UDP IP MAC PHY MII 1012 DELAY RESP 1012 DELAY RESP Master sends ‘FOLLOW UP’ message with actual time of transmission of the SYNC message, i.e seconds DELAY RESP 1012 Slave tries to determine unknown line delay by sending a ‘DELAY REQ’ message to the master 1012 DELAY RESP Master responds with ‘DELAY RESP’ message containing timestamp when ‘DELAY REQ’ was received Slave calculates average delay by assuming symmetric path and dividing total delay by 2 1001: SYNC Offset = 1015 – 1003 – Unknown line delay = 12 – Unknown line delay 1015: SYNC 1003: FOLLOW UP 1018: FOLLOW UP Adjusted slave time = 1018 – 12 – Unknown line delay = 1006 – Unknown line delay 1009: DELAY REQ 1013: DELAY REQ Line delay = ((1012 – 1009) + (1006 – 1003)) / 2 = 3 seconds Slave time = 1015 – 3 = 1012 seconds 1012: DELAY RESP 1015: DELAY RESP 49 49

Boundary clock Boundary Clock S M A Boundary Clock extends synchronization across an intermediate network element M S S M IP Network Grandmaster Boundary Clock Slave Grandmaster Boundary Clock Slave Slave Master A boundary clock contains more than one PTP port: a slave port that is synchronized with a remote master, and a master port that synchronizes other slaves downstream Synchronization messages are terminated at each port and not forwarded PTP UDP IP MAC PHY MII PTP UDP IP MAC PHY MII PTP UDP IP MAC PHY MII PTP UDP IP MAC PHY MII 50 50

Transparent clock Transparent Clock A Transparent Clock is neither a master nor a slave. It is merely a switch that adjusts a PTP message’s timestamp to compensate for its own queueing delays M S IP Network Grandmaster Trasparent Clock Slave Grandmaster Transparent Clock Slave A Transparent Clock contains no PTP ports. Timestamp in incoming message is modified before sending the message out Creates security issues, since original crypto checksum is not valid anymore PTP UDP IP MAC PHY MII PTP UDP IP MAC PHY MII MAC MAC MII MII PHY PHY 51 51

Boundary clocks and transparent clocks: How do they compare?
Point-to-point synchronization Cascading of error offsets Grand- master M S M S M S End- point M Hops Time Offset End-to-end synchronization Corrects only residence time Causes less jitter in a highly cascaded network Grand- master M Transparent Clock Transparent Clock S Hops Time Offset 52 52

How does PTP compare to NTP?
Attribute PTP NTP Accuracy Sub-microsecond accuracy. Nanosecond accuracy with good oscillator Millisecond accuracy. Brilliant achieves sub-microsecond accuracy using hardware implementation Network topology Version-1 suitable for LANs only. Version-2 is under development for WANs Has been designed for use in public networks and can be used across WANs Synchronization mechanism Single Grandmaster “pushes” time to one or more slaves in a multicast mode NTP client regularly polls one or more NTP servers Redundancy Version 2 supports multiple clock sources running a best-master selection algorithm Built-in redundancy through multiple clock sources (NTP servers) Security Hash codes and improved clock selection mechanism in v2 prevents security risks Cryptographic security mechanism Applications Military and aerospace, industrial automation (synchronization of CNC systems, sensors, actuators, etc.), telecommunications (synchronization of base stations), home networking (standard for Audio-video-bridging) Enterprise IT applications, synchronization of computers in the home network, IPTV related applications (DRM), generic time-stamping applications in a variety of industries 53 53

Mobile Operator view of Sync Techniques
GPS receiver at every node Deliver frequency and time (up to 50ns accuracy claimed) Not always viable (indoor cells) Expensive oscillators required ($$$) for periods of unavailability (not % solution) Packet –based In-band synchronization (adaptive clock recovery) The clock is reconstructed using the packet inter-arrival rate (i.e. leaky bucket algorithm) Inexpensive solution Subjected to network load conditions, not ‘always-on’ and deliver frequency (not phase) Could represent a viable ‘interim’ solution only in certain scenarios Out-of-band synchronization Network synchronous Sync Ethernet IEEE 1588v2 represents the most promising ‘long-term’ solution (in conjunction with Sync Eth) Use the PHY clock from bit stream (similar to SDH/PDH), each node recovers clock Only deliver frequency and not phase Independent from network load Represent an excellent SDH/PDH replacement option -> viable ‘interim’ solution Clock information is transmitted via dedicated timing packets (master <-> slave) ‘Always-on’ solution (even without traffic data) Ubiquitous solution (works over any transport technology) Can deliver frequency and phase (FDD and TDD systems) Major protocols: IEEE 1588v2, IETF NTP version 4

NGN Sync Architecture Typical Network
Enterprise VAP Micro and Pico cells Ethernet (IP) 2G IP<->TDM IWF TDM TDM/ATM<->IP IWF Internet 3G R99 STM-1 TDM BTS ATM MGWs Servers PSN Backhaul IP/Ethernet over fibre, MW, leased lines, etc. BSC Node B Eth (IP) CPN (IP/MPLS) 3G R5+,B3G STM-1 ATM GRX E-NodeB IP<->ATM IWF RNC SGSNs Ethernet (IP) Ethernet (IP) GGSNs VPN Corporate 3G R5+, B3G DSLAM E-NodeB S-GW/MME ASN GW Residential VAP DSL TDM/ATM<->IP IWF SHDSL (TDM) IEEE 1588v2 Grand Master Need SHDSL (ATM) IP link PRC 2G Primary reference clock IEEE 1588 sync packets 3G R99 IEEE 1588v2 Grandmaster BTS Node B Typical Network IEEE 1588v2 Client IEEE 1588 slave board IEEE 1588 slave chip IEEE 1588v2 Differential Clock Recovery (DCR) drives Typical NGN network

Tutorial Provider dB Levels, Inc. Dallas, TX, USA www.dblevels.com
Telecom Measurement Consultants *Some material in this tutorial courtesy CXR Larus, Inc.

Basic Timing & Synchronization GPS, NTP and PTP/IEEE 1588

Similar presentations

Presentation on theme: "Basic Timing & Synchronization GPS, NTP and PTP/IEEE 1588"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Basic Timing & Synchronization GPS, NTP and PTP/IEEE 1588

Similar presentations

Presentation on theme: "Basic Timing & Synchronization GPS, NTP and PTP/IEEE 1588"— Presentation transcript:

Similar presentations

About project

Feedback