mobile - Interactive Computing Lab
Download
Report
Transcript mobile - Interactive Computing Lab
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