LABRADOR LAYOUT

7/8/10

12:09 PM

Page 57

G-Sense: A Scalable Architecture for

Global Sensing and Monitoring
Alfredo J. Perez, Miguel A. Labrador, and Sean J. Barbeau, University of South Florida
Abstract
The pervasiveness of cellular phones combined with Internet connectivity, GPS
embedded chips, location information, and integrated sensors provide an excellent
platform to collect data about the individual and its surrounding environment. As a
result, new applications have recently appeared to address large-scale societal
problems as well as improve the quality of life of the individual. However, these
new applications, recently called location-based services, participatory sensing,
and human-centric sensing, bring many new challenges, one of them being the
management of the huge amount of traffic (data) they generate. This article presents G-Sense, for Global-Sense, an architecture that integrates mobile and static
wireless sensor networks in support of location-based services, participatory sensing, and human-centric sensing applications. G-Sense includes specific mechanisms
to control the amount of data generated by these applications while meeting the
application requirements. Furthermore, it creates a network of servers organized in
a peer-to-peer architecture to address scalability and reliability issues. An example
prototype application is presented along with some basic results and open
research issues.

dvancements in computing and communication

systems combined with the development of microelectro-mechanical systems (MEMS) are changing
the way the physical world is understood. Wireless
sensor networks (WSNs) were born as the combination of
these elements, allowing us to take measurements of the physical environment and gather data of interest for monitoring
and decision making purposes. Nonetheless, WSNs consist of
small computing devices with strong limitations in terms of
computing power, storage, mobility, communications, and,
more important, energy. These limitations, plus the still high
cost per device, have limited the use of WSNs to address
large-scale societal problems to very few cases, if any.
At the same time, two important developments have
occurred. First, the number of cellular users has increased
dramatically over the last several years. And second, the characteristics of the mobile devices have improved considerably,
outperforming their WSN counterparts by a substantial margin. For example, mobile devices now come with Internet connectivity, other communication interfaces such as Wi-Fi and
Bluetooth, more computing power and storage than their
WSN counterpart, and come equipped with a microphone,
camera, GPS, accelerometers, and sometimes other sensors.
The interesting part is that this platform is already out there,
ready to be used. Furthermore, it does not present the deployment issues, high costs, and mobility and energy limitations of
WSNs.
These developments have recently made researchers use
cellular phones as a mobile sensing platform to collect data
we could not collect before and address large-scale societal
problems. Furthermore, the same platform can also be used
to collect not only environmental data but also data pertaining
to the user (health, activity, behavior, etc.), which could be
used to improve the users quality of life. Location-based ser-

IEEE Network July/August 2010

vices (LBS), participatory sensing (PS), and human-centric sensing (HCS) are names that have recently appeared in the
research literature to refer to these types of applications.
PS aims to collect enough data to measure and monitor a
variable of interest in a community, city, country, or even
worldwide with the participation or collaboration of many cellular users. Examples of PS are applications that collect air quality measurements to determine the pollution index; real-time
GPS locations to assess traffic congestion and travel times; and
noise, humidity, and temperature measurements to show realtime maps with these variables. HCS applications, on the other
hand, aim to collect data about the health of the user, or a
group of users. Both PS and HCS applications integrate specific
sensors into the cellular telephone to measure the variables of
interest. Carbon dioxide, temperature, humidity, heart rate,
breath depth, and oxygen in the blood are examples of variables that need specialized sensors beyond the ones normally
available in cellular phones. Normally, GPS position and
accelerometer data are used in many LBSs such as real-time
tracking applications for personal security, children tracking,
pet tracking, and fleet and asset management to study, monitor,
and alert about the behavior of the individual, her health, the
effectiveness of medicine and treatments, and so on.
Although this new sensing platform possesses very nice features, and LBSs, PS, and HCS applications seem to be ready
for prime time, they bring new technical and nontechnical
challenges. Imagine for a moment an application to track people in real time that sends a 40-byte packet with the GPS
position of the user to a central server every second. If 10,000
users are subscribed to this service, the application automatically generates 1.4 Gbytes of data per hour. In an envisioned
scenario with many different types of LBSs, and PS and HCS
applications all over the world, these applications may easily
become the next wave of traffic in the Internet, after the

