02+CoCaMAAL- A cloud-oriented context-aware middleware in ambient assisted living_Forkan, Abdur; Khalil, Ibrahim; Tari, Zahir

7/26/2019 02+CoCaMAAL- A cloud-oriented context-aware middleware in ambient assisted living_Forkan, Abdur; Khalil, Ibrah

1/14

Future Generation Computer Systems ( )

Contents lists available atScienceDirect

Future Generation Computer Systems

journal homepage:www.elsevier.com/locate/fgcs

CoCaMAAL: A cloud-oriented context-aware middleware in ambientassisted living

Abdur Forkan a,b,,Ibrahim Khalil a,b,Zahir Tari b

a National ICT Australia (NICTA), Victoria Research Lab, Melbourne, Victoria, Australiab School of Computer Science and IT, RMIT University, Melbourne, Victoria, Australia

h i g h l i g h t s

We have designed a cloud-based model for a context-aware system in ambient assisted living. We have developed a service-oriented architecture to support context-aware services. We suggest a new context-modeling approach for generating context. We evaluated our model by evaluating some case studies in a simulated environment.

a r t i c l e i n f o

Article history:

Received 28 December 2012

Received in revised form10 June 2013

Accepted 17 July 2013

Available online xxxx

Keywords:

Ambient assisted livingBody sensor

Ambient intelligence

Context-aware service

Cloud computing

a b s t r a c t

Research into ambient assisted living (AAL) strives to ease the daily lives of people with disabilities orchronic medical conditions. AALsystems typically consist of multitudesof sensors and embedded devices,generating large amounts of medical and ambient data. However, these biomedical sensors lack the pro-cessing powerto perform key monitoring anddata-aggregationtasks, necessitating datatransmission andcomputation at central locations. The focus here is on the development of a scalable and context-awareframework and easing the flow between data collection and data processing. The resource-constrainednature of typical wearable body sensors is factored into our proposed model, withcloud computing fea-tures utilized to provide a real-timeassisted-living service. With themyriad of distributed AALsystemsatplay, each with uniquerequirements and eccentricities,the challengelies in theneed to service these dis-parate systems with amiddleware layerthat is both coherent and flexible. There is significant complexityin the management of sensor data and the derivation of contextual information, as well as in the moni-toring of user activities and in locating appropriate situational services. The proposedCoCaMAALmodelseeks to address such issues and implement a service-oriented architecture (SOA) forunified context gen-eration. This is done by efficiently aggregating raw sensor data and the timely selection of appropriateservices using a context management system(CMS). With a unified model that includes patients, devices,and computational servers in a single virtual community,AAL services are enhanced. We haveprototypedthe proposed model and implemented some case studies to demonstrate its effectiveness.

2013 Elsevier B.V. All rights reserved.

1. Introduction

Throughout the world, aging populations and higher disabilityrates have intensified the pressure on already burdened health-care infrastructures. Coupled with higher occurrences of diseasessuch as Alzheimers and dementia, this phenomenon has resultedin urgent interest in ambient assisted living (AAL) research. AALhas gained significance in recent years, combining aspects of in-telligent platform design, assistive living solutions, and ambient

Correspondence to: School of Computer Science and Information Technology,RMIT University, GPO Box 2476, Melbourne, Victoria 3001, Australia. Tel.: +61

450354402.

E-mail addresses:[email protected],[email protected]

(A. Forkan),[email protected](I. Khalil),[email protected](Z. Tari).

intelligence technologies [1] into a coherent system. The idea is foran AAL system that features situational awareness and real-time

decision-making capabilities[2], with adequate flexibility at thearchitectural, algorithmic, and human-interface level. To maintainquality healthcare services[3], it is essential to have an intelligent,highlyresourced AALsystem that is efficient, responsive, and, mostimportantly, adequately secures patient health.

A typical AAL environment consists of a target user, smart sen-sors, actuators, wireless networks, ubiquitous devices, and under-lying software services. Wearable and implantable data collectiondevices (i.e., bodysensors) [4], provide real-time physical and med-ical information on the patient. Likewise, knowledge pertaining tothe environment is obtained from embedded sensors that focus onambient readings (e.g. temperature, humidity). Along with a lo-cal processing point where data are initially transmitted, all these

0167-739X/$ see front matter2013 Elsevier B.V. All rights reserved.

http://dx.doi.org/10.1016/j.future.2013.07.009
http://dx.doi.org/10.1016/j.future.2013.07.009http://www.elsevier.com/locate/fgcshttp://www.elsevier.com/locate/fgcsmailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]://dx.doi.org/10.1016/j.future.2013.07.009http://dx.doi.org/10.1016/j.future.2013.07.009mailto:[email protected]:[email protected]:[email protected]:[email protected]://www.elsevier.com/locate/fgcshttp://www.elsevier.com/locate/fgcshttp://dx.doi.org/10.1016/j.future.2013.07.009


2/14


3/14

A. Forkan et al. / Future Generation Computer Systems ( ) 3

Table 1

Some mentionable research works describing the framework of a context-aware system (CaS).

CaS Contributions Limitations

SOCAM[18] For context modeling, a reasoning mechanism is suggested using OWL

(web ontology language).

Most of the complex tasks are performed in a local network where

services need to be downloaded for use. This limits the model to

serve specific services.

JACF[21] It relies on an object-oriented context model developed in a Java

framework.

No clear indication about context-aware service management.

CAMidO[22] The interpretation of context here is policy based; it collects and

evaluates context by communicating with sensors.

React based on collected context from local system.

RCSM[23] Provides flexibility for runtime context data acquisition, monitoring and

detection using adaptive object containers (ADCs).

Only capable of triggering decision from application level.

5W1H [24] Context model based on 5W1H (who, what, where, when, why, and how).

This model has the capability of handling a large number of contexts and

provides flexibility of service provisioning.

Services are bound to specific smart environment services.

HiCon[16] Supports advanced context-aware services which enforce scalable

monitoring and composition of dynamic context.

The context model is not an accepted standard for AAL.

ERMHAN[15] A context-aware service platform for supporting continuous care

networks for home-based assistance.

Only focus on activity monitoring and related services.

Fig. 1. The generic architecture of CoCaMAAL model showing five major distributed cloud-based components of the proposed system.

3. Related work

In the area of context awareness, several middleware-centric

solutions are proposed in different applications other than assistedliving.Table 1shows a summary of those works and their limita-tions.

There are few research works for building situation-aware as-sisted living systems with sensor technology [25,26]. Some of theworks focus on promoting a users social interaction with his/hersurroundings and co-ordination between several distributed ac-tors such as caregivers and monitoring systems[27,14]. EuropeanUnion-funded projects such as AALIANCE[28], PERSONA[29], andSOPRANO [30] aim at developing a next-generation smart homewith ambient intelligence andscalable open standards for buildinga broad range of AAL services. I-Living [31] allows different par-ties to work together in a dependable, secure, and low-cost systemmanner. The Amigo Project [32] is a good example of an Intel-ligent Home for healthcare. A case-driven ambient intelligencetechnique is describedin [13] by converting context at a given timeas a particular case which is obtained through activity recognitionand case-based modeling.

In most of the proposed solutions, the functionalities of middle-ware are achieved by distributing the tasks in a layered architec-ture. There are several applications that leverage cloud resourcesto design efficient systems. Some of the research mainly suggestedhow cloud infrastructure can be used for information context pro-cessing [3335]. MoCASH [9] used the cloud computing feature forassistive healthcare but the concern was in the context-sensingmechanism using mobile devices. There are also some cloud ap-plications that have been developed for healthcare [3639].

All the contributions described above show current effortsfor building solid architecture for AAL environments. Most of

the models are developed as standalone applications. Cloud-based

context-aware system-related research does not specifically focuson healthcare applications. With the support of cloud computing,body sensor networks (BSNs) can be greatly enhanced for the

deployment of innovative healthcare monitoring applications [40].

4. CoCaMAAL system overview

