CoCaMAAL: A cloud-oriented context-aware middleware in ambient assisted living

Future Generation Computer Systems ( ) –

Contents lists available at ScienceDirect

Future Generation Computer Systems

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

CoCaMAAL: A cloud-oriented context-aware middleware in ambientassisted livingAbdur Forkan a,b,∗, Ibrahim Khalil a,b, Zahir Tari ba 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 2012Received in revised form10 June 2013Accepted 17 July 2013Available online xxxx

Keywords:Ambient assisted livingBody sensorAmbient intelligenceContext-aware serviceCloud 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 orchronicmedical conditions. AAL systems typically consist ofmultitudes of sensors and embedded devices,generating large amounts of medical and ambient data. However, these biomedical sensors lack the pro-cessing power to performkeymonitoring and data-aggregation tasks, necessitating data transmission 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, with cloud computing fea-tures utilized to provide a real-time assisted-living service.With themyriad of distributed AAL systems atplay, eachwith unique requirements and eccentricities, the challenge lies in the need to service these dis-parate systems with amiddleware layer that 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 proposed CoCaMAAL modelseeks to address such issues and implement a service-oriented architecture (SOA) for unified 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 unifiedmodel that includes patients, devices,and computational servers in a single virtual community, AAL services are enhanced.We have prototypedthe 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 Alzheimer’s 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.: +61450354402.

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-timedecision-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,highly resourced AAL system 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., body sensors) [4], provide real-timephysical andmed-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 matter© 2013 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.009

http://www.elsevier.com/locate/fgcs

http://www.elsevier.com/locate/fgcs

mailto:[email protected]




http://dx.doi.org/10.1016/j.future.2013.07.009

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

sensors and devices form the overall data-collection component ofan AAL system.

Due to the diversity in such low-level sensors, the range ofdata observed from AAL systems can vary widely. Accordingly, theconversion of the data to structured interchangeable formats andsubsequent aggregation and management represents a significantchallenge. Successful implementations rely not only on solid hard-ware and software foundations, but also on remote compute fa-cilities [5]. Thus, the adoption of cloud computing paradigms willplay a vital role, especially as the overall network performance in-creases.

Context awareness is the key to any AAL system, as it shouldcomprehend the situational context of the collected data and pro-vide personalized services tailored tomeet environmental anduserneeds [6]. Proper context affords a keener understanding of thestate of persons, places, or objects, and how they relate to the inter-action between users and the system [7]. A patient’s physiologicaldata vary with different activities (e.g., pulse during resting versusexercising) and indeed at different locations (e.g., body heat whenrunning outside versus running on a treadmill at home). The dataalso change as the patient ages and, quite obviously, varies withthe individual.

Such dynamism in readings, collected over varying periods oftime, results in massive context spaces for AAL systems. Applica-tions need a complete knowledge repository andmust remain con-text sensitive in order to satisfy different behavior profiles based onan individual’s specialized needs. However, performing such oper-ations from centralized middleware servers would result in rigid,failure-prone, and non-scalable systems.

A cloud-enabled platform eases the management of such largecontext-aware systems, allowing simplified user access and effec-tively handling demand elasticity [8]. The need for a large computespace, and ready availability of cloud services, has led us to envisionand design a cloud-based, real-time context-aware framework. Theproposed cloud platformoffers a high-level abstraction, and its ser-vices can be accessed easily via mature web service protocols [9].Our solution emphasizes a service-oriented architecture [10] thatperforms context modeling from raw data, context data manage-ment and adaptation, context-aware service mapping, service dis-tribution, and service discovery.

The rest of this paper is organized as follows. Section 2 describesthemotivations and the challenges in our approach. Section 3 sum-marizes related work in the area. The proposedmodel is presentedin Section 4, with its intricacies detailed in Section 5. Section 6 pro-vides some of case studies, Section 7 contains experimental results,and Section 8 concludes our work.

2. Motivation and challenges

