SPICE: A SERVICE PLATFORM FOR FUTURE MOBILE IMS SERVICES

Sasu Tarkoma Bharat Bhushan Ern6 KovacsNokia Siemens Networks Fraunhofer Fokus NEC

sasu. tarkoma(@,nsn. com bhushan(@fokusfraunhofer. de Ernoe.Kovacs(4@netlab. nec. de

Herma van Kranenburg Erwin Postmann Robert SeidlTelematica Instituut Siemens Vienna Nokia Siemens Networks Munich

herma. vankranenburg(4,telin. nl erwin.postmann(4@siemens. com robert. seidl(4@nsn. com

Anna V. ZhdanovaUniversity ofSurrey

A. Zhdanova(4@surrey. ac. uk

Abstract commercial services to be developed and deployedefficiently and economically. The project integrates the

Today's wireless and mobile service platforms are competence and knowledge of more than 20 leadingtypically monolithic and centralized in nature, and European telecom operators, service providers, key IT

they do not support heterogeneous service access and and telecommunications suppliers and academia.the sharing of service usage experience. New sources The SPICE project researches, prototypes, and evalu-of revenue for providers are expected to include tai- ates an extendable overlay architecture and frameworklored, personalized, and dynamically composed ser- for the rapid creation and deployment of intelligentvices that are fast to market, cost efficient, andprovide and personalized mobile communications and informa-compelling user experience. To meet the current mar- tion services. The project will provide a novel serviceket needs, the SPICE service delivery platform extends platform architecture that enables cross-domain servicethe conventional IMS by supporting advanced added- access with service roaming support. In addition,value services that are composed of more primitive SPICE works on several key technologies such asservices. We describe the IMS role and functions in component enabling middleware, service brokeringSPICE, and the use of ontology and Semantic Web and mediation mechanisms, semantic enhancement andtechnologies for achieving a better knowledge man- discovery of services, life-cycle management, context-agement in mobile service platforms. awareness [14] and multi-modality.

The project work is driven by a set of requirements

1. Introduction and scenarios, which guide the development of thearchitecture and technologies. The requirements andscenarios reflect the technological and business aspectsIn the last decade we have seen an enormous

growth of the Internet and network access has become of the different value chain players. Also new tech-ubiquitous. While there is a large diversity of services nologies and emerging standards such as SIP [4], IMS

on the Intemet. moe s(IP-Multimedia Subsystem) [19, 8], OMA (Open Mo-

onathed Intenet,mobl servicetprovision is stil ando bile Alliance) [5], OSA (Open Service Architecture)nated by conventional applications such as voice and [20] / Parlay [21], and Web services have been takenmessaging, including SMS (Short Message Service) into acnt JAI initia e hasd en asetand email and basic web browsing. New sources of av Por The deelpmntcati ons odrevenue for service providers are expected to include uand service JANloand Jaa maedpatfors can

tailred peronaized an dynmiclly ompsed er-ucts and services'. JAIN and Java based platforms cantailored, personalized, and dynamically composed ser- b sda osbeApiainSre ehoois

vices that are fast to market, cost efficient, and offercompelling user experience [3, 6]. This paper describes the goals of the SPICE projectThe EU IST SPICE (Service Platform for Innovative and gives a description of the SPICE service platformCommunication Environment) project addresses these architecture that is being developed to fulfill them. We

consider IMS service integration, interoperability, andissues by developing a framework for the rapid devel- evlto. In adiin. ecnie h eeomnopment of new mobile services [1,2,15] . The aim ofthe framework is to hide the complexities of the con-verged communications environment, and to allow 1 http://java.sun.com/products/jain/

1-4244-0992-6/07/$25.OO ©2007 IEEE

and deployment of modular, flexible, and personaliz- IMS decomposes the networking infrastructure intoable services. A knowledge-based framework and on- separate functions with standardized interfaces be-tology is presented for the development of mobile ser- tween them. Each interface is specified as a "referencevices. We also analyze how to maintain and enhance point", which defines both the protocol over the inter-IMS-based security, privacy, and trust management. face and the functions between which it operates (referThe rest of the paper is organized as follows: Section 2 to 3GPP TS 23.002 [22], network architecture). Theconsiders IMS evolution and the motivation for the 3GPP architecture is split into three main planes orpresented work. The SPICE service platform architec- layers, each of which is described by a number ofture is presented in Section 3. Section 4 examines IMS equivalent names: Service or Application Plane, Con-integration with semantic services and the knowledge trol or Signalling Plane, and User or Transport Plane.layer. In Section 5, we consider the current SPICE The service plane (application plane) provides an in-implementation status and the next steps. Finally we frastructure for the provision and management of ser-conclude in Section 6. vices, and defines standard interfaces to common func-

tionality (e.g. configuration storage, identity manage-2. IMS Evolution ment, billing, presence and location).

The control plane comprises network control serversThe IMS standard [19] defines the functional ar- for managing call session set-up, modification and

chitecture for a managed IP-based network. It aims release. It is located between the application and trans-to provide a means for carriers to create an open, stan- port plan and routes the call signalling, tells the trans-dards-based network that delivers integrated multime- port plane what traffic to allow, and generates billingdia services to increase revenue, while also reducing information for the use of the network. The connec-network CapEx and OpEx.. As the recent activities in tivity plane comprises routers and switches, both forETSI TISPAN (Telecoms & Internet converged Ser- the backbone and the access network.vices & Protocols for Advanced Networks) has shown, While the IMS is acknowledged to be a main part ofit has become increasingly popular also with wireline the next generation network architecture, it is also nec-service providers and is now considered the de-facto essary to improve the service plane to allow fast andstandard for Fixed-Mobile Convergence (FMC) in easy provisioning of a large set of services.Next-Generation Networks (NGN) [7,8,13 ].The IMS architecture has been designed to clearlyseparate the connectivity, control and service plane.

Instant Presence PoC Open API Customer/Messaging SIP AS Business VolP

Sh

SIP /OS>.+ Mr / XML SGWSIP

,lSIP *

HSS

,,,...'''SUP,,fA ,# ISUPSUPS S

MGW

SI SIPCG w

UE (moble) Software Client UE (fixed) IP Phone IP PBX

Figure 1: IMS Architecture overview

This requires a service platform that reduces the effort the Figure 2 and the server-side distributed platform onof creating and delivering services by several orders of the right. Both the terminal and the server-side systemmagnitude in terms of capital expenditures and time have a layered structure. The SPICE architecture hasrequired compared to traditional approaches. Cur- the following four layers, namely the Capabilities andrently, the most interesting service platform functions Enablers Layer, the Component Service Layer, theinclude: Knowledge Layer, and the Value Added Service (VAS)* identity provisioning allowing 3rdparties and visit- Layer.

ing networks to assert the identity of a user and . . .their subscriptions while keeping the anonymity of 3.1 Capablities and Enablers Layerend-users,

* charging and billing, allowing users to easily pay This layer is responsible for providing the variousfor connectivity, services and good while allowing supportfunctions that are vital for the SPICE platform.the operators to take a small premium from each Support functions play a major part in enabling theservice, serviceposioin (e.g. core functions of the Service Execution Environment

* improved through push (SEE). The support functions are external to the plat-technologies, search engines, or context aware form and used to realize functions such as profile stor-service offering) and service access, age and management, and basic signalling and session

* personalization and adaptation to specific situa- control. This layer provides support for the publishingtions provider thus making mobile and converged of profile and other information to the component ser-services easier to use, vice layer. The component service layer has a corre-

* mediation supporting the creation of service bun- sponding functionality that exposes this information todles. interested components.

The SPICE project aims at enabling this leap in the 3.2 Component Service Layerservice delivery process through several innovationsthat are explained in the following section.

The component service layer provides facilities3. SPICE Architecture Overview for component-based development and deployment.

This layer includes services such as the messageThe SPICE project has a platform-centric archi- router, various managers, controllers, and the resource

tecture approach [2,15]. It targets fixed-mobile con- adapters. Resource adapters are used to integrate leg-vergence and manages heterogeneous access tech- acy components with the SPICE-project architecturenologies and devices. SPICE investigates new or im- components.proved mechanisms regarding the different steps The component model and methodology support cross-within the service life cycle process. The architecture system service deployment and provisioning. Thedeveloped within the SPICE project is based on com- methodology regards the components as a set of mod-ponents, which are discovered, federated, combined, elling artifacts that are constructed using technology-and executed in a distributed environment. The SPICE neutral notations such as UML (Unified Modelingproject platform consists of four different kinds of Language) and XML (Extensible Markup Language).components. The basic components are generic build- The use of technology-neutral notations brings muching blocks that take advantage of the SPICE project needed robustness and consistency into the service lifeplatform features. Resource adapters are special basic cycle, i.e., development, publication, and discovery.components, which act as proxies to components in In order to invoke component services seamlessly,legacy systems. Components that support interfaces component metadata and interface semantics must befrom the knowledge framework are called intelligent developed and published in a heterogeneous environ-components. Both may further be used to create Value ment. Novelty of the methodology is that it leveragesAdded Service (VAS) components and composite best-practice architecture of SOA (Service-OrientedVAS components. The composite components may be Architecture) [16] to support IP-based multimedia ser-created at runtime by using real-time information pro- vices [12] on networking architecture such as IMS. Itvided by various sources and processed by the knowl- allows the various users taking part in service life cy-edge layer components. cle to have a uniform understanding of diverse serviceFigure 2 presents an overview of the SPICE architec- execution platforms [18].ture. The terminal platform is presented on the left of

A number of components are exposed to the outside commender. Any component that adheres to theworld using the exposure and mediator layer. These Knowledge-Management-Framework (KMF) specifi-components can then be used and combined in a multi- cation is part of this layer. The layer is realized as aplatform environment to create composite services. A collection of distributed knowledge sources, sinks, andthird party service execution environment can use the brokers. Sources produce information, which is deliv-publishing capability of the SPICE platform to publish ered to sinks. Information is either delivered directly orand advertise services or components in the SPICE by employing the publishlsubscribe pattern. For exam-system. Several support functions are needed, such as ple, the profile manager is one source of knowledge.the IMS system or parts of it, which are not part of the Enablers on this layer include knowledge brokers andcore SPICE platform. recommendation engines. Brokers are responsible for

mediating and transforming information, and provid-3.3 Knowledge Layer ing interfaces for knowledge discovery. Discovery is

performed either using direct query to a broker or byThe knowledge layer supports the discovery, de- using a publish/subscribe pattern. The learning and

livery, and transformation of information, such as con- prediction algorithms are pluggable and new tech-text and presence variables. This layer introduces sev- niques can be added to the system.eral fundamental building blocks for intelligent com-ponents, e.g., knowledge brokers, reasoner and re-

Service Creation Environment (SCE)

I _3rd Party Service Execution Environment

TerminalPlatform Exposure and Mediation Layer

_ ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _

KnowldgeM layer Brkers,Medaos Reasner

Componet seric laye Component servc layerSCM S clie

Browscr IMS System Third party Various reposioisBasic OS support Legacy systcms componenits incluidingi po6files,1-_~~~~~~~~~~44W144NkM____ II

Figure 2: Overview of the SPICE architecture

3.4 Value Added Service (VAS) Layer services and components of several different stake-holders need to be contacted. Orchestration is needed

The VAS layer facilitates the creation of com- to coordinate the information flow between these enti-pound components and services from the basic SPICE ties. Run-time meta-data and context-based discoverycomponents. A compound component is needed, for of components is used to find suitable components forexample, for personalized ticket booking or for finding composition. The orchestration engine is responsiblenearby restaurants that have events that match the con- for ensuring that the components of a composite com-sumer's interests. These interactions require that the ponent are properly synchronized and the interactions

follow predefined rules. The SPICE orchestration en- (UPM) module which provides the users with an easygine could be seen as a possible realization of the so- interface to define their privacy policies.called 3GPP SCIM (Service Capability Interaction Controlling access to services relies on an authentica-Manager) [22], which performs according to 3GPP the tion credential provided to the user or service by anrole of service interaction management, but which is identity provider. In the heterogeneous environment ofnot defined in detail yet. SPICE, multiple credentials from the IT and telecom-

munications world will be used. The ID-Management3.5 Service Creation and Delivery in SPICE aims to integrate these two worlds, espe-

cially the Liberty Alliance framework with the GenericService Delivery comprises the complete set of creat- Bootstrapping Architecture (GBA) credentials of theing services, testing them, deploying them to the net- telecommunications world by defining mechanisms forwork and terminal side execution environments, and their inter-working [17].then provisioning them to end-users. The Service SPiC pr-ovide e s h a lCreation process will be supported by a set of graphi- S . . f

cal tools. A dedicated Development Studio for profes- the SPICE services to bill users for service access. The

sional developers is being developed around the high- charging and mediation component in SPICE provideslevel service description language SPATEL (SPICE an interface to the billing system of the underlying

A n SfTele- network operator and other entities such as banks andAdvanced Service Description Language for crdiecrloertoscommunication services). SPATEL allows using a credit card operators.Model-Driven Architecture (MDA) approach for trans- 4. SPICE-IMS Interworkingforming a service idea through a platform independentrepresentation to an executable service. A special tool As presented in Section 2, IMS is the accepted ar-will allow end-users to create easily services tailored to chitecture for the Next-Generation Networks. It is

their~~~ ~ ~ ~ ~ ~ ~ ~~h1etr needs.x-Gnrho etok. t1theirneeds. hence essential that an optimal interworking of theSPICE develops a Service Creation Environment SPICE platform with the IMS system shall be(SCE) that supports the creation of new services based achieved. Mainly two different level of integrationon existing components. Re-use of service enablers, between SPICE and IMS were considered as oppor-e.g. for OSS (Operational Support Systems) and BSS tune candidates for the SPICE architecture guidelines:(Billing Support System), will be supported through tight and loose coupling with IMS.service repositories that store semantic description ofthe services thus allowing for easy service composi- 4.1 Tight Couplingtion. The SCE will provide service development tools,as well as emulation of service enablers and testing The rationale of the tightly coupled approach is toenvironments. A special version of the SCE will be make SPICE platform a service platform on top ofprovided to end-users that can create simple services OMA/IMS, very closely following standardizationadapted to their needs. efforts. This approach would result in the following

3.6 Security platform features:* User Identity of SPICE users would be handled

Access to SPICE services is controlled by an Ac- together with the IMS system, so that OMA/IMSservices could be easily used and build into thecess Control and ID-Management framework. Thissevc lafr.HneSIEursaw sae

is a distributed framework inside the SPICE platform IMS, subscribsyand forms a part of the exposure layer through which IMS subscribers.

* Access to the SPICE platform would always re-the services are exposed to the outside world. The quire users to be registered with IMS, besides onlyframework provides a Single Sign On (SSO) feature for using IMS interfaces Ut (XCAP (XML Configura-authorized services to authenticated users and services tion Access Protocol), limited to self-managementwithout the need to re-authenticate at different ser-vices. In case of 3rd party services requesting access to of services) and Gm/ISC (SIP).

* SPICE application servers would be imple-SPICE services, the framework is responsible for en- ppppforcing the Service Level Agreements (SLAs) related to mented as IMS application servers.such requests. The accs control framework is also * OMA/IMS Service Enablers would be the pre-responsible for controlling access to sensitive user fre h1edata. This is handled by the User Privacy Management

4.2 Loose Coupling ensure the compatibility with recent and upcomingIMS versions.

In case of the loosely coupled approach, SPICE * OMA and IMS oriented data models will be re-would be a service platform with some support of used to achieve an optimal integration with theIMS. This approach results in the following platform IMS. These data models should be used on thefeatures: terminal as well as on the application server side* User identity of SPICE users would not rely for defining, modelling and exchanging data.To

ensure interoperability between the above datasolely on the IMS system, although. IMS could be elsSPC provideteway.used for bootstrapping SPICE users' identities.

* Access to the SPICE platform does not require 4.4 IMS Integrationusers to be registered with IMS, and allows accessby any means supported by the service, e.g., The SPICE platform fosters the distribution ofHTTP/WAP/iMode. service logic and data between different platform enti-

* SPICE application servers could utilize a pleth- ties. The following paragraphs focus on the distribu-ora of implementation technologies and interfaces tion aspects regarding the SPICE knowledge layer andincluding, e.g., the ISC interface for an IMS appli- the integration of readily available knowledge fromcation server. that layer into the IMS.

* OMA/IMS Service Enablers would be treated inasimilarwayOM/I

s rierEnabers.woulbei trreand-i The goal of the KMF is to provide an easy-to-use in-asimilarwaya as woth bersytms.pTheir orrespond-e frastructure that standardizes the exchange and the

discovery of knowledge. To have a shared understand-concepts of the SPICE platform through adaptors .gtonguarantee the lPIn withptherelatedr henabers. ing of the meaning of the information that is delivered

to guarantee the link with the related enablers. adecagdb h M,tesucso nwegand exchanged by the KMF, the sources of knowledge4.3 The Selected Approach exchange their information as instances of a shared

ontology. During the specification of the platform-Both solutions described above do not fulfill com- specific knowledge layer interfaces an Internet-based

pletely the requirements of the SPICE project, e.g., approach has been chosen.restricting the applicability of the SPICE platform to In particular, the first realization of the KMF relied onIMS only, or by not supporting the IMS enablers in an the HTTP GET/POST protocol, and SOAP overoptimal way. The selected solution is a compromise HTTP, respectively. The knowledge is semanticallybetween the tight and loose integration and has the described with Mobile Ontology [9] using the Webfollowing features: Ontology language (OWL) [10] as defined by the* Identity: If the user is already an IMS subscriber World Wide Web Consortium (W3C). The underlying

(IMS registered or not IMS registered), SPICE re- data format was RDF [11]. As one of the main func-uses the well defined 3GPP/OMA mechanisms for tions of Mobile ontology is to make the telecommuni-user specific activities (e.g. reuse 3GPP GBA ar- cations world interoperable with the Web (and ITchitecture methods for user authentication). For world), different strategies need to be applied whennon IMS users new Identity mechanism (e.g. en- addressing different ontology/schema languages andhancements to 3GPP/Liberty Alliance) will be de- existing ontologies and schemata for certain types ofveloped in SPICE. knowledge.

* Application Servers based on the SPICE plat- Using the SIP protocol and PIDF as the knowledgeform will mainly behave like IMS application data format allows for an easy integration of knowl-servers. These servers can be accessed by the us- edge that is readily available in existing OMA/IMSers and other application servers via SIP-based service enablers. The context and knowledge gatheredand non-SIP-based (HTTP, XCAP, XML) mecha- by the SPICE platform goes well beyond the conceptsnisms. In case the SPICE AS does not conform to examined for the presence service. Therefore we pro-the current 3GPP IMS specification it has to be vide support for knowledge sources that exchangeensured that the IMS is optimally supported. their information in either "rich" OWL, or PIDF for-

* Service Enablers from OMA/IMS (such as pres- mats and both. Moreover, gateway components pro-ence, messaging, POC) will be accessed by the vide semantic (and transport mechanisms) mappingcapability enabler layer of the SPICE platform functionality between the different source types.(e.g. to build new SPICE services). This reuse will

5. Realizing the SEE 4. The BPEL script stores the request in the Personal-Agenda of the user (implemented by Google Calen-

The SPICE SEE is a distributed runtime environ- dar) and sets a notification callback.ment offering the capabilities to bridge between the 5. At the right time, the personalAgenda calls theIMS world and the three SPICE component layers. To BPEL script triggering the execution of the recom-allow industrial and academic partners cooperate and mendation process. This process requests the user'swork on a common testbed, the project decided to first location and other context, calls the web service in-create its own Mini-IMS based on Open Source com- terface of a yellow page service for relevant restau-ponents. For the next release of the SEE, SPICE de- rants, and computes the list of recommendations.cided to switch to the Open Source IMS core (Open- 6. Recommendations are packed into an IM sent to theIMS) developed by Fraunhofer Fokus2. The Mini-IMS user using the Web service of the Mes-offers standard IMS features like Instant Messaging, sage RA Wrapper.Presence, VoIP calls, conferencing, and chat rooms. 7. The user can then select a restaurant and a new IMWith the OpenIMS, we will include Video calls as is used for requesting a third-party voice call towell. make a table reservation.Using the dispatching facilities of the S-CSCF, IMS 8. The IM is again received by the composed servicerequests are dispatched to the core SPICE platform. A in the BPEL engine which then invokes the third-Resource Adaptor component transforms the SIP re- party call control API for connecting restaurant andquest to SPICE internal requests based on Web Ser- end-user.vices or J2EE RMI calls. SEE uses resource adaptors The described process is implemented in the SPICErunning in the Mobicent JSLEE (Java Service Logic testbed with application servers running at differentExecution Environment) execution container. Applica- partners sites, and external services (like Google Cal-tions can be executed in JSLEE, J2EE, .NET or BPEL endar and Yellow Pages) accessed during service exe-(Business Process Execution Language) execution cution.containers. The major means for communication isbased on Web Services thought technology specific 6. Conclusionscalls (like J2EE RMI) is also possible.The implemented SEE presented in Figure 3 has been The SPICE project designs, develops, and tests anused to verify SPICE concepts such as the proposed innovative mobile service creation and execution envi-coupling of the IMS and SPICE platform, the support ronment for networks beyond 3G. The emphasis is onfor dynamic deployment of new SPICE components supporting multiple execution platforms, hiding theinto application containers, the use of knowledge in- underlying complexities and enabling new, innovativeformation in SPICE applications, and the fast and ef- services to be rapidly developed.fective re-use of (IMS based) network enablers such as The presented architecture consists of four well-Instant Messaging, Presence, VoIP and Third-Party defined layers, and is based on components, which areCall Control. discovered, federated, combined and executed in aThe following walk-through explains details of the distributed environment. The knowledge layer pro-realization. The scenario is called eTourism, in which a vides a rich set of mechanisms for context gathering,user asks for interesting nearby restaurants for the eve- knowledge processing, and making this knowledgening: available to easily create context-aware services. The

main innovations of the architecture include the fol-1. The userasks realgood estaurathug a Im lowing: converged communications, knowledge-based

ThIs interacgtion istandare d eItherMthroughac ustom.operation, integrated security features, and focus onGUI or using the standard IM client.2. A SIP request is forwarded to a SIP application platform federation.

running JSLEE Mobicent using the IMS trigger ar- Acknowledgmentschitecture.

3. A SPICE basic component (Message RA Wrapper) This work has been performed in the frameworkuses the Mobicent IMS resource adaptor to create a of the IST project IST-2005-027617 SPICE, which isweb service call to the composed service running in partly funded by the European Union. We would likethe BPEL execution engine. to thank all SPICE project partners and people for con-

tributing to this paper. We would like to especially2 Available at http://www.opcnimscorc.org/ thank S. Arbanowski (Fraunhofer Fokus), H. Demeter

(Nokia NRC), L. W. Goix (Telecom Italia), C. Pre- [9] Zhdanova, A.V., Boussard, M., Cesar, P., Clavier, E.,hofer (Nokia NRC), H. Rajasekaran (Siemens Net- Gessler, S., Hesselman, C., Kernchen, R., Le Berre, O.,works, Munich), C. Rack (Fraunhofer Fokus), and N. Marengo, M., Melpignano, D., Nani, R., Patrini, L.,Snoeck (Telematica Instituut). Strohbach, M., Villalonga, C., Vitale, A. Ontology

Definition for the DCS and DCS Resource Description,User Rules. EU IST SPICE IP deliverable (D3.1), 2006.

[10] W3C: Web Ontology Language (OWL) [Online], 2004,Available: http://www.w3.org/2004/OWL/

OPaySA, [11] W3C: Resource Description Framework (RDF)<SEEHHHH'Cnae>Hlll V VebSerPbfiyeX, [Online], 2004, Available: http:H/www.w3.org/RDF/

i[12] Kampmann M., Vorwerk M., Kleis M., Schmid S., Her-born S., Agulero R., Choque J. Multimedia Delivery

ResourceAdapter Framework for Ambient Networks WWRF# 15, Wire-\SIP:ISC lc " -Qless World Research Forum Meeting 15, Paris, France.

UE1 n \ 1< k X [13] Akkawi A., Schaller S., Wellnitz 0. and Wolf L. AH 7 TP WEB Servi ewMobile Gaming Platform for the IMS, in Proceedings of

3GPhonre\ _ s>t<Psence> <C ferencing> 3rd International Workshop on Network and System@-<k-CSCF> \ \l/P Support for Games (Netgames 2004), Portland, USA,<I-CSCF> s lP\\ / /<HSS> August 2004.

RADIUS i _ I - r a[14] Mohomed I., Cai J. C., Chavoshi S., Lara E. Context-SIPProxy aware interactive content adaptation. 42-55. Proceed-D/ SIPProxy SIP SeeeR ings of the First International Conference on Mobile

<5 . MGCF :z° XSystems, Applications, and Services (MobiSys 2003),|) U.E<ih/ISDAf/GSM <Med iaGW> l San Francisco, CA, USA. USENIX 2003.

-..... PBXAsterisk [15] Tarkoma, S., Prehofer, C., Zhdanova, A.V., Moessner,SIPPhoneo<vK., Kovacs, E. SPICE: Evolving IMS to Next Genera-tion Service Platforms. In the Proceedings of 3rd IEEE

Figure 3: Service Execution Environment (SEE) SAINT 2007 Workshop on Next Generation ServicePlatforms for Future Mobile Systems (SPMS 2007), Hi-roshima, JAPAN, January 15-19, 2007.

References [16] Ferguson D. F. and Stockton M. L. Service-orientedarchitecture: Programming model and product architec-

[1] SPICE deliverable D1.2: Scenarios for the representa- ture, IBM Systems Journal, Volume 44, Number 4,tive next generation communication and information 2005.services. EU IST SPICE IP deliverable (D1.2), June [17] 3GPP TS 33.220. Generic Authentication Architecture2006. (GAA); Generic bootstrapping architecture, Release-6

[2] Advances beyond 3G service delivery environment: the and 7.SPICE service platform design principles, C. Cordier et [18] Bhushan B., Tarlano A., Fischer G., Hendriks J. Devel-al., Wireless World Research Forum, May 2006. opment and Publication of Generic Middleware Com-

[3] Tafazolli R. (Editor). Technologies for the Wireless ponents for the Next Generation Mobile Service Plat-Future: Wireless World Research Forum (WWRF), form. In the Proceedings of 3rd IEEE SAINT 2007Volume 2, 2006, Wiley. Workshop on Next Generation Service Platforms for

[4] Schulzrinne, H. and Wedlund, E., 2000. Application- Future Mobile Systems (SPMS 2007), Hiroshima,layer mobility using SIP. Mobile Computing and Com- JAPAN, January 15-19, 2007.munications Review, 1(2). [19] 3GPP TS 23.228. Technical Specification Group Ser-

[5] Open Mobile Alliance. Homepage at vices and System Aspects. IP Multimedia Subsystemhttp://www.openmobilealliance.org/ (IMS). Stage 2, (Release 7).

[6] Schullke A., Abbadessa D., Winkler W. Service Deliv- [20] 3GPP TS 23.198. Technical Specification Group Coreery Platform: Critical Enabler to Service Providers' New Network and Terminals. Open Service Access (OSA).Revenue Streams. World Telecommunications Congress Stage 2, (Release 7).2006. [21] The Parlay Group, Homepage at http://www.parlay.org/

[7] Cuevas A., Moreno J. I., Vidales P., Einsiedler H. The [22] 3GPP TS 23.002 Technical Specification Group Ser-IMS Service Platform: A Solution for Next Generation vices and Systems Aspects. Network architecture, (Re-Network Operators to Be More Than Bit Pipes. IEEE lease 7).Communications Magazine, August 2006.

[8] Camarillo G. and GarcIa-MartIn M.-A. The 3G IP Mul-timedia Subsystem (IMS): Merging the Internet and theCellular Worlds. Wiley, 2004.