R-Evolution of the Service Provider Networks

There was a lot of buzz around several themes this week at the LTE World Summit event. In previous posts I mentioned virtualization through NFV, VoLTE, and LTE roaming as examples. All of these technologies and concepts are extending the function and design of the service provider environment. There is a binding thought in everyone's minds with these and other discussed topics. The service provider networks are changing and will never be the same. But is this a revolution against the staid incumbent design or just an expected rung in the evolutionary ladder?

Expected Evolutionary Step

LTE roaming is an expected development just like the current roaming agreements that exist between the 2G and 3G networks. The LTE networks though, with the change in the signaling technology from SS7 to Diameter, have created an additional burden for the LTE networks to be able to allow roaming relationships to the legacy networks. This means that the peering between the different networks of the service providers needs to be able to translate between the two protocols. This created the need for interworking function (IWF) within the Diameter edge agent (DEA) to provide that capability.

Changes do not Necessarily Mean a Revolution

VoLTE is another technology that was expected and is now being implemented in with the service providers. VoLTE is designed to replace circuit switched voice calls that were based on non-IP technology by utilizing the same infrastructure that the data uses in the network. The IMS infrastructure to support VoLTE communications as well as other rich communications suite (RCS) services supports this transition by leveraging Diameter messaging and the SIP protocol.

There are few VoLTE deployments today as the service providers look to see how to effectively deliver the service and determine how they will manage and properly bill for this capability. As more VoLTE deployments occur and service providers learn through trial and error what works and what does not, expect the design and support to start becoming standardized.

But Revolutions do Come Every Now and Then

The NFV movement initiated by the service providers has been a visionary game changer so far. They are looking to deploy typical core network services in a virtual fashion leveraging software modules residing on common off-the-shelf hardware. The vendors have responded in kind by creating and delivering virtual versions of almost their entire portfolio of products eliminating the requirement for proprietary hardware.

But as most revolutions go, there are always gaps in the plan and execution. For NFV to be successful, everyone agrees that a proper management and orchestration solution is necessary to enable the benefits of the NFV architecture – agility and elasticity. The ability to bring services to market quickly and efficiently is critical to the service provider business. Resource flexibility and the abstraction of the services through dynamic resource allocation via an automated orchestration engine delivers a more robust and reliable network.

Unfortunately there is not a current model or implementation of a successful multi-vendor management and orchestration system today. In fact, it will probably take a significant amount of time for one to become available due to the complexities needed in the heuristics and analytics and the ability to support a multi-vendor ecosystem.

Change is Good

But whether we consider these technologies and others to be evolutionary or revolutionary, they all have positive benefits and there are many different visions of how they can enhance the service provider business and ultimately benefit the consumers. The telecommunications market has changed dramatically many times due to technological innovations and insights over the past 100+ years ever since Mr. Bell made the famous call, ‘Mr. Watson—Come here—I want to see you’. The industry will continue to change and this will only benefit everyone.

BTW – Since we are in Amsterdam, Netherlands beat Chile on Monday.

Published Jun 25, 2014
Version 1.0

Was this article helpful?

No CommentsBe the first to comment