By Brough Turner, SVP & CTO
This was the title of a panel I participated in at Spring VON 2007. I reported on what NMS Communications has learned so far in migrating our MyCaller™ Ringback application from the Intelligent Network (IN) implementation that’s been deployed by nearly 30 operators today, to an IMS version capable of working with Middle East operators who have “IMS” networks from major European equipment providers.
For the impatient, here are the takeaways.
- It’s very early days for IMS. Today’s “IMS” networks are combinations of SIP infrastructure with 3GPP Release 4 softswitch-controlled voice service.
- IMS is about connection control, only. Only part of your application has to change. For MyCaller, ~90 percent of the software remains the same.
- IMS enables multimedia ringback, i.e. video! So there is significant new functionality, versus today’s audio-only ringback.
- Parallels with Intelligent Network are striking!
- Most application–specific data remains outside of IMS. In particular, operators do not want to add data fields to their Home Subscriber Server (HSS).
- Application–specific MRFs make sense. Operators tend to avoid sharing resources between diverse applications. And, for rich media, application–specific MRFs can be more cost-effective.
- Operators await 3GPP Release 7. At least anecdotally, several operators have suggested that 3GPP Release 7 is the first complete, stable, and consistent version they will fully deploy.
Ringbacks, The Application
Ringbacks are a service where you get to specify what callers hear in place of traditional “ring, ring” sounds, while they wait for you to answer. Why is there a market for such a service? There is a market because subscribers want to prove to their friends that they are cool or, in my case, a classical music die-hard.
Ringback systems must…
-
accept audio (and now video) clips from multiple content sources,
-
manage that content, offer it for sale to subscribers via web, WAP, IVR, and/or SMS dialogs,
-
manage “albums” of content that subscribers have purchased,
-
provide facilities for subscribers to define who hears what content based on caller ID, time and date, and so on,
-
and then finally play the appropriate content as calls are made.
Only the last step involves any IN or IMS complexity.
Most of the ringback application is based on a conventional three–tiered IT architecture, i.e., database core, business logic tier, and presentation tier. Moreover, the majority of operator–specific integration issues have to do with the operator’s IT infrastructure—OSS/BSS, network management, and the like. It’s no wonder that less than ten percent of the MyCaller ringback code base is impacted by IMS.
Migration in Two Stages
NMS decided to migrate in two stages. The first stage is IMS enabling the current MyCaller ringback system. The second stage leverages as much of the evolving IMS infrastructure as possible. We refer to these stages as “IMS-enabled” and “IMS-native.” To see how this works, Figure 1 shows a high-level view of the current (IN-based) system.
Figure 1: MyCaller IN-Based System
IMS-Enabled MyCaller
The first stage of IMS migration is straight forward. Figure 2 illustrates an implementation in an IMS network where the IMS application server is a WebLogic SIP Server from BEA. As you can see, the parallels between IN and IMS are striking.
The provisioning interface to the HSS is slightly different than that of the HLR, but the functions and architecture are identical. IN triggers are replaced by IMS filter criteria. There is work to be done developing call flows and implementing them on the IMS application server, but the functions and complexity match those of call flows on an Intelligent Network SCP.
The MyCaller Intelligent Peripheral becomes the MyCaller MRF. It’s still a media server, only now it’s invoked by SIP instead of ISUP signaling over SS7, and it plays media streams over RTP/UDP/IP rather than over T1/E1 trunks. The specific choice of media is still done by application code on the MyCaller Subscriber Server, which is unchanged.
An added advantage of the IMS-enabled system is that one can mix TDM and IP nodes in larger networks during a staged transition.
Figure 2: IMS-Enabled MyCaller
Issues for IMS-Native MyCaller Ringback
A pure IMS implementation should be able to leverage IMS to minimize costs. Unfortunately today’s realities muddy the picture.
Can we eliminate the MyCaller Subscriber Server by moving its functions to the IMS application server (AS)? Maybe, though not in a standard way. The problem is that there is a good amount of data per each subscriber—multiple audio and video clips with complex assignment rules based on caller ID, time, date, rotation rules, special days (birthdays, holidays), and so on. If this subscriber data could be stored in an extension to the HSS, there would be a standard way for the AS to access the data and execute the rules. However, it appears that operators do not want to tamper with the data fields supplied by their HSS vendors. The preferred solution is to have the AS interrogate the MyCaller Subscriber Server and use the result to compose an appropriate command or VoiceXML page for the MRF. This conforms to the IMS specifications but doesn’t reduce the number of boxes or otherwise simplify the implementation.
Can we at least use the network’s standard MRF? Yes, but there are management, performance, and cost considerations. Operators typically qualify one or two specific vendors’ MRFs, but then deploy separate instances for significant applications—one set of boxes as announcement servers, another set for voicemail, and a third for ringbacks. This minimizes finger pointing and simplifies cost allocations.
Typically, the default MRF is ideal for audio applications, like announcements, voicemail, and music ringbacks, requiring expensive upgrades if conferencing, video, or other rich media are needed. In such cases, application-specific MRFs can be much more cost effective.
Finally, for ringbacks, a critical competitive issue is minimizing added post dial delay—the time from when a caller punches in the last digit or hits “Send”, until they hear the ringback media clip. This requires fast response from the Subscriber Servers and Content Servers, typically achieved by caching and low-latency connections. The highest performance and lowest cost is achieved by integrating the content server and content cache into the MRF.
As a practical matter, IMS applications must work with the operator’s default MRF, but application providers are still likely to sell application-specific MRFs.
“R4” today, R7 eventually
IMS was initially defined in 3GPP Release 5 specifications. I was surprised when I first saw the term “IMS R4” in a confidential presentation deck from a major equipment provider. If IMS began with R5, what could “IMS R4” mean? I have heard this term used by field staff (but not corporate) at two major equipment providers as they referred to recently deployed configurations where a 3GPP Release 4 softswitch handled voice traffic and a SIP infrastructure handled new applications, like push-to-talk or video sharing.
Most operators have deployed some form of SIP infrastructure today. But from discussions with their IMS planners, Release 7 is the first version of IMS that is complete enough to meet long-term needs. Certainly, IMS Release 7 is the first version to fully integrate fixed and mobile networks, though Release 7 specifications won’t be frozen until June 2007. It will take at least two years from stable specifications to initial deployments.
So IMS will be a work-in-progress, supporting equipment sales and professional services, for many years to come.