1 Introduction

The widespread adoption of wireless sensor networks (WSNs) [1, 2] has enabled a wide range of pervasive computing and networking applications. These applications are based on the collection, processing and archiving of the data generated by sensing natural and/or artificial phenomena. In particular, a WSN consists of spatially distributed sensor nodes, which are coordinated by one or more base stations and cooperatively monitor physical, environmental, or human parameters such as temperature, sound, vibration, pressure, pollution, motion, heart rate, and blood pressure.

Sensor nodes in a WSN can generate a large amount of real-time, contextual data about a specific monitored area (e.g. agricultural field, city quarter, building, room, human body). The capabilities of a WSN do not only involve collection and forwarding of raw sensor readings, but also include in-node/in-network data processing (e.g. aggregation, fusion and merging) and, sometimes, in-network complex elaboration, such as event detection and object tracking based on sophisticated distributed classification algorithms. WSNs provide a technological push for the development of pervasive systems in a wide range of application domains. For example, they can be adopted to provide diversified services, ranging from building automation to industrial process monitoring, health-care analysis, weather forecasting, military situation awareness, emergency and disaster event support, traffic control, implicit social interactions among people.

Body sensor networks or body area networks (BANs) [3–5] are specific classes of WSNs purposely applied to monitoring the physical and medical conditions of individuals. BANs represent an emerging technological platform for many human-centered applications, ranging from medical to sports performance monitoring, gaming, and social networking.

Body area networks can be formed by a large variety of wearable sensor nodes providing important physiological measurements such as body temperature, heart rate, limb motions, blood glucose, blood oxygen saturation, electrocardiogram (ECG), electromyography (EMG), galvanic skin response (GSR), electroencephalogram (EEG), photoplethysmography (PPG). Algorithms processing such body sensor data streams can provide further important information involving activity recognition, emotion detection, sickness prevention and monitoring.

In healthcare scenarios, it is common that assisted livings are monitored by BANs to collect sensor streams not only to elaborate them in real-time through specific algorithms, but also to store them in remote medical data repositories. Depending on the signal characteristics, the sensing parameters and the rate of data production, this may imply that a huge amount of data needs to be transmitted, stored and analyzed. In a near future, BANs could also be used for implicit social interactions: private/public information can be exchanged through worn BANs when people come into contact (e.g. through handshake-based meetings or by waving goodbye) or are simply in proximity [6, 7]. Networks of BANs during public events and gatherings can be utilized as ad-hoc mobile sensor infrastructures to support context-aware pervasive applications, for example, involving the management of disasters, medical emergency and mass events.

A fundamental issue to deal with is the effective and efficient management of a large number of cooperative and non-cooperative BANs to support diversified pervasive applications. In fact, the huge amount of data that a network of BANs is able to produce, demands a powerful and scalable collection, processing and storage infrastructure to perform both online and offline analysis of BAN sensor data streams.

The management of networks of BANs, with their huge amount of gathered sensor data and their limited processing power, can be tackled by exploiting a Cloud computing infrastructure to provide an integrated platform, namely Cloud-enabled BAN infrastructure, that offers:

  • ability to utilize heterogeneous sensors through mobile devices acting as gateways;

  • scalability of processing power for different kinds of analysis;

  • scalability of data storage;

  • global access to the processing and storage infrastructure;

  • easy sharing of results;

  • pay-as-you-go pricing for using BAN services.

In this paper, we first aim at motivating the integration of BANs and Cloud computing to obtain Cloud-Assisted BANs (CABANs) able to cope with the main challenges posed by the management of large-scale networks of BANs [8]. We then survey the state-of-the-art related to Cloud/GRID-based distributed architectures for the management of wireless sensor networks, with particular emphasis on BAN distributed management systems. We also delineate a general reference architecture for CABANs which allows collection and dissemination of sensor data streams from BANs to a Cloud repository and performs processing and analysis of the stored data using software services hosted in the Cloud.

The rest of the paper is structured as follows. Section 2 discusses the motivations and challenges of the introduction of CABANs. Section 3 defines the requirements of CABANs along with a reference architecture. Section 4 provides an overview of the most recent state-of-the-art involving the integration of WSNs (and more specifically BANs) and Cloud computing. Moreover, it compares current WSN-Cloud architectures with respect to the requirements elicited in Sect. 3. Section 5 discusses some open research issues in building practical Cloud-enabled systems based on networks of BANs. Finally, Sect. 6 provides some conclusive remarks.

