Architecture for Global Sensing

57IEEE Network • July/August 2010 0890-8044/10/$25.00 © 2010 IEEE

Alfredo J. Perez, Miguel A. Labrador, and Sean J. Barbeau, University of South Florida

AbstractThe pervasiveness of cellular phones combined with Internet connectivity, GPSembedded chips, location information, and integrated sensors provide an excellentplatform to collect data about the individual and its surrounding environment. As aresult, new applications have recently appeared to address large-scale societalproblems as well as improve the quality of life of the individual. However, thesenew applications, recently called location-based services, participatory sensing,and human-centric sensing, bring many new challenges, one of them being themanagement of the huge amount of traffic (data) they generate. This article pre-sents G-Sense, for Global-Sense, an architecture that integrates mobile and staticwireless sensor networks in support of location-based services, participatory sens-ing, and human-centric sensing applications. G-Sense includes specific mechanismsto control the amount of data generated by these applications while meeting theapplication requirements. Furthermore, it creates a network of servers organized ina peer-to-peer architecture to address scalability and reliability issues. An exampleprototype application is presented along with some basic results and openresearch issues.

G-Sense: A Scalable Architecture forGlobal Sensing and Monitoring

dvancements in computing and communicationsystems combined with the development of micro-electro-mechanical systems (MEMS) are changingthe way the physical world is understood. Wireless

sensor networks (WSNs) were born as the combination ofthese elements, allowing us to take measurements of the phys-ical environment and gather data of interest for monitoringand decision making purposes. Nonetheless, WSNs consist ofsmall computing devices with strong limitations in terms ofcomputing power, storage, mobility, communications, and,more important, energy. These limitations, plus the still highcost per device, have limited the use of WSNs to addresslarge-scale societal problems to very few cases, if any.

At the same time, two important developments haveoccurred. First, the number of cellular users has increaseddramatically over the last several years. And second, the char-acteristics of the mobile devices have improved considerably,outperforming their WSN counterparts by a substantial mar-gin. For example, mobile devices now come with Internet con-nectivity, other communication interfaces such as Wi-Fi andBluetooth, more computing power and storage than theirWSN 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 deploy-ment issues, high costs, and mobility and energy limitations ofWSNs.

These developments have recently made researchers usecellular phones as a mobile sensing platform to collect datawe could not collect before and address large-scale societalproblems. Furthermore, the same platform can also be usedto collect not only environmental data but also data pertainingto the user (health, activity, behavior, etc.), which could beused to improve the user’s quality of life. Location-based ser-

vices (LBS), participatory sensing (PS), and human-centric sens-ing (HCS) are names that have recently appeared in theresearch literature to refer to these types of applications.

PS aims to collect enough data to measure and monitor avariable of interest in a community, city, country, or evenworldwide with the participation or collaboration of many cellu-lar users. Examples of PS are applications that collect air quali-ty measurements to determine the pollution index; real-timeGPS locations to assess traffic congestion and travel times; andnoise, humidity, and temperature measurements to show real-time maps with these variables. HCS applications, on the otherhand, aim to collect data about the health of the user, or agroup of users. Both PS and HCS applications integrate specificsensors into the cellular telephone to measure the variables ofinterest. Carbon dioxide, temperature, humidity, heart rate,breath depth, and oxygen in the blood are examples of vari-ables that need specialized sensors beyond the ones normallyavailable in cellular phones. Normally, GPS position andaccelerometer data are used in many LBSs such as real-timetracking 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, theeffectiveness of medicine and treatments, and so on.

Although this new sensing platform possesses very nice fea-tures, and LBSs, PS, and HCS applications seem to be readyfor prime time, they bring new technical and nontechnicalchallenges. Imagine for a moment an application to track peo-ple in real time that sends a 40-byte packet with the GPSposition of the user to a central server every second. If 10,000users are subscribed to this service, the application automati-cally generates 1.4 Gbytes of data per hour. In an envisionedscenario with many different types of LBSs, and PS and HCSapplications all over the world, these applications may easilybecome the next wave of traffic in the Internet, after the

AA

LABRADOR LAYOUT 7/8/10 12:09 PM Page 57

IEEE Network • July/August 201058

recent wave of traffic generated by peer-to-peer applications.Understanding the nature and characteristics of this trafficand finding new ways to manage it will be essential to main-tain or improve the level of service we currently enjoy.