Context awareness in AAL systems is accomplished by contextflow in a distributed middleware. The abstract architecture of theCoCaMAAL system is illustrated in Fig.1. The system comprises fivemain cloud-oriented components: AAL systems, context aggrega-tor and providers (CAP) cloud, service providers cloud, context-aware middleware (CaM) cloud, context data visualization andmonitoring cloud. That is, every piece of the functional elements ofthe model copes with context and has a cloud-oriented infrastruc-ture. A detailed overview of each of thecomponents is given below.

AAL systems: Our proposed model can serve large numbers ofAAL clients. AAL clients act as sensor data providers as wellas context-aware service consumers. The setup of AAL systemsvaries based on target user requirements. Each of the AAL sys-tems consists of different BSN foundations and monitoring sys-tems [41,42]. Any new AAL system can beincluded in the modelwithout altering the architecture. All the AAL systems togetherform a distributed cloud structure. They generate raw sensordata for the model which become the input for high-level con-text generation and consume context-aware services. For ex-ample, an AAL system generates raw heart beat data from anECG sensor and waits for automated assistive services relevantto the context value of the heart beat rate.

Context aggregator and providers (CAP): The CAP cloud containsthe computing logic and process of converting low-level raw

data to abstract context representation which is recognizable


4/14

4 A. Forkan et al. / Future Generation Computer Systems ( )

to all components of the architecture. The CAP cloud uses fu-sion and reasoning mechanisms to infer context from sensordata [43]. A context provider can be a medical server whichmanipulates ECG medical data, or it can be a weather stationwhich provides context related to a weather forecast (i.e., tem-perature, humidity). For instance, the process of classifying theheart beat rate into a high, medium, or low category is hostedin a cloud server of a context provider which consumes ECG

data as input and outputs the context of the desired classifica-tion. The context aggregator collects data from AAL systems anddistributes them among different context providers for find-ing context. After getting high-level abstraction as context, theaggregator integrates all the information in a single contextmodel. It then forwards that context description to the CaMcloud.

Service providers: Service providers (SPs) are applications andservices related to context awareness. An SP can be a softwareapplication running on the mobile device of an AAL system thatreminds the user about appointments, or it can be an exter-nal caregiver who monitors emergency situations. The SP cloudcontains information such as symptom detection for differentdiseases andthe types of action required.For example, the rules

for detecting fever and related actions are hosted in the clouddatabase of a service provider. The emergency actions that arerequired after detecting the fever of different patients are alsodescribed in the cloud storage. Thus, the SP cloud delivers vari-ous kinds of service to the CaM cloud.

Context-aware middleware (CaM): The CaM cloud is the mostimportant functional component of the model. The CaM cloudhas the infrastructure for processing context data, storing andretrieving context, context-aware service management, accesscontrol [44] mechanisms of medical records, context-to-servicemapping, delivery of assistive actions, and many other complexcomputational tasks. It contains an intelligent context manage-ment system (CMS) which manages incoming context and en-sures that appropriate assistive services are delivered properly

and in a timely manner. A context manager is responsible forstoring and managing context that is gathered from AAL sys-tems and converts them as services. The context manager au-tomatically reconfigures its knowledge to adapt the change incontext.

Context data visualization: Context data contain the valuablemedical information of the user. A proper visual interface isneeded for the healthcare professional to view the informa-tion. Some data visualization services provide useful user in-terfaces for this purpose. Using a flexible GUI, the monitoringsystems can examine medical records. The model also has dif-ferent social networks of doctors and patients friends and fam-ily to analyze, visualize, and discuss medical data wheneverrequired [45]. All these components together form a cloud

source for context data visualization.In our model, all the AAL clients, context providers, and service

providers are physically distributed. The model takes advantage ofcloudcomputing by hosting all the context-processing and service-generation logic inside the cloud platform. Therefore, it becomesbeneficial in terms of elasticity, storage scalability, and extensi-bility. Here, a new AAL client can be added or separated easily. Aprovider (context or service) can join or leave the system anytime.The context-aware cloud adopts its behavior according to the re-cent contextual situation and distributes services related to that.

5. System description

In this section, allfive major cloud components of the model are

briefly described.

Table 2

Examples of some typical body sensors and their use in AAL.

Sensor Measured signal Application

ECG [38] Electrocardiogram wave Heart rate

PPG Photoplethysmogram wave Blood volume pulse

BP Blood pressure in mm Hg Blood pressure

EEG Electroencephalogram wave Abnormality

EMG Electromyograph wave Muscular activity

Accelerometer [46] Acceleration in 3D space Activity recognition

Motion sensor Motion signal User movementActivity sensor 3-axis motion Activity recognition

Inertial sensor Motion signal Position detection

BG sensor Blood sugar level Diabetes detection

Gyroscopes Rotation angle Body orientation

Thermometer Body temperature inF Fever detectionInsulin pump Inject insulin

RF antenna RF wave Position detection

Fall detector Motion signal Fall detection

5.1. AAL system

Our conceptual AAL system consists of a target user, body sen-sor network[47], and other ambient devices belonging to the typeof observation and monitoring required for the user, the home en-

vironment of the user, a central workstation for capturing sensordata to send it in the cloud, and the software services running onthe cell phones, smart devices, and workstations. The completesetup depends on available devices and the type of running ser-vices. Each AAL system has a unique identifier in the CoCaMAALstructure to identify it in the generalized cloud architecture. What-ever the requirement is, the objective here is to generate a uniquemodel for context representation.

Table 2shows some examples of typical body sensors. Thesekinds of sensors together form a body sensor network (BSN)[48,49]. These sensors have some key configurations and infras-tructure that make them easilyimplantable or wearable on the hu-manbody (Fig.2). Some sensors canbe implantedin thegarment ofthe user; these are known as wearable textile sensors. These sen-

sors have lowpower, arecapable of communicating wirelessly, andmonitor thehealth andactivityof the target user. We want to elim-inate thecomputational burdenfrom these sensors so that they canperform their task for longer periods and more quickly.

Body sensors measure the users body and activity-related in-formation. To detect other conditions of the environment someenvironmental devices, ambient sensors, smart sensors, and com-munication devices are also deployed in AAL systems (Fig. 3).

The wearable sensors and ambient devices have appropriatewireless or wired connectivity to a local workstation (LW) in theAAL environment. The LW is responsible for collecting sensor datausing suitable communication protocols and forwarding them tothe cloud infrastructure. Body sensors and other devices collectmedical data regarding the status of the user. For example, wear-

able sensors communicate using Bluetooth to a mobile phone orusing Zigbeeto a PDA which thenforwardsthe datato the LWusingWiFi (Fig. 4). Even sensors can directly send data to the LW usingBluetooth. The communication depends on the availability of asuitable communication medium between the pairs. As an exam-ple, a more power consuming device like a monitor is connectedusing the local area network, cameras are connected using USBconnections, and so on.

Each sensor and device has a unique identifier in the local sys-tem so that the LW can distinguish between incoming data fromdifferent sensors and devices. A data collector program in the LWperiodically collects sensor data. The program then passes the col-lected sample with device information to the cloud gateway usingan optimized sampling rate. Every device sample contains a com-

plete set of information. Finally, the collected data are uploaded to


5/14


Fig. 2. (a) A demonstration of wearable body sensors on a human body. (b) A conceptual BSN architecture of the proposed AAL system. (c) An example of wearable textile

sensors.

Fig. 3. There aredifferent types of ambient deviceand white goods areinstalled in

AALsystem includingBSN that generate valuable context. Some sampledevices areillustrated in here.

Fig.4. Data acquisition: The raw sensor data produced bybody sensors and other

devices aretransmittedto a local workstation using a connectedmedium. Thelocalworkstation then forwards the data to the cloud server using a cloud gateway.

the cloud servers using a cloud gateway. Fig. 5illustrates the ab-stract system architecture of our framework for a single AAL sys-tem. Simple and lightweight communication protocols (such as aweb service call) are utilized for transmitting data to the context

aggregator cloud.

5.2. Context providers and aggregator cloud

5.2.1. Context providers

