Peer-produced systems can achieve what mightbe infeasible for stand-alone systems developed

by a single entity. Take Wikipedia, for example.Each contributor to the site provides a small pieceof information. Coordinated effectively, the sum ofthe compositions yields something of far greatervalue than all the compositions individually.

This kind of approach is at work in systemsproduced by labs and businesses such as SETI@home, YouTube, and Linux. In the area of sensornetworks, SenseWeb (http://research.microsoft.com/nec/senseweb/) enables peer production ofsensing applications, producing new kinds ofmedia and applications over existing data net-works. Contributors deploy their own sensors orsensors network. This might be designed for theirown dedicated application, as in a security surveil-lance camera network, parking occupancy counter,weather monitoring home system, or heart ratemonitor for runners. However, if these sensors areplaced into and shared in a single developmentsystem, many more applications can be built.

When people share weather sensors from theirhomes on the Weather Underground forecastingWeb site (http://www.wunderground.com/), forinstance, it results in large-scale weather forecasts(for more information about this site, see also theIEEE Computer Graphics and Applications article athttp://doi.ieeecomputersociety.org/10.1109/MCG.2007.124). Information from hikers’ GPS-enabled body-worn sensors shared on Motion-Based (http://www.motionbased.com/) andSlamXR (http://www.msslam.com/slamxr/slamxr.

htm) helps others choose appropriate travel routesfor their fitness and endurance levels. Essentially,in these system, the system sensor owners uploadtheir data which is then made available throughan application-specific GUI. While these exam-ples reveal some of the many benefits that sharedsensing offers, that’s just the beginning.

Imagine, however, the potential if you couldbuild new applications that leverage data fromsensors already available in the deployed systems.For instance, if a retailer with several outlets atshopping malls across a nation could access videostreams from security cameras at those malls, theretailer could build custom business applicationsfor understanding customer behavior (such as thevideo analysis business tools from IBM’s SmartSurveillance System1).

Imagine, then, if you could configure data col-lection for the specific needs of a new sensingapplication. Say, for example, a rainstorm hits anda cab dispatch back-end automatically requestsfrom commuters with cell-phone cameras imagesof flooded road segments. Geology research labscould deploy soil sensors near their local universi-ty, and other researchers could task those sensorsto collect data for new experiments.

SenseWeb’s goal is to enable these kinds ofcapabilities. Using SenseWeb, applications can ini-tiate and access sensor data streams from sharedsensors across the entire Internet. The SenseWebinfrastructure helps ensure optimal sensor selec-tion for each application and efficient sharing ofsensor streams among multiple applications.

System architectureWe designed the SenseWeb architecture to let

multiple concurrent applications share sensingresources contributed by several entities in a flex-ible but uniform manner (see Figure 1). The archi-tecture’s key components are the coordinator;sensors, sensor gateways, and mobile proxy; datatransformers; and applications.

8 1070-986X/07/$25.00 © 2007 IEEE Published by the IEEE Computer Society

Media Impact William I. GroskyUtz Westermann

Aman Kansal,Suman Nath,

Jie Liu, and Feng Zhao

Microsoft Research

SenseWeb: An Infrastructure for Shared Sensing

Web 2.0 is an emerging paradigm for applications and user interactions.In this article, Aman Kansal, Suman Nath, Jie Liu, and Feng Zhao fromMicrosoft Research discuss the development of SenseWeb, a peer-producedsensor network environment, used for everyday life decisions.

—William I. Grosky and Utz Westermann

Editor’s Note

CoordinatorThe coordinator is the central point of access

into the system for all applications and sensorcontributors. The functions of the coordinatorare internally divided between two components:the tasking module and senseDB (streaming sen-sor database).

The tasking module accepts applications’ sens-ing requirements and tries to satisfy these fromavailable sensing resources. To do this, it takesinto account the capabilities, sharing willingness,and other characteristics of the available sensors.

The senseDB leverages the overlap amongmultiple application needs. When multiple appli-cations need data from overlapping space–timewindows, senseDB attempts to minimize the loadon the sensors or the respective sensor gatewaysby combining the requests for common data andusing a cache for recently accessed data. Forinstance, if data collected in response to an appli-cation’s query is cached, other queries with par-tially overlapping needs might be served partlyfrom the cache, and the number of sensorsaccessed might be reduced. Data extracted fromthe cache and sensors is streamed to appropriateapplications with requested aggregation. SenseDBis also responsible for indexing the sensor char-acteristics and other shared resources in the sys-tem to enable applications to discover what isavailable for their use.

Sensors, sensor gateways, and mobile proxySensing resources form the foundation of the

entire system. Sensors can measure various phys-ical variables and might be static or mobile, andcarried by humans, on vehicles, or in robots.

Because contributors may build sensors usingmany different platforms that vary in processingpower, energy, and bandwidth capabilities, thesensors might have different interfaces to accessthem. Low-powered wireless sensor nodes canuse ZigBee radios to communicate while higherpower and higher bandwidth sensors might needFireWire or similar interfaces. The sensors mightor might not be connected at all times.

To hide much of this complexity, sensors areconnected to a sensor gateway that provides auniform interface to all components above it.The gateway implements sensor-specific methodsto communicate with the sensor. However, othercomponents of SenseWeb access the gateway toobtain sensor data streams, submit data collec-tion demands, or access sensor characteristicsthrough a standardized Web service API.

Each sensor contributor might maintain hisor her own gateway. The gateway might alsoimplement sharing policies defined by the con-tributor. For instance, the gateway might main-tain all raw data in its local database—possiblyfor local applications the sensor owner runs —but only make certain nonprivacy-sensitive partsof the data or data at lower sampling rates avail-able to the rest of SenseWeb.

We implemented a shared gateway in theSenseWeb prototype that could be used by sen-sor contributors who don’t want to maintaintheir own gateway. This shared gateway, calledDataHub, supports communications with sensorsthrough a Web service API; drivers for commontypes of sensors, including wireless motes and net-work cameras, are provided to sensor contributors.

A mobile proxy is a special gateway built formobile sensors. The mobile sensors form a high-ly volatile swarm of sensing devices that canpotentially provide coverage where no staticdevices are available. However, given an applica-tion’s region and time window of sensing inter-est, it’s difficult for applications to track whichmobile devices were or will be present in thatrequired space–time window and which, if any,will be able or willing to provide samples.

The mobile proxy makes the mobility of sens-ing devices transparent to the applications. Itprovides location-based access to sensor readings.Applications simply express their sensing needsand the mobile proxy returns data from anydevices that can satisfy those needs. Kansal and

9

Octo

ber–D

ecemb

er 2007

Figure 1. SenseWeb’s

open system

architecture for flexible

sharing. WS = Web

service.

App 1

Transformer 1Transformer 2

archiveTransformer 2

iconizer

SenseDB

Sense gateway Mobile proxy

Tasking module

WS-API

WS-API

DataHub WS-API DataHub WS-API

WS-API

Coordinator

App n

10

IEEE

Mul

tiM

edia

Media Impact

Zhao discussed the specialized methods to helpdesign the mobile proxy.2

Data transformersA transformer converts data semantics through

processing. For example, a transformer mightextract the people count from a video stream.Data transformers can also convert units, fusedata, and provide data visualization services.Moreover, application developers can extendSenseWeb’s processing functionality by writingnew transformers on top of the coordinator’sprimitive access methods. Domain experts mightuse various transformers for different sensor datausing suitable domain-specific algorithms.

Transformers are indexed at the coordinatorand applications might discover and use them asneeded. Transformers provide an interface simi-lar to that of a sensor gateway, but serve processeddata. One example of a transformer is the iconiz-er implemented in our prototype: It converts rawsensor readings into an icon that represents sen-sor type in its shape and sensor value in its color.Graphical applications might use output of thistransformer instead of raw sensor values.

ApplicationsApplications are all users of sensor data. These

might be interactive applications where humanusers specify their data needs manually (such asuser queries for average hiker heart rate over thelast season on a particular trail). Or they might beautomated applications in back-end enterprise sys-tems that access sensor streams for business pro-cessing—such as an inventory managementapplication that accesses shopper volume fromparking counters or customer behaviors from videostreams—and correlates them with sales records.

SensorMap is an example of an interactiveapplication (see Figure 2) that demonstratesaccess to several sensor data types through a geo-centric interface deployed as part of our prototype(http://atom.research.microsoft.com/sensormap/).SensorMap is a mash-up application that com-bines sensor streams obtained using SenseWebwith maps from Virtual Earth (http://msdn2.microsoft.com/en-us/virtualearth/default.aspx).SensorMap lets sensor contributors add theirsensors to it through a standardized Web serviceinterface. This lets application developers useSensorMap in visualizing their own sensordeployment.

As another example, in a prototype deploy-ment, we installed sensors at a small number ofhomes near our lab. A graphical applicationqueried these sensors for their temperature read-ings and produced the temperature contour mapshown in Figure 3.

Other SenseWeb applicationsSeveral other applications are being prototyped

using the SenseWeb infrastructure. Researchers atVanderbilt University are building a fine-grainedpollution monitoring application using car-mounted devices that will enable visualizing real-time and historic pollution distribution within acity (http://www.isis.vanderbilt.edu/maqumon).

A team at The Ohio State University is devel-oping applications to provide human location,network health, and home plant soil moisturedata through SenseWeb (http://69.211.157.230/kansei/).

A collaborative effort at National Tsing HuaUniversity and Feng Chia University is usingSenseWeb to deploy a debris flow monitoringand warning application (http://www.ccrc.nthu.edu.tw/projects/debrisflow/debrisflow.html).

A national scale weather study system deployedby a team at the Nanyang Technological Universi-ty is using SenseWeb to manage its sensor streamsand visualizations at multiple user sites (http://nwsp.ntu.edu.sg/sensormap/).

Researchers at the University of Virginia areprototyping a system that would use SenseWeb toshare data from urban shopping areas and assistedliving facilities. SenseWeb has also been used to

❚ provide RFID-tag-based data for inferringindoor events at the University of Washington,

❚ study the Great Barrier Reef at the Universityof Melbourne,

Figure 2. The

SensorMap application

user interface.

❚ develop city-scale sensing infrastructures atHarvard, and

❚ collect biological and physiological data at theUniversity of Illinois.

SenseWeb architecture enables not only sharedheterogeneous sensors, but provides for the reuseof several resources required for sensor networkdeployment. Developers can reuse deployed sen-sors, spatiotemporal indexing and caching, datacollection methods, and relevant transformersalready present in the system so that they canfocus their efforts on their specific applications.They might extend the system to meet new needsand in turn share results from their developmentefforts as additional transformers.

SenseWeb helps coordinate the multiple enti-ties involved and optimizes the operationthrough effective reuse of data collection andprocessing tasks as well as the selection of appro-priate sensors for various tasks. It simplifies thecollection of complex data from heterogeneoussensors, provides abstractions that hide unreli-able device connectivity and mobility of sensorsfrom applications, and standardizes access to het-erogeneous platforms.

ChallengesThe peer production paradigm has several

advantages. It enables large spatiotemporal cov-erage—not easy to achieve with a dedicated sys-tem because of cost or jurisdiction issues.Resources can be shared opportunistically or ondemand; hence the costs can be amortized overa large number of applications. Further, a sharedinfrastructure enables a community effect, whichmakes the development of new sensing applica-tions feasible. For instance, an individual with amobile phone camera can take pictures of dam-aged sidewalks that might not yield significantdata over an interesting space and time window.Now, if multiple mobile phone owners sharetheir data, the aggregation might become signif-icant enough to plan running routes and torepair facilities. However, when the resources areshared across multiple concurrent applications,several new challenges arise.

HeterogeneityUnlike the sensors comprising an application-

specific system, components of a shared sensornetwork might be highly heterogeneous alongseveral dimensions: how data are produced, con-

sumed, and understood. The production dimen-sion has several types of heterogeneities, includ-ing types of sensors (such as wireless embeddeddevices, mobile phones, network cameras, pollu-tion sensors, and even RSS feeds); their connec-tivity to the Internet (constant, intermittent, oraffected by a firewall); their sharing willingnessor privacy sensitivity; and the resource capabili-ties for processing data locally. Further, some sen-sors might need human assistance in collectingsamples, such as a phone camera, and that adds anew set of issues to the design.

Consumers of the data are heterogeneous interms of their data needs: some might need onlya current snapshot while others might needstreams extending over the past archived dataand even future data. Their needs in terms ofdata quality, spatial resolution, and samplingrates vary. Further, different applications mightneed disparate processing or filtering of data. Theunderstanding of the data depends on a widevariety of semantic information about it.

From an infrastructure perspective, the type ofdata might range among scalar, vector, image,video, or other complex structures that havevarying storage, latency, and bandwidth needs.How the data might be indexed also depends onthe type of data. For instance, while scalar datamight be indexed by value, multimedia dataneeds more sophisticated indexing methods.From an application’s perspective, the interpre-tation of data in terms of what it measuresbecomes crucial since even data with a commonunit—say, temperature—sensors might not bemeasuring the same metric (for example, onesensor might be measuring the ambient temper-

11

Octo

ber–D

ecemb

er 2007

Figure 3. Temperature

data retrieved by an

application using

sensors contributed on

SenseWeb. The black

dots show the sensor

locations.

ature and another might be measuring pointtemperature).

SenseWeb tries to address problems because ofheterogeneity in various ways. The differences innetwork connectivity are hidden from applicationsusing standardized Web service interfaces for sen-sor gateways. Efficient communication techniquessuited to the power and bandwidth constraints ofthe sensor devices can be implemented at the gate-ways. SenseWeb addresses the heterogeneity insensor quality and willingness to share by provid-ing additional metadata in sensor descriptions andlearning sensor characteristics at runtime. Con-tributors can specify sensor precision, the maxi-mum sampling rate they are willing to contribute,and the specific applications or groups of userswith whom they are willing to share resources.

Applications can also specify their qualityrequirements and corresponding tolerances. Thecoordinator learns sensor characteristics such asconnectivity disruptions and network bandwidthat runtime. It then uses both specified character-istics in combination with the learned propertiesto optimize the selection of sensors serving dif-ferent applications.

ScalabilityA shared system becomes more useful as the

participant number grows, creating the commu-nity effect. This introduces significant challengesfor scalability. As the number of applicationsgrows, the demand for resources increases.Requiring all the contributing sensors to sharetheir raw data streams is not scalable in a largesystem. In stand-alone systems, developers mightimprove scalability by reducing the amount ofraw data transmitted from sensors through appli-cation-specific event detection or compression atthe sensors. Doing the same in a shared systemwith multiple applications is challenging. Also,more than one application might use data fromthe same sensors in a shared system. To keep theresource usage scalable and to avoid unnecessar-ily denying access to more applications, it’sessential for the system to reuse common dataand sensing resources among overlapping appli-cation needs. The scalability challenges are fur-ther compounded by the need for maintainingextensibility to unknown applications, new typesof sensors, and domain-specific data processing,aggregation, and visualization.

SenseWeb addresses scalability in two ways.First, data collection from sensors is minimizedwhenever possible by reusing the common data

accessed by multiple applications and by com-puting approximate answers on a carefully cho-sen subset of sensors, instead of on all the sensors,within the query region.

Second, all sensors are not required to shareall their available data. Data is collected inresponse to application needs only. Sensors aredynamically tasked to carry out sensing or eventdetection tasks according to the query workload.This not only avoids the need for all sensors tostream their raw data at the highest samplingrates, but also lets actuated sensors, such as pan-tilt-zoom cameras, sense in their most relevantpose or configuration. Another advantage of thisapproach is that in cases when only a limitedamount of data can be obtained from a sensor—for example, because of bandwidth, battery, orincentive budget—the most relevant data can beobtained, rather than an arbitrary set of samples.

Incentives and cost sharingSensing resources’ contributors must usually

realize some benefit for the shared system tofunction. The benefit, however, need not bemonetary. In many cases, there is an inherentincentive for the user to take samples and sharethem within a larger user group, such as in theearlier examples of a runner mapping brokensidewalks for her health enthusiasts’ e-group, forcar drivers in vulnerable river valleys to reportflooded roads, and for homeowners to map noiselevels in their community.

In other instances, the application users whoneed the sensor data can provide incentives. Forexample, a surfer who lives some distance fromthe beach might place a request for currentimages showing wave conditions at the beach ina region of his interest (by using a map-basedinterface, for example) and offer a small mone-tary compensation in return. News networksmight use similar techniques to get instant newscoverage even before their correspondent reach-es the scene. In other instances, the contributormight advertise usage rates much like rental ratesfor other equipment usage. For example, a shop-ping mall might charge a retailers’ headquartersif the retailer accesses mall-surveillance videodata for their back-end enterprise applications ona pay-per-use or monthly basis.

Security, privacy, and trustOther practical considerations in enabling

widespread adoption of a shared system arise inensuring security of shared resources against mis-

12

IEEE

Mul

tiM

edia

Media Impact

use, protecting the privacy of users who are beingsensed or sharing parts of their data, and provid-ing estimates of reliability or verifiability ofsensed data against malicious intervention orinadvertent errors.

Many applications are based on sensor datathat users might share without significant priva-cy concerns. However, where privacy or dataownership is a concern, the data might be sharedwithin restricted groups only; while the trustedcoordination system might archive and index alldata, applications might only be able to accessrestricted portions of it. Such an approach hasbeen used in existing image-sharing systems thatarchive all images but let users access only datato which they are authorized.

For highly sensitive data, the contributorscould locally compute summaries and share onlythat data. For instance, for image or video, scale-invariant key features that do not reveal thehuman-understandable visual content might beshared. The coordinator could use the features tobuild multimedia data indices. When an appli-cation requests the actual data, the data ownersserve the data, according to their desired controland access policies. Sensor contributors can usesophisticated data-hiding methods to revealaggregate results without revealing individualsensor values. Further, they can share data tovarying spatial resolution and sampling ratesamong different application groups.

Trustworthiness of data is always a concern inshared systems. Systems where independent userspublish information have their share of incorrector offensive content. To some extent such prob-lems are solved through community feedback,such as ratings associated with different contrib-utors assigned by their users. Additional methodscan be used to verify sensor data when correlationmodels in sensor values corresponding to a com-mon phenomenon are known or can be learned.

Building a sensing infrastructure out of sharedresources deployed and controlled by a largenumber of independent contributors rather thanby a single governmental or commercial infra-structure agency has security and trust challenges.But the former is more immune to the visions of a“Big Brother” world, and that encourages us toovercome the challenges in the shared systemrather than falling back on a centralized one.

Participate!The increasing availability of digitized data

enabled by information technology advances

and the Internet has shown tremendous benefitsfor personal lives and efficiency of businessprocesses in recent decades. We believe that easyaccess to measurements of physical variables thatcharacterize various aspects of our social and eco-nomic life will help realize the full potential ofthis trend. While many types of sensors are nowavailable and even deployed, applications still donot have seamless on-demand access to the rele-vant sensor streams. SenseWeb can provide thetools and infrastructure to enable such access byleveraging peer-produced sensing resources fordata collection and sharing.

Several open sensor sharing interfaces havealready been deployed in our research prototypeand we encourage sharing sensor data, be it fromembedded wireless sensors, network cameras, orcell phones. MM

References1. L. Brown et al., “IBM Smart Surveillance System

(S3): An Open and Extensible Architecture for

Smart Video Surveillance,” white paper, IBM, Aug.

2005; http://research.microsoft.com/iccv2005/

demo/IBM_S3/IBMS3_ICCV05Demo.PDF.

2. A. Kansal and F. Zhao, “Location and Mobility in a

Sensor Network of Mobile Phones,” Proc. ACM

SIGMM 17th Int’l Workshop on Network and Operat-

ing Systems Support for Digital Audio & Video (NOSS-

DAV), ACM Press, 2007; http://www.nossdav.org/

2007/files/file-31-session6-paper1-kansal.pdf.

Readers may contact the authors at kansal@microsoft.

com.

Contact Media Impact editor William I. Grosky at

wgrosky@umich.edu and editor Utz Westermann at

westermann@gmx.tm.

13

Get accessto individual IEEE Computer Society documents online.

More than 100,000 articles and conference papers available!

$9US per article for members

$19US for nonmembers

www.computer.org/publications/dlib