a case study on ivr applications' provisioning as cloud computing services

33IEEE Network • January/February 2014 0890-8044/14/$25.00 © 2014 IEEE

nteractive Voice Response (IVR) is a telephony technolo-gy that allows interactions with a wide range of automatedinformation systems via a telephone keypad or voice com-mands. Its key function is to provide self-service voice

information to assist users [1]. Automated attendant and auto-mated survey are two examples of IVR applications. The auto-mated attendant application replaces live operators, transferringcallers to the appropriate extensions. In the automated surveyapplication, a questionnaire is played by the IVR over thephone and respondents answer by pressing the appropriate keyson their phone keypad or by voicing their responses.

IVR applications rely on substrates (i.e. basic buildingblocks that represent resources) such as key detector, voicerecorder and dialog manager. Improved efficiency in resourceusage could be achieved by enabling different IVR applica-tions to share the same substrates. A potential technology thatcould be used to enable this sharing is virtualization. Virtual-ization is a broad computing concept that refers to theabstraction of computer resources and even networkresources, thereby enabling efficiency through the sharing ofthese resources [2]. Nodes and links are examples of sharedsubstrates in network virtualization.

Virtualization is a key technology of cloud computing. Cloudcomputing enables a “computing-as-a-service” model in whichcomputing resources residing in the cloud infrastructure aremade available as a utility service – an illusion of the availabilityof as much resources as needed [3]. This illusion is made possi-ble by the resource sharing enabled by virtualization.

Cloud computing is a promising multi-facet paradigm withmany inherent advantages, such as the easy introduction ofnew applications, resource efficiency, and scalability. There isnot yet a standard technical definition. However, a consensusis emerging around the most critical facets it encompasses:Infrastructure as a Service (IaaS) with virtualization as the keytechnology, Platform as a Service (PaaS), and Software as aService (SaaS) [4]. The reader can consult a recently pub-lished feature topic of IEEE Communications Magazine [5]for more tutorial-level information on cloud computing.

This article proposes a case study on IVR applications’ pro-visioning as cloud computing services, with a focus on the IaaSand PaaS facets. A few typical IVR applications are developedand managed to illustrate the SaaS facet. The following sectionintroduces the design goals and the related work. We presentthe proposed architecture in the third section. The implemen-tation is discussed in the fourth section. Our conclusions andfuture work are presented in the last section.

Design Goals and Related WorkDesign GoalsFigure 1 depicts our overall vision of IVR applications inclouds. The bottom layer shows a simplified IVR IaaS layerwith the following substrates: announcement player, voicerecorder, key detector, extension detector and call transfer. Inthe top layer, we have a simplified SaaS layer with applicationssuch as automated attendant, automated meter reader, auto-mated survey, and IVR banking, which all share substrates andare offered as services to end-users and other applications.

In Fig. 1, for instance, automated attendant and IVR bank-ing are offered to end-users while the automated survey isoffered to another application (clinical trials). The middle

I

AbstractInteractive Voice Response (IVR) applications (e.g. automated attendant, automatedsurvey) have become ubiquitous. However, very few, if any, IVR applications areprovisioned today as cloud computing services despite all the potential benefits.Cloud computing is an emerging multi-faceted paradigm, whose main facets areInfrastructure as a Service-IaaS, Platform as a Service-PaaS, and Software as a Ser-vice-SaaS. This paper proposes a case study on IVR applications’ provisioning ascloud computing services. It identifies the IVR substrates (e.g. key detector, voicerecorder and dialog manager) on which the IVR applications rely and proposes atthe IaaS level an IVR substrate virtualization infrastructure. Substrates’ virtualizationenables a more efficient resource usage, a key benefit inherent to cloud comput-ing. The article also proposes at the PaaS level an accompanying platform todevelop and manage the IVR applications which use the identified virtualized sub-strates. A few typical IVR applications are also developed and managed to illus-trate the SaaS facet of cloud computing. The implementation is described, alongwith the prototype and the performance measurements.

A Case Study on IVR Applications’Provisioning as Cloud Computing Services

Fatna Belqasmi, Christian Azar, and Roch Glitho, Concordia UniversityMbarka Soualhia and Nadjia Kara, University of Quebec

I

This article is an extended version of a paper presented at the ITU-T Kalei-doscope conference 2011 under the title “A Virtualized Infrastructure forIVR Applications as Services”

BELQASMI_LAYOUT.qxp_Layout 1 1/15/14 11:41 AM Page 33

IEEE Network • January/February 201434

layer is the platform layer. It includes graphical user interfaces(GUIs) and application programming interfaces (APIs) thatare used for the development and management of the applica-tions in the top layer.

One of our first design goals is that different IVR applica-tions in different domains should be able to share substrates,as illustrated in Fig. 1. Conversely, an IVR application shouldalso be able to use many instances of the same substrate, forscalability. Another design goal is that it should be possible topublish and discover substrates and substrate instances. Yetanother goal is that IVR service providers should be able tocompose the substrates available in the infrastructure intopowerful IVR applications, using appropriate platforms. Thedesign goal assigned to the platform in this case study is thatit should be easy to use and should not require expertise insoftware design.

