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
|
Internet Telephony Magazine
Click here to read latest issue
CUSTOMER 
Cloud Computing Magazine
Click here to read latest issue
IoT EVOLUTION MAGAZINE