Assisted living systems aim to provide medical support andmonitoring services in a cost-effective way to vulnerable sectionsof the community such as the elderly and disabled who live aloneat home [11]. The main motivations behind the research work arestated as follows.

• Modern aged-care andhealthcare industries depend on service-oriented and context-driven assistive technologies [12]. Exist-ing architectural solutions of context-aware middleware areconfined to specific services [13–18] and mostly rely on a lo-cal smart agent (i.e. mobile device) for context discovery andmanagement. The lack of storage and power in wearable sen-sors and mobile devices limits them to process limitless sensordata using decent computational methods. Moreover, the dis-covery of new smart sensors and devices is increasing the de-mand formore intelligent and complex assistive services. Cloudcomputing escalates the capability of handling data in big vol-umes and the provision of versatile services. This persuades us

to build a well-collaborative system by transferring the contextprocessing task from a local smart device to a distributed cloudenvironment to improve the processing time of context gener-ation and convey complex services.

• Traditional context management systems are incapable of han-dling large numbers of AAL systems together. They depend onstandalone applications on a local server [18,19]. This drawbackencourages us to design cloud-orientedmiddleware thatwill becompetent enough to handle a good number of clients simulta-neously. The context derived from one AAL systemwill becomea context knowledge bank for another AAL system inside thecloud repository. This is how the cloud middleware will be anextendable knowledge source of context for assisted living, andwill able to deliver assistive actions quickly.

• The integration of cloud computing will expand the diversity ofservices for the AAL system. We are keen to develop a systemthat is able to deliver every kind of service using a single model.A cloud-based software service, a set of instructions as a webservice or a cloud-based API for event alerts etc., can be imple-mented inside the cloud. That is, from context generation to ser-vice delivery, everything can be done using the cloud platform.

However, to design an SOA with scalable computing facilitiesthat efficiently supports the above objectives involves manychallenges.• The acquisition of data feeds from body sensors and other

wireless devices in real time, processing of heterogeneous data,and categorizing the data in an appropriate context is a majorchallenge.

• The integration task of distributed components and massivedata sources is not so simple. The raw data generated from AALsystems contain large variations. The data can be a small binarydata stream from the sensor, an analog signal, or even richmul-timedia content such as streaming of video, voice, and images.Accurate processing of data with such distinctions and classify-ing the context to trigger relevant services in a short time is avery challenging task. It becomes more complicated when thedata arrive in mass volume from a large number of systems.

• A key challenging issue in ubiquitous healthcare [20] is tochoose accurate services from a large set for a given context andto interact with the target user immediately with acquired ser-vices.

• If the data sets and their corresponding services are geograph-ically distributed, the allocation of storage and data migrationbecomes a critical challenge.

To overcome the above challenges, we are interested in de-signing our framework using cloud computing technology, becauseit enables every user, from patients to healthcare professionals,to easily collect, access, process, visualize, archive, share, andsearch vast amounts of data fromdifferent AAL systems and serviceproviders. Using the immense processing power of cloud comput-ing, it is easy to process highly swift data and provide quick re-sponses to the user environment. Our framework acts as a decisionsupport system in the backend and converts raw data to intelligentservices. Sizable amounts of context and service information can beprocessed, analyzed, and stored using computational and storageresources of the cloud.

Moreover, the solution in cloud computing allows sharing andreuse of information for different users and applications underflexible usage scenarios, and thus minimizes the extra cost. Asthe major computation is performed in the cloud architecture, sosensors and devices can handle other specialized processing tasks.Cloud services are easily deliverable to a system having internetconnections. So, our proposed solution actually simplifies theworkof every constituent. It reduces the computing load of sensors,helps disabled people, and minimizes the work of healthcareprofessionals.

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

Table 1Some 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 whereservices need to be downloaded for use. This limits the model toserve specific services.

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

No clear indication about context-aware service management.

