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  Publish-Subscribe Model 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 real-time 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

Data Dissemination Goal: to exchange traffic information among a set of moving vehicles Two approaches:  Flooding Each message received is stored and forwarded Not scalable  Diffusion Each message received is stored, and forwarding is defered to the next broadcast period Scalable – Limited number of broadcast messages TrafficView uses diffusion model of data dissemination

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

Reliable communication What happens when a wifi link fails?  Use alternate communication links, eg. GPRS/3G when network partitions When to switch between the two?  Wifi – high bandwidth, low latency, free, but unreliable  GPRS/3G – low bandwidth, high latency, expensive, but reliable Solution - an intelligent hybrid data-link layer which switches between these two medium based on  network conditions  application demands

Publish-Subscribe Model Goal - To provide reliable information exchange Entities:  Publisher – Content Generators  Subscriber – subscribe to hosted content, by specifying the topic or content of interest.  Broker – provide storage and management of subscriptions and messages Guiding Principle - Decouple publishers and subscribers in space, time and flow  Communication is anonymous, asynchronous and loosely coupled Broker Publisher Subscriber

Where does the broker reside? Naïve Approach – Brokers reside on the web, vehicles subscribe with these web brokers  Not scalable Alternate Approach – Brokers reside on the adhoc network (elected leader of a group of vehicles)  Limited by mobility of vehicles

Solution - Hybrid Architecture Our approach - hybrid publish/subscribe framework  Brokers exist in the ad hoc network as well as the internet  Vehicle subscriptions are grouped not only based on content but also location of vehicles Minimizes bandwidth usage while providing reliability

How to maintain Broker? Broker Discovery and Subscription Initiation Broker Election  Reachability  Cellular link availability  Proximity to neighboring connected graph Broker Hand-off and Intercommunication Location-based subscription aggregation

Network Stack Architecture

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 Shankar, Mohammad Tanvir Alam, Stephen SmaldonePravin Shankar, Mohammad Tanvir Alam, Stephen Smaldone, Nishkam RaviNishkam Ravi Collaborators Cristian Borcea, Marios Dikaiakos, Tamer Nadeem