Pervasive and Mobile Computing 6 (2010) 5871

Contents lists available at ScienceDirect

Pervasive and Mobile Computing

journal homepage: www.elsevier.com/locate/pmc

Fast track article

Bubble-sensing: Binding sensing tasks to the physical world

Hong Lu a, , Nicholas D. Lane a , Shane B. Eisenman b , Andrew T. Campbell a
a b

Dartmouth College, Hanover, NH, USA Columbia University, New York, NY, USA

article

info

abstract
We propose bubble-sensing, a new sensor network abstraction that allows mobile phone users to create a binding between sensing tasks and the physical world at locations of interest, that remains active for a duration set by the user. We envision mobile phones being able to affix sensing task bubbles at places of interest and then receive sensed data as it becomes available in a delay-tolerant fashion, in essence, creating a living documentary of places of interest in the physical world. The system relies on other mobile phones that opportunistically pass through bubble-sensing locations to acquire tasks and do the sensing on behalf of the initiator, and deliver the data to the bubble-sensing server for retrieval by the user who initiated the task. We describe an implementation of the bubble-sensing system using sensor-enabled mobile phones, specifically, Nokias N80 and N95 (with GPS, accelerometers, microphone, camera). Task bubbles are maintained at locations through the interaction of bubble carriers, which carry the sensing task into the area of interest, and bubble anchors, which maintain the task bubble in the area when the bubble carrier is no longer present. In our implementation, bubble carriers and bubble anchors implement a number of simple mobile phone based protocols that refresh the task bubble state as new mobile phones move through the area. Phones communicate using the local Ad-Hoc 802.11g radio to transfer task state and maintain the task in the region of interest. This task bubble state is ephemeral and times out when no bubble carriers or bubble anchors are in the area. Our design is resilient to periods when no mobiles pass through the bubble area and is capable of reloading the task into the bubble region. In this paper, we describe the bubble-sensing system and a simple proof-of-concept experiment. 2009 Elsevier B.V. All rights reserved.

Article history: Received 23 July 2008 Received in revised form 8 March 2009 Accepted 27 October 2009 Available online 5 November 2009 Keywords: Opportunistic sensing Mobile phones Location-based service

1. Introduction The mobile phone has become a ubiquitous tool for communications, computing, and increasingly, sensing. Many mobile phone and PDA models (e.g., Nokias N95 and 5500 Sport, Apples iPhone and iPod Touch, and Sony Ericssons W580 and W910) commercially released over the past couple years have integrated sensors (e.g., accelerometer, camera, microphone) that can be accessed programmatically, or support access to external sensor modules connected via Bluetooth. The sensed data gathered from these devices form the basis of a number of new architectures and applications [15]. We present the bubble-sensing system that acts to support the persistent sensing of a particular location, as required by user requests. Conceptually, a user with a phone that has opted into the bubble-sensing system visits a location of interest, presses a button on his phone to affix the sensing request to the location, and then walks away. The sensing request persists at the location until the timeout set by the initiator is reached. This mechanism can be viewed as an application in its own right
Corresponding author. E-mail addresses: hong@cs.dartmouth.edu (H. Lu), niclane@cs.dartmouth.edu (N.D. Lane), shane@ee.columbia.edu (S.B. Eisenman), campbell@cs.dartmouth.edu (A.T. Campbell). 1574-1192/$ see front matter 2009 Elsevier B.V. All rights reserved. doi:10.1016/j.pmcj.2009.10.005

H. Lu et al. / Pervasive and Mobile Computing 6 (2010) 5871

59

(e.g., a user slogging [6] his life), and as a persistent sensing building block for other applications. A number of compelling use cases can be envisioned. Sensing bubbles can be used for people to more easily self-organize and collect the proof they need to demonstrate some problem with their community [7]. Such proof is often required before the appropriate authorities will take action. A bubble could be established near a school to prove that traffic speeds are dangerous and changes to the road design are required (e.g., traffic calming measures such as speed bumps). Or a bubble could be established near a factory to monitor pollution levels. By applying the sensing bubble approach people can participate in such initiatives simply by activating an application on their phone. This lowers the burden of participation increasing the likelihood people will become involved. Recreational communities of joggers, orienteers, and cyclists are increasingly forming groups within which they share information about routes, conditions and performance. Many of these people use sensing systems during these forms of recreation [8,5]. An ad hoc series of sensing bubbles could be established by members of these communities along these routes so they could monitor the conditions on their favorites or those they are interested in trying out soon. Sensing bubbles could be used to monitor locations that people want to come back to once current conditions have changed. For instance they may go to a restaurant and find it is too busy, or go to a night club and find that it is not yet very busy. It is common to leave the location and come back once the desired circumstance have been reached. In these cases a person could leave a sensing bubble about a club and then be notified when the sound volume suggests that it is busy, or the reverse in the case of the restaurant (in which case the person wants to return when the place is less busy). They are then free to go shopping or for a walk and be able to return only once things are to their liking. While the notion of virtually affixing sensor tasks to locations is appealing, it requires some work to implement this service on top of a cloud of human-carried phone based sensors. First, since the mobility of the phones is uncontrolled, there is no guarantee that sensors will be well placed to sample the desired location specified by the sensing task. Further, there is the issue of communicating the sensing task to potential sensors when they are well-positioned. This is made more difficult when, either due to hardware or user policy limitations, an always-on cellular link and localization capabilities are not available on all phones. Wireless data access via EDGE, 3G, or open WiFi infrastructure is increasingly available, as is localization service via on-board GPS, WiFi, or cellular-tower triangulation. However, currently, only a subset of mobile phones on the market have GPS and WiFi, and even when devices have all the required capabilities, users may disable the GPS and or limit data upload via WiFi and cellular data channels to manage privacy, energy consumption, and monetary cost. Though the mobility in a people-centric sensor network is not controllable, it is also not random. In an urban sensing scenario, the visited areas of interest for one person are likely to be visited by many others (e.g., street corners, bus/subway stations, schools, restaurants, night clubs, etc.). We imagine a heterogeneous system where users are willing to share resources and data and to fulfill sensing tasks. Therefore, the bubble-sensing system opportunistically leverages other mobile phones as they pass by on behalf of a sensing task initiator. We adopt a two tier hardware architecture comprising the bubble server on the backend; and sensor-enabled mobile phones that can initiate sensing bubbles, maintain sensing bubbles in the designated location, replace bubbles that disappear due to phone mobility, enact the sampling as indicated by the sensing bubble, and report the sensed data back to the bubble server. Mobile phones participating in the bubble-sensing system take on one or more roles depending on their mobility characteristics, hardware capabilities, and user profiles. The bubble creator is the device whose user initiates the sensing request that leads to the creation of the sensing bubble. The bubble anchor keeps the bubble in the region of interest by broadcasting the sensing request. The sensing node perceives the bubble by listening to the broadcasts, takes samples within the area of interest according to the sensing request, and then uploads the results to the bubble server. The bubble carrier can help to restore a bubble if all bubble anchors are lost. The bubble server binds the results to the bubble, which can be queried by the bubble creator at any time. We have implemented the bubble-sensing system using Nokia N95 mobile phones. In Section 2, we describe the specific responsibilities of the virtual roles mentioned above and provide details on the communication protocols required to implement these roles. Sections 3 and 4 describes our current implementation and a preliminary evaluation of bubblesensing using a N95 testbed, reporting on temporal sensing coverage, and on a measure of sensed data quality. In Section 5, we investigate the performance of the system at scale and under a different mobility pattern to extend our testbed results. We discuss related work from the pervasive and mobile ad hoc networking communities, including comparisons to alternative implementation choices, in Section 7. In Section 8, we discuss possibilities for extending the current work and offer concluding remarks. 2. Bubble-sensing Sensing tasks are created and maintained in the bubble-sensing system through the interaction of a number of virtual roles, where a given physical node can take on one or more virtual roles [9] based on its location, device capabilities (e.g., communication mode, sensor), user configuration (when and to what extent resources should be shared for the common good), device state (e.g., an ongoing phone call may preclude taking an audio sample for another application), and device environment (e.g., a picture taken inside the pocket may not be meaningful to the data consumer). In the bubblesensing system, a task is a tuple (action, context , region, duration). The action can be any kind of sensing operation such as take a photo, or record a sound/video clip. The context parameter specifies the set of conditions under which the action should occur. Examples of context categories include sensor orientation and position on the body, and the speed or activity of the sensor carrier. The region is defined as the tuple (location, radius), where location is a point in a coordinate system