2 Motivations and challenges

The need of integrating BANs with a Cloud computing infrastructure can be motivated by discussing the following issues:

  • Data management. Raw or processed sensor data streams continuously generated by BANs need to be efficiently collected, stored and eventually conveyed for processing. Such data management may be distributed in time and/or space [9]. Time distribution refers to activities taking place at different times, while being coordinated to have a common objective. Space distribution means that activities may take place at different locations, while they are connected by a data network. A Cloud computing infrastructure can facilitate these data management functionalities through the provision of a seamless access to a large-scale storage.

  • Data processing. The collected data from a single BAN are usually processed to obtain higher level information and/or data cumulative charts. In the presence of a large number of incoming sensor streams from BANs, processing of data to produce critical information/decisions in real-time requires fast processing that may be very computing intensive. The exploitation of the computational resources of a Cloud infrastructure can fully support such demand of intensive computation power.

  • Data analysis. Annotated BAN datasets are imported into analysis tools and modeling is performed for further use in various applications and decision making systems. The analysis operations along with the enrichment hierarchy depend on suitable storage and middleware technologies to perform highly swift data processing. It can be availed by exploiting the processing power of Cloud to provide quick response. Moreover, workflow-oriented methods can be exploited to define effective processes to extract knowledge from the annotated BAN datasets.

  • Application development. The development of large-scale BAN applications is a complex task involving not only the programming in-the-small of the BANs worn by individual assisted livings, but particularly the programming in-the-large of an application able to coordinate the collection, storage and processing of distributed body sensor data streams produced by a community of individuals. To this purpose, SaaS approaches based on Cloud infrastructures coupled with efficient BAN frameworks can be exploited. It is important to define the specific paradigm that the SaaS approach is centered on. The service-oriented paradigm [10] is usually the most adopted on Cloud computing platforms as commonly provided at PaaS level by the majority of the currently available academic and commercial solutions.

While it is rather clear that there are main advantages of the adoption of BANs in various application domains, there are a number of specific associated challenges that need to be addressed [11]. Nevertheless, in this paper, we are specifically interested in the integration of BANs with a Cloud infrastructure that poses additional challenges related to data management, implementation and computing. In the following we first briefly enumerate the BAN-related challenges, followed by a more in-depth discussion of specific challenges regarding the integration of BANs with Cloud computing to perform effective distributed body sensor stream management and large-scale BAN application development.

Specific BANs challenges [12] include:

  • Wireless communications. BANs mostly use wireless connectivity for data communication. The wireless link should be able to reduce interference and increase the co-existence of sensor nodes with other networked devices. This is to ensure that the functionalities of BAN nodes are not degraded due to the presence of other devices capable of possible interruption in seamless data transmission.

  • System interoperability. A BAN system requires ensuring seamless data transfer across different standards to promote information exchange, plug-and-play device interaction and uninterrupted connectivity.

  • Sensor heterogeneity. A BAN system should be capable of integrating various different sensors in terms of complexity, power efficiency, storage, and ease-of-use. Moreover, it should provide a common interface between the sensors and a storage service to facilitate remote storage and viewing of sensed data as well as access to external processing and networked analysis tools.

  • Security. Transmission of BAN data streams should be secured to prevent potential intruders. Moreover, integrity of each patient’s data has to be maintained with guarantee that one patient’s data is not mixed with another patient’s data.

  • Privacy. One key concern of BAN users is to protect the privacy of personal data. A BAN system should ensure that patient’s privacy is maintained even when data is being analyzed using an external tool. In addition, social awareness and acceptance is required for wider applications of BANs.

  • Data validation and consistency. Data collected from multiple sensor nodes need to be collected and analyzed in a seamless fashion. BAN sensors are subject to inherent communication, hardware and network failures that may result in erroneous datasets. It is crucial that the sensed data is validated and data quality is maintained to reduce any noise in the data and identify possible weakness in the infrastructure.

  • System programming. Developing applications on BANs requires many efforts due to the lack of proper software abstractions and the difficulties in managing resource-constrained embedded environments. For these reasons, in the last years several frameworks and middlewares have been conceived and made available to support high-level programming of BAN applications. However, there is still the need of defining new paradigm and tools for a more effective programming of efficient BAN systems.

  • Development methodologies and tools. Apart from programming frameworks, the development of BAN applications needs to be tackled by exploiting specific software engineering methodologies able to support the development lifecycle of such systems: from analysis to implementation and deployment.