0890-8044/10/$25.00 2010 IEEE

57

LABRADOR LAYOUT

7/8/10

12:09 PM

Page 58

recent wave of traffic generated by peer-to-peer applications.

Understanding the nature and characteristics of this traffic
and finding new ways to manage it will be essential to maintain or improve the level of service we currently enjoy.
This article presents G-Sense, a two-tier client-server and
peer-to-peer architecture that integrates mobile and static
sensors, and supports the deployment of LBS, PS, and HCS
applications. The article explains the main components of the
architecture and describes an example prototype application
that combines LBS, PS, and HCS characteristics. Four specific
example mechanisms used in this application to address traffic
and scalability issues are also explained along with some basic
results. Finally, the article lists several open issues that need
further research.

Related Work
Wireless sensor networks research has its origins with the
Defense Advanced Research Project Agency (DARPA) in the
late 1970s with the Distributed Sensor Networks program [1].
This program was an initiative to build cooperative networks
of low-cost sensing devices that could perform autonomous,
yet cooperative sensing. With the advancement of MEMS
technology in the late 1990s, the technology for static WSN
platforms was developed [1, 2]. The idea was to build nodes of
small size (as small as 2 mm 2 ) that could be able to sense,
transmit data, and harvest their energy needs from the environment, so they could be active for years and cheap enough
to be deployed everywhere. A complete survey on the evolution of this topic is provided in [3]. As of today, this vision has
not been fully achieved, as most WSN nodes remain fairly big
and costly, which has limited the use of WSNs to rather small
and focused deployments.
Cellular technology, mobile Internet connectivity, and the
widespread utilization of cellular phones are making the envisioned goal of WSNs a reality. In combination with positioning and MEMS technologies, LBS, PS, and HCS applications
using WSNs of cellular phones have started to emerge. LBS
applications are the most common thus far with several tracking services being offered by independent companies as well
as cellular carriers. Many architectures and middleware have
been proposed for LBS applications [46]. Not so common
are PS and HCS applications. MetroSense [7], which calls for
a human-centered approach to sensing, is an architecture that
mixes static wireless sensor networks with mobile cellular
phones, a federated server architecture, and already established social networks such as Facebook, MySpace, and IM to
share sensed information in a secure manner and promote
social interaction, study life patterns, find friends, and several
others.
Under the name of Participatory Sensing [8], researchers
from the Center for Embedded Networked Sensing at UCLA
have developed several projects that involve community-oriented sensing. CENS projects focus on how communities,
using sensor-enabled cellular phones, can monitor variables of
interest and events that affect the lives of the people in the
community [9]. Similar projects have been developed by
research groups at MIT [10], University of Cambridge (Cambridge Mobile Urban Sensing) [11], and Microsoft Researchs
Networked Embedded Computing Group [12].
Since 2005 our Location Aware Information Systems Laboratory at USF has been involved in the development of several projects utilizing cellular phones as sensing devices for both
community and personal sensing. By using GPS-enabled
devices and the architecture described in [4], we have developed applications like Wi-Via, a community-oriented Amber
alert application that captures geotagged images and videos

58

and sends them to a law enforcement central location; TRACIT, a personal-oriented system that keeps track of peoples
commute behavior and provides feedback to optimize travels,
costs, and time; and TAD, a travel assistant device that helps
people with cognitive disabilities use public transportation systems.
The applications and architectures described before differ
from the architecture presented here in several aspects. First,
they are tailored to either LBS, PS, or HCS applications only.
Second, they do not explicitly address the issue of managing
the large amount of traffic they generate. Third, they mostly
use mobile cellular phones only. Finally, they all have a rather
local scope.

G-Sense: A Scalable Architecture for Global

