450 likes | 467 Views
Tutorial on Synchronization. Jean-Loup Ferrant, Tim Frost, Silvana Rodrigues, Stefano Ruffini. Agenda. Intro on need for sync (S. Ruffini) Time sync, basic concepts (T. Frost) Sync distribution (S. Rodrigues) Q13 status and ITSF/WSTS (J-L Ferrant). Need for Sync. Time and Frequency.
E N D
Tutorial on Synchronization Jean-Loup Ferrant, Tim Frost, Silvana Rodrigues, Stefano Ruffini
Agenda • Intro on need for sync (S. Ruffini) • Time sync, basic concepts (T. Frost) • Sync distribution (S. Rodrigues) • Q13 status and ITSF/WSTS (J-L Ferrant)
Time and Frequency Clock A Clock B Time alignment (“local time”) “Time” “Time” Time alignment (UTC) Seconds Counter Seconds Counter Time alignment (equal # of seconds) 1Hz 1Hz Phase alignment (roll-over coincident) 10,000,000 Counter 10,000,000 Counter (equality to within 1 clock cycle of 100ns may suffice) 10MHz 10MHz Frequency alignment (syntonization) • Aligning two time clocks (synchronization) implies: • Make frequency B = frequency A (syntonization) • Make phase B = phase A (e.g. roll-over instant of 107 counter) • Make seconds B = seconds A (elapsed time equal; same time origin) • Choose same formatting convention (and time-zone, etc.)
Timing Alignment in Wireless Df = frequency offset between BSs DT = time offset between BSs BS - B BS - A Mobile in motion; speed = X m/s • When hand-over occurs, the mobile must reacquire carrier frequency • Mobile in motion (X m/s) introduces a Doppler shift (X/c) • Loop bandwidth wide enough to handle (Df+ X/c +LO) (LO = local oscillator offset) • Loop bandwidth should be small from a noise rejection viewpoint • Large Dfcompromises the reliability of hand-over; 50 ppb typical requirement • TDD networks require time/phase alignment between A & B • To control interference between uplink and downlink • Requirement in the microsecond range • LTE-Advanced require DT to be small (microsec) for providing the more bandwidth intensive features
Current Timing Issues • Networks are being migrated to packet switching as opposed to circuit-switched (i.e. based on TDM) • Significant impact of variable delay (packet delay variation) • Timing requirements remain • Going “IP” does not mean that real-time services or mobile networks no longer need synchronization! • Transition Phase: • Hybrid Networks (IP/TDM islands) • Circuit Emulation • Timing over Packet Networks (packet-based methods) • PTP, NTP, adaptive clock recovery • Monitoring and Testing • Metrics for packet-based timing methods (quantifying PDV)
Emerging Needs Increased need of time/phase sync in Mobile networks Time sync over various technologies (microwave, OTN, MPLS, etc.) Financial Sector IoT, Network of Sensors Power Networks ...
Power – the need for Sync Source: NIST • “The Power Grid” is one of the world’s largest infrastructures High synchronization requirements due to distributed nature of the grid and the critical balance between power generation and consumption • Power can’t be stored easily so Grids Generate according to Demand • Need good Comms and Sync to correlate Demand and Generation • Has evolved from seconds to milliseconds and will evolve to microseconds → Greater Efficiencies • Also enables the Greater Diversity of the Smart Grid • Power Profile – IEEE C37.238-2011 (target: 1 ms accuracy)
What is Time? • Time is a fundamental physical dimension • Allows ordering and scheduling of events • Enables sharing of resources (e.g. time division muxing) • Passage of time measured by counting a regularly repeating event • Astronomical events, e.g. day/night, year • Physical events, e.g. pendulum swing, quartz resonance or atomic transitions
Common Time • Common time requires a reference point • Time at an instant has no meaning without a reference • Need to start counting from a common point, or epoch • Example: the Gregorian calendar counts years from the birth of Christ • A time reference clock counts at a constant frequency from a known epoch • Sending time in a message... • Need to know how long the message takes • A letter – might be usable for setting the date • A phone call – could use to set hour/minute/seconds • A packet – millisecond level accuracy
Time Error Time error Time at reference clock Time at measured clock The time error of a clock is the difference between the time indicated by that clock and a reference clock at the same instant in time Always relative: has no meaning without a reference Defined by ITU-T Recommendation G.810:
Direction of Time Error – clocks Reference Clock: Measured Clock: Time Error= 11.55 – 12.00= – 5 minutes Time Error= 12.05 – 12.00= + 5 minutes Clock lags reference (slow, delayed): negative time error Clock leads reference (fast, advanced): positive time error
Direction of Time Error – signals Reference Clock: Measured Clock: negativeTime Error negativeTime Error positiveTime Error Signal lags reference (slow, delayed): negative time error Signal leads reference (fast, advanced): positive time error
Time Error Function Time error Frequency offset Random variations (dynamic time error) Frequency drift Constant time error • Time error varies with time and can be expressed as a function*: • If clocks are locked in phase, frequency offset and drift are eliminated, and time error reduces to two components: • Constant time error or offset • Dynamic time error or random variations * Equation defined in ITU-T Recommendation G.810
Examples of Time Error Functions Time Error Time Error Clock frequency high; time error increasing Clock frequency high; time error increasing Clock frequency low; time error decreasing 0 0 Time Time Periodic frequency corrections Periodic time corrections (not always accurate)
Measuring Time Error Time Error Max|TE| dTE cTE 0 Time • Need an accurate time reference – time error has no meaning without a reference • Maximum Absolute Time Error (Max|TE|) is the maximum distance from zero of the time error function • Sign doesn’t matter: excursions may be positive or negative • Constant Time Error (cTE) is the mean of the time error fn. • Period over it is measured is not specified; depends on signal • Dynamic Time Error (dTE) is the change of the time error fn. • Phase or time wander, analyzed using MTIE and TDEV
Sync Distribution Slides for this section provided by Christian Farrow, Chronos Technology Ltd (except for the last slide)
How Are “Bits” Represented..? The value of a Bit (0 or 1) can be represented by different modulations of a carrier signal examples are: • Fibre Optics • The presence or absence of a light pulse • Different frequencies of light • Radio/Microwaves - Mobile phone, satellite comms, WiFi, etc. • Changes in phase, frequency or amplitude of the electromagnetic waves • Electrical Cabling - Coaxial, twisted pair, etc • Voltage levels on the wire +2.5v 0v -2.5v 1 1 0 1 0 1 The bits arrive at regular intervals, represented here
Sync Trail Architecture Rules • EN 300 462-6-1 • ITU G.811 PRC PRC Level SEC • EN 300 462-5-1 • ITU G.813 SEC N x SECs (N<=20) SEC SEC SEC SEC SEC N x SECs (N<=20) SEC SEC • EN 300 462-7-1 • ITU G.812 SSU-L N x SECs (N<=20) • Standards • EN 300 462-2-1 • ITU G.803 N <= 60 for entire chain SSU-T 1st SSU • EN 300 462-4-1 • ITU G.812 SSU-T Kth SSU, (K<=10)
SyncE Overview TX TX RX RX 100 ppm TX TX TX TX Traceable Inaccurate RX RX RX RX TX TX RX RX Ext.Sync 100 ppm SyncE Element Asynchronous Element 4.6 ppm 4.6 ppm How is SyncE different from normal Ethernet? Existing Ethernet PHY (Physical Layer) • IEEE 802.3 defines Ethernet PHY • Rx uses incoming line timing. Tx uses free-running 100ppm oscillator. • No relationship between the Rx & Tx. SyncE PHY (Physical Layer) • Rx disciplines the internal oscillator • Tx uses the traceable clock reference, creating end-to-end scheme. • PRC can provide the reference. SSUs filter jitter/wander. • SyncE and asynchronous switches cannot be mixed.
From clocks to packets Packets (header, payload and footer) time F Payload 4 H F Payload 3 H F Payload 2 H F Payload 1 H Significant instants • Packet “clocks” can be thought of in the same way as physical layer clocks… • CES Packets do have a regular rhythm – E1 = 1mS • NTP/PTP Packets may not arrive regularly, but timestamps within the packets themselves mean time information can be extracted • Time and timing can be distributed from point A to point B
IEEE 1588-2008 PTPv2 Overview EmbeddedSlave PTPv2 Slave clocks can be either stand-alone or embedded in network equipment 1588 1588 1588 1588 ExternalSlave Grandmaster(Server) 1588 Packets • The Grandmaster “reference clock” sends a series of time-stamped messages to slaves. • Slaves eliminate the round-trip delay & synchronize to the Grandmaster. • Frequency is recovered from an accurate time of day reference. • Accuracy is enhanced by: • Frequent packet send rate (up to 128 per second) • Hardware time-stamping (eliminate software processing delays) • Best Master Clock Algorithm (optional, “best” master voted by nodes)
Combination Operation • SyncE as “frequency assistance” to 1588 PRC 1588 GM 1588 Client UTC SyncE Node SyncE Node PTP Stream PTP Stream 1588 Packet Stream SyncE Physical Layer PSN PRC freq • Gives immediate “frequency lock” to 1588 client • SyncE & 1588 functionality may be in the same node/element
G.8271.1 Architecture G.8273.2 T-BC10/ T-TSC Class A T-BC1 Class A T-BC2 Class A T-BC9 Class A T-GM T-GM PRTC PRTC G.8272 End App. 100ns 50ns 1.5us T-BC20/ T-TSC Class B T-BC1 Class B T-BC2 Class B T-BC19/ Class B End App. 100ns 20ns 1.5us Note: The network limit of 1.5us also accounts for other sources of noise (e.g. holdover, link asymmetries, syncE rearrangements) PRTC = Primary Reference Time Clocks T-GM = Telecom Grand Master
Q13 status transport of timing through telecom data networks -transport of frequency -SyncE -1588 done for IP networks, through NEs not processing 1588 messages - Pure frequency T-GM ongoing: G.8266 -transport of phase and time -ongoing - difficult as propagation delay corrupts time -need a two way transport -asymmetry of 2 directions -Testing sync transport over packets - Need for new metrics and news methods
Overview of recommendations G.8260 (Definition & metrics) Agreed Ongoing Definitions /terminology Frequency: G.826x Time/Phase:G.827x Full support assisted partial support G.8261 G.8271 Basics G.8271.1NetwkPDV SyncE J & W Network requirements G.8271.2 G.8261.1 73.1-GM G.8262 (SyncE) G.8272PRTC 73.2 BC & slave 73.2 BC & slave Clock G.8273 G.8263 (slave clock) 73.3 TC G.8266 GM for F G.8273.4 A-PTS ck G.8264 Methods G.8275 G.8265() G.8265.1 G.8275.1PTPprofile1 Profiles G.8275.2PTPprofile2 G.8265.m
I-6 Time profiles • First profile • Full timing support from the network • It means that all NEs process the PTP messages • PTP messages mapped in Ethernet (G.8275.1) • Completed with • G.8272 (PRTC) • G.8273.2 (BC and slave clock) • Will be upgraded with • Stand alone T-GM G.8273.1 • Transparent clocks G.8273.3
I-7 Second time profile PRTC two-way packet timing signals time reference, Tin Packet Master Clock Boundary Clock Packet Slave Clock Tout + • Partial Timing Support profile (PTS) • Work item created in July 2013 • General architectural view (G.8275) • PTP unaware networks separated by T-BCs • PTP messages mapped in IP
I-8 Assisted PTS profile (A-PTS) • New ideas brought in October 2013 • eNode B be synchronized with GPS receivers in priority • PTP will be used only as a backup in case of GPS failure • Operators request A-PTS for end 2014 • Seemed difficult to achieve on time
new PTS profile- « nonA-PTS » New architecture agreed in September 2014 simple PTP over IP based distributed deployment model a grandmaster is deployed inside a building to provide frequency and time synchronization to the small cells within the building or to nearby buildings. Only a few PTP-unaware nodes between the local GM and the slaves on the small cells.
Partial Timing Support profile • New recommendationsrequired • G.8275 • Add the « 1588unaware » equipments in the network architectures for A-PTS & « nonA »-PTS • G.8271.2(A-PTS), G.8271.x(PTS)? • Define the network limits and HRMs • G.8273.2 • Define a new BoundaryClock if needed • G.8273.4(A-PTS), G.8273.y(PTS)? • Defines new clocks if needed • G.8275.2, G.8275.x?? • both A-PTS & PTS based on IP
Future of recommendations? G.8260 (Definition & metrics) Definitions /terminology Ongoing T B D Agreed Time/Phase:G.827x Full support assisted partial support partial support F R E Q U E N C Y : G . 8 2 6 X G.8271 Basics G.8271.1NetwkPDV Network requirements G.8271.y G.8271.2 73.1-GM G.8272PRTC Clock 73.2 BC & slave 73.2 BC & slave ? 73.y G.8273 73.3 TC G.8273.4 A-PTS ck Methods G.8275 G.8275.1PTPprofile1 Profiles ? G.8275.yPTPprofile? G.8275.2PTPprofile2
Links between Q13/15 and fora Operators, manufacturers, std organisations,universities and scientists meet once a year at WSTS in USA and at ITSF in Europe. During these events several sessions addresses: -the needs for synchronization -tutorials on synchronization -the requirements for synchronization -news from GNSS systems -alternative to GNSS: E Loran, .. -information on future technologies -information on deployments -information on sync standards: ITU Q13/15, IEEE1588 -etc…
ITSF (International Telecom Sync Forum) ITSF Website: www.telecom-sync.com Organiser’s Website: www.itsf-conference.com Meets every year since 2001 in November Last event: 4-6 Nov 2014 in Budapest Next event: 3-5 Nov 2015 location tbd WSTS (Workshop on Synchronization in Telecommunication Systems) Depends on NIST-ATIS http://www.atis.org/wsts/cfp.asp Meets every year since 1992in spring Last event: 4-6 June 2014 in San Jose, Ca USA Next event: 9-12 March 2015 in San Jose, Ca USA
Backup slides List of main ITU-T recommendationsrelated to synchronization (updated November 2014)
Where to get the recommendations? http://www.itu.int/ITU-T/recommendations/index.aspx?ser=G
Recommendations for TDM hierarchies • G.803 (03/2000), Architecture of transport networks based on the synchronous digital hierarchy (SDH) • G.803Amd1(06/2005) • G.810 (08/1996), Definitions and terminology for synchronization networks • G.810 Corr1(10/2001) • G.811 (09/1997), Timing requirements of primary reference clocks • G.812 (06/2004), Timing requirements of slave clocks suitable for use as node clocks in synchronization networks • G.813 (03/2003), Timing requirements of SDH equipment slave clocks (SEC) • G.813 Corr1(06/2005) • G.822 (11/1988), Controlled slip rate objectives on an international digital Connection • G.823 (03/2000), The control of jitter and wander within digital networks which are based on the 2048 kbit/s hierarchy • G.824 (03/2000), The control of jitter and wander within digital networks which are based on the 1544 kbit/s hierarchy • G.825 (03/2000), The control of jitter and wander within digital networks which are based on the synchronous digital hierarchy (SDH ) • G.825 Amd1 (05/2008) • G.781 (09/2008), Synchronization layer functions
Recommendations for Synchronous Ethernet G.781 (09/2008), Synchronization layer functions G.8261 rev(08/2013), Timing and Synchronization aspects in Packet Networks G.8262 (07/2010), Timing characteristics of synchronous Ethernet Equipment slave clock G.8262 Amd1 (02/2012), Amd2 (10/2012) G.8263 (02/2012), Timing characteristics of packet-based equipment clocks G.8263 Amd1 (08/2013), Amd2 (05/2014) G.8264 rev(05/2014), Distribution of timing information through packet networks Recommendations for timing over packet networks • G.8260 rev(02/2012), Definitions and terminology for synchronization in packet networks • G.8260 Amd1 (8/2013), Amd2 (5/2014)
Recommendations for the telecom profile for time and phase G.8271 (02/2012), Time and phase synchronization aspects of packet networks G.8271 Amd1 (08/2013) G.8271.1(08/2013), Network Limits for Time Synchronization in Packet Networks G.8271.1 Amd1 (5/2014) G.8272 (10/2012), Timing characteristics of primary reference time clocks G.8272 Amd1 (8/2013) G.8273 (08/2013), Framework of phase and time clocks G.8273 Corr1 (5/2014) G.8273.2 (05/2014) Timing characteristics of telecom boundary clocks and telecom time slave clocks G.8275 (11/2013), Architecture and requirements for packet-based time and phase distribution G.8275.1 (07/2014), Precision time protocol telecom profile for phase/time synchronization with full timing support from the network
Recommendations for OTN • G.8251 (09/2010), The control of jitter and wander within the optical transport network (OTN) • G.8251 Amd1 (04/2011),Amd2 (02/2012), Amd3 (10/2012) • G.8251 Corr1 (02/2012) Recommendations for the telecom profile for frequency only • G.8261 rev(08/2013), Timing and Synchronization aspects in Packet Networks • G.8261.1 (02/2012), Packet Delay Variation Network Limits applicable to Packet Based Methods (Frequency Synchronization) • G.8261.1 Amd1 (5/2014) • G.8263 (02/2012), Timing characterisctics of packet based equipment clocks • G.8263 Amd1 (8/2013), Amd2 (5/2014) • G.8265 (10/2010), Architecture and requirements for packet based frequency delivery • G.8265.1 rev(07/2014), Precision time protocol telecom profile for frequency synchronization
Future recommendations ( provisional titles) • G.8266 Timing characteristics of telecom grandmaster clocks for frequency synchronization • G.8273.1 Timing characteristics of packet master clocks • G.8273.3 Timing characteristics of telecom transparent clocks • G.8273.4 Timing characteristics of assisted partial timing support slave clocks • G.8275.2 Precision time Protocol Telecom Profile for time/phase synchronization with partial timing support from the network
Recommendation on Jitter and wander tests equipments • O.171 (04/1997), Timing jitter and wander measuring equipment for digital systems which are based on the plesiochronous digital hierarchy (PDH) • O.172 (04/2005) , Jitter and wander measuring equipment for digital systems which are based on the synchronous digital hierarchy (SDH) • O.173 (02/2012), Jitter measuring equipment for digital systems which are based on the Optical Transport Network • O.174 (11/2009), Jitter and wander measuring equipment for digital system based on synchronous Ethernet network