On the other hand, integration of BANs with a Cloud computing infrastructure poses the following major research challenges:

  • Interfacing the Cloud with BANs. There should be an interface between BAN resources and the Cloud fabric. Communication interfaces are to be built to manage network connectivity between BAN and the Cloud. BAN nodes may be exposed as Cloud services and indexed via indexing services. There also has to be provision to manage sensing jobs and data from the sensor networks. Virtualization will be a key technology. Moreover various services for the underlying sensor resources, such as power management, security, availability, and QoS, need to be provided.

  • Sensor stream management. Data management will include data format conversion into standard formats, data cleaning and aggregation to improve data quality, and data transfer to storage Clouds.

  • Massive scale and real time processing. Integration of heterogeneous BANs generating large scale of data is a challenge due to the amount of information that is required to be processed in real time. If BAN is used to generate real-time multimedia content such as streaming video, audio and images, it poses additional challenge to accurately process and store the data in a Cloud environment.

  • Complex event processing. Real-time data streams from BAN may trigger certain events and services in the Cloud. This data streams are analyzed and results are used in applications for decision making by identifying contextual and situational information.

  • Advanced off-line data analysis and analytics. While heterogeneous and real-time BAN data feeds allow improving decision making by using data and decision level fusion techniques, to maximize the intelligence that can be exploited from massively collocated information in the cloud is a challenge.

  • Large scale computing frameworks. The allocation of computational and storage resources as well as data migration in the Cloud is critical when multiple BAN data sources are not collocated. This is particularly challenging when the data sets and their corresponding access/search services are geographically distributed within the Cloud.

  • Development methodologies and tools. The development of large-scale BAN systems is a complex task that needs suitable and effective software engineering methodologies/approaches. Specifically, an application needs to be designed at a higher level of modeling abstraction, implemented according to a given approach and then seamlessly deployed onto the distributed Cloud platform.

3 A general reference architecture

A general reference architecture for the integration of BANs and cloud computing is portrayed in Fig. 1. To support this architecture, we have identified the following requirements:

Fig. 1
figure 1

A reference architecture for the integration of body area networks and cloud computing

Full size image

  • Efficient collection of sensor data streams from highly decentralized BANs.

  • Effective management of sensor data streams.

  • Configuration of a scalable framework to support processing of multiple sensor data streams for (even concurrent) application services.

  • Persistent storage and exchange of sensor data and analysis results to enable further decision-making.

  • Workflow-oriented decision making applications dynamically developed through distributed services/components mash-up.

  • Advanced visualization services (both for raw and processed sensor data, and for analysis results) that can be flexibly customized by the final users.

  • Three-level security for sensor data collection (from sensors to the coordinator), sensor data transmission (from the coordinator to the cloud) and data analysis/visualization services (cloud access).

We endeavor to define an environment supporting data collection and management, concurrent application execution, mash-up service invocation and data analysis for decision-making. For this purpose, we rely on a Cloud environment providing storage and Virtual Machine (VM)-based approach for computational processes. In the following subsections, we detail on the components of our reference architecture.

3.1 Sensor data collection

This component is responsible for capturing sensor readings from the acquisition hardware (i.e. the BAN sensor nodes), convert the raw values to meaningful measurements and store annotated data as necessary. A transport layer is placed to assist in collecting sensor data points across a large dimension in real time. This data acquisition is deployment dependent. As for instance, TinyOS SerialForwarder (for TinyOS 1.x and 2.x compatible motes) can be used to capture raw data directly from remote sensors. There can also be hardware specific proprietary APIs to read raw sensor readings directly from BAN sensors. Indeed, BAN middlewares are currently available for such purpose: CodeBlue [13], Titan [14], RehabSPOT [15], and, particularly SPINE [16, 17] and SPINE2 [18–20], provide high-level abstractions and mechanisms to capture, process and transmit sensor data to static and mobile basestations. Usually, a mobile device (also called mobile BAN coordinator) is interposed between a BAN and the cloud platform. It collects sensor data from the BAN and transmits them onto the Cloud platform. For instance, Android-SPINE, the Android version of the SPINE middleware [17], can be used to enable Android-based mobile devices, such as smartphones and tablets, to be the BAN mobile coordinator. In particular, data collected through Android-SPINE can be easily streamed up to the cloud side through an Internet-based connection. In Android-SPINE wearable sensors communication is currently based on Bluetooth.

