Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Synchronisation and Time Distribution in Modern Telecommunications Networks


Published on

By Sébastien Jobert & Kenneth Hann

The past decade has witnessed a race for networks to provide ever faster communications, interconnecting people via applications used every day by billions of users. Radio spectrum utilisation and synchronisation plays a key role here. But now that Ethernet has won the bandwidth and cost per bit wars, how are base stations being synchronised today?

*** Shared with Permission from ITP Journal Volume 10 | Part 1 - 2016 ***

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Synchronisation and Time Distribution in Modern Telecommunications Networks

  1. 1. THE JOURNAL TJ 22 SÉBASTIEN JOBERT, KENNETH HANN Volume 10 | Part 1 - 2016 SYNCHRONISATION AND TIME DISTRIBUTION IN MODERN TELECOMMUNICATIONS NETWORKS SÉBASTIEN JOBERT, KENNETH HANN The changing picture The past decade has witnessed a race for networks to provide ever faster communications, interconnecting people via applications used every day by billions of users. Radio spectrum utilisation and synchronisation plays a key role here.But now that Ethernet has won the bandwidth and cost per bit wars, how are base stations being synchronised today? For many years,synchronisation was a by- product of the transmission network,but technology changes in both mobile and fixed networks has transformed synchronisation into an essential service.Requirements are becoming more demanding and the traditional means of delivering network synchronisation are evolving. Time synchronisation enables mobile techniques such asTime Division Duplex, Coordinated Multipoint transmission and reception,and Multicast-Broadcast Single- Frequency Network.When mobile networks are precisely synchronised as shown in Figure 1,performance and throughput can be increased. There is a paradox here:while mobile networks have an increased requirement for synchronisation,transport networks,that were once synchronous and therefore capable of carrying frequency synchronisation at the physical layer,have largely lost that capability.So now thatTime Division Multiplexing (TDM) networks are replaced by modern,packet-based, communications networks,how can such a synchronisation service be arranged? In addition to mobile networks,accurate synchronisation is a potential enabler for new paradigms,such as the Internet ofThings (IoT) and virtualisation techniques.This provided motivation to develop new synchronisation technologies for transport networks. Two main candidates were in the starting blocks ten years ago: • Synchronous Ethernet [1] A physical layer technology that inherited the pedigree of the Synchronous Digital Hierarchy (SDH). Central Office Mobile Backhaul Network Common time reference carried over the network µs accuracy µs accuracy Neighboring cells need us accuracy Figure 1:Time synchronisation is essential to some mobile communications technologies.
  2. 2. 23 INFORM NETWORK DEVELOP • IEEE 1588TM [2] A packet-based protocol technology using timestamps,a rookie in telecommunications networks,but a touted successor to NetworkTime Protocol. Synchronous Ethernet WhileTDM networks required a steady rate to avoid slips (corresponding to a buffer that empties or overflows),packet networks such as Ethernet have been designed to work asynchronously,saving on oscillator cost,and removing the need for clock selection and holdover. Although cost reduction was an important factor for network operators,the use of Ethernet broke the timing distribution to the mobile networks [3].The solution was simple – make Ethernet synchronous:the so-called SyncE (Synchronous Ethernet) technology was born! Carrier Ethernet does not require synchronisation as such; the key driver for synchronisation on such networks is only to carry timing up to mobile cell sites.SyncE offers continuity in the synchronisation distribution chain across routers and switches and operators like to use it wherever possible. The standardisation of SyncE was supported by European operators who saw this technology as a way to migrate their networks towards Ethernet while maintaining a link-by-link timing hierarchy fully compatible with SDH (see Figure 2). SyncE ensures that the data bits transmitted at the physical layer are in step with a reference rhythm usually derived from a Primary Reference Clock (PRC).SyncE is therefore a frequency synchronisation solution (although there has been a proposal to expand this to carry also phase/time [4]). Figure 3 illustrates the distinction between frequency THE JOURNAL TJ SYNCHRONISATION AND TIME DISTRIBUTION IN MODERN TELECOMMUNICATIONS NETWORKS In addition to mobile networks, accurate synchronisation is a potential enabler for new paradigms, such as the Internet of Things (IoT) and virtualisation techniques. “ ”
  3. 3. THE JOURNAL TJ 24 SÉBASTIEN JOBERT, KENNETH HANN and phase/time synchronisation. The Synchronisation Status Message that used to be carried as 4 bits in the SDH overhead,can be found in the bowels of SyncE carried via a slow protocol,called Ethernet Synchronisation Messaging Channel.Synchronisation Status Messages indicate when there is a failure in the distribution chain and that the received physical layer signal is no longer traceable to a PRC. Note that,while SyncE does not carry phase/time synchronisation,it is considered a useful technique in combination with IEEE 1588TM in order to maintain phase/time holdover in case of failure.An example of this is where time is set via the PrecisionTime Protocol (PTP) (discussed below),but upon losing the PTP connection,time is advanced using ticks from SyncE.Some industries even combine these two standards to achieve incredibly high time accuracy [5]. SyncE is widely implemented in Ethernet telecoms devices and used in many networks,especially for mobile backhaul. The standards defining SyncE are stable; one new performance enhancement to SyncE clocks is currently being defined in ITU-T to reflect the fact that SyncE implementations typically exceed the previous generation of ITU-T requirements by at least one order of magnitude.In the race for mobile,SyncE was first out of the blocks. IEEE 1588TM – PTP and telecoms profiles An alternative to SyncE for delivering both frequency and phase/time synchronisation is known as IEEE 1588TM which defines PTP. IEEE 1588TM started out as a mechanism for forming a synchronisation hierarchy across an Ethernet network and was developed for applications ranging from instrumentation and measurement to power and automation.Telecoms was not originally represented. IEEE 1588TM was first published in 2002 with a second version ratified in 2008 [2] that includes options for telecoms and a mechanism of making specific industry profiles (telecoms profiles are based on this version).A third version is currently under definition. ITU-T decided to define a PTP profile for frequency distribution in Recommendation G.8265.1 [6].Later,a second PTP profile was defined for phase/time synchronisation in G.8275.1.A third profile is now under definition in the emerging Recommendation G.8275.2. In order to verify that the PTP options are correctly implemented according to these profiles,the IEEE recently launched a certification programme; the first certification programme in the IEEE’s history [7] and it aims to help network operators deploy compliant PTP products.The PTP telecom profiles G.8265.1 and G.8275.1 are currently available in the certification programme,and Volume 10 | Part 1 - 2016 Figure 2: Synchronous Ethernet is a link-by-link solution,all switch and router devices must implement a SyncE clock. Figure 3: Difference between frequency and phase/time synchronisation. Switch/RouterSwitch/Router SyncE aware backhaul network PRC-traceable frequency reference SyncE clock Switch/Router SyncE clock SyncE clock ESMC frames SyncE signal Switch/Router SyncE clock ESMC: Ethernet Synchronisation Messaging Channel
  4. 4. f1 = f2
  5. 5. Frequency synchronisation Phase/time synchronisation
  6. 6. 25 INFORM NETWORK DEVELOP the third PTP profile being defined in G.8275.2 is anticipated in the future. To achieve high accuracy,IEEE 1588TM relies on hardware techniques to timestamp messages very close to the physical layer on both ingress and egress.This allows PTP Sync messages to carry accurate timestamps from a PTP master port to a PTP slave port. For time distribution,a two-way exchange of messages (e.g.Delay_Req/ Delay_Resp mechanism) is required in order to calculate the propagation delay between a PTP master port and a PTP slave port. Ordinary clocks are defined by IEEE 1588TM as having a single port that can act either as a master or as a slave. The source of time for a PTP domain is a master clock known as the grandmaster. IEEE 1588TM defines two other types of clock that are used to build timing networks: • Boundary clock –A PTP clock with multiple PTP ports that can receive,recover and retransmit the timing reference from other PTP clocks (see Figure 4). A boundary clock maintains locally the PTP time. • Transparent clock –A PTP clock with multiple PTP ports that computes the residence time that a PTP message spends inside the network node hosting the transparent clock and inserts this information in the correctionField of the PTP message so that the next PTP clock receiving the message can compensate for this delay (see Figure 5).A transparent clock does not maintain locally the PTP time. The notion of‘timing support from the network’ or‘on-path support’ usually refers to the use of boundary clocks or transparent clocks in the network.G.8265.1 defines a profile with no support from the network (no boundary clock,no transparent clock). G.8275.1 defines a profile with full timing support from the network (telecom boundary clocks must be supported in all the network nodes,transparent clocks are currently considered for the next revision of the profile). G.8275.2 will define a profile with partial timing support from the network (boundary clocks can be supported in some of the network nodes).These are shown in Figure 6. THE JOURNAL TJ SYNCHRONISATION AND TIME DISTRIBUTION IN MODERN TELECOMMUNICATIONS NETWORKS slave masterGM PRTC (GNSS antenna) boundary clock t2 t3 t1 t4 slave t2 t3 t1 t4 t1 t4 GM PRTC (GNSS antenna) transparent clock t2 t3 slave c2c1 c3c4 Figure 4: Synchronisation transfer across a boundary clock (slave and master back-to-back). Figure 5: Synchronisation transfer across a transparent clock (timestamps on transiting PTP packets are corrected with the correctionField value – CF).
  7. 7. THE JOURNAL TJ 26 SÉBASTIEN JOBERT, KENNETH HANN The use of various PTP options also characterises the PTP profiles defined in ITU- T; the main differences between G.8265.1 and G.8275.1 are summarised inTable 1. G.8265.1 was first developed when the telecoms network did not support PTP clocks such as boundary clocks.At this time,some network operators were looking for a solution to carry transparently frequency synchronisation over packet-based leased lines to synchronise mobile base stations. This situation was not ideal,because the PTP messages experienced packet delay variation,also called packet jitter,which is known to degrade the synchronisation quality.However,the synchronisation requirements for the targeted mobile networks (Frequency Division Duplex at this time) were relaxed enough to accommodate this solution.This PTP profile is widely used today where the PTP slave function is generally located in the base station or in a cell site gateway,and the PTP master in a dedicated synchronisation device or in a router.The standards are stable now and no revision is currently planned. G.8275.1 was then developed to address the need for accurate phase/time synchronisation, targeting 1µs accuracy. In order to avoid suffering from packet delay variation effects, it was decided to develop an architecture where all the nodes between the telecom grandmaster and the telecom time slave clock support a telecom boundary clock function.This profile clearly targets networks that have been designed from day-one to support accurate phase/time synchronisation.As this standard is quite recent (approved in 2014), the industry is still on the way to implement this new profile. Pre-standard deployments, significantly in China, show that performance targets can be met also in large networks. Major deployments of G.8275.1 are expected in Europe. The telecom boundary clock function is expected to be supported in a wide range of networks. A new revision of the standard is currently in preparation to add support for transparent clock. G.8275.2 aimstoaddresssomeofthe vulnerabilitiesofGlobal NavigationSatellite System(GNSS)timesources.Oneproposal fromsomeAmericannetworkoperators was to useIEEE1588TM asabackup to Global PositioningSystem(GPS)antennasdeployed ateverybasestation.Asmanynetworksdo not support PTPeverywheretoday,the architectureforthisprofileemploys thepartial timingsupport concept.The notionof‘assisted partialtimingsupport’ (A-PTS) refers tothe casewhereGPSispresent at thebasestation duringnormal operations.(Thisconceptwill be furtherdiscussed in thenext section.) G.8275.2isstill initsearly stagesand is being publishedattheITU-T aswewrite.Some prestandard solutionshavestartedappearing but withno majordeploymentsso far. Architecture evolution From a centralised PRC architecture to distributed Primary Reference Time Clocks (PRTCs) From the days of SDH,synchronisation has been arranged as a tree structure,with the root of the tree,a Caesium PRC,positioned at the core of the network.The branches are the fixed trunks of high-speed links which Volume 10 | Part 1 - 2016 G.8265.1 G.8275.1 PTP clock types Master-only Telecom grandmaster:master-only Slave-only Telecom boundary clock:boundary clock Telecom time slave clock:slave-only Mapping IPv4/IPv6 unicast Ethernet multicast Unicast Slaves negotiate service Not used (fixed rates) negotiation rate using PTP signalling messages Message rates Announce:up to 8 messages Announce:8 messages (per second) Sync,Delay_Req:up to 128 Sync,Delay_Req:16 messages messages Table 1: Comparison of main PTP options for G.8265.1 and G.8275.1. PTP unaware backhaul network Timing reference PTP in end-to-end mode, ITU-T G.8265.1 telecom profile PTP aware backhaul network Timing reference PTP with full timing support from the network, ITU-T G.8275.1 telecom profile T-BCT-BCT-BCT-BC PTP unaware backhaul network Timing reference PTP with partial timing support from the network, ITU-T G.8275.2 telecom profile, under study in ITU-T PTP unaware network “G.8265.1-like” communication“G.8265.1-like” communication Master Telecom Grandmaster Telecom Time Slave Clock Slave MasterSlave Telecom Boundary Clocks Boundary Clock Figure 6: Status of the IEEE 1588TM certification programmes for telecoms networks.
  8. 8. 27 INFORM NETWORK DEVELOP fan out to thousands of mobile base stations at the edge.The synchronisation hierarchy has always been constrained to a tree structure – avoiding timing loops – even though the networks are typically implemented as rings. Since today the required synchronisation service is typically time (and not frequency only),the PRC is being replaced by the PRTC. Also,the availability of low cost synchronisation solutions in small foot-prints has made it attractive to move the PRTC closer to the edge of the network. Whereas previously,a small country may have had a handful of PRCs shared among all the operators for 3G mobile networks,now a single operator may have a few thousands PRTCs in aTime Division LongTerm Evolution network.This architecture reduces the need to transport synchronisation over long network paths and is therefore attractive when very high performance is needed because the time source is now positioned close to the mobile base station.PRTCs have also become much smaller in size.Today,a PTP telecom grandmaster product serving many mobile base stations can be implemented as a small form pluggable module (see Figure 8) Opportunities and challenges with Partial Timing Support (PTS) For decades,the telecoms network engineer has been shackled by reliability – conservative design rules,safety margins and ‘Five Nines’ of network availability.But now, some situations might permit relaxing these requirements.There seems to be a growing trend of taking calculated risks and using solutions that will work under the majority of cases,but cannot be guaranteed by design. One such proposition is the concept of PTS. Let’s first look at the motivation,and then examine the risks and rewards of PTS. A modern network can support high accuracy time synchronisation,but the majority of networks have been built over many years and consist of equipment that was not designed for time synchronisation (i.e.does not support a boundary clock or transparent clock function).However,even a legacy network forwards packets.What happens if we carry time synchronisation transparently over such a network – in short,will it work? If it‘works’,we have saved the trouble and expense of adding time synchronisation support into the network. If it does not work, however,the quality of wireless transmission will be impacted. The challenge,therefore,is in being able to measure the time accuracy at the remote end point of the network by comparing it to a reference.In practice,the only reference for accurate time measurement is a GNSS- based receiver.So a technician jumps in his white van and drives to the remote site, erects a temporary GNSS antenna and uses some measurement equipment to determine if the time accuracy of the PTS PTP service is within the required limits.This is an echo of the days when the same technician was measuring the quality of the Plain Old Telephone Service as part of theADSL installation.We can see that just as Internet deployment quickly became technician-free, so the time synchronisation service needs to be automated. So,what if we run the PTS and perhaps measure a small percentage of cases only? This saves significantly on installation costs and,since the networks are built from similar components and structures,it gives a good indication.The risks of this type of survey approach are asymmetric cable installations (250m cable ≃ 1µs),asymmetric equipment (may change with load,reset,etc.) and asymmetric routing (forward and reverse paths). The keyword in all of these cases is ‘asymmetric’. PTP assumes that the paths are symmetrical and,to the extent that they are not,then an error is introduced. If the total asymmetry can be bounded (by type of equipment, number of hops,fibre installation practices, constrained routing practices),then PTS can offer significant cost savings.But this is not at all a straightforward exercise.The THE JOURNAL TJ SYNCHRONISATION AND TIME DISTRIBUTION IN MODERN TELECOMMUNICATIONS NETWORKS PTP Remote Slaves PTP Local Slave GNSS antenna Aggregation switch with pluggable GM Figure 8: Miniature PTP grandmaster providing time synchronisation at the edge of the network. Figure 7: G.8265.1 was a rather different application of IEEE 1588TM . CartoondrawnbyKennethHann’sdaughterTanja.
  9. 9. THE JOURNAL TJ 28 SÉBASTIEN JOBERT, KENNETH HANN question for the operator is:can the risks be bounded within safe limits?Another issue may be that the requirements for time synchronisation are tightening and what is 1.5µs today may be 300ns tomorrow.One European operator had the view that taking such a risk with PTS would be like swimming with sharks (Figure 9). There may be some applications where PTS can be used to benefit.The next section provides an example. Assisted Partial Timing Support (A-PTS) – Combining PTS and GNSS On the edge of the network there is a high reliance on direct GNSS which has become the de-facto solution for mobile networks requiring time synchronisation. Recently, susceptibility of GNSS receivers to jamming has become a major concern and has led to a proposal to combine a PTS solution with local GNSS.This solves the main problem that we already identified Volume 10 | Part 1 - 2016 T-GM SM A-PTS Clock Figure 10: A-PTS provides resiliency against local GNSS failures. PTS Best-effort Beach
  10. 10. Try G.8275.1 my boy! Figure 9:Time delivery when swimming with asymmetry sharks! CartoondrawnbyKennethHann’sdaughterTanja.
  11. 11. 29 INFORM NETWORK DEVELOP with PTS – that of needing a reference to check or calibrate the PTP path. So, the time derived from PTP can be compared with the time from GNSS.Any fixed offset can be measured and compensated, which in turn allows PTP to provide accurate time should the GNSS fail as shown in Figure 10. Forward looking – synchronisation for the IoT There is much speculation as to the synchronisation requirements of the devices and applications making up the collective IoT and the benefits of having high accuracy time available to the billions of devices making up the IoT. Clearly if time is ubiquitously available, there can be huge changes and improvements in the way things are done – for example, programming languages with a concept of time, programme counters in central processing units where real-time at the nanosecond level is available, cyber- physical systems where events happen at precise time and allow for distribution with precise control. However, all this tends to assume that precise time is pumped across the Internet at high accuracy, with reliability and security – and for free. On the other hand, if time is such a valuable and prestigious service, and could be made available, wouldn’t there be users ready to pay a reasonable price for the service? Such a premium-time service would have to provide a better quality of service compared with a time being carried transparently over a data connection and could be provided by network operators, perhaps in co-operation with national physics laboratories. AUTHORS’ CONCLUSIONS The major synchronisation technologies of SyncE and IEEE 1588TM address different use cases. SyncE offers traditional frequency distribution and takes a supporting role in providing time holdover for PTP systems. IEEE 1588TM is still under development in multiple standards bodies, with specific telecoms profiles defined in ITU-T standards. Combined together, they can achieve accurate and reliable time synchronisation. Applications are now waiting.There’s a whole world still to synchronise! THE JOURNAL TJ SYNCHRONISATION AND TIME DISTRIBUTION IN MODERN TELECOMMUNICATIONS NETWORKS ABOUT THE AUTHORS Sébastien Jobert Sébastien is a telecommunications expert involved for over 10 years in the standardisation of ITU-T Synchronous Ethernet and IEEE 1588TM technologies.He is co-author of a book and of several patents. He has been the editor of various international standards and test suites in ITU- T,IEEE and MEF and led the first certification program of IEEE’s history.Sébastien was senior director of engineering for a certification laboratory based in the Silicon Valley (Iometrix),and a distinguished network expert with Orange,where he focused on QoS,cloud and mobile technologies. Kenneth Hann Kenneth is Senior Director Oscilloquartz,Finland.He was founder and CEO ofTime4 Systems with 30 years’ experience in telecommunications from Nokia,Martis andTellabs.For the past decade Kenneth has focused on innovative synchronisation solutions for packet- networks and has been actively involved in the development and standardisation of both synchronous Ethernet,and IEEE 1588TM . Kenneth has a number of synchronisation- related patents.His daughterTanja draws nice clock characters. ITPINSIGHT CALL Want to talk to the author? To discuss this article and its content, join in the ITP Insight Call on 1 June. To book onto the call visit: ABBREVIATIONS A-PTS Assisted PartialTiming Support GNSS Global Navigation Satellite System GPS Global Positioning System IoT Internet ofThings PRC Primary Reference Clock PRTC Primary ReferenceTime Clock PTP PrecisionTime Protocol PTS PartialTiming Support SDH Synchronous Digital Hierarchy TDM Time-Division Multiplexing REFERENCES 1. Ferrant,J-L.,et al. Synchronous Ethernet:A Method toTransport Synchronization.IEEE Communications Magazine.Sep 2008 2. IEEE Std 1588TM -2008.IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems. Jul 2008 3. Ferrant,J-L.,et al. Synchronous Ethernet and IEEE 1588TM in Telecoms:Next Generation Synchronization Networks.ISTE - Wiley,ISBN 978-1-84821-443-9. Jun 2013 4. Hann,K.,Jobert,S.,and Rodrigues,S. Synchronous Ethernet toTransport Frequency and Phase/Time.IEEE Communications Magazine. Aug 2012 5. Moreira,P.,et al.‘White rabbit:Sub- nanosecond timing distribution over Ethernet. International Symposium on Precision Clock Synchronization for Measurement,Control and Communication.Oct 2009 6. Ferrant,J-L.,et al. Development of the First IEEE 1588TM Telecom Profile toAddress Mobile Backhaul Needs. IEEE Communications Magazine. Oct 2010 7. Eidson,J.C.,et al. IEEE-SA Conformity Assessment Program for IEEE 1588TM in Mobile Networks.IEEE-SAWhite Paper.Nov 2014.