Towards a Sensor-Cloud Infrastructure with Sensor Virtualization

Towards a Sensor-Cloud Infrastructure with Sensor Virtualization Sunanda Bose

Atrayee Gupta

Sriyanjana Adhikary

School Of Mobile Computing and Communications Jadavpur University



[email protected] [email protected] Nandini Mukherjee

[email protected]

Department of Computer Science and Engineering Jadavpur University

[email protected] ABSTRACT

A cloud computing environment, when integrated with sensor technologies, can provide a flexible stack of massive computing, storage, and sensing services in a scalable and virtualized manner at low cost. Till now it has been possible to transmit sensed data from individual sensor devices or from wireless sensor networks to a cloud computing environment. However, the questions that remain unsolved include how we use such sensors as shared resources and offer their services to a variety applications on an as and when required basis. Certain situations are also required to be handled at the infrastructure level instead of keeping them aside for application level decisions. These situations include i) selecting a single piece of data from large number of copies of the same data sensed by different sensors, ii) amalgamating different sensed data associated with same object to provide a unique description regarding the object status, iii) predicting data in the absence of sensed data etc. In the last case, sensed data may not be available due to specific reasons, such as connectivity problems. There may be other such situations which need to be handled at the infrastructure level to make the application lightweight and unaware of various complexities of sensor technologies. In order to handle the situations, we propose to use virtualization of sensors in a sensor-cloud environment. In this paper, the special type of resource we are dealing with is sensor and our objective is to treat a sensor as a first class citizen of resource family just like CPU, Memory, Disk space, and to expose them as services in a sensor cloud infrastructure. Virtualization is used to provide a logical replica having substantially equivalent interface as the physical entity. Remotely hosted Physical Sensors are virtualized with a generic device interface through layers of abstraction in our IaaS infrastructure, where the physical sensors lie underneath along with other resources like CPU, HDD, RAM and their logical instances are exposed to VMs running inside cloud infrastructure. These logical instances can be used for identifying, controlling, monitoring and/or reading from/writing to actual physical sensors or cluster of physical sensors. The generalized tasks of cloud, considering sensors as general purpose on demand resources, are communicating with sensors as remote resources along with resource identifica-

Recent advancements in cloud and sensor technologies have created opportunities for introducing Sensor-Cloud as a convenient framework for developing applications in various fields. It has already been possible to integrate sensor technology with cloud environment and services have been developed to access the sensors via Internet. Here, the sensors can communicate with remote resources and transmit the sensed data. This paper presents a scheme to create Sensor-Cloud infrastructure with virtualization of sensors. We introduce an architectural overview along with new concepts about resource abstraction at the sensor level. We also discuss about providing uninterrupted services by a collection of sensors that can be used as shared resources for online provisioning to the consumers.

Categories and Subject Descriptors H.3.4 [Systems and Software]: Distributed systems; D.2.11 [Software Architectures]: Domain-specific architectures

General Terms Theory, Design

Keywords Sensor-Cloud; Virtual Sensor; Virtualization

1.

INTRODUCTION

”Cloud computing is the delivery of computing as a service rather than a product, whereby shared resources, software, and information are provided to computers and other devices as a utility over a network (typically the Internet)”.[1] Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. MSCC’15, June 22, 2015, Hangzhou, China. c 2015 ACM 978-1-4503-3518-8/15/06 ...$15.00. Copyright http://dx.doi.org/10.1145/2757743.2757748.

25

tion, allocation/utilization, controlling, monitoring, scheduling, load balancing, clustering etc.

2.

sources. A GSM or WiFi or USB module may act as a transmission agent for a coordinator. Depending upon global or local availability, communications with coordinators are done either directly or via Sensor Gateway. Physical Sensors may be attached to a Sensor Coordinator in three different ways.

ARCHITECTURE OF SENSOR CLOUD

