Service-layer solution for IN, IMS, other service technologies
22
Ericsson Composition
Engine – Next-generation IN
The evolution from circuit-switched intelligent networks toward IMS, the internet, and the web
requires an open platform that can seamlessly and efficiently integrate legacy and new services.
J örg N i e möl l e r , Ioa n n i s F i kou r a s , F r a n s de Ro oi j,
Luc a s K l o s t e r m a n n, U l f S t r i nge r a n d U l f Ol s s on
The evolution from traditional
circuit-switched intelligent
networks to an open IMS ser-
vice layer, and the integration of
commercially successful internet
services, such as Web 2.0 social
networks, require new strategies
and investments in new tech-
nologies. Leveraging the exist-
ing subscriber base and legacy
investments is critical in this
evolution.
The Ericsson Composition Engine pro-
vides an environment for managing
feature interaction among intelligent
networks, IMS, and internet servic-
es; it also enables the creation of con-
verged and differentiating applications.
Service composition technology makes
it possible to manage interaction issues
between heterogeneous platforms and
features, allowing for easy creation and
reuse of functionality and mediating
between technologies.
BOX A  Terms and abbreviations
ACE Advanced Composition Engine
AJAX asynchronous Javascript and XML
ARI assist request instructions
BICC bearer-independent call control
EA execution agent
EJB enterprise JavaBeans
ESB enterprise service bus
ETC establish temporary connection
IMS IP Multimedia Subsystem
IM-SCF IMS service control function
IM-SSF IMS service switching function
IN intelligent network
INS intelligent network server
ISC IMS service control
ISDN integrated services digital network
ISUP ISDN user part
E r i c s s o n r e v i e w • 2 2009
C_209a.indd 22
The core infrastructure of many of
today’s networks has entered a transi- BOX b 
tion phase, as users have begun migrat- CAP, CAMEL
ing from classical circuit-switched and INAP
(CS) networks toward IP Multimedia CAP is short
Subsystem (IMS)-controlled networks. for CAMEL ap-
Protecting investments in the intelli- plication part.
gent network (IN) service infrastructure CAMEL is short
of the circuit-switched network and pre- for customized
serving a good user experience for sub- applications for
scribers requires an evolution – not a mobile networks
revolution – toward the new architec- enhanced logic.
ture. INAP is short for
IN services are frequently complex intelligent net-
and costly to develop and integrate. And work application
given that circuit-switched and IMS net- part.
works can be expected to coexist for
many years, it makes good sense to reuse
IN services within an IMS context where
applicable. The services a user is famil-
iar with should migrate with the user
toward the new network technology. In
this context, existing IN services can be
reused as they are and integrated with
IMS. Alternatively, existing services can
JBI Java business integration
JCA Java cryptography architecture
JEE Java platform, Enterprise edition
JSR Java standardizations request
NG-IN next-generation intelligent network
OCS online charging system
RMI remote method invocation
SCP service control point
SIP session initiation protocol
SRF specialized resource function
SS7 signaling system 7
SSF service switching function
VPN virtual private network
VXML voice extensible markup language
WS web service
be combined with newly developed com-
ponents and evolve to true IMS or con-
verged services, thereby profiting from
evolved network and terminal capabili-
ties. The approach of choice needs to be
motivated on a case-by-case basis.
Also, the ability to enrich existing
or evolved IN services by combining
them with services from web and inter-
net domains will give rise to even more
attractive services with a superior user
experience.
Of course, new IMS services should be
implemented to serve IMS users as well
as the still larger base of circuit-switched
subscribers. The Ericsson Composition
Engine can help implement advanced
IMS services that, in principle, are also
accessible to circuit-switched subscrib-
ers. Consequently, operators can avoid
new investments in legacy technology
and services become independent of the
access technology, which is a big step
toward “communication anywhere.”
Ericsson’s approach to evolving the
circuit-switched service layer is to pro-
vide an open multiprotocol service plat-
form that can be used for pure circuit-
switched services, pure IMS services,
and converged services. Furthermore, it
provides advanced capabilities for inte-
grating existing circuit-switched servic-
es with IMS.
As realized by the Ericsson Composition
Engine (ECE), Next Generation IN (NG-IN)
offers an efficient evolution strategy that,
in many instances, avoids implementing
and maintaining multiple variants of the
same service within separate domains.
Instead, it allows existing IN services to
be reused to serve the new IMS user base,
making use of a wide range of CAP/INAP
versions that implement the service.
A main requirement put on the service
layer is the ability to use open technology.
09-09-15 15.18.29
 23

