Sensor Resource Sharing Approaches in Sensor-Cloud Infrastructure

1. Introduction

A wireless sensor network (WSN) consists of spatially distributed sensors to monitor physical or environmental conditions [1, 2]. It is generally invincible trend to monitor a region and fetch useful data about the surroundings. WSNs are utilized in various areas, such as healthcare, military, critical infrastructure surveillance, and environmental monitoring. Since sensors are limited in energy, processing power, memory, and communication bandwidth, a WSN usually has design constraints. Therefore, WSNs have been designed to support a specific application service in mind. The tight coupling between a network and application limits the usability of sensor data because only the targeted applications freely use and manage physical sensors as well as sensor data within a WSN while applications outside the WSN cannot use the sensors and data directly. Thus, sensor data used for specific applications cannot be easily shared among different groups of users, and different WSNs cannot be easily interconnected. If there was an infrastructure on which applications could share different kinds of physical sensors easily, many new applications and services could be provided. In the midst of these issues, the emergence of cloud computing is seen as one of efficient solutions.

Cloud computing has been evolved as the future generation computing paradigm. It is a model for enabling convenient, on demand network access to a shard pool of configurable computing resources [3]. The configurable resources involve networks, servers, storage, applications, and services. Cloud computing platform dynamically provisions, configures, and reconfigures the servers when needed by users. On the platform, users could switch to their application by connecting to the server and start working without any hassle, even though they do not know the locations of servers.

Sensor-cloud infrastructure (SCI) is the extended form of cloud computing to manage the sensors which are scattered throughout WSNs [4, 5]. Since physical sensors in WSNs are directly bound to their specific applications as well as services, users other than the relevant services cannot use these physical sensors when needed. It makes wastage of valuable sensor resources that may be utilized when integrating with other application's infrastructures. Therefore, these sensors need to be supervised by some special sensor management schemes. SCI provides the sensor management to improve sensor data usability by virtualizing the physical sensors on a cloud computing platform. On SCI, users can use and control physical sensors through virtual sensors. Users can destroy their virtual sensors quickly when they become unnecessary. Besides, virtual sensors can be monitored to maintain the quality of service (QoS).

Cloud computing services for IT resources provide users with virtual servers. Users can use the virtual servers with no concerns about the locations of actual servers or their detailed specifications. Similarly, SCI for sensor resources makes users use the sensors with no worrying about their locations and detailed specifications by using virtual sensors.

In this paper, we present a survey on SCI and address technical issues. Section 2 introduces architecture of SCI. Section 3 reviews sensor description methods and Section 4 analyzes the characteristics of middleware based on publish/subscribe data exchange model. The projects and applications based on SCI are described in Section 5. Finally, conclusion is drawn in Section 6.

2. Architecture of Sensor Cloud

In a WSN system, sensors are utilized by their own application for a specific purpose. The only application in the system freely handles the sensor data and the sensor itself. SCI enables the sensors to be shared and utilized by multiple applications by virtualizing the physical sensor on a cloud computing platform. Figure 1 shows architecture of SCI, which is divided mainly into three components. The first component is IT resource pool to provide IT resources such as processors, storage, network, and database. WSNs have issues regarding the limited resources. In other words, the issues include short communication range, security and privacy, reliable data delivery, power consideration, storage capacity, and processing capabilities. To solve the issues, cloud computing platform dynamically provisions, configures, and reconfigures IT resources. In other words, SCI achieves the highly scalable hardware and software resources on the platform. The second component is a pool of sensor resources. SCI virtualizes physical sensors as virtual sensors in order to share various physical sensors from different owners. Each virtual sensor is to use and control one or more physical sensors. A virtual sensor group is composed of one or more virtual sensors. To create virtual sensors and virtual sensor groups, service templates are prepared by SCI providers. The sensor resources include physical sensors, virtual sensors, virtual sensor groups, and service templates. The last component is end users. Users request virtual sensors or virtual sensor groups by selecting service templates. Dynamically grouped virtual sensors are provisioned automatically in response to the requests from users. Then, they use and control their virtual sensors/virtual sensor groups with standard functions. For example, they can activate or inactivate their virtual sensors, check their status, and set the frequency of data collection from them. When virtual sensors become unnecessary, users release them.

