TMCnet - World's Largest Communications and Technology Community



IMS Magazine logo
Oct/Nov 2008 | Volume 3/Number 5
Analyst's Corner

A Survey of the Key IMS Challenges

By Ronald Gruia 
In its current form, IMS is very much a work in progress: despite functioning as a fairly well-defined reference architecture, there are still many issues to be resolved vis-à-vis certain functionality, architecture elements, processes and business cases.

On that backdrop, we periodically survey various vendors, operators and system integrators to get an up-to-date view of the major issues faced by the IMS industry. Our most recent discussions revealed a few interesting challenges related to technology, operation and business considerations.

Technological Challenges

IMS core maturity issues: While some operators have SIP App Servers up and running and ready to be commercially deployed, there are quite a few that believe there are some critical issues that are still lingering with the underlying IMS cores, which thwarts them from going live with the deployments. These concerns include various bugs, configuration issues, standards interpretation and others.

Centralized database issues: one of the cornerstones of the IMS specification is the HSS (Home Subscriber Server), which is a centralized database that makes user-oriented data (such as user profiles, device parameters, account data and usage data) available throughout the network. The issue has been that even those operators deploying IMS apps have chosen to put only the subscriber data for new services on their HSS, while the old data is still residing on HLRs and other legacy databases. This collocation approach is being chosen because it is in fact quite a difficult task to migrate all subscriber data to a single database. This issue is only going to get more complex over time. Moving all customer profiles residing in different places to a single real-time database is a challenge. The tuning of databases will be a hot issue in the future, making indexing an imperative. However, some service provider lab tests revealed that a database with roughly 3 million records entails a 45 minute period for updating the index (on a machine running Solaris 10 and MYSQL and nothing else).

IMS is not quite as “access agnostic” as it seems: despite the fact that the IMS framework is presented as being access agnostic, in practice, it is still more heavily oriented towards cellular networks. This is evident from several different points of view, one of them being security. For instance, plain http-digest is viewed as the only realistic option for non-cellular networks, having been acknowledged as less than optimal or even downright unsecure (it provides only some replay protection and one-way authentication with no mutual authentication, confidentiality, or integrity). The HSS is another noteworthy example of the wireless tilt of the IMS specification. While MSOs are gradually evolving their infrastructure to Packet Cable 2.0, and that architecture has the IMS blueprint, there are also a few differences between the two frameworks, in addition to other MSO specific issues that are not addressed by IMS. Items such as the provisioning of data and devices, packet cable multimedia, and state management transferability questions, among others need to be resolved. The OSS/BSS issues related to the HSS are major, since the subscriber data will have to be migrated to a new schema (HSS) and be centrally stored. Therefore, cable companies will evolve very gradually to an HSS type of architecture, opting instead to keep their legacy back office servers containing their subscribers’ database info.

Migration strategies: While next-gen SPs can readily embrace NGN architectures such as IMS, it is harder for existing operators to do so, as they have made a substantial investment in existing networks and applications. The key issue is how to gradually migrate the already existing services and what kind of investment needs to be made to rewrite some of those applications (such as VPN, pre-paid, etc.). Some operators are exploring various strategies to help them bridge the gap towards the NGN, including using service mediation appliances and/or new components such as application session controllers.

Security: While IMS is an attempt to simplify the network core design, it has made the management and monitoring of that network more complex than in the past. IMS infrastructure will lead to traffic requiring de facto a “real-time” security monitoring. As a result, there are a lot of information security considerations that need to be taken into account in an IMS network, including the usual suspects (identity theft, caller ID spoofing, potential SS7 network breaches, security and integrity of the data streams, DoS/DDoS attacks, convert channels and SPAM/SPIM/SPIT, among others). The key concern for most carriers that we talked to is how to ensure identity, integrity and enforcement of strong authentication on a SIP-based session coming from a terminal that is not trusted outside the wireless domain. Most SIP devices are not currently equipped with a strong security mechanism such as the SIM card on a mobile handset.

Clients: IMS is bringing noteworthy increase in edge intelligence. This will help fuel the need for SIP-enabled personal agents managing presence, mobility, and preferences. Simplicity will be an imperative, with information being pushed to available end-users so that they could decide in real-time how to handle an incoming event. In addition, here is a need to get IMS clients closer to the mobile phone and connect IMS to GGSN. Unless that happens, some pundits warn that there is no bright future for the IMS. There have been some notable developments in this space as previously mentioned in this column (i.e. the OMA IMS PoC specification and the RCS initiative).

