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
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.
Roadside base station
Inter-vehicle
communications
Vehicle-to-roadside
communications
VSN-enabled vehicle
Sensors
Video
Chem.
Systems
Storage Proc.
Vehicular Sensor Applications

Traffic engineering



Environment monitoring


Road surface diagnosis
Traffic pattern/congestion analysis
Urban environment pollution monitoring
Civic and Homeland security


Forensic accident or crime site investigations
Terrorist alerts
Outline








Scenario
Problem Description
Mobility-assist Meta-data Diffusion/Harvesting
Diffusion/Harvesting Analysis
Simulation
Security Issues
Conclusion
Future Work
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)
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
- Sensing
- Processing
Summary
Harvesting
CRASH
Crash Summary
Reporting
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]
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”
MobEyes Architecture



MSI : Unified sensor interface
MDP : Sensed data processing s/w (filters)
MDHP : Opportunistic meta-data diffusion/harvesting
Raw Data
Storage
MDP (Data Processing)
Summary
Database
MSI (Sensor Interface)
JMF API
Java Comm.
API
Java Loc.
API
MDHP
(Diffusion/Harvesting)
J2SE
A/V
Sensors
Bio/Chem
Sensors
GPS
DSRC Compliant Driver
Radio Transceiver
Mobility-assist Meta-data
Diffusion/Harvesting


Let’s exploit “mobility” to disseminate meta-data!
Mobile nodes are periodically broadcasting metadata 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)
Mobility-assist Meta-data
Diffusion/Harvesting
HREP
HREQ
Agent harvests a set of missing meta-data from neighbors
Periodical meta-data broadcasting
+ Broadcasting meta-data to neighbors
+ Listen/store received meta-data
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 ni advertises a single summary si
Diffusion Analysis

Expected number (α) of nodes within the radio range

ρ : network density of disseminating nodes
v : average speed

R: communication range

2R

s=vΔt
Expected number of summaries “passively” harvested
by a regular node (Et)

Prob. of meeting a not yet infected node is 1-Et-1/N
Harvesting Analysis


Agent harvesting summaries from its neighbors
(total α nodes)
A regular node has “passively” collected so far Et
summaries



Having a random summary with probability Et/N
A random summary found from α neighbor nodes
with probability 1-(1-Et/N)
E*t : Expected number of summaries harvested by
the agent
Numerical Results

Numerical analysis
Area: 2400x2400m2
Radio range: 250m
# nodes: 200
Speed: 10m/s
k=1 (one hop relaying)
k=2 (two hop relaying)
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
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)
Real-track Mobility
Fraction of received meta-data
Manhattan Mobility
Time (s)
Time (s)
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)
Real-track Mobility
Fraction of actively
harvested meta-data
Manhattan Mobility
Time (s)
Time (s)
Simulation
k-hop relaying and multiple-agents (RT)
Fraction of harvested summaries

Time (seconds)
Simulation

k-hop relaying and multiple-agents (RT)
Conclusion

Mobility-assist data harvesting protocol




Non-intrusive
Scalable
Delay-tolerant
Performance validation through mathematical
models and extensive simulations
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
Outline






System Architecture
Intermittently connected DB (ICEDB)
Carry-and-forward network (CafNet)
Portal
Applications
Discussion
CarTel System Architecture
Portal
Clients
ICEDB Server
Answers local snapshot queries
Logs continuous query results
Prioritizes data
CafNet
Delay-tolerant relay via WiFi
User’s wireless
Access Point
Open wireless
Access Point
ICEDB Remote
Adapters log GPS, OBD, camera data
Data sent via prioritized continuous queries
CarTel S/W Architecture
Web Server
Portal
Portal Applications
Traffic
Speed/
Delay
OBD-II
WiFi
Monitor
ICEDB
Server
CQ
CafNet Stack
Streaming
Sensor Data
Cont. queries
+ adaptors
Camera
Portal
Data Visualization
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
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
Intermittently connected DB
(ICEDB)
REMOTE
DB
ICEDB Remote
CafNet Stack
Adapter
GPS
Adapter
OBDII
Adapter
Camera
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 bandwidthconstrained network

Intermittent connectivity due to high speed
mobility and restricted mobility patterns
Carry-and-forward Network
(CafNet)

CafNet communication stack
Where should
Buffers be placed?
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
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”)
Portal

Trace visualizer
Case Studies

Road traffic analysis




Commute time analysis
Traffic hot spot heuristics
Wide-area Wi-Fi measurement
Automotive diagnostics via OBD-II
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