OPEN IN VIEWER

Figure 1

Architecture of sensor-cloud infrastructure.

Each application requires a set of physical sensors in the sensor resource pool for its specific purpose. Thus, publish/subscribe mechanism is being employed for choosing the appropriate physical sensors [6]. As shown in Figure 2, there are three players in SCI, and the interactions between the players take place in the publish/subscribe manner. A sensor owner has its own physical sensors. To allow end users to use the physical sensors, the owner publishes the sensors with their metadata. The metadata include the types and locations for the physical sensors. The owner deletes the publication of the sensors when the owner wants to quit the sharing. End user has one or more applications or services that use sensor data. An end user subscribes to one or more physical sensors in order to retrieve sensor data from them for its applications. To do this, the user requests the use of virtual sensors or virtual sensor groups that satisfy the requirements. The user can control its virtual sensors directly or via a web browser. The user can monitor the status of the virtual sensors and use the virtual sensors with no detailed knowledge about physical sensors. The SCI provider manages SCI service. The provider manages and monitors sensor resources such as physical sensors, virtual sensors, virtual sensor groups, service templates, and user interface. It also provides middleware for the publish/subscribe mechanism.

OPEN IN VIEWER

Figure 2

Relationship among players in SCI.

The advantages of SCI are presented as follows. End users can freely control and use physical sensors by using virtual sensors without worrying about the implementation details such as location and specification of physical sensors. End users can also create the virtual sensors dynamically for new services, monitor the states of the virtual sensors, and release the sensors when they are unnecessary. Sensor owners can check the usage of their physical sensors and charge for the usage. The cost of IT resources and WSN infrastructure is reduced by integrating between cloud and WSN [7]. Even though SCI could provide flexible and cost efficient platform, there are requirements to be satisfied to fully take advantage of the SCI services. The IT resources and physical sensors should be prepared prior to operation of SCI [8], and continuous data connectivity is needed among SCI players [9].

3. Sensor Description

In WSNs, there are many different physical sensor types, from simple visual thermometers to complex electron microscopes and earth observing satellites. To allow end users to use physical sensors, a framework is needed to define the geometric, dynamic, and observational characteristics of sensors. On the framework, sensor owners represent the metadata for any physical sensor, such as the type of physical sensor, the location, and the accuracy. Besides, the framework should provide a mapping process between physical sensors and virtual sensors to describe how to translate commands coming from users to virtual sensors into commands for the corresponding physical sensors.

The Sensor Web Enablement (SWE) initiative of the OGC (Open Geospatial Consortium) standardizes the sensor model language (SensorML) to model and encode sensor metadata [10]. Initially, SensorML was developed for describing the geometric and radiometric properties of dynamic remote satellite sensors. In 2000, SensorML became a part of SWE initiative of the OGC. Approved as an international and open technical specification by OGC, SensorML provides standard models and an XML encoding for describing sensors and measurement processes. SensorML models detectors and sensors as processes, which convert real phenomena to data by defining metadata, inputs, outputs, parameters, and method. The metadata is not meant to provide detailed descriptions on hardware but to provide functional model for sensors. It includes identifier, classifier, constraints, capabilities, characteristics, contacts, and references, as well as inputs, outputs, parameters, and system location. The SWE also specified Observations and Measurement (O&M) standard to encode sensor data measured.

Even though SensorML is specified to efficiently use and manage huge amount of sensed data, the encoding and parsing of XML codes are not lightweight enough for resource constrained sensors. In addition, the flexibility of SensorML in modeling sensors causes the interoperability issue at the encoding level because there are multiple ways to encode sensor characteristics.

Since the SCI is composed of a lot of sensors and the number of applications using the SCI keeps increasing, the volume of data inside the SCI also increases accordingly. Furthermore, the devices, data formats, and measurement procedures become more and more heterogeneous. Therefore, as the scale and complexity of SCI increase, it becomes more important to manage not only sensors but also the data generated by them in an efficient manner. On the other hand, users want to use SCI in an intuitive way without involving technical details. Semantic sensor web and ontology are expected to satisfy both requirements of the SCI and users by assisting in managing, querying, and combining sensors and observation data [11]. There are a number of sensor ontologies. They differ in their main purposes. For example, [12, 13] focused on the sensor data while [14, 15] concentrated on the role of stimuli, observed properties or processes. MMI focus more on systems rather than measurements or sensor types [16]. Ontosensor covers wider ranges of sensor concept [17]. The surveys on the sensor ontology could be found in [18].

