& cplSiteName &

Backhaul Timing: Anything But Synchronized

Heavy Lifting Analyst Notes
Heavy Lifting Analyst Notes
Heavy Lifting Analyst Notes
1/26/2010

For those who can remember it, there was a time when cellular backhaul was boring. Not these days. Backhaul has been one of the hottest segments in telecom for three or four years now, and so it remains. One segment of the evolving cellular backhaul technology story that is only now about to go through the same transformation cycle is network synchronization.

While some CDMA operators use GPS for synchronization, most cellular networks today derive their synchronization from an E1 or DS1 at the cell site. But deploy packet backhaul at the cell site – as most operators are doing to support the waves of 3G data that are hitting their base stations – and a whole different modus operandi presents itself. Or more accurately: a whole range of different modi operandi.

Remove the DS1 or E1 from the cell site altogether without introducing a new synchronization solution, and the mobile operators' voice service will deteriorate – imperceptibly to start with, perceptibly over several weeks or months. That's why the majority of cellular operators still prefer to leave DS1s or E1s at the cell site for voice services and synchronization when they introduce packet backhaul: That way, they get some of the cost savings associated with packet transport for backhauling their data traffic, while leaving their voice network undisturbed.

The issue with that approach is the "some" in "some of the cost savings." This is because leaving TDM at the cell site when introducing packet backhaul for 3G data traffic can reduce the scope for cost savings by as much as a third compared with an all-packet backhaul environment.

The two standards that have been developed to address synchronization in this environment are Institute of Electrical and Electronics Engineers Inc. (IEEE) 1588v2 and the International Telecommunication Union (ITU) G.8261 Synchronous Ethernet standard.

On paper, most operators that Heavy Reading has worked with – particularly those in mature markets – clearly prefer Synchronous Ethernet. This is because it conforms to the L1-based approach to synchronization that they are used to with TDM. The big challenge with Synchronous Ethernet, however, is that it needs to be supported throughout the network, requiring upgrades to a large number of network elements. So while some big incumbents, such as Deutsche Telekom AG (NYSE: DT) and BT Group plc (NYSE: BT; London: BTA) are moving ahead with deployments of Synchronous Ethernet in the coming year, the standard is still some way off from scaling in large commercial volumes from a global perspective.

The IEEE's 1588v2 standard is a Layer 2-based solution. There are several working implementations of it in live commercial service already today, such as by Vodafone Portugal and Telus Corp. (NYSE: TU; Toronto: T) (Canada). But again, there are challenges with 1588v2. The first is that as a Layer 2-based solution, 1588 requires a first-class Layer 2 network underlying it to perform optimally. A Ferrari driven over a rugged terrain is still a Ferrari – but through no fault of its own, it won't perform as it's supposed to. Moreover, lack of standards in the implementation of the 1588 algorithm itself means that while intensive bilateral interoperability efforts between two vendors can result in a workable solution, scaling that up easily into a mass market of networking products whose 1588 implementations are all interoperable is taking longer than many operators would like.

Two years ago, a lot of operators were giving Ericsson AB (Nasdaq: ERIC) a hard time for advancing its own proprietary synchronization solution that leverages NTPv3. At group level, for example, Vodafone Group plc (NYSE: VOD) wouldn't hear of it. Now Ericsson has Telstra Corp. Ltd. (ASX: TLS; NZK: TLS) (Australia) and KPN Telecom NV (NYSE: KPN) (Netherlands) among a dozen or so operators that are deploying it.

Operator and vendor complaints that proprietary approaches could prove difficult to operationalize and will create vendor lock-in may contain a large grain of truth in many cases. But in the context of the challenges that are also presented by other standards-based alternatives, these criticisms don't carry quite the same weight as they did two years ago.

Finally into the mix we need to throw the Long Term Evolution (LTE) requirements to support phase as well as frequency and time-of-day synchronization. This may only be required for Network MIMO and MBMS-SFN in future 3rd Generation Partnership Project (3GPP) releases, so it is debatable exactly when this will be required, or even whether some cellular operators will need it at all. Then again, any operator looking to support phase synchronization will find that the only candidate technology with a proven track record in supporting it is GPS. Phase synchronization is something that Synchronous Ethernet is never likely to support, and the IEEE has barely started to look at how it might be supported in 1588.

This support for phase synchronization as well as frequency and time, combined with the slow rate at which other standards-based packet synchronization solutions are scaling, explains why GSM and W-CDMA operators throughout the world are increasingly open – or to put it another way, less opposed – to leveraging GPS or other future Global Navigation Satellite Systems (GNSS) for their packet backhaul synchronization.

The challenges that operators face in selecting a synchronization strategy for packet backhaul – and then scaling it – will be the subject of one of the panel sessions at Light Reading's upcoming virtual tradeshow on February 4, Packet Backhaul 2010: Scaling Up to Bring Costs Down. Hope to "see" you there!