The responsibility of context providers is to convert the sen-sor data into context. The amount of information that can becategorized as a context in AAL system is an extremely large set.Several levels of data abstraction are required to get the exact con-text value. Moreover, different feature selection techniques are re-quired for different sensor data. For example, classifying a usersactivity from accelerometer data and classifying a users heart con-dition using an ECG sensor cannot be solved using the same classi-fier. That is whyour systemhas a large numberof context providerswhich run their own feature selection, classification, and fusion al-gorithm to find the context.

Any classification problem which has a large input set is com-putationally expensive. The system needs to be properly trained toextract the features for classification. Existing healthcare systemsuse local servers to solve specific classification problems such asuser activity recognition, fall detection, and health monitoring. Anefficient classifier requires huge data storage and memory to ef-fectively find the features. If we can utilize the cloud platform forsuch computation then this will minimize the burden from the lo-cal servers. Each of the context providers in our system runs as acloud service which collects rawsample data as input andrespondsback with classification output using a SOAP-based web service.The context providers are distributed in the cloud structure. Thereare several classifiers used in context-aware computing for classi-fying sensor data: ANN, naive Bayes classifier, K-means clustering,HMM, C.5 Decision Trees, and others[50,51]. When the classifica-tion is unknown, unsupervised learning is used. Sometimes fusionis required to obtain an overall classification result. The contextprovider uses the best classification technique for identifying thecontext.Fig. 6shows the general flows performed by a classifier ofthe context provider cloud. In our model, many context providerscan be integrated easily.

5.2.2. Context aggregator

The context aggregator is the main collaborator of our model.It combines the data that arrive from different AAL systems. Theaggregator has computational logic for context integration andinterpretation. It is a distributed cloud service and responsible forthe following operations of the system.

Collect incoming sensor data from various AAL systems.


6/14


Fig. 5. Data flow in a single AAL: Raw data from the AAL system is converted to context by the aggregator cloud. The service provider cloud contains the cloud storage for

the service rules. The context-aware middleware cloud manages incoming context and finds assistive actions. Then it responds back to the AAL system as a context-aware

service.

RawSensor

data

Pre-Processing Segmentation Feature

Extraction

Acceptable

Features

Yes

No

Strat and End

Point Detection

Classification

High

Level

Feature

Segmentation Recognition

Fig. 6. Flow diagram of context classifier: All the context providers perform this generic classification process to extract the high-level features. The method inside each

of the square blocks can be different, based on input and output data.

Separate the data for sending it to the respective contextprovider to obtain the context classification.

Track the identification of AAL systems, particular devices ofAAL systems, and context providers.

Collect high-level output as context from different context

providers after the classification process. The same context can be reported by different providers. The

context aggregator resolves conflicts among duplicate data.

If thesame context has differentvalues from differentprovidersthen it performs a performance score calculation through con-text provisioning to pick up the best and most reliable contextvalue.

Aggregate all the context information in a single context modelagainst a particular AAL system.

Send thecontext model to thecontext-aware middleware cloudfor finding context-aware services.

Context providers perform the primary abstraction, and that isfollowed by the reasoning mechanism in the context aggregator

to convert it into suitable information. This is the standard infor-mation that can be recognized by all the entities (sensors, contextproviders, and service providers) of our model. It is required for in-teroperability between data information from sensors and service-providing entities.

5.2.3. Context modeling

A major aim of the research is to find a unified context modelso that any context and context-aware services of AALsystems canbe designed easily using the model. Without a well-defined, clear,and flexible information model, applications will not be able to usesuch information in an efficient way. The model must be rich andflexible enough to accommodate notonly the current facetsof con-text information, but also future requirements and/or changes. The

model is domain independent but it depends on provider services.

Most of the existing context models focus on special aspects,whereas we focus on generalized model design which can easecontext-aware service composition in assisted living.

The context model is an organized structure that is formed bythe aggregator cloud after identification of the key contexts. It de-

fines the context information that is storable in a data source, re-trievable using simple query, and transmittable using a suitableformat. It contains a list of topics with respective attributes. Thetopics are structured hierarchically. The context model is also asuitable place to specify which context informationis transientandwhich is persistent. The context model only needs to be evolved ifnew context information is processed by the system, e.g. when anew sensing device is added or eliminated.

In our architecture, we adopted the ontology-based contextmodel [52,53] because it is one of the well-accepted contextmodels for ambient intelligent (AmI) systems. Fig. 7 shows theproposed ontology-based context model based on OWL (web on-tology language). The context space is described in four major en-tities.

Personontology is used to identify the user of the AAL systemand his/her profile, diseases, health conditions, doctors, socialinteractions, and so on.

Placeontology describes the current position of the user. Environment ontology is used to identify the conditions of

surrounding environments. Environment has some impact formaking decisions for assistive actions.

Device ontology contains the details of the body sensors anddevices of the system.

This kind of abstraction described above is easily extendableand modifiable. Using this model it is easy to derive new knowl-edge about the current context and to detect any inconsistencyin the context data. Ontology makes reasoning tasks simple. Themodel is also helpful for service providers to define rules for ser-

vices. Moreover, it is convertible to XML in the implementation


7/14


Fig. 7. Context model using OWL. Each context entity has some attributes to describe some basic properties of the entity. Some context entities are part of parent entity

such as characteristics, diseases, preference, social and health ontologies are part of person ontology. Each of those entities has some more children to describe them. The

relation among different entities is also shown here.

Table 3

Service rules of detecting a possible heart attack.

Ontology Instance Raw data Context attr. ValuePerson User X Profile Age 65

Person User X Profile Weight 80

Person Disease Profile Cardiac patient Have cardiac issue

Device ECG sensor ECG wave Heart rate Abnormal

Device BP sensor BP readings Blood pressure Normalorhigh

Device PPG sensor Sensor readings O2consumption LowDevice Audio sensor Sound wave Breathing Irregular

Device Camera, radar,

accelerometer

Video, images, 3D acceleration,

motion path

Motion Trippingorfallingorflailing of

armsorany rapid motion

Table 4

Example of some assistive services, their rules, and the provider of the service.

Service type Rules Providers

Autonomic (energy saving) (?user status: sleeping) (?room light status: on) ACTION: turn off light Power saver

Software (medicationreminder)

(?local time: 5:00 PM) (?medicineYtime: true) ACTION: pop-up mobile app for medicationreminder

Software application

Comfort (search friend) (?location: study room) (?Personal Laptop: on) ACTION: speaker suggest using voice to use site

Xfor finding

Social context providers

Emergency (fall detection) (?user status: lying down) (?fall detector status: on) ACTION: alert emergency assistance Emergency service provider

Symptom detection (?skintemperature:high) (?breathing: abnormal) ACTION: fever detected.Alertpersonaldoctor. Personal doctor

level. XML is a flexible and platform-independent tool that can beused in different stages of information representation. It is alsosuitable for SOAP-based communication.

5.3. Service providers cloud

SPs contain the cloud repository of different kinds of service. Inour model, service providers (Fig. 5)subscribe to a context-awaremiddleware cloud structure and provide service rules using thecontext model which is deployed in the cloud structure. It can be asoftware service which is deployed in thecloud(SaaS) or theinfras-tructure for delivering services (IaaS). The services are describedin the rule-based model using our ontology abstraction. Inside therules of SPs the list of assistive actions that are required for ob-servedconditions are integratedalso. SPs hold this information anddeliver it to the context manager on request by means of the cloudservice. Some typical examples of services in AAL systems includesoftware service, emergency assistance service, autonomic service,comfort service, and symptom detection service.

The same types of service can be different for different patients.The treatment of the same disease for a cardiac patient and for adiabetes patient will not be same. More importantly, services are

implemented by different service providers and they are large in

number. So, it is almost impossible to deploy and install all the ser-vices in a single machine. If all services are deployed in the cloudthere will not be any problem of resources. Besides, if all the ser-vices can be described using a unique model then it will make theservice-mapping task easier.

Table 3shows the service rules of detecting a possible heartattack by using our ontology model. SPs can easily add or mod-ify a rule using the simple query mechanism. In this way, one ofseveral distributed service providers can offer their services us-ing our cloud model. If a context sample contains such a patternas described in Table 3 and the CMS of our model detects this,then it picks the assistive actions described for this service fromthe providers data storage. The consequences of the events hap-pen locally inside the AAL system but the actions are mentioned inthe assistive response.

