Thinking beyond IMS

For a half-decade, the IP Multimedia Subsystem (IMS) has been either the savior 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.

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

For a half-decade, the IP Multimedia Subsystem (IMS) has been either the savior 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.