Developing an On-Demand Cloud-Based Sensing-asa-Service System for Internet of Things

The increasing number of Internet ofThings (IoT) devices with various sensors has resulted in a focus on Cloud-based sensing-asa-service (CSaaS) as a new value-added service, for example, providing temperature-sensing data via a cloud computing system. However, the industry encounters various challenges in the dynamic provisioning of on-demandCSaaS on diverse sensor networks. We require a system that will provide users with standardized access to various sensor networks and a level of abstraction that hides the underlying complexity. In this study, we aim to develop a cloud-based solution to address the challenges mentioned earlier. Our solution, SenseCloud, includes a sensor virtualizationmechanism that interfaces with diverse sensor networks, amultitenancy mechanism that grants multiple users access to virtualized sensor networks while sharing the same underlying infrastructure, and a dynamic provisioningmechanism to allow the users to leverage the vast pool of resources on demand and on a pay-per-use basis.We implement a prototype of SenseCloud by using real sensors and verify the feasibility of our system and its performance. SenseCloud bridges the gap between sensor providers and sensor data consumers who wish to utilize sensor data.


Introduction
As numerous devices and sensors get connected to the Internet, Internet of Things (IoT) is becoming a key topic of interest.Cisco predicts that 50 billion devices will be connected to the Internet by 2020.These devices and sensors will generate approximately 403 zetta bytes of data per year by 2018.In this fast-paced environment, the management of these devices, the networks, and the generated data is vital.The management and provisioning of such sensor devices and data opens doors to new business opportunities and poses new challenges.Industry and academia must manage these interconnected devices and exploit the opportunity presented by the extremely large amount of data generated.However, the huge investment and high maintenance cost of sensor network infrastructure prevents users from building their own IoT systems and web applications that utilize sensor data.Thus, cloud-based sensing-as-a-service (CSaaS) appears as a new service paradigm; its system architecture is shown in Figure 1 [1,2].Sensor providers supply sensor data on mobile devices or on sensor networks through operations to subscribe to and publish sensing data.Big data are saved and processed on the CSaaS infrastructure.Sensor consumers utilize the sensing data from the cloud system on demand.The following important and specific challenges must be carefully addressed in the design and implementation of a CSaaS system [2].First, the system must be generic and must hide the underlying complexity such that it can support various opportunistic and participatory sensing applications (which may even involve a large variety of sensors) and incurs very little overhead when launching a new sensing application and service.Second, the system can provide efficiency and sustainable scalability while using the same underlying infrastructure and ensuring the lowest cost-of-service delivery for each incremental consumer.Third, the system can provide the service dynamically to allow consumers to leverage the vast pool of resources on demand.
Several models have been proposed in order to address some of these challenges in sensor networks.Service-oriented architecture (SOA) approaches [3][4][5] integrate wireless sensor networks (WSNs) and leverage the widespread use of WSNs.Service-centric models [6][7][8][9][10][11] focus on the services provided by a WSN as a service provider.Approaches using crowd-sourced mobile devices as sensors have been proposed [2,12,13]; they utilize the sensors of existing mobile devices to fulfil user requests.Integrated approaches to share the sensing data on existing sensor networks [14][15][16] provide efficient sharing mechanisms among multiple applications.However, these studies have not resolved the challenges related to the engagement and connectivity for diverse sensor networks, multitenancy considering both sensor providers and consumers in CSaaS, and on-demand big data sensing service.Further, these studies have not demonstrated a prototype implementation of the platform with real sensors.
In this study, we develop a CSaaS system called Sense-Cloud.The system aims to create a universal cloud platform with the following features: (1) It engages and manages various sensors on IoT devices by using the virtualization layer; (2) it gathers data from diverse sources such as sensors and sensor networks for useful and predictive analysis on a cloud system; (3) it provides access to real-time and historical data for analysis on an intuitive and feature-rich web interface; (4) it gives multiple users access to virtualized sensor networks while sharing the same underlying infrastructure; (5) it provides easy and standardized sensing data service for consumers and third-party applications dependent on data; and (6) it allows dynamic provisioning for users to leverage the vast pool of resources on demand.We implement a prototype of SenseCloud with real sensors.Then, we evaluate the operation and feasibility of our system and verify the system performance in terms of request time, load balancing, and scalability.
The contributions of this study are as follows: (i) Design of a CSaaS platform with virtualization, multitenancy, and dynamic provisioning.
(ii) Sensor virtualization at two levels-that is, sensor level and consumer level-to enable multiple consumers to customize and control virtual sensors corresponding to a single physical sensor.(iii) Two different multitenancy architectures, one for sensor consumers and another for sensor providers.The architecture for sensor consumers offers the highest degree of multitenancy to enable sharing of the same application for login, engagement, and management of sensors and sensor data.The architecture for providers provides instances dedicated to each sensor provider, taking into consideration security, failover mechanisms, high availability, and reliability.(iv) Dynamic provisioning of CSaaS to allow consumers to leverage the vast pool of resources on demand and on a pay-per-use basis.(v) Implementation of a SenseCloud prototype system with real sensors and evaluation to ensure the feasibility of the system and analyze its performance.
The remainder of this paper is organized as follows.Section 2 introduces existing works related to CSaaS or sensor data sharing approaches.Section 3 designs the Sense-Cloud architecture and explains the system design.Section 4 describes the experiment results for operation and performance.Finally, Section 5 provides concluding remarks with future work.

