Service Delivery within an IMS Environment

Drivers for IP Multimedia Applications

Increased competition and price pressure is directlyimpacting the revenue streams of traditional telecom ser-vice providers. The roll-out of wireline and wirelessbroadband access networks has lowered the entry barri-er for VoIP service providers, allowing them to offerlower-priced telephony services to consumer and enter-prise customers. As the average revenue per user for digi-tal telephony declines (on both fixed and mobilenetworks), many service providers are looking to the newwave of IP-based multi-media communication applica-tions to replace that lost revenue. This has caused astrong shift in focus within the communication industryfrom digital telephony to more media rich applications.

This shift is being driven by many factors. Mobilephones, portable PCs and other personal media devicesall now include multimedia capabilities and support mediacapture and playback features as standard. Wireline and

Abstract: The IP Multimedia Subsystem (IMS) stan-dard is being widely adopted by both wireline and wire-less service providers to support the next wave ofmultimedia communication applications. As currentlydefined, that IMS standard proposes a detailed architec-ture for the transport and control layers of the next-gen-eration telecommunication networks, but leaves manyquestions unanswered on how the application layershould be structured. A more structured approach toservice delivery will be required in order to deliver newmulti-media applications in an efficient and cost-effec-tive way. An approach based on Service Delivery Plat-form (SDP) proposes a layered service architecture,with a strong emphasis on re-use of common serviceenablers and on open APIs. This paper describes workbeing undertaken within HP’s IMS Experience Center tovalidate a horizontal service delivery architecture fornext-generation IP multi-media applications.

© ARTVILLE & EYEWIRE

John O’Connell, Hewlett-Packard

Digital Object Identifier 10.1109/MVT.2007.898099

12 ||| 1556-6072/07/$25.00©2007IEEE IEEE VEHICULAR TECHNOLOGY MAGAZINE | MARCH 2007

wireless broadband access networks have become ubiqui-tous, whether based on DSL, WiFi or 2.5G/3G. Also, asmedia becomes digital, it becomes much easier and morenatural to inject content, whether private content or pub-lic licensed content, into communication sessions.

User expectations are also changing. Our experienceswith the internet are fuelling demand for new ways to com-municate, and to share our thoughts and feelings (in theform of photos, video clips, voice messages, etc) in real-timewith friends and family. The success of services such as SMS(on mobile phones) and Instant Messaging (on the inter-net)—and in particular, the instantaneous nature of theseservices has redefined user’s expectations of being able toinstantly share “stuff”, in real-time, across multiple devices,via any network, and perhaps most importantly, at a reason-able price. Finally, users also expect services to work seam-lessly across multiple devices. Content that is generated ona mobile phone can be downloaded and edited on a PC,before being sent electronically to family members who maychoose to play it back on a TV or personal video device.

All of these trends are expected to drive demand for awide range of new applications, such as:■ Content sharing applications, where various types of

media objects can be shared in real-time across multi-ple devices

■ Personalised interactive TV services, extending theusers’ TV experience with value-added services

■ Rich call services, which enhance the traditional tele-phone call with multimedia features

■ Instant group communication services which enablemultiple forms of interaction within a group or com-munity context.In anticipation of this shift, many service providers are

deploying SIP-based infrastructure, in compliance with the3GPP’s IP Multimedia Subsystem(IMS) [1] standard. IMS bringsmany potential benefits for serviceproviders, as it defines an accessnetwork agnostic architecture fordelivering real-time multimediaservices (including voice services)over an IP-based network, withbuilt in support for inter-network-ing, roaming, access control andonline/offline charging. IMS is alsoexpected to leverage the latest ITand IP technology, and this isexpected to lead to lower cost ofownership, compared to tradition-al telecom equipment which hasoften been based on telecom-specific technology.

Despite these many promisesand despite the hype surround-ing IMS today, the technology