3.2 Sensor data management

Once data are collected, they are passed through a data calibration process to ensure the validity and consistency of the streamed data. A Quality Assurance Quality Control (QAQC) framework, comprising statistical models, is applied to perform outlier detection, missing data handling, aggregation, detection of measurement changes (state), data transmission, automated data correction and data compression in streaming sensor data. A data calibration API should be provided to assist in the implementation of custom calibration functions or reuse third party data calibration packages. Indeed, data quality can also be verified at the sensor data collection side, at the sensor node [21] and/or at the mobile BAN coordinator. Once a calibrated data stream is available, it is fed to the application services running in the Cloud and also stored (with metadata annotation providing meaning of the data) in the storage Cloud resources for future usage. Moreover, such component needs to deal with a large number of streams of data arriving continuously from numerous sensors as they can swamp even the most robust servers designed for online transaction processing applications. The Cloud-enabled system should be extensible and re-targetable in such scenario. If newer sensing devices should appear, it will be straightforward to incorporate them into the system without major changes to the back-end server or to the services. When intermediate software components or operating systems are to be changed, the system takes care of the changes in a seamless fashion without minimal disruption to the service provided to end-users already using the system.

3.3 Scalable processing framework

Application services, such as ECG data analysis, health monitoring, sports performance monitoring, are hosted in a VM-based Cloud computing infrastructure. The communication between calibrated data streams and the Cloud infrastructure should be done through the use of non-blocking callback APIs. These APIs allows services to receive calibrated sensor data streams as data arrives into the system. As an application is executed inside a VM, a data connection is required to push the results of the experiment to the result-processing component. The APIs should be capable of buffering data streams within a time window in case the application service does not respond or the call back connection is lost. Thus, using persistent buffers in the Cloud to communicate between the BAN infrastructures and the application services hosted in the Cloud ensures users from any potential loss of data. Once an application generates an output, it is transmitted to generate continuous data streams consisting of the results. The output of each application execution is also stored in the persistent storage. Once an application generated an output, it is transmitted to generate continuous data streams consisting of the results. The output of each application execution is also stored in the persistent storage.

3.4 Persistent storage

The Cloud-enabled storage component is crucial for the CABAN architecture for storing data coming from (1) the data collection process, (2) the processed data streams, and (3) the data analysis outcomes. These datasets are persistently stored to be re-used either on-line or off-line.

The persistent storage component in the CABAN architecture is characterized by the following constituents:

  • Storage virtualization, referring to thin provisioning of the storage Cloud infrastructure, with the assistance of a management software layer, to automate data availability and security management. Encapsulated in an orchestrated workflow, storage virtualization assists in persistency and optimization of existing storage, and provisioning of new storage.

  • Enterprise resource management to reduce effort from administrators to manage heterogeneous storage Cloud infrastructures. Based on the administrator’s policies, the management software in the Cloud-based BAN gathers information for managing the storage environment.

  • Hierarchical storage management through a tiered storage infrastructure to manage growth and provide different levels of service to BAN users. It is used for storage space management through automatic data migration and transparent data restore in failure situations.

  • Archive management to provide BAN data retention over time as the stored data grows. Storage archives copy data for a dedicated time frame, defined by the CABAN administrator’s policies.

  • Recovery management is the ability to recover backup/archived data, ensuring sustained performance effective operational continuance. It assists in recoverability in a heterogeneous Cloud storage environment.

  • Interfacing APIs to interface with different components of the CABAN architecture. The exposed APIs allow abstraction to complex functionalities, feed input to application execution, data transfer in and out of storage, and run-time interactions.

In addition using application and workload specific tailored Cloud storage, based on commodity storage and/or enterprise-grade storage, CABAN architecture can make use of Google Bigtable [22] or Azure BLOB [23] storage. These Cloud storage services allow managing large-scale structured data across thousands of commodity servers, ensuring persistent data management and meeting latency requirements.