Related Work
Numerous devices around us generate an enormous amount of data.Devices with sensors to capture such data have existed for decades; however, recent developments in technology have enabled these devices to be equipped with energyefficient and cost-effective wireless modules that allow the devices to transmit data wirelessly in real-time.This feature enables the measurement, inference, and understanding of environmental indicators, ranging from delicate ecologies and natural resources to urban environments.The proliferation of these devices in a communicating-actuating network creates IoT, in which sensors and actuators blend seamlessly with the environment around us, and the information is shared across platforms in order to develop a common operating picture [17].IoT has been defined as object sensing, object identification, and communication of object-specific information.The information is the sensed data related to temperature, orientation, motion, vibration, acceleration, humidity, chemical changes in the air, and so forth, depending on the type of sensors.A combination of different sensors can be used for the design of smart services [18].
A multitude of these sensors connected wirelessly form a sensor network.These sensor networks can be leveraged for a variety of applications.Some of these applications, mentioned in [18], are natural-disaster prediction, industrial applications, water-scarcity monitoring, smart-homes design, medical applications, agricultural applications, intelligent transport system design, smart-cities design, smart metering and monitoring, and smart security [2,12,19,20].However, general users are deterred by the huge investments √ SCI [11] √ √ √ and high maintenance costs involved in sensor network infrastructure to utilize sensor data.Thus, the concept of CSaaS originated [1,2], and it could be a value-added service to boost the expansion of IoT infrastructure.The emergence of a plethora of applications for sensor networks is accompanied by several challenges and problems in the management of these networks.The IoT gateway acts as a bridge between WSNs with traditional communication networks or Internet, and it plays an important role in IoT applications; thus, it facilitates the seamless integration of WSNs and mobile communication networks or Internet and the management and control with WSNs [21,22].Some of the problems and challenges that arise are the standardization of governance and management models [3,11,18], complexity arising from heterogeneity [3,21], virtualization, and monitoring [11].
As shown in Table 1, several models have been proposed in order to address these challenges in sensor networks.WSNs as a service [3][4][5] leverage the widespread use of WSNs and adopts a SOA approach based on the integration of WSNs.In particular, sensing sharing mechanism [4] provides a module to integrate industrial sensor information with the World Wide Web through the cloud in order to monitor and control the development process (e.g., nuclear plant management system).In the system, the integration controller and sensor node communicate through SOA to enable the services to be discovered and invoked by the sensor applications (client).Cloud computing is used to provide the extensibility of application servers and constant availability of data to users.However, the system does not address sensor virtualization, which would enable on-demand sharing of the physical sensors among users.
Service-centric models [6][7][8][9][10][11] focus on the services provided by a WSN and view a WSN as a service provider.Information as a service (IaaS) for WSNs [9] uses virtualization of WSNs to provide techniques for sensor provisioning and sharing for the large number of existing WSNs.However, IaaS leaves further scope for expansion in terms of load balancing and universal abstraction for all classes of sensors or sensor networks.A new service model called sensing instrument as a service (SIaaS) [10] provides virtualized sensing instruments to users and shares them as a common resource in a controlled manner.However, SIaaS does not consider on-demand provisioning, which is important to users.Sensor-cloud infrastructure (SCI) [11] manages physical sensors by virtualizing them as virtual sensors on the cloud.SCI provides monitoring, automatic provisioning, and control for virtual sensors and virtual sensor groups, similar to our system; however, SCI does not explicitly design the scalability, load balancing, and multitenancy mechanisms to efficiently manage the infrastructure.
Approaches using crowd-sourced mobile devices as sensors have been proposed [2,12,13]; these approaches utilize the sensors of existing mobile devices and fulfil user requests.A priced public sensing framework (PPSF) [12] is designed for heterogeneous IoT architectures; this framework considers resource limitations in terms of delay, capacity, and lifetime from the perspective of the data provider and considers quality and trust requirements from the perspective of requesters.However, PPSF does not consider the service efficiency of the framework, that is, scalability or load balancing.
Integrated approaches to share the sensing data on existing sensor networks [14][15][16] provide efficient sharing mechanisms among multiple applications.A framework of sensorcloud integration (FSCI) [14] utilizes the ever-expanding sensor data with a content-based pub/submodel.Virtual federated sensor network (VFSN) [15] enables multiple applications to share widely distributed sensor networks flexibly, preserving resource isolations.In VFSN, virtualized sinks are interconnected to achieve a dedicated federated sensor network; further, VFSN provides operations for multiplesensor information to service providers.An infrastructure for shared sensing (SenseWeb) [16] enables applications to initiate and access sensor data streams from shared sensors across the entire Internet.The SenseWeb infrastructure helps ensure optimal sensor selection for each application and efficient sharing of sensor streams among multiple applications.However, these integration approaches do not address the multitenancy challenge that will enable each provider to exclusively and efficiently manage their own resources in a large integrated infrastructure.
In summary, none of the previous studies have developed a prototype of CSaaS with real sensors supporting all the following features: the scaling mechanism, load balancing, virtualization, multitenancy, and dynamic provisioning.In this study, we propose and demonstrate SenseCloud, a prototype that implements sensor system management and addresses the above mentioned challenges.

