A SEMINAR REPORT ON

Bubble-Sensing: A New Paradigm for Binding a SensingTask to the Physical World Using Mobile Phones

SUBMITTED BYMayur M Shah

TE43067

SEMINAR GUIDEProf.Mrs.L.B.Bhagwat

Department of Computer Engineering MAHARASHTRA INSTITUTE OF TECHNOLOGY

PUNE-4110382011-2012

i

MAHARASHTRA ACADEMY OF ENGINEERING & EDUCATIONALRESEARCH’S

MAHARASHTRA INSTITUTE OF TECHNOLOGYPUNE.

DEPARTMENT OF COMPUTER ENGINEERING

CERTIFICATE

This is to certify that Mayur M Shah, Roll No. - TE43067 of

T. E. Computer successfully completed seminar in

BUBBLE-SENSING

to my satisfaction and submitted the same during the academic year 2011-2012 towards the partial fulfillment of degree of Bachelor of Engineering in Computer Engineering of Pune University under the Department of Computer Engineering , Maharashtra Institute of Technology, Pune.

Prof. Mrs.L.B.Bhagwat Prof. Mrs. S.S. Paygude (Seminar guide) (Head of Computer Engineering Department)

ii

ACKNOWLEDGEMENT

I the undersigned is extremely obliged to present a seminar on the topic called “Bubble Sensing”. This seminar wouldn’t have been possible without the assistance of our Computer Head of Department Prof.Mrs.S.S.Paygude, respective project guide Prof.Mrs.L.B.Bhagwat, Laboratory Administrative and all other staff who helped this seminar topic to become more informative and presentable.

I repeatedly express a true sense of gratitude to the seminar guide for giving this seminar topic ,her most precious time filled with co-operation and thorough guidance which helped me understand my seminar topic and enhance my presentation skills required to present my knowledge before the world.I would also like to thank our Head Of Department for her appreciation and patience.

All the staff members have truly inspired and encouraged me throughout, by providing various facilities, which enhanced my seminar and a sense of gratitude and appreciation towards all those who helped me knowingly and unknowingly and pushed me to excel the presentation for the seminar to its fullest. Last but not the least I would thank and express my gratefulness to all my friends who made this seminar look appreciable.

Shah Mayur Mohan(TE43067)

iii

ABSTRACT

This paper presents Bubble-Sensing, a new sensor network abstraction that allows mobile phones users to create a

binding between tasks (e.g., take a photo, or sample audio every hour indefinitely) and the physical world at locations of

interest, that remains active for a duration set by the user. Also to envision mobile phones being able to affix 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 that initiated the task. Also described is an

implementation of the bubble-sensing system using sensor-enabled mobile phones. 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 the

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. The design is resilient to periods when no mobiles

pass through the bubble-area and is capable of “reloading” the task into the bubble region. Described in this paper is the

bubble-sensing system and a simple proof of concept experiment.

iv

INDEX

Chapter 1: Sensors...................................................................................1

1.1 Introduction

1.2 Sensors in Smartphones

1.2.1 Microphone

1.2.2 Accelerometer

1.2.3 Ambient Light Sensor

1.2.4 Proximity Sensor

1.2.5 Gyroscope

1.2.6 GPS

Chapter 2: Sensor Networks.....................................................................4

2.1 Intoduction to Sensor Networks

2.2 Applications

Chapter 3: Bubble-Sensing………………………………………………6

3.1 Introduction

3.2 Bubble Creation

3.3 Bubble Maintenance

3.3.1 Location Based

3.3.2 Mobility Based

3.4 Challenges to Bubble Maintenance

3.5 Bubble Restoration

Chapter 4: Implementation........................................................................11

4.1 Programming Language

4.2 Communication

4.3 Sensors and Classifiers

4.4 Localization

v

4.5 System Integration

Chapter 5: Test-Bed Evaluation………………………………………….14

5.1 Experiment Setup

5.2 Results

Chapter 6: Simulation..................................................................................18

6.1 Experiment Setup

6.2 Results

Chapter 7: Related Work………………………………………………….22

7.1 Code In The Air

7.2 Online Sensing Task Optimization for Shared Sensors

7.3 NotiSense: An Urban Sensing Notification System to improve

