IMS Apps in Anarchy

The IP Multimedia Subsystem (IMS) applications layer is in a state of flux, and for many telcos it has all the clarity of a pool of mud. Despite the fact that Heavy Reading surveys have shown time and again that telcos see IMS primarily as a means to launch new, better, or cheaper applications and services, the 3rd Generation Partnership Project (3GPP) standard says remarkably little about those applications, or how they are to be created and deployed. If IMS is taking longer than vendors had hoped to make the transition from concept to revenues, then the applications layer probably lies at the heart of the matter – and resolving issues there will be key to seeing real progress in 2007.

There is no shortage of companies trying their luck in this area. Investment in the IMS application layer has already been significant, and many companies in the telco applications space are putting IMS at the core of their marketing. In Heavy Reading's recent report IMS Application Servers & the IMS Application Environment, we identified almost 40 companies selling something that they called an "IMS application server." Yet no two companies have an identical or comparable product – reflecting in part the wide range of companies that have entered this sector. These include traditional equipment vendors such as Alcatel-Lucent (NYSE: ALU) and Nortel Networks Ltd. ; telephony application specialists such as BroadSoft Inc. and Sylantro Systems Corp. ; programmable application server vendors such as BEA Systems Inc. (Nasdaq: BEAS), Oracle Corp. (Nasdaq: ORCL), and Ubiquity Software Corp. (London: UBQ); point solution specialists such as BridgePort Networks Inc. and Colibria AS ; and companies emphasizing their brokering capabilities, such as Aepona Ltd. and jNetX Inc. , among many others.

Right now, therefore, despite the fact that the IMS application server is a standardized component in the 3GPP specification, this is about as far from a commodity product as it's possible to have. Even at the most basic level of evaluation, we found more than 20 different means by which vendors sought to differentiate their products – and that's without getting into the mind-boggling technical detail that underlies many propositions.

Why has this happened? In large part, it's because there are some fundamental disagreements about what telcos really need from the applications environment in general, and from IMS applications in particular. Specifically:

What kinds of applications will drive IMS?
Many basic applications, such as VOIP and even voice call continuity (VCC), don't need IMS to work. But the more complex applications – all running on the same IMS substrate – are more difficult to deploy, and vendors don't all agree on the best way to do this. Moreover, there is disagreement about to what extent traditional telcos should be in the applications business at all: Our research found that an increasing number of vendors believe telcos should focus on applications enablers, such as presence, identity, security and so on, rather than applications themselves.

Who will write the applications?
In survey work conducted in 2006, we found that most telcos expect to use a wide range of suppliers for IMS-oriented applications, including not just traditional equipment vendors and specialized application server vendors, but also third-party independent software vendors and internal telco departments. Most traditional vendors, however, expect to continue to play a major role in supplying applications, and it will take time for clear segmentation among these various actors to emerge.

How will IMS applications be connected with the legacy environment?
3GPP specifies a particular kind of application server to do this, called the IM-SSF. But this only takes telcos so far – leaving aside, for example, the huge issue of integration with legacy billing and operations support systems – and in some related areas, such as service brokering, there are fundamental disagreements about the way forward. Although some vendors claim to be supplying a component that fulfils the 3GPP Service Capability Interaction Manager (SCIM) standard, which could act as a broker to some legacy elements, there is no detailed standard in this area yet.

How will IMS be linked with developments on the Web, especially Web services software?
Our 2006 telco survey work found very strong interest in Web services: Asked which service/applications creation environments or software tools they expected to use for IMS development, no less than 80 percent of telco respondents cited Web services – the top pick among respondents. But there are many approaches to connecting Web services with IMS, and some big arguments about how and where to establish the border between the two. For instance, vendors differ on the ongoing importance of Parlay and Parlay X, which enable third-party independent software vendors to write applications that can run on telco networks. More fundamentally, some vendors, for instance Microsoft Corp. (Nasdaq: MSFT), see IMS as very much subordinate to Web services – not a position that all traditional equipment vendors share.

As this list of issues (by no means comprehensive) suggests, much of the complexity arises because IMS sits in a broader context: since it can only take telcos so far with next-gen applications development and deployment, much depends on how the boundaries between IMS and that wider environment are set; how linkages are established across those boundaries; and what sits on the other side of the boundary.

Can anything be done to move things forward? Efforts on the standards side can and will help. 3GPP Release 7 specifications include more detailed work in the area of service brokering, for example, while JSR 289 is working on improvements to the SIP Servlet specification for IMS applications creation. Other groups with important initiatives in the area include the Open Mobile Alliance (OMA) and European Telecommunications Standards Institute (ETSI) TISPAN.

Meanwhile, recent work on interoperability testing has renewed confidence that the control and applications layers in IMS fit very well together. Many application server vendors can already connect to most core IMS vendors via the key ISC interface, while the MultiService Forum 's Global MSF Interoperability IMS test event, which ended in December 2006, has given a big boost to the industry, confirming that the key interfaces are working very well.

But work on standards and interoperability can only take us so far. Most of all, perhaps, vendors need to partner and work together if they are to convince telcos that they have a workable long-term solution for next-generation applications. There is already a lot more partnering going on, in part as a result of IMS, and that is a big step forward. Yet because boundaries have blurred between vendor and product categories, there continues to be widespread rivalry and suspicion about motives, even among the partners themselves. Moreover, as the foregoing has made clear, it's not enough to partner in the IMS space alone.

For all vendors, participation in a broad, open, and clearly defined applications ecosystem is therefore a top priority. Most telcos want someone else to handle the integration of IMS elements into a wider next-generation applications strategy – and those who create the clearest and most convincing proposition here will be in the pole position to move this vital sector forward in 2007.

— Graham Finnie, Senior Analyst, Heavy Reading