CAMidO [22] The interpretation of context here is policy based; it collects andevaluates context by communicating with sensors.

React based on collected context from local system.

RCSM [23] Provides flexibility for runtime context data acquisition, monitoring anddetection 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 andprovides flexibility of service provisioning.

Services are bound to specific smart environment services.

HiCon [16] Supports advanced context-aware services which enforce scalablemonitoring 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 carenetworks 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-centricsolutions are proposed in different applications other than assistedliving. Table 1 shows 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 user’s 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 and scalable 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 described in [13] by converting context at a given timeas a particular case which is obtained through activity recognitionand case-based modeling.

Inmost of the proposed solutions, the functionalities ofmiddle-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 researchmainly suggestedhow cloud infrastructure can be used for information context pro-cessing [33–35]. 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 [36–39].

All the contributions described above show current effortsfor building solid architecture for AAL environments. Most ofthe 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 thedeployment of innovative healthcaremonitoring 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 overviewof each of the components 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 newAAL system can be included in themodelwithout 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 rawdata to abstract context representation which is recognizable


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 ECGdata as input and outputs the context of the desired classifica-tion. The context aggregator collects data fromAAL 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 whomonitors emergency situations. The SP cloudcontains information such as symptom detection for differentdiseases and the types of action required. For example, the rulesfor 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 ofmedical records, context-to-servicemapping, delivery of assistive actions, andmany 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 properlyand 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 patient’s friends and fam-ily to analyze, visualize, and discuss medical data wheneverrequired [45]. All these components together form a cloudsource for context data visualization.

In our model, all the AAL clients, context providers, and serviceproviders are physically distributed. The model takes advantage ofcloud computing 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, all fivemajor cloud components of themodel arebriefly described.

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

Sensor Measured signal Application

ECG [38] Electrocardiogram wave Heart ratePPG Photoplethysmogram wave Blood volume pulseBP Blood pressure in mm Hg Blood pressureEEG Electroencephalogram wave AbnormalityEMG Electromyograph wave Muscular activityAccelerometer [46] Acceleration in 3D space Activity recognitionMotion sensor Motion signal User movementActivity sensor 3-axis motion Activity recognitionInertial sensor Motion signal Position detectionBG sensor Blood sugar level Diabetes detectionGyroscopes Rotation angle Body orientationThermometer Body temperature in ° F Fever detectionInsulin pump – Inject insulinRF antenna RF wave Position detectionFall 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 2 shows 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 thatmake them easily implantable or wearable on the hu-man body (Fig. 2). Some sensors can be implanted in the garment ofthe user; these are known as wearable textile sensors. These sen-sors have lowpower, are capable of communicatingwirelessly, andmonitor the health and activity of the target user.Wewant to elim-inate the computational burden from these sensors so that they canperform their task for longer periods and more quickly.

Body sensors measure the user’s 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 Zigbee to a PDAwhich then forwards the data to 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


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 textilesensors.

Fig. 3. There are different types of ambient device and white goods are installed inAAL system including BSN that generate valuable context. Some sample devices areillustrated in here.

Fig. 4. Data acquisition: The raw sensor data produced by body sensors and otherdevices are transmitted to a local workstation using a connectedmedium. The localworkstation then forwards the data to the cloud server using a cloud gateway.

the cloud servers using a cloud gateway. Fig. 5 illustrates 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 contextaggregator cloud.

5.2. Context providers and aggregator cloud

5.2.1. Context providersThe 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 user’sactivity from accelerometer data and classifying a user’s heart con-dition using an ECG sensor cannot be solved using the same classi-fier. That iswhyour systemhas a large number of 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 servicewhich collects raw sample data as input and respondsback 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. 6 shows the general flows performed by a classifier ofthe context provider cloud. In our model, many context providerscan be integrated easily.

5.2.2. Context aggregatorThe 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.


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 forthe 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-awareservice.

Raw Sensor data

Pre-Processing SegmentationFeature Extraction

AcceptableFeatures