will ultimately be judged on its ability to deliver new real-time multimedia applications in a cost effective way. Thiscost aspect is important because alternative architec-tures, for example based on peer-to-peer approaches, arealso being proposed and adopted by players within theindustry. This raises the question of how to structure theIMS service layer so that IP multimedia applications canbe created rapidly and can be delivered efficiently andeconomically.

A Horizontal Service Delivery Architecture

Delivering a wide range of multi-media applications in acost-effective way will require a more structuredapproach to service delivery, where service resourcesand subscriber data are shared across applications.Given the additional complexity that these multimediaapplications will introduce, the service architecture thathas been adopted for today’s 2G/TDM applications is notsuitable for next-generation services. The trade-off thatwas made in 2G/TDM networks, in favour of performanceand reliability at the expense of openness and ease ofoperation, is no longer appropriate. Increased competi-tion and the need to offer innovative services will requireservice providers to place greater emphasis on open net-works (e.g., in support of 3rd-party services) and on flexi-bility (e.g., in response to user demand for greatercontrol over service offerings). This has led many withinthe industry to propose a horizontal service deliveryarchitecture for IMS, with a service enablement layer sit-ting between the control layer and the applications.

Such a layered approach is central to the concepts andprinciples of a Service Delivery Platform (SDP). As shownin Figure 1, such an architecture addresses the twin goalsof sharing common functions and resources across

FIGURE 1 Horizontal Service Delivery Architecture for IMS.

MARCH 2007 | IEEE VEHICULAR TECHNOLOGY MAGAZINE ||| 13

multiple applications and of adopting common frame-works for provisioning, management, user access, etc, toavoid unnecessary duplication of functionality. By adopt-ing common functions for service delivery and commonframeworks for service management and provisioning, theSDP approach aims to dramatically reduce the incremen-tal cost of introducing a new service in to the network.

Within this layered horizontal architecture, the role ofthe service enablement layer is to host a set of applica-tion-independent building blocks that offer generic func-tionality to support a diverse range of multimediaapplications. Examples of IMS service enablers includepresence server, group contact server, media resourcefunction, messaging gateways, user profile server, etc. Theideal service enabler is both multi-network and multi-device, acting as a point of convergence and consolidationin a heterogeneous environment, while offering network-agnostic and device-agnostic APIs to application develop-ers. These service enablers can be deployed once, andthen re-used across multiple applications.

A complete service delivery environment also needsto address the operational, provisioning and manage-ment aspects of services. In order to avoid unnecessaryredundancy and to reduce OPEX, this implies offeringcommon frameworks for provisioning and management,so that a common look-and-feel is provided across arange of services.

Finally, this need for a common look-and-feel must alsoapply to the end user’s view of the services. Many of thenew multimedia applications are expected to be complexin nature, but must be easy-to-use in order to offer anattractive user experience. An intuitive and integrated userinterface can hide the underlying complexity of the ser-vices, and can help to present new services and new ser-vice features through a familiar interface. This applies bothto the interface that is used to access the service from theuser’s end device and to any interface that is offered to theuser to provision, configure and personalise that service.

Combining IMS and SDP

Both IMS and SDP are being positioned within the industryas key technologies in the migration to NGN, with bothclaiming to address convergence and service innovation.By convergence, we mean delivering the same service overmultiple access networks, with the goal that the service

can be deployed once, and made accessible from manydevices. By service innovation, we mean enabling the rapidcreation and deployment of new applications that delivernew user experiences and that typically are expected todeliver new multimedia and multimodal features. However,despite claiming to deliver the same benefits, it is impor-tant to see IMS and SDP as being complementary, wherethe combination of IMS and SDP can bring many benefits.

On one hand, IMS offers a framework for IP communi-cation applications, across multiple networks anddevices, with a well-defined standard control layer whichensures interoperability and roaming (important formobile and nomadic users), end-to-end session manage-ment and a coherent framework for service charging. IMSalso promises a clean separation of the application layerfrom the core network.