In the proposed sensor-cloud environment, locality of the resources span multiple infrastructures. Hence existence of our logical cloud exceeds beyond a set of Physical Machines which host Virtual Machines. Cloud manages its IaaS through intercommunicating components spanning multiple infrastructures. The architecture of the proposed sensor cloud environment consists of multiple entities as shown in Figure 2. These entities communicate with remote resources and deliver the resources as services. Each of these entities are discussed in the following subsections. Transmission of sensor data traffic to Cloud through intermediate cloud components is described in figure 1. Some of these cloud components exist as physical entities. Although, in the absence of any such entity, a logical abstraction is created. Some are solely logical entities and are placed as software abstractions in different layers. Process of virtualization requires an active channel of communication from physical resources to virtual resources for transmitting and receiving control and data packets. Our sensor-cloud environment consists of two major components: Resource Host and Cloud Station. Cloud Station is the in-house infrastructure of interconnected components building a sensor-aware cloud. Cloud Station provides point of interaction for remote resources to send or receive data traffic, as well as for end users to request resources. Depending on transmission capabilities, traffic may pass through a multihop network to ultimately reach the Cloud Station. Various components of these two logical entities are described in the following two subsections.

Sensor Gateway: Depending on transmission capabilities, sensor coordinators transmit data directly to cloud or via Sensor Gateway. Sensor Gateway acts as a destination for locally identifiable coordinators and dispatches the data traffic to Cloud Station. Traffic from Sensor Coordinator to Sensor Gateway may travel through multiple intermediate devices. Sensor Coordinator and intermediate devices take intelligent routing decisions to route data packets efficiently to Sensor Gateway.

2.1

2.2

Fixed: A fixed set of sensors are always attached with the coordinator, which cannot be plugged in/out in any cases. For example, environment sensors put up in sensor motes, like TelosB, Iris, MICA2 are located at specific positions. Mobile: A coordinator attached with a variable number of sensors either wired or wirelessly plugged with it supporting mobility of both the sensors, as well as the coordinators. For example, multiple health sensors attached with a patient in motion. Variable: A Coordinator located at a fixed position with a fixed set of sensors plugged with it, supposed to be attached with multiple subjects (e.g. patient) in a time slotted fashion. An example can be sensors used in a Kiosk serving multiple patients in different times.

Resource Host

Cloud Station

Cloud Station keeps its own registry service for resource registration and keeps a track on resource allocation with resource graph and log. Cloud Station consists of the following components:

Resource Host is a logical remote component that hosts all the remote resources interacting with Cloud Station. Resource Host can be organizations like hospitals, kiosks or individuals like paramedics). Remote resources may work as standalone entities having sensing, transmitting and power capabilities. A Remote Resource consists of the following components.

Resource Broker: A Resource Broker is the cloud component hosted inside Cloud Station that allocates resources on demand. Once a Resource is requested, Resource Broker searches the Resource Registry for available resources from a resource pool.

Physical Sensor: Physical sensors are at the bottom most layer of our architecture that have sensing capability but does not have ability to transmit the accumulated data. Each sensor may not have independent power unit, that is multiple sensors may share the same battery hosted by a coordinator. These sensors come alive only when they are plugged to some external power sources. Each such sensor is identified with a unique resource id.

Listener Broker: Listener Broker is the primary gateway for remote resources. Remote resources starts their negotiation and handshaking phase of communication with Listener Brokrer. At the handshaking phase a remote resource is supposed to describe its capabilities, requirements and unique identifier. Listener Broker manages the task of resource provisioning by assigning an appropriate Resource listener to listen to the traffic coming from a Remote Resource.

Sensor Coordinator: A Sensor Coordinator provides power and transmission capabilities to a fixed set of sensors but does not have sensing capabilities. A coordinator is treated as a non-sensing resource and a resource id is allocated to it. A coordinator may be locally or globally identifiable based on its transmission capabilities. A globally identifiable coordinator can directly respond to Cloud Station. On the other hand, a locally identifiable coordinator propagates its response through a Sensor Gateway. A coordinator may be battery powered or get power from on board power