Yes

No

Strat and End Point Detection

ClassificationHigh LevelFeature

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 eachof 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 contextproviders after the classification process.

• The same context can be reported by different providers. Thecontext aggregator resolves conflicts among duplicate data.

• If the same context has different values fromdifferent providersthen 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 the contextmodel to the context-awaremiddleware cloudfor finding context-aware services.

Context providers perform the primary abstraction, and that isfollowed by the reasoning mechanism in the context aggregatorto 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 ourmodel. It is required for in-teroperability between data information from sensors and service-providing entities.

5.2.3. Context modelingA major aim of the research is to find a unified context model

so that any context and context-aware services of AAL systems canbe designed easily using the model. Without a well-defined, clear,and flexible informationmodel, applications will not be able to usesuch information in an efficient way. The model must be rich andflexible enough to accommodate not only the current facets of con-text information, but also future requirements and/or changes. Themodel 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 specifywhich context information is transient andwhich 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.

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

• Place ontology 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


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 entitysuch as characteristics, diseases, preference, social and health ontologies are part of person ontology. Each of those entities has some more children to describe them. Therelation among different entities is also shown here.

Table 3Service rules of detecting a possible heart attack.

Ontology Instance Raw data Context attr. Value

Person User X Profile Age ≥65Person User X Profile Weight ≥80Person Disease Profile Cardiac patient Have cardiac issueDevice ECG sensor ECG wave Heart rate AbnormalDevice BP sensor BP readings Blood pressure Normal or highDevice PPG sensor Sensor readings O2 consumption LowDevice Audio sensor Sound wave Breathing IrregularDevice Camera, radar,

accelerometerVideo, images, 3D acceleration,motion path

Motion Tripping or falling or flailing ofarms or any rapid motion

Table 4Example 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 saverSoftware (medicationreminder)

(?local time: 5:00 PM) ∧ (?medicine Y time: 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 siteX for finding

Social context providers

Emergency (fall detection) (?user status: lying down) ∧ (?fall detector status: on) → ACTION: alert emergency assistance Emergency service providerSymptom detection (?skin temperature: high)∧ (?breathing: abnormal)→ ACTION: fever detected. Alert personal doctor. 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 servicewhich is deployed in the cloud (SaaS) or the infras-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-served conditions are integrated also. 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 areimplemented 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 3 shows 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 provider’s data storage. The consequences of the events hap-pen locally inside the AAL system but the actions are mentioned inthe assistive response.

There are differentAALplatforms for generating services, for ex-ample, OpenAAL [54]. OpenAAL is a framework that supports inte-gration and communications betweenAAL services using ontology.The rules of some context-aware services are presented in Table 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-basedcontext model with assistive actions.


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 different

distributed 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 fromwhere it obtains context in-formation and relates the contextswith services defined by the SPs.Since it contains sensitivemedical 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 storingA 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 key–value 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 isused for storing and retrieval sensitive data in the cloud.

5.4.3. Context retrievalThe context manager periodically retrieves context for an AAL

systemvia the context aggregator. The context information requestis triggered by the context manager itself periodically. Third-partyproviders, monitoring services, and social networking services canalso 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 manipulationMost of the context manipulation is done inside the CAP cloud.

Inside the CMS a 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 CMSperforms 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 mappingThe most important role of the context manager is to map

context 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 modelcan 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 shouldbe 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 of M services in the ser-vice repository. CT is 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 in CT which is exactly or very similar to tree STi, then Si is acontext-aware service for context C . So, the action item describedin the structure of Si is picked which is the assistive action for Si.The matching operation is performed for all theM trees and all theactions are combined in a single XML structure. Then the CMS re-sponds back to the AAL system with the action list.


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 = (NS−STi , ES−STi) is a subtree of STi. To find thesimilarity between S − CT and S − STi, we first need to find thesimilarity between the root nodes of S − CT and S − STi and 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<contextML>

<AALSystem id="1001" /><timestamp>2012-11-08T12:23:56+11:00</timestamp><expires>2012-11-08T23:21:56+11:00</expires><contextProviders>

<contextProvider id="3eq32dfs"/><contextProvider id="1eq32daa"/>

</contextProviders><context>

<person id="421332"><name>Alice</name><gender>Male</gender><age>68</age><health>

<blood_pressure>High</blood_pressure><skin_temparature>Normal</skin_temparature>

</health><diseases>

<disease>cardiac</disease><disease>alzheimer</disease>

</diseases></person><place>

<location>Bed Room</location></place><environment>

<temparature>25 C</temparature><humidity>40%</humidity>

</environment><device>

<camera id="cs221">active</camera><Monitor id="T3234">off</Monitor><ECG_sensor id="S2312">

<heart_rate>normal</heart_rate></ECG_sensor><ECG_sensor id="S2312">

<heart_rate>normal</heart_rate></ECG_sensor><Accelerometer id="A5406">

<activity>walking</activity></Accelerometer>

</device></context>

</contextML>

The similarity between two nodes NCTx in tree CT and NSTiy intree STi is w = 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 of NCTx

and NSTiy ).