— Patrick Donegan, Senior Analyst, Wireless, Heavy Reading

(12)  | 
Comment  | 
Print  | 
Newest First  |  Oldest First  |  Threaded View        ADD A COMMENT
Page 1 / 2   >   >>
pdonegan67
pdonegan67
12/5/2012 | 5:05:18 PM
re: Backhaul Timing: Anything But Synchronized


Written in January 2010, my column above was clear at that time that operators "clearly prefer Synchronous Ethernet" among standards-based synchronization solutions for Ethernet backhaul.  And I had very recent research evidence at the time time to back that up.


Over the last 18 months, however, market sentiment has shifted. There is now at least as much, if not more, momentum behind the IEEE 1588v2 standard as there is behind Synchronous Ethernet. 


One key factor in bringing about this shift has been the ITU's commitment to develop a roadmap for phase/ time as well as frequency synchronization for IEEE 1588v2 whereas there is no such roadmap for Synchronous Ethernet which will continue to support only frequency synchronization.


The level of industry energy going onto 1588v2 for Ethernet backhaul is increasing markedly now - for example via Symmetricom's SyncWorld partnership program as well as the IEEE's 1588 Conformity Alliance which is about to begin conformance testing for 1588v2. The Conformity Alliance also has plans to begin serving as a conformance test house for the Synchronous Ethernet standard as well, providing a potentially valuable one stop shop for equipment vendors.


Again I have recent new research evidence to support this recent shift in sentiment towards 1588v2 and it will be used in both my upcoming White Paper and Webinars relating to Light Reading's new 1588v2 Industry Initiative. When it comes to choices of synchronizaton techniques, "Any 2 Will Do" is becoming a new industry mantra. This highlights that whilst each of the various new synchronization approaches have their own strengths, on their own they can each have their limitations as well.


 


 


 

opticalwatcher
opticalwatcher
12/5/2012 | 5:05:17 PM
re: Backhaul Timing: Anything But Synchronized


As for Synchronous Ethernet and 1588v2, why not both? It seems to me that it is quite a lot simpler and less error prone to keep the frequency synchronized using Synchronous Ethernet. Just about all you have to do is lock to the incoming Ethernet clock, whereas with 1588v2, there is all kinds of message passing, averaging and filtering, and many ways for it to go wrong.


And once you are synchronizing frequency with Synchronous Ethernet, then 1588v2 becomes much simpler as a method for synchronizing time.


Any idea as to whether operators might go in this direction?

pdonegan67
pdonegan67
12/5/2012 | 5:05:17 PM
re: Backhaul Timing: Anything But Synchronized


Yes, absolutely. Maybe I should have spelt out the "Any 2 Will Do" trend I mentioned at the foot of my last message in more detail. Increasingly many operators see that no one solution will provide a full-proof solution for all their current and future cell site synchronization requirements. Hence increasingly operators are looking at deploying two in tandem - such as the Synch E and 1588v2 combo that you allude to.

joferrei
joferrei
12/5/2012 | 4:44:06 PM
re: Backhaul Timing: Anything But Synchronized


If plain old PDH TDM (T1/3, E1 etc.) did the synch job just fine, why not then just use the available higher bandwidth synchronous carriers - SONET/SDH or OTN?

These can carry any packet traffic just as well: direct IP, or over MPLS(-TP), Ethernet or any L2 protocol if needed.

If the volumes eventually define the hardware cost per bit, and the operational complexity largely the life time costs of the network, why wouldn’t the operators stick to the known working synchronous carrier signals?

That is, if the operators continued to stay with SDH based physical media (possibly a version that is stripped down to plain packet transport without all the legacy options), its cost per bit should be economical, while the need for the cumbersome efforts to retrofit synchronization features to non-TDM based carrier signals and to deal with their interworking issues would be eliminated.

Just thinking that when did it actually make sense in large scale network operations to add complexity for given basic function (e.g. synchronization distribution) when there was a know working base solution...

paolo.franzoi
paolo.franzoi
12/5/2012 | 4:44:05 PM
re: Backhaul Timing: Anything But Synchronized


 


2 Things:


 


1 - The article did not mention Tellabs which is doing timing in packet networks all over the world with many Tier 1s (including BT and AT&T) and is actually the leader (last count I remember them talking about was 80+ networks).  So, I think the issue is that there is not an effective 1588 implementation.  There are other working implementations in mass deployment today.


2 - Ethernet is cheaper than the alternatives, especially virtually all the added bandwidth is for data and NOT for voice.  OTN is way over the top, we are talking 100Mb/s to a cell site for now, 1 Gb/s is a long way in the future.  So OTN is out.  SONET/SDH is just too expensive.  


So, the article I think presents this is a lot bigger problem than it is in the real world - unless you thought the world was going to be built today on 1588.  


seven


 

