Anda di halaman 1dari 36

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

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 (Seminar guide)

Prof. Mrs. S.S. Paygude (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 bubblesensing 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 1.2 Introduction Sensors in Smartphones 1.2.1 1.2.2 1.2.3 1.2.4 1.2.5 1.2.6 Microphone Accelerometer Ambient Light Sensor Proximity Sensor Gyroscope 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 3.3.2 Location Based 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

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.

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

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

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.

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.

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

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

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.

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/locationdetection 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

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 builtin/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 locationbased 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 mobilitybased 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 timeclustered 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/EuroAmerican 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

Anda mungkin juga menyukai