Listing 2: An example of service XML<serviceXML>

<ServiceProvider id="weq9wq4234"/><service>Detect possible heart attack</service><context>

<person><health>

<blood_pressure>High</blood_pressure><heart_rate>Abnormal</heart_rate><O2_consumption>Low</O2_consumption>

</health><Diseases>

<disease>cardiac</disease></Diseases>

</person></context><result>Talk With user</result><actions>

<action>Turn on Monitor</action><action>Turn on Speaker</action><action>Turn on MIC</action>

<actions></serviceXML>

So, w is either 0 or 1. If w = 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, if STi has z nodes which are exactly similar or nearly similar

to CT then the similarity matrix of STi is WSTi =

wST i1wST i2. . .

wST iz

, where

1 ≤ i ≤ M .Among the z nodes let p nodes be child nodes and the remaining

z−p nodes be parent nodes. Since all parent node similarity valuesare 1, we consider only child nodes for calculating the scorematrixofWSTi : scoreWST i

=p

j=1 wST i j . The score matrix of all services is

scoreS =

scoreST1scoreST2

. . .scoreSTp

.

Therefore, the CMS picks the services and related actions withgood score values.


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

5.4.6. Self-adaptationWhen the CMS calculates the similarities between context and

service structure, it can identify a set of actions and enrich theknowledge base 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 thedatabase 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 fromAAL1 thenwithout performingmapping the CMdelivers the actionsfrom its past knowledge. If another AAL system AAL2 requests ser-vices with context tree CT2, similar to CT1, then the CMS can easilypick the actions required for CT2 and deliver it without performingadditional mapping. As a result, the CMS can acknowledge fasterby self-adaptation.

5.4.7. Service discoveryNot all the assistive actions are described by the service

providers. 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 serviceThe health-related context that is collected, processed, and

managed inside the cloud is sensitive. The security service insidethe CMSwill ensure the 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 privacyof 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 itin a visual interpretation. Also thesemedical 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 the

context 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 proposedmodel. The elements of this simulatedmodel are pre-sented in Fig. 10 and 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


Table 5The 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 alarmDevices of bath room RFIDs, Mic, speakerDevices 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 among them. The rules are stored inXML files (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 contexthistory. Every single sample (as in Table 6) is processed inside theCMS one by one. After the rule matching and service mapping pro-cess described in Section 5.4.5, the CMS selects the best possibleservices from multiple SPs.

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

• Case study 11. The AAL system generates featured context of the user as

described in Table 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 Section 5.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 runninginside the AAL system as a SOAP response.

7. The server receives the response and sends the appropriatecommand 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 question–answer 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 service‘‘risk of heart attack’’.)

