1. MobEyes: Smart Mobs for Urban Monitoring with Vehicular Sensor Networks* Uichin Lee, Eugenio Magistretti, Mario Gerla, Paolo Bellavista, Antonio Corradi Network Research Lab CS, UCLA * Uichin Lee, Eugenio Magistretti, Biao Zhou, Mario Gerla, Paolo Bellavista, Antonio Corradi "MobEyes: Smart Mobs for Urban Monitoring with a Vehicular Sensor Network," IEEE Wireless Communications, 2006

2. Vehicular Sensor Network (VSN) Onboard sensors (e.g., video, chemical, pollution monitoring sensors) Large storage and processing capabilities (no power limit) Wireless communications via DSRC (802.11p): Car-Car/Car-Curb Comm.

3. Vehicular Sensor Applications Traffic engineering  Road surface diagnosis  Traffic pattern/congestion analysis Environment monitoring  Urban environment pollution monitoring Civic and Homeland security  Forensic accident or crime site investigations  Terrorist alerts

4. Outline Scenario Problem Description Mobility-assist Meta-data Diffusion/Harvesting Diffusion/Harvesting Analysis Simulation Security Issues Conclusion Future Work

5. Smart Mobs for Proactive Urban Monitoring with VSN Smart mobs: people with shared interests/goals persuasively and seamlessly cooperate using wireless mobile devices (Futurist Howard Rheingold) Smart-mob-approach for proactive urban monitoring  Vehicles are equipped with wireless devices and sensors (e.g., video cameras etc.)  Process sensed data (e.g., recognizing license plates) and route messages to other vehicles (e.g., diffusing relevant notification to drivers or police agents)

6. Accident Scenario: Storage and Retrieval Private Cars:  Continuously collect images on the street (store data locally)  Process the data and detect an event (if possible)  Create meta-data of sensed Data -- Summary (Type, Option, Location, Vehicle ID, …)  Post it on the distributed index The police build an index and access data from distributed storage

7. Problem Description VSN challenges  Mobile storage with a “sheer” amount of data  Large scale up to hundreds of thousands of nodes Goal: developing efficient meta-data harvesting/data retrieval protocols for mobile sensor platforms  Posting (meta-data dissemination) [Private Cars]  Harvesting (building an index) [Police]  Accessing (retrieve actual data) [Police]

8. Searching on Mobile Storage - Building a Distributed Index Major tasks: Posting / Harvesting Naïve approach: “Flooding”  Not scalable to thousands of nodes (network collapse)  Network can be partitioned (data loss) Design considerations  Non-intrusive: must not disrupt other critical services such as inter-vehicle alerts  Scalable: must be scalable to thousands of nodes  Disruption or delay tolerant: even with network partition, must be able to post & harvest “meta-data”

9. MobEyes Architecture MSI : Unified sensor interface MDP : Sensed data processing s/w (filters) MDHP : Opportunistic meta-data diffusion/harvesting

10. Mobility-assist Meta-data Diffusion/Harvesting Let’s exploit “mobility” to disseminate meta-data! Mobile nodes are periodically broadcasting meta- data of sensed data to their neighbors  Data “owner” advertises only “his” own meta-data to his neighbors  Neighbors listen to advertisements and store them into their local storage A mobile agent (the police) harvests a set of “missing” meta-data from mobile nodes by actively querying mobile nodes (via. Bloom filter)

11. Mobility-assist Meta-data Diffusion/Harvesting + Broadcasting meta-data to neighbors + Listen/store received meta-data Periodical meta-data broadcasting Agent harvests a set of missing meta-data from neighbors HREQ HREP

12. Diffusion/Harvesting Analysis Metrics  Average summary delivery delay?  Average delay of harvesting all summaries? Analysis assumption  Discrete time analysis (time step Δt)  N disseminating nodes  Each node n i advertises a single summary s i

13. Diffusion Analysis Expected number (α) of nodes within the radio range  ρ : network density of disseminating nodes  v : average speed  R: communication range Expected number of summaries “passively” harvested by a regular node ( E t )  Prob. of meeting a not yet infected node is 1-E t-1 /N 2R s=vΔt

14. Harvesting Analysis Agent harvesting summaries from its neighbors (total α nodes) A regular node has “passively” collected so far E t summaries  Having a random summary with probability E t /N A random summary found from α neighbor nodes with probability 1-(1-E t /N)  E* t : Expected number of summaries harvested by the agent

15. Numerical Results Numerical analysis Area: 2400x2400m 2 Radio range: 250m # nodes: 200 Speed: 10m/s k=1 (one hop relaying) k=2 (two hop relaying)

16. Simulation Simulation Setup  Implemented using NS-2  802.11a: 11Mbps, 250m transmission range  Network: 2400m*2400m  Mobility Models Random waypoint (RWP) Real-track model:  Group mobility model  Merge and split at intersections  Westwood map Westwood Area

