CarTel (“Car Telecommunications”):A Distributed Mobile Sensor Computing

System

A Review by Zahid MianWPI CS525D

Motivation

• MOBILE SENSOR NETWORKS– TECHNOLOGY PUSH– TECHNOLOGY PULL

• HETEROGENEOUS SENSOR DATA• STATIC SENSORS EITHER EXPENSIVE

OR CUMBERSOME• PAPER A LITTLE DATED (2006)

– MORE RECENT REVISION

Not Just Traffic Monitoring

• Environmental• Civil Infrastructure• Automotive Diagnostics• Geo-Imaging• Data Muling

Goals of CarTel

• Simple API for Using Development• Handle heterogeneous Data

– Various types of sensors• GPS, Cameras, Chemical

– Various Data Demands (cameras)– Handle Intermittent Connectivity

• Especially for cars on highways

Components of CarTel

The Portal - Overview

• Hosts the Applications• Point of Control• Configuration of Entire System• “Sink” for all data

The ICEDB - Overview

• Intermittently Connected Database• Point of Control• Configuration of Entire System• “Sink” for all data

CafNet (Carry and Forward Network)

• Can’t use traditional “streaming” – needs “delay-tolerant”

• Queries define:– What data must be acquired– At what rate– How data should be sampled– How it should be summarized at Node– What priority order results should be sent back

• Queries results streamed across “network”• Data Inserted into SQL DB

ICEDB Details

• Data Model– ID, Name, Type (push/pull), Rate, Forwarding

flag, Schema (name, type tuple), Priority• Continuous Query Model

– Nodes “continuously” send results based on query• SELECT … FROM … WHERE … RATE 5 mins

– Local vs. Global Prioritization • Allows Nodes to prioritize data into buffers to

send

ICEDB Details

• Local Prioritization– Nodes determine what to send based on

available data– No “guidance” or feedback from portal– DELIVERY ORDER clause is more dyanmic

• Instead of column names, use a function• E.g. “Bisect Points”

ICEDB Details

• Global Prioritization– Uses SUMMARIZE clause– Node first sends summary of data to portal– Portal uses some function to determine order– Portal provides feedback to node about order of

details– E.g. if node tuple<lat, lon, roadname, speed>

• Portal could ask for details based on some order of roadname – maybe those roads that are least represented

CafNet Layers

Simply informs app when connectivity is available or changes; delivery confirmation*;

All media-dependent tasks; write/reads; TCP connections; peer discovery

Handles routing; may buffer messages or optimization **

The Portal--Details

• The Portal Framework• The ICEDB server (to retrieve data)

– Users submit queries– ICEDB pushes queries to nodes

• Data Visualization Library (to display)– Users can view results in

The Portal – Web Interface

User can Navigate one of their own “Trace” data

Heterogeneous Sensors

• “Dynamically” Add Different Sensors to System

• Use “Adapter” pattern– Nodes can receive modules remotely– For newer sensors, send new adapter

component– Similarly, updated adapter when needs

change• Application Defines Adapter

Node Implementation

• Linux • 802.11b wi-fi card• Antenna • PostgreSQL DB• Adapters for sensor type • Use cigarette lighter for power• Software Partitioned into small packages

– Easier to update (via CafNet)

Case Study – Road Traffic Analysis

• Using a GPS adapter, captured daily commute times

• User thought highway was the worst option; Frontage road was probably best

• Data showed highway was best option; Frontage worst

• Can the system answer: “How long will it take to get from point A to B?”

Case Study – Traffic Hot Spot• Knowing main “traffic hot spots” is useful• Compute Traffic Hot Spots

– Collect GPS data once/sec– Calc σ of velocity of each car– Filter out insufficient samples– Mark Top 10 spots with greatest σ

Case Study – Image Acquisition• Capture pictures of landmarks for improving

“turn-by-turn” directions• Use CarTel to capture pictures

– Use Adapters to enhance picture processing at node

Wi-fi Measurements

• Use CarTel to capture mobile Wi-fi measurements

32K APs

5K Assoc

2K IP Acquired

At speeds of upto 60 km/hour

Analyzing Driving Patterns

• Correlation between emission levels and both speed and acceleration?

On-Board Diagnostic Data

• Use OBD-II interface– Emissions, engine status, fuel consumption

• Logged over 60K records – Troubleshooting codes, engine load, fuel

consumption, pressure, engine RMPs, engine timing, car intake temp, engine throttle position, and oxygen sensor status

• Use Data for Further Analysis

Related Works

• Mobile Networks– Use of Robots, ZebraNet

• Delay-tolerant Networking– CarTel Integrates Existing Technologies

• Query Processing– In-network query processing– Dynamic prioritization

• Road Traffic Monitoring– TrafficLab, JamBayes, PATH

Updates to CarTel

• iCarTel2 iPhone App• 27-Vehicle Testbed (PlanetTran) in Boston• Pothole Patrol

– algorithms to automatically monitor and classify road surface conditions

• Updated Network Stack– Cabernet (use fast wifi connectivity; within 400ms)– dpipe (delay-tolerant pipe)

• Privacy Protocols (for smartphones)– Vpriv (location privacy) & PrivStats (provable/acct)

Conclusion

• Goal of Collecting Data from Disparate sensors met

• Enough # of nodes in testbed?– Good enough for some data

• Smartphones may alter tech– SP Good for GPS data; not for other sensors

• Good Research on Intermittent Connectivity, Node Processing, etc.