60

H. Lu et al. / Pervasive and Mobile Computing 6 (2010) 5871

Fig. 1. Bubble-sensing architecture and bubble management. Phone A is the task creator. A is moved by its human carrier to the area of interest, and attempts to attach the sensing bubble to the area by broadcasting the sensing task via its local radio, and also registers the task with the bubble server via its cellular radio. Stationary phone B receives the task broadcasts from A and assumes the role of a bubble anchor. As the mobility of A takes it out of the bubble area (indicated by the dashed circle), B takes over the management of the sensing task by continuing to broadcast the sensing task to passersby. If the anchor B later moves away, the bubble temporarily disappears. A phone C that later moves through the area of interest is signaled by the bubble server, becomes a bubble carrier, and tries to re-affix the sensing bubble by broadcasting the task via its local radio. Sensed data gathered by phones that accept the sensing task broadcasted by the bubble creator, bubble anchor, or bubble carrier can be uploaded in real time via the cellular network, or in a delay-tolerant fashion via a local radio gateway (e.g., WiFi).

like GPS indicating the center of the region, and the radius defines the area of the region. The granularity of the radius is related to the local communication technology (e.g., Bluetooth, or WiFi) in use. We call this region of interest the sensing bubble. In the following, we describe each of the virtual roles (i.e., bubble creator, bubble anchor, sensing node, and bubble carrier) in the context of the major system operations: bubble creation, bubble maintenance, bubble restoration. Fig. 1 gives a pictorial representation of the bubble-sensing system operation and the main bubble management steps. 2.1. Bubble creation The bubble creator is the device whose user initiates the sensing request that leads to the creation of the sensing bubble. Generally speaking, there are two ways a bubble can be created. In the first scenario, the creator is a mobile phone. The phones carrier moves to the location of interest and creates the sensing task. In the second scenario, the creator is any entity that registers a task with the bubble server, but does interact with other nodes at the location of interest in support of the sensing. As the process flow for the second case is a subset of the first (see bubble restoration in Section 2.4), in the following we omit any further explicit discussion of the second scenario. Proceeding with a discussion of the first scenario, we assume the bubble creator is a mobile device at the location of interest with a short range radio for local peer interactions. The creator (e.g., node A in Fig. 1) broadcasts the sensing task using its short range radio. If the user has enabled cellular data access to the backend bubble server, the creator also registers the task with the bubble server. If the creator has localization capability, it populates the region field of the task definition, and the sensing bubble is created with its center at this location. Otherwise, the region field of the task is left blank in the broadcast, and the sensing bubble is created with its center at the current location of the creator where the area of the bubble is determined by its radio transmission range. Note, that if the creator is not able to obtain a location estimate and register its task with the bubble server, it will not be possible to restore the bubble later (see Section 2.4) in case the bubble disappears due to temporary lack of suitable mobile nodes in the area of interest. Nodes that receive the task broadcast, and meet the hardware and context requirements, for the sensing task can then sense in support of the task and will later upload the sensed data to the bubble server in either a delay-tolerant (e.g., opportunistic rendezvous with an open WiFi access point), or real-time (e.g., the cellular data channel) manner. 2.2. Bubble maintenance Given the uncontrolled mobility of the creator, it may happen that the creator leaves the bubble location while the bubble task is still active (as specified in the duration field of the task). If this happens, it is no longer appropriate for the creator to broadcast the task since recipients of this broadcast will not be in the target bubble location. A way to anchor the bubble to the location of interest is needed; the bubble anchor role fills this requirement (e.g., node B in Fig. 1). The node that takes on this role should be relatively stationary at the target location of the task. We propose two variants for bubble anchor selection, one that requires localization capability on all nodes (e.g., GPS), and one that uses inference from an accelerometer for mobility detection.

H. Lu et al. / Pervasive and Mobile Computing 6 (2010) 5871

61

2.2.1. Location-based In the location-based approach, all nodes that find themselves in the sensing bubble with knowledge of the bubble task (i.e., they can hear the bubble task broadcasts) are potential anchor candidates. If the candidate does not hear another anchor (as indicated by a special field populated in the bubble task broadcast) for a particular threshold time, indicating the bubble is not currently covered by an anchor, it prepares to become the anchor for that bubble. Each candidate anchor backs off a time proportional to its mobility as measured by speed inferred from changes in the location fixes. After this backoff time, a candidate that does not overhear any other anchor broadcasting the task then assumes the role of bubble anchor. The anchor will continue to broadcast the task beacon (with the special field to indicate an anchor is sending it) until it moves out of the location of interest for that bubble. 2.2.2. Mobility-based In the mobility-based approach, like the location-based approach, nodes that can hear the bubble task broadcasts are potential anchor candidates. If the candidate does not hear another anchor broadcasting the bubble task, it backs off a time proportional to its mobility (e.g. stationary, moving, or moving fast), as inferred from data collected by its accelerometer. After this backoff time, a candidate that does not overhear any other anchor broadcasting the task then assumes the role of bubble anchor. The anchor will continue to broadcast the task beacon (with the special field to indicate an anchor is sending it) until it moves out of the location of interest for that bubble. In this case, the mobility is again determined through classification of data from the on-board accelerometer. 2.3. Challenges to bubble maintenance The broadcast-based approach to bubble maintenance introduces two main sources of error to the data collected in support of the sensing task. First, since we do not require sensing nodes to have knowledge of their absolute location, recipients of the task broadcast that are outside of the bubble area defined in the broadcast may still collect and upload data to the bubble server. This potentially makes the effective bubble size larger than the specified bubble size. The extent of this distortion depends both on the radio range of the task broadcast, and the location of the broadcaster (i.e., bubble creator, bubble anchor, and bubble carrier see Section 2.4) with respect to the specified bubble center location. If location-based bubble maintenance is used, or if the sensing node has localization capabilities, the location information may be used to compensate for the transmission power of the task broadcast or suppress sensing when nodes are outside of the defined bubble area to reduce this bubble distortion. The second source of error is bubble drift, which can happen for two reasons. First, drift can happen over time if the anchor moves but continues to broadcast the bubble task due to inaccuracy in its mobility/location-detection methods. While improvements in localization technology and mobility classification can help here, we also explicitly limit the consecutive amount of time a node can act as the anchor for a given bubble. Assuming a probabilistic mobility/location error model, it would be possible to calculate the appropriate timeout to probabilistically limit the bubble drift below a desired level. The second cause of bubble drift is limited to the mobility-based bubble maintenance method where ubiquitous localization not assumed. In this case, as the current anchor gives up its role (e.g., out of battery, anchor role timeout, or move out of the bubble region), one of other semi-stationary or slow moving nodes available in the bubble will take over the anchor role as mentioned in Section 2.2. This can be viewed as a passive role handoff. However, with each handoff the center of the bubble drifts to the location of the new anchor and over time this can markedly distort the sensing coverage of the bubble. To counteract this source of drift, we implement a limit on the number of anchor handoffs. After the handoff limit is reached, the anchor must be reinitialized by the bubble restoration process described in the following section. We note that if mobile devices have continuous localization capability (e.g., using GPS, GPS assisted with GSM [10], WiFi [11]), then bubble distortion and drift is limited by the localization inaccuracy. 2.4. Bubble restoration Due to node mobility, it may happen that no nodes are available to anchor the bubble to the desired location and the bubble may temporarily disappear. To address this scenario, the bubble-sensing system provides a mechanism for bubble restoration through the actions of bubble carrier nodes (e.g., node C in Fig. 1). Mobile phones filling the bubble carrier role require localization capability and a connection to the backend bubble server. Bubble carriers periodically contact the bubble server, update their location, and request any active sensing bubbles in the current region. If a bubble carrier visits the location of one of these bubbles and does not hear any task broadcasts, it attempts to restore the bubble by broadcasting the task without the special anchor field set (in the same way the bubble creator did initially). Through this method, either the bubble will be restored with a new anchor node taking over the bubble maintenance, or this attempt at restoration fails. Bubble restoration attempts continue via the bubble carriers until the bubble expires (as indicated by the duration field in the bubble task definition). 3. Implementation We build a proof-of-concept mobile cell phone testbed to demonstrate the bubble-sensing system. The testbed consists of Nokia N80 and N95 smart phones, both of which run Symbian OS S60 v3. Due to the security platform in Symbian, some