In parallel, SDP can bring a lot of value at the servicelayer, by offering a structured framework for managingthe delivery of services, and by doing so in a cost-effective way with a strong emphasis on re-use of com-mon functions across multiple applications. Many of theSDPs in the market also address the issue of how to openup networks to 3rd-party applications, and this more flex-ible approach can be an enabler for service innovation, asmany more players, such as ASPs and 3rd-party contentproviders, can create and deploy multimedia applica-tions. The use of standard IT development tools, basedon familiar java or XML programming methodologies, isalso an important aspect of SDP, and can help to reducethe complexity of creating new applications.

Experimenting with IMS Service Delivery

In order to understand the challenges involved in creat-ing and delivering IMS applications and in order to vali-date this layered approach to IMS service delivery, wehave taken a practical approach by implementing a set ofIP multimedia applications within a functionally completeIMS environment. HP’s OpenCall Experience Center [3],located in Grenoble, has been established to validate thishorizontal approach to service delivery for IMS. The cen-ter includes a functionality-rich IMS network environ-ment, integrating both HP and partner technology. Thecenter currently hosts an initial set of IMS-compliant ser-vice enablers, end devices, and IMS applications, asshown in Figure 2.

This environment is primarily being used to explore thetechnical issues and implementation choices involved indeveloping and deploying end-to-end IMS solutions, includ-ing both client-side and server-side elements. Elements ofthe Experience Center include HSS, CSCF simulator, MRF,presence server, XDMS/GLMS, various AS and SDP.

Focus on Instant Group Communication

For this architecture validation work, an example applica-tion was chosen. The chosen application is a group-based

14 ||| IEEE VEHICULAR TECHNOLOGY MAGAZINE | MARCH 2007

IMS WAS ORIGINALLY DEFINED BY 3GPP TOSUPPORT REAL-TIME MULTIMEDIA APPLICATIONSWITHIN 3G MOBILE. THE BROADBAND AND CABLEINDUSTRIES HAVE ALSO NOW ADOPTED THESAME CONCEPTS TO SUPPORT THE DELIVERYOF REAL-TIME MULTIMEDIA APPLICATIONS INBROADBAND AND CABLE NETWORKS.

media sharing application that combines group contactand presence information, media sharing and real-timevoice communication within a single session. This appli-cation belongs to the category of “instant group commu-nication” applications, which are primarily focused ondelivering instant (i.e., real-time) communication-oriented(i.e., person-to-person) behaviour within a group oronline community.

These applications aim to deliver new multimediaexperiences within a group context, where a group couldbe a family, a group of friends, social group, work group,or some other form of ad-hoc group that is linked by acommon interest. Instant group communication applica-tions build on the success of instant messaging and buddylists which are now widely used in the internet, and theyextend these concepts with new service features to alsooffer a more media rich and multi-modal experience.

Two important characteristics of this category ofapplications are the ability to spawn multiple communica-tion services from a contact list or other shared content,and the ability to combine multiple interaction modes,such as voice, video, messaging, content sharing, etcwithin a single user session.

Given the nature of the applications, it is also veryimportant to present the different service features fromwithin an integrated user interface. A user of the serviceshould be able to browse shared contact information andshared content, to trigger new interaction modes and toinject content into established communication sessions,within a single user sessionand all through a consis-tent user interface thatoffers a common look-and-feel across the differentaspects of the application.

In implementing the cho-sen application within theHP OpenCall ExperienceCenter, two different ser-vice architecture modelshave been adopted and val-idated. The first implemen-tation approach deploysthe application as a stand-alone element within theIMS network, in compliancewith the Application Server(AS) function, as defined bythe IMS standard. In thisapproach, the primaryinterface between theapplication logic and theother elements of thesolution is a SIP-basedinterface, although other IP-

based and HTTP-based protocols are also used for someparts of the solution. In contrast, the second implementa-tion approach has adopted a web services approach,where the application logic is modeled as a “service chain”,invoking a sequence of network functions and network ser-vices via XML-based web service interfaces.

By choosing two different implementation approaches,this work not only validates both approaches, but alsohelps to identify the benefits and challenges that are spe-cific to each approach.

