Proceedings of iiWAS2009
Combining Cloud Computing and Wireless Sensor
Networks
Werner Kurschl
Upper Austria University of Applied Sciences
Softwarepark 11
A-4232 Hagenberg, Austria
werner.kurschl@fh-hagenberg.at
ABSTRACT
Just recently emerged a new paradigm for internet-based software
systems which is called as cloud computing. The cloud provides
scalable processing power and several kinds of connectable
services. This distributed architecture has many similarities with
a typical wireless sensor network, where a lot of motes, which are
responsible for sensing and local preprocessing, are
interconnected with wireless connections. Since wireless sensor
networks are limited in their processing power, battery life and
communication speed, cloud computing usually offers the
opposite, which makes it attractive for long term observations,
analysis and use in different kinds of environments and projects,
since the basic infrastructure remains the same.
In this paper we present a model, which combines the concept of
wireless sensor networks with the cloud computing paradigm, and
show how both can benefit from this combination.
Categories and Subject Descriptors
D.2.11 [Software Architectures]: Patterns; C.2.4 [Distributed
Systems]: Distributed applications;
General Terms
Distributed System, Performance, Design, Reliability, Scalability
Keywords
Wireless Sensor Networks, Cloud Computing, Monitoring, Data
Analysis, Web Application
1. INTRODUCTION
Just recently emerged a new paradigm for internet-based software
systems which is called as Cloud Computing, which is to some
extent much driven by prominent software providers like Google
or Microsoft.
Cloud Computing is often referred to as the next step beyond the
Software as a Service (SaaS) paradigm, but there exists no general
accepted definition of Cloud Computing. In an excellent technical
report [1] written by a group of researchers from Berkeley
university an attempt for a general definition and scope of Cloud
Computing is given. It shows that Cloud Computing both include
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. To copy
otherwise, or republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee.
iiWAS2009, December 14–16, 2009, Kuala Lumpur, Malaysia.
Copyright 2009 ACM 978-1-60558-660-1/09/0012...$10.00.
512
iiWAS 2009 Short Papers
Wolfgang Beer
Software Competence Center Hagenberg
Softwarepark 21
A-4232 Hagenberg, Austria
wolfgang.beer@scch.at
the IT hardware and system software infrastructure, as well as the
applications delivered though this new service infrastructure.
Applications are delivered as a service over the Internet. These
services or applications are generally known and defined as SaaS,
which is also used here in context of Cloud Computing in the
same manner. We will use the term Cloud as the hardware and
system software within a datacenter that provides the
infrastructural background to host SaaS.
Figure 1 shows that the Cloud provider has the responsibility to
offer reliable hardware resources and necessary system software
that allows a transparent hosting of services for the SaaS
providers. It is important that the architectural design of SaaS
services has to consider new billing models that support the Cloud
Computing pay-by-use value chain. The provision of SaaS
services most of the time is given through Web applications or
directly through Web Services.
Figure 1. Cloud Computing and SaaS
The Cloud Computing paradigm is based on existing ideas like
Utility Computing, SaaS and Web Services and adds some new
aspects. According to the work from [1], three new hardware
related aspects are introduced by the Cloud Computing paradigm:
1. The illusion and transparent use of an unlimited amount
of resources that can be used by SaaS. Therefore
application or service provider do not have the need to
plan the amount of resources in advance, instead they
dynamically scale the resources on demand.
2. System software has to be aware that services are
hosted according to a pay-by-use billing model. So the
billing model is an integral part of the system software.
3. Hardware systems are designed at the scale of entire
containers that are managed through Virtual Machine
Monitors according to the status of demand.
 iiWAS 2009 Short Papers