62

H. Lu et al. / Pervasive and Mobile Computing 6 (2010) 5871

Fig. 2. The bubble-sensing architecture implemented on each mobile device.

hardware access APIs are restricted at the OS level and are not open to developers, or require a high privilege certificate. In light of the platform limitations on these two mobile phones, in this section, we discuss the options available and our implementation choices. The bubble-sensing architecture implemented on each mobile device is shown in Fig. 2. 3.1. Programming language We use PyS60 (http://sourceforge.net/projects/pys60/) to prototype our system. PyS60 is Nokias port of Python to the Symbian platform. It not only supports the standard features of Python, but also has access to the phones functions and the on-board sensors (e.g., camera, microphone, accelerometer and GPS), software (e.g., contacts, calendar), and communications (e.g., TCP/IP, Bluetooth, and simple telephony). In addition to that, the developer can easily add access to the native Symbian APIs using the C/C++ extension module. In this regard, PyS60 is more flexible than Java J2ME in providing robust access to native sensor APIs and phone state, as we discovered in our initial development. 3.2. Communication The Nokia N80 and N95 mobile phones are both equipped with GPRS/EDGE, 3G, Bluetooth and WiFi interfaces. For data uplink, they can leverage GPRS, SMS, and MMS for near universal connectivity, and WiFi/Bluetooth access points can also provide Internet access when available. For local peer-to-peer communication, Bluetooth and WiFi are two possible choices. In our testbed, WiFi is our choice for both local communication and communication to the Internet. Considering the cost of the data service for GPRS and existing open WiFi infrastructure in the academic and urban environments, WiFi is a viable option for Internet access. To implement bubble-sensing, broadcast is fundamental and indispensable. While our initial choice for local communication was Bluetooth since it currently enjoys a higher rate of integration into mobile phones, we found peer-to-peer broadcast with Bluetooth technology to be particularly difficult. Fortunately, we can configure the phones to use the Ad-Hoc IEEE 802.11 mode and the UDP broadcasting over WiFi is relatively easy to use. In our current version, the phone uses Ad-Hoc mode when interacting locally with peers, and infrastructure mode to connect to the bubble server. The communications component manages the switch between these two modes on the fly as necessary. The lag of the mode switch is as low as a few seconds. We also set the transmit power of the WiFi interface to its lowest, 4 mW, in order to save energy. 3.3. Sensors Camera and microphone sensors are universal on mobile phones nowadays. In our experiment, to save storage and lower the transmission load, we use lower resolution pictures (640 480 pixels). For sound, we record two second sound clips in .au format; each sound clip is about 28 kB. All data collected are time stamped. For the accelerometer and GPS sensors, the N95 comes with an on-board GPS and a built-in 3D accelerometer. We extend the N80 using the external BluCel device (see Fig. 3), basically a Bluetooth-connected 3D accelerometer. Both types of accelerometers are calibrated, and the data output are normalized to earths gravity. The sampling rate is set to 40 Hz. The sensor manager component coordinates the interleaved sampling of the various sensors, and configures the sensors to sample according to the parameters passed to it by the task manager. 3.4. Classifier Given the hardware and energy constraints of the mobile phone, we implement a simple light weight activity classifier, which consists of two components: a preprocessor and the activity classifier itself.

H. Lu et al. / Pervasive and Mobile Computing 6 (2010) 5871

63

Fig. 3. The BluCel device provides a 3D accelerometer that can be connected to the mobile phone (e.g., Nokia N95 or N80) via Bluetooth.

Table 1 The confusion matrix for our mobility classifier. Stationary Stationary Walking Running 0.9788 0.0480 0.0784 Walking 0.0212 0.9444 0.1765 Running 0.0000 0.0076 0.7451

The preprocessor normalizes the raw accelerometer data it receives from the sensor manager, packs them to 160 four second bins, and then extracts features (attributes) considering each bin separately. Given the constraints of the mobile platform, instead of more computationally costly operations such as FFT, we use simple features such as the mean, standard deviation, and number of peaks for each axis. To achieve better activity inference, prior work [12] suggests that the best position to mount the device is around the hip. However, people may carry a cell phone in different manner (e.g., in a pocket, in a purse), so we cannot make an arbitrary assumption about the cell phones position and orientation while being carried. Therefore, it is impossible to predetermine a particular accelerometer axis whose data would lead to the best classification. Consequently, we treat the three axes equally and merge the three feature vectors together. Our classification is based on the decision tree algorithm, which is a supervised machine learning technique. The computationally expensive training process of the classifier is run offline. We collected the training set for our classifier by having the mobile phone carried by 10 people for several days in their daily routine. They annotate the data when they are sitting, standing, walking and running. Since when sitting and standing, people stay in the same place, we combine them together as the stationary case. Walking means people are moving; running indicates people moving fast. Complicated movements like stair-climbing and cycling will likely by classified as either walking or running. We extract the features for each activity state and then we feed the data set to the J48 decision tree algorithm in the WEKA toolkit [13]. The output of the decision tree algorithm is a small tree with depth three. The classifier is light weight and efficient; the time needed for the preprocessor and the classifier to analyze each bin of samples is less than 1 s on the Nokia N95. On a node currently acting as a bubble anchor, the virtual role manager component resigns its role if the activity classifier informs it that the node is moving (walking or running state) to maintain the stationary property of the sensing bubble. On a potential anchor, the activity classifier informs the virtual role manager about the mobility (e.g., stationary, slow, or fast) of the node to help it determine the appropriate backoff time before replying. Since our system only requires the discrimination between common human mobility patterns, this light weight classifier provides sufficient accuracy (see the confusion matrix in Table 1). 3.5. Localization There are many existing solutions that provide a localization service for mobile phones, including built-in/externalconnected GPS, cell-tower triangulation (GSM fingerprint), Bluetooth indoor localization, and WiFi localization systems such as Skyhook and Navizon. For Symbian, to get all the cell towers information requires a high privilege certificate not available to most developers. Usually, the developer can only get the information about the cell tower to which the phone is currently connected. This does provide a rough sense of where the device is, but is not sufficient for the triangulation algorithm. Therefore, in the outdoor case we simply use GPS. For indoor, the WiFi fingerprint is a natural choice for academic and urban environments, given the relatively widespread coverage of WiFi infrastructure. The localization component manages location acquisition accordingly.

64

H. Lu et al. / Pervasive and Mobile Computing 6 (2010) 5871

3.6. System integration In our current implementation, we use a user interface component to allow for the injecting of sensing tasks into the system. The task manager receives these tasks and coordinates the assignment of virtual roles among mobile peers that rendezvous in the field. The task manager also oversees the collection and upload of data to the backend. Use of the mobile phone as a sensor in the bubble-sensing system should not interfere with the normal usage of the mobile phone. Our bubble-sensing software implementation is light weight, and users can easily switch its user interface to background to use their phone as usual. The software only accesses sensors on demand and releases the resources immediately after use. An incoming or user-initiated voice call has high priority, and our software does not try to access the microphone when it detects a call connection. By adapting in this way, our implementation does not disrupt an ongoing call and also the bubblesensing application will not get killed by an incoming call. We test the CPU and memory usage of our software in a Nokia N95, using a bench mark application, CPUMonitor [14]. The peak CPU usage is around 25%, which happens when sound clips are taken. Otherwise, the CPU usage is about 3%. The memory usage is below 5% of the free memory, including the overhead of the python virtual machine and all the external modules. 4. Testbed evaluation In order to evaluate our implementation of the bubble-sensing system, we perform a series of indoor experiments. The aim of this evaluation is to validate the performance of a mobile cell phone network and how it can benefit from the use of bubble-sensing mechanisms, mainly in terms of the number of data samples collected and the time coverage of those samples. 4.1. Experiment setup Ten mobile phones are carried by people who move around three floors of the Dartmouth computer science building. The carriers stay mobile for the duration of the experiment, except for momentary pauses at the water cooler, printer, or desk (to check for important emails). No particular effort is made to orchestrate the mobility to maintain density in the sensing bubble or elsewhere. The participants are told to carry the cell phones as they normally would. Most of the time the mobile phones are put in the front or back pockets and sometime held in the hand (e.g., when making a call, checking the time, sending a SMS message, etc). Static beacons are used to provide a WiFi localization service. In our experiments, the center of the task bubble is defined to be the Sensor Lab, which is a room on the middle of the three floors. The task is assumed to already be registered by the bubble creator. During the experiment, we play music in the bubble and the task is simply capturing sound clips in this room once every ten seconds. To emulate a heterogeneous network, we intentionally limit device capabilities (i.e., long range connectivity and localization) in some cases. We evaluate the following five different cases:

Static sensor network. For comparison, we deploy one static sensor node (a N95) in the center of the bubble, programmed
to periodically do the sensing. The static node is about three meters away from the source of the music, a pair of speakers, and the microphone is pointed in the direction of the music source. Ideal mobile sensor network. Mobile nodes in the network always have cellular data uplink and localization and can therefore always retrieve the bubble task from the bubble server, and can tell when to do the sensing. No bubble-sensing techniques are used; in fact none are required since all nodes know about all bubble tasks in the system. The results of this case represent an upper bound on what can be expected in the system when using mobile sensors. Limited-capability mobile sensor network. For this scenario, we assume universal always-on connectivity is unrealistic, for both technological and social reasons. Many are unwilling to pay the extra monthly charge to add data service to their cellular service package. In urban environments, such as New York City, we experience frequent dropped connections even outdoors at street level due to interference and fading. Cellular reception indoors is even more inconsistent due to signal attenuation. In rural environments like Hanover, NH, we experience frequent dropped connections due to borderline coverage. Here we make the more realistic assumption that mobile nodes have only a 0.25 probability of an available data uplink (ability to fetch the task from the bubble server and do the sensing) at the moment when they enter the bubble. In this scenario, all nodes are still assumed to have the capability for localization. Again, no bubble-sensing techniques are used. Bubble-sensing with location-based bubble maintenance. This scenario builds on the limited-capability mobile sensor network case by adding bubble carrier and bubble anchor functionality. Therefore, any nodes they hear task broadcasts and are in the bubble will do the sensing. Bubbles are maintained using the location-based scheme (universal localization capability assumed), and are restored using bubble carriers. Mobile nodes entering the bubble location become task carriers with a 0.25 probability as before. Bubble-sensing with mobility-based bubble maintenance. This scenario mirrors the previous, but uses mobility-based bubble maintenance which does not require localization for sensing nodes or anchors, but instead uses radio range to define the bubble size and inference of human mobility from accelerometer data [15] to estimate relative location to the bubble. Mobile nodes entering the bubble location become task carriers with a probability of 0.25 that now includes the probability of having both an available data uplink and localization capability.

H. Lu et al. / Pervasive and Mobile Computing 6 (2010) 5871 Table 2 Sample counts for the five schemes described in Section 4.1: static, ideal, limited, location-based and mobility-based. Static Ideal Limited Location-based Mobility-based All Trial 1 Trial 2 Trial 3 158 143 98 1026 679 324 181 165 74 967 579 294 1004 607 304

65

Out 78 42 40

Locationbased Mobilitybased Limited Ideal Static 0 50 100 150 200 250 Time 300 350 400 450 500

Fig. 4. Sensing coverage over time for each of the five test scenarios described in Section 4.1. The circled points are samples taken outside the bubble due to bubble drift. The bubble-sensing cases do a good job of approximating the ideal case, especially for the location-based bubble maintenance case.

The mobility of the human participants is uncontrolled, but clearly plays a dominant role in the sensing coverage achievable with the bubble-sensing system. Similarly, environmental factors impact the noise environment and thus impact the data that are collected by the mobile sensors. To ensure the five schemes are evaluated in the same environment, we implement them all in the same multi-threaded application and collect data for them simultaneously. The data samples are stored locally and forwarded to the bubble server opportunistically when the phone switches to infrastructure mode, for the duration of the experiment. Any remaining data is transferred to a laptop over USB at the end of the experiment. The analysis is done offline in the backend sever. 4.2. Results We conduct three trials using 11 mobile phones at different times of the day, including both day and night, to capture natural variations in density and mobility pattern. Trial 1 lasts 1936 s during the day-time work hours when people are more stationary; Trial 2 lasts 1752 s during the evening-time work hours; trial 3 lasts 1198 s during a more mobile period. In some cases, we did not get data from all the mobile phones; some did not enter the bubble, and for others the user profile prohibited them from participating (i.e., emulated by the 0.25 probability for task download). We got data from 9, 8, and 7 for the trials 1, 2, and 3, respectively. Table 2 shows raw sample counts taken during each of the trials for each of the five schemes. The table also indicates the samples taken outside of the bubble due to drift in the mobility-based scheme. Fig. 4, shows the time distribution of the collected data samples. It is a 500 s snap shot of trial 2. Each dot in this figure represents one sample. The Y axis lists the five schemes we compare. The distribution of all the mobile schemes is not uniform, because the ability to sense is influenced by uncontrolled mobility. For the mobility-based bubble-sensing scheme, the circled dots show where samples are taken outside the bubble due to bubble distortion and drift. In all mobile schemes, sometimes we have dense readings because multiple sensors stay in the bubble, and sometimes there is a gap in the sensor data due to the absence of sensors. In terms of sensing coverage over time, the bubble-sensing schemes give a good approximation of the ideal mobile sensing scenario, especially in the location-based bubble maintenance case. For the mobility-based bubble maintenance base, we see that the percentage of samples taken outside the defined bubble is less than 10%, which we conjecture is an acceptable error given the flexibility the scheme provides in not requiring localization for sensing nodes or bubble anchors. Further, data just outside the bubble may still be of use to the data consumer. To examine how the data collected by the bubble-sensing system compares with that from the static node, we compute the root mean square (RMS) of the average sound signal amplitude.1 In Fig. 5, we plot the RMS derived from every sound clip recorded by the two different schemes, the static node (thick red) and bubble-sensing with mobility-based bubble maintenance (thin blue). The bubble-sensing curve contains more data points (140) than the static curve (41), reflecting the mobile nodes that opportunistically sample over the 500 s window, as opposed to the single periodic static sensor. While the two curves share general trends, they do not match exactly. There are two main factors contributing to this phenomenon, i.e., mobility and context. The static node remains stationary 3 meters from the sound source, while the mobile nodes move in and out of the audio range of the source, affecting the volume of the samples. Another factor affecting the volume is the sampling context. Users carry the cell phone in their pocket and the pant material serves as a kind of muffler. Also, the orientation of the microphone matters. However, the sampled data does match the general sound situation in the target region, which may be good enough to support applications when static sensor deployments are not present. Thus, bubblesensing provides the flexibility of personalizable sensing regions, but sacrifices some signal fidelity.
1 We use RMS volume as a proxy for music fidelity and are not claiming RMS is itself a direct measure of music fidelity. However, the identification of signal features that predict fidelity (for sound, or anything else) is orthogonal to the mechanism BubbleTag provides to bind sensing tasks to the physical world.

66

H. Lu et al. / Pervasive and Mobile Computing 6 (2010) 5871

103 12 SB w/o Loc Static Node

10

8 RMS ( Power )

0 0 100 200 Time 300 400 500

Fig. 5. In terms of data fidelity, the bubble-sensing approach provides sound data whose trend follows that of the static sensor. In practice, the required fidelity of the signal captured by the task is application-specific.

Battery lifetime on a fully charged N95 running bubble-sensing software is measured 5 times under normal every day use of the cell phone while using no other applications. A full loaded system results in a 4.75 0.45 h battery life. The large standard deviation is due to the number of calls and their duration, distance from cell towers when used, and the other environmental conditions. While the approximately 5 h lifetime is far below the idle lifetime of the phone, we note that the WiFi interface is the most power hungry module. Fortunately, the Bubble-sensing system is designed to be delay tolerant. We can duty-cycle the radio within the typical contact time [16] of common human mobility to reduce the battery consumption, yet still maintain the performance level. By duty-cycling the WiFi interface, the battery life can be extended significantly. With a 50% duty-cycle, the battery life is roughly 8.15 0.63 h. The lifetime is measured as 11.24 0.84 h when the duty-cycle is reduced to 30%. The communication portion of the energy overhead can be further reduced if the mobile phone is equipped with a dedicated low power short range radio module, such as Zigbee. 5. Simulation We perform a simulation of a larger and more complete mobile sensing system to consider the impact of bubblesensing on system level operating characteristics. We assume a sensor network comprising the backend bubble server and a population of mobile sensors. The bubble server accepts sensing task registration both from phones and other entities, as described in Section 2.1. As in the testbed experiment, all tasks have been registered with the bubble server before we start the simulation. With these simulations we assess two test cases: the first using the bubble-sensing techniques, and the other using a centralized approach similar to the ideal case described in Section 4.1. 5.1. Experiment setup The system setup for both test cases is the same. We build a discrete time Java simulator in which a 100 mobile sensors roam over a simulation area of 100 100 distance units. All sensors maintain a queue of sensing tasks. The number of tasks in this queue is bounded to 10 to reflect resource limitations on the phones. Tasks are defined as described in Section 2. All sensors can localize themselves, and the estimation of their position is subject to error selected uniformly at random between 0 and 10 distance units at each time step. All sensors have a wide area data uplink connection to the bubble server that has coverage over the entire simulation area. We assume nodes update their location to the bubble server such that the bubble server is aware of all nodes estimated location at each time step. We neglect the signaling costs of this location tracking in our analysis. In practice, an implementation of the centralized scheme would require a much higher overhead in this regard since nodes are paged and tasked directly from the bubble server for each sensing operation, whereas in the bubble-sensing approach only bubble carriers need to update their location to the server. A simplistic local peer-to-peer radio model is assumed with perfect reception within 10 distance units and no reception outside 10 distance units. Nodes move according to a variant of random waypoint mobility that is adjusted [17] to compensate for the well-known speed decay phenomena. The maximum speed is set to 4 distance units per time step. Under the centralized scheme, the bubble server assigns the appropriate respective sensing task over the WAN connection to any node that has a location estimate within any of the bubbles region of interest. Sensing tasks are executed by the sensing node until its location estimate indicates it has left this bubble region, at which point it notifies the backend infrastructure. The same task may be assigned concurrently to any of the nodes that are within a particular bubble.

H. Lu et al. / Pervasive and Mobile Computing 6 (2010) 5871

25

67

centralized bubbles

wantasking

0 0

10

15

20

500

1000 time

1500

2000

Fig. 6. WAN activity that occurs in support of the sensing task workload.

Under the bubble-sensing scheme, the bubble server assigns sensing tasks to bubble carriers that are within 20 distance units of a bubble center. Again, the same task may be assigned concurrently to any of the nodes that are within this distance from a particular bubble center. If bubble carriers enter the defined bubble region, they take on the sensing role as well as broadcasting the task to other nodes to sense and/or find an anchor, as described in Section 2.4. A sensing task stays in the nodes queue until the node has both entered and subsequently left the bubble region. At this point the task is dropped from the queue to free the resource for other tasks that may be queued at the bubble server. To avoid unfair load on a particular node, a node that is assigned a task by the server and becomes a bubble carrier will not be assigned a new task (regardless of appropriate location) until after a timeout of 100 time units has elapsed. 5.2. Results In the following results we perform simulations lasting 10,000 time units where a collection of 10 tasks remain active for the entire period. Initial node placement is random within the 100 100 square. Bubble center locations are also set randomly when the tasks are registered with the bubble server, and the bubble radius is always 20 distance units. We perform each simulated test case 5 times and report average results. In all figures, we report a window of the simulation results that ranges from time unit 2000 to time unit 4000. By this point, steady state behaviour has been reached, and performance results are no longer being skewed by cold start effects. Fig. 6 shows the WAN usage of both the centralized and bubble-sensing schemes during the simulation. Not surprisingly, WAN use occurs most heavily under the centralized scheme since all tasking occurs directly from the bubble server. The WAN use for bubble-sensing has a periodic pattern due to time-clustered tasking timeouts on multiple nodes. While WAN use is far lower in the bubble-sensing approach, a disproportionately smaller reduction in the collection of data occurs indicating that local communication between the mobile nodes is working effectively to keep the sensing bubble alive. The reverse situation occurs with respect to short range communication. In Fig. 7, we observe significant quantities of these exchanges occurring under the bubble-sensing scheme. Under the centralized scheme such local communications do not take place by definition. In Fig. 8, we consider the ability of bubble-sensing to approximate the sample collection performance of the centralized scheme. The temporal continuity of coverage seen in the centralized approach (the lower panel) is mirrored by the bubblesensing scheme. However the quantity of samples collected has a far higher variance under the bubble-sensing scheme. Under the centralized approach the mobility pattern is paramount in determining the performance of sample collection since if a mobile sensor moves within a region of interest sampling is very likely to occur. But under the bubble-sensing scheme sample collection is influenced more heavily by a wider range of factors including the mobility pattern relative to bubble regions, the relationship of the tasking times to the arrival process of nodes to bubble regions, and the frequency of node rendezvous (when they are within local radio range of each other) that occur within the bubbles. Also, it is interesting to note that there are no noticeable gaps in the plots in Fig. 8, whereas in Fig. 4 for the testbed results there times when no samples are received even for the Ideal case. This is due to the difference in mobility pattern: in the simulation nodes are more or less evenly distributed at all times, whereas in the real testbed, with fewer mobile nodes, the visitations to the bubble region are much more bursty. What is not clearly visible in Fig. 8 is the penalty that occurs in the simulation for the reduction in overhead enabled by bubble-sensing. We observe that while the temporal continuity in collected samples

68

H. Lu et al. / Pervasive and Mobile Computing 6 (2010) 5871

250

bubbles centralized

local_tasking

0 0

50

100

150

200

500

1000 time

1500

2000

Fig. 7. Contrast between the numbers of local peer-to-peer messages exchanged during simulation.
Centralized Scheme

collected samples

10

20

500

1000 time Bubbles Scheme

1500

2000

collected samples

10

20

500

1000 time

5 1500

2000

Fig. 8. Time series comparison of the quantity of samples collected.

achieved with the centralized scheme is maintained with bubble-sensing, the absolute number of the samples collected is somewhat reduced, mirroring the similar relationship we see in the Table 2 for the testbed results between the Ideal and Location-based cases. Thus, the principal tradeoff of the bubble-sensing approach is the ability to reduce the reliance on WAN connectivity, which may or may not be desirable (e.g., due to monetary cost) or feasible (e.g., due to lack of universal coverage), while maintaining support for the same sensing task load as by a centralized scheme, but losing some fidelity through fewer collected samples. The impact on application fidelity of this lower number is different from application to application, and is also sensitive to the threshold when additional samples transition from enhancing fidelity to being redundant. 6. Privacy and security concerns Bubble-sensing presents privacy and security challenges not directly addressed in this paper, but which likely must be addressed for most people to feel comfortable using the system. These challenges center around: (i) the sharing of device resources with unknown third parties and (ii) the privacy implications that result from the collection of people-centric sensor data. These apply generally to any urban sensing system [18,19] and remain an active focus of research. Below we discuss some of the most dominant problems specific to the bubble-sensing system along with recent results that can be leveraged to address these issues.

H. Lu et al. / Pervasive and Mobile Computing 6 (2010) 5871

69

Participants within a bubble-sensing system are subject to having sensitive contextual state about themselves monitored by the infrastructure (e.g., location), which is required for smart task assignment and bubble maintenance. Anonymity preserving context collection and task assignment for opportunistic sensing such as bubble-sensing have been demonstrated [20,21]. The bubble-sensing architecture may be augmented according to these existing proposals to help preserve the privacy of system users. Even if users trust the bubble-sensing infrastructure, individuals privacy concerning their daily activities is still at risk from other users if the system is misused. A sensing bubble can be established in any location, however the people who enter these locations should have the ability to stop sensor data being collected about them if they wish. This issue becomes more complicated when there are conflicting preferences between multiple people in the same physical location. Kapadia, et al. have proposed [22] the concept of virtual walls to resolve of such conflicts and allow people to control their exposure to bubble-sensings sensing infrastructure. Alternatively, individuals privacy can be managed by limiting the representation of data delivered to system users. For example, aggregate summaries (e.g., mean, variance etc.) may be used instead of individual images, sound clips and temperature readings. Even as exposure to other users is limited, an individual can take steps [23] to assure that their own higher resolution data can be recovered. 7. Related work While the mobile phone is ubiquitous, and the discussion of a mobile phone as a sensing device has some history [2426,2,3], no large-scale mobile cell phone sensor networks have yet been deployed in practice. In the last year, the smart phone market has grown rapidly (e.g., Nokia N95, Apple iPhone), cultivating a fertile ground for research on mobile sensor networking. In this paper we present our first attempt to build a mobile cell phone network. Use of information locality to achieve efficient, scalable sensor networking is a hot topic. Ratnasamy, et al. discuss the use of data centric storage to reduce the transmission overhead [27] in data centric routing schemes. The authors of [28] use a publish/subscribe mechanism to opportunistically disseminate information within a specified geographical area using a vehicular networks. Sensor sharing [29] is proposed as an approach to improve sensing fidelity by allowing a tasked node to opportunistically borrow the sensors of nodes in its locality. In contrast, in our work we focus on maintaining the locality of the sensing task, and discuss how to fulfill the sensing task on top of a cloud of human-carried smart phone based sensors in the urban sensing context. Variants of the GUIDE system [30], and other pervasive information broadcast systems address a problem converse to that which bubble-sensing addresses. With these, static infrastructure is used to disseminate location-specific information to mobile devices using either short range or long range radio, or infrared communications. With bubble-sensing, we assume stationary sensing infrastructure is not available at the arbitrary places of peoples interests and instead aim to emulate a static sensing point using the opportunistic interaction of mobile sensors. The authors of [31] describe the challenges to existing programming models when leveraging mobile phones to construct a sensor network. They instead propose an alternative where all mobile sensors are marshalled to sample perpetually in support of all applications, and all data is uploaded to a backend repository. Sensing and uploading is, however, subject to the privacy and energy constraints of the user and her device, respectively. Application developers may write spatiallyconstrained queries against the data repository to support a service similar to bubble-sensing. However, this approach is comparatively very expensive in terms of mobile sensor resources consumed since sampling and uploading may be happening even when no applications require it. The VSA (virtual stationary automata) construct [32], provides an abstraction on which programmers can build any type of program and have the execution of this program occur independent of the mobility pattern of the underlying ad hoc mobile network of nodes that is supporting it. State and code are exchanged in a peer-to-peer fashion within the VSA algorithm. There is an assumption of clock synchronization and for nodes to have a notion of absolute location (i.e, via a GPS device) to execute. Rather than a system providing for user-tagged location-specific sensing, the authors focus on providing a construct that has provable guarantees that are useful for distributed system developers (e.g., self-stabilization). Spatial Programming (SP) [33] is a mobile agent-like approach to the problem of programming mobile embedded devices. SP seeks to abstract away from the programmer the issues such as the density of nodes in a location or even providing for the execution of this application in particular spaces. On each node, virtual machines run and exchange code and data units called bricks. Spatial addressing is done by defining space and tag pairs that bind software variables that incorporate physical locations. Programmers are given freedom to change behaviour but by default a geographic routing protocol is used to distribute bricks to appropriate nodes. Variants of the approach are discussed in [34]. The value of spatially-oriented programming abstractions such as Hood [35] and Abstract Regions [36] have been proposed for mote-class sensor networks. For mobility-based bubble maintenance, we infer the mobility of nodes to determine bubble anchor selection. In [15], the authors use multiple sensing modalities available on a custom-built experimental sensor platform to attempt general purpose activity classification, and use offline analysis due to the heavy weight of the algorithms. For bubble-sensing, we have implemented a light weight, real-time algorithm that can run on the mobile phone using only the accelerometer as a sensor input, and that classifies only peoples movement rather than general activity. Previous work [37,38] has shown that by using only accelerometers placed on different parts of the body one can classify activities fairly well even on resource limited embedded devices. However, using multiple sensors placed on the body is an unnatural solution and is unlikely to be quickly adopted by the general public. Even requiring that a single sensor be affixed

70

H. Lu et al. / Pervasive and Mobile Computing 6 (2010) 5871

to a special location [39], such as clipped to a belt, may be viewed as too intrusive or impractical depending on wardrobe. We use a single accelerometer embedded in commercial mobile phones that people carry every day. Our classification algorithm is robust to sensor placement; our experiments demonstrate relatively high classification accuracy even though people carried the phones however they felt most comfortable (e.g., in the hand, in the front or back pocket, etc.). 8. Conclusion We presented an approach to support persistent location-specific task in a wireless sensor network composed of mobile phones. Mobile sensor nodes collaborate and share sensing and communication resources with each other in a cooperative sensing environment. We describe the virtual roles nodes can assume in support of bubble-sensing, including the required local and backend communication. We discussed the limitations, available options and our design decisions in the implementation of a mobile phone based sensing system. We demonstrated the feasibility of our scheme via a real testbed experiment using people carrying mobile phones. Acknowledgments This work is supported in part by Intel Corp., Nokia, NSF NCS-0631289, and the Institute for Security Technology Studies (ISTS) at Dartmouth College. ISTS support is provided by the US Department of Homeland Security under Grant Award Number 2006-CS-001-000001. The views and conclusions contained in this document are those of the authors and should not be interpreted as necessarily representing the official policies, either expressed or implied, of the US Department of Homeland Security. References
[1] A.T. Campbell, S.B. Eisenman, N.D. Lane, E. Miluzzo, R.A. Peterson, People-centric urban sensing, in: Proc. of 2nd ACM/IEEE Intl Conf. on Wireless Internet, WICON06, ACM Intl Conf. Proc. Series, vol. 220, No. 18, Boston, Aug 25, 2006, (Invited Paper). [2] J. Burke, D. Estrin, M. Hansen, A. Parker, N. Ramanathan, S. Reddy, M.B. Srivastava, Participatory sensing, in: Proc. of 1st Workshop on Wireless Sensor Web, WSW06, Boulder, October 31, 2006, pp. 15. [3] T. Abdelzaher, Y. Anokwa, P. Boda, J. Burke, D. Estrin, L. Guibas, A. Kansal, S. Madden, J. Reich, Mobiscopes for human spaces, IEEE Pervasive Computing 6 (2) (2007) 2029. [4] S.B. Eisenman, A.T. Campbell, SkiScape sensing, in: Proc. of ACM 4th Intl Conf. Embedded Networked Sensor Systems, SENSYS04, 2006. [5] S.B. Eisenman, E. Miluzzo, N.D. Lane, R.A. Peterson, G.-S. Ahn, A.T. Campbell, The BikeNet mobile sensing system for cyclist experience mapping, in: Proc. of 5th ACM Conf. on Embedded Networked Sensor Systems, SENSYS05, Sydney, Nov 69, 2007. [6] K. Chang, N. Yau, M. Hansen, D. Estrin, SensorBase.org A centralized repository to slog sensor network data, in: Proc. of the Intl Conf. on Distributed Computing in Sensor Networks/Euro-American Workshop on Middleware for Sensor Networks, San Francisco, Jun 2006. [7] PEIR project, http://peir.cens.ucla.edu. [8] Nike+iPod Sports Kit, http://www.apple.com/ipod/nike/. [9] C. Frank, K. Rmer, Algorithms for generic role assignment in wireless sensor networks, in: Proc. of 3rd Intl Conf. on Embedded Networked Sensor Systems, SENSYS05, San Diego, Nov 24, 2005, pp. 230242. [10] G.M. Djuknic, R.E. Richton, Geolocation and assisted GPS, IEEE Computer 34 (2) (2001) 123125. Feb. [11] A. LaMarca, Y. Chawathe, S. Consolvo, J. Hightower, I.E. Smith, J. Scott, T. Sohn, J. Howard, J. Hughes, F. Potter, J. Tabert, P. Powledge, G. Borriello, B.N. Schilit, Place lab: Device positioning using radio beacons in the wild, in: Proc. of IEEE 3rd Intl Conf. on Pervasive Computing, PERVASIVE05, Munich, May 813, 2005, pp. 116133. [12] L. Bao, S.S. Intille, Activity recognition from user-annotated acceleration data, in: Proc. of IEEE 2nd Intl Conf. on Pervasive Computing, PERVASIVE04, Vienna, Apr 2123, 2004, pp. 117. [13] I.H. Witten, E. Frank, Data Mining: Practical Machine Learning Tools and Techniques with Java Implementations, Morgan Kaufmann Publishers Inc, San Francisco, CA, USA, 2000. [14] CPUMonitor 1.10 for S60v3, http://www.nokiapower.com/index.php?showtopic=7542. [15] J. Lester, T. Choudhury, G. Borriello, A practical approach to recognizing physical activities, in: Proc. of IEEE 4th Intl Conf. on Pervasive Computing, PERVASIVE06, Dublin, May 710, 2006, pp. 116. [16] E. Miluzzo, X. Zheng, K. Fodor, A.T. Campbell, Radio Characterization of 802.15. 4 and its Impact on the Design of Mobile Sensor Networks, in: Lecture Notes in Computer Science, vol. 4913, 2008, p. 171. [17] L. Hu, D. Evans, Localization for mobile sensor networks, in: Proc. of ACM 10th Annual Intl Conf. on Mobile Computing and Networking, MOBICOM04, Philadelphia, Sep/Oct 2004, pp. 4557. [18] A. Parker, S. Reddy, T. Schmid, K. Chang, G. Saurabh, M. Srivastava, M. Hansen, J. Burke, D. Estrin, M. Allman, V. Paxson, Network system challenges in selective sharing and verification for personal social and urban scale sensing applications, in: Proc. of 5th Workshop on Hot Topics in Networks HotNets-V, Irvine, Nov 2930, 2006, pp. 3743. [19] A. Kapadia, D. Kotz, N. Triandopoulos, Opportunistic sensing: Security challenges for the new paradigm, in: Proc. of 1st International Conference on Communication Systems and Networks, COMNETS, Bangalore, Jan 510 2009. [20] A. Kapadia, N. Triandopoulos, C. Cornelius, D. Peebles, D. Kotz, AnonySense: Opportunistic and privacy-preserving context collection, in: Proc. of IEEE Sixth Intl Conf. on Pervasive Computing, PERVASIVE08, Sydney, May 1922, 2008, pp. 280297. [21] C. Cornelius, A. Kapadia, D. Kotz, D. Peebles, M. Shin, N. Triandopoulos, AnonySense: Privacy-aware people-centric sensing, in: Proc. of ACM 6th Intl Conf. on Mobile Systems, Applications and Services, MOBISYS08, Breckenridge, Jun 1720 2008, pp. 211224. [22] A. Kapadia, T. Henderson, J. Fielding, D. Kotz, Virtual walls: Protecting digital privacy in pervasive environments, in: Proc. of IEEE Fifth Intl Conf. on Pervasive Computing, PERVASIVE07, Toronto, May 13-16, 2007, pp. 162179. [23] R.K. Ganti, N. Pham, Y. Tsai, T.F. Abdelzaher, PoolView: Stream privacy for grassroots participatory sensing, in: Proc. of 6th ACM Conf. on Embedded Networked Sensor Systems, SENSYS08, Raleigh, Nov 57, 2008. [24] A. Kansal, M. Goraczko, F. Zhao, Building a sensor network of mobile phones, in: Proc. of ACM 6th Intl Conf. on Information Processing in Sensor Networks, IPSN07, Cambridge, Apr 2527, 2007, pp. 547548. [25] N. Eagle, A. Pentland, Reality mining: Sensing complex social systems, Journal of Personal and Ubiquitous Computing 10 (4) (2006) 255268. [26] E. Miluzzo, N.D. Lane, S.B. Eisenman, A.T. Campbell, CenceMe Injecting sensing presence into social networking applications, in: Proc. of 2nd European Conf. on Smart Sensing and Context, EUROSSC07, Kendal, Oct 2325, 2007 (Invited paper).

H. Lu et al. / Pervasive and Mobile Computing 6 (2010) 5871

71

[27] S. Ratnasamy, B. Karp, L. Yin, F. Yu, D. Estrin, R. Govindan, S. Shenker, GHT: A geographic hash table for data-centric storage in SensorNets, in: Proc. of 1st ACM Intl Workshop on Wireless Sensor Networks and Applications, WSNA02, Atlanta, Sep 28, 2002, pp. 7887. [28] I. Leontiadis, C. Mascolo, Opportunistic spatio-temporal dissemination system for vehicular networks, in: Proc. of ACM 1st Intl MOBISYS Workshop on Mobile Opportunistic Networking, MOBIOPP07, San Juan, Jun 11, 2007). [29] S.B. Eisenman, N.D. Lane, Andrew T. Campbell, Techniques for improving opportunistic sensor networking performance, in: Proc. of the 4th IEEE Intl Conf. on Distributed Computing in Sensor Systems, DCOSS08, Santorini, Jun 1114, 2008, pp. 157175. [30] K. Cheverst, N. Davies, K. Mitchell, A. Friday, C. Efstratiou, Developing a context-aware electronic tourist guide: Some issues and experiences, in: Proc. of SIGCHI Conf. on Human Factors in Computing Systems, CHI00, The Hague, Apr 16, 2000, pp. 1724. [31] A. Kansal, F. Zhao, Location and mobility in a sensor network of mobile phones, in: Proc. of ACM 17th Intl Workshop on Network and Operating Systems Support for Digital Audio & Video, NOSSDAV07, Urbana-Champaign, Jun 45, 2007. [32] S. Dolev, S. Gilbert, L. Lahiani, N.A. Lynch, T. Nolte, Timed virtual stationary automata for mobile networks, in: Proc. of 9th Intl Conf. on Principles of Distributed Systems, OPODIS05, Pisa, Dec 1215, 2005, pp. 130145. [33] O. Riva, C. Borcea, The urbanet revolution: Sensor power to the people!, IEEE Pervasive Computing 6 (2) (2007) 4149. Apr/Jun. [34] C. Borcea, C. Intanagonwiwat, P. Kang, U. Kremer, L. Iftode, Spatial programming using smart messages: Design and implementation, in: Proc. of 24th Intl Conf. on Distributed Computing Systems, ICDCS04, Tokyo, Mar 2426, 2004, pp. 690699. [35] K. Whitehouse, C. Sharp, E. Brewer, D. Culler, Hood: A neighborhood abstraction for sensor networks, in: Proc. of ACM 2nd Intl Conf. on Mobile Systems, Applications and Services, MOBISYS04, Boston, Jun 69, 2004, pp. 99110. [36] M. Welsh, G. Mainland, Programming sensor networks using abstract regions, in: Proc. of USENIX 1st Symposium on Networked Systems Design and Implementation, NSDI04, pg. 3, San Francisco, Mar 2931, 2004. [37] C. Lombriser, N.B. Bharatula, D. Roggen, G. Trster, On-body activity recognition in a dynamic sensor network, in: Proc. of 2nd ICST Intl Conf. on Body Area Networks, BODYNETS07, June, 2007. [38] N. Kern1, B. Schiele1, A. Schmidt, Multi-sensor activity context detection for wearable computing, in: Proc. of European Symposium on Ambient Intelligence, EUSAI03, Eindhoven, Nov 34, 2003, pp. 220232. [39] Nishkam Ravi, Nikhil Dandekar, Preetham Mysore, Michael Littman, Activity recognition from accelerometer data, in: Proc. of AAAI 17th Conf. on Innovative Applications of Artificial Intelligence, IAAI05, Jul 913, 2005, pp. 15411546.

