CarTel is a distributed, mobile sensor network and telematics system. Applications built on top of this system can collect, process, deliver, analyze, and visualize data from sensors located on mobile units such as automobiles and smartphones. In our deployment, a small embedded computer interfaces with a variety of sensors, processes the collected data, and delivers it to an Internet server. Applications running on the server analyze this data and provide interesting services to users.

The system infrastructure includes software and hardware to collect sensor information from cars and smartphones, a content delivery network that uses WiFi from moving vehicles (Cabernet), an intermittently connected continuous query database system (ICEDB), privacy-preserving protocols for location-based services (VPriv), and applications to traffic mitigation (predictive delay modeling and traffic-aware routing) and road surface monitoring (the Pothole Patrol).

We have used CarTel in several applications, including:

• Commute and traffic portal: A Web site that shows all the trips made by a driver and provides interesting ways to visualize one's trips, and tools to analyze this data. Our portal is now available for public use at icartel.net.

• Traffic mitigation using new predictive delay models and traffic-aware route planning algorithms, running atop the rich set of CarTel data from GPS-equipped cars. Contribute to our traffic mitigation efforts by downloading and running our crowd-sourced traffic data collection and traffic-aware route planning iPhone Application.

• P2 (Pothole Patrol), which uses the CarTel infrastructure in conjunction with our applied machine learning algorithms to automatically monitor and classify road surface conditions.