3.5 Decision making process

Upon the availability of streamed outputs, the result processing service/component informs internal (user-programmed) or external decision making processes (by reusing existing tools) about specific situations. This component can provide a set of user-defined policies, specific to a particular BAN scenario. Furthermore, a client application (decision making process) can register with the result-processing component in the form of making continuous query to gather continuous delivery of latest results. With the use of a continuous query, a client application can specify the window size, i.e. the amount of data used at the processing state, and sliding predicate, i.e. how frequent a continuous query is to be evaluated. Usually, the decision making process is workflow-oriented. Processed data from BAN are associated with meaning, confidence and quality information. Specifically, the data are associated with information on how they processed (derivation), for whom and why they were collected (agency), and how they may be distributed (rights). This process is performed through automatic formation of workflows and invocation of services. Such operational flow requires a platform to support automatic workflow formation and service invocation, potentially through a Cloud infrastructure.

3.6 Open standards and advanced visualization

Open standards for data and for workflow definitions allow input and intermediary data to be propagated through processing elements in data analytics and mining workflows. They also allow the workflow components to be exchanged and executed in distributed environments.

For example, the Attribute-Relation File Format (ARFF) [24] is an ASCII text file format that describes a list of instances sharing a set of attributes. The data-flow programming paradigm adopted in KNIME workflows [25] is based on an XML-based workflow specification format and on an intermediary data format that incorporates rich metadata information about the data attributes. The Predictive Model Markup Language (PMML) [26] is an XML-based open standard for the description and the exchange of models produced by data mining algorithms and for data manipulation and transformations.

However, there is no open standard for the representation and visualization of the data analysis results. A powerful visualization service is necessary, as the cloud computing environment stores and processes enormous amounts of data. The visualization service should provide various predefined and user-defined views on the data and analysis results. The visualizations and views can be implemented with heterogeneous languages like XML, OLAP/data warehouses tools, and/or specific graphical languages/frameworks. Separating the formal specifications of the visualization from the graphical primitives used to generate the views in a given client application is an important aspect for a Cloud-based distributed environment with a wide heterogeneity of the supported devices.

3.7 Security

Considering social, ethical and legal aspects of human-centered systems such as BAN systems, data in CABANs (i.e. data collected from BANs, and stored and processed/analyzed in the Cloud) are highly sensitive and should be managed properly to guarantee people privacy.

It is therefore crucial to define system-wide security mechanisms to guarantee confidentiality, data integrity as well as fine-grained access control to data and services.

We devise a three-level security framework for CABANs:

  • At the sensor data collection level (i.e. from sensors to the BAN coordinator) [27], data communication can be secured with a 128-bit AES encryption, for instance. However, wearable sensor nodes have limited computing and energy resources, and encryption is time and energy consuming so specialized in-node hardware needs to be exploited (e.g. 128-bit AES encryption hardware is included in the telosB crossbow sensors).

  • At the sensor data transmission level (i.e. from the BAN coordinator to the Cloud) [27], data streams can be transferred onto the cloud through TLS/SSL, which is a proven technology. However, new security mechanisms dealing with mobility need to be purposely defined [28].

  • At the sensor data management and access level (i.e. managing and accessing data and services on the cloud) [29], data stored and processed in the cloud computing infrastructure need to be protected by authentication and authorization measures, and can also be encrypted, if needed. Moreover, the cloud services used by different actors of the system need to be secured through specific access control policies.

As CABANs can support different application domains (from health care to crowdsourcing), specific National or Transnational security/privacy standards, e.g. normative on medical data treatment, processing and storing, should be introduced at application-level.

4 Existing solutions

Data stream management systems (DSMS) are among some of the most studied research subjects recently. These systems are designed to provide quick response time when dealing with large volumes of data, e.g. sensor observations. These systems employ window-based data processing combined with synopsis to process large volumes of data [30–32]. Using synopsis helps a DSMS in reducing the response time to queries. Global Sensor Network (GSN) [33], TelegraphCQ [34], Aurora [35] and Stream [36] are among some of the known works in this domain. There are also Internet-based streaming systems, such as Stream-based Overlay Network (SBON) [37] and Peer-to-peer Information Exchange and Retrieval (PIER) [38] that process and deliver data over the Internet. They rely on P2P model for data representation, query dissemination, operations and metadata management. There exist research projects to provide access, query, streaming, and management of WSN data. The Sensor Web project [39] provides a dynamic infrastructure that allows users to access sensor networks and stream data out. Sensor Information Networking Architecture (SINA) [40] is a middleware for querying, monitoring, and tasking of sensor networks. Tiny Application Sensor Kit (TASK) [41] is built on top of TinyDB to provide high level metadata management, query configuration, monitoring and data visualization. These systems are appealing as they address the challenges related to large-scale sensor resource and data sharing.