Bystander Privacy

Conclusion………………………………………………………………….28

References…………………………………………………………………..29

vi

Bubble Sensing

Chapter 1

Sensors

1.1 Introduction

A sensor (also called detector) is a converter that measures a physical quantity and converts it into a

signal which can be read by an observer or by an (today mostly electronic) instrument.

Sensors are used in everyday objects such as touch-sensitive elevator buttons (tactile sensor) and lamps

which dim or brighten by touching the base. There are also innumerable applications for sensors of which

most people are never aware. Applications include cars, machines, aerospace, medicine, manufacturing

and robotics.

The tremendous growth of sensor technology in Smartphone increases day by day and will experience

fabulously over the next few years. Success of smart phones is leading to an increasing amount of

MEMS & sensors in mobile phones to provide new features/ services to end-users, to reduce cost

through more integration or to improve hardware performance.

1.2 Sensors In Smartphones

1.2.1 Microphone

Many mobile devices, specially mobile phones, come equipped with a microphone. Microphones are

high-fidelity sensors that can pick up sounds relating to a range of physical phenomena. Using simple

feature extraction methods, parameters can be found that sensibly map to synthesis algorithms to allow

expressive and interactive performance. For example blowing noise can be used as a wind instrument

excitation source. Also other types of interactions can be detected via microphones, such as striking.

Hence the microphone, in addition to allowing literal recording, serves as an additional source of input to

the developing field of mobile phone performance.

Microphone

1.2.2 Accelerometer

The accelerometer allows the device of Smartphone to detect the orientation of the device and adapts the

content to suit the new orientation. For example, when you rotate your device sideways, the Web

1

Bubble Sensing

browser automatically switches the screen to landscape mode so that you now have a wider viewing

space. Similarly, the camera relies on the accelerometer to tell it whether you are taking a picture in

portrait or landscape mode. The accelerometer in smart devices measures the acceleration of the device

relative to freefall. A value of 1 indicates that the device is experiencing 1 g of force exerting on it (1 g of

force being the gravitational pull of the earth, which your device experiences when it is stationary). The

accelerometer measures the acceleration of the device in three different axes: X, Y, and Z.

Accelerometer

1.2.3 Ambient Light Sensor

An ambient light sensor to portable devices such as tablets, smart phones, and laptops extends battery

life and enables easy-to-view displays that are optimized to the environment. basically an ambient light

sensor adjusts the display brightness which in turn saves battery power in Smartphone; it saves power by

adjusting the brightness of the display based on how much ambient light is present.

1.2.4 Proximity Sensor

A proximity sensor is very much useful in Smartphone. It detects how close the screen of the phone is to

your body. This allows the phone to sense when you have brought the phone up to your ear. At that

point, the display turns off in order to save battery. It also stops detecting touches, as to avoid unwanted

input, until you take the phone away from your ear. Proximity Sensor can turn off the screen to avoid

accidental touch of the screen by ear. Besides it is useful for detecting towers and sources of interference.

So in a word, The proximity sensor in Smartphone senses how close the phone is to the user’s

cheek/face, so that it can pause whatever activity it is in the middle of (playing music or browsing the

web, for example) so the user can take a phone call. When the phone is removed from the ear after the

call, the phone resumes its previous activity.

2

Bubble Sensing

1.2.5 Gyroscope

A gyroscope is a device for measuring or maintaining orientation, based on the principles of angular

momentum. Gyroscopic sensors used in navigation systems and gesture recognition systems in

Smartphones and tablet PCs. Gyroscopes are used in Smartphones and tablet PCs for finding the position

and orientation of devices. . Combining a gyroscope with an accelerometer allows the device to sense

motion on six axes – left, right, up, down, forward and backward, as well as roll, pitch and yaw rotations

– allowing for more accurate motion sensing abilities comparable to a game controller such as the Wii-

mote.

1.2.6 GPS Module

GPS was originally intended for military applications, but in the 1980s, the government made the system

available for civilian use. It’s a Navigation tracking, often with a map “picture” in the background, but

showing where you have been, and allowing “routes” to be preprogrammed, giving a line you can follow

on the screen of Smartphone. GPS satellites circle the earth twice a day in a very precise orbit and

