CoCaMAAL: A Cloud-oriented Context-aware Middleware in Ambient Assisted Living Abdur Forkana,b,∗, Ibrahim Khalila,b , Zahir Tarib a Natinal b School
ICT Australia (NICTA), Victoria Research Lab, Melbourne, Victoria, Australia of Computer Science and IT, RMIT University, Melbourne, Victoria, Australia
Abstract Research into Ambient Assisted Living (AAL) strives to ease the daily lives of people with disabilities or chronic medical conditions. AAL systems typically consist of multitudes of sensors and embedded devices, generating large amounts of medical and ambient data. However, these biomedical sensors lack the processing power to perform key monitoring and data-aggregation tasks, necessitating data transmission and computation at central locations. The focus here is on the development of a scalable and contextaware framework and easing the flow between data-collection and data-processing. The resource-constrained nature of typical wearable body sensors is factored into our proposed model, with cloud computing features utilized to provide a real-time assisted-living service. With the myriad of distributed AAL systems at play, each with unique requirements and eccentricities, the challenge lies in the need to service these disparate systems with a middleware layer that is both coherent and flexible . There is significant complexity in the management of sensor data and the derivation of contextual information, as well as in the monitoring of user activities and in locating appropriate situational services. The proposed CoCaMAAL model seeks to address such issues and implement a service oriented architecture (SOA) for unified context generation. This is done by efficiently aggregating raw sensor data and the timely selection of appropriate services using a context management system (CMS). With a unified model that includes patients, devices, computational servers into a single virtual community, AAL services are enhanced. We have prototyped the proposed model and implemented some case studies to demonstrate its effectiveness. Keywords: Ambient Assisted Living, Body Sensor, Ambient Intelligence, Context-aware Service, Cloud Computing.
1. Introduction Throughout the world, rapidly aging populations and higher disability rates has intensified pressure on already burdened health-care infrastructures. Coupled with higher ∗ Corresponding
Author Email addresses:
[email protected] (Abdur Forkan),
[email protected] (Ibrahim Khalil),
[email protected] (Zahir Tari) Preprint submitted to Integration of Cloud Computing and Body Sensor Networks February 23, 2016
occurrences of diseases like Alzheimer’s and Dementia, this phenomenon has resulted in urgent interest in AAL research. AAL has gained significance in recent years, combining aspects of intelligent platform design, assistive living solutions and ambient intelligence technologies [1] into a coherent system. The idea is for an AAL system that features situational awareness and real-time decision making capabilities [2], with adequate flexibility at the architectural, algorithmic and human-interface level. To maintain quality health-care services [3], it is essential to have an intelligent, highly-resourced AAL system that is efficient, responsive and most importantly, adequately secures patient health. A typical AAL environment consists of a target user, smart sensors, actuators, wireless networks, ubiquitous devices, and underlying software services. Wearable and implantable data collection devices (i.e., body sensors) [4], provides real-time physical and medical information on the patient. Likewise, knowledge pertaining to the environment is obtained from embedded sensors that focus on ambient readings (e.g. temperature, humidity ). Along with a local processing point where data is initially transmitted, all these sensors and devices form the overall data-collection component of an AAL. Due to the diversity in such low level sensors, the range of data observed from AAL systems can vary widely. Accordingly, the conversion of this data to structured interchangeable formats and subsequent aggregation and management represents a significant challenge. Successful implementations rely not only on solid hardware and software foundations, but also on remote compute facilities [5]. Thus, the adoption of cloud computing paradigms will play a vital role, especially as overall network performance increases. Context-awareness is the key to any AAL system, as it should comprehend the situational context of collected data and provide personalized services tailored to meet environmental and user needs [6]. Proper context affords a keener understanding of the state of persons, places, or objects and how they relate to the interaction between users and the system [7]. A patient’s physiological data varies with different activities (e.g., pulse during resting vs exercising) and indeed at different locations (e.g., body heat when running outside vs running on a treadmill at home). This data also changes as the patient ages and quite obviously, varies with the individual. Such dynamism in readings, collected over varying periods of time, results in massive context-spaces for AAL systems. Applications need a complete knowledge repository and must remaincontext-sensitive in order to satisfy different behaviour profiles based on an individual’s specialized needs. However, performing such operations from centralized middleware servers would result in rigid, failure-prone and non-scalable systems. Cloud-enabled platform eases the management of such large, context-aware systems, allowing simplified user access and effectively handling demand elasticity [8]. The need for a large compute space, and ready availability of cloud services, has led us to envision and design a cloud-based, real-time context-aware framework. The proposed cloud platform offers a high-level abstraction and its services can be accessed easily via mature web service protocols [9]. Our solution emphasizes a service oriented architecture [10] that performs context modelling from raw data, context data management and adaptation, context-aware service mapping, service distribution, and service discovery. The rest of this paper is organized as follows: Section 2 describes the motivations and the challenges in our approach. Section 3 summarizes related work in the area. The proposed model is presented in Section 4, with its intricacies detailed in Section 5. Section 6 provides some of case studies, Section 7 contains experimental results and Section 8 concludes our work. 2
2. Motivation and Challenges Assisted Living systems aim to provide medical support and monitoring services in a cost-effective way to vulnerable sections of the community such as the elderly and disabled who live alone at home [11]. The main motivations behind the research work are stated as follows: • Modern aged-care and healthcare industries depend on service-oriented and contextdriven assistive technologies [12]. Existing architectural solutions of context-aware middleware are confined to specific services [13–18] and mostly rely on a local smart agent (i.e. mobile device) for context discovery and management. The lack of storage and power in wearable sensors and mobile devices limits them to process limitless sensor data using decent computational method. Moreover, the discovery of new smart sensors and devices is increasing the demand of more intelligent and complex assistive services. Cloud computing escalate the capability of handling data in big volume and the provision of versatile services. This persuades us to build a well-collaborative system by transferring context processing task from local smart device to distributed cloud environment for improving the processing time of context generation and conveying complex services. • Traditional context management systems are incapable of handling large numbers of AAL systems together. They depend on standalone applications on a local server [18, 19]. This drawback encourages us to design cloud-oriented middleware that will be competent enough to handle a good number of clients simultaneously. The context derived from one AAL system will become a context knowledge-bank for another AAL system inside the cloud repository. This is how the cloud middleware will be an extendable knowledge source of context for assisted living, and will able to deliver assistive actions quickly. • The integration of cloud computing will expand the diversity of services for the AAL system. We are enthusiastic to develop a system that is able to deliver every kind of services using a single model. A cloud-based software service, a set of instructions as a web service or a cloud-based API for event alerts etc., can be implemented inside the cloud. That is, from context generation to service delivery all can be done using the cloud platform. However, to design a SOA with scalable computing facilities that efficiently supports the above objectives involves many challenges : • The acquisition of data feed from body sensors and other wireless devices in realtime, processing of heterogeneous data, and categorizing them in an appropriate context is a major challenge. • The integration task of distributed components and massive data sources is not so simple. The raw data generated from AAL systems contain large variations. It can be a small binary data stream from the sensor, an analogue signal, or even rich multimedia contents like streaming of video, voice, and images. Accurate processing of data with such distinctions and classify context to trigger relevant services in short time is a very challenging task. It becomes more complicated when data arrive in mass volume from a large number of systems. 3
• A key challenging issue in ubiquitous healthcare [20] is to choose accurate services from a large set for a given context and interacting with the target user immediately with acquired services. • If the data sets and their corresponding services are geographically distributed the allocation of storage and data migration becomes a critical challenge. To overcome the above challenges, we are interested to design our framework using cloud computing technology. Because it enables every users, from patients to healthcare professionals, to easily collect, access, process, visualize, archive, share, and search vast amounts of data from different AAL systems and service providers. Using the immense processing power of the cloud computing it is easy to process highly swift data and provide quick responses to the user environment. Our framework acts as a decision support system in the backend and converts raw data to intelligent services. Sizeable amounts of context and service information can be processed, analyzed, and stored using computational and storage resources of the cloud. Moreover, the solution in cloud computing allows sharing and reuse of information for different users and applications under flexible usage scenarios and thus minimizes the extra cost. As the major computation is performed in the cloud architecture, so sensors and devices can handle other specialized processing tasks. Cloud services are easily deliverable to a system having internet connections. So, our proposed solution actually simplifies the work of every constituent. It reduces the computing load of sensors, helps disabled people, and minimizes the work of healthcare professionals. 3. Related Work In the area of context-awareness several middleware-centric solutions are proposed in different applications other than assisted living. Table 1 shows a summary of those works and their limitations. There are few research works for building situation-aware assisted living systems with sensor technology [25, 26]. Some of the works focus on promoting user’s social interaction with his surroundings and co-ordination between several distributed actors like caregivers and monitoring systems [14, 27]. European Union funded projects like AALIANCE [28], PERSONA [29], and SOPRANO [30] aim at developing a next generation smart home with ambient intelligence and scalable open standards for building a broad range of AAL services. I-Living [31] allows different parties to work together in a dependable, secure, and low cost system manner. The Amigo Project [32] is a good example of “Intelligent Home” for healthcare. A case driven Ambient Intelligence technique is described in [13] by converting context at a given time as a particular case which is obtained through activity recognition and case-based modeling. In most of the proposed solutions, the functionalities of middleware are achieved by distributing the tasks in a layered architecture. There are several applications that leverage cloud resources to design efficient systems. Some of the research mainly suggested how cloud infrastructure can be used for information context-processing [33–35]. MoCASH [9] used the cloud computing feature for assistive healthcare but the concern was in context sensing mechanism using mobile devices. There are also some cloud applications that are developed for healthcare [36–39]. 4
Table 1: Some mentionable research works describing the framework of Context-aware System (CaS)
CaS SOCAM [18]
Contributions For context modeling a reasoning mechanism is suggested using OWL (web ontology language)
JACF [21]
It relies on object oriented context model developed in java framework The interpretation of context in here is policy based which collects and evaluates context by communicating with sensors. Provides flexibility for runtime context data acquisition, monitoring and detection using adaptive object containers (ADCs). Context model based on 5W1H(who, what, where, when, why and how). This model has capability of handling large number of context and provides flexibility of service provisioning. Supports advanced context-aware services which enforce scalable monitoring and composition of dynamic context. A context-aware service platform for supporting continuous care networks for home-based assistance.
CAMidO [22] RCSM [23]
5W1H [24]
HiCon [16]
ERMHAN [15]
Limitations Most of the complex tasks are performed in local network where services need to be downloaded for use. This limits the model to serve specific services. No clear indication about context-aware service management. React based on collected context from local system. Only capable of triggering decision from application level Services are bound to specific smart environment services.
The context model is not an accepted standard for AAL. Only focus on activity monitoring and related services.
All the contributions described above show current efforts for building solid architecture for AAL environments. Most of the models are developed as standalone applications. The cloud based context-aware system related researches do not specifically focus on healthcare applications. With the support of cloud computing, BSNs can be greatly enhanced for the deployment of innovative healthcare monitoring applications [40]. 4. CoCaMAAL System Overview The context-awareness in AAL systems is accomplished by context-flow in a distributed middleware. The abstract architecture of the CoCaMAAL system is illustrated in Figure 1. The system comprises of five main cloud-oriented components: AAL systems, context aggregator and providers (CAP) cloud, service providers cloud, context-aware middleware (CaM) cloud, context data visualization and monitoring cloud. That is, every piece of the functional elements of the model cope with context and have cloud-oriented infrastructure. The detail overview of each of the component is described below. • AAL Systems: Our proposed model can serve large numbers of AAL clients. AAL clients act as sensor data providers as well as context-aware service consumers. The setup of AAL systems varies based on target user requirements. Each of the AAL systems consists of different BSN foundations and monitoring systems [41, 42]. Any 5
Context aggregator and providers cloud medical server
Data visualization and Social Network cloud
image processor weather station
AAL Systems medical data
and context-aware service consumers Cloud
Emergency
Service providers cloud
context Food Advisor
CaM Cloud sensor data
sensor data, context, context-aware service for assisted living
service
Doctor
Figure 1: The Generic architecture of CoCaMAAL model showing 5 major distributed cloud-based components of the proposed system.
new AAL system can be included in the model without altering the architecture. All the AAL systems together form a distributed cloud structure. They generate raw sensor data for the model which is the input for high level context generation and consume context-aware services. For example, an AAL system generates raw heart beat data from ECG sensor and waits for automated assistive services relevant to the context value of the heart beat rate. • Context Aggregator and Providers (CAP): CAP cloud contains the computing logic and process of converting low level raw data to abstract context representation which is recognizable to all components of the architecture. CAP cloud uses fusion and reasoning mechanisms to infer context from sensor data [43]. A context provider can be a medical server which manipulates ECG medical data, or it can be a weather station which provides context related to weather forecast(i.e., Temperature, Humidity). For instance, the process of classifying heart beat rate into high, medium, or low category is hosted in a cloud server of a context provider which consumes ECG data as input and outputs the context of desired classification. The context aggregator collects data from AAL systems and distributes them among different context providers for finding context. After getting high level abstraction, the aggregator integrates all the information in a single context model. It then forwards that context description to the CaM cloud. • Service Providers: Service providers (SPs) are applications and services related to context-awareness. A SP can be a software application running on the mobile device of AAL system that reminds the user about his appointments, or it can be an external caregiver who monitors emergency situations. The SP cloud contains information like symptom detection of different diseases and the type of actions required. For example, the rules for detecting fever and related actions are hosted in the cloud database of a service provider. The emergency actions that required after detecting the fever of different patients are also described in the cloud storage. Thus, the SP cloud delivers various kinds of services to the CaM cloud. • Context-aware Middleware (CaM): The CaM cloud is the most important functional component of the model. The CaM cloud has the infrastructure for pro6
cessing context data, storing and retrieving context, context-aware service management, access control [44] mechanisms of medical records, context-to-service mapping, delivery of assistive actions, and many other complex computational tasks. It contains an intelligent context management system (CMS) which manages incoming context and ensures appropriate assistive services are delivered properly and in a timely manner. A context manager is responsible for storing and managing context that is gathered from AAL systems and converts them as services. The context manager automatically reconfigures its knowledge to adapt the change in context. • Context Data Visualization: Context data contains the valuable medical information of the user. Proper visual interface is needed for the healthcare professional to view the information. Some data visualization services provide useful user interface for this purpose. Using flexible GUI the monitoring systems can examine medical records. The model also has different social networks of doctors and patient’s friends and family to analyze, visualize, and discuss medical data whenever required [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 grabs the advantage of cloud computing by hosting all the context processing and service generation logic inside the cloud platform. Therefore, tt becomes beneficial in terms of elasticity, storage scalability and extensibility. Here, a new AAL client can be added or separated easily. A provider (context or service) can join or leave the system anytime. The context-aware cloud adopts its behavior according to the recent contextual situation and distribute services related to that. 5. System Description In this section all the major 5 cloud components of the model is briefly described. 5.1. AAL System Our conceptual AAL system consists of a target user, body sensor network [46] and other ambient devices belonging to the type of observation and monitoring required for the user, the home environment of the user, a central workstation for capturing sensor data to send it in the cloud, and the software services running on the cell phones, smart devices and workstations. The complete setup depends on available devices and the type of running services. Each AAL system has a unique identifier in the CoCaMAAL structure to identify it in generalized cloud architecture. Whatever the requirement is, the objective here is to generate a unique model for context representation. Table 2 shows some examples of typical body sensors. These kinds of sensors together form a Body Sensor Network (BSN) [48, 49]. These sensors have some key configuration and infrastructure that make them easily implantable or wearable in the human body (Figure 2). Some sensors can be implanted in the garment of the user and known as wearable textile sensors. These sensors have low power, are capable of communicating wirelessly, and monitor the health and activity of the target user. We want to eliminate 7
Table 2: Examples of some typical body sensors and their use in AAL
Sensor ECG [38] PPG BP EEG EMG Accelerometer [47] Motion Sensor Activity Sensor Inertial Sensor BG sensor Gyroscopes Thermometer Insulin Pump RF antena Fall Detector
Measured Signal Electrocardiogram wave Photoplethysmogram wave Blood Pressure in mmHg Electroencephalogram wave Electromyograpm wave Acceleration in 3D space Motion signal 3-Axis motion Motion Signal Blood Sugar level Rotation Angle Body Temparature in ◦ F RF wave Motion Signal
Application Heart Rate Blood Volume Pulse Blood Pressure Abnormality Muscular activity Activity recognition User Movement Activity recognition Position detection Diabetes detection Body orintation Fever detection Inject insulin position detection fall detection
Speaker Small Head phone
Light Sensor
EEG Sensor
Motion Sensor
Fire alarm
EEG Sensor
Camera Temparature Sensor
ECG
Blood Pressure Sensor
White Goods Outdoor Camera
Insulin Pump Accelerometer
Fall Detector
RFID Antena
Activity Sensor
(a)
Audio Detector
PPG
Gyroscopes
Motion Sensor
PDA
EMG
BG sensor
Temparature Sensor
Mic
Monitor
BP
Motoin ECG Sensor Sensor
RFID reader
(c)
Temparature Sensor BSN Smart Phone
Smell detector
Smoke Detector
Reminder System
Inertial sensor
PPG Sensor
(b)
Figure 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.
Figure 3: There are different types of ambient devices and white goods are installed in AAL system including BSN that generate valuable context. Some sample devices are illustrated in here.
the computational burden from these sensors so that they can perform their task for longer periods and more quickly. Body sensors measure user’s body and activity related information. To detect other conditions of the environment some environmental devices, ambient sensors, smart sensors, and communication devices are also deployed in AAL system (Figure 3). The wearable sensors and ambient devices have appropriate wireless or wired connectivity to a local workstation (LW) in the AAL environment. LW is responsible for collecting sensor data using suitable communication protocols and forwarding them in 8
the cloud infrastructure. Body sensors and other devices collect medical data regarding the status of the user. For example, wearable sensors communicate using blue-tooth to a mobile phone or using zigbee to a PDA which then forward the data to the LW using WiFi (Figure 4). Even sensors can directly send data to the LW using blue-tooth. It is based on the availability of a suitable communication medium between the pairs. As example, more power consuming device like Monitor is connected using the Local Area Network, cameras are connected using USB and so on. Raw data Sensor data
Cloud gateway Bluetooth
Wifi
BSN
Cloud Gateway
Service Providers
Context Providers and Aggregator
rules
Contex-aware Middleware Cloud
raw data
Context aware service
LAN
ontology
medical data
Medical data
context
social netwok and monitoring system
Assistive Actions
USB
person in assisted living
self-adaptation Cloud Gateway
Person in AAL
Local Workstation
Figure 4: Data Acquisition The raw sensor data produced by body sensors and other devices are transmitted to Local workstation using connected medium. Local Workstation then forward the data to Cloud Server using Cloud Gateway.
Figure 5: Data flow in a single AAL: Raw data from AAL system is converted to context by Aggregator Cloud. Service Provider Cloud contains the cloud storage for service rules. Context-aware Middleware Cloud manages incoming context and find assistive actions. Then it responds back to AAL system as Context-aware Service.
Each sensor and device has a unique identifier in the local system so that LW can distinguish between incoming data of different sensors and devices. A data collector program in LW periodically collects sensor data. The program then passes the collected sample with device information to the cloud gateway using an optimized sampling rate. Every device sample contains a complete set of information. Finally, collected data is uploaded to cloud servers using a cloud gateway. Figure 5 illustrates the abstract system architecture of our framework for single AAL system. Simple and lightweight communication protocols (like web 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 sensor data into context. The amount of information that can be categorized as a ‘context’ in AAL system is an extremely large set. Several levels of data abstraction are required to get exact context value. Moreover, different feature selection techniques are required for different sensor data. For example, classify user activity from accelerometer data and classify user heart condition using ECG cannot be solved using the same classifier. Thats why our system has a large number of context providers which run their own feature selection, classification, and fusion algorithm to find the context. 9
services
Service
Context
Any classification problem which has a large input set is computationally expensive. The system needs to be properly trained to extract the features for classification. Existing healthcare systems use local servers to solve specific classification problems like user activity recognition, fall detection, health monitoring, etc. An efficient classifier requires huge data storage and memory to effectively find the features. If we can utilize the cloud platform for such computation then it will minimize the burden from the local servers. Each of the context providers in our system run as cloud services which collect raw sample data as input and respond back with classification output using SOAP based web service. Context providers are distributed in cloud structure. There are several classifiers used in context-aware computing for classifying sensor data like: ANN, Naive Bayes classifier, K-means clustering, HMM, C.5 Decision Trees, and others [50, 51]. When classification is unknown, unsupervised learning is used. Sometimes fusion is required to obtain an overall classification result. The context provider uses the best classification technique for identifying the context. Figure 6 shows the general flows performed by a classifier of the context provider cloud. In our model many context providers can be integrated easily. Recognition
Segmentation Raw Sensor data
Pre-Processing
Sementation
Feature Extraction
Acceptable Features
Yes
Strat and End Point Detection
Classification
High Level Feature
No
Figure 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 block can be different based on input and output data.
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. The aggregator has computational logic for context integration and interpretation. It is a distributed cloud service and responsible for the following operations of the system: • Collect incoming sensor data from various AAL systems. • Separate the data for sending it to respective context provider to obtain the context classification. • Track the identification of AAL systems, particular devices of AAL systems and context providers. • Collect high level output as context from different context providers after classification process. • Same context can be reported by different providers. Context aggregator resolves conflicts among duplicate data. • If same context has different value from different providers then it performs a performance score calculation through context provisioning to pick up the best and reliable context value. 10
• Aggregate all the context information in a single context model against a particular AAL system. • Send the context model to Context-aware middleware Cloud for finding contextaware services. Context providers perform the primary abstraction and that is followed by the reasoning mechanism in the context aggregator to convert it suitable information. This is the standard information that can be recognized by all the entities (sensors, context providers, and service providers) of our model. It is required for interoperability between data information from sensors and service providing entities. 5.2.3. Context Modeling Context is part of is part of
is part of
is part of
Person
has
has Characteristics
is a is a Habit
Interest
has
Diseases
is a is a
Place
owns by
Location Longitude Latitudue
has
is a
Social
High Blood Pressure
Consultants
Doctors
is a
is a
TV Monitor
Accelerometer
Smoke Detector Camera
is a is a
is a Role
Alzheimer
ECG Sensor
Mobile Phone
is a
is a Friends
is a Diabetes
is a
is a is a
Temparature Humidity Light Noise DateTime
Health
has
Preference is a
Device Environment
Age Sex Name Weight Height
Family
is a Blood Pressure
is a Heart Beat
Oxyzen Level
is a
is a
Temparature
Accelaration
Figure 7: Context Model using OWL Each of the context entity has some attributes to describe some basic properties of the entity. Some are composed from parent entity. Such as Characteristics, Diseases, Preference, Social and Health ontology is composed of Person ontology. Each of those entities has some more children to describe them. The relation among different entities is also shown here.
A major aim of the research is to find a unified context model so that any context and context-aware services of AAL systems can be designed easily using the model. Without a well-defined, clear and flexible information model applications will not be able to use such information in an efficient way. The model must be rich and flexible enough to accommodate not only the current facets of context information, but also future requirements and/or changes. The model is domain independent but depends on providers services. Most of the existing context models focus on special aspects, where we focus on generalized model design which can ease context-aware service composition in assisted living. The context model is an organized structure that is formed by the aggregator cloud after identification of the key contexts. It defines the context information that is storable in a data source, retrievable using simple query and transmittable using a suitable format. It contains a list of topics with respective attributes. The topics are structured hierarchically. The context model is also a suitable place to specify, which context information is transient and which is persistent. The context model only needs to be evolved 11
if new context information is processed by the system, e.g. when a new sensing device is added or eliminated. In our architecture we adopted the ontology based context model [52] [53] because it is one of the well accepted context models for Ambient Intelligent (AmI) systems. Figure 7 shows the proposed ontology based context model based on OWL ( Web Ontology Language). The context space is described in 4 major entities: • Person ontology is used to identify the user of the AAL system and his profile, diseases, health conditions, doctors, social interactions 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 for making decisions for assistive actions. • Device ontology contains the details of the body sensors and devices of the system. This kind of abstraction described above is easily extendable and modifiable. Using this model it is easy to derive new knowledge about current context and to detect inconsistency in context data. Ontology makes reasoning tasks simple. The model is also helpful for service providers to define rules for services. Moreover, it is convertible to XML in implementation level. XML is a flexible and platform-independent tool that can be used in different stages of the information representation. It is also suits for SOAP based communication. 5.3. Service Providers Cloud SPs contain the cloud repository of different kinds of services. In our model service providers (Figure 5) subscribe to context-aware middleware cloud structure and provide service rules using the context model which is deployed in cloud structure. It can be a software service which is deployed in cloud (SaaS) or the infrastructure for delivering services (IaaS). The services are described in the rule-based model using our ontology abstraction. Inside the rules of SPs the list of assistive actions that required for observed conditions are integrated also. SPs hold this information and deliver this to the context manager on request by means of the cloud service. Some typical examples of services in AAL systems include software service, emergency assistance service, autonomic service, comfort service and symptom detection service. The same type of services can be different for different patients. The treatment of the same disease for a cardiac patient and for a diabetes 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 services in a single machine. If every services are deployed in the cloud there will not be any problem of resources. Besides, if all the service can be described using a unique model then it will make the service-mapping task easier. Table 3 shows the service rules of detecting possible heart attack by using our ontology model. SPs can easily add or modify a rule using the simple query mechanism. Like this one a numerous number of distributed service providers can offer their services using our cloud model. If a context sample contains such a pattern as described in Table 3 and the CMS of our model detects this then it picks the assistive actions described for 12
Table 3: Service rules of detecting possible heart attack
Ontology Person Person Person Device Device Device Device Device
Instance User X User X Disease ECG Sensor BP Sensor PPG Sensor Audio Sensor Camera, Radar, Accelerometer
Raw data Profile Profile Profile ECG wave BP readings Sensor readings Sound wave Video, Images, 3D Acceleration, Motion path,
Context Attr. Age Weight Cardiac patient Heart Rate Blood Pressure O2 consumption Breathing Motion
Value ≥65 ≥80 Have Cardiac issue Abnormal Normal or High Low Irregular Tripping or falling or flailing of arms or any rapid motion
this service from provider’s data storage. The consequences of the events happen locally inside AAL system but the actions are mentioned in assistive response. Table 4: Example of some assistive services, their rules and the provider of the service
Service Type Autonomic (Energy Saving) Software (Medication Reminder) Comfort (Search Friend)
Emergency (Fall Detection) Symptomp Detection
Rules (?user status : sleeping) ∧ (?room light status : on) → ACTION : Turn off light (?local time : 5:00 PM) ∧ (?medicine Y time : true) → ACTION : pop-up mobile app for medication reminder (?location : study room) ∧ (?Personal Laptop : on) → ACTION : Speaker suggest using voice to use site X for finding (?user status : lying down) ∧ (?fall detector status : on) → ACTION : Alert emergency assistance (?skin temparature : high) ∧ (?breathing : abnormal) → ACTION : fever detected. Alert Personal doctor.
Providers Power Saver Software application Socail Context Providers
Emergency Provider Personal doctor
There are different AAL platforms for generating services, for example, OpenAAL [54]. OpenAAL is a framework that supports integration and communications between AAL 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 appropriate service provisioning mechanism [55]. Once a service rule is retrieved it can be easily described by our 4-entity based context model with assistive actions. 5.4. Context-aware Middleware (CaM) The high level context model that is prepared by the context aggregator 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 and services from SPs cloud. It stores the context which is required for future use. Then utilizing existing knowledge and incoming context the CaM identifies assistive services for the given context. It then immediately transmits the context-aware actions to the 13
Service
associated AAL system. The context-aware cloud acts as a decision support system for the whole model. 5.4.1. Context Management System (CMS) A Context Management System (CMS) interacts with different distributed components and binds operations of each individual component together in the CaM cloud. Context manager (CM) contains the repository of context that is gathered from different AAL systems by adopting the IaaS properties of cloud computing. IaaS encompasses the storage, computing and network for the CMS. CMS is the main component of our SOA where the medical information of the AAL user is stored, analyzed, and accessed. CMS dynamically scales the storage resources via on demand provisioning. It is in charge of handling requests from AAL systems via aggregator cloud from where it obtains context information and relates the contexts with services defined by SPs. Since it contains sensitive medical information, it maintains different public and private cloud for storing and accessing data. CMS applies intelligent matching criteria to find the assistive actions for current context. The CM is self-adaptive in nature. It measures the performance to detect the best possible assistive actions for a context sample. 5.4.2. Context Storing A distributed cloud repository ensures the persistency of context information (Figure 8). It contains up-to-date data and relevant context of the AAL user. CMS stores context as an expandable knowledge-base of ontologies (described previously). All the attributes are stored as key-value pairs in different ontology containers which simplifies querying the instantiations. Each of the AAL systems has a unique id and all the devices in an AAL system also have some specific id to differentiate between incoming context data. To help the monitoring service it is useful to store recent context and to retain previously received context. Rarely used and old context 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 AAL system via the context aggregator. The context information request is triggered by the context manager itself periodically. Third party providers, monitoring services, and social networking services can also initiate context requests from storage. Any component request context to the context manager through a web service running in the cloud server with AAL system id and attributes set of context. After filtering the duplicate and unwanted context a service in the CMS retrieves related information and returns most relevant and accurate information. 5.4.4. Context Manipulation Most of the context manipulation is done inside the CAP cloud. Inside the CMS a context transformer impacts on changes of certain information. For instance, body temperature expressed in ◦ C scale can be transferred to ◦ F scale using the mathematical transformation rule. In addition, CMS performs context derivation tasks like finding a city from longitude and latitude information. Context manipulator also requests missing 14
context from AAL system via the context aggregator when required, and combines that context with retrieved information. Cotnext unavailability requested from neighbour
Listing 1: A snippet of context XML < contextML > < AALSystem id = " 1001 " / > < timestamp > 2012 -11 -08 T12 :23:56+11:00 < expires > 2012 -11 -08 T23 :21:56+11:00 < contextProviders > < contextProvider id = " 3 eq32dfs " / > < contextProvider id = " 1 eq32daa " / > < context > < person id = " 421332 " > < name > Alice < gender > Male < age > 68 < health > < blood_pressure > High < skin_temparature > Normal < diseases > < disease > cardiac < disease > alzheimer < place > < location > Bed Room < environment > < temparature > 25 C < humidity > 40% < device > < camera id = " cs221 " > active < Monitor id = " T3234 " > off < ECG_sensor id = " S2312 " > < heart_rate > normal < ECG_sensor id = " S2312 " > < heart_rate > normal < Accelerometer id = " A5406 " > < activity > walking
CMS 1
cotnext
CMS 4
CMS 3
SP
medical history
service map engine
service discovery engine
SP
CMS 2
storage unavailability forwarded to neighbour having more storage capacity
SP
SP
context manipution engine
context retrival engine profile ontolgy
Distributed Context Management System
Distributed Service providers
Figure 8: Dynamic scalability of distributed CMS: A snapshot of how the CMS of CoCaMAAL works.
Listing 2: An example of service XML < serviceXML > < ServiceProvider id = " weq9wq4234 " / > < service > Detect possible heart attack < context > < person > < health > < blood_pressure > High < heart_rate > Abnormal < O2_consumption > Low < Diseases > < disease > cardiac < result > Talk With user < actions > < action > Turn on Monitor < action > Turn on Speaker < action > Turn on MIC < actions >
5.4.5. Service Mapping The most important role of the context manager is to map context data to a respective service so that it can find the assistive actions to accomplish those services. The context model that is generated by our proposed ontology can be converted to a XML like Listing 1 with attribute values. A service profile also can be described using similar XML structure as shown in Listing 2. The CMS matches the context with possible services by comparing the value and calculating the weighted score matrix of the possible match. It then picks the best possible matches and combines them in assistive actions. Both the context-model and service-model can be represented in a tree structure like Figure 5.4.5. The root of the tree in level 0 is context. In level 1 there should be 4 main entity nodes: person, environment, place and device. The value nodes are located in the lowest levels that have no child node. The problem is to find the list of similar paths in the context-tree which are the list of services described in service trees. 15
Figure 9: Context Tree: Every context sample and services of our system is converted to such context tree to find the service mapping
Context
Device
Person Place
Enviro
path
Let CM have the knowledge-base of M services in service repository. CT is contexttree for current context data and {ST1 , ST2 , ......, STi , ......, STM } are context trees for M services {S1 , S2 , ......., Si , ..., SM }.Our matching criteria is, if any sub-tree is found in CT which is exactly or mostly similar like tree, STi then Si is a context-aware service for the context C. So, the actions item described in the structure of Si is picked which is the assistive action for Si . The matching operation is performed for all the M tress and all the actions are combined in a single XML structure. Then CMS responds back to AAL system with the action list. NS − CT are the list of nodes and ES − CT are list of edges. Similarly, S − STi =(NS−STi ,ES−STi ) is a sub-tree of STi . To find the similarity between to S − CT and S − STi we first need to find the similarity between the root nodes of S − CT and S − STi and then progress through the nodes of sub-tree upto child nodes recursively. At the lowest level of tree it just matches the higher level context values. The similarity between two nodes NCTx in CT and NSTiy 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 ). So, w of that case is 0 or 1. If w = 0 for any parent node then that sub-tree is skipped from the matching as that is not requires. For the child node w value can be between 0 to 1. 0 < w < 1, when child node value is numeric and numerical compassion is performed between node value. So, if STi have z nodes which are exactlysimilar or nearly similar with CT then the wST i1 wST i2 similarity matrix of STi , WSTi = ... where 1 ≤ i ≤ M wST iz Among z nodes lets p nodes are child node and rest z − p nodes are parent node. Since, all parents node similarity values Ppare 1, we consider only child nodes for calculating score matrix of WSTi , scoreWST i = j=1 wST i j . The score matrix of all services,
16
scoreST 1 scoreST 2 scoreS = ... scoreST p Therefore, the CMS picks the services and related actions with good score values. 5.4.6. Self-adaptation When the CMS calculates the similarities between context and service structure, it can identify a set of actions and enrich the knowledge base by storing this information inside the cloud repository. When the same pattern in the context is detected, it can able to response faster than before. Furthermore, when any providers update their information, the CMS synchronizes the database accordingly. Because a change in service means a change in the service context tree and the context manger needs to recalculate the score of service for a context sample. As Example, from AAL1 the CMS has identified list of services {S1 , S2 , ..., Sn } and corresponding actions {A1 , A2 , ..., An } for a context tree CT1 and stored that information in the context cloud repository. Now if the same context-tree appears from AAL1 then without performing mapping the CM delivers the actions from its past knowledge. If another AAL system AAL2 request services with context tree CT2 , nearly similar like CT1 then the CMS can easily pick the actions required for CT2 and delivers it without performing additional mapping. As a result, CMS can acknowledge faster by self-adaptation. 5.4.7. Service Discovery All the assistive actions are not described by service providers. In some cases CMS builds compound services from composition of existing services. This is known as service discovery in the system. 5.4.8. Security Service The health related context that is collected, processed and managed inside cloud is sensitive. The security service inside CMS will ensure the privacy of context information that gathered from different AAL systems. Different solutions are proposed to protect personal health information [9, 56, 57] in distributed cloud environment that ensure the privacy of the services. Context-aware role based access control and privacy preserve context 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 are event-driven but also requires manual tracking in some cases. In CoCaMAAL we suggest different kinds of web interfaces for managing context-aware middleware. These kinds of interfaces 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 published in a social network of doctors. Thus, doctors have up-to-date health status of patients. We believe that such type of monitoring UI services are easily adoptable in our model. But the in depth analysis of such services is beyond the scope of this paper. 17
Service Providers Cloud Context Providers Cloud
After receving assistive response, turn on the conversation session with user using Monitor, Speker and MIC
Activity Recognizer
PPG data classifier
Context: User Activity
Audio/Video Stream
PPG
cloud gateway
BP
Monitor
ECG data classifier
Signals
API HTTP
Context Aggreagator Context Integration
raw data
Context-aware Middleware (CaM) Cloud
Context: User diseases and Profiles
CMS
Web Service
Context and Service
---------
local data store
Raw data files
Service Data Store
Context: Blood Pressure
Smart Phone
Context model (Ontology)
RFID reader
Service: heart attack detection
Context: O2 Cosumption
Context: Heart Rate
data stream
ECG
Speaker Mic
BP data classifier
match service
match found
assistive actions for possible heart attack
User Activity Image
Context Data Store
Context model (XML)
Data Collector running in Local Server Camera
User location information
Sevice: C
Sevice: B
Sevice:A
Web Service cloud gateway
------
heart attack symptom detected
User Medication information
Figure 10: Evaluation: The experimental setup of simulated model for evaluating the case studies described in this section.
6. Case Study The major objectives for building the system described in this paper are: • Detect current situational information of the elderly user under assisted living from various context sources. • Aggregate the information in a meaningful context model. • Manage the context in distributed cloud environment. • Find related services from service providers depending on the context to assist the user. In accordance to the CoCaMAAL functional components described in previous section we have developed a simulated prototype, implemented mostly in Java, to show the feasibility of the proposed model. The elements of this simulated model are presented in Figure 10 and the setup of the home domain is described in Table 5. We have synthesized numerical values from realistic observation of medical data (e.g., heart rate is 65). The generated values represents raw data of ECG, PPG, BP sensor and accelerometer. Four rule-based classifiers are developed as context providers (as in 10) to classify those numerical values to high level context (e.g., user activity is sleeping [58], heart rate is high). All those data are aggregated using our java implemented context aggregator and finally the context model is generated using suggested ontology. 18
Table 5: The components considered in the experimental setup of simulated prototype.
User locations Body Sensor Network Devices of Living Room Devices of Bath Room Devices of Kithen
Living room, Bathroom, Kitchen ECG sensor, PPG sensor, BP sensor, Accelerometer, RF tags RFIDs, Camera, Mic, Speaker, TV, Emergency Alarm RFIDs, Mic, Speaker RFIDs, Mic, Speaker
Table 6: Aggregated high level context samples
No 1 2 3 4 5 6
Time 23:10:12 10:11:45 09:42:78 01:43:21 05:22:34 19:17:28
Heart Rate Normal High High Normal High Normal
O2 saturation Normal Low Normal Normal Low Normal
Blood Pressure Normal High Normal Normal High Normal
Location Living Room Living Room Living Room Living Room Bath Room Kitchen
Activity Watching TV Sitting Excessing Taking Medicine Fallen Down Cooking
We have randomly generated 3000 samples for single user scenario considering sampling rate of 10 minutes. Each sample contains different physiological parameters, current activity, time and location of the user. A piece of such sample data of is presented in Table 6. User specific information (i.e., medication time, disease, age etc.) are stored in MySql database. We also created 10 service providers (sp1 ,sp2 ,...,sp10 ) and distributed 67 different fuzzy rules among them. The rules are stored in XML files ( as in Listings 2) including the list of possible actions for context matching. Log entries 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 in Table 6) is processed inside the CMS one by one. After rule matching and service mapping process described in section 5.4.5 CMS selects the best possible services from multiple SPs. Table 7: Components developed for simulated prototype
Model Component Wearable Sensors Data Collector Context Providers Context ontology Context Aggregator CM Repository Service Providers Service Mapper
Simulated components Java Servlet as Numerical Data Generator Java Servlet Java program running in GAE OWL Java program running in GAE Static database Static XML in different web servers Java program running in GAE
Development Platform Java thread in Tomcat Server
Output format Data files
Java thread in Tomcat Server API using GAE GAE Data Source for ontology containers API using GAE GAE Data Source GAE web server
Data files High level context Context model
API using GAE
19
Context model as XML Database records Simple service rules with actions. List of assistive actions as XML
We used Java for prototyping and Google App Engine(GAE)[59] for evaluating cloud infrastructure. GAE is an open source cloud computing platform for developing and hosting applications in Google managed data centers. Table 7 summaries the different software tools we used to simulate the components of the CoCaMAAL model and to examine the following case studies. • Case Study 1 1. 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 profile database disease context is also included (i.e., cardiac disease and hypertension) in the information. 4. After rule matching step CMS finds 21 services stored in different service providers. 5. CMS picks the best possible services (using technique stated in Section 5.4.5). 6. CMS reports heart attack symptom as detected service. From location and activity context the CMS detects that user is sitting in living room (No 2 of Table 6) and according to the setup of the domain the living room contains speaker, microphone and TV Monitor (Table 5) for communication. So, the CMS appends communicate user with voice as assistive actions in the response. This response is converted to XML and sent to the tomcat server running inside AAL system as SOAP response. 7. The server receives the response and sends appropriate command to turn on the monitor and speaker ( In simulated model a flag is set in the class object of the device). 8. The voice conversation with user is question-answer session. The questions are picked from service providers and appended at the time of generating service response. A sample question is “Are you feeling Chest pain?” [60]. 9. The recorded conversation (as voice or video) is sent to the context aggregator to obtain more specific context like Chest pain is true. (In case of the simulated environment it selects a random answer). 10. The CMS run another service mapping with new context (Chest pain) and picks new service actions based on context value. (For chest pain true value it picks the service ”risk of heart attack”) • Case Study 2 1. CMS received the context generated in step 3 of case study 1 and requests some more context like ”taking medicine activity for the day” from context history database. 2. RF reader of the living room tracks user’s medication [61, 62]. If user does not take medicine in time the system logs this event in context history from status of RF reader. In our experiment, the CMS detects this event from a retrieved entry in the database. So, after rule mapping it picks medication reminder service and as assistive actions it reminds user to take his medicine properly. • Case Study 3 20
1. As in sample 5 of Table 6 from context the CMS detects that user’s physical condition is not good and fallen down in bathroom [63, 64] 2. CMS identifies the situation as ”Emergency Service” from service mapping. As assistive action it notifies server to bell emergency alarm in the house so a nearby neighbor can come to help him and also send automated emergency alert to doctor using sms. 7. Experimental Results We first evaluated the model for single AAL system with different context and service load. For each of the case, the average service response time (Tresponse ) is calculated. The time starts when raw data is sent to CoCaMAAL aggregator cloud from local server and ends when AAL system gets service response. So, Tresponse includes context processing time, service mapping time, and service delivery time. Tresponse is measured by increasing the number of context sources, service providers, and services. The result is shown in Table 8. We also measured the service mapping accuracy to ensure, the system is picking correct services for a scenario. To compute the accuracy we compared the observed results with expected services and made true/false decision for it. For 21 contexts with 67 services in 10 service providers and 3000 samples the measured accuracy was 96.34%. Table 8: Average Service Response Time for different Context, Service Provider (SPs) and service load. **Note that in the 2nd column of item 2, 1 and Activity refers to Activity, Location and Time including Physical parameters of row 1 and so on for other rows of row column
Item Context Domain 1 2 3 4 5 6
Physical parameters 1 and Activity, Location, Time 2 and Environment 3 and User Profile 4 and Context History 5 and Device Status
Number of Contexts 4 7
Number of SPs 1 3
Number of Services 10 21
Tresponse
11 14 16 21
5 7 8 10
35 43 54 67
23 28 30 31
18 ms 21 ms ms ms ms ms
The above results prove the benefit of CoCaMAAL model in terms of selecting correct services for a given context in short time. To measure the performance of CoCaMAAL model with large number of AAL systems we adopted M/G/1 queuing system with FCFS [65]. In M/G/1 the inter-arrival time of request is exponentially distributed, the service time is generally distributed and the total number of processing server is 1. The model is presented in Figure 11. The model can be extended to a M/G/c queuing system [66]. Computation of M/G/c is much complex and beyond the scope of this paper. For the sake of simplicity, here the whole CoCaMAAL model is considered as single ultra-fast processing unit of M/G/1 model to serve n number of AAL systems. So, here the number of processing server, c=1 and the processing of k different requests are distributed in k different nodes of this very ultra-fast processing server. Our goal is to find the mean response time of a request. 21
Table 9: General distribution of Service Time of 5 different sets for k=10 and λ= 2 sec
AAL-1
Service Rate
Reuest Arrival Rate
Set AAL-2
Context aware Services
1
CPs SPs
S2
2 AAL-3
CA
CMS
CoCaMAAL
S1
S3 k
S4 Number of Processing Nodes (k) AAL-n
S5
Si Ti Si Ti Si Ti Si Ti Si Ti
Si in % 22 17 20 10 28 20 38 20 25 19 12 30 21 18 12 40 22 15 33 21
and Ti 14 12 15 30 11 11 25 15 14 12 28 55 16 10 55 15 12 12 12 16
in milliseconds 9 8 6 5 80 45 18 50 10 7 5 5 40 21 27 35 10 6 6 4 62 40 10 17 9 9 8 5 10 20 50 35 10 7 7 6 40 55 42 44
ρ 4 90 2 85 2 29 3 25 6 24
Figure 11: The M/G/1 queuing system of CoCaMAAL model
If the number of requests from n AAL systems is 120/minute then service request rate is a Poisson process with mean, λ = 120 60 = 2 requests/sec. The service response time depends on the size,type and value of the context. Here service time is generally distributed with mean µ1 sec and variance σ 2 The average service time to process a request is, k
X 1 = E[S] = Si Ti µ i=1
(1)
Where Si percent requests are processed in Ti seconds and k is the number of request types. The variance, σ 2 = E[s2 ] − (E[s])2 . In our evaluation, we considered 10 request types. So here, k = 10 and for Si percent requests, services are selected from context with overall mean processing time (inside CoCaMAAL) Ti ms. The distribution for 5 different configurations ( for k=10) are presented in Figure 9. The processing of the request containing large data (i.e., image) takes longer time than the processing time of sensor data (i.e., accelerometer data). So in Table 9, different percentage of the requests have different processing time. For example in case of S1: Using equation 1 we got, µ1 = E[S] = 31 ms = 0.031 sec Variance σ 2 = E[s2 ] − (E[s])2 = 0.000538 sec2 . Utilization, ρ = µλ = 2 × 0.031 = 0.062 According to Pollaczek-Kinchine formula [65], 2 +λ2 σ 2 Average number of requests, L = ρ + ρ2(1−ρ) = 0.0652 L Average response time of a request, W = λ = 0.0326 sec. ρ and W values for each of the cases is presented in Table 9. Here we found the service response is much faster in CoCaMAAL model with large number of requests when they are served by ultra-fast processing unit running on cloud. We also evaluated the model by varying the k and the λ and the results are in Figure 12 and 13. From the obtained result we find that CoCaMAAL model respond much faster with good service recognition accuracy even for large number of AAL systems. 22
3 40 1 70 2 72 1 95 3 82
W
0.062 0.0326 0.060 0.0311 0.062 0.0325 0.060 0.0315 0.062 0.0324
Observation 1 Observation 2 Observation 3
1
λ = 2 request/sec
0.5
0 1
0.2
0.036
Response Time, W
Average Response Time, W
1.5
0.035
3
4
5
6
7
8
9
10
Number of processing Nodes, k
Figure 12: The average response time(W ) vary with the distribution of service time in different processing nodes for different observations. Using only a single ultra-fast server with k processing slots the average response time (using same arrival rate) is very low for each of the observation. For k ≥ 5 the response time of each of the observation is nearly similar.
0.15
k = 10 E[S] = 0.012 sec
0.034 0.1 0.033 0.05
0.032 0.031
2
k = 10 E[S] = 0.031 sec
1
2 (a)
3
4
0
10
20
Reuest Arraival Rate, λ
30
(b)
40
50
Figure 13: (a) Using lower value of Request arrival rate (λ). (b) λ is high. That is request is arriving in high volume from massive number of AAL systems. Both for (a) and (b) the average response time (W ) increases with the increment of request arrivals. The response time is still very fast (only 0.11 sec) even with high request arrival rate(λ = 60).
8. Conclusion and Future Works In this work, we presented a generic architecture to support BSN-integrated Ambient Assisted Living (AAL) environments with context-aware service management systems using cloud computing infrastructure. We believe that the proposed model is a complete framework to support distributed features of context-awareness in AAL. We have started by describing the limitations of existing systems and the challenges that AAL users and healthcare professionals are facing in traditional computing model. Our system analyzed the issues related to scalability, cost, and support of heterogeneous services using a single model. We suggested the need of a suitable context model for the AAL system which is easily modifiable, reusable, adaptable, and extendable. We demonstrated our model by describing the setup and the major functionalities of the components and their communication standard. As part of an ongoing work, we are working on the robust implementation of each of the components of the model. We are also working on in-depth performance and accuracy measurements of the system. We ignored issues related to noise reduction in sensor data, conflicts in context, implementation of security and privacy, and reliability analysis. Also, we have not considered much involvement of the virtual world, social networking and monitoring system. So, as part of our future work, we are aiming to include these features. 9. Acknowledgment The authors wish to acknowledge the support of RMIT University and NICTA (National ICT Australia) of Victoria Research Lab for funding the research work presented in this paper. NICTA is funded by the Australian Government as represented by the Department of Broadband, Communications and the Digital Economy and the Australian Research Council through the ICT Centre of Excellence program. References [1] T. Kleinberger, M. Becker, E. Ras, A. Holzinger, P. M¨ uller, Ambient intelligence in assisted living: enable elderly people to handle future interfaces, Universal Access in Human-Computer Interaction. Ambient Interaction (2007) 103–112.
23
60
[2] J. Ye, S. Dobson, S. McKeever, Situation identification techniques in pervasive computing: A review, Pervasive and Mobile Computing 8 (2012) 36–66. [3] S. Kern, D. Jaron, Healthcare technology, economics, and policy: an evolving balance., IEEE engineering in medicine and biology magazine: the quarterly magazine of the Engineering in Medicine & Biology Society 22 (2003) 16. [4] F. Sufi, I. Khalil, Z. Tari, A cardiod based technique to identify cardiovascular diseases using mobile phones and body sensors, in: Engineering in Medicine and Biology Society (EMBC), 2010 Annual International Conference of the IEEE, IEEE, pp. 5500–5503. [5] P. Remagnino, G. Foresti, Ambient intelligence: A new multidisciplinary paradigm, Systems, Man and Cybernetics, Part A: Systems and Humans, IEEE Transactions on 35 (2005) 1–6. [6] A. Schmidt, Interactive context-aware systems interacting with ambient intelligence, Ambient intelligence (2005) 159–178. [7] A. Dey, Understanding and using context, Personal and ubiquitous computing 5 (2001) 4–7. [8] R. Buyya, C. Yeo, S. Venugopal, J. Broberg, I. Brandic, Cloud computing and emerging it platforms: Vision, hype, and reality for delivering computing as the 5th utility, Future Generation computer systems 25 (2009) 599–616. [9] D. Hoang, L. Chen, Mobile cloud for assistive healthcare (mocash), in: Services Computing Conference (APSCC), 2010 IEEE Asia-Pacific, Ieee, pp. 325–332. [10] F. Azzedin, M. Eltoweissy, S. Khwaja, Overview of service oriented architecture for resource management in p2p systems, The Handbook of Research on P2P and Grid Systems for Service-Oriented Computing: Models, Methodologies and Applications (2009). [11] P. Emiliani, C. Stephanidis, Universal access to ambient intelligence environments: opportunities and challenges for people with disabilities, IBM Systems Journal 44 (2005) 605–619. [12] K. Johnson, A. Bamer, K. Yorkston, D. Amtmann, Use of cognitive aids and other assistive technology by individuals with multiple sclerosis, Disability & Rehabilitation: Assistive Technology 4 (2009) 1–8. [13] F. Zhou, J. Jiao, S. Chen, D. Zhang, A case-driven ambient intelligence system for elderly in-home assistance applications, Systems, Man, and Cybernetics, Part C: Applications and Reviews, IEEE Transactions on (2010) 1–11. [14] T. Taleb, D. Bottazzi, M. Guizani, H. Nait-Charif, Angelah: a framework for assisting elders at home, Selected Areas in Communications, IEEE Journal on 27 (2009) 480–494. [15] F. Paganelli, E. Spinicci, D. Giuli, Ermhan: a context-aware service platform to support continuous care networks for home-based assistance, International journal 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, Network, IEEE 22 (2008) 34–42. [17] J. Hong, E. Suh, S. Kim, Context-aware systems: A literature review and classification, Expert Systems with Applications 36 (2009) 8509–8522. [18] T. Gu, H. Pung, D. Zhang, Toward an osgi-based infrastructure for context-aware applications, Pervasive Computing, IEEE 3 (2004) 66–74. [19] S. Baek, E. Choi, J. Huh, K. Park, Sensor information management mechanism for context-aware service in ubiquitous home, Consumer Electronics, IEEE Transactions on 53 (2007) 1393–1400. [20] H. Viswanathan, B. Chen, D. Pompili, Research challenges in computation, communication, and context awareness for ubiquitous healthcare, Communications Magazine, IEEE 50 (2012) 92–99. [21] J. Bardram, The java context awareness framework (jcaf)–a service infrastructure and programming framework for context-aware applications, Pervasive Computing (2005) 98–115. [22] N. Behlouli, C. Taconet, G. Bernard, An architecture for supporting development and execution of context-aware component applications, in: ICPS06: IEEE International Conference on Pervasive Services 2006, pp. 57–66. [23] S. Yau, F. Karim, Y. Wang, B. Wang, S. Gupta, Reconfigurable context-sensitive middleware for pervasive computing, Pervasive Computing, IEEE 1 (2002) 33–40. [24] Y. Oh, J. Han, W. Woo, A context management architecture for large-scale smart environments, Communications Magazine, IEEE 48 (2010) 118–126. [25] W. Kurschl, S. Mitsch, J. Schoenboeck, Modeling situation-aware ambient assisted living systems for eldercare, in: Information Technology: New Generations, 2009. ITNG’09. Sixth International Conference on, IEEE, pp. 1214–1219. [26] K. Henricksen, J. Indulska, A. Rakotonirainy, Modeling context information in pervasive computing systems, Pervasive Computing (2002) 79–117.
24
[27] D. Bottazzi, A. Corradi, R. Montanari, Context-aware middleware solutions for anytime and anywhere emergency assistance to elderly people, Communications Magazine, IEEE 44 (2006) 82–90. [28] G. Van Den Broek, F. Cavallo, C. Wehrmann, AALIANCE ambient assisted living roadmap, volume 6, Ios PressInc, 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) 1–18. [30] R. Woolrych, A. Sixsmith, Challenges of user-centred research in the development of ambient assisted living systems, Impact Analysis of Solutions for Chronic Disease Prevention and Management (2012) 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: Systems, Man and Cybernetics, 2006. SMC’06. IEEE International Conference on, volume 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 provisioning, Arxiv preprint arXiv:1105.2213 (2011). [34] A. Gill, D. Bunker, Conceptualization of a context aware cloud adaptation (caca) framework, in: Dependable, Autonomic and Secure Computing (DASC), 2011 IEEE Ninth International Conference on, IEEE, pp. 760–767. [35] A. Devlic, E. Klintskog, Context retrieval and distribution in a mobile distributed environment, in: Third Workshop on Context Awareness for Proactive Systems (CAPS 2007), Guildford, UK. [36] C. Rolim, F. Koch, C. Westphall, J. Werner, A. Fracalossi, G. Salvador, A cloud computing solution for patient’s data collection in health care institutions, in: eHealth, Telemedicine, and Social Medicine, 2010. ETELEMED’10. Second International Conference on, IEEE, pp. 95–99. [37] N. Fernando, S. Loke, W. Rahayu, Mobile cloud computing: A survey, Future Generation Computer Systems (2012). [38] S. Pandey, W. Voorsluys, S. Niu, A. Khandoker, R. Buyya, An autonomic cloud environment for hosting ecg data analysis services, Future Generation Computer Systems 28 (2012) 147–154. [39] E. Ekonomou, L. Fan, W. Buchanan, C. Thuemmler, An integrated cloud-based healthcare infrastructure, in: Cloud Computing Technology and Science (CloudCom), 2011 IEEE Third International Conference on, IEEE, pp. 532–536. [40] G. Fortino, M. Pathan, G. Di Fatta, Bodycloud: Integration of cloud computing and body sensor networks, in: Cloud Computing Technology and Science (CloudCom), 2012 IEEE 4th International Conference on, IEEE, pp. 851–856. [41] A. Pantelopoulos, N. Bourbakis, A survey on wearable sensor-based systems for health monitoring and prognosis, Systems, Man, and Cybernetics, Part C: Applications and Reviews, IEEE Transactions on 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, Pervasive and 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: Computer Communications and Networks (ICCCN), 2012 21st International Conference on, IEEE, pp. 1–7. [45] M. Rahman, A. El Saddik, W. Gueaieb, Data visualization: From body sensor network to social networks, in: Robotic and Sensors Environments, 2009. ROSE 2009. IEEE International Workshop on, IEEE, pp. 157–162. [46] G. Fortino, R. Giannantonio, R. Gravina, P. Kuryloski, R. Jafari, Enabling effective programming and flexible management of efficient body sensor network applications, Human-Machine Systems, IEEE Transactions on 43 (2013) 115–133. [47] K. Laerhoven, H. Gellersen, Y. Malliaris, Long term activity monitoring with a wearable sensor node, in: Wearable and Implantable Body Sensor Networks, 2006. BSN 2006. International Workshop on, IEEE, pp. 4–pp. [48] C. Otto, A. Milenkovic, C. Sanders, E. Jovanov, System architecture of a wireless body area sensor network for ubiquitous health monitoring, Journal of Mobile Multimedia 1 (2006) 307–326. [49] F. Bellifemine, G. Fortino, R. Giannantonio, R. Gravina, A. Guerrieri, M. Sgroi, Spine: a domainspecific framework for rapid prototyping of wbsn applications, Software: Practice and Experience 41 (2011) 237–265.
25
[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 virtual sensors in body sensor networks, Sensors Journal, IEEE 12 (2012) 583–593. [52] J. Mochol´ı, P. Sala, C. Fern´ andez-Llatas, J. Naranjo, Ontology for modeling interaction in ambient assisted living environments, in: XII Mediterranean Conference on Medical and Biological Engineering and Computing 2010, Springer, pp. 655–658. [53] A. Devaraju, S. Hoh, Ontology-based context modeling for user-centered context-aware services platform, in: Information Technology, 2008. ITSim 2008. International Symposium on, volume 2, IEEE, pp. 1–7. [54] P. Antonino, D. Schneider, C. Hofmann, E. Nakagawa, Evaluation of aal platforms 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: Cloud Computing (CLOUD), 2012 IEEE 5th International Conference on, IEEE, pp. 962–969. [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. 547–552. [57] M. Nkosi, F. Mekuria, Cloud computing for enhanced mobile health applications, in: Cloud Computing Technology and Science (CloudCom), 2010 IEEE Second International Conference on, IEEE, pp. 629–633. [58] L. Wang, T. Gu, H. Chen, X. Tao, J. Lu, Real-time activity recognition in wireless body sensor networks: from simple gestures to complex activities, in: Embedded and Real-Time Computing Systems and Applications (RTCSA), 2010 IEEE 16th International Conference on, IEEE, pp. 43–52. [59] D. Guermeur, A. Unruh, Google App Engine Java and GWT Application Development: Build Powerful, Scalable, and Interactive Web Apps in the Cloud, Packt, 2010. [60] A. Pantelopoulos, N. Bourbakis, A formal language approach for multi-sensor wearable healthmonitoring systems, in: BioInformatics and BioEngineering, 2008. BIBE 2008. 8th IEEE International Conference on, IEEE, pp. 1–7. [61] T. Suzuki, Y. Oyama, Y. Nakauchi, Intelligent medicine case system with distributed rfid readers, in: Engineering in Medicine and Biology Society (EMBC), 2010 Annual International Conference of the IEEE, IEEE, pp. 344–347. [62] A. Hristova, A. M. Bernardos, J. R. Casar, Context-aware services for ambient assisted living: A case-study, in: Applied Sciences on Biomedical and Communication Technologies, 2008. ISABEL’08. First International Symposium on, IEEE, pp. 1–5. [63] Y.-C. Chen, Y.-W. Lin, Indoor rfid gait monitoring system for fall detection, in: Aware Computing (ISAC), 2010 2nd International Symposium on, 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 care quality improvement, in: Multimedia and Ubiquitous Engineering, 2009. MUE’09. Third International Conference on, IEEE, pp. 477–480. [65] D. Gross, C. M. Harris, Fundamentals of queueing theory, ISBN: 0-471-17083 (1998). [66] L. Wang, R. Ranjan, J. Chen, Cloud Computing: Methodology, System, and Applications, CRC PressI Llc, 2011.
26