Both implementation approaches, and the lessonslearned, are described in the following sections.

IMS Application Server Model

In the first target service implementation architecture,the media sharing application has been implementedas a standalone element within the IMS environment.In this approach, the media sharing application acts asa centralised session controller, with responsibility forco-ordinating session establishment, media mixing andmulticasting, addition and removal of interactionmodes (e.g., adding/removing voice channels), andsession termination. It is deployed as an IMS Applica-tion Server, and it interacts with the other elements ofthe IMS environment using standard protocol inter-faces such as SIP, Diameter and HTTP, in order to ful-fill these responsibilities.

The core logic of the media sharing application exe-cutes within a java execution environment. It interacts

FIGURE 2 Components of the HP OpenCall Experience Center.

MARCH 2007 | IEEE VEHICULAR TECHNOLOGY MAGAZINE ||| 15

with the other components of the Experience Centerusing the protocol interfaces shown in Figure 3.

In a typical use case scenario, the initiator of a sessionwill initially interact directly with the application serverin order to configure and establish the group session e.g.,choosing who should participate in the session, and withwhat rights. The Media Sharing application uses bothGLMS/XDMS [4] and presence servers to present the ses-sion initiator with up-to-date information on which groupmembers are available to participate.

In a messaging and content sharing use case, the ses-sion initiator selects the participants, and sends a SIPmessage with the list of invited participants to the appli-cation server. This implementation uses SIP to establishan MSRP-based messaging session, where all messagesare forwarded by the application server to the sessionparticipants. The media server is invoked, when required,to stream audio or video content to the participants’devices (e.g., when the audio or video content is too largeto be downloaded to the end device).

In an instant audio/video conferencing use case, thesession initiator again selects the session participants,and in this case, sends an XCAP CPCP request to theapplication server to launch an instant conference. Theapplication server interacts with the media server toprompt each invitee to join the conference, and oncethe session is established, the media server is respon-sible for mixing the voice and video streams and for

delivering any shared media content in the correct for-mat to all participants.

Other interfaces that have been included in this imple-mentation include:■ XML/http interface between the Media Sharing server

and the Media Server for real-time control of the mediastreams.

■ Sh interface with the HSS, for storing and retrievinguser profile and user preference information related tothis service.

■ Ro/Rf interface with charging engine, for online/offlinecharging.

■ MSRP [2] interface, implemented directly by the MediaSharing application, for messaging-based content shar-ing between session participants.

■ Service management interfaces, based on SNMP andJMX.

Results and Lessons Learned

This work successfully demonstrated the implementationof an end-to-end instant group communication applica-tion in compliance with the 3GPP IMS specifications. Thechosen implementation architecture conforms with theobjectives of a horizontal service delivery architecture(as outlined earlier) in that the implementation relies onapplication-independent service enablers (GLMS/XDMS,presence server, media server, client software, chargingfunction, etc.) to fulfill many of the basic features of theapplication. In effect, the application itself acts as a “ses-sion orchestrator”, invoking these basic service enablersas appropriate (in response to user requests, network-generated requests, and other external events), to deliverthe required end-user experience.

It is interesting to note that although the architecturehas been presented here as being application server cen-tric, client-based software also played an important role inthe implementation. Indeed, much of the development andtesting effort was focused on the device side. Applicationlogic was required on the client to deliver the requiredintegrated user interface, and was also required to man-age local content. A group-aware application integrationframework was implemented for the client devices as ageneric plug’n play layer for invoking various networkapplications from within a single user session. While themedia sharing application described here was implement-ed as a single application, it is expected that multiple suchapplications, offering different sets of capabilities, will bedeployed in the emerging IMS networks. As each newapplication is deployed within the network environment, acorresponding client application will need to be deployedon the user devices. A generic plug’n play framework onthe client can help to reduce the complexity associatedwith the deployment of client-based application logic.

This project highlighted a number of areas where thereis a lack of industry-wide standards today, and where, as aFIGURE 3 IMS-compliant Application Architecture.