This article presents G-Sense, a two-tier client-server andpeer-to-peer architecture that integrates mobile and staticsensors, and supports the deployment of LBS, PS, and HCSapplications. The article explains the main components of thearchitecture and describes an example prototype applicationthat combines LBS, PS, and HCS characteristics. Four specificexample mechanisms used in this application to address trafficand scalability issues are also explained along with some basicresults. Finally, the article lists several open issues that needfurther research.

Related WorkWireless sensor networks research has its origins with theDefense Advanced Research Project Agency (DARPA) in thelate 1970s with the Distributed Sensor Networks program [1].This program was an initiative to build cooperative networksof low-cost sensing devices that could perform autonomous,yet cooperative sensing. With the advancement of MEMStechnology in the late 1990s, the technology for static WSNplatforms was developed [1, 2]. The idea was to build nodes ofsmall size (as small as 2 mm2) that could be able to sense,transmit data, and harvest their energy needs from the envi-ronment, so they could be active for years and cheap enoughto be deployed everywhere. A complete survey on the evolu-tion of this topic is provided in [3]. As of today, this vision hasnot been fully achieved, as most WSN nodes remain fairly bigand costly, which has limited the use of WSNs to rather smalland focused deployments.

Cellular technology, mobile Internet connectivity, and thewidespread utilization of cellular phones are making the envi-sioned goal of WSNs a reality. In combination with position-ing and MEMS technologies, LBS, PS, and HCS applicationsusing WSNs of cellular phones have started to emerge. LBSapplications are the most common thus far with several track-ing services being offered by independent companies as wellas cellular carriers. Many architectures and middleware havebeen proposed for LBS applications [4–6]. Not so commonare PS and HCS applications. MetroSense [7], which calls fora human-centered approach to sensing, is an architecture thatmixes static wireless sensor networks with mobile cellularphones, a federated server architecture, and already estab-lished social networks such as Facebook, MySpace, and IM toshare sensed information in a secure manner and promotesocial interaction, study life patterns, find friends, and severalothers.

Under the name of Participatory Sensing [8], researchersfrom the Center for Embedded Networked Sensing at UCLAhave developed several projects that involve community-ori-ented sensing. CENS projects focus on how communities,using sensor-enabled cellular phones, can monitor variables ofinterest and events that affect the lives of the people in thecommunity [9]. Similar projects have been developed byresearch groups at MIT [10], University of Cambridge (Cam-bridge Mobile Urban Sensing) [11], and Microsoft Research’sNetworked Embedded Computing Group [12].

Since 2005 our Location Aware Information Systems Labo-ratory at USF has been involved in the development of sever-al projects utilizing cellular phones as sensing devices for bothcommunity and personal sensing. By using GPS-enableddevices and the architecture described in [4], we have devel-oped applications like Wi-Via, a community-oriented Amberalert application that captures geotagged images and videos

and sends them to a law enforcement central location; TRAC-IT, a personal-oriented system that keeps track of people’scommute behavior and provides feedback to optimize travels,costs, and time; and TAD, a travel assistant device that helpspeople with cognitive disabilities use public transportation sys-tems.

The applications and architectures described before differfrom 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 managingthe large amount of traffic they generate. Third, they mostlyuse mobile cellular phones only. Finally, they all have a ratherlocal scope.

G-Sense: A Scalable Architecture for GlobalSensing and MonitoringG-Sense is a two-tier client-server and peer-to-peer architec-ture that supports the development of local and global LBS,PS, and HCS applications. G-Sense integrates mobile sensingdevices, static WSNs, and servers to perform data collectionfrom the environment and the individual, analyze the data atdifferent levels of the architecture, make estimations andinferences, and provide feedback and visualization capabili-ties. G-Sense is based on the high-level architecture shown inFig. 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 inter-faces available to transfer the data from the sensors to thefirst-level integrating device, which is either the mobiledevice or the base station. This pertains to the data collec-tion function.

• First-level integrator: This is the device that collects all datasent by the sensors. In the architecture it is represented byeither a cellular phone or a laptop, or the base station inthe case of a WSN. This component may perform initialdata analysis over the data collected by the sensors forimmediate feedback.

• Data transport network: The data transport network is thecombination of IP-based networking technologies thatmake possible the transfer of data from the first-level inte-grator device to the servers.