The Cloud provides scalable resources, such as processing power
and memory, and several kinds of connectable services on a
transparent, virtually unlimited hardware layer [1]. This
distributed architecture technically has many similarities with a
typical wireless sensor network as depicted in Figure 3, where a
lot of motes (see Figure 2), which are responsible for sensing and
local preprocessing, are interconnected with wireless connections
for large scale observations (see [2]). Since wireless sensor
networks are limited in their processing power, battery life and
communication speed, cloud computing usually offers the
opposite, which makes it attractive for long term observations and
for shared use of data and services in different kind of projects or
analysis tasks.
Figure 2. Crossbow Mote (left) and SunSpot (right)
The huge amount of data, which a sensor network is able to
deliver, demands a powerful and scalable storage and processing
infrastructure. Depending on the sample frequency (e.g. from 100
Hz or more down to few samples a day) of the sensors and the
defined size of a sliding data window for calculating observations
the deployed infrastructure has to scale up memory, storage and
processing power. Today wireless sensor network platforms (e.g.
Crossbow MicaZ, Sentilla JCreate, SunSpot) that perform sensing
and complex calculations are most of the time constrained in their
capabilities and therefore is one appropriate way to solve this
issue offline processing of sensor data if the resources aren`t
sufficient.
Figure 3. Wireless Sensor Network
The combination of wireless sensor networks, with their huge
amount of gathered sensor data and their limited processing
power, with a cloud computing infrastructure makes it attractive
in terms of i) integration of sensor network platforms from
different vendors, ii) scalability of data storage, iii) scalability of
513
Proceedings of iiWAS2009
processing power for different kinds of analysis, iv) worldwide
access to the processing and storage infrastructure, v) resource
optimization, vi) be able to share the results more easily, vii) and
using pricing as one more criteria for the IT infrastructure.
The remainder of the paper is structured as follows: section 2
discusses related work, section 3 presents the architectural model,
section 4 shows an example for energy monitoring, and section 5
discusses advantages and drawbacks of the novel approach.
Section 6 concludes the paper and summarizes the main features
and gives a short outlook for further work.
2. RELATED WORK
BeTelGeuse ( [3], [4]) is a platform for gathering and processing
situational data. BeTelGeuse runs on a mobile devices (e.g., a
cellular phone or a PDA), and gathers data from a body area
network over Bluetooth. It transmits the gathered data to a server
for further processing. The main advantage of BeTelGeuse is that
it can be extended to use new sensors and it runs on several
platforms. A major drawback of the BeTelGeuse is that the server
does not offer a general architecture for data processing and
analysis. The approach also doesn`t consider aspects like
scalability and data security.
TinyDB [5] is a service for data aggregation in low-power,
distributed, wireless environments. Participating motes within the
wireless sensor network are running TinyDB on top of TinyOS
[6]. It allows users to express simple, declarative queries and
have them distributed and executed efficiently in networks of low-
power, wireless sensors. TinyDB offers a simple GUI and a Java
API for declaring and executing queries in an acquisitional query
language, which is similar to SQL. It was used for instance on
Great Duck Island off the coast of Maine, where researchers
deployed a sensor network to monitor (via light, temperature, and
infrared presence detection sensors) the nesting grounds of
seabirds [7]. 100 Crossbow Mica2 nodes stayed operational
during summer and fall of 2002, and also on summer of 2003.
TinyDB has also been used in a network with 80 motes for
microclimate analysis in the redwood trees in Santa Cruz via the
temperature, humidity, light, atmospheric pressure sensors [8].
The main advantage of TinyDB is its ease of use and efficient use
of the available processing and battery power, so that users don`t
have to be experts in wireless sensor network, because one only
has to declare the required queries. All of these deployments
collected a lot of data during several month or years of operation
and it wasn`t possible to easily share the data with other
researcher interested in the collected data.
SPINE [9] is a TinyOS-based software framework for body sensor
signal processing applications. The framework comprises signal
processing components for sensor nodes running the TinyOS [6]
environment and Java components to manage the sensor nodes
from a central coordinator node (star topology). It has further be
taken to the newly create platform DexterNet [10], an open
platform for heterogeneous body sensor networks and its
applications. The framework succeeds in abstracting from low-
level TinyOS programming, and offers a sensor data classification
service, which is operated in a distributed fashion on individual
sensor nodes and a base station computer. The approach also
doesn`t consider aspects like scalability and data security.
Google App Engine ( [11]) and Microsoft Windows Azure ( [12],
[13]) are two competitors in the cloud computing business. Both
provide on-demand compute and storage capabilities to host,
 Proceedings of iiWAS2009 iiWAS 2009 Short Papers

scale, and manage Web applications and services on the Internet • Provide an interface for data export, so that the stored
hosted in a datacenter. Applications for the host environment, data can easily be taken from the Cloud storage and to
which are typically web applications, can be developed with be used in non-cloud solutions.
several different languages, ranging from Python over Java to C#.
The preferred communication method from the client`s computer • Provide a notification service, so that external
to the cloud computing environment is based on web services, services can be informed about specific events; e.g. a
which is a proven technology and supports interoperability (e.g. filter or machine learning component identifies a
between Java and .NET). The use of web services brings a lot of specific situations or has finally calculated a specific
flexibility for the development of those clients, which are hosted result.
in the customer`s environment so that the customer`s legacy • Provide data access rules, so that data, for instance
systems can be easily integrated. They can be developed in an from various customers, can be protected against
arbitrary programming language, as long web services are unauthorized use.
supported. Very important for the development of cloud
computing application is, that these applications can be developed • Provide configuration capabilities for filter chains,
locally, because both (Google App Engine and Microsoft (web) services, notifications, and data access rules.
Windows Azure) come with a local runtime environment that also
facilitates debugging before the application is deployed to the • Provide a management console for the configuration
remote cloud computing environment. of the whole system, so that it can be easily adapted
to specific needs.
3. ARCHITECTURE MODEL
For those parts of the whole systems, which are hosted at the
cloud computing infrastructure do we propose a cloud computing
model that is mainly based on pipes and filters (see [14]). The
pipes and filter design pattern (see Figure 4) is often used in
digital signal processing applications, which also fits well into the
domain of wireless sensor networks (see [15]). Pipes do not
transform data, but generally buffer data and provide a uniform
interconnection mechanism of filters. Filters do specific
processing and transformation on the input data, such as data
refinement or suppression. Filters consume data from an input and
deliver it to an output port. A simple filter could, for example be
responsible for storing the data in the database or deleting data
below or above a certain threshold. More complex filters could be
based on a machine learning components (e.g. WEKA).