Related WorkSeveral commercially-hosted IVRs, such as call centers, allowusers to remotely access IVR applications as services. Howev-er, to the best of our knowledge these applications do not relyon virtualized infrastructures. Some work has been done toenable re-usability and extensibility in the IVR world.

A first example is presented in [1]. The authors proposea layering format for IVR systems. The lowest layer, calledthe functionality layer, deals with voice cards and providesan abstract interface to the highest layer, called the servicelayer. This enables the re-use of the abstract layer acrossvoice cards. The same paper also proposes the use of XMLfiles to enable some level of extensibility when configuringIVRs. However, virtualization is not considered and there-usability and extension that can be achieved with theapproach proposed in [1] is far from what could beachieved with the virtualized substrates proposed in thisarticle.

A second example is a configurable IVR system [6] thatend-users can customise according to their needs. They mayfor instance personalise the IVR menu to make it more suit-able for their own use. However, the efficient use of resourcesthrough virtualization is not addressed. A more interestingapproach is presented in [7]. The authors propose an architec-ture for IVR in the Cloud, covering the Iaas, PaaS and SaaS.The main drawback of this work is the same as the two previ-

ously discussed related works. Theefficient use of resources throughvirtualization is not addressed. Fur-thermore substrates’ sharing, publi-cation, discovery, and compositionare not tackled.

Embryonic architectures havebeen proposed that could offer afew applications, which includesome selected IVR features, as ser-vices in clouds. One example is con-ferencing that can includeannouncement player and digit col-lector. A video conferencing appli-cation as SaaS is proposed in [8],along with the required supportingvirtualized infrastructure. The goalis to ease the integration of videoconferencing with other applica-tions. The infrastructure is limitedto one virtual full-blown video con-ferencing server. The key drawbackis that it follows a very coarse-grained approach. It does not pro-

vide an infrastructure with substrates that can be published,discovered and dynamically shared, as we envision in thearchitecture proposed here. Furthermore, it does not includeany IVR features.

Substrates have been proposed for virtualized infrastruc-tures that support applications with no bearing on IVR. Oneexample is the infrastructure we have proposed for presence[9]. That proposed architecture includes a business model.However, the work is still at a preliminary stage and thus faronly one substrate has been identified for the application.Publication, discovery and composition have not yet beenaddressed.

Several virtualized infrastructures have been proposed forFuture Internet [10]. These rely on virtualized nodes and linksas substrates. However, they focus on the core infrastructureof the Internet and do not address issues related to the virtu-alization of the Internet’s edge infrastructure, where applica-tions such as those of IVR reside.

A few architectures do deal with some of the challengesrelated to application development by composition in a cloudenvironment. However, none of them addresses the specificcase of IVR applications. An example is provided in [11]. Ittargets applications at large and proposes a virtualized mashup container. Application substrates, called service compo-nents in that work, are described using existing technologiessuch as REST, JSON, and RSSFeed. A service proxy mapsthese descriptions into the internal description technologysupported by the container. However, the specific publicationand discovery mechanisms are not discussed.

Another example is provided in [12], which puts forth aninfrastructure where music content providers federate withvalue-added service providers (e.g. security, audit) to buildvirtual music stores on the fly. Several registries (e.g. client,capability registry) are mentioned. However, no detailedinformation is provided about how the content of these reg-istries is described, published and discovered.

ArchitectureThe business model is presented first, followed by the archi-tectural components, and then the interfaces. An illustrativescenario is presented next. The last sub-section discusses thesubstrates’ sharing.

Figure 1. Overall vision.

End-users

SaaS layer

Platform layer

Infrastructure layer

End users

Clinicaltrials

Automatedsurvey

Automatedattendant

IVRbanking

Announcementplayer

Extensiondetector

Calltransfer

Keydetector

Voicerecorder

Automatedmeter reading

APIs GUIs


IEEE Network • January/February 2014 35

Business ModelFigure 2 shows the proposed business model. The IVRservice provider offers IVR applications as SaaS,accessible to end-users and other applications; andalso develops and manages the applications using theIVR platform offered by IVR platform providers. Theplatform adds levels of abstractions to IVR infrastruc-tures to ease IVR application development and man-agement. For instance, in our case study it offers aGUI for developing IVR applications.

The IVR infrastructure providers offer the infrastructure(e.g. substrates) necessary to create and run IVR applications.An infrastructure might comprise different types of substrates(e.g. network substrates and computing substrates) as dis-cussed in [13]. This holds for our case study where substratesrange from voice recorder to announcement player andinclude key detector. To further refine the existing businessmodels, we assume in this article that some of these differentsubstrates might be provided by third parties and the infras-tructure providers might lease them. We call these third par-ties substrate providers.

In our case, the IVR substrate providers offer the virtual-ized and sharable IVR substrates to IVR infrastructureproviders, which make these substrates available and ready tobe used by the service providers (via the platform layer). Theinfrastructure providers may offer different substrates via aunified interface and therefore hide their heterogeneity.

The broker enables the substrate providers to publish theirsubstrates, and allows the infrastructure providers to discoverand select the substrates that meet their requirements. Theconnectivity provider enables connectivity between the differ-ent actors. As in any business model, the same entity can playseveral roles in the proposed model.