Sensing and Monitoring
G-Sense is a two-tier client-server and peer-to-peer architecture that supports the development of local and global LBS,
PS, and HCS applications. G-Sense integrates mobile sensing
devices, static WSNs, and servers to perform data collection
from the environment and the individual, analyze the data at
different levels of the architecture, make estimations and
inferences, and provide feedback and visualization capabilities. G-Sense is based on the high-level architecture shown in
Fig. 1, which consists of the following components:
Sensing devices: This part of the architecture consists of all
types of sensors utilized by the applications and the interfaces available to transfer the data from the sensors to the
first-level integrating device, which is either the mobile
device or the base station. This pertains to the data collection function.
First-level integrator: This is the device that collects all data
sent by the sensors. In the architecture it is represented by
either a cellular phone or a laptop, or the base station in
the case of a WSN. This component may perform initial
data analysis over the data collected by the sensors for
immediate feedback.
Data transport network: The data transport network is the
combination of IP-based networking technologies that
make possible the transfer of data from the first-level integrator device to the servers.
Servers: This component stores the data collected from the
mobile nodes and static WSN nodes. In addition, it performs additional processing on the data to perform estimations and inferences that cannot be performed in either the
mobile node or the base station due to data availability
and/or the complexity of the algorithms. This component
also supports data visualization using Web 2.0 tools for
reporting purposes.
G-Sense provides a framework to implement this vision,
including a software architecture that supports all these functions. G-Sense is a hybrid client-server and peer-to-peer architecture, where the client-server part abstracts the base station
and mobile sensing nodes as clients that connect to a server,
which is a more powerful computer system in terms of processing, energy, communication, and storage capabilities. The
architecture shown in Fig. 1 is meant to have a rather local
scope and be replicated in as many other sites as necessary.
Then servers from different sites are interconnected using a
peer-to-peer system, so the sensing tasks are distributed for
load balancing, traffic filtering, and scalability purposes. This
peer-to-peer system, shown in Fig. 2, is the one that allows
global deployment of LBS, PS, and HCS applications, and
manages the traffic in the network. The software architecture
that supports this platform is described next.

IEEE Network July/August 2010

LABRADOR LAYOUT

7/8/10

12:09 PM

Page 59

Static sensor networks

environmental information
GPS

Internet

Mobile
sensor
network

Personal
and
environmental
information

Servers

Data collection

Data analysis
point

Data transport

Data storage,
estimation, inference,
visualization and
feedback

Figure 1. G-Senses hardware architecture.

Client-Side Software Architecture

G-Senses software architecture for the client is shown in Fig.
3. It consists of four major components known as the Sensor
Communication and OS layer, and the Location Management,
Sensor Management, and Server Communication Management components. The Sensor Communication and OS layer
is closest to the hardware and is common to all the other
components, which are more specific in terms of the function
that they perform.

Sensor Communication and OS Layer

The Sensor Communication and OS layer abstract the communication with the sensors that are connected to the mobile
device. Currently, cellular phones and laptops come equipped
with Wi-Fi and Bluetooth interfaces that can be used to integrate external sensors that already come with such communication capabilities. Examples of commercially available devices
that can be used to measure body variables are Zephyrs BioHarness strap, the Nonin Pulse Oxymeter, and the Alive Heart
and Activity Monitor, among others. More specialized sensors,
such as those measuring gases, temperature, and humidity, are
usually built in special circuit boards equipped with such network interfaces. Other sensors, such as accelerometers and
GPS chips, come already integrated in the mobile device.

Location Management Component

The Location Management component provides the mobile
sensing application with information about the position of the
device. As location information is important to any mobile

IEEE Network July/August 2010

sensing application, the careful management of this information is required. For this reason G-Sense manages location
information in a special component that consists of three
modules.

Location Acquisition Module This module obtains the position of the device. Example implementations of this module
are the Java Location API (JSR-179 or 293) for Java ME, the
Androids Location API, any custom made GPS wrapper, or
location services, such as the one provided by Skyhook, or
similar companies. Therefore, this subcomponent abstracts the
positioning methods and devices (GPS) the mobile sensing
device can use to obtain a location.
Location Estimation Module The main objective of this module is to combine the location information from different
sources that the device gathers using the Location Acquisition
module and provide a better estimate of the units position.
This module could utilize technologies like dead reckoning, or
use historical data about the travel patterns of the user to
obtain or improve the position of the unit.
Critical Point Management Module The Critical Point Management module makes two important decisions. First, it
decides whether it is worth spending extra energy trying to
obtain the units position or not. Second, once the units position is obtained, it decides whether it is worth sending it to
the server or not. This is one of the most important modules
in the clients software architecture because it is meant to
reduce the amount of traffic on the network, reduce energy