The W3C Semantic Sensor Network Incubator Group (SSN-XG) produced Semantic Sensor Network Ontology (SSNO) to describe the capabilities and properties of sensors, measurement processes used, and the resulting observations [19]. The SSN-XG has transitioned into the Semantic Sensor Networks Community Group. The SSNO is encoded in OWL (Web Ontology Language) [20] and aligned to DOLCE-UltraLite (DUL) [21].

Even though SensorML from OGC provides syntactic interoperability and SSNO provides semantic interoperability, it is difficult to integrate SSNO with SensorML. Starfish Fungus Language (StarFL) is proposed to relate SSNO and SWE [22]. StarFL focuses on the common features shared by a wide range of users and communities without supporting details of sensors. Unlike the Sensor Interface Descriptor approach which includes the description of sensor communication interfaces [23, 24], StarFL focuses on modeling sensor capabilities leaving aside the description of the actual sensor interface.

4. Publish/Subscribe Middleware for Sensor Cloud

SCI could support wide ranges of application services by providing various sensed data. However, sensors are different in their hardware and operating systems, and applications have their own specific requirements. Therefore, it is difficult for application developers to understand these specific details when they implement application services. Therefore, a middleware based on an appropriate communication method is required to glue the gap between the various details residing inside of SCI and specific requirements of applications so as to facilitate the development of various application services.

A user using SCI is provided with two interfaces. One interface is used to express the information the user is interested in, and the other one is used to receive the information from SCI. It means that users are not interested in the sensors providing the information and how the information is delivered to them if they receive information they want. Therefore, unlike the request/response data exchange model prevailed in the Internet where a sender and a receiver communicate synchronously by constructing an individual point-to-point connection between them, the information in SCI is exchanged asynchronously between an information producer and its consumer when specific events specified by the consumer are triggered. In addition, since SCI is a distributed system composed of a lot of different types of sensors, it needs a scalable information distribution method.

Considering these specific characteristics of SCI, a middleware based on publish/subscribe interaction scheme has drawn a lot of attention [25]. Usually, a publish/subscribe system operates by the interactions among three entities—a subscriber (end user), a publisher (sensor owner), and a broker (SCI provider). A subscriber registers an event or a pattern of events it wants to receive with a broker. A publisher produces the information and sends it to a broker. A broker maintains the subscription information and filters the information sent from publishers according to the rules that specified the subscribers. If an event is detected, the broker distributes the event to all the subscribers who subscribe to the event. Therefore, by taking into account the constraints in the SCI, it is important to implement efficient event filtering and delivery services for a publish/subscribe middleware.

The publish/subscribe middleware decouples the production and consumption of information in time and space. In other words, interacting parties are not necessarily participating in the information delivery at the same time. Therefore, they do not need to know the availability of the other parties. In addition, by decoupling space, interacting parties do not need to know each other (e.g., location, the number of publishers/subscribers, etc.). Therefore, the publish/subscribe middleware could increase the scalability in information delivery, which suits the design requirements of the SCI.

There have been a lot of proposals for publish/subscribe middleware in the literature. Mires is a topic-based publish/subscribe middleware for WSN [26]. It uses the message-oriented paradigm provided by TinyOS. Even though only the messages referring to the subscribed topic are delivered to a message sink, Mires is not energy efficient because it uses broadcast protocol to distribute subscriptions. In addition, publishers in Mires must know not only the event subscribers but also the paths the event must follow.

Since applications using SCI handle very complex situation, they need to interpret data from heterogeneous sensors at the same time so as to detect a composite event. However, since it is required for sensors to individually detect primitive events and cooperatively determine the relationship among these events, it is not easy to support composite events in publish/subscribe middleware. To overcome these difficulties, a PSWare is proposed to support both the primitive and composite events in a publish/subscribe manner [27]. The authors proposed an event definition language (EDL) to accurately define primitive events and describe the spatial and temporal relationship among the events. They also developed a compiler which compiles the applications programmed by EDL. In addition, an event detection protocol is proposed to detect composite events in an energy-efficient manner.