• Servers: This component stores the data collected from themobile nodes and static WSN nodes. In addition, it per-forms additional processing on the data to perform estima-tions and inferences that cannot be performed in either themobile node or the base station due to data availabilityand/or the complexity of the algorithms. This componentalso supports data visualization using Web 2.0 tools forreporting purposes.G-Sense provides a framework to implement this vision,

including a software architecture that supports all these func-tions. G-Sense is a hybrid client-server and peer-to-peer archi-tecture, where the client-server part abstracts the base stationand mobile sensing nodes as clients that connect to a server,which is a more powerful computer system in terms of pro-cessing, energy, communication, and storage capabilities. Thearchitecture shown in Fig. 1 is meant to have a rather localscope and be replicated in as many other sites as necessary.Then servers from different sites are interconnected using apeer-to-peer system, so the sensing tasks are distributed forload balancing, traffic filtering, and scalability purposes. Thispeer-to-peer system, shown in Fig. 2, is the one that allowsglobal deployment of LBS, PS, and HCS applications, andmanages the traffic in the network. The software architecturethat supports this platform is described next.


IEEE Network • July/August 2010 59

Client-Side Software ArchitectureG-Sense’s software architecture for the client is shown in Fig.3. It consists of four major components known as the SensorCommunication and OS layer, and the Location Management,Sensor Management, and Server Communication Manage-ment components. The Sensor Communication and OS layeris closest to the hardware and is common to all the othercomponents, which are more specific in terms of the functionthat they perform.

Sensor Communication and OS LayerThe Sensor Communication and OS layer abstract the commu-nication with the sensors that are connected to the mobiledevice. Currently, cellular phones and laptops come equippedwith Wi-Fi and Bluetooth interfaces that can be used to inte-grate external sensors that already come with such communica-tion capabilities. Examples of commercially available devicesthat can be used to measure body variables are Zephyr’s Bio-Harness strap, the Nonin Pulse Oxymeter, and the Alive Heartand Activity Monitor, among others. More specialized sensors,such as those measuring gases, temperature, and humidity, areusually built in special circuit boards equipped with such net-work interfaces. Other sensors, such as accelerometers andGPS chips, come already integrated in the mobile device.

Location Management ComponentThe Location Management component provides the mobilesensing application with information about the position of thedevice. As location information is important to any mobile

sensing application, the careful management of this informa-tion is required. For this reason G-Sense manages locationinformation in a special component that consists of threemodules.

Location Acquisition Module — This module obtains the posi-tion of the device. Example implementations of this moduleare the Java Location API (JSR-179 or 293) for Java ME, theAndroid’s Location API, any custom made GPS wrapper, orlocation services, such as the one provided by Skyhook, orsimilar companies. Therefore, this subcomponent abstracts thepositioning methods and devices (GPS) the mobile sensingdevice can use to obtain a location.

Location Estimation Module — The main objective of this mod-ule is to combine the location information from differentsources that the device gathers using the Location Acquisitionmodule and provide a better estimate of the unit’s position.This module could utilize technologies like dead reckoning, oruse historical data about the travel patterns of the user toobtain or improve the position of the unit.

Critical Point Management Module — The Critical Point Man-agement module makes two important decisions. First, itdecides whether it is worth spending extra energy trying toobtain the unit’s position or not. Second, once the unit’s posi-tion is obtained, it decides whether it is worth sending it tothe server or not. This is one of the most important modulesin the client’s software architecture because it is meant toreduce the amount of traffic on the network, reduce energy

Figure 1. G-Sense’s hardware architecture.

Data collection Data transport

Servers

Data analysispoint

Data storage,estimation, inference,

visualization andfeedback

Mobilesensornetwork

Personalandenvironmentalinformation

Internet

GPS

Static sensor networksenvironmental information



consumption in the client, and save storage space while satis-fying the requirements of the application.

Sensor Management ComponentThe Sensor Management component consists of the DataAcquisition module, the Feature Detection module, and theEvent Notification Manager.

Data Acquisition Module — The Data Acquisition moduleconsists of an API to control the sensors. For example, thisAPI should include functionality to query the sensors andobtain measurements, turn the sensors on or off, change thefrequency of queries, and so forth. The implementation of thismodule should return an object that represents the measure-ment along with the units utilized to obtain it. An exampleimplementation of this module is the JSR 256: Mobile SensorAPI for Java ME.

