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
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.
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.
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 3: Bubble-Sensing6
3.1 Introduction 3.2 Bubble Creation 3.3 Bubble Maintenance 3.3.1 3.3.2 Location Based Mobility Based
Chapter 4: Implementation........................................................................11
4.1 Programming Language 4.2 Communication 4.3 Sensors and Classifiers 4.4 Localization 4.5 System Integration
Chapter 6: Simulation..................................................................................18
6.1 Experiment Setup 6.2 Results
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.
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
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.
GPS Module
Bubble Sensing
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.
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.
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.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.
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.
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
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.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.
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
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
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.
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
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
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).
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.
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
28
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