TinyDDS is proposed for a lightweight implementation of the DDS (Data Distribution Service) standardized for topic-based publish/subscribe middleware by OMG (Object Management Group) [28]. TinyDDS uses nesC to implement the standard interfaces for event subscription and publication for DDS, which are described in IDL (Interface Definition Language). A self-configuring routing protocol in TinyDDS delivers events adaptively according to current network states by autonomously balancing the tradeoffs among conflicting objectives. TinyDDS uses evolutionary multiobjective optimization mechanism (called MONSOON) in order to seek the optimal tradeoffs among operational objectives and adjusts parameters in its routing protocols accordingly to satisfy QoS requirements of an event delivery service. However, since TinyDDS is a topic-based publish/subscribe middleware, the granularities in event description may not be fine enough to satisfy the requirements of the applications using SCI.

Middleware applications based on overlay network are proposed in [29, 30]. In [29], a tree is constructed on top of the physical sensors to deliver subscriptions and published data. It is composed of a virtualization component and indexing component. The former maintains a naming structure by assigning each node a unique virtual address while the latter determines the notification paths for given subscriptions and publications. However, congestion could occur in a tree, which deteriorates the performance of the event delivery service. A content-based publish/subscribe middleware that employs a general message mapping and routing mechanism is proposed in [30]. Unlike the middleware in [29] that constructs a single tree, TinyMQ partitions sensors into multiple trees and maps a subscription/publication into multiple sensors in the different trees so as to facilitate load-balancing and increase availability. TinyMQ also allows cross-tree routing to relieve the burden of a broker. However, there could be considerable cost for tree maintenance, especially when sensors leave and join the tree dynamically.

Most of the existing publish/subscribe middleware applications support only stationary and interconnected sensors. Since they depend on the multihop routing protocols to deliver subscription and published data, they are not applicable to the environment where static sensors are sparsely deployed or sensors move around. A content-based publish/subscribe middleware supporting mobile sensors or static sensors sparsely deployed is proposed in [31]. The authors proposed to use mobile phones as data mules for relaying subscription and published data between a broker and sensors. They also proposed a method to adaptively update the locations of mobile mules so as not to deteriorate the scalability of publish/subscribe services. Despite the fact that most of the publish/subscribe middleware applications focus on the event delivery service among the players, the authors in [32] use the publish/subscribe mechanism to deliver mobile agents (MAs). Compared with other types of middleware, MA-based middleware could save the energy for communication between sensors because the size of mobile codes is much smaller than that of the data collected in a sensor. In addition, since small-sized mobile agents could be sent at any time according to the demands of a network, the MA-based approach provides flexibility in program installation and update. The authors in [32] implement a mobile agent manager on top of the publish/subscribe service. With this decoupling, the mobile agent manager could concentrate on details related to agents such as creating, moving, and executing codes without concerning the transmission details. However, since an agent represents an application, the failure of agent transfer results in the failure of the application. Therefore, the fidelity of the publish/subscribe mechanisms should be evaluated in an environment where there are constraints in network connectivity and available sensors.

5. Case Study

Since sensors are very specific to their applications, the numbers of organizations that can provide the sensor services are very limited. However, on top of SCI, it is possible to include sensors to realize a variety of applications and services.

IoTCloud develops a sensor-centric framework which supports an extensible set of sensor types and large numbers of geographically distributed smart objects [33]. As shown in Figure 3, the framework consists of four components: IoTCloud controller, distributed message broker, sensors, and clients. IoTCloud controller manages the other components and provides SOAP (Simple Object Access Protocol) web service [34] for sensor publication, discovery, subscription, and control. Message broker handles the low level details of message routing. Sensor is a component which generates a time dependent series of data to IoTCloud controller. It also listens for control messages sent by IoTCloud controller. Clients are able to discover, subscribe to, and control sensors by using the web service API provided by IoTCloud controller. The IoTCloud framework is deployed on the FutureGrid [35]. FugureGrid is a part of the XSEDE (Extreme Science and Engineering Discovery Environment) [36]. The FutureGrid provides a capability that makes it possible for researchers to tackle complex research challenges in computer science related to the use and security of grids and clouds.