In the recent years, there have been an increasing number of initiatives to develop distributed platforms based on BANs for e-Health applications. Many national and international research projects in academia, industry and government focus on the development and deployment of health care platforms in which wearable sensors are attached to patients for enabling round-the-clock monitoring of vital parameters. Examples of such projects include CodeBlue [13], DexterNet [42], SPINE [16, 17, 43], SPINE2 [18–20], and Titan [14]. These systems provide programming abstractions from low-level TinyOS system programming, but do not address the issues of integrating a Cloud infrastructure to provide extended scalability, seamless data streaming and data analysis.

Recently researchers have investigated the integration of WSNs/BANs with large-scale distributed computing infrastructures. Examples include an integration architecture of Cloud computing and WSNs [27], Open Sensor Web Architecture [44], the Sensor-Cloud infrastructure [45], the BodyCloud architecture [46, 47], and so forth.

In [27], a SaaS architecture for sensor network analytical services is proposed. It is implemented atop a PaaS layer (e.g. Google App Engine and Microsoft Azure) and is organized in three layers: (1) sensor data management, which collect sensor data streams coming from the WSN gateway; (2) run-time for filter analysis, which supports the execution of processing workflows for sensor data according to the pipe-and-filter paradigm; (3) filter management, visualization and notification, which are three components that respectively allow for the definition and management of the processing filter chain, for the visualization of analyzed data, and for the notification of events to external applications.

Authors in [44] propose the Open Sensor Web Architecture (OSWA). OSWA is an OGC (Open Geospatial Consortium) Sensor Web Enablement standard-compliant software infrastructure for providing service-oriented based access to and management/integration of sensors. OSWA also integrates emerging distributed computing platforms such as SOA and Grid Computing. OSWA is designed around the conventional Grid layers: Fabric, Services, Development and Application. Specifically, the OSWA-based platform provides a number of sensor services such as sensor notification, collection and observation; data collection, aggregation and archive; sensor coordination and data processing; faulty sensor data correction and management; sensor configuration and directory service.

In [45], authors propose a new infrastructure, called Sensor-Cloud infrastructure, which can manage physical sensors on an IT infrastructure for sensors virtualization. The Sensor-Cloud Infrastructure virtualizes a physical sensor as a virtual sensor on the Cloud computing platform. Dynamic grouped virtual sensors on cloud computing can be automatically provisioned when the users need them through a portal server interacting with the workflow-oriented provisioning server, performing resource management, and a monitoring server, monitoring real/virtual sensors.

SAaaS [48] is a cloud-enabled SaaS architecture aiming at the management of wireless sensor and actuator networks (WSAN). SAaaS is a software stack that implement the following main functionalities: involvement of (W)SNs, smartphones or other devices endowed with sensors and/or actuators, and their enablement for interoperation and management in a Cloud environment; exploitation of Volunteer-based methods for node involvement; functions and interfaces for federating SAaaS Clouds, either volunteer-based or commercial/institutional.

The aforementioned works describe architectural models, case study and identify some related development issues. However, there is still a gap to develop a Cloud-based infrastructure that is targeted to BAN applications as the one delineated in Sect. 3. The following research works aim at tackling the fulfillment of such a gap.

In [49] authors propose the development of an autonomic Cloud environment for hosting an ECG data analysis service. In particular, they propose an autonomic Cloud environment that collects people’s health data and stores them to a Cloud-based information repository and facilitates analysis on the data using software services hosted in the Cloud. To evaluate the software design, a prototype system is developed, which is used as an experimental testbed on a specific use case, namely, the collection of electrocardiogram (ECG) data obtained at real-time from volunteers to perform basic ECG beat analysis. The ECG software is hosted as a web-service such that any client-side implementation can simply call the underlying functions (analyze, upload data, etc.) without having to go through the complexities of the underlying application. The PaaS layer controls the execution of the software using three major components: (1) Container scaling manager, (2) Workflow Engine, and (3) Aneka Cloud middleware.