• Fleet testbed, a 27-car CarTel deployment in the cars of a local limo company (PlanetTran). This testbed also serves as the “vehicle” for much of our research, allowing us to deploy software and applications on a running system (in addition, some user's cars also have CarTel nodes).

• Wi-Fi Monitoring, mapping the proliferation of 802.11 access points in the Boston metro area.

• On-board automotive diagnostics & notification: Using the OBD-II interface to monitor and report internal performance characteristics such as emissions, gas mileage, RPM, etc. These reports can be combined with historical data, thus highlighting long-term changes in a car's behavior. Such a system would be able to provide the driver with early trouble notification. In the future, with enough participation, this system could compare and “mine” data across multiple cars of similar make and age to identify anomalies in particular cars (e.g., “all the other cars show a value between X and 1.3X for this sensor, but your car shows a value of X/2, which is suspicious”).

• Cars as mules. We have developed CafNet (“carry and forward network”) protocols that will allow cars to serve as data mules, delivering data between nodes that are otherwise not connected to one another. For example, these protocols could be used to deliver data from sensor networks deployed in the field to Internet servers without requiring anything other than short-range radio connectivity on the sensors (or at the sensor gateway node).

Unlike traditional automotive telematics systems that rely on cellular or satellite connectivity, CarTel uses wireless networks opportunistically. It uses a combination of WiFi, Bluetooth, and cellular connectivity, using whatever mode is available and working well at any time, but shields applications from the underlying details. Applications running on the mobile nodes and the server use a simple API to communicate with each other. CarTel's communication protocols handle the variable and intermittent network connectivity. To simplify application development, CarTel uses two well-known programming abstractions—pipes and databases—adapting them to the intermittently connected, mobile environment.

The CarTel system has three main software components. The portal is the central location that hosts CarTel applications and functions as the point of control and configuration for the distributed system. The portal is also the sink for all data sent from the mobile nodes. To simplify application development, we have developed ICEDB, a delay-tolerant continuous query processor. To transfer data efficiently, we have developed opportunistic wireless network protocols that can connect rapidly (at vehicular speeds) to access points and techniques to cope with intermittent connectivity.

CarTel applications running on the portal can either issue continuous queries using an API exported by ICEDB, or simply ask to transfer a sequence of data items from one node to another akin to a pipe (using dpipe, explained below). Both models are simple and resemble SQL and UNIX pipes, respectively.

CarTel's network subsystem has three useful components that higher layers can choose to use: Cabernet, dpipe, and CafNet.

• Cabernet: CarTel nodes are able to achieve end-to-end connectivity across a changing set of WiFi access points much faster than in current stacks, which makes it possible to use even when the client is in range of an access point for only a few seconds. The bulk of the time can then be spent in data transfer. Cabernet is a software stack that provides these features using QuickWifi (fast Wifi connectivity, within 400 ms or less from moving cars) and CTP, a new transport protocol that is better than TCP at high non-congestive loss rates (as in moving cars using WiFi).

• dpipe: dpipe is a delay-tolerant pipe, a transport abstraction that allows a producer node and consumer node to reliably transport data even across an intermittently connected network. dpipe optimizes for the case when the IP address of an end-point changes often.

• CafNet: CafNet (carry and forward network) is a delay-tolerant stack that enables mobile data muling and allows data to be sent across an intermittently connected network. dpipe subsumes some of its functions now, but dpipe doesn't handle data muling.

ICEDB is a continuous query processor to process streaming data, but differs from traditional stream processing applications in how query results are sent to the querying application (running on the portal). Because network connectivity is variable and intermittent, with ICEDB:

• Queries specify what sensor data must be acquired and at what rate, how the data should be sub-sampled, filtered, and summarized on the mobile node, and in what (dynamic) priority order results should be sent back to the portal.

• Query results stream in across an intermittently connected network, and populate a relational database at the portal.

• Applications issue SQL queries on the portal's relational database to retrieve data they need for further analysis, visualization, etc. These are snapshot queries that run on whatever data is currently available. Applications do not wait synchronously for the results of continuous queries.

Thus, applications can think of the data distributed across the mobile network as being stored locally in a standard SQL relational database, which simplifies how they are written. The programming model is familiar, essentially the same as what web developers today use. ICEDB deals with the underlying complexity of distributing queries to the mobile nodes (where they run in situ), coping with the network's vagaries, and ensuring that the results are available locally.

ICEDB handles heterogeneous sensor data, allowing the set of sensors to be expanded without requiring major software changes on the remote nodes. Each sensor has an adapter running on the node that handles the details of configuring and extracting information from that sensor and converting it into a normalized form. To ease management and deployment, when a new sensor is added, or when the functions of an adapter need to be modified, only the adapter module needs to change.

The portal includes a geo-spatial data visualization system that stores sensor data from cars. It organizes data in terms of traces, which are sets of sensor readings collected during a particular drive. Users are given a simple graphical query interface for selecting the traces they are interested in and visualizing various summaries, statistics, and maps within or across the traces they select.

Click here to see a brief walk-through of the portal.

VPriv protects the locational privacy of users in systems like CarTel. More generally, a variety of location-based vehicular services are currently being woven into the national transportation infrastructure in many countries. These include usage- or congestion-based road pricing, traffic law enforcement, traffic monitoring, ``pay-as-you-go'' insurance, and vehicle safety systems. Although such applications promise clear benefits, there are significant potential violations of the locational privacy of drivers under standard implementations (i.e., GPS monitoring of cars as they drive, surveillance cameras, and toll transponders).

VPriv is a system that can be used by several such applications without violating the locational privacy of drivers. The starting point is the observation that in many applications, some centralized server needs to compute a function of a car's or user's {\em path}—a list of time-position tuples. VPriv provides two components: 1) a protocol to compute path functions in a way that does not reveal anything more than the result of the function to the server, and 2) an out-of-band enforcement mechanism using random spot checks that allows the server and application to handle misbehaving cars or users. Checkout the C++ code at http://mit.edu/ralucap/www/vpriv-code/.

A small yet powerful embedded computer running Linux 2.6 (previously, 2.4), the Soekris net4801, though other similar devices running Linux would also work. This unit has a 586-class processor running at 266 MHz with 128 MB of RAM and 1 GB (or more) of Flash. It has 2 serial ports and a USB 1.1 port for external devices. This expandable unit comes in rugged package.

Reasonably accurate location and time information are critical to most of our applications. We use a commodity GPS unit with a USB interface for this purpose.

Most cars made after 1996 provide access to the internal computer through OBD-II interface. We use an OBD-to-serial adapter from ScanTool.net. This adapter provides a modem-like interface and can be automatically queried over a serial port.

