Ericsson IMS Client Platform

Piotr Kessler

The success of IMS will largely depend on the availability of new ser- tion services. But on the other hand, we see
vices in end-user equipment. Strong focus on terminals is thus especially how difficult it is to create and use a con-
important to ensure that IMS services remain independent of access and sistent suite of communication services that
terminal type. can interoperate with others suites of com-
munication services. Indeed, having myriad
Implementations of IMS applications in terminals must address two
applications on your computer does not offer
disparate aspects: technology and end-user experience. Accordingly, the same simplicity of service you experience
Ericssons solution partitions IMS applications into two layers consisting of when using a phone to set up a call. Nor can
an IMS client framework (which essentially hides IMS technology behind a you expect to reach all your contacts in the
high-level API) and IMS applications. same easy way as you can currently do from
The author describes Ericssons realization of the IMS client framework. your phone book. Therefore, looking for-
ward, the challenge is to ensure that com-
munication applications will work together,
simply, and on any communication device.
The solution calls for an architecture for
Background IMS ing to include the ability to communicate advanced network-based multimedia com-
and interact with just about anybody, any- munication services one that merges tech-
No one is an isolated island, wrote British where, at any time, and using any commu- nologies and fuses the advantages of the
poet John Donne in 1623, indicating, among nication device. internet domain with those of the telecom-
other things, that it is human nature to want For most people, exposure to this new munications domain. This architecture, the
to belong to a social context.1 Previously, our communication paradigm began with the IP Multimedia Subsystem (IMS), has already
worlds were defined to a great extent by introduction of internet access to the home. been defined and standardized by the Third
small communities in our immediate sur- On the one hand, it has taught us how easy Generation Partnership Project (3GPP).
roundings, whereas today they are expand- it is to develop and use new communica- IMS defines a framework that facilitates
development and deployment of any type of
multimedia service. The IMS framework in-
cludes or addresses
end-to-end service (that is, it takes into
account all the nodes that are needed to
TERMS AND ABBREVIATIONS realize service);
reachability, using similar (or possibly the
3G Third-generation mobile system JSR Java standardization request same) addressing mechanisms;
3GPP Third Generation Partnership MRF Media resource function mobility;
Project MSISDN Mobile station international ISDN
AL Abstraction layer number
interoperability;
API Application program interface MSRP Message session relay protocol convergence;
AS Application server OMA Open Mobile Alliance quality of service (QoS);
CDC Connected device configuration OS Operating system multimedia connections;
CLDC Connected limited device P2P Peer-to-peer security; and
configuration PBX Public branch exchange
CoSe Communication service P-CSCF Proxy CSCF charging.
CSCF Call session control function PoC Push-to-talk over cellular Examples of services that have been stan-
DM Device management QoS Quality of service dardized on top of IMS include OMA pres-
E2E End-to-end RFC Request for comments ence and group list management, OMA
GPRS General packet radio service RTCP Real-time control protocol
GUI Graphical user interface RTP Real-time protocol
Push-to-Talk over Cellular (PoC), 3GPP
HSS Home subscriber server RTSP Real-time streaming protocol combinational services (CSI), OMA Instant
HTTP Hypertext transport protocol S-CSCF Serving CSCF Messaging, and TISPAN/3GPP multimedia
HW Hardware SDP Session description protocol telephony for IMS (MMTel).2
IARI IMS application reference SDS Service development studio IMS has been positioned on top of the
identification SIP Session initiation protocol
ICP IMS Client Platform TCP Transport control protocol IP technology layer to make it access-
I-CSCF Interrogating CSCF TTM Time to market independent and to take advantage of under-
IDE Integrated development UA User agent lying layers (Figure 1). The IMS layer includes
environment UDP User datagram protocol several components, such as proxy call session
IETF Internet Engineering Task Force UMTS Universal mobile
IMEI International mobile equipment telecommunication system
control function (P-CSCF), serving CSCF
identity VCC Voice call continuity (S-CSCF), interrogating CSCF (I-CSCF), and
IMS IP Multimedia Subsystem VoIP Voice over IP media resource function (MRF).3
IOT Interoperability test WLAN Wireless local area network Figure 2 shows a simplified view of the
IP Internet protocol XCAP XML configuration access protocol IMS architecture, highlighting the core parts
IT Information technology XDM XML document management
JCP Java community process XML Extensible mark-up language of the IMS infrastructure and the enabler
JME Java micro edition part, which supports IMS services.