In a traditional IVR application provisioning businessmodel, an IVR usually comes as a single monolithic compo-nent. There is therefore no sharable substrates, no broker, noinfrastructure provider, and no platform provider. The IVRservice provider offers a full-fledged service that is directlyused by end-users.

Our proposed model is a multiplayer model, since theremay be several substrate providers interacting with the sameinfrastructure provider, and several infrastructure providersinteracting with the same platform provider. However, there isno contention because all interactions are performed via thebroker.

Architectural ComponentsFigure 3 shows the proposed architecture. It comprises threelayers, three planes and a repository. The three layers are theplatform, the infrastructure and the substrate layer. The inter-actions between the three layers are organized via threeplanes: service, management and composition. The repositoryinstantiates the role of broker.

The key functional entities of the three layers are the plat-form IVR engine, the infrastructure IVR engine, and the sub-strate IVR engine. The platform IVR engine coordinates theoperation of the platform layer entities at the three planes;i.e. the platform service, management and compositionengines. The infrastructure IVR engine coordinates the activi-ties of the virtual service engine, the virtual managementengine and the virtual composition engine. The substrate IVRengine coordinates the activities of the substrate serviceengine, the substrate management engine, and the substratecomposition engine. The infrastructure IVR engine interactswith several substrate IVR engines—or more precisely, itinteracts with the engines of all the substrates that make up agiven composed service.

The main functionality handled in the service plane is medi-ation. In addition to mediation, the service plane also coordi-nates the execution of services that involve several substrates.

The management plane handles the actual control andmanagement of substrate resources. The composition planeinteracts with the repository and enables the publication anddiscovery of the substrates and substrate instances that areused in composition. The discovery may be based on specificcriteria, such as the type of the substrate (e.g. a key detector)or its capacity (e.g. 100 calls/s).

InterfacesThe virtual service engine and the substrate service enginecommunicate via the interface supported by the substrate ser-vice engine. The virtual service engine interacts with the plat-form service engine using the same interface. Our choice ofthe substrate interface is motivated by the fact that potentialIVR substrates currently come with a plurality of interfaces(e.g. VoiceXML, Session Initiation Protocol-SIP, Media Serv-er Control Markup Language-MSCML). They communicatewith the virtual service engine via mediators that are incorpo-rated in the virtual service engine.

A key requirement for the management interface is that itmust accommodate a plurality of resource description mecha-nisms (e.g. XML, plain text). Another requirement is that theinterface should be supported by commonly used virtualizationservers, such as XEN, to ease the creation of instances. Theserequirements have led to our selection of RESTful Web ser-vices as the natural choice. RESTful Web services follow theRepresentational State Transfer (REST) design paradigm,which uses the Web’s basic technologies (e.g. HTML, XMLand HTTP) as a platform to provision distributed services [14].

We have also decided to use RESTful Web services for thepublication/discovery interfaces to minimize the number ofinterface technologies in our proposed architecture. The factthat RESTful services support a wide range of resourcedescription mechanisms is also a distinct advantage for publi-cation and discovery.

Illustrative ScenarioThe infrastructure of this scenario is composed of the fivesubstrates shown in Fig. 1. We assume that the substrates aresupplied by substrate providers SubP1, SubP2, SubP3, SubP4,and SubP5, respectively. We further assume that we have oneinfrastructure provider (InfP), one platform provider (PP),two service providers (ServP1, ServP2) and one end-user witha subscription to one of the two service providers.

The substrates are described using WADL [15] (as implied byour choice of RESTful Web services), and Donkey StateMachine (DSM) [16]. The DSM description represents the sub-strate behavior as a state machine and is included under the<doc> element of the WADL description. The use of DSM ismotivated by the fact that it is used by the SIP Express MediaServer (SEMS) [17] in our prototyping environment, and becauseit makes the substrates’ composition easier. DSM enables a tex-tual description of applications (substrates in our case) that canbe directly executed by interpreters hosted by the SEMS.

Figure 2. Business model.

IVR serviceprovider

IVR platformprovider

IVR substratesprovider

IVR infrastructureprovider

Broker

Connectivity provider

BELQASMI_LAYOUT.qxp_Layout 1 1/15/14 11:41 AM 5


The scenario covers application development (including thepre-required publication and discovery of substrates), manage-ment and execution. The management phase is restricted toactivation. Figure 4 depicts these three phases. In Fig. 4a, thesubstrate composition engine of each substrate provider pub-lishes its substrate to the repository using a put request, withthe WADL description of the substrate as argument.

Next, the first service provider uses the GUI offered by theplatform provider to discover existing substrates. The request isforwarded to the virtual composition engine of the infrastruc-ture provider, which sends a get request to get the list of avail-able substrates with their descriptions. It should be noted thatthe get request could have been sent at anytime during the pro-cess to get the list of substrates available at that point. The list isthen made available to the platform engine, which adds a levelof abstraction to the substrates by making them visible througha GUI. The first service provider uses the GUI to develop anautomated attendant by composing the substrates, while the sec-ond one develops an automated survey by the same process.