transmit signal information to earth. GPS receivers take this information and use triangulation to calculate

the user’s exact location. Mobile GPS unit identifies user’s position information with details including

latitude, longitude with maximum accuracy up to 15 meters in radius. GPS technology is measuring the

exact position of the mobile user more accurately by calculating user's coordinates with the help of

satellite signals. 

GPS Module

3

Bubble Sensing

Chapter 2

Sensor Networks

2.1 Introduction to Sensor Networks

A sensor network is a group of specialized transducers with a communications infrastructure intended to

monitor and record conditions at diverse locations. Commonly monitored parameters are temperature,

humidity, pressure, wind direction and speed, illumination intensity, vibration intensity, sound intensity,

power-line voltage, chemical concentrations, pollutant levels and vital body functions. A sensor network

consists of multiple detection stations called sensor nodes, each of which is small, lightweight and

portable. Every sensor node is equipped with a transducer, microcomputer, transceiver and power

source. The transducer generates electrical signals based on sensed physical effects and phenomena. The

microcomputer processes and stores the sensor output. The transceiver, which can be hard-wired

or wireless, receives commands from a central computer and transmits data to that computer. The power

for each sensor node is derived from the electric utility or from a battery.The more modern networks are

bi-directional, also enabling control of sensor activity. The development of wireless sensor networks was

motivated by military applications such as battlefield surveillance; today such networks are used in many

industrial and consumer applications, such as industrial process monitoring and control, machine health

monitoring, and so on.

2.2 Applications

Area monitoring

Area monitoring is a common application of WSNs. In area monitoring, the WSN is deployed over a

region where some phenomenon is to be monitored. A military example is the use of sensors to detect

enemy intrusion; a civilian example is the geo-fencing of gas or oil pipelines.

When the sensors detect the event being monitored (heat, pressure), the event is reported to one of the

base stations, which then takes appropriate action (e.g., send a message on the internet or to a satellite).

Similarly, wireless sensor networks can use a range of sensors to detect the presence of vehicles ranging

from motorcycles to train cars.

4

Bubble Sensing

Forest fires detection

A network of Sensor Nodes can be installed in a forest to detect when a fire has started. The nodes can be

equipped with sensors to measure temperature, humidity and gases which are produced by fires in the

trees or vegetation. The early detection is crucial for a successful action of the firefighters; thanks to

Wireless Sensor Networks, the fire brigade will be able to know when a fire is started and how it is

spreading.

Structural monitoringWireless sensors can be used to monitor the movement within buildings and infrastructure such as

bridges, flyovers, embankments, tunnels etc... enabling Engineering practices to monitor assets remotely

without the need for costly site visits, as well as having the advantage of daily data, whereas traditionally

this data was collected weekly or monthly, using physical site visits, involving either road or rail closure

in some cases. It is also far more accurate than any visual inspection that would be carried out.

5

Bubble Sensing

Chapter 3

Bubble Sensing

3.1 Introduction

The mobile phone has become a ubiquitous tool for communications, computing, and increasingly,

sensing. Many mobile phone and PDA models (e.g., Nokia’s N95 and 5500 Sport, Apple’s iPhone and

iPod Touch, and Sony Ericsson’s 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 . The Bubble-Sensing

system, 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 tothe 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 ownright (e.g., a user slogging his life), and as a

persistent sensing building block for other applications. 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. For example, wireless data access via EDGE,

3G, or open WiFi infrastructure is increasingly available, as is the location service via on-board GPS,

WiFi, or cellular tower triangulation. However, for example, 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

6

Bubble Sensing

on the back end; 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

characteristic, 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 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.

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 role 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 bubble-sensing system, a task is a

tuple (action, region, duration) The action can be any kind of sensing operation such as “take a photo”, or

“record a sound/video clip”. The region is defined as the tuple (location, radius), where location is a point

in a coordinate system like GPS indicating the center of the region, and the radius defines the area of the

region. 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.

3.2 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 phone’s 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.

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 Figure

1) broadcasts the sensing task using its short range radio. If the user has enabled cellular data access to the

7

Bubble Sensing

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 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.

3.3 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 Figure 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.

3.3.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 thenassumes 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.

8

Bubble Sensing

3.3.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, 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.