59

LABRADOR LAYOUT

7/8/10

12:09 PM

Page 60

Static sensor networks

environmental information

Static sensor networks

environmental information

GPS

GPS

Mobile
sensor
Internet
network
Personal
Servers
and
environmental
G
Data storage,
information
Data
estimation,
Data
Data
analysis
inference,
collection point transport visualization
and feedback

Mobile
sensor
network
Personal
and
environmental
information

Internet
Servers

Data storage,
Data
estimation,
Data analysis
Data
inference,
collection point transport visualization
and feedback

Miami
Berlin

Static sensor networks

environmental information
GPS

Static sensor networks

environmental information
G

Mobile
sensor
Internet
network
Personal
and
Servers
environmental
Data storage,
information
Data
estimation,
Data analysis Data
inference,
collection point transport visualization
and feedback
Washington

GPS

Mobile
Internet
sensor
network
Personal
Servers
and
environmental
Data storage,
information
Data
estimation,
Data
Data
analysis
collection
transport inference,
point
visualization
Baghdad
and feedback

Figure 2. G-Senses peer-to-peer architecture.

consumption in the client, and save storage space while satisfying the requirements of the application.

users needs or the application to send immediate alerts to the

user, caregiver, or whoever is designated or appropriate.

Sensor Management Component

Server Communication Management Component

The Sensor Management component consists of the Data

Acquisition module, the Feature Detection module, and the
Event Notification Manager.

This component manages the communication with the server

as well as the security and privacy policies for the mobile sensing application. It consists of the Communication Management, Security and Privacy, and Session Management modules.

Data Acquisition Module The Data Acquisition module

consists of an API to control the sensors. For example, this
API should include functionality to query the sensors and
obtain measurements, turn the sensors on or off, change the
frequency of queries, and so forth. The implementation of this
module should return an object that represents the measurement along with the units utilized to obtain it. An example
implementation of this module is the JSR 256: Mobile Sensor
API for Java ME.
Feature Detection Module Using the data obtained by the
Data Acquisition module, the Feature Detection module provides the functionality to learn and detect behaviors and/or
features that are useful for the application and the user. This
module is meant to perform an initial analysis on the data and
provide immediate feedback to the user, if necessary. Data
mining and/or artificial intelligence techniques are normally
used for these tasks.
Event Notification Manager Upon the detection of features
of interest, this module provides the functionality to notify the
mobile application of the feature that has been recognized.
Thresholds can be set up in this module according to the

60

Communication Management Module This module provides

standard ways to transfer data from the clients to the server
and vice versa. Standard interfaces exist to utilize HTTP,
HTTPS, TCP, and UDP, which are chosen according to the
application requirements. For example, continuous real-time
data (e.g., GPS fixes every second in a tracking application)
are sent using UDP. On the other hand, if reliability is
required, (e.g., a medical application, transfer of logged sensing data, and session maintenance), TCP or HTTP(S) is used.
Security and Privacy Module Security and privacy are key
aspects in any LBS, PS, or HCS system. This module includes
the interfaces and mechanisms needed to provide security and
guarantee privacy. Encryption algorithms, user identity randomization mechanisms, and security policies and their enforcing
mechanisms are some examples of the mechanisms included in
this module. These mechanisms are application-dependent and
should be set by the user or system administrator.
Session Management Module This module consists of the
methods needed to exchange session data with the server. Session data consists of users data, devices, session ids, and simi-

IEEE Network July/August 2010

LABRADOR LAYOUT

7/8/10

12:09 PM

Page 61

Mobile sensing application

Location management

Sensor management

Server communication
management

Clinical point management

Event notification manager

Session management

Location estimation

Feature detection

Security and privacy management