Figure 4b describes the flow that occurs for applicationactivation. Through the same GUI, the first service providerinstructs the activation of the composed service. The requestis then forwarded to the infrastructure provider`s virtual com-position engine. The latter uses the description of the com-posed service (created in the previous step) and creates adifferent instance of the virtual management engine to com-municate with each of the substrates involved in the composi-tion. The virtual composition engine then instructs theseinstances to create a substrate IVR service instance (ISI) at

each substrate. The instantiation is accomplished by sending apost request to the appropriate substrate, along with the DSMdescription of the service instance to create and the identifierof the IVR service provider. When a substrate managementengine receives an instantiation request, it verifies the avail-ability of the relevant physical resource(s) (e.g. CPU, memo-ry), creates a new ISI and allocates the necessary resources.

Figure 4c presents the execution flow for the automatedattendant service. The virtual IVR engine of the infrastructureprovider receives an IVR execution request from the platformprovider. It then gets the service description from the virtualcomposition engine (including the ISIs to use), creates a virtu-al service engine instance to communicate with each of thesubstrates, and instructs the different instances to execute theappropriate sub-requests, following the request plan. A requestplan is a set of sub-requests and their execution sequence,along with the relevant substrates/ISIs that are required torespond to an IVR request. The request plan is created by thevirtual composition engine during the service creation phase.

When a substrate service engine receives a service execu-tion request, it forwards the request to the appropriate ISI,which then executes the request and replies back to the virtualservice engine.

Substrates’ SharingThe IVR applications can share the substrates at two levels: aphysical and a virtualized level. At the physical level, differentsubstrate instances may be running on the same physicalmachine, sharing the physical resources (e.g. CPU, memory,

Figure 3. Overall architecture.

Mgmt.I/F

ServiceI/F

Platformcomposition

engine

Platform IVR engine

Infrastructure IVR engine

Substrate IVR engine

Substrate layer

Infrastructure layer

Platform layer

IVRsubstraterepository

Platformmanagement

engine

Managementplane

Mgmt.I/F

ServiceI/F

Discovery I/F

Serviceplane

Platformserviceengine

Virtualcomposition

engine

Virtualmanagement

engine

Virtualserviceengine

Substratecomposition

engine

Substratemanagement

engine

Substrateserviceengine

Publication anddiscovery I/F

Publication anddiscovery I/F

Compositionplane



processors, and disk space) offered by the machine. The phys-ical resources allocated to each instance may be dynamicallyupdated to adapt to the actual instance usage (e.g. moreresources are allocated in peak periods). Each instance will berunning on a separate virtual machine (VM), in order toachieve resource isolation. A different substrate instance iscreated for each service provider. When multiple substratesare offered by the same provider, a service provider maychose to either have all of its substrate instances running onthe same VM or on separate VMs.

At the virtualized level, different service providers mayshare the same IVR instance (e.g. ServP1 and ServP2 use thesame announcement player instance). This will increase thelevel of sharing, minimize the infrastructure cost, and lowerthe number of VMs required, thereby reducing the overheadinduced by creating and managing new VMs [18]. On theother hand, the isolation between the different serviceproviders will be affected. However, this can be handled bymeans of policies, given that no or only limited sensitive datais used by the IVR substrates (e.g. the announcement player

Figure 4. Application development, management and execution phases: a) substrate pulication and discovery; b) service activation; andc) the first step (i.e. play announcement) of the execution of the automated attendant service.

InfP

1: Incoming call

2: Execute (automated attendant)

3: getServiceDescription (automated attendant)

4: Description, request plan

5: Execute (announcement player, SubP1, ISI-ID, client address)

7: “Welcome message” announcement

8: Announcement played

6: playAnnouncement (ISI-ID, proxy address)

SubP1

Platform IVRengine

Virtual compositionengine Virtual management

engine

Virtual serviceengine

Virtual IVRengine

1: Activate (automated attendant)

2: POST (automated attendant)3: Activate (automated attendant)

4: <<Create>>

5: CreateInstance(Subp1, announcement player DSM, service provider ID)

8: SII-ID

9: CreateInstance(Subp5, call transfer DSM, service provider ID)

6: POST (announcement player DSM)

10: POST (call transfer DSM)

7: ISI-ID

11: ISI-ID12: ISI-ID13: Activated14: Activated (service ID)

15: Activated

SubP1 SubP5

SubP1Client ServP1 Virtual IVRengine

Virtual compositionengine SubP5

Platform managementengine

SubP2 SubP5 Broker

(a)

(b)

(c)

7: GET8:

6: GET5: PUT (call transfer)

2: PUT (voice recorder)

1: PUT (announcement player)

9:

InfP PlatP

PlatP InfP

The call is transferred to the firstsubstrate, which plays a welcomemessage to the client through thevirtual service engine that act as amediation proxy between theclient and the substrate provider.

Announcement player: SubP1Voice recorder: SubP2Key detector: SubP3Extension detector: SubP4Call transfer: SubP5



may not store any data, merely playing the requested messageto the specified user).

A service provider can give its preferences, such as whetherto use separate substrate instances or to share existing oneswhen activating a new service.

ImplementationWe start off this section with the software architecture, fol-lowed by the prototype description. The last sub-section pre-sents and discusses the performance results.

Software ArchitectureFigure 5 presents the software architecture. The IVR sub-strate repository includes a publication manager and a discov-ery manager that handle the publication and discoveryrequests, respectively. The published service descriptions arestored in a local database.

At the platform layer, the platform IVR engine is com-

posed of a platform GUI, a service request handler, and aplatform operation coordinator. The GUI handles the man-agement and the composition requests from the serviceprovider. The service request handler processes the serviceexecution requests from end-users. The platform operationcoordinator dispatches the incoming requests to the appropri-ate planes and coordinates their execution.

The platform composition engine is comprised of two enti-ties: a composition manager and a discovery engine. The com-position manager creates the composition request to be sentto the infrastructure layer, based on the information given viathe GUI. The discovery engine interacts with the infrastruc-ture layer to get the list of available substrates, or directlywith the broker to discover existing IVR services (e.g. a com-posed service that was created by another service providerand made available for reuse).

The platform management engine is made up of a servicelevel agreement (SLA) manager and an activation manager.The SLA manager is responsible for establishing and manag-

Figure 5. Software architecture.

Platform composition engine Platform managementengine

DB

Discoverymanager

Publicationmanager

Publicationengine

Instancecoordinator

IVR serviceinstance

CompositionmanagerIVR component

IVR resourcemgmt engine

Substratemanagement

engine

Substrate compositionengine

SubstrateIVR engine

Infrastructure IVR engine

Service request handler

Message dispatcher

Substrate service engine IVR instancemanager

IVRsubstraterepository

Substratelayer

Infrastructurelayer

Platform layer

Service I/F

Service I/F

Management I/F

Management I/F

DB

IVR resource manager

DB

Management request handler

Service request handler Management request handler

ISS client

Executionengine

Mediationcoordinator Mediation

proxy

Serviceorchestrator

SLA manager

Activationmanager

Serviceexecution

coordinator

Serviceactivation

coordinator

Servicecreation

coordinatorManagementcoordinator

Virtual management engine

Virtualizationclient

Virtual service engine

Discovery andpublication engine

Executionmanager

Discoveryengine

Compositionmanager

Service request handler Platform GUI

Platform operation coordinator

PlatformIVR engine

Platform service engine



ing an SLA between the service and the plat-form providers. It also performs security(e.g. authentication and admission control)and resource monitoring (e.g. for billing pur-poses) functions. The activation managermanages and forwards the activation requeststo the infrastructure layer.

The platform service engine contains twoentities: the service orchestrator and the exe-cution manager. The service orchestratorplays the role of a service execution con-troller. It interacts with the execution man-ager to run or stop the execution of a givenIVR service.

At the infrastructure layer, the service andmanagement request handlers realize theservice and the management interfaces ofthe infrastructure provider, respectively. Thevirtual composition engine contains fourfunctional entities: the service creation coor-dinator, the discovery and publicationengine, the service activation coordinator,and the service execution coordinator. Theservice creation coordinator gets the list ofavailable substrates from the broker (usingthe publication and discovery engine) and sends them to theplatform provider. It also takes the inputs from the platformprovider GUI for the service composition, creates the descrip-tion file for the composed service, and stores the descriptionin a local database. The service activation coordinator man-ages and coordinates the instantiation of new ISIs. The serviceexecution coordinator coordinates the execution of a givenservice request.

The virtual service engine is composed of an executionengine, itself made up of a mediation coordinator and anIVR service substrate (ISS) client, and a mediation proxy.The mediation coordinator translates the requests receivedfrom the service execution coordinator into requests thatthe ISS client should send to the target substrate. The medi-ation proxy plays the role of a media proxy between theend-user and the different substrates involved in the serviceto execute.

The virtual management engine has two entities: the man-agement coordinator and the virtualization client. The man-agement coordinator translates the requests received from theservice activation coordinator into requests that the virtualiza-tion client should then send to the target substrate.

At the substrate layer, each ISI is managed by a separateIVR instance manager. The message dispatcher (attachedto the management request handler) dispatches thereceived messages to the appropriate IVR instance manag-er. The management messages for a given ISI are forward-ed to the IVR instance manager that created it . Therelationships between service instances and their managersare saved when the service instances are created. The IVRresource manager maintains and monitors the currentstates of the physical resources and allocates resources fornew ISIs.

The substrate service engine includes one or more IVRcomponents (e.g. in the case of the automated attendant, wehave five IVR components) and an instance coordinator thatorchestrates the execution of the different components. Thecomposition manager allows new IVR service components tobe created and managed from existing substrate services whenactivating new IVR service instances. The publication engineis responsible for publishing the IVR substrates as well as thenewly created ISIs.

Prototype

As a prototype, we implemented the scenario presented in theillustrative scenario section, where a service provider createsand provisions an automated attendant service. The substrateservices are implemented using DSM and deployed on anSEMS server. The REST interface of the substrate manage-ment engine is implemented using Jersey, an open source ref-erence implementation of JSR 311. The interface module isdeployed on a Glassfish server; it communicates with theSEMS using sockets. The implementation of the IVR sub-strate repository is also based on Jersey and deployed on aGlassfish server.

Figure 6 presents the GUI offered by the platform provider.The GUI shows the existing (substrate) services, discovered byinterrogating the substrate repository after the serviceprovider has pushed the “Discover” button on the GUI. TheGUI allows the service provider to create a composed serviceby choosing the substrates to compose and then orderingthem graphically. When the “Compose” button is pushed, arequest is sent to the service creation coordinator to generatethe DSM description of the composed service. The servicecreation coordinator also generates the execution plan of thecomposed service and stores the DSM description and theexecution plan in the local database. The activation of thenew service is initiated by pushing the “Activate” button.

Figure 6 shows the creation of the automated attendantservice. The client calls a company`s generic number and getsan announcement inviting him/her to enter the extension ofthe person to reach. The client provides the extension and isthen connected to that person. If that person does not answer,the client can leave a voice message. After the composed ser-vice is created, the service provider can publish it to the sub-strate repository, so that other service providers or clients canuse it.

