A SEMINAR REPORT ON

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

Using Mobile Phones

SUBMITTED BY
Mayur M Shah
TE43067

SEMINAR GUIDE
Prof.Mrs.L.B.Bhagwat

Department of Computer Engineering

MAHARASHTRA INSTITUTE OF TECHNOLOGY
PUNE-411038
2011-2012

i
 MAHARASHTRA ACADEMY OF ENGINEERING & EDUCATIONAL
RESEARCHS
MAHARASHTRA INSTITUTE OF TECHNOLOGY
PUNE.
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 wouldnt 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-Sensing6
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
4.5 System Integration

v
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 browser

1
 Bubble Sensing

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 users 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. Its 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 users exact location. Mobile GPS unit identifies users 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 monitoring
Wireless 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., 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 . 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 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.
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 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 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).

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

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
implementation does not disrupt an ongoing call and also the bubble-sensing application will not get killed by

12
 Bubble Sensing

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

during 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

20
 Bubble Sensing

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 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 users 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 Im 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., dont connect to WiFi when Im outside and moving), multi-user
tasks (make my phone silent when Im 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 Ive
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 (WSW06), pp. 15, 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 Intl 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 Intl 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 Intl
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 Intl 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 Intl 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 712, 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