There aredifferent AALplatformsfor generating services,for ex-ample, OpenAAL [54]. OpenAAL is a framework that supports inte-gration and communicationsbetween AAL services using ontology.The rules of some context-aware services are presented inTable 4.The rules are stored inside the service cloud and retrieved using anappropriate service provisioning mechanism [55]. Once a servicerule is retrieved it can be easily described by our four-entity-based

context model with assistive actions.


8/14


Fig. 8. Dynamic scalability of distributed CMS: A snapshot of how the CMS of CoCaMAAL works.

5.4. Context-aware middleware (CaM)

The high-level context model that is prepared by the contextaggregator cloud is forwarded to the context-aware middleware(CaM) cloud for the final output, which is context-aware services.

As input data the CaM takes context from the CAP cloud andservices from the SP cloud. It stores the context which is requiredfor future use. Then, utilizing existing knowledge and incomingcontext, the CaM identifies assistive services for the given context.It then immediately transmits the context-aware actions to theassociated AAL system. The context-aware cloud acts as a decisionsupport system for the whole model.

5.4.1. Context management system (CMS)

A context management system (CMS) interacts with differentdistributed components and binds the operations of each individ-ual component together in the CaM cloud. The context manager(CM) contains the repository of context that is gathered from dif-

ferent AAL systems by adopting the IaaS properties of cloud com-puting. IaaS encompasses the storage, computing, and network forthe CMS. The CMS is the main component of our SOA where themedical information of the AAL user is stored, analyzed, and ac-cessed. The CMS dynamically scales the storage resources via ondemand provisioning. It is in charge of handling requests from AALsystems via the aggregator cloud from where it obtains context in-formation andrelates thecontextswith services defined by theSPs.Since it contains sensitive medical information, it maintains differ-ent public and private clouds for storing and accessing data.

The CMS applies intelligent matching criteria to find the as-sistive actions for the current context. The CM is self-adaptive innature. It measures the performance to detect the best possibleassistive actions for a context sample.

5.4.2. Context storing

A distributed cloud repository ensures the persistency of con-text information(Fig. 8). It contains up-to-date data and relevantcontext of the AAL user. The CMS stores context as an expandableknowledge base of ontologies (described previously). All the at-tributes are stored as keyvalue pairs in different ontology con-tainers, which simplifies querying the instantiations. Each of theAAL systems has a unique id, and all the devices in an AAL systemalso have some specific id to differentiate between incoming con-text data.

To help the monitoring service, it is useful to store recent con-text and to retain previously received context. Rarely used and oldcontext is removed. An efficient access control [44] mechanism is

used for storing and retrieval sensitive data in the cloud.

5.4.3. Context retrieval

The context manager periodically retrieves context for an AALsystem via the context aggregator. The context information requestis triggered by the context manager itself periodically. Third-partyproviders, monitoring services, and social networking services can

also initiate context requests from storage. Any component canrequest context from the context manager through a web servicerunning in the cloud server with an AAL system id and an attributeset of context. After filtering the duplicate and unwanted context,a service in the CMS retrieves related information and returns themost relevant and accurate information.

5.4.4. Context manipulation

Most of the context manipulation is done inside the CAP cloud.Insidethe CMSa context transformer impacts on changes of certaininformation. For instance, body temperature expressed in C scalecan be transferred to the F scale using the mathematical transfor-mation rule.In addition,the CMS performs context derivation taskssuch as finding a city from longitude and latitude information. Thecontext manipulator also requests missing context from the AALsystem via the context aggregator when required, and combinesthat context with retrieved information.

5.4.5. Service mapping

The most important role of the context manager is to mapcontext data to a respective service so that it can find the assistiveactions to accomplish those services. The context model that isgenerated by our proposed ontology can be converted to an XMLlike Listing 1 with attribute values. A service profile also can bedescribed using a similar XML structure, as shown in Listing 2. TheCMS matches the context with possible services by comparing thevalue and calculating the weighted score matrix of the possiblematch. It then picks the best possible matches and combines themin assistive actions. Both the context model and the service model

can be represented in a tree structure like that shown in Fig. 9.The root of the tree in level 0 is context. In level 1 there should

be four main entity nodes: person, environment, place, and device.The value nodes are located in the lowest levels that have no childnode. The problem is to find the list of similar paths in the contexttree which is the list of services described in the service trees.

Let the CM have the knowledge base ofMservices in the ser-vice repository.CTis the context tree for current context data and{ST1, ST2, . . . , STi, . . . , STM} are the context trees for M services{S1, S2, . . . , Si, . . . , SM}. Our matching criterion is, if any subtree isfound inCTwhich is exactly or very similar to tree STi, thenSiis acontext-aware service for contextC. So, the action item describedin the structure ofSi is picked which is the assistive action for Si.The matching operation is performed for all the Mtrees and all theactions are combined in a single XML structure. Then the CMS re-

sponds back to the AAL system with the action list.


9/14


Fig. 9. Context tree: Every context sample and service of our system is converted to such a context tree to find the service mapping.

NS CT is the list of nodes and ES CT is the list of edges.Similarly,S STi = (NSSTi, ESSTi )is a subtree ofSTi. To find the

similarity betweenS CT andS STi , we first need to find thesimilarity between the root nodes ofS CTandS STiand thenprogress through the nodes of the subtree up to child nodes recur-sively. At the lowest level of the tree the matching algorithm justmatches the higher-level context values.

Listing 1: A snippet of context XML

2012-11-08T12:23:56+11:002012-11-08T23:21:56+11:00

AliceMale68

HighNormal

cardiacalzheimer

Bed Room

25 C < /temparature>40%

activeoff

normal

normal

walking

The similarity between two nodes NCTx in tree CT andNSTiy in

treeSTiisw = sim(NCTx , NSTiy), 0 w 1

w = 1, if nodes are exactly similar, i.e.: any parent node.w = 0, if nodes are not similar, i.e.: mismatch in name or value.

For any parent node, sim(NCTx , NSTiy) = sim (tag name ofNCTxandNSTiy ).

Listing 2: An example of service XML

Detect possible heart attack

HighAbnormalLow

cardiac

Talk With user

Turn on MonitorTurn on SpeakerTurn on MIC

So,w is either 0 or 1. Ifw = 0 for any parent node then thatsubtree is skipped from the matching. For the child node the wvalue is between 0 and 1.w is between 0 and 1, when child nodevalue is numeric and numerical comparison is performed betweennode value.

So, ifSTihasznodes which are exactly similar or nearly similar

toCT then the similarity matrix ofSTi is WSTi =

wSTi1wSTi2. . .

wSTiz

, where

1 i M.Amongtheznodes letp nodes be child nodes andthe remaining

zp nodes be parent nodes. Since all parent node similarity valuesare 1, we consider only child nodes for calculating the score matrixofWSTi : scoreWSTi

=p

j=1wSTij . The score matrix of all services is

scoreS=

scoreST1scoreST2

. . .

scoreSTp

.

Therefore, the CMS picks the services and related actions with

good score values.


10/14


Fig. 10. Evaluation: The experimental setup of simulated model for evaluating the case studies described in this section.

5.4.6. Self-adaptation

When the CMS calculates the similarities between context andservice structure, it can identify a set of actions and enrich theknowledgebase by storing this information inside the cloud repos-itory. When the same pattern in the context is detected, it isthen able to respond faster than before. Furthermore, when anyproviders update their information, the CMS synchronizes the

database accordingly. Because a change in service means a changein the service context tree. The CM needs to recalculate the scoreof service for a context sample.

As an example, from AAL1, the CMS has identified a list of ser-vices {S1, S2, . . . , Sn} and corresponding actions {A1,A2, . . . ,An}for a context tree CT1 and stored that information in the con-text cloud repository. Now if the same context tree appears from

AAL1 then without performing mapping theCM delivers theactionsfrom its past knowledge. If another AAL systemAAL2requests ser-vices with context treeCT2, similar toCT1, then the CMS can easilypick the actions required for CT2and deliver it without performingadditional mapping. As a result, the CMS can acknowledge fasterby self-adaptation.