SenseCloud System
This section describes our proposed SenseCloud system according to a top-down approach: first, the overview and then, the detailed system design.

Overview of SenseCloud System
Architecture.This subsection presents an overview of our SenseCloud system architecture, which consists of three main components-Entity, Cloud Infrastructure, and Sensor Network-as shown in Figure 2.
The four entities are Sensor Consumer, Sensor Provider, Network Admin, and Cloud Admin.The roles of each entity are described below.All entities perform their roles after authentication by the portal server.
(i) Sensor Consumer.First, sensor consumers register on the system and log in.After successful authentication, they subscribe to interesting sensors and create or modify sensor groups that include these sensors.Then, sensor consumers fetch the sensing data from sensors and view the analytical data.Further, they can download historical data and view their bills.
(ii) Sensor Provider.Sensor providers register on the system and log in.After successful authentication, they register their sensors on the system, manage the sensors, and control them while checking their status.
Sensor providers view the sensor usage statements.
(iii) Network Admin.After logging in to the system as a network admin, this entity monitors sensor health and manages virtual sensors.Further, a network admin manages the sensor provider accounts.
(iv) Cloud Admin.After logging in to the system as a cloud admin, this entity monitors virtual machines (VMs) and manages cloud infrastructure.A cloud admin manages the sensor consumer accounts and services.
The cloud infrastructure consists of the following servers and storage: Portal Server, SenseCloud Management Server, Provisioning Server, Sensor Monitoring Server, Virtual Server, and Data Storage for User/Virtual Sensor Group (VSG)/Sensing Data.The features of the main components and the roles of each entity are described below: (i) Portal Server.When a user logs in to the SenseCloud portal, the user role, which can be sensor consumer, sensor provider, or admin, determines the operations.
In the case of sensor consumers, the dashboard presented by the portal server allows the user to place a request to monitor their virtual sensors, to provision or terminate virtual sensor groups, and to control virtual sensors.In the case of sensor providers, the dashboard provided by the portal server allows the user to register or remove physical sensors.In the case of SenseCloud admins, the dashboard presented by the portal server allows the user to create, modify, and remove the VMs, virtual sensors, and virtual sensor groups.The portal server also forwards the requests to other servers when required.(ii) Provisioning Server.The SenseCloud provisioning server creates the virtual sensor groups and manages them according to the requests that are received from the portal server.This task is achieved by the workflow engine and some predefined workflows in the system.The workflow is executed in the following order: The provisioning server creates and reserves a VM (if not already created) when it receives the request for provisioning.After the VM is ready, a virtual sensor group is automatically provisioned by the provisioning server.The virtual sensor group is owned by a sensor consumer, and it has one or many virtual sensors.The provisioning server updates the records in the data storage for the virtual sensor groups created by consumers.The consumers can control the virtual sensors.For instance, they can activate or deactivate their subscribed virtual sensors, set the frequency of data, and check the status.(iii) Sensor Monitoring Server.The sensor monitoring server receives the informational or health data about virtual sensors from the virtual servers and stores these data.This information about the virtual sensors is available to sensor consumers on the dashboard.Further, the sensor monitoring server monitors the health status of the physical sensors.This monitoring is important because live data provisioning is based on the live physical sensors.The admins can also monitor the status of the servers.(iv) SenseCloud Management Server.This server provides the location-aware load balancing algorithm that attempts to select a VM instance that is closest to the request sender zone and that has the shortest pending list.This server provides a multitenant solution over the cloud to the registered sensor consumers and providers.It also performs scaling according to the policy engine.This policy engine is based on the network and system performance.(v) Virtual Server.When requested by the provisioning server, the virtual server creates virtual sensors (VSs) on the VM.The VSs are controlled by the portal server.The virtual server provides health information about the sensors to the sensor monitoring server when requested and saves the information in data storage.(vi) Data Storage.Data storage consists of databases for user, VSG, and sensing data.