• Case study 21. 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 user’s 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 rulemappingit picksmedication reminder service and as an assistive actionit reminds the user to take his/her medicine properly.

• Case study 31. As in sample 5 of Table 6 from context the CMS detects that

user’s physical condition is not good and that he/she hasfallen down in the bathroom [63,64].

2. The CMS identifies the situation as ‘‘Emergency Service’’from 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 6Aggregated high-level context samples.

No Time Heart rate O2 saturation Blood pressure Location Activity

1 23:10:12 Normal Normal Normal Living room Watching TV2 10:11:45 High Low High Living room Sitting3 09:42:78 High Normal Normal Living room Excessing4 01:43:21 Normal Normal Normal Living room Taking medicine5 05:22:34 High Low High Bath room Fallen down6 19:17:28 Normal Normal Normal Kitchen Cooking

Table 7Components developed for simulated prototype.

Model component Simulated components Development platform Output format

Wearable sensors Java servlet as numerical data generator Java thread in tomcat server Data filesData collector Java servlet Java thread in tomcat server Data filesContext providers Java program running in GAE API using GAE High-level contextContext ontology OWL GAE data source for ontology containers Context modelContext aggregator Java program running in GAE API using GAE Context model as XMLCM repository Static database GAE data source Database recordsService providers Static XML in different web servers GAE web server Simple service rules with actionsService mapper Java program running in GAE API using GAE List of assistive actions as XML


Table 8Average 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 182 1 and activity, location, time 7 3 21 213 2 and environment 11 5 35 234 3 and user profile 14 7 43 285 4 and context history 16 8 54 306 5 and device status 21 10 67 31

Note that in the second column of item 2, 1 and activity refers to activity, location and time including physical parameters of row 1, and so onfor other rows.

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

Set Si in % and Ti in ms ρ W

S1 Si 22 17 14 12 9 8 6 5 4 3 0.062 0.0326Ti 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.0311Ti 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.0325Ti 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.0324Ti 33 21 12 16 40 55 42 44 24 82

7. Experimental results

We first evaluated the model for a single AAL system withdifferent context and service load. For each of the cases, the averageservice 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, Tresponse includes the context processing time, service mappingtime, and service delivery time. Tresponse is measured by increasingthe number of context sources, service providers, and services. Theresult is shown in Table 8. We also measured the service mappingaccuracy to ensure that the system is picking the correct servicesfor a scenario. To compute the accuracy,we compared the observedresults with expected services andmade a true/false decision for it.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 of selecting 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/1 queuing systemwith FCFS [65]. InM/G/1, the inter-arrival time of requests is expo-nentially distributed, the service time is generally distributed, andthe total number of processing servers is 1. Themodel is presentedin Fig. 11. The model can be extended to an M/G/c queuing sys-tem [66]. Computation of M/G/c is 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 anM/G/1model to serve n AAL systems. So, here the number ofprocessing servers c = 1, and the processing of k different requestsis distributed in k different 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 λ =

12060 =

2 requests/s.The service response time depends on the size, type, and value

of the context. Here, the service time is generally distributed withmean 1

µs and variance σ 2.

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)

where Si% requests are processed in Ti s and k is the number of re-quest types. The variance σ 2

= 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 meanprocessing time (inside CoCaMAAL) Ti ms. The distribution for fivedifferent configurations (for k = 10) are presented in Table 9. Theprocessing of the request containing large data (i.e., image) takesa longer time than the processing time of the sensor data (i.e., ac-celerometer data). So, in Table 9, different percentages of the re-quests have different processing times. For example, in the case ofS1 we have the following.

Using Eq. (1), we got 1µ

= E[S] = 31 ms = 0.031 s.Variance σ 2

= E[s2] − (E[s])2 = 0.000538 s2.Utilization ρ =

λµ

= 2 × 0.031 = 0.062.


Fig. 12. The average response time (W ) varies with the distribution of servicetime in different processing nodes for different observations. Using only a singleultra-fast server with k processing slots, the average response time (using the samearrival rate) is very low for each observation. For k ≥ 5, the response time of eachobservation is very similar.

