Becoming More Agile with IMS

By Ronald Gruia      

S ervice providers are increasinglyconcerned with the fact that commoditized voice and basic data services are simply not enough to stem the tide of declining average revenue per user (ARPU) and rising subscriber churn.Wireline carriers are worrying about the advent of new competitors, including MSOs and other “over the top” new market entrants such as Google, MSN/ Microsoft (News - Alert) , Skype/e-Bay,Vonage and Yahoo.Meanwhile, mobile operators are facing challenges such as lower margins for voice service, limited uptake of data services, high subscriber penetration rates, and many of them have yet to experience a better return on their third generation network investment. Furthermore, all service providers are increasingly under pressure from these “over-the-top” players to rapidly introduce new custom apps to react to new opportunities, given the pricing erosion that has become
prevalent in the industry. One of the key promises of IMS that it enables telcos to achieve a better service velocity, or the ability to quickly and cost effectively introduce new multimedia applications within their networks. These new services are much simpler to implement and more efficient in terms of performance. The key factors that drive this service velocity are the re-utilization of key elements in the control layer (such as the CSCF and HSS) and the ability to fit ready-made applications onto the IMS network.

Therefore, IMS can enable service providers to quickly deliver new blended
applications such as voice and video or voice and gaming. Since SCEs (Service
Creation Environments) are inherent in most IMS implementations, carriers can
rely on these rapid service creation environments and SIP to add and drop
service features, application components, and session data. This significantly
raises the potential for launching new “combinational” services.

The Role of the SDP

Closely tied with the development of the IMS is the SDP (Service Delivery
Platform) opportunity. An SDP can be thought of as an overlay system for the
rapid and cost-effective delivery of advanced services. The SDP concept
incorporates multiple components for execution, management, provisioning and
billing of end-user services that address market-specific segments. The SDP
model is intrinsic to IMS, since the notion of rapid service creation if
fundamental to the IMS market. Conversely, SDPs also enable the rapid
decommissioning of an offering in the event that it is not widely adopted by the
market, which is another IMS requirement.

Despite the close relationship between SDPs and IMS, there are many service providers opting to initially roll out an SDP, even prior to deploying IMS. IMS enables the disaggregation of transport, control and application. An SDP allows the rapid deployment of subscriber services in a controlled manner. Therefore, since the SDP resides entirely on the application layer, it can be initially deployed to quickly roll out new “IMS-ready” services without necessarily requiring the existence of control elements of the IMS architecture.Hence, the SDP can serve as a catalyst to IMS, since it will enable operators to implement new services quicker, and use the revenues generated by these new applications to later finance IMS equipment purchases. In turn, the IMS equipment can later enable carriers to achieve operational savings.

These OPEX (News - Alert) savings can be impressive, as evidenced by an example from the U.K. division of Cable & Wireless, which estimates that IMS can lower OPEX by at least 25% when compared to a legacy stovepipe implementation. Another example comes from Lucent Bell Labs, which estimates that IMS can improve a service provider’s operating costs by at least 20% to 25% after the first year of deployment.

Wider Developer Base

Besides the advent of SDPs, another IMS factor driving service velocity is the openness of the underlying protocols. SIP and the web-based model are widely known, thereby shortening the required investment of a programmer to develop new applications. The web-based programming models (XML/VXML, etc.) are well known to most developers, and in case they are not, it would not take them more than 3-6 months to become savvy programmers. By contrast, the proprietary languages of IN would take a lot longer time commitment (at least 12 to 18 months until a developer would become fully proficient).

By relying on open protocols such as SIP and XML, instead of being faced with legacy systems where each service had a specific
protocol and interface to the network, third party developers can write applications much more efficiently. Another benefit is
reduced CAPEX, since applications can potentially become cheaper to implement, given a wider availability of developers.
Furthermore, since IMS enables the re-utilization of common functions such as billing, QoS and presence across all
applications, the incremental cost per service goes down over time. The previously mentioned UK division of Cable &
Wireless estimates that IMS can reduce CAPEX by roughly 35% to 40% for each service deployed.

The IMS design also cuts down programming complexity. Most developers typically deliver ten lines of code per day (on average),
or 50 lines in the best-case scenario (independent of the language An SDP can
be thought
of as an overlay system
for the rapid and costeffective
delivery of advanced services.used: C++, Java or assembly). A low-level code
obviously entails more branches, which increases complexity and test cases while decreasing the overall quality level of the software. (see footnote 1) In addition, the new IMS programming model achieves the application logic separation from the user interface, and “stateless servers”, so scalability is also much more realistic. The end result is quite compelling, as the average time to deploy a new service can be substantially reduced, by as much as 12 times (from 18 months to less than a month and a half ) when compared to the old stovepipe approach.


Key Takeaways

The fragmentation of the value chain is a natural consequence of the separation of the transport, control and application planes that is being unleashed by IMS. The development of the application will no longer lie exclusively with the vendor selling the core infrastructure. Therefore, service providers will have a choice and can opt for a best-of-breed approach, picking different developers for distinct applications. Given the standard IMS interfaces, it will be much easier to replace a non-performing or non-cooperating vendor. Another byproduct of this fragmentation is that carriers can now play vendors off each other and obtain better pricing for their applications. All of these factors lead to a faster time-to-market for a given application.

One Final Cautionary Note
Despite the rapid service creation and CAPEX and OPEX savings the IMS will deliver, there is a cost factor that is often overlooked, namely systems integration. The complexity associated with a multi-vendor deployment will require a topnotch systems integration. For instance, an application such as push-to-talk can belong to one vendor, with another one supplying the CSCF, and an independent systems integrator providing the professional services. This will require careful coordination and expertise to deliver an IMS implementation. The level of systems integration required to implement IMS due to its distributed nature, number of components and functions will be time-consuming and quite an obstacle to overcome.More importantly, the systems integrators will need to refine their skillsets in order to be able to troubleshoot any issues that arise during or after the installation of an IMS service involving equipment from several vendors.Hence, it is not surprising that over half the cost of the implementation is frequently incurred by professional services support. For service providers, the implication is that they will have to carefully weigh the pros and cons of keeping that work in-house versus relying on an external systems integrator.

Ronald Gruia is Program Leader and Principal Analyst at Frost & Sullivan covering Emerging Communications Solutions. He can be reached at [email protected].

1 This was one of the key conclusions from a presentation (“Current Research in Applications and Services Infrastructure Protocols”) given by Dr. Eric Burger (from Cantata), at the SIP Summit in June 2005.