Ericsson Review No.

1, 2008
8
Introduction
Based on the following observations, it
would seem inevitable that IMS will suc-
ceed. First, IP technology is essentially the
basis for all present and future mass-market
communication. Second, users are attracted
by experiences that are rich in multimedia
features, such as high-quality audio, video,
and multimode communication. Third, the
market anticipates the rapid creation and in-
troduction of multiple services. Fourth, these
new services must be able to fully utilize the
capabilities of access network technology.
And nally, only one comprehensive, multi-
vendor, multi-operator, internationally stan-
dardized architecture fullls all these crite-
ria: IMS.
But as history repeatedly shows, the most
perfect technology does not always prevail.
Instead, the winning alternative is the one
that is capable of attracting real market sup-
port. Therefore, there is a need to show that
IMS has the qualities to become the clear
tool of choice for application developers. This
article explores how the advanced and varied
features of IMS can simply and effectively be
packaged and exposed to developers and user
communities.
The IMS market: serving
two masters
Two forces are shaping the IMS architec-
ture. The rst is the need to provide services
for a true mass market with the same global
reach and impact as, say, telephony and
SMS. The second is the desire to tap into
the extraordinary creativity and dynamics of
the IP community so that operators can give
end-users attractive and compelling service
offerings. This gives rise to two categories
of services:
Mass-market, standardized services which
are supported by a wide range of terminals
and which interoperate within the global

operator community. These services are

characterized by scalability, availability
and performance; functional growth is de-
ned by standardization.
Non-standardized services that individu-
al operators can give to their customers,
within an operator group regionally, be-
tween different operator groups, or even
globally. These services are characterized
by exibility and rapid time to market.
The emerging IMS ecosystem supports the
development of new services and a rich busi-
ness landscape. Building on carefully de-
signed interfaces, it allows operators (as well
as any third party) to launch new services
or to expand existing ones. The interfaces
provide the architectural foundation for ad-
dressing the two categories of services listed
above. Furthermore, to facilitate the develop-
ment of creative new services that incorpo-
rate the standard capabilities as components,
the standardized mass-market capabilities
can be exposed through published interfaces
to downloadable clients and network servers
(Figure 1).
Therefore, by combining the best parts of
these two service categories, the new services
have the potential to rapidly come to mar-
ket with a global reach and without affecting
network infrastructure.
Complementing this, we also need power-
ful development environments that put these
components at any developers ngertips for
ready incorporation into innovative combi-
nations.
The Communication
Services concept
The key to understanding the Communica-
tion Services (CoSe) concept lies in the notion
that achieving global reach and interoper-
ability requires interworking interfaces that
are well established and stable. This simple
statement has two distinct facets:
The developer view: How, for instance,
can application developers request support
from, and interact with, the IMS infra-
structure that is, the API view?
The industry view: How can the industry
ensure the rapid deployment of applica-
tions without affecting infrastructure?
And how can the industry ensure that us-
ers benet from a true mass market that
is, a broad array of devices, a competitive
market dened by price, quality and func-
tional diversity, and any-device-to-any-
device connectivity?

IMS gives developers a tremendous range of opportunities to create ser-