System Design.
This subsection provides a detailed explanation of the operations of the sensor provider and consumer in SenseCloud by using sequence diagrams, state machine diagram, and active diagram.Then, this subsection presents the functional view of our system.

3.2.1.
Operations of Provider and Consumer.Figure 3 depicts the sequence diagram for the workflows of an important entity, that is, the sensor provider.The sensor provider installs the sensors or sensor network at the corresponding locations.As shown in Figure 3, the sensor provider registers the sensors or sensor network with SenseCloud.After the sensors or sensor networks are registered (registerSensor()), the sensor providers can view them on the dashboard of the portal server, monitor their health (listSensor()), view the usage of their sensors (sensorUsageDetails()), and obtain the monthly usage statement (viewStatement()).Figure 4 describes the state machine for registerSensor().When a sensor provider registers for an account, the setup is executed in the cloud.This setup involves the creation of a VM for that sensor provider; the VM will hold all the virtual sensors for every physical sensor plugged in to the cloud by the sensor provider.This setup initiates a process on amazon web service (AWS) using AWS CloudFormation, creates a VM, and updates the database by recording the assignment of the newly created VM against the entry of the sensor provider.If the setup fails, or if the assignment of the VM to the sensor provider account fails, the process is stopped, and the sensor provider is notified.On de-registering the account, the VM is unassigned, and the user account is removed from the records.
Figure 5 shows the detailed flow of the sensor consumer operations in SenseCloud.The sensor consumer registers with SenseCloud.After registration, the consumers can view the list of available sensors on their dashboard of the portal server.They can subscribe to any interesting sensors.After subscription, the consumers can club multiple sensors in a group and can manage their groups through the dashboard.The end consumer can view the real-time analytics, download the archived data, and use the developer APIs to utilize the data in their own applications.
Figure 6 illustrates the activity flow of the sensor consumer who subscribes to the sensor, downloads the historical data, and views the analytics on the dashboard.The cloud infrastructure creates a virtual sensor for each physical sensor that the consumer subscribes to.After subscription to a sensor, the consumer can view and download the realtime and historical data in addition to the analytics on the dashboard.

