Don't Forget to Look Back When Running Forward
Posted by Gil Epshtein on 4 Jul 2010
How many times have you found yourself struggling to achieve something, only to forget what prompted you to try it in the first place? Isn’t that the case with the hype surrounding the shift to a packet-based infrastructure for wireless backhaul?
Let’s get back to basics for a moment. The incentive to find alternatives for the well-proven TDM-based infrastructure was to reduce the cost-per-bit to address the ‘Catch-22’ syndrome that plagued service providers: to increase revenues, you must offer new bandwidth-intensive services. But it’s those services that increase the load on an already congested network, necessitating a substantial increase in capex. And in the end, all potential revenue is eaten up.
Simply stated, exponential traffic explosion (mainly from data services) and the linear linkage between traffic volume and leased infrastructure costs make it nearly impossible to grow revenues. Since data revenues are not linked to traffic volume (it’s a flat rate in many cases), turning up new services could actually result in losses for the service provider. Because it’s clear that new services should be affordable for service providers and end-users alike, the need arose for an infrastructure that’s capable of providing lower cost-per-bit. So, then, since many of the new bandwidth-intensive services were packet based, it was only natural that the providers turned to packet-based infrastructures. Given the decreasing cost and increasing capacity of the data equipment in the LAN, service providers thought their Catch-22 was solved. They had found a ‘magical’ solution that could support higher bandwidth with lower cost-per-bit, and it was already available and based on well-proven technology. Or had they?
Problems first surfaced when operators began using the same equipment they had in the LAN for transport. Gaps popped up all over the place…no quality of service guarantees…a lack of fast and assured protection and restoration schemes…scalability and synchronization issues. In short, the gear wasn’t carrier grade. It lacked the features that make transport networks so reliable. Features that ensure that when you pick up a phone you hear a dial tone – and that the call quality is good and carried out without interruption. Indeed, the cost-per-bit may have been lower, but whether the bit would reach its destination (so operators could charge for it) was not certain.
To address these gaps, Carrier Ethernet equipment was developed. It promised the best of both worlds: low cost and high bandwidth with carrier-class performance. However, these carrier-class features weren’t free, and the thin and low-cost products become fatter and more expensive. Then another problem reared its head. As the industry shifted to more and more packet-based services, the revenue-generating legacy services did not go away. And while delivering Ethernet over TDM is a simple thing, delivering TDM over Ethernet has proved to be much more complex. In the case of wireless backhaul, the lack of native synchronization was a showstopper, and only now have the standards stabilized enough to support large-scale networks. Bottom line: the economies of scale that drove down the cost of data products lost much of their impact when the carrier-class transport products evolved.
So, then, am I suggesting that we abandon packet-based infrastructure altogether? Not at all. What I’m saying is that in the race for a packet-based utopia, where we’re running full speed ahead and dealing with all the bumps along the way, we shouldn’t forget to look back and ask…did we achieve what we originally set out to accomplish? I believe the answer here is ‘not always.’ Yes, Carrier Ethernet products that are built with a transport-oriented mindset, like those developed by ECI, live up to their promise. But is this true for every deployment scenario and business model?
What I encourage service providers to do when looking for ways to cope with new service challenges is to keep these basic questions in mind:
- Can it cost effectively support new as well as legacy services?
- Will it be able to handle future capacity demands?
- Does it offer “SDH like” performance and management in terms of reliability and ease?
The answers to these questions should not be driven by technological hype, but rather by bottom-line calculations. In many cases, a total cost of ownership (TCO) analysis will show that it’s better to leverage an existing TDM infrastructure, adding new services when appropriate. This doesn’t mean that operators should keep delivering Ethernet services over SDH/SONET (EoS); rather, they should evolve their existing TDM-based machines into hybrid machines that are capable of supporting TDM and Ethernet natively. The TDM services and revenues can be left untouched while new packet-based services are handled and carried natively over Ethernet using the same network elements and working procedures. Operators should make the move to a pure packet-based infrastructure only when it makes sense from an economic point of view, usually when the network becomes congested or in greenfield situations where all or most of the traffic is packet based.
Is leveraging the SDH/SONET infrastructure a sexy approach? Maybe not, but it is cost efficient.