50 Ericsson Review No. 2, 2007


EgZhZcXZ
BBIZa
HZgk^XZcZildg`
8H8;
H>E BG;
>BH
I>HE6C
Bjai^"VXXZhh
GZh^YZci^Va
:ciZgeg^hZ
IMS support in terminals
The success of IMS will largely depend on
the availability of new services in end-user
equipment. Therefore, strong focus on termi-
nals is especially important because IMS ser-
vices must remain independent of access and
terminal type that is, they must be able to
run on all kinds of terminals in the broad-
est sense, including mobile phones PCs, set-
top boxes, modems, and so on. Furthermore,
IMS services must rely to a high degree on
the implementations in end-user equipment.
Implementing IMS applications in termi-
nals is not an easy task because developers
must address two disparate aspects: technol-
ogy and end-user experience. Where technol-
ogy is concerned, developers must consider a
variety of communication protocols (for in-
stance, SIP, SDP, RTP, RTCP, MSRP, XML
and XCAP), standards compliance, real-time
requirements, low-level task management,
and enablers. And where end-user experience
is concerned, they must focus on service ag-
gregation, the graphical user interface (GUI),
usability, and user interaction.
In all fairness, however, one cannot expect
developers to have so broad and comprehen-
Ericsson Review No. 2, 2007
8H>
Ed8
BZhhV\Z
8H8;
=HH H>E
(<EE
BdW^aZ
Figure 1
IMS technology.
sive a skill set as to satisfactorily span both Figure 2
these areas. Consequently, without interven- Simplified overview of the architecture of
tion we cannot achieve a high penetration the IMS infrastructure.
of IMS applications, which is a criterion for
the success of IMS. What is more, most of
todays IMS applications include their own
implementations of IMS technology, which
substantially threatens interoperability, a 6eea^XVi^dch
second criterion for true, long-term success.
Ericssons solution is to partition IMS ap-
plications into two layers consisting of
an IMS client framework (the domain of
providers of terminal platforms); and
IMS applications (the domain of applica- :cVWaZg
tion developers).
The IMS client framework essentially hides
IMS technology behind a high-level API, al-
lowing application developers to focus exclu-
sively on innovations.
Ericsson IMS Client
Platform
Ericssons IMS Client Platform (ICP), which 8dgZ
implements the IMS client framework,
is easy to download and install on open
platform terminals. When designing it,
51
 CVi^kZ ?B:
Veea^XVi^dch Veea^XVi^dch
?B:6E> 6eea^XVi^dc

8 6E>

:cVWaZgh :cVWaZgh

>BH

>8EXdgZ

>8E >BH
Figure 3
End-to-end realization of layered IMS
architecture.

Ericsson put special emphasis on the end-to- Application development

end perspective: given that IMS services are
distributed throughout the IMS infrastruc-
ture and terminals, ICP mirrors the architec-
ture of the infrastructure, creating a horizon-
tal architecture that includes a core part and
a service-enabler part (Figure 3). End-to-end
applications run on top of these two parts.
ICP is a highly modularized, expandable
product whose horizontal architecture (Fig-
Figure 4 ure 4) encompasses
Horizontal architecture of IMS Client an abstraction layer (AL), which encapsu-
Platform. lates all terminal- and OS-related depen-
dencies;
>BH8a^ZciEaVi[dgb a protocol layer (which can be abstracted
in the AL);
>ciZg[VXZ a control layer, which consists of a core part
and a services part; and
8dcigda an interface layer.
8dgZ HZgk^XZh The idea is that ICP will help guarantee
IMS evolution while making it easy both
EgdidXdaaVnZg
to develop and run IMS applications on all
available open-platform terminals that use
available IMS technology. ICP does this by
6WhigVXi^dc EgdidXdaaVnZg
addressing application development and
aVnZg interoperability, common enablers for stan-
dardized services, innovative non-standard-
ized services, multiclient support, flexibility
IZgb^cVaeaVi[dgbDH
and expandability, multiterminal support,
and convergence.
The ICP API hides the complexity of IMS by
solely exposing high-level primitives to ap-
plications (Figure 5).
Developers are offered a toolbox that per-
forms all low-level technical tasks on behalf
of applications, which are either controlled
by high-level function calls or executed au-
tomatically without application involvement
for example, by registering the IMS appli-
cations installed in a terminal.
ICP also manages terminal resources
and offers application developers easy-to-
understand communication objects or media
connections that can be used for exchanging
different kinds of content between applica-
tions and terminals. In addition, it enables
developers to require a given quality of ser-
vice (QoS) in an easy and intuitive way.
The ICP API is partitioned into a core
API and a service API. This design enforces
a clear method of creating new services, en-
couraging the development of totally new
services while also facilitating common and
widely accepted means of communication,
such as messaging.
ICP exposes a C++ API and a JME/CDC
(Java) API. The Java API, an early variant of
JSR-281, is usually called pre-JSR-281. The
Ericsson Service Development Studio (SDS)

52 Ericsson Review No. 2, 2007

also provides excellent support for develop-
ing Java applications.
Interoperability
Due to the complex nature of IMS, one can-
not easily accelerate application development
without using the IMS client framework.
Although 3GPP has gone to great lengths
to define and standardize the basic mecha-
nisms of IMS, there is still room for diver-
gence when implementing the specification.
Moreover, a number of primitives have yet to
be standardized, which leaves room for in-
terpretation.
The traditional way of developing a ser-
vice client entails encapsulating the entire
vertical implementation of IMS technology
inside the application. Unfortunately, this
approach has a negative impact on interop-
erability, calls for co-location of applications
in the same terminal, and results in a large
footprint.
ICP, on the other hand, is a tool for secur-
ing interoperability, among other things, by
careful compliance with IMS standards ac-
cording to 3GPP rel. 6-7. To begin with, ICP
employs all the protocols that are necessary
for implementing IMS services (Table 1).
ICP also takes actions to authenticate and
authorize terminals when they register avail-
able IMS services. At present, ICP supports
Digest and Early IMS authentication. Like-
wise, full IMS security is being planned. At
the application level, ICP sets up communi-
cation sessions, negotiating media connec-
tions and network QoS while establishing
the data-plane communication channel (PDP
context, in the case of cellular terminals).
To guarantee interoperability, ICP in-
cludes a set of enablers, or modules, on top
of IMS that implement a variety of standard-
ized communication services (CoSe).
Ericsson has put particular emphasis on the
end-to-end aspects of IMS service. Therefore,
apart from its relationship to IMS infrastruc-
ture, ICP has been included as a component
in the design process of end-to-end IMS ser-
vices. This approach ensures interoperability
between ICP-enabled terminals, the IMS
infrastructure, and the application servers
that run on top of IMS. When testing ser-
vices implemented on different ICP-enabled
terminals, for example, there is virtually no
need for additional interoperability testing,
because the terminals include the same ICP
code base (Figure 6). Even so, Ericsson tests
its own solutions together with other termi-
nal vendors solutions at GSMA test fests.
Common enablers for standardized
services
ICP implements communication-service-
related functionality in dedicated service-
enabler components (Table 2), each of which
implements the entire standardized set of
operations and client-server interactions and
exposes service functionality through a high
abstraction-level API. The ICP enablers fa-
cilitate application development and interop-
erability (Figure 7, left).
In addition, ICP includes a presence-
enhanced phone book (PEP) enabler on top of
the presence and group list management en-
ablers. The PEP enabler raises the abstraction
level of these two enablers by simplifying the
implementation of contact lists (including
the integration of presence information in
native phone books in mobile terminals and
PCs, for example, Outlook).
Innovative non-standardized services
ICP also gives developers a means of creating
innovative and attractive services that have
not yet been standardized. Furthermore, it

Figure 5
>BHiZgb^cVa >BHiZgb^cVa The ICP API hides IMS end-to-end tech-
nology from applications.
6eea^XVi^dc 6eea^XVi^dc

6eea^XVi^dc 6eea^XVi^dc 6E> 6eea^XVi^dc 6eea^XVi^dc

8db& 8db' 8db( 8db( 8db' 8db&

Xa^Zci Xa^Zci Xa^Zci Xa^Zci Xa^Zci Xa^Zci
JC> JC>
CC

>BHXdbbjc^XVi^dc
hZgk^XZ(
8db( 8db(
hZgkZg hZgkZg

>BHXdbbjc^XVi^dc
hZgk^XZ'
8db' 8db'
hZgkZg hZgkZg
>BHXdbbjc^XVi^dc
hZgk^XZ&
8db& 8db&
hZgkZg hZgkZg

Ericsson Review No. 2, 2007 53


Figure 6
ICP realizes interoperability between
terminals in different segments.
TABLE 1, PROTOCOLS INCLUDED IN ICP
SIP, according to RFC 3261
provisional responses, according to RFC
3262
event notification, according to RFC 3265
refer method, according to RFC 3515
UPDATE method, according to RFC 3311
INFO method, according to RFC 2976
event state publication, according to RFC
3903
extension for instant messaging,
according to RFC 3428
SDP, according to RFC 2327 & 3264
RTP, according to RFC 1889 & 1890
MSRP, according to RFC draft
XML
XCAP
54
>8E
>8E
>8E
supports these new applications via stan-
dardized IMS mechanisms and allows for
the definition of primitives at the applica-
tion level. Consequently, using primitives
that have been standardized by 3GPP, one
can identify new non-standard services. This
feature improves the interoperability of ap-
plications that implement new services (Fig-
ure 7, right). Interoperability in this case
is not 100% due to a lack of standardized
application identities, but time to market
(TTM) is very short, which has an impor-
tant impact on growth in the IMS applica-
tion space.
One can create new proprietary services
using the following objects of the ICP core
API:
ImsCoreService;
ImsSession (based on SIP session);
BasicReliableMedia (based on TCP);
BasicUnReliableMedia (based on UDP);
StreamMedia (based on RTP);
FramedMedia (based on MSRP);
player; and
recorder.
ImsCoreService, the main object in propri-
etary applications, is identified by an appli-
cation identity that represents the service
to be developed. Application developers
can create any number of ImsSessions and
>8E
>8E
>8E
>BH
>8E
>8E
bind them to a ImsCoreService object. Each
ImsSession is based on a SIP session and rep-
resents a service session with another service
participant. One may thus create ImsSessions
with different service participants within the
same ImsCoreService. Each ImsSession can
use any valid communication mechanism
for the SIP session and add, in bidirectional
and unidirectional mode, any number of
media connections, such as StreamMedia,
FramedMedia, BasicReliableMedia and
BasicUnReliableMedia.
Furthermore, each media connection can
be used to transmit standard as well as non-
standard objects. ICP handles audio and
video data streams using players and record-
ers without moving data between itself and
client applications. If proprietary formats are
used, the client applications read data direct-
ly from media streams and implement their
own interpreters, such as proprietary players,
games, and so on.
Multiclient support
ICP allows IMS client applications to be
co-located in the same terminal (not to be
confused with multitasking execution, which
is managed by the application run-time en-
vironment). In the context of ICP, multi-
client support addresses the
Ericsson Review No. 2, 2007
 registration of installed client applica-
tions;
launching of appropriate client applica-
tions and routing of SIP messages to them;
and
management and coordination of IMS re-
sources.
Registration of installed client applications
ICP makes terminal capabilities visible (in
terms of installed client applications) in the
IMS domain. It does so by executing the IMS
registration mechanism at launch time (usu-
ally when a device is powered on).
The 3GPP is working to standardize two
primitives for identifying application capa-
bilities:
IMS Communication Service ID (ICSI),
which identifies the standardized IMS ser-
vice; and
IMS Application Reference ID (IARI),
which identifies the type of application
used to realize a certain service. Such an
application includes proprietary service
logic implemented using the core API, and
possibly additional aggregated functional-
ity realized in standardized service. IARI
ensures interoperability between applica-
tions from different vendors that realize
the same functionality.
ICP scans the IMS application space and reg-
isters the ICSI and IARI of installed applica-
tions.
Launching client applications and routing
SIP messages to them
ICP uses the ICSI and IARI in SIP messages
as routing keys.
HiVcYVgY^oZY
Veea^XVi^dc
^ciZg[VXZ
6eea^XVi^dc 6eea^XVi^dc
6E> 6E>
>8E >8E
HiVcYVgY^oZY
>BH^ciZg[VXZ
Ericsson Review No. 2, 2007
There are two steps or levels in message TABLE 2, ENABLERS OF STANDARDIZED
dispatching: ICSI level and IARI level. ICSI SERVICES IN ICP
identifies the service enabler to which the SIP
weShare (Ericsson implementation of
message is to be routed. The service enabler 3GPP-standardized CSI service)
responds in accordance with standardized OMA push-to-talk-over-cellular standard
service mechanisms and forwards an appro- OMA presence standard
priate event to the application (identified by OMA group list management (XDM)
standard
the IARI). If no ICSI has been included in OMA simple messaging standard
the message, the application implements its Peer-to-peer VoIP
own service logic and the messages are routed
directly to the application.
ICP supervises the life cycle of IMS ap-
plications. If the addressed application is not
running, ICP launches it before routing the
incoming SIP message or event.
Management and coordination of IMS
resources
The ICP API exposes access to communica-
tion and multimedia resources. Client appli-
cations can request resources without bother-
ing about one another. ICP allocates media
streams and communication ports, negotiat-
ing with other service peers while establish-
ing sessions. Each client application owns
the resources in use while a session is alive.
When the application or one of its sessions
is terminated, ICP automatically releases all
associated resources.
Flexibility and easy expandability of
ICP
The ICP architecture is highly modular, con-
sisting of different components with dedi-
cated functionality and well-defined internal
APIs. The components are grouped together
in either a core or service-enabler domain
(Figure 8).
Egdeg^ZiVgn Figure 7
Veea^XVi^dc Left: Interactions between realizations of
^ciZg[VXZ
standardized services.
Right: Interactions between realizations
6eea^XVi^dc 6eea^XVi^dc
of proprietary services.
6E> 6E>
>8E >8E
HiVcYVgY^oZY
>BH^ciZg[VXZ
55
 <ZcZg^X6E> HZgk^XZZcVWaZg6E>

>BHbVcV\Zg >BHhZgk^XZZcVWaZgh
>8EXdgZ 6E> 6E> 6E> 6E>
Ed8 Kd>E 8H> M
>BHhZhh^dc >BHhZgk^XZ 6E>
E:E 6E>
BZY^VM BZY^VN 6E> 6E> N
<AB EgZhZcXZ
EaVnZg
@ZgcZa6E>
GZXdgYZg M >BHgZ\^higVi^dcbVcV\Zg
>8E
GZedh^idgn N 8dc[^\jgVi^dcbVcV\Zg

H>EV\Zci BHGEV\Zci GIEV\Zci =IIEV\Zci I8EV\Zci J9EV\Zci

H>E BHGE GIE$GI8E =IIE MBA M86E GIHE

H>E BHGE GIE$GI8E =IIE 6WhigVXi^dc MBA M86E

Figure 8 aVnZg
Interactions between realizations of pro- IZgb^cVaeaVi[dgb
prietary services.

ICP core
The ICP core domain consists of a kernel,
various protocols, control objects, and in-
terface objects. The kernel is responsible for
fundamental ICP functionality and core IMS
functionality.
Apart from the kernel, each of the compo-
nents or objects in ICP can be extended and
tailored to specific needs.
The protocols consist of several protocol
agents together with optional protocol stack
implementations. The protocol layer includes
mandatory protocol agents that manage all
connections using dedicated protocols. Pro-
tocol stacks are implemented together with
ICP, but can be replaced in hardware and
software by the realization in the terminal
platform. The ICP architecture supports easy
expansion via new protocols.
Control objects are a set of modules that
implement dedicated functionality on top
of the kernel and protocols to extend ICP
functionality. New modules can be added as
needed to complement ICP functionality, for
example, voice call continuity (VCC).
Interface objects are a set of objects that
expose primitives to applications through the
API. The API, which reflects the function-
ality implemented in ICP, can be extended
with new interface objects as new functional-
ity is exposed for developers.
Service enablers
Service enablers implement functionality at
the service level. There are two main reasons
for grouping functionality in enablers:
to ensure compliance with standards (for
standardized services); and
to group service-related parts of function-
ality for reuse by many different clients.
The implementation of enablers relies on
public APIs exposed through the core and
enabler parts of ICP. In addition, enablers
can access the kernels low-level APIs, there-
by exposing the low-level mechanisms that
are needed to develop enablers.
In many cases it makes sense to create an
enabler even when there is no standardized
functionality to be encapsulated. For example,
one might implement interactions with the
local PBX to access its value-added services.
This way, client applications can access these
services through an enablers high-level API.
The ICP architecture also allows Ericssons
partners to develop dedicated enablers; that
is, the model permits
free implementation of proprietary en-

Figure 9 >BHXa^ZcieaVi[dgb
Components of the abstraction layer.
6E>

6WhigVXi^dcaVnZg EgdidXdahiVX`h H>E GIE$GI8E BHGE =IIE MBA M86E