Fig. 13. (a) Using the lower value of the request arrival rate (λ). (b) λ is high. Thatis, 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 ofrequest arrivals. The response time is still very fast (only 0.11 s) even with a highrequest arrival rate (λ = 60).

According to the Pollaczek–Khinchine formula [65], we obtainthe following.

Average number of requests L = ρ +ρ2

+λ2σ 2

2(1−ρ)= 0.0652.

Average response time of a requestW =Lλ

= 0.0326 s.

The ρ and W values for each of the cases are presented inTable 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 evaluated themodel by varying k and λ, and the resultsare given in Figs. 12 and 13. From the obtained results we findthat the CoCaMAALmodel respondsmuch 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 isa 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 for a suitable contextmodel for theAAL systemwhich is 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-ing systems. So, as part of our futurework,we are aiming to includethese features.

Acknowledgments

The authors wish to acknowledge the support of NICTA (Na-tional ICT Australia) of Victoria Research Lab for funding theresearchwork presented in this paper. NICTA is funded by the Aus-tralian Government as represented by the Department of Broad-band, Communications and theDigital Economy and the AustralianResearch Council through the ICT Centre of Excellence program.

References

[1] T. Kleinberger, M. Becker, E. Ras, A. Holzinger, P. Müller, Ambient intelligencein assisted living: enable elderly people to handle future interfaces,in: Universal Access in Human–Computer Interaction. Ambient Interaction,2007, pp. 103–112.

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

[3] S. Kern, D. Jaron, Healthcare technology, economics, and policy: an evolvingbalance, in: IEEE Engineering inMedicine and BiologyMagazine: the QuarterlyMagazine of the Engineering 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 body sensors, in: 2010 Annual InternationalConference of the IEEE Engineering in Medicine and Biology Society, EMBC,IEEE, pp. 5500–5503.

[5] P. Remagnino, G. Foresti, Ambient intelligence: a new multidisciplinaryparadigm, IEEE Transactions on Systems,Man andCybernetics, Part A: Systemsand Humans 35 (2005) 1–6.

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

[7] A. Dey, Understanding and using context, Personal and Ubiquitous Computing5 (2001) 4–7.

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

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

[10] F. Azzedin, M. Eltoweissy, S. Khwaja, Overview of service oriented architec-ture for resource management in P2P systems, in: The Handbook of Researchon P2P 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 challenges for people with disabilities, IBM SystemsJournal 44 (2005) 605–619.

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

[13] F. Zhou, J. Jiao, S. Chen, D. Zhang, A case-driven ambient intelligence system forelderly in-home assistance applications, IEEE Transactions on Systems, Man,and Cybernetics, Part C: Applications and Reviews (2010) 1–11.

[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) 480–494.