Accordingly, the Ericsson Composition

Engine is based on the Open Multimedia Figure 1  Ericsson Composition Engine architecture integrating IMS, IN, and the web.
Platform framework10, which provides
a Java EE/JSR289 environment derived Services in the public internet
from the SUN Glassfish Communication
Server.
Operators today are under increasing AJAX Other
application application
pressure to differentiate themselves and
to provide clear value to their customers, Web services Services on enterprise service bus
not only in traditional settings but also IN IN Web service Other Other Other
application application application application application application
by embracing new internet services such
SOAP
as Web 2.0 communities. One way of easi- SCP SCP application
other vendor Ericsson IN server
ly achieving differentiation is to combine
vertical services, such as telephony, mes- INAP, CAP, …
saging, location, IPTV, push-to-talk, and
presence. Likewise, operators can capital- Advanced SIP IN Converged
ize on the popularity of internet services SSF stack composition engine application application application
by integrating them into new types of JEE/SIP application server
telecom mashups – realizing typical long- SCF stack JSR 289
tail applications. IMS service control MMTel
Consider a location-based weather INAP, CAP, … INAP, CAP, … (ISC) interface application server

forecast service that is triggered by a Service switching

function (SSF)
push-to-talk voice message: a compos- IP Multimedia Subsystem (IMS) core
ISUP Circuit switched ISUP SIP SIP
ite service of this kind could reuse exist- (CS) core
/BICC /BICC
ing telecom enablers, such as push-to-
talk, location, and messaging, while add- CS/Legacy IN domain IMS domain
ing internet weather forecast and online
map services to the mix. The Ericsson
Composition Engine enables operators
to efficiently implement and deploy tele-
com mashups of this kind for circuit-
switched and IMS users.
Figure 2  The Ericsson Composition Engine bridges technology worlds.
Next-generation IN architecture
Session initiation protocol (SIP) and IN Services in the public internet
services differ both in protocol syntax SIP services Services on an enterprise service bus
and corresponding protocol state mod- Other Other Other
els. Therefore, they are, as part of a user application application application
Other AJAX
SIP
session, invoked in very different ways. application application application
SIP services are directly linked into the
SIP signaling chain and have full control Multimedia
of the user session. IN services, by con- telephony (MMTEL)
trast, are kept apart from the call ses-
Composition
sion and maintain a control relationship MMTEL engine Web services SIP Web services
that is limited by the protocol capabili- application application application
ties, mechanisms, and triggers defined Service
database Web services
for CAP/INAP. IN/CAMELservices JEE/JSR 289 application
Further, due to the nature of IN stan-
dards, business logic is intertwined IN
with protocol-handling logic and application
protocol-determined state machines.
Consequently, use cases that incorporate
multiple service technologies require
more than the basic mapping of signal- CS networks IMS network Internet
ing and session state; indeed, any inte-
gration between IN and services based on
the latest technology also require a sig-
nificant portion of the business logic that
applies to the applications at hand.

E r i c s s o n r e v i e w • 2 2009

C_209a.indd 23 09-09-15 15.18.29

 Service-layer solution for IN, IMS, other service technologies
24

The Ericsson Composition Engine
provides the basis for Ericsson’s next-
generation IN. It is based on an open Java
EE server platform for circuit-switched
and IMS-triggered services. Advanced
composition features make it possible,
using a single trigger, to combine locally
or remotely deployed services of different
technologies in a single composition.
The Ericsson Composition Engine is a
superset of functions and concepts intro-
duced by 3GPP, including the
 IP application server (SIP-AS);
