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.
A
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 user’s 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 [4–6]. 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 Research’s 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 people’s 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-Sense’s hardware architecture.
Client-Side Software Architecture G-Sense’s 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 Zephyr’s 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 Android’s 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 unit’s 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 unit’s position or not. Second, once the unit’s 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 client’s 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
G
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
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-Sense’s peer-to-peer architecture.
consumption in the client, and save storage space while satisfying the requirements of the application.
user’s 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-Sense’s 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-Sense’s 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, Microsoft’s 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-Sense’s 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 5–10 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 Geotella’s 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. Geotella’s 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 network’s 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. 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.
64
[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, Multimedia, 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 Middleware Framework for Location-Based Services,” IEEE Commun. Mag., Sept. 2006, pp. 114–20. [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] (
[email protected]) 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] (
[email protected]) 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] (
[email protected]) 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 Master’s and Bachelor’s 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
