CarTel (“Car Telecommunications”) : A Distributed Mobile Sensor Computing System A Review by Zahid Mian WPI CS525D

Motivation M OBILE S ENSOR N ETWORKS –T ECHNOLOGY P USH – TECHNOLOGY P ULL H ETEROGENEOUS S ENSOR D ATA S TATIC S ENSORS E ITHER E XPENSIVE O R C UMBERSOME P APER A LITTLE D ATED (2006) –M ORE R ECENT 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 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 b 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.