Functional View of SenseCloud.
Figure 7 shows the functional modules corresponding to each entity in Sense-Cloud; each module provides the following features: (i) Registration.The registration module provides consumers with the login and registration capability to enable them to consume the services and data from the sensors via the dashboard.Further, the sensor providers can register their sensors, which will be authenticated by the admins.
(ii) Virtualization.The virtualization module virtualizes the sensor network in the cloud by virtually grouping the sensors and services requested by a consumer.Thus, each consumer can group the sensors and services and can configure, add, edit, and delete the virtualized sensors in the group.provider and admins in order to control the users and sensor network services.
(ix) Billing.The billing module provides billing to the consumer according to the usage of data and services.The billing is based on a configurable cost model.The sensor providers can view the usage of their sensors and obtain the monthly usage statement.
(x) Analytics.Sensor consumers can access real-time sensor data analysis and archived sensor data analysis on the dashboard.
(xi) Management.The management module enables the network admin to manage the virtual sensors.The network admin can create virtual groups with virtual sensors.Further, this module provides user account management and cloud infrastructure management capabilities to the cloud admin.
We focus on the design of virtualization, multitenancy, and dynamic provisioning.We explain our solutions that address these aspects.
(1) Virtualization Solution.In order to obtain the typical benefits of virtualization and provide an abstraction and isolation to the consumers, the virtualization in SenseCloud is composed of two levels (similar to the model in [11]), as shown in Figure 8; these levels are Sensor-Level Virtualization and Consumer-Level Virtualization.Sensor-Level Virtualization refers to the actual virtualization of physical sensors to VMs.Consumer-Level Virtualization refers to the logical grouping of virtual sensors, thus providing an abstraction and isolation to the consumers.
In Sensor-Level Virtualization, SenseCloud virtualizes physical sensors from providers to virtualized instances available to individual consumers.Besides sensor virtualization, we allocate a VM instance to each sensor provider to register, manage, and monitor their sensors and sensor networks, as shown in Figures 8 and 9.In Consumer-Level Virtualization, if a consumer subscribes to any of the sensors, the sensors are virtualized, and multiple virtualized sensors are grouped together.This process allows multiple consumers to customize and control virtual sensors corresponding to a single physical sensor.For example, a consumer C1 could group the temperature sensor (virtual sensor) and light sensor (virtual sensor) as virtual sensor group VSG1, and another consumer C2 could group the temperature sensor (virtual sensor) and pressure sensor (virtual sensor) as virtual sensor group VSG2.These two virtual groups (VSG1 and VSG2) are independent of each other and can be customized by the consumer.
Although our system consists of two levels of virtualization, the sensor data are not replicated by each virtual sensor, and the data from each sensor are stored in a common distributed database.Thus, instead of replication of data, the data are shared with consumers who subscribe to the sensors and own the virtual sensors in their virtual sensor group.
(2) Multitenancy Solution.As shown in Figure 10, SenseCloud has two different perspectives for multitenancy: perspective of sensor consumer and perspective of sensor provider.Database (3) Dynamic Provisioning.In order to allow the sensor consumers to efficiently leverage the vast pool of resources on demand and on a pay-per-use basis, we provide two solutions: scalability solution and load balancing solution.
Our scaling solution considers three parameters for scaling in and out.We consider the average incoming network traffic per instance, average outgoing network traffic per instance, and average CPU utilization per instance.As shown in Figure 11, we dynamically set thresholds for each of these parameters according to the usage patterns.When surpassed, these thresholds trigger the dynamic creation and deletion of instances to efficiently scale out and scale in, respectively.
The load balancing solution is shown in Figure 12.When an application server (e.g., provisioning server) receives the request, it selects a load balancer from the multiple load balancers by using the round robin algorithm.If only one load balancer exists, it is selected by default.The selected load balancer uses the location-aware load balancing algorithm in conjunction with the least outstanding request routing algorithm.Thus, the location-aware load balancing algorithm attempts to select an instance that is closest to the request sender zone and that has the shortest pending list.First, the load balancer selects the availability zone closest to the location where the request is sent.Then, the load balancer determines the application server instances that exist in the selected availability zone.If multiple application server instances exist, the load balancer selects an instance according to the least outstanding request routing algorithm; that is, it selects an instance that has the smallest queue size for outstanding requests.system response time and the performance of our functional algorithms.