Location acquisition

Data acquisition

Communication management

Sensor communication management

Sensor communication and OS layer

Operating system

Figure 3. G-Senses client-side software architecture.

lar data plus individual session information such as the number of packets sent and the session key.

Server Sensing Management Component

G-Senses server-side software architecture is shown in Fig.

4. From the bottom up, the architecture starts with the
Operating System and Application Server components. The
application server is a runtime environment for server applications. Examples of these are the Java Platform Enterprise
Edition (J2EE) application server, Microsofts Internet
Information Services (IIS), and the Apache HTTP Server.
At the same level are the spatial and relational databases
needed to store all the data. The following layer consists of
three components that manage the communication of the
server with mobile and static sensors and other servers.
These are the Mobile WSN Management component, the
Static WSN Management component, and the Server Sensing Management component. The following four components are the Data Collection and Analysis components, the
Data Visualization Component, and the Sensing Application.
All these components are described next.

This component interconnects a sensing-aware application

with other sensing applications in other servers. With this
functionality, a sensing task can be distributed among several
servers, which reduces and balances the load in a server and
provides service reliability for sensing in hostile environments
such as a war zone. This component consists of the Task Management module, which provides similar functionality as the
one in the mobile WSN, and the Communication Management module that provides connectivity among servers.
The Communication Management module is responsible
for the establishment and maintenance of the peer-to-peer
architecture. By interconnecting servers in a peer-to-peer
fashion, a sensing cloud is created, allowing servers to share
information. Our current implementation of this subcomponent is based on a protocol called Geotella. Geotella maintains an overlay of geographic-aware servers, updating the
peers locations as well as the current sensing area assigned to
each server. Using a non-distributed hash table (DHT)
approach to manage the location, Geotella assigns and distributes sensing tasks geographically.

Mobile WSN Management Component

Data Collection and Analysis Components

The Mobile WSN Management component manages connectivity with the mobile sensing devices. The functionality of this
component matches those included in the Server Communication Management component in the client-side software architecture. In addition, it includes the Task Management module,
which executes policies over the received data from the
mobile devices to decide whether to store the data in the
database, invoke a data analysis algorithm, or notify other
devices in the system.

These two server components use the data coming from static
and mobile sensors, other servers, and historical data stored in
the database to perform inference, correlation, and data analysis tasks. Contrary to the data analysis tasks performed at the
client device, which are based only on local and individual data,
these components have a complete picture of the situation and
therefore are able to make deeper and global analyses.

Server-Side Software Architecture

Static WSN Management Component

The Static WSN Management component integrates static
WSNs in the G-Sense architecture. It consists of the Communication Management, WSN Network Services, and Task
Management modules. The Communication Management
module provides the basic transport and session management
functionality to connect and transfer data to and from the
base station of the WSN. The WSN Network Services module
includes algorithms that cannot be run in the base station
because of the lack of data and/or processing capacity. Examples of algorithms that could run as services for a WSN are
topology control and topology maintenance algorithms. The
last module is Task Management, which also executes policies
and makes decisions based on the received data.

IEEE Network July/August 2010

Data Visualization Component

The final component of the architecture is the data visualization component. This is implemented in the architecture using
Web 2.0 tools such as the Google Web Toolkit and open
source mapping applications, which along with geographic
markup languages such as KML show the data in geographic
browsers (e.g., Google Earth, NASA Worldwind).

A Prototype Application Combining LBS, PS,

and HCS
G-Sense has been prototyped in a military application that
combines LBS, PS, and HCS, integrates static and mobile
sensing clients, and implements the peer-to-peer architecture
for data traffic management, reliability, and scalability purpos-

61

LABRADOR LAYOUT

7/8/10

12:09 PM

Page 62

Sensing aware application

Data visualization
Data analysis
Data collection
Mobile WSN management

Server sensing management

Static WSN management

Task management

Task management

Task management

Session management

WSN network services

Communication
management

Communication management

Communication management

Spatial
and
relational
database

Application server
Operating system

Figure 4. G-Senses server-side software architecture.