Resource Listener: Cloud Station hosts a set of listeners each running a fixed protocol with a finite load capacity in terms of maximum concurrent connections. Listener Broker is supposed to assign remote resources to Resource Listeners in an optimal way utilizing capacities and capabilities of listeners and delivering required QoS to applications or VM requests. In most cases remote resources are allocated on-demand basis

26

Figure 1: Sensor Communication Sequence and attached in a time slotted fashion (ts , te ) that may be a subinterval of the time slot provided to an application or a VM request. In these cases Listeners may be leased on advanced reservation (AR) basis and AR specific resource scheduling algorithms may be used. In some cases immediate reservation may also be requested specifying ts as current time.

for available resources by searching for the vertices of specific type with 0 in-degree. Compute Node: A Compute Node is a Physical Machine (PM), inside Cloud Station, running a hypervisor, hosting multiple Virtual Machines with a fixed set of CPU Cores, Memory and Disk. Presence of this hypervisor inside a Compute Node enables virtualization of remote sensors along with local resources like CPU, Memory, Network Interfaces, and Disk.

Resource Acceptor: Resource Acceptor is the primary destination of sensor traffic coming from Resource Listener. Resource Acceptor may again forward the traffic to a hypervisor, or to another logical entity through 0 or more intermediate nodes, or even work as a hypervisor itself, depending on virtualization scheme. For logical isolation and generality, a Resource Acceptor is termed as PPoV (Primary Point of Virtualization) initializing process of virtualization that finally ends at PoV (Point of Virtualization) providing the virtual sensors as generic resources.

Elastic Storage: Elastic Storage provides Block storage services for the Compute Nodes hosted in Cloud Station by virtualizing a pool of block storage devices. Virtual Machine: A Virtual Machine is a software implementation of a computing environment in which an operating system and applications can be installed and run. Every virtual machine has virtual devices that provide the same functionality as physical hardware and has additional benefits in terms of portability, manageability, and security.

Resource Registry: Resource registry provides registration services for resources. Resource Registry can be queried for resource meta data such as resource type, location, capabilities, QoS range etc.. Mobile resources may advertise to Resource Registry to register themselves with their meta informations.

3.

SENSOR VIRTUALIZATION

Our sensor-cloud environment incorporates virtual sensors. Virtual Sensors abstract the physical sensors in many ways. Physical sensors convert the environment signals into digital forms so that they can be interpreted by human. For example, intensity of light can be measured by a sensor mote and can be programmed to comprehend the threshold which can be used to trigger an alert. Hence by no means we can replace this responsibility of physical sensors. The point of abstraction for a virtual sensor is not to replace any

Resource Graph: Resource Graph holds assignment informations of resources in a DAG where different physical and virtual resources are denoted by vertices and an edge connecting them denotes allocation. Whenever a resource is reserved or deallocated, an edge is added or removed. Resource Graph can be queried

27

Figure 2: Sensor Cloud Components

physical sensor but to facilitate and add any further module to physical sensors at the software-computing level. Many researchers suggest a number of sensor virtualization techniques for different purposes [4], [5], [6]. An environment monitoring physical sensor can delegate its task to virtual sensor to determine the toxicity level of carbon monoxide in air. Similarly a body sensor can use gait specific application and the huge computation tasks such as HMM modelling which can be delegated to virtual sensors. In this sensorcloud architecture we have designed virtual sensors for two different purposes. First, sensor virtualization enables better utilization of resources. A collection of sensors can be used as shared resources for online provisioning to the consumers. Abstraction of multiple physical sensors as a single virtual sensor also improves availability. The other features are accessibility and portability of physical sensors as virtual sensors from any device. Secondly, cloud gives better performance for any physical device. Likewise, virtual sensor gives enhanced performance for any kind of physical sensor with limited resources. Virtual sensors can be present anywhere and can be accessed from anywhere improving the coverage parameters of a physical sensor device. Virtualization technique supports management of devices via a hypervisor. As per our architecture, once the connection with the physical sensor with PPoV is created, any computation intensive task will be delegated to virtual sensors at IaaS level. Consumers should be able to communicate with the physical sensors via virtual sensors. Virtual sensors will not only reduce the burden of the computation task of physical sensors, but will also be managed as resources so that any kind of query can be handled at IaaS level. Challenge is to provide uninterrupted services to the users. One way of achieving this is providing a temporary buffer and creating an abstraction, so that sensor data can be pulled even in case of failures. Thus, it can be said that various challenges of physical sensors, like its energy consumption, coverage, memory limitation can be overcome by virtual sensors. On the other hand, utilization of the sensors as resources can be maximized. In the next section, we define different types of virtual sensors used in our sensor cloud environment.