Feature Detection Module — Using the data obtained by theData Acquisition module, the Feature Detection module pro-vides the functionality to learn and detect behaviors and/orfeatures that are useful for the application and the user. Thismodule is meant to perform an initial analysis on the data andprovide immediate feedback to the user, if necessary. Datamining and/or artificial intelligence techniques are normallyused for these tasks.

Event Notification Manager — Upon the detection of featuresof interest, this module provides the functionality to notify themobile application of the feature that has been recognized.Thresholds can be set up in this module according to the

user’s needs or the application to send immediate alerts to theuser, caregiver, or whoever is designated or appropriate.

Server Communication Management ComponentThis component manages the communication with the serveras well as the security and privacy policies for the mobile sens-ing application. It consists of the Communication Manage-ment, Security and Privacy, and Session Management modules.

Communication Management Module — This module providesstandard ways to transfer data from the clients to the serverand vice versa. Standard interfaces exist to utilize HTTP,HTTPS, TCP, and UDP, which are chosen according to theapplication requirements. For example, continuous real-timedata (e.g., GPS fixes every second in a tracking application)are sent using UDP. On the other hand, if reliability isrequired, (e.g., a medical application, transfer of logged sens-ing data, and session maintenance), TCP or HTTP(S) is used.

Security and Privacy Module — Security and privacy are keyaspects in any LBS, PS, or HCS system. This module includesthe interfaces and mechanisms needed to provide security andguarantee privacy. Encryption algorithms, user identity random-ization mechanisms, and security policies and their enforcingmechanisms are some examples of the mechanisms included inthis module. These mechanisms are application-dependent andshould be set by the user or system administrator.

Session Management Module — This module consists of themethods needed to exchange session data with the server. Ses-sion data consists of users’ data, devices, session ids, and simi-

Figure 2. G-Sense’s peer-to-peer architecture.

G

Datacollection

Datatransport

Miami

Servers

G

Dataanalysispoint

Data storage,estimation,inference,

visualizationand feedback

Mobilesensornetwork


Internet

GPS


Datacollection

Datatransport

Berlin

Servers

Dataanalysispoint



Mobilesensornetwork


Internet

GPS


Datacollection

Datatransport

Washington

Servers

G

Dataanalysispoint



Mobilesensornetwork


Internet

GPS


Data collection

Data transport

Baghdad

Servers

Data analysis point

Data storage, estimation, inference,

visualization and feedback

Mobile sensor network

Personal and environmental information

Internet

GPS

Static sensor networks environmental information

G



lar data plus individual session information such as the num-ber of packets sent and the session key.

Server-Side Software ArchitectureG-Sense’s server-side software architecture is shown in Fig.4. From the bottom up, the architecture starts with theOperating System and Application Server components. Theapplication server is a runtime environment for server appli-cations. Examples of these are the Java Platform EnterpriseEdition (J2EE) application server, Microsoft’s InternetInformation Services (IIS), and the Apache HTTP Server.At the same level are the spatial and relational databasesneeded to store all the data. The following layer consists ofthree components that manage the communication of theserver with mobile and static sensors and other servers.These are the Mobile WSN Management component, theStatic WSN Management component, and the Server Sens-ing Management component. The following four compo-nents are the Data Collection and Analysis components, theData Visualization Component, and the Sensing Application.All these components are described next.

Mobile WSN Management ComponentThe Mobile WSN Management component manages connec-tivity with the mobile sensing devices. The functionality of thiscomponent matches those included in the Server Communica-tion Management component in the client-side software archi-tecture. In addition, it includes the Task Management module,which executes policies over the received data from themobile devices to decide whether to store the data in thedatabase, invoke a data analysis algorithm, or notify otherdevices in the system.

Static WSN Management ComponentThe Static WSN Management component integrates staticWSNs in the G-Sense architecture. It consists of the Commu-nication Management, WSN Network Services, and TaskManagement modules. The Communication Managementmodule provides the basic transport and session managementfunctionality to connect and transfer data to and from thebase station of the WSN. The WSN Network Services moduleincludes algorithms that cannot be run in the base stationbecause of the lack of data and/or processing capacity. Exam-ples of algorithms that could run as services for a WSN aretopology control and topology maintenance algorithms. Thelast module is Task Management, which also executes policiesand makes decisions based on the received data.

Server Sensing Management Component

This component interconnects a sensing-aware applicationwith other sensing applications in other servers. With thisfunctionality, a sensing task can be distributed among severalservers, which reduces and balances the load in a server andprovides service reliability for sensing in hostile environmentssuch as a war zone. This component consists of the Task Man-agement module, which provides similar functionality as theone in the mobile WSN, and the Communication Manage-ment module that provides connectivity among servers.