In [29], a secure and scalable Cloud-based architecture for e-Health WSNs is proposed. The aim is to support (1) body sensor data collection from patients both hospitalized and at home, and (2) medical data management for e-Health monitoring. Collection is based on BANs worn by patients and mobile/static devices working as Internet-based gateways. A Cloud infrastructure is used for storing and retrieving the collected BAN data. Security protocols and mechanisms are defined to provide data security.

Finally, BodyCloud [46, 47] is a novel cloud-enabled system architecture that integrates BANs services with a Cloud computing infrastructure. In particular, BodyCloud is a SaaS architecture that supports the storage and management of sensor data streams generated by SPINE enabled mobile BANs [17] and the processing and analysis of the stored data using software services hosted in the Cloud. BodyCloud endeavors to support several cross-disciplinary applications and specialized processing tasks. It enables large-scale data sharing and collaborations among users and applications in the Cloud, and delivers Cloud services via sensor-rich mobile devices. BodyCloud also offers workflow-oriented decision support services to take further actions based on the analyzed BAN data. BodyCloud is fully compliant with the reference architecture described in Sect. 3.

In Table 1, the architectures for integrating WSN/BAN with a Cloud computing platform are compared with respect to the requirements identified in Sect. 3.

Table 1 Architectures for the Integration of Wireless Sensor Networks (or Body Area Networks) with Cloud Computing: a comparison
Full size table

Although, sensor data collection is provided by all architectures and is based on a (static and/or mobile) gateway device that gathers data from the body worn sensors and transmits them to the Cloud through an Internet-based connection, the exploited technologies are different at application, protocol and system level. It is worth noting that SAaaS uses a complex software framework at the gateway side called Hypervisor, which is able to manage not only sensor reading collection but also to control actuator devices.

Sensor data management is conversely based on different paradigms (data-driven pipes and filters, rule-based planning, virtual sensors, and workflow-oriented). However, SAaaS, ECGaaS and Cloud BAN e-Health do not specify any sensor data management paradigm.

The processing framework is basically the execution engine of the sensor data management paradigm carried out at SaaS level or at PaaS level. CC-WSN, SAaaS, Sensor-Cloud, and BodyCloud provide a processing framework at SaaS level supported by a specific PaaS. The processing framework of OSWA and ECGaaS are implemented at PaaS level. Finally, Cloud BAN e-Health does not support any specific processing framework.

All architectures provide Cloud storage but OSWA and Sensor-Cloud, which are based on stand-alone databases, and SAaaS, which does not specify the use of persistent storage.

The decision making process is fully supported only by BodyCloud through a flexible and distributed workflow-oriented model.

A customizable visualization service is only provided by CC-WSN and BodyCloud. Both architectures allow the implementation of user-defined views on sensor data and analysis results. In particular, the BodyCloud architecture [8] proposes an approach that integrates XML-based specifications for input data and for output data and their visualization.

Finally, only Cloud BAN e-Health and BodyCloud provide security mechanisms. Specifically, BodyCloud is curently based only on OAuth protocol supported by the GAE to access the Cloud services, whereas Cloud BAN e-Health delivers an effective security framework centered on (1) data encryption based on a hybrid RSK (Randomly generated Symmetric Key) and ABE (Attribute Based Encryption) method supported by a Health Authority, which also enable fine-grained access control to data, and (2) SSL-secured communications.

5 Open research issues

The integration of BANs and cloud computing is a recent research area so many open research issues do still exist, ranging from efficient and secure collection of body sensor streams to software engineering approaches for large-scale BAN application development. In the following we discuss some important open research issues and some effective solutions given so far.

Efficient collection of body sensor streams is crucial for enabling body sensor gathering from a multitude of BANs by reducing energy consumption of BAN sensors and gateways and minimizing latency time and bandwidth of the exploited network [50, 51]. In particular, in [50], authors propose an architecture that performs push–pull hybrid communication between three layers (cloud, edge or WSN gateway and sensor) for the purpose of optimizing the data transmission rates from the sensor layer to the cloud layer, the bandwidth consumption between the cloud layer and the edge layer, and energy consumption of sensor nodes in the sensor layer. Optimization is based on an evolutionary multi-objective optimization algorithm. The proposed architecture is currently developed into a simulator and is being also implemented atop the BodyCloud architecture.