16 ||| IEEE VEHICULAR TECHNOLOGY MAGAZINE | MARCH 2007

TWO DIFFERENT SERVICE ARCHITECTURE MODELSHAVE BEEN ADOPTED AND VALIDATED: ONEDEPLOYING THE APPLICATION AS A STAND-ALONEELEMENT, AND THE OTHER TAKING A WEB-SERVICES APPROACH.

MARCH 2007 | IEEE VEHICULAR TECHNOLOGY MAGAZINE ||| 17

result, pre-standard implementations were developed inthis project. Some areas are highlighted here.

A media server control and media resource manage-ment framework is required, to complement and extendthe current specifications of the Media Resource Function(MRF). The evolution from a voice-centric to video-cen-tric world will change how media resources are usedwithin the network, and this needs to be taken into con-sideration in the ongoing AS—MRF standardisation work.An XML approach, based on VoiceXML (with video exten-sions) and CCXML technology, was used in this imple-mentation, to allow direct control of the media server bythe centralised application logic.

The project also highlighted the need for a network-wide subscriber data management infrastructure, whereboth static user data (e.g., profile and preference informa-tion) and dynamic user data (e.g., presence and locationinformation) can be accessed easily and efficiently. Sucha framework should expose a common user profile datamodel and an abstract data access API both to provision-ing applications and to network applications, ensuring aclear separation of application logic from the underlyingdata management architecture.

A similar challenge exists in terms of charging APIs,because of the multiple billing systems and billing modelsthat need to co-exist. This implementation adopted a Par-lay-like charging API, with support for group billing mod-els, as an abstract API between the application logic andthe protocol charging interfaces.

Service Chaining Model

As an alternative to the service implementation architec-ture described above, we have also developed thisinstant group communication scenario using a ServiceChaining architecture based on web services technology.In this second approach, the set of network functions areexposed as web services and the application logic isimplemented as a sequence of web service invocations.

The concept of a Service Delivery Platform—a horizon-tal service delivery architecture based on web servicestechnology and Service Oriented Architecture (SOA)concepts—is well understood within the industry today.In compliance with the OMA Open Service Environment(OSE) [5], HP’s Service Delivery Platform [6] exposes net-work level functions as web services, and provides policymanagement and policy enforcement functions to controlaccess by 3rd-party applications to these network func-tions. Service Chaining extends the SDP concept by pro-viding an environment to facilitate the rapid developmentof value-add applications that are structured as asequence of web service invocations. The Service Chain-ing environment includes service creation tools to specifyand validate the application logic (i.e., to define and testthe sequence of web service invocations, prior to deploy-ment), as well as a service chaining server that manages

the execution of the application logic; that is, it managesthe execution of a “service chain”.

A complete service chaining architecture mustaddress multiple requirements:■ It must provide a framework to combine multiple indi-

vidual network services to deliver a richer, multi-modal user experience

■ It must enable the seamless transition from one net-work service to another, maintaining both user ses-sions and session information

■ It must work across multiple devices and multiplenetworks

■ It must provide an integrated user interface, support-ing sequential & parallel invocation of services withina single user session

■ It should use web technology to allow easy customisa-tion of the service chaining logicIn the context of instant group communication ser-

vices, a service chain should enable, for example, a real-time discussion between friends to be transferredseamlessly from an instant messaging session to a voicesession without having to tear down and re-establishthe communication sessions. Similarly, as shown in Fig-ure 4, a service chain can invoke contact list and pres-ence/location information initially, before invoking aninstant messaging service, an audio/video conferencingservice, or both.

In this service chaining model, the decision to switchfrom one service to another (that is, to transition to thenext service in the sequence) can be triggered by user

FIGURE 4 Service Chaining Scenario.

IN THE SIMPLEST MODEL, SERVICE CHAININGINVOKES SERVICE INSTANCES IN SEQUENTIALORDER, TRANSFERRING SESSION CONTROL ANDSESSION STATE INFORMATION FROM THE CURRENTSERVICE INSTANCE TO THE NEXT ONE IN THE CHAIN.

