Over the course of the last several years, I have spent much time with operators discussing the evolution to packetized backhaul, and I find that a rather interesting trend. I will try to explain through a timeline-based approach:
Focus was less around how to migrate off of TDM infrastructure, but instead extend the life of TDM/ATM infrastructure as long as possible. Techniques like A-Bis/IuB optimization, silence suppression, etc were all the rage, given the pending explosion of 3G (EVDO Rev0/A and UMTS at the time) data usage and the relatively limited reach of Ethernet/packet networks to towers. Given that voice was fairly predictable in nature - fixed and deterministic bandwidth, the influx of data was such a serious concern that operators deployed voice and data over separate leased lines to protect their voice quality.
The focus shifted towards developing strategies and scenarios for evolving backhaul networks off of legacy, circuit-switched (or cell-switched, I supposed) transport mechanisms to more robust, scaleable, and cheaper alternatives - namely, packet transport. There was no question that the operational simplicity, ubiquitous access to vendor products, and monthly transport costs of the packet infrastructure were cheaper than that of the circuit infrastructure, but there was still much debate around the technologies that would be used to deliver the "Service".
Across numerous standards organizations, many protocols and technologies emerged:
Pseudowire technologies - Pseudowire Edge to Edge (PWE3), Circuit Emulation over Packet Switched Network (CESoPSN), Structure-Aware Transport over Packet (SAToP)
Timing technologies - differential vs adaptive, Network Time Protocol (NTP), Synchronous Ethernet (SyncE), Precision Time Protocol (PTP), Timing over IP Connection and Transfer of Clouc (TICTOC)
OA&M - IETF (802.3ag), MEF (E-LMI) and ITU (Y.1731) all played a role here in building different standards for implementing OA&M
Ethernet - Connection-oriented vs Connectionless debate. With Provider Backbone Bridging (PBB - 802.1ah), PBB - Traffic Engineering (802.1Qay), Transport MPLS (T-MPLS), etc - the options were astounding.
So, this period marked the great technology confusion and debate - which technologies would win, and many service providers spent their days writing RFIs/RFPs to understand where the industry was moving.
The technology debate is over - there are clear winners and losers. PBB-TE has mostly gone by the wayside (With Ciena acquiring both Worldwide Packet and Nortel's MEN business, there are not many vendors investing in PBB-TE), T-MPLS has disappeared, and MPLS/MPLS-TP have emerged as the most promising path for building robust, manageable backhaul transport networks. Of course, support for pseudowires will be especially relevant through the transition to All IP architectures like LTE or WiMAX, but this is to be expected during any technology migration.
However, re-emerging in the debate over packet backhaul are the economics. With T1 pricing reaching sub $300 per T1, and 3G networks continuing to rely on oversubscription models on the backhaul network, it might just be that T1s are sufficient for meeting service requirements until 4G networks and devices are widely available. Sure, packet backhaul is getting deployed, slowly, in many areas of the world, but take note that the majority of these deployments fit into one of two categories:
1) Those service providers who are preparing for an imminent launch of a higher-speed technology than HSPA or EVDO. This may be HSPA+, or LTE, or WiMAX - the packet backhaul network is agnostic to the RAN technology.
2) Those service providers who can provide the entire service in-house. So, a mobile SP who relies on their parent company to provide the transport of their backhaul network.
So, why does the transition for the rest of the mobile SPs continue to be slow? A number of factors can be seen:
1) Still some longterm leases out there. While most mobile SP are not signing longterm leases, there are still many that are carrying leases signed nearly a decade ago
2) Technology aversion. There have been prior posts around the impact of LTE on organizational structure. The same holds true for any technology shift - organizations continue to justify a period of time (an "Aversion window", I call it), during which the impact of adopting a technology outweighs the impact of not adopting the technology.
3) Ubiquitous service offering. With mobility, consideration of how the user moves, and ensuring the same level of experience across multiple cell sites is very relevant. For this reason, it is important that every cell tower within a geographic region has a strikingly similar performance level (jitter, latency, delay, packet loss, etc). Given the history of packet (metro/carrier Ethernet) networks to be built for shared access and best effort services, finding a provider who can offer the SLAs required for mobile voice traffic, at a compelling price, is not always as straightforward as it might seem.
This begs the question - is the transition to packet backhaul no longer a technology decision, but instead a business decision? My opinion - yes, but I believe the business decision determines "when", not "if" ("IF" is a foregone conclusion - packet backhaul will dominate in the future).
And the business decision is based on a number of factors:
1) Is the OPEX of the packet network outweighed by the CAPEX cost of ripping/replacing circuit infrastructure with packet infrastructure.
2) Customer experience. As the network becomes dominated by video, oversubscription models may no longer hold in the backhaul network. Customer experience will suffer without a more scaleable transport mechanism.
3) Compettive pressures. With competitors moving to packet backhaul, the longterm OPEX structure they will have enables more aggressive pricing models.
As always, I rely on much of my firsthand experience, augmented with industry research. Given that I do not have full firsthand visibility into every geography or operator, I look to Cisco's SP Mobility Community to provide your thoughts on how the packet backhaul transition will shake out, and what other factors are key.
Does anyone have any simple EEM Scripts handy that can shut down a bgp neighbor based on syslog entry? Right now I have some IPSLA's and track statements setup, but am clueless on the EEM part. (It was so much easier in regular IOS) all I want i...
In the setup, there will be 2 x BGP routers capable of doing up to 400g routing (non-cisco) and 2 more BGP cisco routers capable of doing multiple 10g routing. In day to day operation, definitely, there won't be such a crazy amount of traffic. Just f...
Hi, Is there anyone configured cisco communication manager (CUCM) for direct calls to SIP Trunk provided by the Service Provider (Without Voice Gateway or CUBE)? I am looking for configuration steps Thanks
Hi, I might be missing something, but for some reason IOS XRv 9000 (7.2.2) doesn't seem to impose an inner (VPN) label to transit traffic only. For traffic that originates from the IOS XRv 9000 itself it seems to be working as expected. Sim...