Designing an Inter-Vehicular Network Stack for Car-to-Car Communication Pravin Shankar Department of Computer Science Rutgers University

Outline Motivation – Traffic Safety TrafficView  Overview of System  Data Aggregation/Validation layer  On-demand Traffic Query Future work Conclusion

Some facts on Traffic safety * Since 1975, vehicle safety technology has focused on passive devices:  Seat belts  Air bags  Antilock Brake System However, the number of reported traffic accidents in US has remained relatively constant * based on U.S. Traffic Safety Facts Report

Passive Approach is not Enough What’s in front of that bus ? What’s behind the bend ? On rainy days On foggy days

TrafficView Uses vehicle-to-vehicle ad hoc network Enables active accident-prevention using dissemination of safety messages

TrafficView Overview Infrastructure-free approach based on car- to-car communication Each vehicle has an embedded system  short-range wireless communication  location information from GPS receiver  vehicle’s data from sensors through on-board diagnostic system (OBD-II)

How TrafficView works? Receive data from remote vehicle Non-validated dataset Validate Validated dataset Local data Display Broadcast data

TrafficView Prototype Developed in Java, ported to both Windows and Linux User Interface developed using OpenGL b network card  augmented with 5dBi omni-directional antenna Garmin eTrex GPS receiver TIGER ® road maps from U.S. Census Bureau (publicly available) Tested using 3 cars in real traffic conditions

TrafficView Outdoors

Too much traffic! Vehicles transfer records:  Vehicle ID (ID), position (POS), speed (SPD), broadcast time (BT) Consider a very high-density 5-lane road  Distance between consecutive cars – 5m  Average size of data records – 50 bytes  Wireless transmission range of 250 m 250 vehicles compete for the same wireless medium Total data transmitted every broadcast period = 250 MB Beyond the capabilities of current wireless technology!

Data Aggregation Aggregate data to see vehicles as far as possible with “acceptable” accuracy loss  Combine data for vehicles that are close to each other  Perform more aggregation as distance increases

Data Aggregation Having n records Calculate the aggregated record’s fields: POS and SPD are weighted averages.

Need for Data Validation Out-of-date information  Vehicles move and change speed  Packets may get lost in transit  Information received from OBD* might be invalid  Solution: Data aging Malicious nodes can corrupt data  Inject incorrect data  Refuse to forward data  Modify data  Solution: Probabilistic validation * On-Board Diagnostic Interface

Push v/s Pull Most cars are interested in information about immediate neighboring road segment  “Push” mechanism is sufficient How to get information about other roads? Broadcast is not scalable  Road segments are extensive in size  Traffic information is dynamic in nature There is a need for “pull” i.e. On-Demand traffic query

On-demand Traffic Query Protocol VITP – Vehicular Information Transfer Protocol  Location-sensitive queries and replies between nodes of a VANET  VITP Peers – nodes that operate as Clients Intermediates Servers  Agnostic of network communication layer

Location-sensitive queries Gas Station Coffee place GSM Link Traffic Server

Virtual Ad-Hoc Servers (VAHS) The server that computes the reply is a dynamic collection of VITP peers that:  Run on vehicles moving inside the target-location area of Q.  Are willing and able to participate in Q’s resolution. Gas Station Q

VAHS (continued) Established on the fly in an ad-hoc manner Identified with a query and its target-location area. Maintains no explicit knowledge (state) about its constituent VITP peers Follows a best-effort approach in serving queries VAHS members maintain no information about other members of the VAHS.

VITP transactions VITP Peer VANET node VAHS Q Q Intermediary nodes Q1 Q2 Q3 Q4 Q5 Q6 Q7 R R R Dispatch-query phaseVAHS-computation phase Dispatch-Reply phase Reply-delivery phase

Return Conditions (RC) Determine at which point in time the resolution of a VITP request can be considered done (VAHS computation completes). RC decision depends upon:  Query semantics: RC must be defined explicitly in the query specification.  Timeout condition: either pre-set by higher-level application semantics or default.

Other protocol features Support for caching. Message identifiers. Privacy protection. Dissemination vs. pull-based retrieval.

VITP – Message Format METHOD VITP/ Target: [rd_id_dest,seg_id_dest] From: [rd_id_src,seg_id_src] with Time: Expires: Cache-Control: TTL: msgID: Content-Length: CRLF

VITP URI Format / / ?[ &…]& &… type: classes of physical-world entities involved in the request (vehicle,service). tag: actual information sought (traffic, alert, gas, index). Example VITP requests: GET /vehicle/traffic?[cnt=10&tout=2000ms]&tframe=3min GET /service/gas?[cnt=4&tout=1800ms]&price<2USD POST /vehicle/alert?[cnt=*&tout=*]&type=slippery-road

Future work Reliable multicast – content delivery on VANETs  Provide support for rich multimedia on cars Outdoor Experiments  Perform experiments in real traffic conditions in order to better understand VANET characteristics Mobility emulation Traffic modelling Privacy Issues Deployment on real systems

Related Work Car Manufacturers  GM-CMU -  Daimler-Chrysler -  MIT CarTel, Berkeley PATH, PSU CITrans, etc. Europe  Fleetnet  Network-On-Wheels  Car 2 Car Communication Consortium - Japan  Toyota InfoTechnology Center -  Tokyo University, Keio University And many more…

Thank you! Work supported in part by NSF Collaborative Research: NeTS-NBD: (ANI ) grant and NSF Information Technology Research (ANI ) grant.. Faculty Liviu Iftode Graduate Students Pravin ShankarPravin Shankar, Stephen Smaldone, Nishkam RaviStephen SmaldoneNishkam Ravi Collaborators Cristian Borcea, Marios Dikaiakos, Tamer Nadeem, Yanzhi Bai, Josiane Nzouonta

E-Road Vision To use ad-hoc vehicular networking to improve the way we drive by supporting  Collaborative traffic information exchange  Emergency/safety message dissemination  On-demand traffic conditions monitoring  Dynamic route planning  Rich multimedia distribution