vices, and this freedom is being used to craft timely, attractive, innovative
and differentiating applications as well as standardized services from, for
example, 3GPP and OMA. This ensures that operators continue to play
a valuable and protable part in delivering voice, video, text, and more to
a gigantic consumer community. Signicantly, IMS brings multimedia-
enabled communication to the market while retaining the basic character-
istics of telecommunications: reliability, predictability and global reach.
The authors explore Ericssons strategy for achieving differentiation and
mass-market reach in the same architecture.
Communication Services The key to IMS
service growth
Ulf Olsson and Mats Stille
TERMS AND ABBREVIATIONS
3GPP Third Generation Partnership
Project
API Application programming interface
ASP Application service provider
CoSe Communication service
IARI IMS application reference identier
ICSI IMS communication service
identier
IETF Internet Engineering Task Force
IMS IP Multimedia Subsystem
Java EE Java Enterprise Edition
JCP Java Community Process
JSR Java Specication Request
MMTel Multimedia Telephony
MSRP Message session relay protocol
NNI Network-to-network interface
OMA Open Mobile Alliance
PoC PTT over cellular
PTT Push to talk
QoS Quality of service
RFC Request for comment
RTP Real-time transport protocol
SDP Service delivery platform
(also Session description protocol)
SDS Service Development Studio
SIP Session initiation protocol
SMS Simple message service
TISPAN An ETSI activity, created by the
combination of TIPHON (Telecom
munications and Internet Protocol
Harmonization over Networks) and
SPAN (Services and Protocols for
Advanced Networks)
UE User equipment
UNI User network interface
Review108.indd 8 08-01-21 16.07.54
Ericsson Review No. 1, 2008
9
The developer view
The IMS control plane is based on the IETF
session initiation protocol (SIP), which is a set
of simple operations, including REGISTER,
INVITE, ACK, and BYE. Combine this
with SDP (session description protocol, the
protocol for dening media), the 3GPP IMS
service identication (ICSI and IARI) model,
and other related standards, and you have an
incredibly varied landscape of service behav-
iors, ranging from simple and direct interac-
tion to complex services, such as Multimedia
Telephony. As usual, this creative power does
not come for free. To understand and interact
with a complex service, one must understand
the standard (3GPPs rather large set of IMS
specications, IETFs RFC3261 plus several
dozen related RFCs) as well as the architecture
of the application. Typically, the right user ex-
perience is dependent on the proper sequenc-
ing of SIP messages. For standard applications,
the message exchange pattern is described in,
for example, OMA (for presence and IM) and
TISPAN/3GPP (for Multimedia Telephony).
Building a downloadable peer-to-peer
client application directly on SIP seems
simple because this basically only entails
interworking with as it were yourself.
However, if somebody else implements the
peer, then a standard (at very least, a pub-
lished de facto standard) becomes necessary.
This is especially true if the service requires
network support, and trafc is expected to
pass through servers that are owned and op-
erated by different actors. Standards are thus
a necessity, because they typically specify
complex multi-participant interactions. The
complexity of a given service should, howev-
er, be controlled in order to avoid ending up
with feature overload: the kind of vertical
monolithical implementations that dampen
innovation and fragment the market.
Partitioning the problem space
Does this mean that everybody needs to
understand how Communication Services
actually work? In a word, no. That would
put an effective end to innovation and service
growth. However, we do need to structure
and horizontalize the problem space. This-
brings us to a key theme of this article, an
almost ancient principle of good software
engineering: abstraction. In particular, what
we should aim for is to raise the level of ab-
straction from individual SIP messages to
atomic operations that make sense to appli-
cation developers (Figure 2). Some examples
follow:
registerApplication (connect the applica-
tion with the infrastructure);
callUser (create a multimedia session with
another user);
createGroup (set up a push-to-talk session
with, for example, players in a game); and
addVideo (add a media component to an
existing session).
This way, all a developer needs to worry
about is a compact and easily understandable
application programming interface (API).
The focus of the API is what the developer
needs, not the complex signaling sequences
needed to make it work.

Developing in the terminal