3.4 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) with

respect to the specified bubble center location. If locationbased bubble maintenance is used, or if the sensing

node haslocalization capabilities, the location information may be used to compensate 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, or anchor role timeout, 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. This can be viewed as a passive role handoff. However, with each handoff the center of the bubble drifts

9

Bubble Sensing

to the location of the new anchor and over time this can markedly distort the sensingcoverage of the bubble.

To counteract this source of drift, we implement a limit on the number of anchor handoffs.

3.5 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 Figure 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).

Fig 1. Bubble-Sensing architecture and bubble management. Phone A isthe task creator. A is moved by its human carrier to the area of interest, andattempts to attach the sensing bubble to the area by broadcasting the sensingtask 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 andassumes the role of bubble anchor. As the mobility of A takes it out of the

bubble area (indicated by the dashed circle), B takes over the management ofthe sensing task by continuing to broadcast the sensing task to passersby. Ifthe anchor B later moves away, the bubble temporarily disappears. A phone

C that later moves through the area of interest is signaled by the bubbleserver, 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 thataccept the sensing task broadcasted by the bubble creator, bubble anchor, orbubble 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).

10

Bubble Sensing

Chapter 4

Implementation

The test bed consists of Nokia N80 and N95 smart phones, both of which run Symbian OS S60 v3. Due to the

security platform in Symbian, some 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 implementation choices.

4.1 Programming Language

We use PyS60 to prototype our system. PyS60 is Nokia’s port of Python to the Symbian platform. It not only

supports the standard features of Python, but also has access to the phone’s 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.

4.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 the universal connectivity, and

WiFi/Bluetooth access points can also provide Internet access when available. For local communication,

Bluetooth and WiFi are two possible choices. In our test bed, WiFi is our choice for both local communication

and communication to the Internet. Considering the cost of the data service for GPRS and existing openWiFi

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 out current version, the phone uses Ad-Hoc mode when interacting locally with peers, and

infrastructure mode to connect to the bubble server. Phones canswitch between these two modes on the fly

when 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 the lowest, 4mW, in order to save energy.

11

Bubble Sensing

4.3 Sensors and Classifier

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 soundclips in .au format; each sound clip is about 28 kB. All data collected are time

stamped. For the accelerometer and GPS sensors, the smartphones come with an on-board GPS and a built-in

3D accelerometer.Both types of accelerometers are calibrated, and the data output are normalized to earth

gravity. The sampling rate is set to 40 Hz. Phones perform some relatively simple processing on the data

samples (e.g.,

mean, variance, and threshold) and feed the features extracted from data samples to a simple decision tree

classifier, which classifies the movement of people carrying the phone. The classifier does not require the user

to mount the mobile phone in a particular way; users can simply put the phone in a pocket or clip it on the belt.

The tradeoff for this flexibility is that the classifier can only differentiate basic movements of people, i.e.,

stationary, walking, running. Complicated movements like stair-climbing and cycling will likely by classified

as either walking or running. However, our system only requires the discrimination between stationary and

moving. In this sense, this light weight classifier provides sufficient accuracy.

4.4 Localization

There are many existing solutions that provide a localization service for mobile phones, including

built-in/external connected 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.

4.5 System Integration

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, so users can easily switch it

to background, and use their phone as usual. The software only accesses sensors on demand and release 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

12

Bubble Sensing

implementation does not disrupt an ongoing call and also the bubble-sensing 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 . 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.

13

Bubble Sensing

Chapter 5

Test-Bed 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.

5.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, sensing 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: Assuming 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

14

Bubble Sensing

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

mobilitybased 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

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.

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.

Fig. 2 Sensing coverage over time for each of the five test scenarios described above 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.

15

Bubble Sensing

5.2 Results

Sample Counts For Schemes Described Above

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 seconds during the day-time work

hours when people are more stationary; Trial 2 lasts 1752 seconds during the eveningtime work hours; trial 3

lasts 1198 seconds 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 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. Figure 3,

shows the time distribution of the collected data samples. It is a 500 second 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, sometime 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. In Figure 4, 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

16

Bubble Sensing

the 500 second 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, bubble-sensing provides the flexibility of personalizable sensing

regions, but sacrifices some signal fidelity.