S needs of the constituent services.
service capability interaction manager
(SCIM);
IMS service-switching function
(IM-SSF);
service control function (SCF); and
trigger interaction manager (TRIM).
It can handle the protocols used on the
web as well as the service layers of the
circuit-switched and packet-switched
(PS)/IMS domains.
The aforementioned intertwining of
protocol capabilities and service busi-
ness logic requires a high degree of
adaptability from an IM-SSF solution.
Flexible alignment and integration of
the IM-SSF with services is thus a key
feature for converged scenarios. The
Ericsson Composition Engine approach-
es this requirement by providing IM-SSF
functionality via the application server
platform. With the toolset available on
this platform, Ericsson can tailor IM-SSF
functionality to the unique needs of the
integration use case at hand. This inte-
gration strategy is in clear contrast to a
hypothetical solution that favors a gener-
ic IM-SSF node as a gateway between
circuit-switched and IMS domains. A
node of this kind would provide a com-
prehensive but static set of SSF function- services must be aware of the capabilities
ality, thereby failing in practical integra- box c  provided by the underlying networks.
tion cases. IM-SSF Ericsson NGIN services products are
The Ericsson Composition Engine pres- typically realized as Java applications
The IM-SSF is
ents an innovative solution to resolving in the environment described above.
specified by
the feature-interaction issues that arise 3GPP as part
Ericsson and third parties also use this
from the composition of services coming of the REL-5
environment for custom service devel-
from heterogeneous network domains. version of the opment.
Composite services require feature- 3G network. The The Ericsson Composition Engine sup-
interaction support and are implement- IM-SSF serves ports interaction with IMS Multimedia
ed as a custom mediation function that as a SIP-AS Telephony (MMTel). Ordinarily, the IMS
considers the complete communication toward the IMS core invokes SIP services either before
core network. or after MMTel service invocation. The
The Java Enterprise Edition (JEE) appli- Out­going or introduction of the Ericsson Composition
cation server and SIP container (JSR289) incoming SIP Engine adds two additional integration
form the basis of the solution (Figure 1). sessions from an points to Ericsson’s MMTel solution. The
Web services are integrated via the IMS subscriber Ericsson Composition Engine can receive
Java API for XML web services (JAX-WS who subscribes indications from the MMTel service log-
JSR224). The platform integrates CAP/ to legacy IN ser- ic and provide information regarding
INAP via the Java connector architecture vices are routed further routing of the call. It can also
(JCA). IN protocol stacks implement an through the influence the execution of MMTel ser-
SSF role that makes it possible to use leg- IM-SSF, which vices by adding an information element
acy IN services in the composition logic translates SIP in the IMS service control (ISC) channel.
that resides on the platform. In addition, signaling from This mechanism enables ECE-based ser-
the IN protocol stacks expose the applica- the S-CSCF into vice composition with, for example, the
tion server as a service-control function CAP signaling included MMTel-terminating service but
(SCF). Services implemented on the appli- toward the SCP. without MMTel call forwarding.
cation server can thus be exposed to the The concept of
circuit-switched domain as IN services. reversed IM-SSF Advanced service composition
The protocol stacks take care of low- or IM-SCF is The Advanced Composition Engine is a
level protocol operations, such as the cod- also sometimes function in the Ericsson Composition
introduced to
ing and decoding of messages and param- Engine that makes it possible to han-
address the op-
eters. They also support mediation, but dle feature interaction between services
posite use case,
they alone should and do not implement that run on different platforms. Equally
exposing the SIP
complete service-logic-specific commu- important, it creates and executes work-
application serv-
nication procedures and service interac- flows by instantiating the abstract
er as a service
tion. The idea is to clearly separate top- descriptions of the composite service
control function
level service logic (such as business logic) (Figure 2).
(SCF) to the
from support components (such as the Service-composition technology, as
circuit-switched
protocol stacks that provide control com- network.
provided by the Advanced Composition
munication capabilities). Nevertheless, in Engine (ACE), targets integrators,
order to provide the best user experience, enabling them to quickly adapt or real-

BOX d  SCIM BOX e  TRIM BOX f  MMTel

The service capabilities interaction manager
(SCIM) is an entity in the service layer of IMS that
was introduced by 3GPP as part of the REL-5 ver-
sion of the 3G network.8 Capabilities interaction
management refers to the coordinated execution
of services. SCIM is an additional layer between
the S-CSCF and application servers, interfacing
the S-CSCF and the AS through an IMS service
control (ISC) interface. SCIM is sometimes con-
sidered to be a stand-alone entity. The functional-
ity applied by SCIM is also referred to as “service
brokering”.
The trigger interaction manager (TRIM) is a
logical entity that distributes a single trigger from
the circuit-switched core network over multiple
application servers. TRIM targets service distri-
bution in the circuit-switched network and con-
tains logic that identifies which IN services are
to be invoked for a particular call. TRIM may, for
example, be used to combine VPN with Personal
Greeting Service in one call.
The IMS multimedia telephony service (MMTel)
is an IMS standard that enables real-time multi-
media communication with the characteristics of
a telephony service over fixed broadband, fixed
narrowband, and mobile access. Converged,
fixed and mobile real-time multimedia communi-
cation is achieved using media capabilities such
as voice, real-time video, text, file transfer and the
sharing of pictures, audio and video clips.

E r i c s s o n r e v i e w • 2 2009

