White Paper

IMS Whitepaper
Preserving Investment Along The Path to IMS
April 2007

www.apptrigger.com
IMS Whitepaper

1 Executive Overview
The IP Multimedia Subsystem (IMS), the open standardized architecture
that defines how Internet Protocol (IP) networks should handle voice, video
and data, continues to generate as much excitement today as it has since its
introduction. The promise of IMS is fundamentally the move to IP Platforms
which will allow Communications Service Providers (CSP) to achieve new
revenue protection and growth while simultaneously reducing infrastructure
cost. While the architecture may be complex and evolving, the motivation
is simple: enable the CSP to rapidly deploy services that improve the user
experience and open the network to create and foster an ecosystem of
application developers to generate additional ARPU. Aggressive competition
and increasing consumer choice make time-to-revenue a critical competitive
differentiator and CSPs are quickly turning to IP-based solutions in order to
deliver an improved user experience with services like Voice over IP and IPTV.

Beyond time to revenue and application benefits, the migration into IMS can deliver
CAPEX and OPEX savings. IMS streamlines back-office systems, integrates two to
three networks into one, and largely aims to standardize not only network elements
but the networks themselves, easing inter-operator connectivity.

IMS and rapid application deployment are key to communication service provider
success, however the transition to an IMS network in today’s cost constrained
environment is challenging. Hence, it is necessary for CSPs to maintain and reuse
existing applications and infrastructure in creative ways to maximize their existing
customer base and revenues. In short, replacing non-IMS applications to comply with
an IP structure makes little sense if there’s no additional revenue to be generated. To
compound the problem, IMS makes little provision to allow legacy applications access
to IMS elements directly; the net effect being that major IMS roll outs are delayed
pending positive business cases.

1
 IMS Whitepaper

In order to address this need, a solution has been created in the form of the
Application Session Controller. Application Session Controllers manage network
connectivity for currently deployed applications, taking full advantage of a deployed
infrastructure and applications, while also adhering to IMS architectural entities
and easing the migration into IMS. Application Session Controllers provide the
service operator a true migration plan to IMS while fully leveraging existing revenue-
generating applications, existing infrastructure and post investments (CAPEX) and
preventing IMS from becoming another network silo.

2 IMS and Application Delivery

There is much speculation on when a full IMS network and applications will be
completed. The industry at large believes that the IMS will be a gradual build out over
the next 10 years and will consist of three key phases:

• Phase I (2005 – 2008): Proof of concepts and field trials focused on leveraging IP within
the transport and application level.

• Phase II (2008 – 2012): Significant IMS deployments with a key focus area of converging
wireline and wireless solutions beginning on a mass scale with the enterprise and
spreading into the residential markets.

• Phase III: (2012 and beyond): VoIP becomes the prevalent voice, video and data
technology and QoS will be fully monitored and guaranteed.

From an architectural point of view, the IMS architecture merges applications with
the capabilities of the Internet to address both wireless and wireline telephony. It
also aims to deliver fixed-mobile convergence and other 3G/4G applications: a true
multimedia experience incorporating voice and data (video, etc.) across all sorts of
devices including mobile phones, computers, PDAs, etc.

In order to deliver this vision, functional entities that comprise the overall architecture
of IMS are documented. Each entity may or may not be a discrete product, but the
functionality delivered by these building blocks is such, that in theory, interoperability
is not a concern. Figure 1 depicts the overall IMS architecture (as conceived by 3GPP).

2
IMS Whitepaper

HSS Service/Applications Layer

IMS Data AS
Application
(SIP AS, OSA AS
SLF SIP AS IM-SSF OSA-SCS CAMEL SE)
HLR/AuC
(’C5/P5’)

CSCF

S-CSCF I-CSCF

BGCF
IMS Layer P-CSCF

MGCF

CS Networks
DSLAM DSLAM (PSTN, CS PLMN)
SGW
MRF IMS GW

