1 / 25

NOTICE : An Architecture for the No tification of T raffic I ncidents and C ong e stion

NOTICE : An Architecture for the No tification of T raffic I ncidents and C ong e stion. Dr. Michele C. Weigle Department of Computer Science Old Dominion University (Work done with Dr. Stephan Olariu and Gongjun Yan). Norfolk State University Department of Computer Science Colloquium

Download Presentation

NOTICE : An Architecture for the No tification of T raffic I ncidents and C ong e stion

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. NOTICE: An Architecture for the Notification of Traffic Incidents and Congestion Dr. Michele C. Weigle Department of Computer Science Old Dominion University (Work done with Dr. Stephan Olariu and Gongjun Yan) Norfolk State University Department of Computer Science Colloquium March 1, 2007

  2. EXIT 12 Exit while you still can! From trekearth.com Motivation Give drivers advance warning of upcoming traffic congestion

  3. Outline • Overview of Vehicular Ad-Hoc Networks (VANETs) • Security Issues in VANETs • Our Approach: NOTICE • Simulations • Conclusions

  4. c1 c2 c4 c3 c5 EXIT 12 C1 speed 0 C2 speed 0 C3 speed 0 … Vehicular Ad-Hoc NetworksVANETs • Traffic information • cars report their position and speed to surrounding cars • car may suggest an alternate route • Weather warnings • Collision warning • Platooning • Intersection Assistance

  5. VANETsApproaches • V2V only (zero infrastructure, purely ad-hoc) • require no outside infrastructure or roadside devices • vehicles communicate with each other to determine traffic situation • V2V and V2I • requires some outside infrastructure, often in the form of roadside devices • infrastructure can provide aggregation/processing, encryption key distribution, access to larger network

  6. From “The Security of Vehicular Ad Hoc Networks”, M. Raya and J.-P. Hubaux, SASN 2005 VANETsV2V / V2I Architecture

  7. Security IssuesAdversaries • Greedy Drivers • convince neighbors that congestion is ahead to clear roads • Snoops • driver profiling, tracking • Pranksters • hack things “just for fun” • Industrial Insiders • if mechanics are in charge of uploading software, they can load malicious programs • Malicious Attackers • terrorists, criminals with specific targets in mind Bryan Parno and Adrian Perrig. Challenges in Securing Vehicular Networks, HotNets 2005.

  8. Security IssuesAttacks • Denial of Service (DoS) • overwhelm a vehicle’s resources or jam communication channels • Message Suppression • selectively drop messages, suppress congestion alerts • Fabrication • broadcast false information into network • Alteration • alter existing data, replaying earlier transmissions, disrupt voting mechanisms Bryan Parno and Adrian Perrig. Challenges in Securing Vehicular Networks, HotNets 2005.

  9. Security IssuesApproaches • Digitally sign (encrypt with private key) each message sent by a vehicle • a vehicle is issued a certificate from an authority • certificate verifies vehicle’s public key used for decryption • disadvantage: allows tracking of vehicles • Pre-load many different anonymous key pairs and change keys at certain intervals • disadvantage: malicious user could use the keys to impersonate multiple vehicles Key: Reliably associate a message with physical vehicle

  10. Our ApproachNOTICE • Allow the roadway to associate messages with physical vehicles • Embed intelligent sensor belts in the highway • When a car passes over the belt, it reports its speed to the belt • The belt makes decisions about where congestion is occurring based on reports from cars and other belts speed 55

  11. Event Data Recorder (EDR) tamper-proof records location, speed, etc. Two transceivers one for handshaking, Th one for data transfer, Td Pressure sensors detect passing cars Two transceivers one for handshaking, BTh short range (~1m) one for data transfer, BTd larger range (~3m) NOTICECar Model and Belt Model EDR BTd Td Th BTh

  12. NOTICEBelt-to-Belt Communication • Individual belt in each lane • Connected belts (sub-belts) communicate instantaneously • Non-connected belts do not directly communicate • use cars as data mules • Gives encrypted message to a car to drop off at next belt [avg spd 55] [avg spd 55]

  13. EDR Td Th NOTICEBelt-to-Car Communication - Handshaking • Belt sends “Hello” message to car • ID of belt • frequency channel for further communication,  • one-time shared encryption key,  • Car sends short acknowledgement BTh

  14. EDR Td Th NOTICEBelt-to-Car Communication - Data Transfer • Belt sends query • Car sends message from previous belt • Car sends encrypted (with ) EDR data • Belt sends encrypted (with ) traffic information • Belt sends encrypted message for next belt 3m BTd

  15. EXIT 12 NOTICEInformation Propagation A2 A1 • B1 is aware of traffic slowdown • creates encrypted message with latest traffic statistics • Information is provided to B2 • B2 uploads message onto car destined for C2 • When C2 receives message, it provides it to C1 • C1 notifies passing cars B2 B1 C2 C1

  16. EXIT 12 NOTICEUrgent Mode A2 A1 • B2 uploads message with urgent bit set onto car destined for C2 • Car broadcasts message to other cars for faster delivery • Cars are passing encrypted messages, so no security risk B2 B1 C2 C1

  17. EXIT 12 NOTICERole-Based Communication • Emergency responders can provide information to NOTICE belts • Special encryption key used • Validate incident/congestion inference made by belts

  18. NOTICEEvacuations • Evacuees need information about resources • gasoline, hotels, shelters, etc. • Emergency management centers need method to disseminate information • Enhanced NOTICE can provide this • temporary infrastructure connected to belts for long-range communication • to emergency management centers • for backward propagation during contraflow

  19. NOTICEEvacuations • Cars that have refueled report to nearest belt • Location and time of refuel propagated backwards by temporary infrastructure • Cars needing gas can exit at the appropriate location

  20. NOTICESimulations • Developed a Java-based simulator • based on applet using realistic highway traffic model • http://www.traffic-simulation.de/ • Measured message propagation time • normal mode • car receiving message carries it to the next belt • urgent mode • car receiving message broadcasts it to nearby cars • Traffic intensities from 70 vehicles/hr to 3600 vehicles/hr

  21. NOTICESimulations

  22. NOTICESimulations

  23. Conclusion • NOTICE: An Architecture for the Notification of Traffic Incidents and Congestion • Provides security and privacy • belts can independently corroborate information provided by vehicles • Works in sparse or dense traffic • Extensions for evacuation scenarios

  24. Future Work • Enhance our simulator • wireless channel conditions • Rules for how far to propagate congestion notifications • Rules for how to infer occurrence of traffic incident or congestion • Use with non-intrusive sensor

  25. Michele C. Weigle Department of Computer Science Old Dominion University Norfolk, VA mweigle@cs.odu.edu http://www.cs.odu.edu/~mweigle VANET Research Group @ ODU http://www.cs.odu.edu/~vanet

More Related