es. The application supports military deployments by providing the following main services:
Real-time tracking of soldiers (LBS part).
Real-time health status of each soldier with body temperature, pulse rate, breathing depth, and EKG information, if
necessary (HCS part). These sensors are automatically activated by the application either periodically or when necessary based on locally sensed data, type of activity, and other
variables.
Sensing of environmental gases and variables of interest
such as temperature, humidity, CO2, and poisonous gases
(PS part).
Integration of static WSNs with intrusion detection capabilities. Upon intrusion detection, the system automatically
generates Geo-Alerts to those soldiers close enough to the
event and to the main control station.
Real-time feedback based on locally sensed data. This analysis and notification is performed in the client device.
Real-time situational awareness feedback based on location.
This Geo-Alert capability is implemented in the server.
Data analysis with data collected from all users and historical data from the database. Feedback to individual or
groups of users is also provided using the Geo-Alert capability.
Data visualization allows authorized users at each server
location to see the users and the variables of interest in real
time.
The services described above are services per deployment
site. Since there are many deployments worldwide at the same
time, global information is needed to coordinate military tasks
appropriately. The peer-to-peer architecture and the Geotella
protocol provide this functionality. If one deployment consists
of the architecture shown in Fig. 1, the peer-to-peer architecture provides a distributed system-of-systems view that integrates as many individual deployments as necessary, as shown
in Fig. 2. Please notice that this same distributed architecture
could be used for many other PS applications. If each individual system collected CO2 data from a PS application in a city,
the distributed system would be able to show a country pollution map.
The following sections describe some of the algorithms that
can be implemented to reduce the amount of traffic (redun-

62

dant or unnecessary data), and therefore save energy in the

client device and network bandwidth, and the Geotella protocol. Then a list of open research issues is included.

Reducing Data Traffic and Saving Energy

Reducing the amount of unnecessary traffic and the energy
consumption in the mobile device are critical aspects in LBS,
PS, and HCS applications. Since one of the most expensive
functions in resource-constrained devices is communications,
reducing the amount of unnecessary or redundant data has
the double effect of saving bandwidth, particularly important
in bandwidth scarce networks such as public cellular networks
and wireless mobile ad hoc military networks, and saving
energy. Four client-side mechanisms meant to achieve these
goals are the following.

The Client State Machine The client state machine automatically determines the rate at which GPS position fixes are
queried according to the location of the user, the GPS signal
strength, and other GPS information. Even though the application may need to send new GPS fixes to the server, it makes
no sense to continue querying the GPS system if the user is
indoors with no GPS coverage, or in the same position (not
moving) for a long time. Figure 5a shows an example of a
state machine, and Fig. 5b shows that the state machine accurately achieves its goals, making the mobile device active or
inactive at appropriate times.
Geo-Sensing This is a feature that activates or deactivates
the sensing functionality of the mobile device according to its
current location. In a community-oriented PS application
meant to assess the pollution index in a particular zone of a
city, it does not make sense to have the sensor activated and
sending data from a location outside the specific zone.
Time-Sensing Similar to geo-sensing but based on time. The
sensors are activated only during specific time slots, peak
hours, or shifts, and the like.
The Critical Point Algorithm The critical point algorithm,
which is also implemented in the Critical Point Management
module, decides whether or not to send a GPS fix to the serv-

IEEE Network July/August 2010

LABRADOR LAYOUT

7/8/10

12:09 PM

Page 63

Move toward state [0] (gradual or jump) based on certainty of movement.

Making the System Scalable

State
0

State
1

State
n-1

State
n

GPS interval
=4s

GPS interval
interval
GPS
s
==4 8sec.

GPS interval
= 2 min

GPS interval
= 5 min

Move toward state [n] when the user stops traveling.

(a)
State maching activity - awake to asleep
300
Time between adjacent GPS fixes (s)

er while maintaining the accuracy of the tracking