Developers of a client-side application are
mostly interested in the Communication
Service endpoints. The capabilities represent-
ed by the CoSe APIs are essentially captured
in standards, such as OMA IMS Messaging,
OMA Push-to-talk, OMA Presence, and
TISPAN Multimedia Telephony. As they
should, these standards tend to stop short of
programming issues, but as a consequence
the functionality described in the stan-
dard must also be expressed in a way that
is more closely adapted to the workbench of
the application developer. Given that Java is
Figure 1
IMS supports person-to-person and person-to-content communication.
Multitude of non-standardized services
Standardized services
Operator A
Operator B
Figure 2
IMS as a black box.
Device-side
application
Device Service network
APl APl
IMS
Server-side
application
Device
infrastructure
Network
infrastructure
Review108.indd 9 08-01-21 16.07.55
Ericsson Review No. 1, 2008
10
Ericssons strategic rst choice for application
development, the main thrust of API deni-
tion is in the realm of the Java Community
Process (JCP) .
Java Specication Requests (JSRs), the
products of the JCP, are complete APIs to-
gether with reference implementations and
conformance test kits. At present, several
initiatives are under way. The rst (JSR281,
a basic IMS API that has been released for
public review) will be nalized in 2008
and embodies the basic abstractions of IMS
interaction (Figure 3). Ericsson is driving the
JSR281 effort to underline the strategic im-
portance it attaches to these activities. The
API gives developers an IMS core functional
level that includes basic authentication, sig-
nal routing, and session setup toward a called
party or a server end-point.
Developing on servers
At this point, it should be noted (as stated
in Figure 1) that there is a variety of IMS-
based services. To people with a telecom
mindset, services tends to mean features that
modify how a network sets up and manages
sessions. In this context, services deal with
issues like call diversion, number translation,
and charging. In IMS, these kinds of services
are typically managed by linking servers in
the control ow path. This kind of feature
is thus tightly coupled to the main service
(for instance, MMTel), which is to say opera-
tors typically control it. A third party may
have developed the feature, but it must still
be carefully integrated into the network, be-
cause it can potentially affect the stability of
the operators core business.
However, the other point of view the
information/entertainment pattern of ac-
cess is growing in importance, resulting
in a clear asymmetry between the consumer
and network sides of the interaction. This
means that services can have a much looser
coupling to the network. SIP endpoints can
be used for applications (for example, con-
tent delivery), but in all likelihood a wide
range of services will be built directly on
top of web service interfaces that expose
network capabilities. Note also that with
phenomena like YouTube, the end-user can
both consume and produce content. And in
the case of Facebook this concept of user-
generated content can even be extended to
user-generated services!
On the server side, JSR116 (and its evolu-
tion, JSR289) is the fundament for aggregat-
ing SIP-based Java components into complete
network-side applications. These capabilities
are an integral part of the industry-standard
Java EE environment, providing
an efcient environment for creating SIP-
based services as such; and
the means of exposing the SIP services us-
ing interfaces that developers who are ac-
customed to web-style programming have
come to expect.
The industry view
Given that the IMS control plane consists of
SIP, and the IMS architecture denes the basic
session-management procedures, do network
operators or device vendors really need to
worry about anything else? In fact, yes.
To begin with, the network as well as the
SIP stack in a terminal must understand
what to do with a new session. In the net-
work, the session must be routed to the ap-
propriate server; in the device, to the correct
application. One cannot merely rely on the
basic SIP level, because SIP (through SDP)
solely indicates which media are to be used;
that is, it does not provide any information
about context.
Second, the network must be able to apply
the correct policy to the session, for example,
by selecting the proper quality bearer.
Third, if the session crosses operator bor-
ders, then for charging and settlement pur-
poses, there must be some means of iden-
tifying the session type. A user might be
consuming resources from a network other
than the one with a direct relationship to the
service provider. These issues are unavoidable

Figure 3
An application that employs JSR281 (basic IMS).
Yes No
Send Othello
invitation
to user-B?
Othello
lMS core
Create
session
Session
started
Accept
session