SCP/AS integration: Some service providers are also wondering about the integration of the SCP (Service Control Point) and AS (Application Server) with the rest of the world. In other words, the SCP/AS need to be integrated with the consumer’s home for applications such as web, IPTV, etc. In addition, for security purposes it might become necessary to integrate the HLR/AUC with all other vendors and to implement some sort of a centralized control.

Signaling delay: While some vendors are pointing to increases in signaling traffic, operators are also becoming increasingly concerned with the signaling delay, as call setup time, handover time, etc. are increasing as there is a lot of extra interaction given the extra network elements involved. Furthermore, there is more latency involved in the IP network compared to the rugged SS7 network, so service providers believe the latency is a key area on which to focus on their testing. This latency is also raising new issues which these operators never faced in the TDM world, including RTP streams coming from multiple resources for an endpoint, which creates garbled voice.

Operational Challenges

Application platform uncertainty: Given the complexity of IMS and the fact that there are other competing technologies and different voices even within the carrier organizations articulating different viewpoints, it is tough to determine the best “future proof ” way to go forward. The central issue is where to spend the extra budgets. Moreover, carriers need better tools in the early stage of the IMS app server deployments, including sniffers, easy-to-use network monitors and other similar equipment.

Operation and management issues: Another issue brought up quite often in our discussions with carriers relates to operation and management of the NGN, including the associated processes for fulfillment, activation, billing (FAB) — in other words, questions related to the integration of BSS systems into the IMS network infrastructure.

Resource management: Some operators pointed out that there is currently no centralized entity defined for IMS policy and resource management. This is extremely crucial in order to take advantage of some of the efficiency potential within the architecture — shared resources.

QoS: QoS becomes a major concern for operators when calls are routed through other service provider networks, where they cannot really control the QoS. On an all-IP world, carriers cannot clearly define or evaluate QoS data (traffic measurement of calls or Erlangs, etc.) the way they can in the circuit switched TDM world. This introduces unnecessary delay in transcoding in the network. The voice quality and the KPIs must be improved (compared to the circuit, dramatically). The upshot of this could be complaints for poor voice quality, one way RTP, CODEC negotiations and dropped calls.

Business Challenges

Business case justification: It’s certainly been hard for technical staff to justify an investment in a non-silo based architectural approach, which represents a paradigm shift from the current status quo (i.e. stovepipe implementations). We have brought this issue several times in the past but the one key area that operators would like to see a refinement in the business case is a better quantification of a better service velocity, or the ability to introduce new services faster than before. Another one is how elements from a service which eventually fails can be leveraged for the creation of a newer service.

Organizational convergence: IMS flattens the traditional network architecture by defining a common service control layer across any and all types of access networks, supporting any and all types of multi-media services. However, since most operators’ organizational processes are not prepared for this change, these benefits can hardly materialize. For instance, budget allocations are currently done per each existing organizational unit (mobile, access, etc.). This means that when an IMS solution is being pitched to a service provider, the vendor gets into discussions about who will be responsible for which parts of IMS, and more importantly, which organization pays for what. Everyone has to be a willing participant in the IMS negotiations, and it takes time to reach such a consensus. Another complicating factor is that the benefits have something of a “visionary” element in them (faster rollout of new services, lower incremental cost to roll out new services, etc.). From a pragmatic standpoint, the scale benefits and new services both depend on take rates which are unpredictable. Consequently, IMS is still being thought of as “high risk” type of NGN approach.

The Final Word

IMS gives operators a more open architecture that can not only enable innovative Web/Telco 2.0 offerings but also tie their legacy infrastructure into these new services. However, IMS still is a relatively new specification (with ongoing issues remaining to be addressed) that entails a significant upfront investment. The above-mentioned issues will be eventually resolved, but that will require good partnerships between vendors and service providers. Buying off-the-shelf gear will not solve these challenges; instead it will be necessary to go through the IMS growing pains.

Ronald Gruia (News - Alert) is Program Leader and Principal Analyst at Frost & Sullivan covering Emerging Communications Solutions. He can be reached at [email protected].

IMS Magazine Table of Contents

Technology Marketing Corporation

2 Trap Falls Road Suite 106, Shelton, CT 06484 USA
Ph: +1-203-852-6800, 800-243-6002

General comments: [email protected].
Comments about this site: [email protected].


© 2023 Technology Marketing Corporation. All rights reserved | Privacy Policy