application. Several possibilities exist here. For
example:
Change of direction: A fix is marked as critical
(sent to the server) if there is a considerable
change in the direction of the user between
sequential locations.
Distance-based: A fix is marked as critical
when a distance threshold is reached respect to
the last critical point.
Time-based: A fix is marked as critical when a
time threshold is reached between a last critical point and a current location.
Combinations: Direction changes, distance, and
time thresholds, accuracy of GPS fix, and other
variables can be combined to produce the
desired effect. Which options to utilize and
how to combine them is application-dependent. Figure 6 shows a path in which all GPS
fixes are sent every 4 s (left), and the same
path with a distance- and change-of-directionbased critical point algorithm that only sends
between 510 percent of the fixes to the server.

250

200

150

1
24
47
70
93
116
139
162
185
208
231
254
277
300
323
346
369
392
415
438
461
484
507
530
553
576
599
622
645
668
691
714
737
760
783
806
829
852
875
898
921
944
967
990
1013

100
One of the most important aspects of building
a global system like G-Sense is how to manage
the large amount of traffic generated by all the
50
sensing devices. This challenge has been partially addressed by the algorithms presented
0
before. However, if the system is implemented
in many places at the same time, a centralized
system would not be appropriate. In order to
(b)
make G-Sense scalable, a peer-to-peer architecture is introduced based on the locality of
Figure 5. Functionality of the state machine: a) the client state machine; b)
the data. The peer-to-peer protocol that impleinterval detection.
ments the architecture is the Geotella protocol.
Geotella interconnects individual servers and
creates a sensing overlay over the Internet in
which each of the servers becomes a place for sensor data
their indices. These data might be manipulated to provide an
aggregation, provides the functionality to distribute sensing
unreal picture of the pollution index in a country.
tasks among several places, and collects the information
from such tasks.
Security and Privacy Mechanisms to ensure security and privacy
Geotellas name comes from the fact that the peer-to-peer
are very important in all these applications. Some applications
system is a non-DHT system like Gnutella, structured over the
require protection of the real position as well as the personal inforlocation information exchanged by the servers. A non-DHTmation of the user. Achieving these goals in an energy-efficient
based approach was chosen to develop the protocol, as it is
and simple manner for mobile client devices is very challenging.
difficult to deal with range queries in DHTs, which is the case
Location-based security is also an interesting research topic.
in geography-centric queries. Geotellas peers periodically
exchange location information and sensing range, which allows
Activity Determination Algorithms to automatically determine
peers to be aware of the location and current sensing area of
the type of activity the user is doing are important for all these
the others. From a wireless sensor networks point of view,
applications as well. Accelerometer and positioning data have
Geotella is a clustering approach over the Internet to manage
been used in different studies to determine the mode of transthe sensing information gathered by the static and mobile
portation, the type of activity and position of the user (walking,
wireless sensor devices. In the protocol the overlay is mainjogging, sitting, sleeping, etc.), and others. For some applications
tained using UDP messages, but the exchange of the results of
the combination of these data plus personal data might be used to
a sensing task is done using HTTP.
make more accurate estimations. Furthermore, several of these
data could also be used to trigger sensing tasks at more appropriOpen Challenges
ate times, reducing the amount of data and saving more energy.
LBSs, PS, and HCS are fairly new areas with many still unresolved challenges. The following list provides a brief descripLearning and Feature Extraction Algorithms HCS applications
tion of the most important challenges.
can send and store lots of data about a particular user. The
data by itself is not very useful. Mechanisms need to be
devised to translate these data into information about the
Validity of the Data Mechanisms to guarantee the validity of
users, their behaviors, their preferences, and so on so that this
the data are very important. Imagine a PS application to meacontextual information can be used to enhance the service
sure the pollution index in different countries that will be used
providing effective and timely feedback.
to either charge or provide funds to the countries according to

IEEE Network July/August 2010

63

LABRADOR LAYOUT

7/8/10

12:09 PM

Page 64

Figure 6. The critical point algorithm.

AI Algorithms for Resource-Constrained Devices Most learning and feature extraction algorithms are computationally
expensive and therefore are usually run in servers. However,
some of these applications might benefit if some of these
algorithms could be run in the client device.
Data Correlation Global applications provide the capability
to collect data worldwide. Correlation and visualization mechanisms are needed to understand and see the effect that the
data from one place of the globe might produce on others.
Incentive Mechanisms Some participatory sensing applications will need some sort of incentive for users to participate.
Data Visualization Showing a variable of interest (e.g., pollution, temperature) on a map will need estimation and inference techniques to complete the map when there is a small
number or incomplete set of samples.