The Communication Management module is responsiblefor the establishment and maintenance of the peer-to-peerarchitecture. By interconnecting servers in a peer-to-peerfashion, a sensing cloud is created, allowing servers to shareinformation. Our current implementation of this subcompo-nent is based on a protocol called Geotella. Geotella main-tains an overlay of geographic-aware servers, updating thepeers’ locations as well as the current sensing area assigned toeach server. Using a non-distributed hash table (DHT)approach to manage the location, Geotella assigns and dis-tributes sensing tasks geographically.

Data Collection and Analysis ComponentsThese two server components use the data coming from staticand mobile sensors, other servers, and historical data stored inthe database to perform inference, correlation, and data analy-sis tasks. Contrary to the data analysis tasks performed at theclient device, which are based only on local and individual data,these components have a complete picture of the situation andtherefore are able to make deeper and global analyses.

Data Visualization ComponentThe final component of the architecture is the data visualiza-tion component. This is implemented in the architecture usingWeb 2.0 tools such as the Google Web Toolkit and opensource mapping applications, which along with geographicmarkup languages such as KML show the data in geographicbrowsers (e.g., Google Earth, NASA Worldwind).

A Prototype Application Combining LBS, PS,and HCSG-Sense has been prototyped in a military application thatcombines LBS, PS, and HCS, integrates static and mobilesensing clients, and implements the peer-to-peer architecturefor data traffic management, reliability, and scalability purpos-

Figure 3. G-Sense’s client-side software architecture.

Location management

Clinical point management

Location estimation

Location acquisition

Sensor management

Event notification manager

Feature detection

Data acquisition

Server communication management

Session management

Sensor communication management

Operating system

Sensor communication and OS layer

Security and privacy management

Communication management

Mobile sensing application



es. The application supports military deployments by provid-ing the following main services:• Real-time tracking of soldiers (LBS part).• Real-time health status of each soldier with body tempera-

ture, pulse rate, breathing depth, and EKG information, ifnecessary (HCS part). These sensors are automatically acti-vated by the application either periodically or when neces-sary based on locally sensed data, type of activity, and othervariables.

• Sensing of environmental gases and variables of interestsuch as temperature, humidity, CO2, and poisonous gases(PS part).

• Integration of static WSNs with intrusion detection capabili-ties. Upon intrusion detection, the system automaticallygenerates Geo-Alerts to those soldiers close enough to theevent and to the main control station.

• Real-time feedback based on locally sensed data. This anal-ysis 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 histori-cal data from the database. Feedback to individual orgroups of users is also provided using the Geo-Alert capa-bility.

• Data visualization allows authorized users at each serverlocation to see the users and the variables of interest in realtime.The services described above are services per deployment

site. Since there are many deployments worldwide at the sametime, global information is needed to coordinate military tasksappropriately. The peer-to-peer architecture and the Geotellaprotocol provide this functionality. If one deployment consistsof the architecture shown in Fig. 1, the peer-to-peer architec-ture provides a distributed system-of-systems view that inte-grates as many individual deployments as necessary, as shownin Fig. 2. Please notice that this same distributed architecturecould be used for many other PS applications. If each individ-ual system collected CO2 data from a PS application in a city,the distributed system would be able to show a country pollu-tion map.

The following sections describe some of the algorithms thatcan be implemented to reduce the amount of traffic (redun-

dant or unnecessary data), and therefore save energy in theclient device and network bandwidth, and the Geotella proto-col. Then a list of open research issues is included.

Reducing Data Traffic and Saving EnergyReducing the amount of unnecessary traffic and the energyconsumption in the mobile device are critical aspects in LBS,PS, and HCS applications. Since one of the most expensivefunctions in resource-constrained devices is communications,reducing the amount of unnecessary or redundant data hasthe double effect of saving bandwidth, particularly importantin bandwidth scarce networks such as public cellular networksand wireless mobile ad hoc military networks, and savingenergy. Four client-side mechanisms meant to achieve thesegoals are the following.

The Client State Machine — The client state machine auto-matically determines the rate at which GPS position fixes arequeried according to the location of the user, the GPS signalstrength, and other GPS information. Even though the appli-cation may need to send new GPS fixes to the server, it makesno sense to continue querying the GPS system if the user isindoors with no GPS coverage, or in the same position (notmoving) for a long time. Figure 5a shows an example of astate machine, and Fig. 5b shows that the state machine accu-rately achieves its goals, making the mobile device active orinactive at appropriate times.