Contextual sensing is the ability to detect contextual information and use it to augment the user’s sensory system. In addition to performing contextual sensing, the architectural model for CABANs should be capable of performing contextual management and adaptation [52], i.e. the ability to execute or modify a service automatically based on the current context. The main features for context-aware applications can be considered as the presentation of information and services to a user according to the current context, the automatic execution of a service, and the tagging of context to information for later retrieval. For the purposes of BAN systems, the main emphasis of a context-aware design is concerned with the interpretation of physical and biochemical signals acquired from body sensors and their association with the surrounding ambient environment. The contextual information will be mainly focused on the users’ activity, psychological states and the physical environment around the user.

Great emphasis is currently devoted to the software-defined networking (SDN) paradigm [53], which advocates separating the network control plane from the data plane. This migration of control, formerly tightly bound in individual network devices, into computing devices accessible through well-defined API enables the underlying infrastructure to be abstracted for applications and network services. The network can be thus viewed as a logical or virtual entity. Such concepts are being applied to enable software-defined WSNs, specifically through the Sensor OpenFlow approach [54]. A similar approach can be indeed taken also to model and implement software-defined BANs to improve their versatileness, flexibility, and easiness of management.

Another important research challenge, which has a main impact on the actual adoption of CABANs, is related to methodologies and tools for the development of diversified applications atop them. Currently only the BodyCloud approach [46, 47] makes it available a usable development process supporting the design, implementation and deployment of large scale BAN applications. However, more research efforts are needed to define software engineering methodologies along with specific CASE tools for engineering CABAN applications.

The security aspects in CABANs are receiving enormous attention, particularly in those application domains such as e-Health and e-Sociality that strongly require data privacy [55]. In particular, authenticating the data that BANs generate is vital to ensure proper diagnosis, traceability and validation claims. Digital signatures at the packet-level are too resource intensive for wearable sensors whereas block-level signatures are not robust enough to losses. So new lightweight robust authentication schemes assisted by Cloud platforms and suitable for health/social monitoring need to be devised and implemented [56].

Mobile cloud computing [57, 58] will pave a new way for the engineering and deployment of infrastructure-less (or mobile) CABANs; specifically in those contexts that require the dynamic establishment of an ad-hoc mobile infrastructure, which enables real-time body sensor stream collection, processing and analysis, to support application domains such as disaster and emergency management.

The integration of cloud computing and IoT infrastructures [59] will also offer new opportunities to deliver architectures and services for collection, management and analysis of (body) sensor streams coming from different sources (e.g. environment/building sensor networks, smart objects, BANs) dislocated in smart cities, factories [60], hospitals, offices, homes, etc.

Finally, we point out that the agent-oriented computing paradigm, particularly mobile software agents able to roam networks of computing entities (sensor nodes, mobile devices, computers) by carrying computation, data and code with themselves [61], may be adopted to provide mobile-agent-based techniques and mechanisms to incorporate autonomicity in the architectural components of CABANs [62]. Autonomic system behavior based on the self-* properties (Self-Configuration, Self-Healing, Self-Optimization, Self-Protection) [63] is becoming a requirement for an effective and efficient management of large-scale complex systems.

6 Conclusions

In this paper, we have identified motivations and challenges for the integration of BANs and Cloud computing. Specifically, we have presented a general reference architecture based on purposely elicited requirements for supporting CABANs, from sensor data collection to workflow-oriented data analysis: (1) sensor stream efficient collection, (2) effective sensor stream management, (3) scalable sensor stream processing framework, (4) persistent sensor data storage, (5) workflow-oriented decision making, (6) advanced visualization services, and (7) multi-layer security. The current state-of-the-art has been overviewed and compared according to the defined architectural requirements. Finally, open research issues, related to efficient wearable sensor collection, contextual sensing, software defined BANs, application/service development methods, multi-level security and privacy, and integration of BANs with mobile, IoT and autonomic infrastructures, have been discussed to provide an outlook on ongoing, interesting and promising research efforts.