requests, by network events, or by other externalevents. Analogous to the first implementation architec-ture described above, in this model the service chainapplication logic acts as the session orchestrator,invoking the appropriate web service in response toexternal requests.

Service Chaining Architecture

As shown in Figure 5, the implementation of the ser-vice chaining architecture relies on three key technolo-gy components of hosted within the Service DeliveryPlatform:1. The Service Registry which holds information on the

underlying network functions that are available, andthat can be invoked via web service interfaces

2. The Context Repository, which holds context informa-tion for a given user or group session, so that this con-text information can be maintained for the duration ofthe service chain.

3. The Service Controller which executes the servicechaining application logic that invokes network func-tions (via their web services interface) in response touser requests and other events. As each web service in the chain corresponds to the

invocation of an independent network function, one ofthe main challenges for the service chaining architec-ture is how to ensure a seamless transition from oneweb service to the next. To achieve this, network ses-sion information, session state information, user infor-mation, and other contextual information is maintainedin the Context Repository independently of each givenweb service invocation. For example, session-specificcontact information that is extracted from the buddy list

function (GLMS) can be stored in the Context Reposito-ry and then delivered as input to other network func-tions as they are invoked by the Service Controller inresponse to user requests. That is, once the user haschosen the list of friends with whom he/she wants tocommunicate, that subset is stored in the ContextRepository. When a user requests the messaging or con-ferencing functions, the service chaining applicationretrieves that context information (in this case thebuddy list) and passes the information on to therequested services. Other session state information canalso be shared in this way between the elements of theservice chain.

Results and Lessons Learned

Note that the use of a Service Chaining implementationmodel is not restricted to IMS networks or to instantgroup communication applications. Network functionsthat reside in existing TDM, 2G and VoIP networks canalso be exposed as web services within an SDP environ-ment, and as a result, can be invoked from within servicechaining applications. In this way, the service chainingarchitecture can act as an enabler for the convergence ofTDM and IP networks, by facilitating the development ofend-user services that span multiple networks and thatbundle network services from different sub-networks. Forservice providers, this allows them to re-use their so-called legacy network functions to deliver value-addedapplications, even when those network functions havebeen implemented as vertical silos or have only beendeployed within legacy networks.

The core application logic, as specified by the servicechain code, plays an important role in managing the

user interface of the service. That is, all user interac-tions are processed by the service chaining logic,which then takes the appropriate action, such asinvoking a network function via its web service inter-face, or transitioning to the next web service in theservice chain. In this way, the service chaining appli-cation can take responsibility for the user experi-ence, and can offer the same user experience acrossdifferent device types. As the range of handsetsgrows more diverse, and with no global standard inplace to ease the burden that service providers faceeach time they seek to deploy a new service, this ser-vice chaining approach can remove some of the com-plexity by offering a clear separation of the userinterface aspects from the network functions that areused to deliver end-user services.

This service chaining approach offers great flexi-bility, allowing easy customization of the applica-tion logic on a per-user, per business customer orper-session basis. The service chaining logic isimplemented as an XML script, and as such, stan-dard IT tools and limited telecom knowledge areFIGURE 5 Service Chaining Architecture.

18 ||| IEEE VEHICULAR TECHNOLOGY MAGAZINE | MARCH 2007

MARCH 2007 | IEEE VEHICULAR TECHNOLOGY MAGAZINE ||| 19

required to modify or customize the script. In addition,by using an XML-based approach, the Service Con-troller can download and execute user-specific or oper-ator-specific scripts on a per-user or per-session basis,which is an important factor if a more open servicedelivery environment is being considered (e.g., wheresome of the application logic is hosted by 3rd-partyASPs or enterprise customers).

Conclusions