Geo-Sensing — This is a feature that activates or deactivatesthe sensing functionality of the mobile device according to itscurrent location. In a community-oriented PS applicationmeant to assess the pollution index in a particular zone of acity, it does not make sense to have the sensor activated andsending data from a location outside the specific zone.

Time-Sensing — Similar to geo-sensing but based on time. Thesensors are activated only during specific time slots, peakhours, or shifts, and the like.

The Critical Point Algorithm — The critical point algorithm,which is also implemented in the Critical Point Managementmodule, decides whether or not to send a GPS fix to the serv-

Figure 4. G-Sense’s server-side software architecture.

Mobile WSN management

Task management

Session management


Static WSN management

Task management

WSN network services


Server sensing management

Task management

Communicationmanagement

Sensing aware application

Data visualization

Application server

Operating system

Data analysis

Data collection

Spatialand

relationaldatabase



er while maintaining the accuracy of the trackingapplication. Several possibilities exist here. Forexample:• Change of direction: A fix is marked as critical

(sent to the server) if there is a considerablechange in the direction of the user betweensequential locations.

• Distance-based: A fix is marked as criticalwhen a distance threshold is reached respect tothe last critical point.

• Time-based: A fix is marked as critical when atime threshold is reached between a last criti-cal point and a current location.

• Combinations: Direction changes, distance, andtime thresholds, accuracy of GPS fix, and othervariables can be combined to produce thedesired effect. Which options to utilize andhow to combine them is application-depen-dent. Figure 6 shows a path in which all GPSfixes are sent every 4 s (left), and the samepath with a distance- and change-of-direction-based critical point algorithm that only sendsbetween 5–10 percent of the fixes to the server.

Making the System ScalableOne of the most important aspects of buildinga global system like G-Sense is how to managethe large amount of traffic generated by all thesensing devices. This challenge has been par-tially addressed by the algorithms presentedbefore. However, if the system is implementedin many places at the same time, a centralizedsystem would not be appropriate. In order tomake G-Sense scalable, a peer-to-peer archi-tecture is introduced based on the locality ofthe data. The peer-to-peer protocol that imple-ments the architecture is the Geotella protocol.Geotella interconnects individual servers andcreates a sensing overlay over the Internet inwhich each of the servers becomes a place for sensor dataaggregation, provides the functionality to distribute sensingtasks among several places, and collects the informationfrom such tasks.

Geotella’s name comes from the fact that the peer-to-peersystem is a non-DHT system like Gnutella, structured over thelocation information exchanged by the servers. A non-DHT-based approach was chosen to develop the protocol, as it isdifficult to deal with range queries in DHTs, which is the casein geography-centric queries. Geotella’s peers periodicallyexchange location information and sensing range, which allowspeers to be aware of the location and current sensing area ofthe others. From a wireless sensor network’s point of view,Geotella is a clustering approach over the Internet to managethe sensing information gathered by the static and mobilewireless sensor devices. In the protocol the overlay is main-tained using UDP messages, but the exchange of the results ofa sensing task is done using HTTP.

Open ChallengesLBSs, PS, and HCS are fairly new areas with many still unre-solved challenges. The following list provides a brief descrip-tion of the most important challenges.

Validity of the Data — Mechanisms to guarantee the validity ofthe data are very important. Imagine a PS application to mea-sure the pollution index in different countries that will be usedto either charge or provide funds to the countries according to

their indices. These data might be manipulated to provide anunreal picture of the pollution index in a country.

Security and Privacy — Mechanisms to ensure security and privacyare very important in all these applications. Some applicationsrequire protection of the real position as well as the personal infor-mation of the user. Achieving these goals in an energy-efficientand simple manner for mobile client devices is very challenging.Location-based security is also an interesting research topic.

Activity Determination — Algorithms to automatically determinethe type of activity the user is doing are important for all theseapplications as well. Accelerometer and positioning data havebeen used in different studies to determine the mode of trans-portation, the type of activity and position of the user (walking,jogging, sitting, sleeping, etc.), and others. For some applicationsthe combination of these data plus personal data might be used tomake more accurate estimations. Furthermore, several of thesedata could also be used to trigger sensing tasks at more appropri-ate times, reducing the amount of data and saving more energy.