Figure 4. Pipe, Filter, and Filter Chain

The general system architecture, which combines sensor networks
with the Cloud Computing paradigm, consists of several basic
services. The main requirements for the system are:
• Receive and manage sensor data from a highly
scalable number of heterogeneous motes.
• Manage a set or chain of filters that perform on-line
analysis on sensor data.
• Run filters offline on a given set of sensor data.
• Permanently run filters on a given set of sensoric data
in order to provide online analysis.
• Provide different, user definable views and
visualizations on the sensor data and calculation
results.
• Provide an interface for changing existing filters or to
develop new filters out of an existing domain specific
modelling tool (e.g. KNIME).
Figure 5. System architecture of the proposed cloud
computing based sensor data analysis environment
The system architecture in Figure 5 shows the collection of base
services provided to the user as SaaS applications. The Sensor
Network Analytical Services group all services that are necessary
to fulfill the requirements that where mentioned above. The
services are based on the Cloud Provider`s infrastructure in order
to scale the demanded resources. The following base services are
necessary to collect and analyze sensor network data within the
cloud:
• Sensor Data Management: It is responsible for the
management of the sensor data within the Cloud
Computing environment. Since the cloud computing
environment provide several ways for storing data, e.g.:
Google AppEngine offers Bigtables [16] for data
persistence and Microsoft Azure provides BLOBs,
queues and tables, it’s necessary to have a flexible data

514
 iiWAS 2009 Short Papers Proceedings of iiWAS2009

access layer, which raises the level of abstraction, so contains and it would provide some properties, so that the data can
that persistence mechanism can be easily exchanged. be accessed in a convenient way. Several classes could then be
• Runtime for Filter Chains: Filters are usually grouped together in a hierarchy, e.g. energy management with
configured for a specific filter chain. A filter chain is a classes like power consumption, temperature, humidity, light
reliable runtime environment for filters and it executes exposure, etc., so that polymorphism can be used in describing
various user defined filters. Such a filter chain which data has to be dispatch to the individual filter chains.
represents a specific analysis, e.g. energy efficiency
analysis of a building or a production process, where
various sensor data (e.g. temperature, gas speed,
vibrations, power/energy consumption, open/closed
windows, etc.) is continuously processed.
• Filter Chain and Filter Management: Filters and filter
chains need some management. This management
service allows the (remote) administration of filters, so
that a user is able to add new filters, delete filters and
aggregate existing filters to combined filters. Combined
Figure 6. Dispatching incoming data to specific filter chains
filters offer an aggregation mechanism for those cases,
where the number of filters gets too big or where 4. EXAMPLE: ENERGY MONITORING
specific filter/processing operations can be grouped
To show how powerful this approach can be, we show an
together. Since many filter chains are executed in example, which uses a wireless sensor network for gathering
parallel, it is necessary to offer a flexible configuration
energy consumption data of various devices and pushes this data
mechanism, which defines the following aspects: i) to the above described cloud. The basis forms a wireless sensor
which filters should be applied, ii) how is their ordering,
network (see Figure 7) built with JCreate motes from Sentilla,
iii) how big is the temporary buffer of a pipe (e.g. if a which are reading the power consumption of different devices
sliding window is applied on previous data), iv) how
from an attached 30 Amp current sensor AC&DC from Phidgets.
internal and external services (e.g. notification service) The Sentilla mote JCreate sends the sensed data in a predefined
can be accessed, and v) the dispatching of the incoming
interval (e.g. every 5 seconds) to its neighbors over the wireless
sensor data to the specific filter chains, so that the data connection link built on the Zigbee (IEEE 802.15.4) protocol. The
of several user`s isn`t mixed up and filter chains with
message being sent is called PowerMessage, and it contains the
specific analysis tasks get only the relevant sensor data. mode identification number, a message number which is
• Visualization / Views: A powerful visualization is continuously increased, and the electric potential provided by the
necessary, since the cloud computing environment current sensor. It is possible to have more data in the message, and
stores and processes a lot of data. The visualization for example to sends a number of readings in one message, which
service provides various predefined and user-defined is called in-network processing and preserves a certain amount of
views on the data and analysis results. The energy [17], but we left this out for the sake of simplicity in this
visualizations and views can be implemented with paper.
languages like OLAP and data warehouses.
• Notification Service: This service is a mechanism to
inform external applications and services about specific
situations, where it fires an event. The service itself can
provide a set of predefined and user-defined rules. Such
a rule could fire an event, if for instance, several sensor
values exceed a certain vibration threshold. This could
be for example, an indication that a gas pump failure is
approaching.
The core of the cloud computing system is built around a pipes
and filter chain approach. Since the system has to maintain many
filter chains in parallel, the reliable dispatching (see Figure 6) of
the incoming sensor data to the specific filter chains is very
important, so that the data of several user`s isn`t mixed up and
filter chains with specific analysis tasks get only the relevant
sensor data.
The dispatcher can be configured with the Filter and Filter Chain
Management. The configuration defines a mapping, in terms of i) Figure 7. Power measurement with Sentilla motes
customer/data owner so that the data of different customers can be
separated in different filter chains, and ii) sensor data type, which Since our wireless network is organized as a mesh network, each
has to be put to a specific filter chain. We assume in our individual mote forwards received messages from its neighbors
approach, that data is described and processed in an object- within its communication range of 20-50 m, depending of the
oriented manner, so that incoming data (e.g. a temperature or a actual environment. This forwarding is achieved through using the
power consumption measurement) has a data type and is derived collect-protocol provided by the Sentilla mote implementation,
from a base class. The specific class would describe the data it

515
 Proceedings of iiWAS2009
which eases the code to be developed for and deployed to the
individual motes.
Figure 8. Sentilla USB gateway for ZigBee protocol
The mesh network contains also a Zigbee USB gateway (see
Figure 8), which is attached to a computer and collects the
messages being send from the motes. Such a ZigBee USB
gateway can also be used to deploy new application over the air
onto motes, which saves a lot of time in the setup stage, where all
motes are prepared for the energy monitoring task. Even the
communication range of an individual mote is quite limited, the
mesh networks allows us to communicated over several hundred
meters to the ZigBee USB gateway, using the Multi-Hop RF
advantage.
The computer with the attached ZigBee USB gateway manages
the communication with 20 or more motes, but it could be up to
65,000 motes on a network. The PC itself acts as a
communication link between the wireless sensor network
observing the environment and the remote cloud computing
infrastructure. The component in Figure 5 named wireless sensor
network has been refined accordingly. This component acts in our
architecture as a wireless sensor network communication
(WSNCH) hub or router.
Figure 9. Wireless Sensor Network Communication Hub
The WSNCH as depicted in Figure 9 can use for the
communication with the cloud computing infrastructure those
communication media, which are appropriate. In cases, where a
PC is used and a wired internet connection exists, for example
Ethernet, the fast wired connection can be used. In cases, where
the wireless sensor network operates in more remote or harsh
environment areas, for example in a big steel or chemical plant or
in urban areas, a wireless connection based on HSDPA, UMTS, or
even GPRS can be applied. In our case, it does not matter, if the
WSNCH is a PC/Laptop or just a Smartphone, hosting the
relevant software components for the communication.
The configuration data, which is needed for each individual
WSNCH, usually contains at least customer identification, access
authorization, location of the cloud computing infrastructure, and
buffering settings in case of communication problems.
The data, which is pushed up to the cloud computing
infrastructure gets stored and processed in the previously
configured filter chains. One of the simplest filter chains would
only put the sensor data into the persistent storage. Finally, the
516
iiWAS 2009 Short Papers
data can be used for further analysis and visualization. Figure 10
shows on simple visualization of the energy/power consumption
of a customer over a given time period.
A common visualization technique is based on web applications
since cloud computing environments are operated remote to the
customer, and which frees the user from local installation. It
facilitates also the cooperation within research communities since
results can be shared more easily.
Figure 10. Example visualization of energy/power
consumption
In our prototypical implementation do we have a mix of languages
and platforms, which make it attractive for heterogeneous
environments. The wireless sensor network platform Sentilla uses
the Java Micro Edition (JME), so that the applications deployed to
the motes are written in Java. The wireless sensor network
communication (WSNCH) hub run either on a Java virtual
machine or on the .NET Common Language runtime. We
currently have experimented with both platforms. The same
situation do we have for the cloud computing environment.
Microsoft Windows Azure prefers the .NET platform, so that we
have chosen C# for the implementation. Finally, have we used
Java as the implementation language for the Google App Engine.
5. DISCUSSION
To identify advantages and drawbacks of the proposed
combination of wireless sensor networks and cloud computing
environments we discuss it in terms of i) development issues , ii)
scalability, iii) interoperability, iv), security, v) law, vi) business
issues.
The development of such systems has the advantage, that several
programming languages and different kind of devices can be used
and easily interconnected. It provides a lot of flexibility in terms
of programming languages and devices, but this come with the
drawback of heterogeneity, which quite often leads to more
complexity.
The scalability of this approach seems to be unlimited, since
wireless sensor networks operate independently and in a mesh
network, and are connected to the cloud computing environment
through a scalable number of wireless sensor network
communication hubs. The cloud computing environment itself
offers a scalable infrastructure, which makes it very attractive.
The main bottleneck in this architecture is the remote
communication between the wireless sensor network
communication hubs and the cloud computing environment. The
local computation within the cloud computing environment is
usually fast, but the remote communication between the hub and
the cloud computing environment is much slower, which has to be
considered in advance and further investigated in the future (see
[18], [19]).
 iiWAS 2009 Short Papers
The interoperability between different kinds of devices, services,
and programming platforms is organized on the level of web
services interfaces, which provides a good level of abstraction and
is a proven concept. But it must be noted, that the necessary
interoperability measures usually lead to some overhead, which
may have an impact on the overall system performance (see [18]).
Several measures are taken to ensure security of the sensed,
processed and stored data. The data store and processed in cloud
computing infrastructure are protected by authentication and
authorization measures, and can if needed be encrypted. But
Foster [20] mentioned, that currently, the security model for
Clouds seems to be relatively simpler and less secure than the
security model adopted by Grids. The sensor data transferred from
the wireless sensor network communication hub to the cloud
computing infrastructure can be secured by TLS/SSL, which is a
proven technology. Last but not least can the data communication
within the wireless sensor network also be secured with a 128-bit
AES encryption. Since motes in a wireless sensor network have
limited energy resources (i.e. are battery powered), and they
sometimes don`t process in some cases mission critical data, it`s
possible to omit the encryption overhead if necessary.
The storage of data outside the corporate environment or outside
the state/country is sometimes strictly regulated in company
policies and laws. Some institutions like the Michigan State
University clearly state in a document (see [21]) defining the use
of cloud computing services as follows: “Cloud-computing
services must NOT be used with any of these confidential data
types, unless an appropriate contractual agreement can be
negotiated with the service provider by the University”. Such
policies sometimes prevent the adoption of remote cloud
computing services in specific projects.
Beside of the technical issues offers the combination of cloud
computing and wireless sensor network a lot of opportunities for
new business models (see [1]). But technical risks of wireless
sensor networks and cloud computing must not be
underestimated.
6. CONCLUSION
We have presented a novel way of combining wireless sensor
networks with cloud computing services. The wireless sensor
networks are used to sense and collect environmental data. Since
wireless sensor networks are limited in their processing power,
battery life and communication speed, cloud computing usually
offers the necessary storage capacity and processing power for
long term observations, analysis and use in different kind of
environments and projects, since the basic infrastructure remains
the same. The presented concept and implementation must now be
further evaluated in different use cases to measure its advantages
and shortcomings. Further work should investigate the integration
of predefined complex filters and different classifiers and define a
suitable ontology for semantic reasoning, so that data analysis can
be done within the cloud computing environment.
7. REFERENCES
[1] M. Armbrust, A. Fox, R. Griffith, A. Joseph, R. Katz, A.
Konwinski, G. Lee, D. Patterson, A. Rabkin, I. Stoica, and
M. Zaharia,., "Above the Clouds: A Berkeley View of Cloud
Computing," University of California, Berkeley,
UCB/EECS-2009-28, 2009.
517
Proceedings of iiWAS2009
[2] Feng Zhao and Leonidas Guibas, Wireless Sensor Networks -
An Information Processing Approach.: Morgan Kaufmann,
2004.
[3] Petteri Nurmi, Joonas Kukkonen, and Eemil Lagerspetz,
"BeTelGeuse – A Tool for Bluetooth Data Gathering," in
Proceedings of the ICST 2nd international conference on
Body area networks , Florence, Italy , 2007.
[4] Joonas Kukkonen, Eemil Lagerspetz, Petteri Nurmi, and
Mikael Andersson, "BeTelGeuse: A Platform for Gathering
and Processing Situational Data," IEEE Pervasive
Computing, vol. 8, no. 2, pp. 49--56, Aug. 2009.
[5] Samuel Madden, J. Franklin, Joseph M Hellerstein, and Wei
Hong, "TinyDB: An Acqusitional Query Processing System
for Sensor Networks," in ACM Transactions on Database
Systems, 2005, p. 47.
[6] Philip Levis et al., "TinyOS: An Operating System for
Wireless Sensor Networks.," in Ambient Intelligence., 2005.
[7] R. Szewczyk, A. Mainwaring, J. Polastre, and D. Culler, "An
analysis of a large scale habitat monitoring application," in
Proceedings of the Second ACM Conference on Embedded
Networked Sensor Systems (SenSys), 2004.
[8] G. Tolle et al., "A macroscope in the redwoods," in
Proceedings of the Third ACM Conference on Embedded
Networked Sensor Systems (SenSys), 2005.
[9] R. Giannantonio, F. Bellifemine, and M. Sgroi, "SPINE -
(signal processing in node environment): A framework
forhealthcare monitoring applications based on body sensor
networks," 2008.
[10] Philip Kuryloski et al., "DexterNet: An open platform for
heterogeneous body sensor networks and its applications," in
Proceedings of 6th International Workshop on Body Sensor
Networks, Berkeley, USA, 2009.
[11] Charles Severance, Using Google App Engine , O'Reilly, Ed.:
O'Reilly, 2009.
[12] Joshy Joseph, "Cloud Computing: Computing: Patterns For
High Availability, Scalability, And Computing Power With
Windows Azure ," MSDN Magazine, May 2009.
[13] Elisa Flasko, "Data Services: Access Your Data On Premise
Or In The Cloud With ADO.NET Data Services," MSDN
Magazine, May 2009.
[14] Erich Gamma, Richard Helm, and Ralph E. Johnson, Design
Patterns. Elements of Reusable Object-Oriented Software.:
Addison-Wesley Longman, 1995.
[15] Werner Kurschl, Stefan Mitsch, and Johannes Schönböck,
"Modeling Distributed Signal Processing Applications," in
Proceedings of 6th International Workshop on Body Sensor
Networks, Berkeley, USA, 2009.
[16] Fay Chang et al., "Bigtable: A Distributed Storage System
for Structured Data," in OSDI06: Seventh Symposium on
Operating System Design and Implementation, Seattle, WA,
2006.
 Proceedings of iiWAS2009 iiWAS 2009 Short Papers

[17] K. Römer, "Time Synchronization and Localization in 1-10, 2008.

Sensor Networks," Swiss Federal Institute of Technology
Zürich (ETH Zürich), Zürich, Schweiz, Phd Thesis 2005. [21] David Gift, "Appropriate Use of “Cloud Computing”
Services by the Michigan State University Community,"
[18] F. Douglas, A. Mirno C. Loosley, High-Performance Michigan State University, WORKING DRAFT 2008.
Client/Server.: John Wiley and Sons Inc., 1997.
[22] C. Hewitt, "ORGs for Scalable, Robust, Privacy-Friendly
[19] Peter J. Denning, "The Locality Principle," Client Cloud Computing," IEEE Internet Computing, vol. 12,
COMMUNICATIONS OF THE ACM, vol. 48, no. 7, pp. 19- pp. 96-99, 2008.
24, July 2005.
[20] Ian Foster, Yong Zhao, Ioan Raicu, and Shiyong Lu, "Cloud
Computing and Grid Computing 360-Degree Compared,"
Proc. Grid Computing Environments Workshop GCE '08, pp.

518