For a half-decade, the IP Multimedia Subsystem (IMS) has been either the saviour of mobile service stability and progress or the last bastion of walled-gardenism, so to speak. The emotionalism of the discussion has obscured a really important question. Is IMS enough of the right answer to drive the future in any direction at all? Do we need IMS, or more, or less?
IMS as a standard covers how SIP-based services are coordinated between customers, their mobile carriers and other roaming providers. The standard includes definitions of interfaces between network devices (session border controllers, for example) and central call and session management functions. It also shows how applications can fit into the process. IMS is a key element in the service delivery platform (SDP) standards of many vendors. The problem is that at the application level, IMS doesn’t really specify much. There are two key things it lacks, in fact.
Thing No. 1 is a complete and rigorous definition of what used to be called a Service Logic Execution Environment, or SLEE. A network feature or service application is a program, and like all programs it needs a set of application program interfaces (APIs) that link it to the operating system, network services set, and hardware platform it runs on. A SLEE standard that would be portable to different SDPs would allow developers to write services and features and run them wherever the SLEE was supported, just as Linux applications run where Linux has been ported. There’s no such thing in IMS.
The second missing IMS ingredient is a Service Management Execution Environment, that I guess we could call SMEE. These days, it’s as important to understand how a new service or feature integrates with operations and business support systems (OSS/BSS) as it is to understand how the service or feature works with its users. IMS doesn’t provide that either.
Without a specific definition of a SLEE and SMEE, IMS applications aren’t portable between SDPs, which means that there really isn’t any such thing as an “IMS application” in a generic sense. There are no “IMS developers” either, only developers of IMS-compatible applications written for someone’s specific platform.
There are some other standards activities that have addressed, or are addressing, some of these issues. The Parlay X initiative provides APIs for call control and OSS/BSS connection, but it’s focused on calling and not on general multimedia network services. The same is true with the Java Advanced Intelligent Network (JAIN) work. The Telemanagement Forum’s Service Delivery Framework team is working on a management framework for hosted services and features, but it doesn’t include service logic definitions or standards. Thus, nobody is really taking on the high-level question of how service features and service-creating applications are authored in a flexible and portable way.
It’s reasonable to suggest that a good standard approach to SLEE and SMEE specification would be to use Java, which has become an almost-universal programming language that is also accepted by the service provider market. SLEE and SMEE work can also draw on Parlay and the TMF’s work. The key question may be to find a place for service and feature standards like this to live. The whole area seems to fall between the cracks of the current standards processes, and this is surprising given the focus operators have placed on the issue of creating hosted service features. One could argue that IMS has been promoted by the notion that it can provide for feature hosting, even though IMS doesn’t really do that.
An ironic truth is that a true SLEE/SMEE specification could be used as an alternative to IMS, as well as a way to provide application and feature programming support within IMS. IMS opponents gloss over this point; they oppose IMS but offer no alternative other than a vague comment like “Use Web 2.0.” Since virtually every major portal player has its own unique and incompatible Web 2.0 API tool kit, this offers no realistic path toward creating open, portable, service features and logic. A standardized SLEE/SMEE architecture would still leave some open issues, issues that Google’s open mobile Android initiative exposes in the mobile space. Consumers expect to be able to prevent nuisance and obscene calls, for example, and they also expect that their handsets won’t be hacked or that they won’t roam into a rogue cell area that imposes extravagant roaming fees. This kind of thing can’t be prevented by an open handset architecture and can’t necessarily be prevented by a standard SLEE/SMEE framework either. What prevents that sort of abuse is at least a little bit of a walled garden, a provider that takes responsibility for the behaviour of the community it supports.
The recent open mobile trends, including Android, seem to show that we need both a more complete service feature and operations standards set to guide hosted applications and a way of creating credible open services. The challenge may be in figuring out how to get them both, and in how to reconcile these new standards with the work of more traditional standards — including IMS.