Evaluation of Implementation.
Table 2 shows the tools and technologies that we used to implement a prototype of SenseCloud and to test it.We present some screenshots of our implemented prototype.Users type the SenseCloud index page URL in the browser.After successful registration, the users can log in to their account by entering their credentials.After successful login, the users are redirected to the main dashboard page, which shows the links to the functions that the users can perform, as shown in Figure 13(a).
Sensor providers can click the "Manage My Sensors" menu to view, edit, and delete the sensors that they have registered; Figure 13(b) shows the sensor list of a sensor provider.Sensor providers can add sensors by clicking the "Add a Sensor" menu.They can group their sensors and manage the groups through the "Manage Provider Groups" menu; further, they can add sensor hubs by selecting the "Add a Sensor Hub" menu in order to create a sensor network.
Sensor consumers can subscribe to interesting sensors through the "Subscribe Sensors" menu, view the list of available sensors, search for sensors, and subscribe to these sensors.Sensor consumers can manage their subscriptions and view the data of the subscribed sensors through the "Manage Subscribed Sensors" menu.The subscribed sensors can also be grouped together; then, the consumer can view, edit, manage, and visualize the data from the sensors of the created group by selecting the "Manage Subscriber Group" menu. Figure 13(c) shows the temperature sensor data for a subscribed sensor.The consumer can view the daily current, minimum, maximum, and average temperature and can also download the historical data in JSON format by selecting the date.Figure 13(d) shows the maximum and minimum temperatures of the current week for a subscribed sensor.
From the results in Table 5, the use of other performancetuning mechanisms such as connection pooling, prepared statement, and object caching has significantly reduced the average time for a request response.Our system implements connection pooling by maintaining a connection pool of database connections and using the queue mechanism to dequeue or enqueue database connection objects.This process improves the performance significantly because the connection objects are reused.Instead of traditional statements, prepared statements are used for database querying.The prepared statements are precompiled.Object caching is also implemented in our system; the most frequently queried results are cached based on the time-to-live.
In order to evaluate the performance of our load balancing and scalability algorithms, we use a request generator that, at a given time, randomly generates 1000 requests across nine locations.Initially, each location has one instance.All instances have different configurations created in the Elastic Cloud Compute service of Amazon Web Services (AWS).The nine locations on AWS are as follows [23]: (1) US East (N.Virginia).
(5) Asia Pacific (Singapore).Figure 14 is a graphical representation of the request distribution results according to the applied algorithms.From the results shown in Figure 14(a), in the absence of the algorithms, all the 1000 requests were randomly distributed across all the locations.Thus, the result of request distribution is the most uneven in this case.In Figure 14(b), only the load balancing algorithm is applied; the load balancer attempts to distribute the requests originating from a particular location until the capacity of the server to serve requests reaches a maximum.If overload occurs, the requests are redirected to different locations randomly, using the least pending request algorithm.For example, location 1 received 121 requests, and according to the load balancing algorithm, the first 101 requests are handled by the instance at location 1.After the instance at location 1 reaches its threshold, the subsequent requests are directed to other locations by using the least outstanding request routing algorithm.In Figure 14(c), only the scalability algorithm is enabled.When a particular location experiences a surge in network traffic and high CPU usage that reaches the threshold values, our system scales the infrastructure for that location.For example, when the instance at location 1 reached its threshold, the infrastructure at location 1 scaled out, and the subsequent requests were handled by these instances at location 1.In Figure 14(d), both algorithms are enabled, and they work in conjunction to serve the requests.For example, location 1 received 202 requests.Based on the load balancing algorithm and these requests, location 1 scaled out to serve these requests.A similar trend is observed for the other locations.

Conclusions and Future Work
SenseCloud is a cloud platform that addresses the challenges of virtualization, multitenancy, and dynamic provisioning encountered by the IoT industry today.Our cloud infrastructure provides a layer that connects with different sensor networks, resolves the connectivity and engagement concerns, and efficiently provides CSaaS between sensor providers and consumers.SenseCloud provides a two-level virtualization mechanism.It virtualizes the physical sensors to enable the consumers to utilize them without apprehensions about the specification and location details.Further, it allows the  consumers to place dynamic requests for virtual sensor groups and to customize the virtual sensor groups.Sense-Cloud provides different types of multitenancy to sensor providers and consumers: It provides a virtual instance dedicated to each provider to enable isolation without affecting the other providers in case of failover or attacks; further, it also provides common application server instances to all consumers for efficient sharing of resources.SenseCloud provides dynamic provisioning to allow the consumers to leverage the vast pool of resources on demand and on a payper-use basis.The results from our prototype implementation and simulation have demonstrated the feasibility of Sense-Cloud and the achievement of our objectives.
In future work, we must consider the large number of IoT devices and the exponential growth of sensor manufacturers in the market.Instead of adopting a de facto standard, we must define a specific standard for communication, data format, and security between the devices and the cloud platform.The definition of such a standard will eliminate the necessity of frequent changes in the cloud implementation when a new manufacturer enters the market.Current security in SenseCloud is imposed by the role-based access control and provision policy and the two levels of virtualization.With advanced and proper security being the most important feature in the world of connected devices, further development and advancement is required to increase the trust in such cloud platforms among consumers.

Figure 14 :
Figure 14: Request Distributions with/without our load balancing and scalability algorithms on AWS (Li denotes location i): (a) without algorithms; (b) with load balancing; (c) with scalability algorithm; (d) with load balancing and scalability algorithms.

Table 1 :
Comparison of sensor data sharing approaches based on cloud system.

Table 2 :
Tools and technologies.

Table 3 :
System response time versus requests to list the subscribed sensors.

Table 4 :
System response time versus requests to add sensors.