Building New Services with Some Old Tools

By David Hayward          

Like a good framework for government, IMS has a rock-solid core set of rules that govern its internal processes, yet is flexible enough to be applied to changing real-world conditions. At one end, it can be applied to new access networks as they emerge, and on the other, it can be applied to new kinds of applications as users demand them and use a variety of application servers and platforms: old and new. In previous “Reality Check” columns, we looked at how IMS provides a control platform for converged voice, video and data services — ultimately at lower capital and operational costs than legacy, “siloed” approaches. We saw how its framers, the 3GPP, originally designed IMS for delivering IP-based services for cellular mobile networks and expanded its value for delivering services over all major access network types: WiFi, WiMAX (News - Alert) , DSL and cable. We also looked at examples of carriers who are carefully examining consumer and business trends in purchasing Internet and mobility applications and devices. Carriers who are carefully observing their customer base are the ones who are building IMS services virtually guaranteed to get a warm reception from the market.

But IMS is attractive not only because of its new applications; it also can leverage some of the old. Its beauty is found in its layered anatomy: session control in the middle, networks at the bottom and application services at the top — with the Session Initiation Protocol (News - Alert) (SIP) being the connective tissue. Being a standardized architecture, carriers can choose to deploy services based on any application server from any third party (or in-house developer) as long as the server is SIP compliant or as long as there is a way to hook it into an element at the top layer that will talk SIP for it.

While IMS will deploy attractive new services (push-to-talk over cellular, mobile phone-based video conferencing, video instant messaging, presence and location aware applications, etc.), various standards bodies are working together to ensure that certain existing services (and existing ways of developing services) can be leveraged by the IMS infrastructure.
This includes groups beyond the 3GPP and 3PGG2 to include the IETF, ETSI (News - Alert) /TIPSNA, OMA, Parlay Group and last but not least, JCP, representing the Java community. Beyond SIP, these groups address JAIN SLEE, CAMEL, Parlay/OSA and a variety of web-based services. These are technologies that IT departments have been using prior to IMS. Carriers can (and must) find a way to leverage all that investment and human intelligence for its next-generation network, IMS.

Many carriers have already invested in so-called Service Delivery Platforms (SDPs), which are as diverse as the companies who tout them, such as Sun Microsystems, BEA, Ubiquity, IBM (News - Alert) , etc. (See Figure 1.) Designed for rapid service development, re-use of service elements for recombination with others, SDPs are the perfect corollary to the IMS architecture’s ability to re-use its middle layer (session control) elements (Call Serving Control Functions, Border Gateway (News - Alert) Control Functions, Media Gateway Control Functions, etc.) for delivering services to users regardless of the access network technology they may be using.

Figure 1. While Service Delivery Platforms enable ISVs and carriers themselves to custom-develop and run unique, competitive services, SIP integration is essential for leveraging these applications within the IMS architecture.

Merging Web Services with IMS
Smart SDP vendors have been hard at work the last few years to incorporate the key IMS protocols (SIP for session control and Diameter for subscriber data access) into their web services platforms. This makes sense to carriers planning to evolve from legacy networks to the IMS architecture.

Carriers will use IMS to offer subscribers competitive value by offering clever services that merge voice (i.e., VoIP) with rich media content (photos, video, gaming, business graphics and other documents). Converging VoIP with Web services will be a big part of the equation.

The IMS architecture’s top (application services) layer is undefined, giving equipment vendors and carriers the freedom to innovatively craft their SDPs and service applications, respectively. The architecture only specifies standard interfaces (or “control points”) for session management, subscriber profiles and charging between the service delivery platforms (i.e., app servers) and the IMS control layer.

The interface, called the IMS Services Control (ISC), describes the rules of engagement between SDPs with the Serving Call Session Control Function (S-CSCF) at the middle layer of the architecture. The S-CSCF (one of several types of CSCFs) is located in the subscriber’s home network. The S-CSCF uses the SIP signaling between app server functions and the users’ devices for enabling session control, authentication/authorization, context and message routing.

Beyond mere application servers, SDPs have rich programming tools (service creation environments with libraries of routines, programming collaboration elements, scripting languages, etc.). SDPs hide the complexity of the network from programmers so they can focus on coding operational functions and application bells and whistles. Thus, they support industry standards, such as Java, HTPP, IPv4 and 6, XCAP, SOAP, JMS, etc. Additionally, they have runtime engines (execution environments) for deploying the application in operational networks to deliver the services. (See Figure 2.)

Figure 2. Service Delivery Platforms for developing and running application servers can leverage standard protocols, application interfaces and IMS control points to bring new SIP and legacy non-SIP services into the IMS architecture and out to users on multiple access networks.

Some platforms may be integrated as an all-in-one package; others are offered as separate, but compatible modules. For IMS, they have added SIP and Diameter.

Merging IMS and Legacy Applications
Carriers can further leverage IMS with legacy industry standards and older IT application development platforms, such as non-SIP application servers, like CAMEL and Parlay. These can use the ISC interface to deliver service through the IMS architecture.

Parlay is an industry consortium founded in 1998 that specified application interfaces (APIs) for carrier networks for call control, conferencing, audio and text messaging and charging. Another important legacy standard, CORBA, is used for application code and Parlay gateway interaction, and Java can be used to invoke the APIs. Like IMS, Parlay was designed to be agnostic to the underlying network technology and therefore applies to fixed or mobile networks. In 2003, the Parlay organization released Parlay X, for Web Services. The organization collaborated with the IMS framers (3GPP) as well as ETSI, to make Parlay standards compliant with the Open Service Architecture: thus the term “Parlay/OSA.”

IMS interaction with Customized Applications for Mobile networks Enhanced Logic (CAMEL) is another way that carriers will leverage their legacy investments. CAMEL provides SS7-related mechanisms to support services which are not covered by standardized GSM services even when roaming outside the HPLMN (Home Public Land Mobile Network). Examples are call holding, call forwarding, suppression of announcements, etc. CAMEL applications use the SS7 protocol for network addressing, resource allocation, and various interworking functions.

IMS Will Continue to Evolve
Carriers are always looking for ways to leverage standards, either inside the standards themselves, or with work-arounds. The concept of a Service Capability Interaction Manager (SCIM) is a good example. For at least two years, carriers have been debating the concept of SCIMs at standards meetings and industry conferences.

A SCIM could, for example, add efficiency to the complex IMS architecture by allowing interaction among application servers (SIP and non-SIP) at the architecture’s upper layer, without having to dip into the S-CSCF at the IMS middle layer. Outside the original concept of the IMS architecture, this innovation could economize on network resources and speed performance when “mashing up” functions from different servers in order to deliver media-rich combo services.

Good examples are video messaging to a buddy list or using a prepaid card for push-to-video in the middle of a voice call, with each function on different vendors’ application servers or SDPs at the top IMS layer.

The fortunate reality about IMS is that it is an open architecture by virtue of its standard protocol, SIP. Leveraging this with application development technologies, practices, and products that our IT community knows, loves and invests in is perhaps the truest expression of IMS’ flexibility. This will accelerate the deployment of IMS and its benefits to carriers and their subscribers alike.

David Hayward is an independent telecomm marketing consultant and is the Director of Marketing for the IMS Forum (News - Alert) . You can reach him at [email protected].