C_209a.indd 24 09-09-15 15.18.29


ize new adapted business offerings from
existing services. Advanced composition
follows SOA principles, and essentially
extends the SOA tooling to the IMS and
SS7 worlds.
The Advanced Composition Engine
facilitates the rapid and dynamic imple-
mentation of customized mediators
without having to write, generate, or
compile classical source code.6 This
approach to service composition flexibly
reuses existing service components and
combines them with new functionality.
Most mediation tasks can be covered by
pre-designed services (for example, trans-
lating user addresses between SIP and
circuit-switched addressing schemes)
from an existing component toolbox.
The Advanced Composition Engine
is technology-agnostic and allows com-
ponents from different platforms and
technologies to be mixed within a single
composite service. It currently supports
SIP services, CAP/INAP-based IN servic-
es, SOAP/web services, and JSON RESTful
services. Further technologies can be add-
ed efficiently without changing the core
composition concepts or the way in which
composite services are designed.
The Advanced Composition Engine
helps developers to reuse functionality
– they need only define the functions to
be included in the composite service, and
related dependencies and constraints.
The Advanced Composition Engine
selects, in run-time, the constituent ser-
vices to be executed and maintains the
overall composition session context.
Constituent services are selected by
matching developer-stipulated require-
ments and constraints with the current
system state and the service descriptions
stored in a service repository.
The accumulated state in a compos-
ite service enables the management of
service interaction between constituent
services across technological borders.
Rather than being based on protocol
abstraction, the full network triggering
context, including network addressing
information, is available in the compo-
sition context. Any protocol parameter
can be used as input for decisions or as
input for services used in the compo-
sition. Mediation functionality can be
added to the composition through com-
ponents that use the shared state – for
example, a component that translates
the user address received in an INAP mes-
C_209a.indd 25
25
sage into a SIP user ID.  front-end to the service repository; and
a
BOX g  To summarize, advanced service com- an environment for deploying and man-
SOAP, JSON, position aging the compositions on the Advanced
RESTful  nables applications to react flexibly and
e Composition Engine.
SOAP is short to tolerate changes in the environment –
for simple object such as different deployment, multi- Next-generation IN use case
access protocol. tenancy, system load, and system faults; The following example, which originates
JSON is short for dynamically selects the services to be from a recent customer proof of concept,
JavaScript object included in the composition at the time demonstrates an IMS-triggered SIP/SS7
notation. REST- of execution. This gives a more flexible composite service involving on-line
ful is short for reaction to run-time conditions than a charging and VPN control implemented
representational solution that is based on pre-defined in the circuit-switched network.
state transfer. workflows; The limited ability of the core net-
provides a toolset for managing interac- work setup to address number normal-
tion between services that originate in ization and to filter emergency num-
different technological worlds; and bers as required for the use case at hand
BOX h  enables efficient adaptation to the causes an exceptional implementation.
S-CSCF requirements of new use cases while In this respect, the example shows how
and IFC reusing large parts of previous work. easily the Ericsson Composition Engine
S-CSCF is short can address integration-specific require-
for serving call Graphical creation environment for com- ments.
session control posite services It is important to note that the integra-
function. IFC is Advanced service composition is carried tion of a VPN service with IMS and online
short for initial out through a graphical development charging does not need to be realized
filter criteria. environment that integrates as described in this example. In particu-
 graphical creation tool for modeling
a lar, Ericsson’s VPN service is already inte-
composite services; grated with online charging, and to ful-
a monitoring and debugging environ- ly profit from network and terminal evo-
ment for composite services; lution, it will evolve to be integrated
Figure 3  Example composition skeletons (originating and terminating) for realization
of the use case.
Start NN_VPN_O Start NN_VPN_T
Skeleton Id: VPN_NN_OCS_orig Skeleton Id: VPN_NN_OCS_term
Constraint: Constraint:
ServiceReference=’NN_VPN_o’ ServiceReference=’NN_VPN_t’
Number normalization Number normalization
Constraints: (Function=NN) Constraints: (Function=NN)
Emergency NR check Virtual private network
$( sip_request.to)=’112’ OR Constraints: (Function=VPN)
$( sip_request.to)=’911’ AND (NT=IMS)
FALSE TRUE
Virtual private network
End End
Constraints: (Function=VPN)
AND (NT=IMS)
Online Charging
Constraints: (Function=OCS)
AND (NT=IMS)
End
E r i c s s o n r e v i e w • 2 2009
09-09-15 15.18.30
 Service-layer solution for IN, IMS, other service technologies