[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 fornext-generation context-aware services, IEEE Network 22 (2008) 34–42.

[17] J. Hong, E. Suh, S. Kim, Context-aware systems: a literature review andclassification, Expert Systems with Applications 36 (2009) 8509–8522.

[18] T. Gu, H. Pung, D. Zhang, Toward an osgi-based infrastructure for context-aware applications, IEEE Pervasive Computing 3 (2004) 66–74.

[19] S. Baek, E. Choi, J. Huh, K. Park, Sensor information management mechanismfor context-aware service in ubiquitous home, IEEE Transactions on ConsumerElectronics 53 (2007) 1393–1400.

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

[21] J. Bardram, The java context awareness framework (JCAF)–a service infrastruc-ture and programming framework for context-aware applications, PervasiveComputing (2005) 98–115.

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

[23] S. Yau, F. Karim, Y. Wang, B. Wang, S. Gupta, Reconfigurable context-sensitivemiddleware for pervasive computing, IEEE Pervasive Computing 1 (2002)33–40.

http://refhub.elsevier.com/S0167-739X(13)00154-4/sbref1





















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

[25] W. Kurschl, S. Mitsch, J. Schoenboeck, Modeling situation-aware ambientassisted living systems for eldercare, in: Sixth International Conference on In-formation Technology: NewGenerations, 2009, ITNG’09, IEEE, pp. 1214–1219.

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

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

[28] G. VanDen Broek, F. Cavallo, C.Wehrmann, AALIANCE Ambient Assisted LivingRoadmap, Vol. 6, IOS Press Inc., 2010.

[29] M. Amoretti, S. Copelli, F.Wientapper, F. Furfari, S. Lenzi, S. Chessa, Sensor datafusion for activity monitoring in the persona ambient assisted living project,Journal of Ambient Intelligence and Humanized Computing (2011) 1–18.

[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. 1–8.

[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 system architecture for assisted living,in: IEEE International Conference on Systems, Man and Cybernetics, 2006,SMC’06, Vol. 5, IEEE, pp. 4268–4275.

[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 Preprint arXiv: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. 760–767.

[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 patient’s data collection in health care institutions,in: Second International Conference on eHealth, Telemedicine, and SocialMedicine, 2010, ETELEMED’10, IEEE, pp. 95–99.

[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) 147–154.

[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. 532–536.

[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 3–6, 2012.

[41] A. Pantelopoulos, N. Bourbakis, A survey on wearable sensor-based systemsfor health monitoring and prognosis, IEEE Transactions on Systems, Man, andCybernetics, Part C: Applications and Reviews 40 (2010) 1–12.

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

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

[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. 1–7.

[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. 157–162.

[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)115–133.

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

[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) 237–265.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) 571–583.

[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) 583–593.

[52] J. Mocholí, P. Sala, C. Fernández-Llatas, J. Naranjo, Ontology for modelinginteraction in ambient assisted living environments, in: XII MediterraneanConference on Medical and Biological Engineering and Computing 2010,Springer, pp. 655–658.

[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. 1–7.

[54] P. Antonino, D. Schneider, C. Hofmann, E. Nakagawa, Evaluation of aal plat-forms according to architecture-based quality attributes, Ambient Intelligence(2011) 264–274.

[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. 962–969.

[56] X. Huang, Y. He, Y. Hou, L. Li, L. Sun, S. Zhang, Y. Jiang, T. Zhang, Privacyof value-added context-aware service cloud, in: Cloud Computing, Springer,2009, pp. 547–552.

[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. 629–633.

[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. 43–52.

[59] D. Guermeur, A. Unruh, Google App Engine Java and GWT ApplicationDevelopment: Build Powerful, Scalable, and InteractiveWebApps in 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. 1–7.

[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. 344–347.

[62] A. Hristova, A.M. Bernardos, J.R. Casar, Context-aware services for ambientassisted living: a case-study, in: First International Symposium on AppliedSciences on Biomedical and Communication Technologies, 2008, ISABEL’08,IEEE, pp. 1–5.

[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. 207–212.

[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, MUE’09, IEEE, pp. 477–480.

[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 Forkan is 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 obtained his Ph.D. in 2003 from the Uni-versity of Berne in Switzerland. He has several years ofexperience in Silicon Valley based companies working onLarge Network Provisioning and Management software.He also worked as an academic in several research univer-sities. Primary research interests include quality of service,wireless sensor networks, and remote healthcare.

Zahir Tari received 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 researchhas a special focus on the performance ofWeb servers andSOAP-based systems, SCADA system security, and Web

services, including protocol verification and service matching. He has organizedmore than 12 international conferences as either a general co-chair or a PC co-chair.He regularly publishes in reputable journals, such as ACM and IEEE Transactions. Heis a senior member of the IEEE.







http://arxiv.org/1105.2213








http://dx.doi.org/doi:10.1002/spe







Documents

CoCaMAAL: A cloud-oriented context-aware middleware in ambient assisted living