5.4.7. Service discovery

Not all the assistive actions are described by the serviceproviders. In some cases the CMS builds compound services from acomposition of existing services.This is known as service discoveryin the system.

5.4.8. Security service

The health-related context that is collected, processed, andmanaged inside the cloud is sensitive. The security service insidetheCMS will ensurethe privacy of context information that is gath-ered from different AAL systems. Different solutions are proposedto protect personal health information [9,56,57] in distributedcloud environments that ensure the privacy of the services.Context-aware role-based access control and a privacy-preservingcontext service protocol [56] can be adopted to ensure the privacy

of context information in our model.

5.5. Monitoring and data visualization service

Inside the CaM every action is event driven but also requiresmanual tracking in some cases. In CoCaMAAL we suggest differentkinds of web interface for managing context-aware middleware.These kinds of interface are essential to store and retrieve context.Other data visualization interfaces parse the context and present it

in a visual interpretation. Also these medical data can be publishedin a social network of doctors. Thus, doctors have an up-to-datehealth status of patients. We believe that such type of monitoringservices are easily adoptable in our model. But the in-depthanalysis of such services is beyond the scope of this paper.

6. Case study

The major objectives for building the system described in thispaper are as follows.

Detect current situational information of an elderly user underassisted living from various context sources.

Aggregate the information in a meaningful context model. Manage the context in a distributed cloud environment.

Find related services from service providers depending on thecontext to assist the user.

In accordance to the CoCaMAAL functional components de-scribed in the previous section, we have developed a simulatedprototype, implemented mostly in Java, to show the feasibility ofthe proposed model. Theelements of this simulatedmodel arepre-sented inFig. 10and the setup of the home domain is described inTable 5.

We have synthesized numerical values from realistic observa-tion of medical data (e.g., heart rate is 65). The generated valuesrepresent raw data from the ECG, PPG, and BP sensors and the ac-celerometer. Four rule-based classifiers are developed as contextproviders (as in 10) to classify those numerical values to high-level context (e.g., user activity is sleeping[58], heart rate is high).

All the data are aggregated using our Java-implemented context


11/14


Table 5

The components considered in the experimental setup of the simulated prototype.

User locations Living room, bathroom, kitchen

Body sensor network ECG sensor, PPG sensor, BP sensor, accelerometer,

RF tags

Devices of living room RFIDs, camera, Mic, speaker, TV, emergency alarm

Devices of bath room RFIDs, Mic, speaker

Devices of kitchen RFIDs, Mic, speaker

aggregator, and finally the context model is generated using thesuggested ontology.

We have randomly generated 3000 samples for a single-userscenario considering a sampling rate of 10 min. Each sample con-tains different physiological parameters, current activity, time, andlocation of the user. A piece of such sample data is presented inTable 6.User-specific information (i.e., medication time, disease,age, etc.) is stored in a MySql database. We also created 10 serviceproviders (sp1, sp2, . . . , sp10) and distributed 67 different fuzzyrules amongthem.The rules arestored in XMLfiles(as in Listings 2)including the list of possible actions for context matching. Log en-tries of unusual events (i.e., user has not taken medicine in time)are created with timestamps in the database and kept as context

history. Every single sample (as inTable 6)is processed inside theCMS one by one. After the rule matching and service mapping pro-cess described in Section5.4.5,the CMS selects the best possibleservices from multiple SPs.

We used Java for prototyping andGoogle AppEngine(GAE) [59]for evaluating the cloud infrastructure. GAE is an open-sourcecloud computing platform for developing and hosting applicationsin Google-managed data centers.Table 7summaries the differentsoftware tools we used to simulate the components of the CoCa-MAAL model and to examine the following case studies.

Case study11. The AAL system generates featured context of the user as

described inTable 6.2. A sudden observation contains abnormal values (No 2 of

Table 6).3. From extracted information in the profile database, disease

context is also included (i.e., cardiac disease and hyperten-sion) in the information.

4. After the rule matching step the CMS finds 21 servicesstored in different service providers.

5. The CMS picks the best possible services (using thetechnique stated in Section5.4.5).

6. The CMS reports heart attack symptom as a detected service.From the location and activity context the CMS detects thatthe user is sitting in the living room (No 2 of Table 6),and according to the setup of the domain the living roomcontains a speaker, microphone, and TV monitor(Table 5)for communication. So, the CMS appends communicate userwith voice as assistive actions in the response. This responseis converted to XML and sent to the tomcat server running

inside the AAL system as a SOAP response.7. The server receives the response and sends the appropriate

command to turn on the monitor and speaker (in the sim-ulated model a flag is set in the class object of the device).

8. The voice conversation with user is a questionanswer ses-sion. The questions are picked from the service providersand appended at the time of generating the service re-sponse. A sample question is Are you feeling chestpain? [60].

9. The recorded conversation (as voice or video) is sent tothe context aggregator to obtain more specific context likeChest pain is true. (In the case of the simulated environmentit selects a random answer.)

10. The CMS runs another service mapping with new context

(Chest pain) and picks new service actions based on thecontext value. (For chest pain true value it picks the servicerisk of heart attack.)

Case study21. The CMS receives the context generated in step 3 of case

study 1 and requests some more context like taking medi-cine activity for the day from the context history database.

2. The RF reader of the living room tracks users medication[61,62]. If the user does not take medicine in time the sys-tem logs this event in the context history from the status ofthe RF reader. In our experiment, the CMS detects this eventfrom a retrieved entry in the database. So, after rule mappingit picks medication reminder service and as an assistive actionit reminds the user to take his/her medicine properly.

Case study3

1. As in sample 5 ofTable 6from context the CMS detects thatusers physical condition is not good and that he/she hasfallen down in the bathroom [63,64].

2. The CMS identifies the situation as Emergency Servicefrom service mapping. As assistive action it notifies theserver to ring the emergency alarm in the house so a nearbyneighbor can come to help and it also sends an automatedemergency alert to doctor (using sms).

Table 6

Aggregated high-level context samples.

No Time Heart rate O2 saturation Blood pressure Location Activity

1 23:10:12 Normal Normal Normal Living room Watching TV

2 10:11:45 High Low High Living room Sitting

3 09:42:78 High Normal Normal Living room Excessing4 01:43:21 Normal Normal Normal Living room Taking medicine

5 05:22:34 High Low High Bath room Fallen down

6 19:17:28 Normal Normal Normal Kitchen Cooking

Table 7

Components developed for simulated prototype.

Model component Simulated components Development platform Output format

Wearable sensors Java servlet as nu merical data generator Java thread i n tomcat server Data files

Data collector Java servlet Java thread in tomcat server Data files

Context providers Java program running in GAE API using GAE High-level context

Context ontology OWL GAE data source for ontology containers Context model

Context aggregator Java program running in GAE API using GAE Context model as XML CM repository Static database GAE data source Database records

Service providers Static XML in different web servers GAE web server Simple service rules with actions

Service mapper Java program running in GAE API using GAE List of assistive actions as XML


12/14


Table 8

Average service response time for different context, service provider (SPs), and service load.

Item Context domain Number of contexts Number of SPs Number of services Tresponse(ms)

1 Physical parameters 4 1 10 18

2 1 and activity, location, time 7 3 21 21

3 2 and environment 11 5 35 23

4 3 and user profile 14 7 43 28

5 4 and context history 16 8 54 30

6 5 and device status 21 10 67 31

Note that in thesecond columnof item 2, 1 and activity refers to activity, location and time including physical parameters of row 1, and soon

for other rows.

Table 9

General distribution of service time of five different sets for k = 10 and = 2 s.

Set Siin % andTiin ms W

S1 Si 22 17 14 12 9 8 6 5 4 3 0.062 0.0326

Ti 20 10 15 30 80 45 18 50 90 40

S2 Si 28 20 11 11 10 7 5 5 2 1 0.060 0.0311

Ti 38 20 25 15 40 21 27 35 85 70

S3 Si 25 19 14 12 10 6 6 4 2 2 0.062 0.0325

Ti 12 30 28 55 62 40 10 17 29 72

S4