CZildg` ;^aZ I^bZg IZaZe]dcn :cXdYZg$YZXdYZg 8VbZgV 6eea^XVi^dc

hnhiZb VjY^d$k^YZd [gVbZldg`

56 Ericsson Review No. 2, 2007

 ablers on top of core and kernel APIs; and
newly developed enablers to be included,
after certification, in the ICP configura-
tion.
Unlike the core part, which must be included
in every ICP configuration, the service enabler
part is optional and highly configurable. Any
enabler may be included in the ICP configu-
ration. In addition, common mechanisms are
used for accessing APIs exposed by enablers.
One may thus dynamically extend the ICP
configuration simply by installing any addi-
tional enabler component.
Multiterminal support
Ericsson can easily port ICP to different op-
erating systems. Indeed, all aspects of the
IMS Client Platform are independent of the
terminal operating system, because ICP has
been partitioned into two parts, namely the
ICP functional part and the abstraction layer
(AL).
The abstraction layer encapsulates all
operating system dependencies, including
network, file system, timers, telephony, co-
decs, and protocol stacks (optional). All AL
functionality is exposed through an API that
is accessed via the ICP functional part (Fig-
ure 9).
In summary, multiterminal support offers
the same API on all supported terminals and
ensures that the IMS functionality in ICP
complies with standards regardless of operat-
ing system. It also simplifies interoperability
testing by using the same code base and the
same API, which yields the same perception
of service realization when new proprietary
services are implemented.
At present, ICP supports Windows 2000/
XP, Symbian/UIQ, Linux, and vxWorks.
It will also eventually support Windows
Mobile, Symbian/S60, and Mobile Linux.
different terminals without having to change
the service level (only the GUI is affected). In
addition, ICP supports SIP methods of mov-
ing an entire session to a different terminal.
An interesting study case entails moving just
one media connection between two ICP-
enabled terminals.
Even though ICP is access-independent,
the second aspect of convergence is dependent
on access network support in the terminal.
In other words, terminals may realize IMS
services using any supported access network
type. The Sony Ericsson P990 Smartphone,
for instance, can access the same service us-
ing UMTS, WLAN and Bluetooth.
Standardization of IMS
client framework
Early on, while implementing ICP, Ericsson
worked hard to make the IMS client frame-
work available for a broad Java development
community. At the end of 2005, Ericsson
and BenQ Mobile (formerly Siemens Mobile)
jointly proposed standardization of an IMS
Services API within the Java Community
Process (JCP), which is in charge of stan-
dardizing Java APIs. JCP approved the pro-
posal and formed the JSR-281 Expert Group.
Figure 10
JSR-281 architecture.
8dgZ
6E>aVnZg :kZci ;gVbZY HigZVb
[gVbZldg` bZY^V bZY^V
From the start, there has been broad support
for this JSR as seen by the 34 experts work-
ing in the expert group.
The goals of the expert group are to stan-
dardize the IMS services API, including (in
conformity with ICP) the core and service-
enabler parts. Service enablers include IMS
presence, XDM (group list management),
and PoC. The architecture of JSR-281 is
strongly related to the architecture of ICP
(Figure 10).
As in ICP, the IMS core part constitutes
the base for implementing service enablers.
The enablers in JSR-281 were defined accord-
ing to the state of standardized IMS services
at the time JSR-281 was formed. New service
enablers will be included in coming versions
of the IMS services API as the services are
standardized.
The abstraction level of the API defined
in JSR-281 is the same as that of ICP but
the details of the API differ due to ongoing
work in JSR-281 standardization. When the
work is complete, the ICP API will be fully
aligned with JSR-281. The ICP API will not
be limited to the set of methods in JSR-281,
however, because ICP offers broader func-
tionality, especially in the area of service en-
ablers. JSR-281 is scheduled for release in Q2
2007.
HZgk^XZ6E>
HZhh^dc Ed8 >BH <AB
egZhZcXZ

7Vh^X EaVnZg GZXdgYZg CZildg` M9B

bZhhV\^c\
Convergence
IMS fixed-mobile convergence guarantees
access network independence. Services may
>BHXdgZ >BH
thus be used on the terminal and access net- egZhZcXZ >BHhZgk^XZZcVWaZgh
work that is most convenient for any given ;gVbZY HigZVb Ed8 >BH <AB
G>aVnZg bZY^V bZY^V
end user at any given time, for instance,
using different terminals (for example, 7Vh^X
bZhhV\^c\ EaVnZg GZXdgYZg M9B
while moving a video session from, say, a
mobile phone to a TV set); or
using different access networks from the :kZci[gVbZldg` GZ\^hiZg$Vji]dg^oZ CZildg`
same terminal (for example, by transfer-
ring a video session from UMTS to WiFi
as one enters a WLAN hotspot). 9Zk^XZHL
HiVX`h/
eaVi[dgb
Given that ICP supports terminals in differ- aVnZg
H>E$H9E$GIE$GI8E$BHGE$MBA$=IIE$M86E

ent segments, the same service can be run on

Ericsson Review No. 2, 2007 57


Figure 11
Developer view of service development.
Service Development
Studio
Ericsson has created the Service Develop-
ment Studio (SDS) to facilitate further de-
velopment of IMS services. This integrated
development tool, based on Eclipse IDE and
complemented with plug-ins that realize a
development environment for IMS services
in an end-to-end context, supports the de-
velopment of end-to-end solutions, includ-
ing client and server parts. JSR-116 exposes
a SIP Servlets API for server-side develop-
ment of service. ICP is the cornerstone on
the client side. A pre-JSR-281 ICP API ex-
poses IMS functionality for client applica-
tion development.
SDS includes the entire environment for
developing, testing and deploying IMS ser-
vices.
On the client side, applications are devel-
oped and run on top of real ICP implemen-
tations installed on Windows together with
the complete SDS installation. A Symbian/
UIQ emulator is included in the installation
for applications that target Symbian smart-
58
>BH:':hZgk^XZh
EgZ"?HG'-&
>BH8a^ZciEaVi[dgb>8E
8H8;
H>E BG;
>BH
I>HE6C
Bjai^"VXXZhh
phones. ICP is automatically installed on
the Symbian emulator during the SDS con-
figuration process. This ensures consistency
of ICP run time, since ICP is identical in
both the emulation environment and target
terminals.
SDS can simulate the entire IMS infra-
structure, enabling developers to realize the
complete development cycle and end-to-end
tests on a single computer without connec-
tion to an actual IMS infrastructure (Fig-
ure 11).
In addition, SDS offers a toolbox for cre-
ating IMS client applications by means of
specific plug-ins that support client de-
velopment projects and the deployment of
applications in emulated and target termi-
nals.
Conclusion
Ericsson stands behind the IMS concept as
a way of realizing end-user communication
needs. IMS technology offers a framework
that supports several basic mechanisms that
are necessary for creating rich, interoperable
?HG&&+

>BHhZgkZgeaVi[dgb
8H8;
=HH H>E
(<EE
services. Notwithstanding, IMS is complex
and sometimes daunting to application de-
velopers. Ericsson recognizes this fact and
understands that it could impede the IMS
application market. As a consequence, it
has created the IMS Client Platform, which
hides the details of IMS technology from de-
velopers while exposing IMS functionality
in a simple, straightforward way (high-level
abstraction API). This approach
simplifies and speeds up the development
and deployment of new services;
ensures compliance with standards for core
IMS functionality and services;
substantially shortens time to market;
substantially simplifies interoperability
testing; and
gives end users the same service regardless
of terminal platform or access technology.
The industry broadly supports this concept
through the standardization of a Java-based
IMS services API. Ericssons ICP serves as
the basic framework in this standardization
process and will be the flavor of JSR-281 for
terminals that are not addressed by stan-
dardization.
Ericsson Review No. 2, 2007
 REFERENCES AND TRADEMARKS
1. Donne, John. Nunc Lento Sonitu Dicunt Mori-
eris [Now, this bell tolling softly for another,
says to me: Thou must die.] From Devotions
upon Emergent Occasions, XVII, 1623
2. Enstrm, D., Nohlgren, A., Olofsson, H., Peisa,
J. and Synnergren, P. Multimedia telephony
for IMS Interoperable VoIP with multimedia
support. Ericsson Review, Vol. 84(2007):2, pp.
10-13
3. Camarillo, Gonzalo and Garcia-Martin, Miguel-
Angel. The 3G IP Multimedia Subsystem (IMS):
Merging the Internet and the Cellular Worlds,
2nd ed. Chichester: John Wiley & Sons Ltd,
2005
Ericsson Review No. 2, 2007
3GPP is a trademark of ETSI in France
and other jurisdictions
Java, and Java Servlet are trademarks
or registered trademarks of Sun
Microsystems, Inc. in the United
States and other countries
Symbian, Symbian OS, and other
trademarks incorporating the word
Symbian in conjunction with other
words or logos are brands of Symbian
Software Ltd
Windows and Windows Mobile are
trademarks or registered trademarks
of Microsoft Corporation
59