Launch
application APl (JSR281j
Payload e.g. MSRP
lMS core
Basic lMS:
lnvite (lARl = Othelloj
200 OK
ACK
Othello
User-A
Yes No
Play Othello
with user-A?
User-B
Figure 4
The simplest view of a standardized ser-
vice.
A-side
server
End
point
End
point
B-side
server
UNl
UNl = User-to-network interface
NNl = Network-to-network interface
NNl UNl
Review108.indd 10 08-01-21 16.08.04
Ericsson Review No. 1, 2008
11
as long as resources are nite and (relatively)
expensive to produce (as is the case in the
mobile world for the foreseeable future).
Note that alternate business models, such
as nancing by way of advertising, do not
eliminate this need. The key is the network-
to-network interface (NNI). In other words,
a concept of services needs to be established
that supports a multi-operator cost-and-
revenue-sharing business environment with-
out having to renegotiate complex inter-
working agreements every time a new ser-
vice is launched (Figure 4).
As mentioned above, a fundamental ob-
servation for this discussion is that services
are not dened by media type. Voice, for
instance, is an obvious component of tele-
phony, but it is also present in push-to-talk
and messaging voice clips. In general, if the
main characteristics of a service are consid-
ered topology (point-to-point, star, mesh,
and so on) and time behavior (for example,
full duplex, oor control, store-and-forward),
then one may conclude that all services can
potentially support all kinds of media (au-
dio, video, text, and so forth). Accordingly,
IMS emerges not merely as a solution for
multimedia, but as a multiservice environ-
ment. It follows that, the base mechanisms
of IMS which inherit media-negotiation
capabilities from the SIP offer-answer model
can make good use of some additions in
order to become a truly global solution.
New tools in the toolbox
Therefore, there is a need to identify com-
munication patterns at levels above the ba-
sic SIP session model. Existing services have
recognized this need, introducing service
identiers in various ad hoc fashions. Re-
cently, 3GPP introduced the IMS commu-
nication service identier (ICSI) to provide a
standardized, scalable and manageable way
of handling services. In addition, 3GPP has
specied the IMS application reference iden-
tier (IARI), to give application developers
of an enterprise or organization a unique
identier to use for innovative proprietary
services. IARI uses either
an IMS Communication Service (CoSe) as
bearer, in order to inherit its characteris-
tics, service logic, and NNI agreements
for transport; or
the basic IMS core as transport (JSR 281).
To exemplify, let us imagine that a devel-
oper is making a mobile phone whiteboard
application that enables consumers to talk
and draw with one another. The talk part

of the application requires real-time voice

characteristics, whereas the draw part re-
quires the interactive exchange of data. The
developer rst selects the ICSI of a standard-
ized service (such as MMTel) that supports
simultaneous full-duplex voice and data.
The developer then sets an IARI that identi-
es whiteboard (Figure 5).
The ICSI and IARI are both placed in
the same outgoing SIP request. The desti-
nation terminal dispatches the SIP request
to the standard application behind the ICSI,
which in turn, relays the session to the non-
standard whiteboard application behind the
IARI. Payload will be RTP voice and, for ex-
ample, MSRP SEND, which carries white-
board commands.
One other example (a single-media CoSe-
based application) might be a PoC talk-burst
chess application where a consumer
depresses the PTT button;
speaks a command, such as Move queen
from D4 to D7;
releases the PTT button; and
waits for the network game server to make
its move.
In this case, the initial SIP request might
contain ICSI (PoC) and IARI (chess). The
ICSI is used by the network to link (that is,
to add to the protocol-processing chain) any
SIP application server associated with the
ICSI. The IARI and ICSI are used by the
local destination end-point dispatcher to in-
voke the correct application.
From an industry point of view, this ex-
ample shows that consumers who belong to
any operator with a PoC NNI service agree-
ment can, in principle, reach the application
service provider (ASP; that is, the mobile op-
erator or third party who hosts the chess
server). The talk-burst chess client can be
either pre-installed or downloaded to devices
after purchase. Sending an SMS with the let-
ters CHESS to the ASP is a simple example
of how one can initiate the download of the
client to a JSR API-enabled phone platform.
The 3GPP has standardized a new fea-
ture tag, g.3gpp.app_ref, which can carry the
IARI and ICSI in an unaltered container
(the accept-contact header) from endpoint
to endpoint. In addition, a new header
(P-Preferred-Service) carries the ICSI from
UE-A to network-A. This is primarily for
network usage purposes, such as service
authorization, QoS allocation over radio,
and for linking in a SIP application server.
After service authorization (ICSI) has been
approved, Network-A changes the header to
a)
b)
c)
d)
P-Asserted-Service, and sends it to Network-
B. But because Network-B does not forward
the header to the remote end-point (termi-
nal or server), the ICSI must also be set in
the g.3gpp.app_ref.
Communication service types
At present, we see three major communica-
tion services emerging that represent dif-
ferent user behavior and network topology
(Figure 6). They are:
Multimedia Telephony as dened by
TISPAN. This communication service is
based on the model of a basic person-to-
person interaction pattern inherited from
classical telephony but extended with
multimedia capabilities.
Push-to-talk as represented by PoC (PTT
over cellular). The interaction pattern here
is half duplex, with oor control as a basic