Summary
This article presents G-Sense, a scalable architecture in support of LBS, PS, and HCS applications made of mobile and
static sensor devices. G-Sense is a hybrid architecture that
uses a client-server architecture within a server domain and a
peer-to-peer architecture among servers to scale the system to
worldwide deployments. The article describes the hardware
and software components of the architecture, and shows the
importance of these new applications and the new wave of
massive traffic they will generate. A prototype application is
described, and several client-side mechanisms to reduce the
amount of data and address energy issues are presented.
Finally, the article lists some of the most important issues that
are still pending for research contributions.

References
[1] C. Chong and S. P. Kumar, Sensor Networks: Evolution, Opportunities, and
Challenges, Proc. IEEE, vol. 91, no. 9, 2003, pp. 124756.
[2] J. M. Kahn, R. H. Katz, and K. S. Pister, Next Century Challenges: Mobile
Networking for Smart Dust, Proc. 5th ACM/IEEE MobiCom, 1999.

64

[3] J. Yick, B. Mukherjee, and D. Ghosal, Wireless Sensor Network Survey,

Comp. Net., vol. 52, no. 12, 2008, pp. 22922330.
[4] S. Barbeau et al., A General Architecture in Support of Interactive, Multimedia, Location-Based Mobile Applications, IEEE Commun. Mag., Nov. 2006,
pp. 15663.
[5] A. Kupper, G. Treu, and C. Linnhoff-Popien, TraX: A Device-Centric Middleware Framework for Location-Based Services, IEEE Commun. Mag., Sept.
2006, pp. 11420.
[6] P. Bellavista and A. Corradi, The Handbook of Mobile Middleware, Auerbach, 2006.
[7] S. B. Eisenman et al., Metrosense Project: People-Centric Sensing at Scale,
Proc. 4th ACM SenSys, 2006.
[8] J. Burke et al., Participatory Sensing, Proc. 4th ACM SenSys, 2006.
[9] CENS Urban Sensing; http://urban.cens.ucla.edu/projects/
[10] MIT Senseable City Lab; http://senseable.mit.edu/
[11] Cambridge Mobile Urban Sensing; http://www.escience.cam.ac.uk/mobiledata/
[12] Microsoft Networked Embedded Computing Research Group;
http://research.microsoft.com/en-us/groups/nec/

Biographies
ALFREDO J. PEREZ [M] (ajperez4@cse.usf.edu) received his B.S. in systems engineering from the Universidad del Norte, Barranquilla, Colombia, in 2006, and
his M.S. in computer science from the University of South Florida in 2009,
where he is a Ph.D. candidate in the Department of Computer Science and
Engineering. His research interests are in the areas of evolutionary algorithms,
multi-objective optimization, mobile sensor networks, and location-based systems. He is co-author of the book Location-Based Information Systems , CRC
Press, 2010.
MIGUEL A. LABRADOR [SM] (labrador@cse.usf.edu) received his Ph.D. degree in
information science with concentration in telecommunications from the University
of Pittsburgh in 2000. He is currently an associate professor in the Department
of Computer Science and Engineering at the University of South Florida. His
research interests are in energy-efficient mechanisms for wireless sensor networks
and location-based services. He is lead author of the books Topology Control in
Wireless Sensor Networks, Springer, 2009, and Location-Based Information Systems, CRC Press, 2010.
SEAN J. BARBEAU [M] (barbeau@cutr.usf.edu) joined the research faculty of the
Center for Urban Transportation Research at the University of South Florida in
2004. He has over five years of experience with the development and application of intelligent mobile technology to transportation challenges involving GPSenabled mobile phones. He served in the international Expert Group that
developed the JSR293-Location API 2.0. He holds Masters and Bachelors
degrees in computer science from the University of South Florida where he is
also a part-time Ph.D. student.

IEEE Network July/August 2010