Fig. 3 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.

17

Bubble Sensing

Chapter 6

Simulation

We perform a simulation of a larger and more complete mobile sensing system to consider the impact of

bubble sensing 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 II-A. 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.

6.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.

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 assumenodes 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 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.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

18

Bubble Sensing

bubble region, they take on the sensing role as well as broadcasting the task to other nodes to sense and/or find

an anchor. A sensing task stays in the node’s 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 timeout of 100 time units has elapsed.

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

Fig. 5. Contrast of the number of local peer-to-peer messages exchangedduring simulation.

19

Bubble Sensing

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

6.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 2,000 to time unit 4,000. By this point,

steady state behaviour has been reached, and performance results are no longer being skewed by cold start

effects. Figure 4 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 Figure 5, we observe significant quantities of these exchanges

occurring under the bubblesensing scheme. Under the centralized scheme such local communications do not

take place by definition. In Figure 6, 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 bubble-sensing scheme. However the quantity of samples

collected has a far higher variance under the bubble-sensing scheme. Under the centralized approach the

20

Bubble Sensing

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 bubblesensing 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 Figure 6, whereas in

Figure 2 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 Figure 6 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

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 II 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 throughfewer collected samples. The impact on

application fidelity of this lower number is different from application to application, and is also sensitive to

threshold when additional samples transition from enhancing fidelity to being redundant.

21

Bubble Sensing

Chapter 7

Related Work

All mobile phones have a microphone, and most have a camera. Other sensors can be connected to a phone

using Bluetooth. Mobile phones are connected to a network. They have a relatively predictable power supply,

based on human user initiated charging. They are present in large numbers covering a vast spatial expanse,

making them suitable to be used as a large scale sensor network. Using such mobile devices as sensors has a

significant advantage over unattended wireless sensor networks in that deploying the sensing hardware and

providing it with network and power is already taken care of. Secondly, mobile phones can provide coverage

where static sensors are hard to deploy and maintain. No single entity may have the access rights to place

sensors across the complete coverage domain required by an application, such as a combination of subway

stations, public parks, and shopping malls. Thirdly, each mobile device is associated with a human user, whose

assistance can sometimes be used to enhance application functionality. For instance, a human user may help

by pointing the camera appropriately at the target object to be sensed. Our goal is to enhance the utility of the

existing swarm of mobile devices by presenting it as a physical sensing substrate that sensor networking

applications may program for their sensing objectives. Several applications can be enabled using sensor

networks of mobile phones, such as instant news coverage for an unplanned interesting event, residential area

noise mapping, urban mood in ference, trail condition updates after storms, dynamically updated street side

imagery overlays for maps, and other enterprize applications that use the audio-visual feeds to compute

metrics of interest for various business dashboards. Other works have also considered building sensor

networks using mobile phones . Sensor networks where the sensor nodes are mobile and carried by people or

vehicles have also been proposed .

Fig. 7: A shared sensor network of mobile phones

22

Bubble Sensing

7.1 Code In The Air

Smartphones and other mobile devices now come equipped with an impressive array of sensors: multiple

position sensors (GPS, WiFi, cellular radios), inertial sensors (accelerometers and gyroscopes), magnetic

compass, microphone, light sensors, proximity sensors, and many more. These capabilities provide

smartphones the ability to discover more about users and their activities than any other commodity computing

device ever invented. Application developers have recently started taking advantage of these powerful

capabilities, leading to the first signs of a new class of tasking applications. These applications process data

from multiple sensors, in a continuous fashion, to determine the user’s context and activity, and take actions

when certain conditions are met. They usually operate with almost no user input, and may require applications

to coordinate their state with external conditions (e.g., turn off the ringer if I’m inside a movie theater) or with

the state of other devices (e.g., send my phone a message if my spouse leaves work by 5 pm). Tasking

applications are starting to get popular with end users [3, 8]. For example, Apple has integrated location-based

reminders into its latest iPhone OS (iOS5) [4]. Our goal is to make it easy to develop and run new tasking

applications. We believe that most tasking applications are relatively easy to state, often in a few words as

“condition/ action” rules, but are extremely difficult to implement today. In fact, this hypothesis is borne out by