Learning and Feature Extraction Algorithms — HCS applicationscan send and store lots of data about a particular user. Thedata by itself is not very useful. Mechanisms need to bedevised to translate these data into information about theusers, their behaviors, their preferences, and so on so that thiscontextual information can be used to enhance the serviceproviding effective and timely feedback.

Figure 5. Functionality of the state machine: a) the client state machine; b)interval detection.

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

(a)

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

State0

GPS interval= 4 s

GPS interval= 4 sec.

State1

GPS interval= 8 s

Staten-1

GPS interval= 2 min

Staten

GPS interval= 5 min

(b)

State maching activity - “awake” to “asleep”

47

50

0

Tim

e be

twee

n ad

jace

nt G

PS f

ixes

(s)

100

150

200

250

300

24 1 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



AI Algorithms for Resource-Constrained Devices — Most learn-ing and feature extraction algorithms are computationallyexpensive and therefore are usually run in servers. However,some of these applications might benefit if some of thesealgorithms could be run in the client device.

Data Correlation — Global applications provide the capabilityto collect data worldwide. Correlation and visualization mech-anisms are needed to understand and see the effect that thedata from one place of the globe might produce on others.

Incentive Mechanisms — Some participatory sensing applica-tions will need some sort of incentive for users to participate.

Data Visualization — Showing a variable of interest (e.g., pol-lution, temperature) on a map will need estimation and infer-ence techniques to complete the map when there is a smallnumber or incomplete set of samples.

SummaryThis article presents G-Sense, a scalable architecture in sup-port of LBS, PS, and HCS applications made of mobile andstatic sensor devices. G-Sense is a hybrid architecture thatuses a client-server architecture within a server domain and apeer-to-peer architecture among servers to scale the system toworldwide deployments. The article describes the hardwareand software components of the architecture, and shows theimportance of these new applications and the new wave ofmassive traffic they will generate. A prototype application isdescribed, and several client-side mechanisms to reduce theamount of data and address energy issues are presented.Finally, the article lists some of the most important issues thatare 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. 1247–56.[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.

[3] J. Yick, B. Mukherjee, and D. Ghosal, “Wireless Sensor Network Survey,”Comp. Net., vol. 52, no. 12, 2008, pp. 2292–2330.

[4] S. Barbeau et al., “A General Architecture in Support of Interactive, Multime-dia, Location-Based Mobile Applications,” IEEE Commun. Mag., Nov. 2006,pp. 156–63.

[5] A. Kupper, G. Treu, and C. Linnhoff-Popien, “TraX: A Device-Centric Middle-ware Framework for Location-Based Services,” IEEE Commun. Mag., Sept.2006, pp. 114–20.

[6] P. Bellavista and A. Corradi, The Handbook of Mobile Middleware, Auer-bach, 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/mobile-

data/[12] Microsoft Networked Embedded Computing Research Group;

http://research.microsoft.com/en-us/groups/nec/

BiographiesALFREDO J. PEREZ [M] ([email protected]) received his B.S. in systems engi-neering from the Universidad del Norte, Barranquilla, Colombia, in 2006, andhis 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 andEngineering. His research interests are in the areas of evolutionary algorithms,multi-objective optimization, mobile sensor networks, and location-based sys-tems. He is co-author of the book Location-Based Information Systems, CRCPress, 2010.

MIGUEL A. LABRADOR [SM] ([email protected]) received his Ph.D. degree ininformation science with concentration in telecommunications from the Universityof Pittsburgh in 2000. He is currently an associate professor in the Departmentof Computer Science and Engineering at the University of South Florida. Hisresearch interests are in energy-efficient mechanisms for wireless sensor networksand location-based services. He is lead author of the books Topology Control inWireless Sensor Networks, Springer, 2009, and Location-Based Information Sys-tems, CRC Press, 2010.

SEAN J. BARBEAU [M] ([email protected]) joined the research faculty of theCenter for Urban Transportation Research at the University of South Florida in2004. He has over five years of experience with the development and applica-tion of intelligent mobile technology to transportation challenges involving GPS-enabled mobile phones. He served in the international Expert Group thatdeveloped the JSR293-Location API 2.0. He holds Master’s and Bachelor’sdegrees in computer science from the University of South Florida where he isalso a part-time Ph.D. student.

Figure 6. The critical point algorithm.


Documents

Architecture for Global Sensing