Three use cases were considered. In the first use case, weassume that the five substrate services are offered by the samesubstrate provider. The composed service is then offered bythe same provider and the execution plan is the same as whenexecuting a simple (i.e. non-composed) service.

In the second use case, two substrate providers were con-sidered. The first one provides the extension detector and the

Figure 6. The platform provider GUI.

The composedservice

List of existing(substrate) services

The name of thecomposed service



call transfer, and the second provides the other three sub-strates (including the announcement player).

In the third scenario, three substrate providers wereinvolved. The first one provides the extension detector, thesecond offers the call transfer, and the third one provides theannouncement player as well as the other two substrates.

At the service plane, the composed IVR service is accessedvia SIP. A free SIP client, X-Lite, is used as the IVR client.To initiate the service execution, X-Lite sends a SIP INVITEto its service provider, which proxies the call to the virtual ser-vice engine that orchestrates the composed service executionas well as the communication with the involved substrate ser-vice engines.

Performance MeasurementsPerformance measurements were made under both normaland stressed conditions. The main purpose of the measure-ments under normal conditions is to compare the perfor-mance between running the automated attendant service in avirtualized environment and running it in a non-virtualizedenvironment (i.e. using a regular machine that hosts a full-fledged service). The measurements under stressed conditionsserve to assess the performance of the virtualized serviceunder heavy load conditions.