pdonegan67
pdonegan67
12/5/2012 | 4:44:05 PM
re: Backhaul Timing: Anything But Synchronized
Regarding Tellabs, every vendor in the backhaul space supports at least one timing solution. And whilst Tellabs does have a market leadership position in terms of customer adoption of the 8600 for mobile backhaul, IGÇÖve seen nothing to suggest that their timing solutions are any better or worse than anyone elseGÇÖs. BT isnGÇÖt a good example. As of very recently, the solution they are delivering to Vodafone in the UK still uses an E1 for synchronization. And thatGÇÖs hampering BTGÇÖs efforts to turn a profit on that deal. As for AT&T, IGÇÖll be asking Yiannis Argyropolous about their approach to synch in the opening carrier panel at our Virtual Trade Show on February 4th. I doubt AT&T is as comfortable with the available options as you seem to imply but letGÇÖs see.
paolo.franzoi
paolo.franzoi
12/5/2012 | 4:44:03 PM
re: Backhaul Timing: Anything But Synchronized


 


Patrick,


Your article implies that there are only 12 networks and they are only done by the big E.


AT&T has a multi-vendor environment with Cisco as the other vendor (and they as well have a method to make this work).  So, I think that there is a lot of skepticism around 1588 but Ethernet backhaul proceeds apace.  The biggest issue is still availability of Ethernet physical pipes.  


Since Tellabs has already announced revenue from BT, you probably need to take another look there - like perhaps Ethernet Radios for backhaul.


 


seven


 


 

pdonegan67
pdonegan67
12/5/2012 | 4:44:02 PM
re: Backhaul Timing: Anything But Synchronized
Tellabs is in the BT network and no doubt they are recognizing revenue from the account. But as of very recently the synchronization in that deployment leverages an E1 at the cell site and not the synch solution of Tellabs or any other vendor.
joferrei
joferrei
12/5/2012 | 4:44:02 PM
re: Backhaul Timing: Anything But Synchronized


Yes, the availability of the (sub-physical-layer, L0) pipes supporting 100Mb/s and higher bandwidths to the cell sites is the #1 cost problem: the cost of installing fiber will largely dominate the upfront cost of getting the required (3/4G) bandwidth connectivity to the cell sites. And the cost of running fiber to the cell sites is the same regardless of the L1/2 protocols used; pure-packet protocols like Ethernet do not bring any meaningful savings here.

But once there is the business case (read: necessity) to run the fiber to cell sites, I don’t see the reason to move from the existing synchronous L1 protocols to new ones, especially ones to which the synchronization features would need to be retrofitted.

One can carry IP/MPLS packet traffic just the same over POS as over optical Ethernet, and in current hardware design, the physical hardware (bit transparent optical transponders combined with a large FPGA) will be just about the same regardless of the digital protocol layers used.

So I would tend to prefer existing synchronous carrier signals as long as the fiber goes (or there is biz case to run fiber), and microwave and/or plain old PDH copper (T3) from there on.

Reasonings for alternative approaches welcomed too.

opticalwatcher
opticalwatcher
12/5/2012 | 4:43:58 PM
re: Backhaul Timing: Anything But Synchronized


I don’t see the reason to move from the existing synchronous L1 protocols to new ones, especially ones to which the synchronization features would need to be retrofitted.


Newer basestations are Ethernet based (and most are because T1/T3 is too slow) and will increasingly have Synchronous Ethernet and 1588 built in, since it costs very little to do so. I think it is your POS idea that would require a lot of retrofitting of emerging Ethernet based backhaul and basestation equipment.


My understanding is that at present, basestations that are installed in locations with only an Ethernet connection are using GPS for synchronization and time of day. As Synchronous Ethernet and 1588 are more fully developed, they can save the cost and reliability concerns of using GPS and have cheaper basestations.





Page 1 / 2   >   >>
More Blogs from Heavy Lifting Analyst Notes
Fixed broadband service provider developed its own OSS and BSS systems, a move that gives it cost efficiencies compared with traditional systems and advanced data analysis capabilities, according to its executives.
Among the many considerations facing network operators as they make the leap into the 5G world, service assurance is right up there with the toughest, as CSP executives will explain at the upcoming Software-Driven Operations summit in London.
The Eurasian operator has flipped its digital strategy to give greater autonomy to its geographically diverse operating companies.
With hype around all things 'edge' on the rise, Heavy Reading launched a research study to gain a realistic understanding of how edge computing will affect the future of network connectivity.
There's early evidence that network operators are getting to grips with the opportunities associated with 5G edge cloud architectures.
Featured Video
Upcoming Live Events
October 22, 2019, Los Angeles, CA
November 5, 2019, London, England
November 7, 2019, London, UK
November 14, 2019, Maritim Hotel, Berlin
December 3-5, 2019, Vienna, Austria
December 3, 2019, New York, New York
March 16-18, 2020, Embassy Suites, Denver, Colorado
May 18-20, 2020, Irving Convention Center, Dallas, TX
All Upcoming Live Events