3.1

more physical sensor(s), may be interfaced through a virtual sensor vi at IaaS and PaaS level in the following ways. IaaS Level  ri     {ri |ri ∈ B}   B vi →  h(B)      {ri : ∀ri ∈ B → f (ri )} {ri : ∀ri ∈ B → f (ri , B)} PaaS Level p(riτ : τ ∈ T ) vi → c(B)

singular ...(i) selector ...(ii) accumulator ...(iii) aggregator ...(iv) qualif ier ...(v) context qualif ier ...(vi)

predicted computed

...(vii) ...(viii)

Following is a description along with use cases for each of the above types of virtual sensors. (i) Singular: Direct or singular virtual sensor (VS) corresponds to one-to-one mapping between the physical sensor and its virtual interface. So for each sensor ri ∈ B, a corresponding virtual sensor vi is created. (ii) Selector: a group of homogeneous physical sensors is represented as one virtual sensor vi . vi gets its data fram any one physical sensor in the bundle on the basis of a selection algorithm. For example, when a group of temperature sensors are deployed in a region, data from any one of them can be gathered to obtain the temperature in that region. (iii) Accumulator a bundle B that comprises homogeneous or heterogeneous sensors may be represented as one composite interface as provided by the virtual sensor vi . For example, in case of a body sensor network, all the physical sensors can be considered as the bundle B and may be represented as a single VS. (iv) Aggregator An aggregator function h is applied on the sensed data coming from all physical sensors ri : ∀ ri ∈ B, and that aggregated output is represented as virtual sensor vi . When temperature sensors are distributed over a large geographic region, in order to obtain the average temperature for that region, a VS may implement an aggregator function.

Virtual Sensor

Given a set R of all physical sensors {ri | ∀ ri ∈ R}, each of type {ωi | ∀ ωi ∈ Ω}, a bundle B ⊂ R having one or

28

(v) Qualifier A virtual sensor vi is created and allocated corresponding to a physical sensor ri , but that virtual sensor only comes active when sensed value coming from the physical sensor ri qualifies a qualifier function f.

device has memory constraints. Therefore, mapping sensor memory to a cloud storage can overcome the limitation. Further temporal data can also be represented by the virtual sensor. Communication Module : Transmission and reception of data is abstracted by communication module. A Virtual Sensor consists of a source and a destination port. Source port gathers data from the physical device at the coordinator end. The destination port can be another socket for uploading data to cloud, or forwarding data to another VS or simply to the application for displaying or using the data in some manner. Naming and Identification of VS : When a group of VSs is created at the IaaS level, each one of them is provided with a unique name which is mapped to an IP. Once the VS is allocated to a particular VM, it can communicate with the bundle of physical sensors. Application Program Interfaces are provided at the IaaS level for allocation and using these VSs. The APIs may enable the user / application to create a name for the VS, to register while allocation of VS, to deregister (at the time of deallocation) a VS, to establish connection and bandwidth provisioning, to uploading data to cloud etc. Monitoring Module : Another aspect of virtualization of sensor is to provide error free data. A monitoring module is proposed for this purpose that provides APIs for virtual sensor management. With these APIs, the user / application may be able to monitor and control specific events, report about data duplication and monitor network connectivity and bandwidth availability.