In this sub-section, we first describe the experimental setup,and then we present the performance metrics used for bothcategories. The performance results are presented and dis-cussed at the end.

Experimental Setup — The experiment was set up with sixmachines, all connected to the same local area network. Theservice provider and the broker were each run on a differentmachine with Windows 7, an Intel core i7, and 8 GB of RAM.The infrastructure provider ran on a machine with Windows 7,2 Intel® Xeon® CPU W3520 @ 2.67GHz, and 4GB of RAM.

A desktop server was used to run Xen Server, so that a dif-ferent virtual machine could be used for each substrate. Theautomated attendant service ran on a separate virtualmachine, with 2 GB of RAM, a Linux Ubuntu operating sys-tem, and 2 Intel® Xeon® CPU E5649 @ 2.53GHz.

SIPp was used as a SIP client (i.e. the caller). SIPp is a per-formance testing tool that can establish and release multipleSIP calls simultaneously. A SIPp client was run on a machinewith Linux Ubuntu, 1GB of Memory, and 1 Intel® Xeon®CPU W3520 @ 2.67GHz. The callee was set up to run in adifferent machine, with the same characteristics.

Performance Metrics — The prototype’s performance is evalu-ated in terms of the end-to-end time delay for publishing aservice/substrate, for discovering existing services/substrates,and for executing the automated attendant service. The publi-

cation and discovery delays are measured as the differencebetween the time when the requestor (e.g. the discovery andpublication engine at the infrastructure layer) sends a requestand the time it receives the response (e.g. the list of existingsubstrates).

The execution delay is measured in terms of the call length,which is the total time between when the caller sends anINVITE message and when it gets a BYE request from thecallee. By adapting the IVR service to make it directly call aspecific extension when an INVITE message is received, weeliminate the delays added by playing the welcome files andby the human entering an extension number.

The testing call scenario in the case of a virtualized envi-ronment is as follows. The caller (i.e. the SIPp client) sendsan INVITE message to the automated attendant serviceprovider. The automated service provider proxies the call tothe infrastructure provider, which orchestrates the executionof the composing substrates. When the call transfer substrateis called, it transfers the call to the callee, who accepts thecall, plays a “bip” message, then sends a bye message.

For stress testing, we also measure the execution delay interms of the response delay, which is the time differencebetween sending an INVITE message and receiving a 200 OKresponse from the callee. We further measure the percentageof CPU and memory utilization.

Performance Results — We first measured the time needed todiscover all the substrates available in the broker, then thetime to publish a new composed service. The averages ofthese measures are 330 ms and 447 ms. Each measurement isan average of ten experiments. These time measurementsshow that the discovery and publication delays remain accept-able from the service provider point of view.