existing products, which only come with a set of pre-defined conditions and actions that users can configure,

but cannot extend or personalize effectively.Current approaches suffer from two problems:

1. Poor abstractions: Today, writing tasking applications requires grappling with low-level sensor data. Even

something as easy to express as “is the user riding a bicycle” is difficult because one needs to process data

from position, accelerometer, and/or gyroscope sensors to make this determination. An ideal solution would

allow developers, and even end users, to use (and reuse) an isBiking primitive.

2. Poor programming support : Tasking applications are often inherently distributed. Writing them

involves both server-side and smartphone code, and figuring out how to partition that code. A better approach

for this type of application would be a macroprogramming approach, which only requires developers to write

server-side code, with an execution framework that automatically partitions the code across one or more

smartphones and the server. Additionally, a development framework that also supports end users, who have

no interest or ability to write tasking code, is desirable. Such users should be able to combine existing

capabilities to specify their own tasks. In this way, a user need not be dependent on, or wait for, a developer to

create the task. These shortcomings are addressed by Code In The Air (CITA), a system that lowers the barrier

for programming and executing tasking applications. CITA helps two groups of people:

• Developers: who can create tasks by writing only serverside code, even for tasks that involve multiple end

usersand their devices, a variety of sensors, and the server. In our current implementation, these tasks are

written in JavaScript.

23

Bubble Sensing

• End users: who are able to specify their own tasks by “mixing and matching” available activities and tasks

via a web UI (or a smartphone UI).

The CITA architecture, shown in Fig.8 has three interesting components. First, the tasking framework (in

green) allows developers to write task scripts, compiles them into server-side and mobile code, and manages

the task execution run-time on mobile devices. CITA provides a JavaScript interface in which developers can

manipulate different phone devices as objects within a single program. The CITA backend automatically

partitions the code, deals with device coordination, and efficiently executes code on the devices. Second, the

activity layer (in red) raises the abstraction for tasks from “sensor data hacking” to “activity composition”

by providing extensible modules for higher-level activities (isBiking, isDriving, isOutside, enterPlace,

leavePlace, and many more). The activity layer provides accurate, energyefficient activity recognition. Third,

the efficient push communication service (in blue) improves on the energy and load shortcomings of existing

systems like the iOS and Android push services. Using CITA, a variety of tasks become easier to express and

run. These include single-device tasks (e.g., don’t connect to WiFi when I’m outside and moving), multi-user

tasks (make my phone silent when I’m meeting with my boss), tasks with complex activities (map my path

when I bike or run but not when I drive or ride the bus), and multi-device tasks (put my laptop to sleep if I’ve

not been in the same room for more than 15 minutes).

Fig. 8 Code In The Air Architecture

24

Bubble Sensing

7.2 Online Sensing Task Optimization for Shared Sensors

Sensing systems now allow sensors to be shared among multiple users and applications . Open interfaces

using the Internet protocol and web services have been prototyped to facilitate such shared access to sensors.

Multiple applications can use such sensing infrastructures to provide new functionalities using live sensor data.

Also, within a single application, multiple users can access different data based on their needs. As the numbers

of applications and users within applications grow, the amount of data to be provided from the sensors and the

amount of computation performed on that data go up. This increases the load on the sensing infrastructure,

limiting the number of allowable concurrent application requests. “Hot” sensors, i.e., ones that contain events

of interest to several users, are likely to become especially overloaded. Consider, as an example, the road traffic

sensors deployed by the Department of Transportation on several roads, to measure the volume and average

speed of traffic for the covered road segments. In a shared system, multiple sensing applications, such as

driving directions computation, traffic characterization , congestion prediction, cab fleet management, or urban

planning tools, may obtain data streams from these sensors. In existing systems each application obtains data

directly from sensors and performs computations in isolation, which is not efficient. As an illustration of a

specific application using these sensors, consider the following. A commuter wishes to avoid getting stuck in

traffic on her way home from work. To choose a good departure time, she wants to calculate the average travel

time on a route covering k road segments every 15 minutes in a time window extending from 3pm to 7pm,

and then take the minimum over all of these, repeating for each day of the work-week. Similar data collection

and computation tasks may also be submitted by many other commuters within the same city. The routes