MRFC ALG
IPv4 PDN
BAS PDF (IPv4 Networks)
UE DSLAM MRFP TrGW IMS-MGW

BB
WLAN WLAN PDG (IPv4/IPv6)
UE
WAG
GGSN/PEF BG IPv6 PDN
(IPv6 Network
UE
Transport Layer
RAN SGSN

Figure 1 - IMS Overview

The key application delivery entity in IMS is the IP-based application server (AS),
which hosts and executes services, and interfaces with the network using the Session
Initiation Protocol (SIP). The aim of the AS is to allow third party providers an easy
integration and deployment of their value added services into the IMS infrastructure.
Examples of such services include:

• Call waiting, Call holding, Push to talk, Call forwarding, Call transfer
• Call blocking services, Malicious Caller Identification
• Announcement and Conference call services
• Voicemail, Text-to-speech, Speech-to-text
• Location based services
• Messaging, SMS, MMS
• Presence information, Instant messaging, Find Me / Follow Me

3
 IMS Whitepaper

The 3GPP standards body has identified three distinct types of AS, each with a
specific role:

• SIP AS: This is the native IMS application server, hosting value added services and
triggered by the S-CSCF. The SIP AS utilizes resources such as the Home Subscriber
Server (HSS) or User Profile Server Function (UPSF) to store and lookup the
identities and information used in calls and sessions made by subscribers. These
new IP-based application servers face the challenge of connecting to the existing
wireline and wireless networks, which by design, are still TDM based.

• OSA-SCS: an Open Service Access - Service Capability Server interfaces with

application servers using OSA/Parlay API. As such, SCS is not truly a server as much
as a gateway; however, from the S-CSCF point of view, applications reside at the
SCS. SCSs allow application servers to view and gain access to IMS and legacy
wireline and wireless networks. SCS provide a level of network abstraction by
exposing the network via an API known as OSA/Parlay API. The SCS allows current
service subscribers, which are on legacy wireline and wireless networks, to access
the new IMS applications. This conversion function is critical to ensure the business
cases for IMS remain viable by allowing coexistence of IMS and legacy wireline and
wireless infrastructure.

• IM-SSF: The IM-SSF is another gateway server. In this case, the IM-SSF provides
networking between IMS and a CAMEL service environment by bridging SIP-ISC
and CAP protocols. As with the OSA-SCS, from the S-CSCF point of view, it is an
application server; in this case, with access to an IN network.

A challenge not currently addressed is how to migrate to new IMS-based services

while allowing the current applications to integrate with the new architecture. The
IMS framework expects the application servers to replace existing TDM and legacy
applications. It is this required migration that presents a unique opportunity for
solutions that manage to bridge the gap between the feature rich, tried and true
“legacy” applications and the IP core of IMS.

3 AppTrigger and IMS 

In an IMS deployment, AppTrigger delivers capabilities of the IM-SSF, SCIM, and OSA-
SCS, as represented in Figure 2, to applications utilizing the AppTrigger’s Application
Session Controller framework. It’s important to note that while the Application

4
IMS Whitepaper

Session Controller may become all of these elements under one product, much as
it already is in the TDM/VoIP arena, the focus remains application deployment and
delivery. From the point of view of the application, a media resource is just that,
regardless of whether it’s located in the IMS domain or in the legacy network.

SCP (IN) OSA App Servers

IM-SSF RAN OSA-SCS

S-CSF

IMS HSS Wireline Wireless HLR

MRFC MRFC Legacy Networks

MRFP MSFP

Figure 2 – Application Session Controller and IMS IP Applications Interaction

The AppTrigger Application Session Controller consists of just the right blend
of traditional network elements, brought together under a single manageable
product, to facilitate rapid application deployment across diverse networks,
including IMS. The aim is to provide feature transparency to subscribers,
regardless of the network employed. This is accomplished by providing an
abstracted view of the network to the applications.

The Application Session Controller delivers rich call control via an application-aware
switch, media gateway, media server, trans-coding, signaling gateway, and protocol
conversion, all under API control. A functional diagram of the AppTrigger software is
shown in Figure 3. The framework includes traditional IN and TDM protocols, plus VoIP,
such as SIP and H.323.

5
 IMS Whitepaper

TransparentExchange ™
APPTRIGGER API CCXML Parlay/X IN SIP
O TPX, XML VXNL CAMEL, INAP, WIN

A Composite Builder Registration SCIM+ Dynamic Policy Static Rules

M Validation Agent Service Abstraction Intelligent Service Components
P Protocol Bridges Call Control CS2 Call Model
CLI
FIFO Endpoint Control Abstraction
GUI
Media Signaling Switching Media Gateway Control
SNMP
Third Party Hardware

Fixed IP Wireless IMS

Figure 3 – Application Session Controller Architecture

Application developers may utilize a number of available APIs to signal and control
the behavior of the Application Session Controller and therefore bring innovative
functions to their applications. Capabilities such as system partitioning, service
arbitration and application policing allow centrally maintained network connectivity,
regardless of the number of applications served by the Application Session Controller.

A key enabler of the Application Session Controller is its ability to abstract and
normalize the network, regardless of whether it is wireline, wireless, SIP, IMS, etc.,
and present this view via a number of available APIs. This has the effect of shielding
the developer from the network and allowing for application portability between
different networks. In addition, as long as the API remains constant or backwards
compatible, new networks may be abstracted by the Application Session Controller.
The application remains unchanged and if so desired, unaware of network changes
and provides a consistent interface to the user, regardless of network access.

6
IMS Whitepaper

4 Legacy Silo Applications and IMS

A challenge not currently addressed is how to migrate to new IMS-based services
while allowing the current applications to integrate with the new evolving architecture.
The IMS framework expects the application servers to replace existing TDM and
legacy applications. It is this required migration that presents a unique opportunity
for solutions that manage to bridge the gap between the feature rich, tried and true
“legacy” applications and the IP core of IMS.

AppTrigger aims to solve this critical need in the IMS architecture of allowing new IMS
subscribers (those new subscribers added via SIP and SIP-enabled infrastructure) to
access legacy applications, and therefore extend the useful life and associated revenue
generation already in place by those applications. While the IM-SFF was created as
a mechanism to allow SIP AS and the S-CSCF to access CAMEL IN, the many other
services and applications that depend on INAP, MAP, WIN and other mechanisms are
not addressed. Viewed another way, by connecting all the current applications, the
operator may continue to receive revenue from platforms that are not only proven, but
potentially already fully capitalized.

A new AppTrigger IMS element is proposed that enables legacy applications to function
in an IMS world, and therefore, bring feature transparency across the entire subscriber
population. As subscribers are migrated from one network to the next generation
network, their experience (revenue generating subscriptions) remains constant. In order
to accomplish this, this new element emulates and translates function calls that would
normally be answered by IN-enabled devices (those speaking INAP, MAP, WIN, etc.) by
presenting appropriate IMS-based calls. This new IMS element is called the IN Service
Capability Server, or IN-SCS. Figure 4 - IN-SCS shows a representation of the IN-SCS in
place, with legacy applications interacting with the IMS.

7
 IMS Whitepaper

SCP (IN) SIP App Servers OSA App Servers Current Applications

C++
OSA/Parlay CCXML/VXML
Parlay/X SIP 3PCC
Other APIs

IM-SSF RAN OSA-SCS IN-SCS

S-CSF

IMS HSS Wireline Wireless HLR

MRFC MRFC Legacy Networks

MRFP MSFP

Figure 4 - IN-SCS Supporting Legacy Applications

The net effect is that legacy applications are able to work within the IMS network
without the need to modify or rewrite them. The applications interact with the
abstracted network using their current APIs, whether it’s C++, CCXML/VXML, or SIP
3PCC; other proprietary APIs may also be supported via dedicated API connectors.
Those applications continue to utilize network protocols they were originally designed
to utilize so there’s no requirement to rewrite and retest and ultimately redeploy
existing applications. As an example, take an existing application that may have to
execute a lookup against an HLR. With the IN-SCS in place, the application believes
that the IMS equivalent to an HLR, the HSS, is an active HLR and the IN-SCS would do
the appropriate translations between MAP and Diameter, and maintain session control
and states to ensure the entire transaction is seamless.

The capability of the Application Session Controller to support these current

applications means that the CSP:

• Saves valuable time and OPEX by redeploying current, tested applications on the
new IMS network

• Enjoys CAPEX savings by extending the useful life of existing applications and
avoiding “reinventing the wheel”

• Reduces churn by providing subscribers with familiar applications and eliminating

the learning curve of replacement applications

• May extend features (feature transparency) across into the IMS network, thus
ensuring subscribers enjoy a richer experience

8
IMS Whitepaper

5 Summary
It will take several more years for the IMS vision to become fully realized. Early
implementations of IMS are being installed today but there is a clear need to marry
those with the existing revenue generation applications and networks of today. Those
service providers that successfully transition to the IP world of IMS, without losing
revenue in the process, will ensure a continued returned on their investment.

The AppTrigger Application Session Controller is an essential component of the

service operator’s IMS migration strategy. By sitting “between the network clouds”,
the Application Session Controller provides a unique view of all the networks to
the application developer and enables the service operator to migrate to IMS while
retaining current revenue (ARPU) generating applications. The Application Session
Controller eliminates the silos created by discrete network solutions used in the past,
thus lowering CAPEX, as well as those silos created when IMS in installed is mixed
environments with legacy applications.

For More Information

AppTrigger is dynamically changing the telecom application delivery marketplace
by empowering its customers to insulate their revenue-producing applications from
the challenges of the ever evolving fixed-line, mobile, and IP networks. AppTrigger’s
Application Session Controller provides a purpose built unique combination of media,
signaling, call control, and a family of APIs for multi-network, converged application
deployments. In an environment of ongoing network evolution, AppTrigger delivers
time to market advantages, reduces application deployment costs, and provides feature
transparency acrossdisparate and ever evolving networks. For more information, please
visit www.apptrigger.com or call 866-227-7487.

5 Glossary
3GPP Third Generation Partnership Project
API Application Programming Interface
AS Application Server
CAMEL Customized Applications for Mobile networks Enhanced Logic
CAP CAMEL Application Part
CAPEX Capital Expenditures
CSCF Call Service Control Function
CSP Communications Service Operator
ETSI European Telecommunications Standards Institute
GSM Global System for Mobile Communications

9
 IMS Whitepaper

HSS Home Subscriber Server

I-CSCF Interrogating Call Session Control Function
IMS IP Multimedia Subsystem (3GPP standard)
IM-SSF IP Multimedia Service Switching Function
IN Intelligent Network
INAP Intelligent Network Application Part
IP Internet Protocol
MAP Mobile Application Part
MMS Multimedia Messaging System
NLSPD Network Layer Service Delivery Platform
OMA Open Mobile Alliance
OPEX Operational Expenditures
OSA Open Service Access
OSA-SCS Open Service Access – Service Capability Server
P-CSCF Proxy Call Session Control Function
PDA Personal Digital Assistant (Handheld computer)
PLMN Public Land Mobile Network
PSTN Public Switched Telephony Network
SCIM Service Capability Interaction Management
SCS Service Capability Server
S-CSCF Serving Call Session Control Function
SIP Session Initiation Protocol
SIP-3PCC Session Initiation Protocol – Third Party Call Control
SIP-ISC Session Initiation Protocol – IMS Service Control
SMS Short Message Service
TDM Time-division multiplexing
TEM Telecom Equipment Manufacturer
VoIP Voice over IP
WIN Wireless IN

10