Figure 5
End-to-end view of two example servi-
ces.
White
board
White
board
Chess
MMTel
MMTel
MTAS
PTT-AS
MTAS
PTT-AS
Chess
PoC
PoC
UNl NNl
UNl
Figure 6
Three kinds of communication service
(CoSe).
:cY
ed^ci
:cY
ed^ci
:cY
ed^ci
:cY
ed^ci
:cY
ed^ci
:cY
ed^ci
UNl NNl UNl
Review108.indd 11 08-01-21 16.08.10
Ericsson Review No. 1, 2008
12
network feature. Note that addressing also
differs from MMTel: the central concept is
the group (predened or ad hoc).
Messaging, where the interaction pattern
emphasizes a store-and-forward model.
One should understand that these are just
three of many potential communication
services being developed. The concept in no
way restricts the denition of new commu-
nication services, or even the direct use of
basic IMS. Indeed, in all likelihood the rst
crop of IMS services will be deployed on ba-
sic IMS, because this approach yields quick
results with a minimum of infrastructure
investments. Below, however, we explore
the CoSe concept further, since it represents
the level of abstraction that will provide the
best balance between a simple interface and
a highly capable network service.
Benets of CoSe concept
So far, one might get the impression that the
CoSe concept severely constrains IMS. And
wasnt the point of IMS to provide much
more development freedom? The solution to
this apparent conict lies in three observa-
tions. First, the existence of communication
services in no way stops one from dening
new peer-to-peer IMS applications on top
of the IMS core (basic IMS). One of the key
assets of IMS is that it is multiservice; that
is, the same infrastructure can host many
different services, even for the same user.
Therefore, having communication services in
a service suite still allows users to subscribe
to any other interesting feature.
Second, and probably more important,
the CoSe concept is yet one more example
of one of the most successful strategies in
software (and system) development, namely
information hiding. Communication ser-
vices encapsulate the detailed implementa-
tion and management of complex behavior,
thereby hiding the mechanisms needed to
ensure proper interworking between devices
and networks. The CoSe concept implements
these capabilities through interfaces between
devices and networks, as well as between co-
operating networks. These interfaces are ab-
solutely essential preconditions for creating a
truly global IMS user community.
Third, these capabilities are exposed to the
application developer community as well-
dened, developer-friendly APIs. They are
tailored to allow developers to do their jobs,
by hiding the housekeeping that typically
detracts from what should be the focus: cre-
ating the end-user service.