specified in the tasks may contain common road segments and have overlapping departure time windows.

Clearly, fetching data from a sensor only once for multiple tasks will help resource constrained sensors avoid

expensive communication, and computing the route latencies for shared segments along routes will allow the

infrastructure to support a larger number of users. It is thus important to eliminate the computational and

communication overlap among application requests, to make the system more scalable and to avoid excess

load on hot sensors. As a large number of applications start accessing shared sensors, the efficiency of resource

usage at the embedded nodes and in the network infrastructure supporting them becomes a concern. To

address this, we develop methods that detect when common data and common stream processing is requested

by multiple applications, including cases where only some of the data is shared or only intermediate

processing steps are common. The communication and processing is then modified to eliminate the

redundancies. Specifically, we use an interval-cover graph to minimize communication redundancies and a

joint data flow graph optimization to remove computational redundancies. Both methods operate online and

allow application requests to be dynamically added or removed.

25

Bubble Sensing

7.3 NotiSense : An Urban Sensing Notification System to Improve Bystander

Privacy

The growth in popularity of hand-held mobile devices has fuelled research exploring how to harness the

collective abilities of sensors attached to these devices. One area of development has been urban sensing,

which explores building a crowd-sourced wireless sensor network using consumer mobile devices. Urban

sensing participants use their devices to capture information about their surroundings to contribute to an urban

sensing system. Existing research has explored protecting the privacy of the urban sensing participants,through

anonymization and aggregation of collected data. We are interested in the privacy ofbystanders who may be

inadvertently affected by nearby urban sensing data collection. There are difficult aspects to this problem, as

we must weigh the privacy of bystanders against the privacy of urban sensing participants. We describe

NotiSense, a simple system that provides useful notications of nearby sensing activities to those who choose to

subscribe. We evaluate a prototype implementation of NotiSense and its use of Wi-Fi to provide notications.

NotiSense is a good approach to enhancing the privacy of bystanders and opens up interesting challenges for

future work.

The privacy of bystanders is potentially impacted the most in implementations that involve constant recording

of data from the surrounding environment. One example of an ur-ban sensing application that could cause

such privacy prob-lems is BikeNet[4], which employs a large collection of sen-sors to measure not only

cyclists' personal states (e.g., heart rate, wheel speed) but their cycling experiences (e.g., noise level, pictures of

a route) and upload the sensed data to a repository. Biketastic[13] follows a similar approach, but uses only the

sensors available in a mobile phone for sensing. In these applications, the sensed and uploaded data, such as

video and audio data, may include information about by-standers and violate their privacy.

Fig. 9 Noti-Sense's system architecture

26

Bubble Sensing

As shown in Figure 9, NotiSense adds three important components to a traditional urban sensing architecture.

No-tiSense relies on metadata from urban sensing systems, which is collected from urban sensing tasks and

consenting urban sensing participants. Since the raw metadata from many urban sensing systems could be too

large for mobile devices to periodically download, NotiSense clients rely on filter servers to avoid transferring

entire data sets. Finally, some urban sensing participants broadcast short-range wireless signals

that are identifiable by NotiSense clients.

27

Bubble Sensing

Conclusion

The concept of crowd-sourcing has recently received tremendous attention especially to solve large scale

problem composed of small subtasks. We present a first attempt towards understanding and realizing a

programmable sensor network that uses the large deployed base of mobile devices as its sensing infrastructure.

Several challenges need to be addressed in building such a system. 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 both simulation and a real test bed experiment. There has been a significant amount of research

relating to the privacy of participants in urban sensing systems, but they are not the only parties whose privacy

may be impacted. Bystanders who are in an area where sensing is occurring may have some aspect of their

state captured without their knowledge. We have proposed NotiSense, a simple system that can provide useful

notifications about nearby urban sensing to those who subscribe. Our prototype uses the Wi-Fi SSID as a

privacy beacon from urban sensing participants. This can be detected by NotiSense clients without

establishing a two-way connection. NotiSense is a simple approach to the issues we have identied, but many

challenges remain.

28

Bubble Sensing

References

[1] 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, vol. 6, no. 2, pp. 20-29, Apr-Jun, 2007.