Si 21 18 16 10 9 9 8 5 3 1

0.060 0.0315Ti 12 40 55 15 10 20 50 35 25 95

S5 Si 22 15 12 12 10 7 7 6 6 3 0.062 0.0324

Ti 33 21 12 16 40 55 42 44 24 82

7. Experimental results

We first evaluated the model for a single AAL system withdifferentcontext andservice load. Foreach of thecases, theaverageservice response time (Tresponse) is calculated. The time starts whenraw data are sent to the CoCaMAAL aggregator cloud from the localserver and ends when the AAL system gets a service response.So,Tresponseincludes the context processing time, service mappingtime, and service delivery time.Tresponseis measured by increasingthe number of context sources, service providers, and services. Theresult is shown inTable 8.We also measured the service mappingaccuracy to ensure that the system is picking the correct servicesfora scenario.To compute theaccuracy, we compared theobservedresults with expected services andmade a true/false decision forit.For 21 contexts with 67 services in 10 service providers and 3000samples the measured accuracy was 96.34%.

The above results prove the benefit of the CoCaMAAL model interms ofselecting the correct services for a given context in a shorttime.

To measure the performance of the CoCaMAAL model with alarge number of AAL systems we adopted M/G/1queuing systemwith FCFS[65].In M/G/1, the inter-arrival time of requests is expo-nentially distributed, the service time is generally distributed, and

the total number of processing servers is 1. The model is presentedinFig. 11.The model can be extended to an M/G/cqueuing sys-tem [66]. Computation ofM/G/cis very complex and beyond thescope of this paper. For the sake of simplicity, here the whole Co-CaMAAL model is considered as a single ultra-fast processing unitof an M/G/1 model to serve n AAL systems. So, here the number ofprocessing servers c= 1, andthe processing ofk different requestsis distributed inkdifferent nodes of this very ultra-fast processingserver. Our goal is to find the mean response time of a request.

If the number of requests from n AAL systems is 120/min thenthe service request rate is a Poisson process with mean = 120

60 =

2 requests/s.

The service response time depends on the size, type, and valueof the context. Here, the service time is generally distributed with

mean 1 s and variance2.

Fig. 11. TheM/G/1 queuing system of the CoCaMAAL model.

The average service time to process a request is

1

= E[S] =

ki=1

SiTi, (1)

whereSi% requests are processed in Tis andkis the number of re-

quest types. The variance2 = E[s2] (E[s])2. In our evaluation,we considered ten request types. So, here, k = 10 and for Si% re-quests, services are selected from the context with overall mean

processing time (inside CoCaMAAL)Tims. The distribution for fivedifferent configurations (fork = 10) are presented inTable 9.Theprocessing of the request containing large data (i.e., image) takes

a longer time than the processing time of the sensor data (i.e., ac-celerometer data). So, inTable 9,different percentages of the re-quests have different processing times. For example, in the case of

S1 we have the following.

Using Eq.(1),we got 1= E[S] = 31 ms = 0.031 s.

Variance2 = E[s2] (E[s])2 = 0.000538 s2.

Utilization = = 2 0.031 = 0.062.


13/14


Fig. 12. The average response time (W) varies with the distribution of service

time in different processing nodes for different observations. Using only a single

ultra-fastserver with k processing slots, the average response time (using the same

arrival rate) is very low for each observation. For k 5, the response time of each

observation is very similar.

Fig. 13. (a) Using the lower value of the request arrival rate (). (b)is high. That

is, requests are arriving in high volume from a massive number of AAL systems.

For both (a) and (b) the average response time (W) increases with the increase of

request arrivals. The response time is still very fast (only 0.11 s) even with a high

request arrival rate ( = 60).

According to the PollaczekKhinchine formula [65], we obtainthe following.

Average number of requestsL = + 2+22

2(1) = 0.0652.

Average response time of a request W= L= 0.0326 s.

The and Wvalues for each of the cases are presented in

Table 9.We found that the service response is much faster in theCoCaMAAL model with a large number of requests when they areserved by a ultra-fast processing unit running on a cloud.

We also evaluatedthe model by varying k and , and the resultsare given inFigs. 12 and13. From the obtained results we findthat the CoCaMAAL model responds much faster with good servicerecognition accuracy even for a large number of AAL systems.

8. Conclusion and future works

In this work, we have presented a generic architecture to sup-port BSN-integrated ambient assisted living (AAL) environmentswith context-aware service management systems using cloudcomputing infrastructure. We believe that the proposed model is

a complete framework to support distributed features of contextawareness in AAL. We started by describing the limitations of ex-isting systems and the challenges that AAL users and healthcareprofessionals are facing in the traditional computing model. Oursystem analyzed the issues related to scalability, cost, and supportof heterogeneous services using a single model. We suggested theneed fora suitable context modelfor theAAL systemwhichis easilymodifiable, reusable, adaptable, and extendable. We demonstratedour model by describing the setup and the major functionalities ofthe components and their communication standards.

As part of our ongoing work, we are working on the robust im-plementation of each of the components of the model. We are alsoworking on in-depth performance and accuracy measurements ofthe system. We ignored issues related to noise reduction in sen-sor data, conflicts in context, implementation of security and pri-

vacy, and reliability analysis. Also, we have not considered much

involvement of the virtual world, social networking, and monitor-ingsystems.So, as part of ourfuture work, we areaiming to includethese features.

Acknowledgments

The authors wish to acknowledge the support of NICTA (Na-tional ICT Australia) of Victoria Research Lab for funding the

research work presented in this paper. NICTA is funded by the Aus-tralian Government as represented by the Department of Broad-band, Communicationsand the Digital Economy and the AustralianResearch Council through the ICT Centre of Excellence program.

References

[1] T. Kleinberger, M. Becker, E. Ras, A. Holzinger, P. Mller, Ambient intelligencein assisted living: enable elderly people to handle future interfaces,in: Universal Access in HumanComputer Interaction. Ambient Interaction,2007, pp. 103112.

[2] J. Ye, S. Dobson, S. McKeever, Situation identification techniques in pervasivecomputing: a review, Pervasive and Mobile Computing 8 (2012) 3666.

[3] S. Kern, D. Jaron, Healthcare technology, economics, and policy: an evolvingbalance,in: IEEE Engineering in Medicine andBiology Magazine: theQuarterlyMagazineof theEngineering inMedicine& Biology Society,Vol.22, 2003,p. 16.

[4] F. Sufi, I. Khalil, Z. Tari, A cardiod based technique to identify cardiovasculardiseases usingmobile phones and bodysensors, in: 2010 Annual InternationalConference of the IEEE Engineering in Medicine and Biology Society, EMBC,IEEE, pp. 55005503.

[5] P. Remagnino, G. Foresti, Ambient intelligence: a new multidisciplinaryparadigm,IEEE Transactions onSystems,Man andCybernetics,Part A: SystemsandHumans 35 (2005) 16.

[6] A. Schmidt, Interactive context-aware systems interacting with ambientintelligence, Ambient Intelligence (2005) 159178.

[7] A. Dey, Understanding and usingcontext, Personal and Ubiquitous Computing5 (2001) 47.

[8] R. Buyya, C. Yeo, S. Venugopal, J. Broberg, I. Brandic, Cloud computing andemerging it platforms: vision, hype, and reality for delivering computing asthe5th utility, Future Generation Computer Systems 25 (2009) 599616.

[9] D. Hoang, L. Chen, Mobile cloud for assistive healthcare (mocash), in: 2010IEEE Asia-Pacific Services Computing Conference, APSCC, IEEE, pp. 325332.

[10] F. Azzedin, M. Eltoweissy, S. Khwaja, Overview of service oriented architec-ture for resource management in P2P systems, in: The Handbook of ResearchonP2P and Grid Systems for Service-Oriented Computing: Models, Method-ologies and Applications, 2009.

[11] P. Emiliani, C. Stephanidis, Universal access to ambient intelligence environ-ments: opportunities and challengesfor people with disabilities, IBM SystemsJournal 44 (2005) 605619.