Figure 7a shows the evaluation results for the service exe-cution in normal circumstances. They reveal that the time dif-ference between the service execution on a virtualized and anon-virtualized environment is barely observable by end-userswhen only one substrate provider is used. We can thereforeconclude that the use of the proposed novel architecture doesnot penalize the system’s performance in this case. On theother hand, by using the proposed architecture, serviceproviders can develop and manage their own IVR serviceswith all the benefits of the virtualized environment.

In the case of different substrate providers, the execution delaysincrease linearly with respect to the providers’ number. This is anextreme case because the different substrates need to be executedsequentially. The performance would be much improved for ser-vices that allow substrates to be executed in parallel.

For stress testing, we started with a call generation rate of 5calls/s, which we then increased up to 100 call/s in 100 sec-onds. Figure 7b shows the results. The total number of calls

Figure 7. Performance results.

Number of times

(a)

10

200Cal

l len

gth

[ms]

100

0

300

400

500

600

700

800

20 30 40 50 60 70 80 90 1000Number of calls generated per second (CPS)

(b)

10

Tim

e [m

s]

% u

tiliz

atio

n

100

0

200

300

400

500

0

10

20

30

40

50

60

70

80

20 30 40 50 60 70 80 90 1000

Non-virtualized environment1-Substrate provider2-Substrate providers3-Substrate providers

Call lengthResponse time%CPU%Memory



generated during the 100s period was 5230. As expected, theexecution delays as well as the memory and CPU usageincreases linearly with the number of calls. However, exceptfor the CPU use, the increase rates of these parameters arerather small. This result means that the CPU is the mainparameter to consider when planning for new IVR applicationprovisioning in the Cloud.

Conclusions and Future Work

A first conclusion we can draw from this work is that casestudies that focus on specific applications but cover severalkey aspects of cloud computing (i.e. IaaS, PaaS, SaaS) arequite beneficial because they aid in gaining very usefulinsights into the development and management of applica-tions in cloud settings (e.g. interactions between layers andwith repositories).

The second conclusion is that service providers can easilyand quickly develop IVR applications in the cloud using asimple PaaS graphical user interface. The process does notrequire any expertise in software design. Instead, a visual,coherent drag & drop mechanism is adopted to add/removeservices, conditions, or actions.

The third conclusion is that virtualization does come at aprice in terms of overhead when we compare it to non-virtual-ized environments. However, our measurements indicate thatthe price could be affordable, especially when all the expectedbenefits are factored in. This might be the case when, forinstance, only one substrate provider is used, or when the sub-strates can be executed in parallel.

The last conclusion concerns the substrates’ composition tocreate and execute new services. The case of IVR has provento be one of the simplest cases because the substrates involvedare executed sequentially. However, it is also one of the ser-vices that introduce more execution delays for the same rea-son. More complex approaches and algorithms are needed forservices that allow substrates to be executed in parallel, suchas in conferencing.

In future work, we will tackle resource allocation and man-agement schemes for IVR applications. This includes the defi-nition of appropriate schemes that will enable infrastructureproviders to identify and allocate the optimal amount of phys-ical resources to the different IVR substrate instances. Wewill also research more generic algorithms for substrates’ com-position. Quality of service and service level agreement man-agement are also on our list of items for future work.

References[1] S. Xu et al., “Design of Hierarchical and Configurable IVR System,” 2nd

Int’l. Conf. Computational Intelligence and Natural Computing Proc.(CINC), vol. 2, Sept. 2010, pp. 205–08.

[2] A. Khan et al., “Network Virtualization: A Hypervisor for the Internet?,”IEEE Commun. Mag., vol. 50, no. 1, Jan. 2012, pp. 136–43.

[3] M. Armbrust et al., “A View of Cloud Computing,” Commun. ACM, vol.53, no. 4, Apr. 2010, pp. 50–58.

[4] L. M. Vaquero et al., “A Break in the Clouds: Towards a Cloud Defini-tion,” ACM SIGCOMM Comp. Commun. Review, vol. 39, no. 1, Jan.2009, pp. 50–55.

[5] A. Mishra et al., Guest Editors, “Cloud Computing: Networking and Com-munications Challenges,” IEEE Commun. Mag., vol. 50, no. 9, Sept.2012, pp. 24–25.

[6] M. Soujanya and S. Kumar, “Personalized IVR Aystem in Contact Center,”Int’l. Conf. Electronics and Information Engineering (ICEIE’2010), vol. 1,Aug. 2010, pp. 453–57.

[7] A. Chotimongkol et al., “Smart IVR Service Platform,” Service Researchand Innovation Institute Global Conference Global Conference (SRII), July2012, pp. 426–34.

[8] P. Rodriguez et al., “VaaS: Videoconference as a Service,” 5th Int’l. Conf.Collaborative Computing: Networking, Application and Worksharing (Col-laborateCom 2009), Nov. 2009, pp. 1–11.

[9] F. Belqasmi, N. Kara, and R. Glitho, “A Novel Virtualized Presence Ser-vice for future Internet,” IEEE Int’l. Conf. Commun. (ICC’2011), Wksp.Future Networks, June 2011, pp. 1–6.