OPEN IN VIEWER

Figure 3

IoTCloud architecture [33].

The project SensorCloud is a member of the project cluster Trusted Cloud which is funded by the German Federal Ministry of Economics and Technology [37]. Trusted Cloud aims to develop and evaluate innovative, robust, secure, and law conform cloud computing solutions. The goal of SensorCloud is to develop a cloud-based platform that integrates basically every kind of distributed internet-connected sensors and actuators. The project uses the smart home scenario to capture requirements when designing technical solutions. For the scenario, SensorCloud serves as a central hub to which sensors and actuators can be connected. The hub manages sensors and actuators and aggregates their data from different domains, places, and owners at the same time. Though serving the hub, SensorCloud provides an extensible and flexible service platform that is populated by applications from third-party developers. Bringing together sensor owners, end users, and cloud provider on the platform, the SensorCloud enables a marketplace for customer solutions that minimizes costs and hurdles for all involved players.

SAaaS (Sensing and Actuation as a Service) is to implement services to provide indexing and querying methods applied to things, that is, heterogeneous resources such as sensors and actuators [38]. The resources are aggregated according to a given thing-like semantics and provided to final users. For the services, SAaaS presents a new architecture which is composed of three components as shown in Figure 4: hypervisor, autonomic enforcer, and volunteer cloud manager. Hypervisor works at the level of a single sensor node, where it abstracts away either embedded sensors available on a device or standalone sensors belonging to WSN. It relays commands and data, abstraction of devices and capabilities, virtualization of abstracted resources, semantic labeling, and thing-enabled services. The abstraction has been developed according to SWE standard defined by OGC. Autonomic enforcer is tasked with enforcement of policies, local versus global policy tie-breaking, subscription management, and cooperation on overlay instantiation. Volunteer cloud manager is in charge of exposing the generated cloud, framing reward mechanisms and policies in synergy with SLA matching, to be mediated by QoS metrics and monitoring, as well as indexing duties to allow for efficient discovery of resources.

OPEN IN VIEWER

Figure 4

Architecture of SAaaS [38].

There are many other applications that are emerging based on SCI. Google Health provides a service for users to access their personal health and wellness information. Users are allowed to monitor their health records at collaborated cloud health service providers. However, now the service has been discontinued. Microsoft HealthVault is another personal health record provider. It helps users to gather, store, use, and share their health information, such as allergies, adverse drug reactions, and prescription record [39]. IBM India has considered SCI in the context of sensor web for smarter cities (SENSIT) to assist India with rainfall monitoring and flood forecasting [40]. Fujitsu provides Akisai as agricultural cloud to analyze data from field sensors [41]. It combines data from a nationwide network of sensors and cameras in fields that keep track of factors including soil temperature, moisture, rainfall, and humidity. Farmers will benefit from detailed data on factors such as their profitability per crop and expenses.

Even though these case studies show the potential of the SCI, there are several issues need to be taken into consideration when designing an application using a SCI. Most of the applications require reliable and continuous data transfer. However, real radio propagation environments are prone to errors which make a reliable data transfer difficult and cause a connection failure. Therefore, application developers must consider these scenarios into consideration to avoid negative effects of unreliable communications. The other issues are related to security. For example, a web-based interface is used by many people with different authorization. Therefore, the system should be able to provide different authorization roles for different types of users. In addition, since most of the data collected by sensors are related to privacy, the data exchanged and stored in the SCI must be protected appropriately. Therefore, privacy policies including secure key management and data integrity must be addressed.

6. Conclusion

In this paper, we introduced SCI and addressed technical issues such as sensor description and publish/subscribe middleware. To allow end users to use physical sensors, a sensor description framework is needed to define the characteristics of sensors. As the scale and complexity of SCI increase, ontologies and semantic approaches are considered to manage not only sensors but also the data generated by them in an efficient manner. SCI could support wide ranges of application services by providing various sensed data. The publish/subscribe middleware glues the gap between the various details residing inside of SCI and specific requirements of applications.

Integrating the sensors with cloud opens the doors to provide numerous applications and services. However, to maximize the potential of SCI, many research challenges including system design, energy efficiency, efficient information dissemination, collective intelligence harvesting, and interface standardization need to be resolved.