Figure 7
Delivering a session inside the terminal.
White
boarding
Default
app
Default
app
Default
app
Poker Chess
Multimedia
telephony
service
lMS
messaging
service
PTT over
cellular
service
SlP/lMS stack
lCSl
CoSe
applications
lMS
services
lARl +
absence
of lCSl
P2P
application
Othello
lMS communication services
SlP (lCSl/lARlj
Dispatcher
APl JSR281+
APl JSR281
Figure 8
Exposing network capabilities as web services.
Device-side
application
Device Service
network
Web services
APl APl
IMS
Server-side
application
Device
infrastructure
Network
infrastructure
Review108.indd 12 08-01-21 16.08.19
Ericsson Review No. 1, 2008
13
This brings us to the most important value
of the CoSe concept: the ability to combine
the capabilities into aggregated, higher-level
services and then deploy them without hav-
ing to update complex network-to-network
interworking agreements. The main point is
this: if you base your application on Com-
munication Services, you get instant access to
a vast market that is supported by standard
interfaces and interworking agreements. Fig-
ure 7 illustrates the relationship between
the basic IMS stack, IMS communication
services (ICSI), and application developer
clients (IARI). It shows how ICSI and IARI
are used to route incoming signals to the rel-
evant agent in the terminal, allowing it to
become an efcient multiservice device that
offers a coherent end-user experience. The
SIP stack and IMS middleware are shared;
the standard CoSe clients are integrated and
extended to provide the APIs that higher-
layer services can use.
IMS and Web 2.0
The described method of exposing the capa-
bilities of IMS infrastructure and enablers is
the key to understanding how IMS will nd
its proper place in the Web 2.0 world. Den-
ing and exposing IMS capabilities as higher-
order abstractions, thereby making them
available as components for creating new and
innovative applications, is very much in line
with the vision of the web as an environment
where innovation feeds on innovation. What
is more, when seen from the other side, the
introduction of web-oriented programming
environments, such as Java EE, means that
IMS-based services can benet from other
enablers exposed as web services or compo-
nents accessible from Java (Figure 8).
The developer workbench
Thus far, we have discussed the abstractions
that application developers will see and use:
basic IMS, and the higher-level CoSes. This
is all made possible through integrated de-
velopment environments like the Service
Development Studio (SDS), which is an in-
tegrated, Eclipse-based desktop environment
with a tool suite that includes
classical edit/compile/build tools for termi-
nal- as well as server-side applications; and
a complete testing environment a fully
functional terminal emulator, a complete,
fully congurable IMS core, an application
server for deploying SIP Servlets, and a
presence server.

Developers can thus complete the code/test/

debug cycle on their own desktops includ-
ing interaction between terminal applications
and server-side counterparts. This radically
lowers the turnaround time for producing
and maintaining code. It also provides com-
monality with the popular requirements
management and design tool environments
such as Rational.
Closing the loop that we started at the be-
ginning of this article, the APIs in Figure 9
comprise the basic IMS capabilities as well as
CoSe endpoints. The basic IMS terminal-side
API is dened in JSR281. On the server side,
the major activity is centered on JSR289,
which adds service-composition capabilities
to the SIP Servlet engine (originally specied
in JSR116). The next round of standardiza-
tion will address the CoSe APIs (JSR281+)
and corresponding server-side APIs.
Conclusion
The introduction of communication services
(CoSe) enables developers to create new ap-
plications on top of previous efforts, avoiding
the classical stovepipe approach. Exposing
communication services in the SDS environ-
ment further eases the introduction of IMS
capabilities as widely deployed components
in the web developer toolkit.
Given that the API is open, operators
are free to turn to any third-party applica-
tion vendor to create IMS services above the
standardized JSR API. Conversely, as seen
from an application developers point of view,
it provides the largest possible addressable
market for new products as the APIs are not
tied to any specic vendor or operator.
Together with the ability to reach across
operator boundaries in a managed way, these
mechanisms give creative developers access to
the largest market potential possible: the mo-
bile and xed communications communities.
One can thus combine the needs of the
innovation-driven, internet-style service mar-
ket and still provide the core values of the
global telecom industry: interoperability and
global reach. The CoSe concept is a frame
of reference that will allow the industry to
align without blocking creativity, resulting
in a healthy service market based on a global
and thriving IMS community.
Figure 9
The end-to-end workbench
Device-side
application
Device
JavaME
applications
Execute:
JavaME applications,
SlP servlets
Emulate: terminal,
lMS core, PGM
SlP servlets
Service
network
APl
SDS
APl
IMS
Server-side
application
Device
infrastructure
Network
infrastructure
REFERENCES
For further reading on IMS and SDP (and
many other subjects) please visit:
www.ericsson.com/technology
Review108.indd 13 08-01-21 16.08.24