One such virtual sensor may sense the blood pressure of a patient when that goes beyond a threshold value and can generate an alert. (vi) Context Qualifier Similar to Qualifier, but this qualifier function f observes one or more other sensor(s) {rj | ∀ rj ∈ B and rj 6= ri } present inside bundle B. (vii) Predictor A virtual sensor vi may be equipped with a predictor algorithm that may predict a possible sensed value based on time series data analysis on previously sensed data when actual physical sensor goes down. (viii) Compute A virtual sensor vi may be equipped with some contextual computation abilities that analyzes sensed traffic from a bundle of sensors that transforms sensed data to a more understandable information. For example, an image analysis algorithm may be executed on the data obtained from a group of physical sensors. The VS is then represented in an integrated form which containes the data obtained from the bundle of physical sensors, the algorithm and necessary computation and storage resources.

3.2

Interaction with Virtual Sensors

Any physical sensor can be represented as a virtual sensor system. For each sensing element there should be a minimum requirement for activation of the element, that means we need to activate the processes associated with this. So a sensor object is created at the virtual level. The purpose of this sensor object is interaction with the user (application) and the physical sensor without interruption and thus to overcome any kind of data loss. Moreover, a physical sensor reading can be intermittent or sometimes erroneous which can be handled at this level. A physical sensor performs four main tasks, such as sensing, processing, communication, and storage. A virtual sensor can be represented as a system with these four modules interacting with each other. These modules are distributed either at the physical sensor level, or at the gateway level or at the cloud station. The user or application requesting for the sensor object acts as a client and the host module, interacting with physical sensors in specified manner, acts as the server. Functions of each of the modules attached with a VS are described below. Sensing Module : This is placed at the lowest level where data is being selected or aggregated. As logical component is required to be present close to the physical device. This module can be placed at the sensor coordinator or sensor gateway. Processing Module : As there may be requirement for delegating processing task to virtual sensors, a processing module is incorporated to handle this. The processing module can be further subdivided to handle individual function. Its logical extension can be present in the cloud station and may work at the IaaS or at the PaaS level. Storage Module : Another objective is to map sensor memory to a virtual storage at the cloud end. Any typical sensor

4.

CONCLUSION

This paper presents the concept of a sensor-cloud environment and gives an overview of the design of such an environment. It defines various types of virtual sensors and gives a brief description about how the virtual sensors can be used by an application developed and deployed on a sensor cloud environment. We are currently working towards implementation of the sensor-cloud environment which will enable virtualization of sensors and use of these sensors in a virtual machine.

Acknowledgments This work is supported by Information Technology Research Academy (ITRA), Government of India under, ITRA-Mobile grant ITRA/15(59)/Mobile/RemoteHealth/01.

5.

REFERENCES

[1] P. Mell, T. Grance The NIST Definition of Cloud Computing. Recommendations of the National Institute of Standards and Technology 24 July 2011 [2] compuBase IT Channel Glossary March 2013. Retrieved 13 February 2013 [3] S. S. Manvi, G. K. Shyam. Resource management for Infrastructure as a Service (IaaS) in cloud computing: A survey, Journal of Network and Computer Applications 41(2014):424-440, October 2013 [4] L. Liu, S. M. Kuo, M. Zho. Virtual Sensing Techniques and Their Applications, In Proceedings of the 2009 IEEE International Conference on Networking, Sensing and Control, ICNSC’09, pages 31-36. IEEE, Okayama, Japan March, 2009

29

[5] P. Evensen, H. Meling. Sensor Virtualization with Self-Configuration and Flexible Interactions, In Proceedings of the 3rd ACM International Workshop on Context-Awareness for Self-Managing Systems, CASEMANS’09, pages 31-38. ACM, Nara, Japan May, 2009

[6] M. Iqbal, D. Yang, T. Obaid, T. J. Ng, H. B. Lim. Demo Abstract: A Service-Oriented Application Programming Interface for Sensor Network Virtualization, In Proceedings of the 10th ACM/IEEE International Conference on Information Processing in Sensor Networks, IPSN’11, pages 143-144. Chicago, Illinois, April, 2011

30