Vinjett
26

with IMS directly. However, this cus-

tomer example demonstrates the ability Figure 4  High-level architectural view of SIP-triggered composi-
of advanced service composition to seam- tions with SIP and SS7-based services. Focus is on the call/session
lessly integrate circuit-switched/IN and control part.
packet-switched/IMS services within a
single application. Multiservice
Example: Subscriber A, who has an composition engine
assigned VPN group (for example, a
short-numbers group for family mem-
bers), calls Subscriber B, who also has
an assigned VPN group. When Sub- Online Ro OC SIP Number INAP INAP
charging EA normalization EA VPN
scriber A calls an emergency response integration
number (such as 112 and 911), the
Ericsson Composition Engine only AR if
invokes the number normalization ser-
vice; that is, it skips the VPN and online J EE AS
charging service, and forwards the SIP (including JSR289 SIP container)
INVITE to the core network immediate-
ly after the number normalization sends ISC
back the SIP INVITE. The number nor-
malization service handles special num- S-CSCF GW SRF
bers like emergency numbers by insert-
ing a location suffix in the B-number in
order to redirect the call to the correct
emergency center.
Figure 3 shows the composition the SIP container and SIP services. nection (ETC) message from the VPN is
skeleton for the above example. Using The online charging integration mapped by the INAP EA into setting up
either of these services, the composite service is a locally deployed SIP service a SIP dialogue using the E164 address in
service handles user interaction, releas- that integrates with online charging the ETC. The INVITE is routed by the IMS
es the call, or both. The services can per- via Diameter. User interaction may be network via a circuit-switched/IMS gate-
form user interaction without involving a factor for both VPN and online charg- way to the specialized resource func-
the composition. In the SIP paradigm, ing integration services. However, only tion (SRF), which contacts the VPN via
releasing the call implies that the next the VPN user interaction is visualized an assist request instructions (ARI) mes-
service is not invoked. in Figure 5. An establish temporary con- sage. An alternative approach is to chan-
In this example use case, there is no
need to act on subsequent events (SIP
answers) in the composition, because Figure 5  Concepts of IM-SSF, TRIM and SCIM.
there is no need to link new SIP services
or web services based on the occurrence
of these events. The skeletons are only Service conrol point Service conrol point SIP SIP
(SCP) (SCP) application server application server
executed at SIP INVITE.
The two composition skeletons in
CAP/INAP ISC (SIP)
Figure 4 are for the originating side (left) CAP/INAP CAP/INAP ISC (SIP) ISC (SIP)
and the terminating side (right). A check is
performed on the originating side to deter-
Trigger interaction IMS service switching function/ IMS service capabilities
mine if an emergency number has been manager (TRIM) IMS service control function interaction manager
called. This check determines whether or (IM-SSF/IM-SCF) (SCIM)
not the VPN and online charging service
should be triggered or bypassed. The VPN ISC (SIP)
is always used in the terminating case. CAP/INAP CAP/INAP CAP/INAP ISC (SIP) ISC (SIP)
The constraint in the top element of the
skeletons represents the selection of com- SSF
position based on information stored in
the S-CSCF/IFC and passed on in the SIP Circuit-switched core IMS core
AS uniform resource identifier.
Figure 4 shows the high-level archi-
tecture for SIP-triggered compositions. Circuit-switched domain Packet-switched/IMS domain
The SIP execution agent (EA) integrates
the Advanced Composition Engine with

E r i c s s o n r e v i e w • 2 2009

C_209a.indd 26 09-09-15 15.18.30