17. Meta-data Diffusion Results Meta-data diffusion: regular node passively collects meta-data Impact of node density (#nodes), speed, mobility  Higher speed, faster diffusion  Density is not a factor (increased meeting rate vs. more items to collect)  Less restricted mobility, faster diffusion (Man>Westwood) Manhattan Mobility Real-track Mobility Time (s) Fraction of received meta-data

18. Meta-data Harvesting Results Meta-data harvesting: agent actively harvests meta-data Impact of node density (#nodes), speed, mobility  Higher speed, faster harvesting  Higher density, faster harvesting (more # of meta-data from neighbors)  Less restricted mobility, faster harvesting (Man>Westwood) Manhattan MobilityReal-track Mobility Time (s) Fraction of actively harvested meta-data

19. Simulation k-hop relaying and multiple-agents (RT) Fraction of harvested summaries Time (seconds)

20. Simulation k-hop relaying and multiple-agents (RT)

21. Conclusion Mobility-assist data harvesting protocol  Non-intrusive  Scalable  Delay-tolerant Performance validation through mathematical models and extensive simulations

22. CarTel: A Distributed Mobile S ensor Computing System Bret Hull, Vladimir Bychkovsky, Kevin Chen, Mi chel Goraczko, Allen Miu, Eugene Shih, Yang Z hang, Hari Balakrishnan, and Samuel Madden Sensys 2006

23. Outline System Architecture Intermittently connected DB (ICEDB) Carry-and-forward network (CafNet) Portal Applications Discussion

24. CarTel System Architecture Open wireless Access Point User’s wireless Access Point Adapters log GPS, OBD, camera data Data sent via prioritized continuous queries ICEDB Remote Delay-tolerant relay via WiFi CafNet PortalClients Prioritizes data Answers local snapshot queries Logs continuous query results ICEDB Server

25. CarTel S/W Architecture Portal Data Visualization CafNet Stack CQ Web Server ICEDB Server OBD-II WiFi Monitor Camera Traffic Speed/ Delay Portal Applications Portal Streaming Sensor Data Cont. queries + adaptors

26. Intermittently connected DB (ICEDB) ICEDB server  Maintains a list of continuous queries submitted by applications  Queries are pushed to mobile nodes using CafNets  Results from ICEDB clients are stored in the RDBMS at the portal ICEDB client  Process the sensed data and return the query results using CafNet  Prioritize the result streams in the order of importance

27. Intermittently connected DB (ICEDB) Adaptor (meta-data package)  Defines sensor type and schema (i.e., “interests” in Directed Diffusion)  A typical adaptor includes Unique identifier Adapter type: push/pull Pull rate (each pull invokes a processing script) Forwarding flag Schema (a list of (name, type) pairs for sensed data) Priority CarTel has adapters for node diagnostics, the GPS receiver, the OBD-II interface, the Wi-Fi interface, and the digital camera

28. Intermittently connected DB (ICEDB) REMOTE ICEDB Remote DB CafNet Stack Adapter GPS Adapter OBDII Adapter Camera

29. Intermittently connected DB (ICEDB) Queries in ICEDB are written in SQL with several extensions for continuous queries and prioritization  EX)SELECT carid, traceid, time, location FROM gps WHERE gps.time BETWEEN now()-1 mins AND now() RATE 5 mins Prioritization is required since delivering data in FIFO order is suboptimal in bandwidth- constrained network  Intermittent connectivity due to high speed mobility and restricted mobility patterns

30. Intermittently connected DB (ICEDB) Local prioritization  PRIORITY : Numeric priority over queries  DELIVERY ORDER : determine the priority within a given query buffer (like ORDER BY ) Global prioritization  SUMMARIZE AS : a set of tuples that summarize the entire buffer of result tuples  1) Client sends the summary results to the portal 2) Portal applies a customized order function to order tuples 3) Portal sends this prioritization back to the client  Useful for data aggregation/filtering If there are several nodes collecting similar data about the same location?

31. Intermittently connected DB (ICEDB) P14P13P12P11 P24… Query1 Query2 Query3 Queues PRIORITY DELIVERY ORDER SUMMARY SUMMARIZE AS f SERVER to REMOTE P14P23P33 LOCAL GLOBAL

32. Carry-and-forward Network (CafNet) CafNet communication stack Where should Buffers be placed?

33. Carry-and-forward Network (CafNet) CafNet offers a message-oriented data tx/rx API to apps (not streams like TCP) CafNet Transport Layer (CTL) doesn’t have a buffer; only inform the availability of connectivity to applications  CTL API has one call back function: cb_get_adu() causes the app to synchronously return an ADU for immediate transfer  Delivery options (NONE/END2END) Currently CafNet does not have any routing protocol in the network layer (CNL) (only flooding) Mule adaptation layer (MAL) for connectivity discovery (WiFi, Bluetooth, etc) CafNet with a buffer in order to long latency of generating/packaging data from application  Size of a buffer is important for prioritization

34. Portal Users navigate sensor data in CarTel using a web-based interface Main components of the portal  Portal framework  ICEDB server to retrieve sensor data  Data visualization library to display geo-coded data Trace: all sensor data collected during a single trip (i.e., between ignition “on” and “off”)

35. Portal Trace visualizer

36. Case Studies Road traffic analysis  Commute time analysis  Traffic hot spot heuristics Wide-area Wi-Fi measurement Automotive diagnostics via OBD-II

37. Future Work Data aggregation with privacy Delay prediction of delay-tolerant cont. queries Analysis of OBD data CafNet routing protocol (movement patterns and connectivity prediction model) Mining and statistical analysis of traces