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

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

2. 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

3. Not Just Traffic Monitoring • Environmental • Civil Infrastructure • Automotive Diagnostics • Geo-Imaging • Data Muling

4. 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

5. Components of CarTel

6. The Portal - Overview • Hosts the Applications • Point of Control • Configuration of Entire System • “Sink” for all data

7. The ICEDB - Overview • Intermittently Connected Database • Point of Control • Configuration of Entire System • “Sink” for all data

8. 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

9. 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

10. 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”

11. 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

12. CafNet Layers Simply informs app when connectivity is available or changes; delivery confirmation*; Handles routing; may buffer messages or optimization ** All media-dependent tasks; write/reads; TCP connections; peer discovery

13. 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

14. The Portal – Web Interface User can Navigate one of their own “Trace” data

15. 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

16. 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)

17. 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?”

18. 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 σ

19. 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

20. Wi-fi Measurements • Use CarTel to capture mobile Wi-fi measurements At speeds of upto 60 km/hour

21. Analyzing Driving Patterns • Correlation between emission levels and both speed and acceleration?

22. 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

23. Related Works • Mobile Networks • Use of Robots, ZebraNet • Delay-tolerant Networking • CarTelIntegrates Existing Technologies • Query Processing • In-network query processing • Dynamic prioritization • Road Traffic Monitoring • TrafficLab, JamBayes, PATH

24. 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)

25. 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.