[10] J. Carapinha and J. Jiménez, “Network Virtualization: A View from theBottom,” Proc. 1st ACM workshop on Virtualized Infrastructure Systemsand Architectures (VISA-09), 2009, pp. 73–80.

[11] M. Stecca and M. Maresca, “An Architecture for a Mashup Container inVirtualized Environments,” IEEE 3rd Int’l. Conf. Cloud Computing, July2010, pp. 386–93.

[12] P. de Leusse et al., “Secure and Rapid Composition of Infrastructure Ser-vices in the Cloud,” Proc. 2nd Int’l. Conf. Sensor Technologies and Appli-cations (SENSORCOMM ’08), pp. 770–75, 2008.

[13] G. Koslovski et al., “Locating Virtual Infrastructures: Users and InP per-spectives,” IFIP/IEEE Int’l. Symp. Integrated Network Management (IM),May 2011, pp. 153–60.

[14] F. Belqasmi, R. Glitho, and F. Chunyan, “RESTful Web Services for Ser-vice Provisioning in Next-Generation Networks: A Survey,” IEEE Commun.Mag., vol. 49, no. 12, Dec. 2011, pp. 66–73.

[15] W3C Member Submission, “Web Application Description Language,” 31Aug. 2009.

[16] Donkey State Machine (DSM), http://ftp.iptel.org/pub/sems/doc/cur-rent/ModuleDoc_dsm.html, Nov. 2012.

[17] SIP Express Media Server, http://www.iptel.org/sems, Nov. 2012.[18] P. Garbacki and V. K. Naik, “Efficient Resource Virtualization and Shar-

ing Strategies for Heterogeneous Grid Environments,” 10th IFIP/IEEE Int’l.Symp. Integrated Network Management (IM ‘07), May 2007, pp. 40–49.

BiographiesFATNA BELQASMI () holds a Ph.D. and an M.Sc. degree in electrical and com-puter engineering from Concordia University, Canada. She is a research asso-ciate at Concordia University, Canada. In the past, she worked as aresearcher at Ericsson Canada. She was part of the IST Ambient Network pro-ject (a research project sponsored by the European Commission within theSixth Framework Programme -FP6-). She worked as an R&D engineer forMaroc Telecom in Morocco. Her research interests include next generationnetworks, service engineering, distributed systems, and networking technolo-gies for emerging economies.

CHRISTIAN AZAR ([email protected]) holds a Master of Applied Sci-ence (M.A.Sc) in Electrical and Computer Engineering from Concordia Univer-sity, Canada, and a Bachelor of Science (B.Sc) in Computer Engineering fromUniversity of Balamand, Lebanon. He possesses 4 years of professional expe-rience in system administration and software development. His research inter-ests include Web Technology, Computing Systems and Networking.

MBARKA SOUALHIA ([email protected]) holds an M.Engdegree in Engineering concentration Information Technology from École deTechnologie Supérieure (ÉTS), Canada and a bachelor degree in ComputerSciences from École Supérieure de Sciences et de Technologies à Tunis(ÉSSTT), Tunisia. She is currently a Ph.D student at Concordia University.Her research interests include Hardware Specification and Verification andFormal Methods which focuses on the development of methodologies, algo-rithms and tools for formal and semi-formal verification of hardware andembedded systems.

NADJIA KARA received her Ph.D., in Electrical Engineering from Ecole Polytech-nique of Montreal, Canada. She has worked in the industry as researcher andsystem architect for more than 10 years. She is an associate professor in soft-ware engineering and IT at ETS, University of Quebec in Montreal, Canada.Her research interests include network and service architectures, next genera-tion networks, distributed systems and algorithms.

ROCH GLITHO [SM] (http://users.encs.concordia.ca/~glitho/) holds a Ph.D.(Tekn. Dr.) in tele-informatics (Royal Institute of Technology, Stockholm, Swe-den) and M.Sc. degrees in business economics (University of Grenoble,France), pure mathematics (University Geneva, Switzerland), and computer sci-ence (University of Geneva). He works in Montreal, Canada, as an associateprofessor of networking and telecommunications at the Concordia Institute ofInformation Systems Engineering (CIISE) where he leads the telecommunicationservice engineering (TSE) research laboratory (.ht tp://users.encs.concordia.ca/~tse/). In the past he has worked in industry for almost a quar-ter of a century and has held several senior technical positions at LM Ericssonin Sweden and Canada (e.g. expert, principal engineer, senior specialist). Hisindustrial experience includes research, international standards setting (e.g.contributions to ITU-T, ETSI, TMF, ANSI, TIA, and 3GPP), product manage-ment, project management, systems engineering and software/firmwaredesign. In the past he has served as IEEE Communications Society distin-guished lecturer, Editor-In-Chief of IEEE Communications Magazine and Editor-In-Chief of IEEE Communications Surveys & Tutorials. His research areas are:virtualization and cloud computing; Machine-to-Machine communications(M2M) and Internet of Things; Distributed systems (e.g. SOAP Based - WebServices, RESTful Web Services); Rural communications and networking tech-nologies for emerging economies.


a case study on ivr applications' provisioning as cloud computing services

Documents