[12] K. Johnson, A. Bamer, K. Yorkston, D. Amtmann, Use of cognitive aids andother assistive technology by individuals with multiple sclerosis, DisabilityandRehabilitation: Assistive Technology 4 (2009) 18.

[13] F. Zhou, J. Jiao,S. Chen,D. Zhang, A case-drivenambientintelligence systemforelderly in-home assistance applications, IEEE Transactions on Systems, Man,andCybernetics, Part C: Applications and Reviews (2010) 111.

[14] T. Taleb, D. Bottazzi, M. Guizani, H. Nait-Charif, Angelah: a framework forassisting elders at home, IEEE Journal on Selected Areas in Communications27(2009) 480494.

[15] F. Paganelli, E. Spinicci, D. Giuli, Ermhan: a context-aware service platform tosupport continuous care networks for home-based assistance, InternationalJournal of Telemedicine and Applications 2008 (2008) 4.

[16] K. Cho, I. Hwang, S. Kang, B. Kim, J. Lee, S. Lee, S. Park, J. Song, Y. Rhee,HiCon: a hierarchical context monitoring and composition framework for

next-generation context-aware services, IEEE Network 22 (2008) 3442.[17] J. Hong, E. Suh, S. Kim, Context-aware systems: a literature review and

classification, Expert Systems with Applications 36 (2009) 85098522.[18] T. Gu, H. Pung, D. Zhang, Toward an osgi-based infrastructure for context-

aware applications, IEEE Pervasive Computing 3 (2004) 6674.[19] S. Baek, E. Choi, J. Huh, K. Park, Sensor information management mechanism

for context-aware service in ubiquitoushome, IEEE Transactions on ConsumerElectronics 53 (2007) 13931400.

[20] H. Viswanathan, B. Chen, D. Pompili, Research challenges in computation,communication, and context awareness for ubiquitous healthcare, IEEECommunications Magazine 50 (2012) 9299.

[21] J. Bardram, Thejava context awarenessframework (JCAF)a service infrastruc-ture and programming framework for context-aware applications, PervasiveComputing (2005) 98115.

[22] N. Behlouli, C. Taconet, G. Bernard, An architecture for supporting develop-ment and execution of context-aware component applications, in: ICPS06:IEEE International Conference on Pervasive Services 2006, pp. 5766.

[23] S. Yau, F. Karim, Y. Wang, B. Wang, S. Gupta, Reconfigurable context-sensitivemiddleware for pervasive computing, IEEE Pervasive Computing 1 (2002)3340.
http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref1http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref1http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref1http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref1http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref2http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref2http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref3http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref3http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref3http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref5http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref5http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref5http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref6http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref6http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref7http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref7http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref8http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref8http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref8http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref10http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref10http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref10http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref10http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref11http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref11http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref11http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref12http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref12http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref12http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref13http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref13http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref13http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref14http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref14http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref14http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref15http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref15http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref15http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref16http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref16http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref16http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref17http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref17http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref18http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref18http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref19http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref19http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref19http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref20http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref20http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref20http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref21http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref21http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref21http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref23http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref23http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref23http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref23http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref21http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref20http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref19http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref18http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref17http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref16http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref15http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref14http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref13http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref12http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref11http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref10http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref8http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref7http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref6http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref5http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref3http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref2http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref1


14/14


[24] Y. Oh, J. Han, W. Woo, A context management architecture for large-scalesmart environments, IEEE Communications Magazine 48 (2010) 118126.

[25] W. Kurschl, S. Mitsch, J. Schoenboeck, Modeling situation-aware ambientassisted living systems for eldercare, in: Sixth International Conference on In-formationTechnology: New Generations, 2009,ITNG09, IEEE,pp. 12141219.

[26] K. Henricksen, J. Indulska, A. Rakotonirainy, Modeling context information inpervasive computing systems, Pervasive Computing (2002) 79117.

[27] D. Bottazzi, A. Corradi, R. Montanari, Context-aware middleware solutionsfor anytime and anywhere emergency assistance to elderly people, IEEECommunications Magazine 44 (2006) 8290.

[28] G. Van Den Broek, F. Cavallo, C. Wehrmann, AALIANCE Ambient AssistedLivingRoadmap, Vol. 6, IOS Press Inc., 2010.[29] M. Amoretti,S. Copelli, F. Wientapper, F. Furfari, S. Lenzi, S. Chessa, Sensor data

fusion for activity monitoring in the persona ambient assisted living project,Journal of Ambient Intelligence and Humanized Computing (2011) 118.

[30] R. Woolrych, A. Sixsmith, Challenges of user-centred research in thedevelopment of ambient assisted living systems, in: Impact Analysis ofSolutions for Chronic Disease Prevention and Management, 2012, pp. 18.

[31] Q. Wang, W. Shin, X. Liu, Z. Zeng, C. Oh, B. AlShebli, M. Caccamo, C. Gunter,E. Gunter, J. Hou, et al.I-living: an open systemarchitecture forassisted living,in: IEEE International Conference on Systems, Man and Cybernetics, 2006,SMC06, Vol. 5, IEEE, pp. 42684275.

[32] Amigo, Amigo: ambient intelligence for the networked home environment,2008.

[33] E. Badidi, L. Esmahi, A cloud-based approach for context information provi-sioning, 2011. Arxiv PreprintarXiv:1105.2213.

[34] A. Gill, D. Bunker, Conceptualization of a context aware cloud adapta-tion (CACA) framework, in: 2011 IEEE Ninth International Conference onDependable, Autonomic and Secure Computing, DASC, IEEE, pp. 760767.

[35] A. Devlic, E. Klintskog, Context retrieval and distribution in a mobile dis-tributed environment, in: Third Workshop on Context Awareness forProactive Systems, CAPS 2007, Guildford, UK.

[36] C. Rolim, F. Koch, C. Westphall, J. Werner, A. Fracalossi, G. Salvador, A cloudcomputing solution for patients data collection in health care institutions,in: Second International Conference on eHealth, Telemedicine, and SocialMedicine, 2010, ETELEMED10, IEEE, pp. 9599.

[37] N. Fernando, S. Loke, W. Rahayu, Mobile cloud computing: a survey, FutureGeneration Computer Systems (2012).

[38] S. Pandey, W. Voorsluys, S. Niu, A. Khandoker, R. Buyya, An autonomiccloud environment for hosting ECG data analysis services, Future GenerationComputer Systems 28 (2012) 147154.

[39] E. Ekonomou, L. Fan, W. Buchanan, C. Thuemmler, An integrated cloud-basedhealthcare infrastructure, in: 2011 IEEE Third International Conference onCloud Computing Technology and Science, CloudCom, IEEE, pp. 532536.

[40] G. Fortino, M. Pathan, G. Di Fatta, BodyCloud: integration of cloud computingand body sensor networks, in: Proc. of IEEE 4th International Conference onCloud Computing Technology and Science (CloudCom 2012), Taipei, Taiwan,

Dec 36, 2012.[41] A. Pantelopoulos, N. Bourbakis, A survey on wearable sensor-based systemsforhealth monitoring and prognosis, IEEE Transactions on Systems, Man, andCybernetics, Part C: Applications and Reviews 40 (2010) 112.

[42] H. Alemdar, C. Ersoy, Wireless sensor networks for healthcare: a survey,Computer Networks 54 (2010) 26882710.

[43] C. Bettini, O. Brdiczka, K. Henricksen, J. Indulska, D. Nicklas, A. Ranganathan,D. Riboni, A survey of context modelling and reasoning techniques, PervasiveandMobile Computing 6 (2010) 161180.

[44] A. Lounis, A. Hadjidj, A. Bouabdallah, Y. Challal, Secure and scalable cloud-based architecture for e-health wireless sensor networks, in: 2012 21stInternational Conference on Computer Communications and Networks,ICCCN, IEEE, pp. 17.

[45] M. Rahman, A. El Saddik, W. Gueaieb, Data visualization: from body sensornetwork to social networks, in: IEEE International Workshop on Robotic andSensors Environments, 2009, ROSE 2009, IEEE, pp. 157162.