[2] J. Burke, D. Estrin, M. Hansen, A. Parker, N. Ramanathan, S. Reddy, M. B. Srivastava. Partcipatory

Sensing. In Proc. of 1st Workshop on Wireless Sensor Web (WSW’06), pp. 1–5, Boulder, October 31, 2006.

[3] A. T. Campbell, S. B. Eisenman, N. D. Lane, E. Miluzzo and R. A. Peterson. People-Centric Urban

Sensing (Invited Paper). In Proc. of 2nd ACM/IEEE Int’l Conf. on Wireless Internet, Boston, Aug 2-5, 2006.

[4] K. Chang, N. Yau, M. Hansen, and D. Estrin. SensorBase.org A Centralized Repository to Slog Sensor

Network Data. In Proc. Of the Int’l Conf. on Distributed Computing in Sensor Networks/Euro-

American Workshop on Middleware for Sensor Networks, San Francisco, Jun 2006.

[5] N. Eagle and A. Pentland. Reality Mining: Sensing Complex Social Systems. In Journal of Personal and

Ubiquitous Computing, Jun 2005.

[6] S. B. Eisenman, E. Miluzzo, N. D. Lane, R. A. Peterson, G.-S. Ahn, and A. T. Campbell. The BikeNet

Mobile Sensing System for Cyclist Experience Mapping. In Proc. of 5th ACM Conf. on Embedded

Networked Sensor Systems, Sydney, Nov 6-9, 2007.

[7] S. B. Eisenman and A. T. Campbell. “SkiScape Sensing”. In Proc. Of ACM 4th Intl Conf. Embedded

Networked Sensor Systems, 2006.

[8] A. Kansal, M. Goraczko, and F. Zhao. Building a sensor network of mobile phones. In Proc. of 6th Int’l

Conf. on Information Processing in Sensor Networks, Cambridge, Apr 25-27, 2007.

[9] I. Leontiadis and C. Mascolo. Opportunistic spatio-temporal dissemination system for vehicular networks.

In Proc. of 1st Int’l Mobisys Workshop on Mobile Opportunistic Networking, San Juan, Jun 11 2007).

[10] J. Lester, T. Choudhury, and G. Borriello. A Practical Approach to Recognizing Physical Activities. In

Proc. of Pervasive, Dublin, May 2006.

[11] S. Ratnasamy, B. Karp, L. Yin, F. Yu, D. Estrin, R. Govindan, and S. Shenker. GHT: A Geographic

Hash Table for Data-Centric Storage in SensorNets. In Proc. of 1st ACM Int’l Workshop on Wireless Sensor

Networks and Applications, Atlanta, Sep 2002.

[12] K. Romer, C. Frank, P. Jose Marron, and C. Becker. Generic role assignment for wireless sensor

networks. In Proc. of 11th ACM SIGOPS European Workshop, pp 7–12, Leuven, Sep 2004.

[13] CPUMonitor 1.10 for S60v3. http://www.nokiapower.com/index.php? showtopic=7542.

[14] G. M. Djuknic and R. E. Richton. Geolocation and Assisted GPS. IEEE Computer, Vol. 34, No. 2, pp.

123-125, Feb, 2001.

29

Bubble Sensing

[15] 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 and B. N. Schilit. Place Lab: Device Positioning Using

Radio Beacons in the Wild. In Proc. of Pervasive, pp. 116-133, 2005.

[16] K. Aberer, M. Hauswirth, and A. Salehi. Infrastructure for data processing in large-scale interconnected

sensor networks. In International Conference on Mobile Data Management, May 2007.

[17] J. Cocke. Global common subexpression elimination. In Proceedings of symposium on Compiler

Optimization, 1970.

[18] A. Dunkels. Full TCP/IP for 8-bit architectures. In ACM MobiSys, 2003.

[19] S. B. Eisenman, E. Miluzzo, N. D. Lane, R. A. Peterson, G.-S. Ahn, and A. T. Campbell. The bikenet

mobile sensing system for cyclist experience mapping. In Sensys, 2007.

[20] M. C. Golumbic. Algorithmic Graph Theory and Perfect Graphs (Annals of Discrete Mathematics, Vol

57). North-Holland Publishing Co., Amsterdam, The Netherlands, The Netherlands, 2004.

30