nel all user interaction via an IMS MRF
and have the VPN map user announce-
ment IDs in the ECE.
Figure 5 also shows the difference
between the SIP and CAP/INAP para-
digms: SIP services are added to the SIP
signaling chain, whereas IN services
maintain a control relationship with the
actual call session in the network.
Summary and outlook
Ericsson NG-IN is a composition plat-
form that can handle the various pro-
tocols used in the web as well as the ser-
vice layers of the circuit-switched and
packet-switched/IMS domains. In addi-
tion to supporting migration use cas-
es between circuit-switched/IN and
packet-switched/IMS, the concepts pre-
sented in this article allow operators to
realize new IN and IMS services and to
enrich existing IN services with services
from web and internet domains.
The Ericsson Composition Engine
(ECE) is an innovative solution to abstract-
ing and resolving the feature-interaction
issues that result from the composition
of services coming from heterogeneous
network domains, as part of the IN evo-
lution toward IMS and internet services.
Further, it enables operator-specific ser-
vice orchestration.
The architecture of the Ericsson
Composition Engine enables IM-SSF,
reversed IM-SSF, SCIM and TRIM use cas-
es without being restricted to a pure bro-
kering node or to compositions based
exclusively on call-control protocols.
Existing services can be flexibly
reused and combined within new con-
texts. This is supported by a service com-
position framework that enables media-
tion between service components across
technological borders.
References and trademarks
1. Introduction to IMS. Ericsson white paper,
March 2007
2. Olsson, U. and Stille, M.: Communication ser-
vices – The key to IMS service growth.
Ericsson Review, Vol. 85(2008)1, pp. 8-13
3. MMTEL – a standard for multimedia services
over IMS. Ericsson white paper, July 2008
4. Services in the IMS Ecosystem. Ericsson white
paper, February 2007
5. TS 23.002 v5.12.0. 3rd Generation Partner-
ship Project; Technical Specification Group
C_209a.indd 27
Jörg Niemöller,
who joined Ericsson in
1998, is Senior Research-
er at the Ericsson Re-
search Service Layer
Technologies unit. His current focus is
on techniques for composing and man-
aging services within a converged
next-generation service layer. Jörg has
held several positions in system man-
agement and research while working
on solutions for the mobile core net-
work, charging, and billing. He holds a
M.Sc. in electrical engineering from the
University of Dortmund, Germany.
Ioannis Fikouras
is the initiator and main
driver of SOA and service
composition research at
Ericsson. His research on
service composition led to the proto-
typing of multiservice composition
and, later, its production as part of the
Ericsson Composition Engine. Ioannis
holds an M.Sc. in computer science
and a Ph.D. from the University of Bre-
men, Germany.
Frans de Rooij,
who joined Ericsson in
1990, is a Strategic Prod-
uct Manager at Business
Unit Multimedia, where he
is responsible for the Ericsson Compo-
sition Engine. Frans has held a number
of R&D positions while working in the
Intelligent Network domain. Over the
years, he has worked with the AXE-
based IN platform, followed by the
TSP-based Intelligent Network Server,
and now, the Next-generation IN plat-
form, Ericsson Composition Engine.
Services and Systems Aspects; Network
architecture (Release 8), September 2008
6. Dinsing, T., Eriksson, G., Fikouras, I., 9. Next-generation intelligent networks: migrat-
Gronowski, K., Levenshteyn, R., Pettersson, P.
and Wiss, P.: Service composition in IMS using 10. Bo Andren: Open Multimedia Platform
Java EE SIP servlet containers. Ericsson Re-
view, Vol. 84(2007)3, pp.92-96
7. Rogier Noldus et al.: IMS multi-access, single
core, consistent service delivery. ICIN 2008 trademark of Sun Microsystems, Inc. in
8. TS 23.002 v5.12.0. 3rd Generation Partner- the United States and other countries.
ship Project; Technical Specification Group
27
Lucas Klostermann,
who joined Ericsson in
1997, is Solution Architect
of the Ericsson Composi-
tion Engine product, and an
Expert in multimedia architecture and
technologies at Business Unit Multime-
dia. He has been an active driver of using
open technologies in the service layer as
well as past Parlay/ParlayX products. In
his previous life, he obtained a Ph.D. in
high-energy physics after a four-year
stay at CERN, Geneva, Switzerland.
Ulf Stringer
has worked in the tele-
com industry since 1987
and joined Ericsson in
1997. He is a Strategic So-
lution Manager for Multimedia Solu-
tions at Ericsson Global Services,
working with NG-IN and SDP solutions.
Before joining Ericsson, Ulf spent 10
years developing public safety and IN
solutions at TeliaSonera in Sweden.
Ulf Olsson
has a background in
software architecture for
distributed military com-
mand and control sys-
tems. He joined Ericsson in 1996,
mainly to work with architecture issues
concerning packet-based systems
(PDC, GPRS, UMTS packet and the
CDMA­­2000 packet core network). He
is a Senior Expert with the Systems
Management group, Business Unit
Multimedia. His professional focus is
on IMS, enterprise and developer-ori-
ented issues. Ulf holds an M.Sc. in en-
gineering physics from the Royal Insti-
tute of Technology, Stockholm.
Services and Systems Aspects; Network
architecture (Release 8), September 2008
ing to IMS. Ericsson white paper, June 2009
Framework. Ericsson Review No 1, 2009
Java is a trademark or registered
E r i c s s o n r e v i e w • 2 2009
09-09-15 15.18.31