Hong Lu is a Ph.D. student at the Dartmouth College. His research interests include networked systems, mobile and ubiquitous computing, and wireless sensor networks. He has a Masters in computer science from Tianjin University, China.

Nicholas D. Lane is a Ph.D. student in the Computer Science Department at Dartmouth College. He received a B.Sc. degree in Computer Science and Finance from Waikato University in New Zealand and an M.Eng. degree in Computer Science from Cornell University in the US. His research interests include wireless sensor networks, particularly urban and people-centric sensing systems. He is a member of the MetroSense project and the Sensor Networks group at Dartmouth College.

Shane B. Eisenman (M96) received the B.Sc. degree in 1998 from Binghamton University, New York, and the M.Sc. and Ph.D. degrees in 2003 and 2008, respectively, from Columbia University, New York, all in Electrical Engineering. His research interests include wireless networking, with particular interest in people-centric sensing. He is a member of the COMET group and the Armstrong project at Columbia University and a member of the Sensor Lab and the MetroSense project at Dartmouth College.

Andrew T. Campbell (M93) received the Ph.D. in computer science (1996) from Lancaster University, Lancaster, England. He is an Associate Professor of Computer Science at Dartmouth College, Hanover, where he leads the Sensor Lab and the MetroSense project and is a member of the Institute for Security Technology Studies (ISTS). His current research interests include peoplecentric sensing, intrusion detection systems for WiFi networks, and open spectrum wireless networks. Dr. Campbell received the NSF CAREER Award (1999) for his research in programmable mobile networking. He spent his sabbatical year (20032004) at the Computer Lab, Cambridge University, as an EPSRC Visiting Fellow.