[46] K. Laerhoven, H. Gellersen, Y. Malliaris, Long term activity monitoringwith a wearable sensor node, in: International Workshop on Wearable andImplantable Body Sensor Networks, 2006, BSN 2006, IEEE, pp. 4-pp.

[47] G. Fortino, R. Giannantonio, R. Gravina, P. Kuryloski,R. Jafari, Enabling effectiveprogramming and flexible management of efficient body sensor networkapplications, IEEE Transactions on Human-Machine Systems 43 (1) (2013)115133.

[48] C. Otto, A. Milenkovic, C. Sanders,E. Jovanov, Systemarchitectureof a wirelessbody area sensor network for ubiquitous health monitoring, Journal of MobileMultimedia 1 (2006) 307326.

[49] F. Bellifemine, G. Fortino, R. Giannantonio, R. Gravina, A. Guerrieri, M.Sgroi, SPINE: a domain-specific framework for rapid prototyping of WBSNapplications, Software Practice and Experience 41 (3) (2011) 237265.http://dx.doi.org/10.1002/spe.

[50] B. Korel, S. Koo, A survey on context-aware sensing for body sensor networks,Wireless Sensor Network 2 (2010) 571583.

[51] N. Raveendranathan, S. Galzarano, V. Loseu, R. Gravina, R. Giannantonio,M. Sgroi, R. Jafari, G. Fortino, From modeling to implementation of virtualsensors in body sensor networks, IEEE Sensors Journal 12 (2012) 583593.

[52] J. Mochol, P. Sala, C. Fernndez-Llatas, J. Naranjo, Ontology for modelinginteraction in ambient assisted living environments, in: XII MediterraneanConference on Medical and Biological Engineering and Computing 2010,

Springer, pp. 655658.

[53] A. Devaraju, S. Hoh, Ontology-based context modeling for user-centeredcontext-aware services platform, in: International Symposium on Informa-tion Technology, 2008, ITSim 2008, Vol. 2, IEEE, pp. 17.

[54] P. Antonino, D. Schneider, C. Hofmann, E. Nakagawa, Evaluation of aal plat-forms accordingto architecture-basedquality attributes, Ambient Intelligence(2011) 264274.

[55] M. Aslam, S. Rea, D. Pesch, Service provisioning for the WSN cloud, in:2012 IEEE 5th International Conference on Cloud Computing, CLOUD, IEEE,pp. 962969.

[56] X. Huang, Y. He, Y. Hou, L. Li, L. Sun, S. Zhang, Y. Jiang, T. Zhang, Privacy

of value-added context-aware service cloud, in: Cloud Computing, Springer,2009, pp. 547552.[57] M. Nkosi, F. Mekuria, Cloud computing for enhanced mobile health applica-

tions, in: 2010 IEEE Second International Conference on Cloud ComputingTechnology and Science, CloudCom, IEEE, pp. 629633.

[58] L. Wang, T. Gu, H. Chen, X. Tao, J. Lu, Real-time activity recognition in wirelessbody sensor networks: from simple gestures to complex activities, in: 2010IEEE 16th International Conference on Embedded and Real-Time ComputingSystems and Applications, RTCSA, IEEE, pp. 4352.

[59] D. Guermeur, A. Unruh, Google App Engine Java and GWT ApplicationDevelopment:Build Powerful,Scalable,and InteractiveWeb Appsin theCloud,Packt, 2010.

[60] A. Pantelopoulos, N. Bourbakis, A formal language approach for multi-sensorwearable health-monitoring systems, in: 8th IEEE International Conferenceon BioInformatics and BioEngineering, 2008, BIBE 2008, IEEE, pp. 17.

[61] T. Suzuki, Y. Oyama, Y. Nakauchi, Intelligent medicine case system withdistributed rfid readers, in: 2010 Annual International Conference of the IEEEEngineering in Medicine and Biology Society, EMBC, IEEE, pp. 344347.

[62] A. Hristova, A.M. Bernardos, J.R. Casar, Context-aware services for ambient

assisted living: a case-study, in: First International Symposium on AppliedSciences on Biomedical and Communication Technologies, 2008, ISABEL08,IEEE, pp. 15.

[63] Y.-C. Chen, Y.-W. Lin, Indoor RFID gait monitoring system for fall detection,in: 2010 2nd International Symposium on Aware Computing, ISAC, IEEE,pp. 207212.

[64] C.-N. Huang, C.-Y. Chiang, J.-S. Chang, Y.-C. Chou, Y.-X. Hong, S.J. Hsu,W.-C. Chu, C.-T. Chan, Location-aware fall detection system for medical carequality improvement, in: Third International Conference on Multimedia andUbiquitous Engineering, 2009, MUE09, IEEE, pp. 477480.

[65] D. Gross, C.M. Harris, Fundamentals of queueing theory (1998) ISBN: 0-471-17083.

[66] L. Wang, R. Ranjan, J. Chen, Cloud Computing: Methodology, System, andApplications, CRC Press LLC, 2011.

Abdur Forkanis currently a Ph.D. student at the School ofComputer Science and Information Technology, RMIT Uni-versity, Melbourne, Australia. He received his B.Sc. degreein Computer Science and Engineering from BangladeshUniversity of Engineering and Technology (BUET), Dhaka,Bangladesh, in 2007. He worked as a Software Engineer ina USA-based software outsourcing company for 5 years.His research interests include context-aware technology,distributed systems and networks, data mining, machinelearning and remote healthcare.

Ibrahim Khalil is a senior lecturer in the School ofComputer Science and IT, RMIT University, Melbourne,Australia. Ibrahim obtainedhis Ph.D. in2003 from theUni-versity of Berne in Switzerland. He has several years ofexperience in Silicon Valley based companies working onLarge Network Provisioning and Management software.He also workedas an academic in several research univer-sities. Primary researchinterests include quality of service,

wireless sensor networks, and remote healthcare.

Zahir Tarireceived an honours degree in operational re-search from the Universite des Sciences et de la Tech-nologie Houari Boumediene (USTHB), Algiers, Algeria, amasters degree in operational research from the Univer-sity of Grenoble I, France, and a Ph.D. in artificial intel-ligence from the University of Grenoble II, France. He isthe head of the Distributed Systems and Networking Dis-cipline, School of Computer Science and Information Tech-nology, RMIT University, Melbourne. His current researchhasa special focus on theperformanceof Webservers andSOAP-based systems, SCADA system security, and Web

services, including protocol verification and service matching. He has organizedmore than 12 international conferencesas eithera general co-chair ora PC co-chair.Heregularlypublishes inreputable journals,such asACM andIEEE Transactions. Heis a senior member of the IEEE.
http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref24http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref24http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref26http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref26http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref27http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref27http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref27http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref28http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref28http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref29http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref29http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref29http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref30http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref30http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref30http://arxiv.org/1105.2213http://arxiv.org/1105.2213http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref37http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref37http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref38http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref38http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref38http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref41http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref41http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref41http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref42http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref42http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref43http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref43http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref43http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref47http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref47http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref47http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref47http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref48http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref48http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref48http://dx.doi.org/doi:10.1002/spehttp://dx.doi.org/doi:10.1002/spehttp://refhub.elsevier.com/S0167-739X(13)00154-4/sbref50http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref50http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref51http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref51http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref51http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref54http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref54http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref54http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref56http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref56http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref56http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref59http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref59http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref59http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref66http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref66http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref66http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref59http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref56http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref54http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref51http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref50http://dx.doi.org/doi:10.1002/spehttp://refhub.elsevier.com/S0167-739X(13)00154-4/sbref48http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref47http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref43http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref42http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref41http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref38http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref37http://arxiv.org/1105.2213http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref30http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref29http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref28http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref27http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref26http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref24

Documents

02+CoCaMAAL- A cloud-oriented context-aware middleware in ambient assisted living_Forkan, Abdur; Khalil, Ibrahim; Tari, Zahir