In this paper, we have described two different servicearchitectures that have been used within HP’s IMS Experi-ence Center to implement an instant group communica-tion application. The first approach is closely alignedwith the 3GPP IMS architecture, where the core applica-tion logic was deployed as an application server functionwithin the IMS network. In contrast, the second approachis more aligned with the OMA Open Service Environment(OSE), where network functions are exposed as web ser-vices and where the core application logic resides withina web environment.

Through this work, we can conclude that bothapproaches represent valid approaches to service deliv-ery within an IMS environment. Indeed, while there aremany differences between the two approaches, the twoapproaches also have much in common. ■ Both approaches deliver a multi-modal and multi-

media experience, as per the original user scenariodescription, and both approaches have been success-fully implemented.

■ Both implementations rely on a horizontal servicedelivery approach, where the core application logicacts as a “session orchestrator”, coordinating theactions of application-independent service enablers.

■ In both cases, application development was achievedusing IT-standard development tools (in one case,using java development tools; in the other case, usinga web services environment).

■ Both projects have highlighted the importance of userinterface aspects, and the importance of offering aseamless user experience across multiple services,multiple devices and multiple networks.At the same time, as highlighted previously, each

approach also brings its own unique set of benefits andchallenges. The choice of which implementation modelto adopt for a given service will depend on many fac-tors, including the levels of flexibility, openness and per-formance that are required, the capabilities of the targetend devices, and the functionality that is exposed by thenetwork service enablers on their protocol and web ser-vice interfaces.

The choice of implementation model will often dependon the business model being adopted for a given service.The Application Server approach is likely to be used forapplications that are deployed within the network service

layer, while an approach based on the Service Chainingmodel is more likely to appeal to 3rd-party ApplicationService Providers (ASPs) who host applications outsideof the network domain and who may wish to combinenetwork service enablers with service enablers comingfrom other domains.

For developers and vendors of service enablers, thechallenge will be to ensure that the same functionality ismade available on both the protocol interface and webservice interface, so that each service enabler can beused with both models. As such, the service enablementelements that populate a service delivery environmentshould not impose a specific service implementationmodel, but should be flexible enough to be used withinmultiple such models.

In conclusion, a layered horizontal approach to ser-vice delivery, within an IMS environment, can greatlyhelp to reduce the cost of deploying and delivering newIP multimedia services, by enabling the re-use of com-mon service enabler elements across multiple services.However, the adoption of such an architecture mustalso allow multiple service implementation models toco-exist. Through the IMS environment within the HPOpenCall Experience Center, HP is taking a hands-onapproach to validate different IMS service implementa-tion models and to understand the impact of these mod-els on the architecture and the elements of the IMSservice delivery environment.

Acknowledgements

Thanks to my colleagues at Hewlett-Packard, and in partic-ular to Mark Gullett, Olivier Bertin, Paul Burke, DavidIsaacson and Sven Krause for their help and input on thispaper.

Author Information

John O’Connell is based in Grenoble, France where heworks for Hewlett-Packard’s Software business, as chiefarchitect for IMS within the OpenCall CTO Office. TheOpenCall group is responsible for HP’s telecom signaling,media, service and mobile management products. Johnjoined Hewlett-Packard in 1986. He has been working inthe network services area for over 10 years, initially in theIN domain, and more recently, in VoIP and IMS domains.During that time, he has been an active member of indus-try groups such as IN Forum and VASA Forum.

References1. IP Multimedia Subsystem (IMS), 3G Partnership Program (3GPP),

http://www.3gpp.org/.2. IETF Internet Draft Message Session Relay Protocol (MSRP), http://www.

ietf.org/internet-drafts/draft-ietf-simple-message- sessions-19.txt.3. HP OpenCall Experience Center, www.hp.com/go/ims/.4. OMA Group List Management Server (GLMS)/XML Document Management

Server (XDMS), Open Mobile Alliance, http://www.openmobilealliance.org/.5. OMA Service Environment (OSE), Open Mobile Alliance, OMA-Service_

Environment-V1_0-20040907-A, http://www.openmobilealliance.org/.6. HP Service Delivery Platform, http://www.hp.com/go/sdp/ .