In order to upload collected data and download software updates we use miniPCI WiFi card. The picture shows the WiFi card is plugged into the MiniPCI slot of the embedded computer.

Many of the applications mentioned earlier deploy additional sensors, for vibration, images, etc. The embedded computer in the car also provides Bluetooth connectivity (via a USB dongle) to any external Bluetooth-enabled devices (e.g., cell phone).

A custom-made device built from a commodity WiFi access point with additional enhancements for other sensors.

Currently, the following software packages have been released. Please consult their respective pages for packages and documentation.

• CafNet
• ICEDB

Also, check out our iCarTel iPhone Application

* VTrack: Accurate, Energy-Aware Road Traffic Delay Estimation Using Mobile Phones. Arvind Thiagarajan, Lenin Ravindranath, Katrina LaCurts, Sivan Toledo, Jakob Eriksson, Hari Balakrishnan, Samuel Madden, in Proc. 14th ACM SenSys, Berkeley, CA, November 2009. Paper. Winner of the best paper award.

* Cabernet: Vehicular Content Delivery Using WiFi. Jakob Eriksson, Hari Balakrishnan, Samuel Madden, in Proc. 14th ACM MOBICOM, San Francisco, CA, September 2008. Paper

* The Pothole Patrol: Using a Mobile Sensor Network for Road Surface Monitoring. Jakob Eriksson, Lewis Girod, Bret Hull, Ryan Newton, Samuel Madden, Hari Balakrishnan, in Proc. of the 6th Annual International conference on Mobile Systems, Applications and Services (MobiSys), Breckenridge, U.S.A., June 2008. Paper

* IceDB: Continuous Query Processing in an Intermittently Connected World. Yang Zhang, Bret Hull, Hari Balakrishnan, and Samuel Madden. In Proc. ICDE 2007. Abstract PDF

* A Measurement Study of Vehicular Internet Access Using Unplanned 802.11 Networks. Vladimir Bychkovsky, Bret Hull, Allen Miu, Hari Balakrishnan, and Samuel Madden, in Proc. ACM MOBICOM, 2006. Award paper. Abstract PDF

* CarTel: A Distributed Mobile Sensor Computing System. Bret Hull, Vladimir Bychkovsky, Kevin Chen, Michel Goraczko, Allen Miu, Eugene Shih, Yang Zhang, Hari Balakrishnan, and Samuel Madden, in Proc. ACM SenSys, 2006. Abstract PDF

* The CarTel Mobile Sensor Computing System. Demonstration at ACM SenSys 2006. Best demo award.

* CafNet: A Carry-and-Forward Delay-Tolerant Network. MEng Thesis, MIT EECS, Feb. 2007. Abstract with link to PDF

• Faculty PIs: Hari Balakrishnan, Sam Madden, Daniela Rus

• PhD students: Katrina LaCurts, Bret Hull, Sejoon Lim, Lenin Sivalingam, Arvind Thiagarajan

• MEng and undergrad students: Tural Badirkhanli, Raluca Ada Popa, Paresh Malalur, Jason Gavris

• Collaborators and research scientists: Jakob Eriksson, Sivan Toledo, Lewis Girod, Nikolaus Correll, Andrew Blumberg

• Alumni (past contributors): Jakob Eriksson, Vladimir Bychkovsky, Kevin Chen (MEng), Hongyi Hu (MEng), Michel Goraczko (staff), Allen Miu, Eugene Shih, Yang Zhang.

The CarTel project is funded by the National Science Foundation under grants CNS-0205445, CNS-0520032, and CAREER-0448124 and in part (Cabernet, the CafNet stack, and the WiFi measurement study) by the T-Party Project, a joint research program between MIT and Quanta Computer Inc., Taiwan, and in part by Google.

We are also grateful to Seth Riney of PlanetTran for his help.

To learn more, contact Hari Balakrishnan, Sam Madden, and/or the CarTel team (send a note to cartel at the domain nms.csail.mit.edu).

• Mobile Mesh Networking