VII Proof Of Concept Program Summary

1. VII Proof Of Concept Program Summary Scott Andrews VII Consortium 4/29/08

2. VII System Objectives • Provide a mechanism for wirelessly sending and receiving information to and from cars, and between cars to: • Improve safety - Intersections, curves, road incidents, weather, etc • Improve mobility - Traffic flow, road utilization, road maintenance, tolling and congenstion pricing, etc. • Allow for commerce to support operations - private services to offset opeaating costs

3. VII System Overview Service Provider Management Systems Roadside Infrastructure Local Safety Systems Signal Controllers Local Transaction Processors Roadside Sensors Network Users ENOC Data Subscribers Driver Vehicle Interface On Board Equipment RSE’s Advisory Providers Transaction Service Providers Service Delivery Node Certificate Authority GPS Signals DGPS Correction Reference Maps External Data Sources

4. POC Scope • Implement reference design for network and supporting services • Implement reference design for mobile terminal • Perform basic tests to characterize functionality and performance of system • Perform application tests to assess utility and limitations of system

5. POC Project Status • OBEs complete (hardware and software) • Development Test Environment (DTE) network nearly complete • SDNs at Herndon Virginia and Detroit • 23 RSEs deployed • Vehicles integrated • OEM and VIIC fleets

6. POC Project Status (Cont’d) • Applications complete and being tested • V2V (Heartbeat) • Probe Data Collection • Signage • Tolling/Parking • Off Board Navigation • Trip-Path • Publich applications (BAH) • Security functions complete • Being integrated • Initial test phases complete (garage and track)

7. Key General Findings • DSRC works for most applications, but need to be mindful of dynamic wireless environment • Some areas of standards require significant refinement (many refinements developed during POC) • Mating DSRC with wired networks requires extra care (DSRC in-motion does not behave like Ethernet) • DSRC capacity does not seem to be a limiting factor under normal road environments • Processing speed appears to be greater limitation (probably addressable using lower level, faster software system) • Intermittent RSE connectivity is not a significant limitation for most applications • RSE to RSE hand-off works!

8. Key General Findings • DSRC Multipath requires further study • Antenna and diversity systems need to be refined for optimal performance • Significant signal fading at specific ranges • System can be secured without major overhead • Security functions do not appear to significantly impact system capacity or latency (in test) • Security credentials can be managed over-the-air (static tests to date) • Certificate based approach appears to be well suited to distributed system management • Anonymity can be assured without compromising security (analysis) • Security scalability needs to be addressed • Not fully covered during POC

9. State Logic in 1609.3 Needs Refinement • Very useful to have ability for application to actively indicate interest in WBSS • Confirm Before Join • Unavailable • Should define WBSS arbitration rules • How to arbitrate between same PSID advertised on two WBSSs? • Inactivity based WAVEend is slightly problematic • Essential that only WBSS SCH be monitored • Must monitor all types of message traffic (WSMP & IP) • May encounter un-join problems if other nearby RSEs are not on distant SCHs • May want to significantly revise this concept based on WSA MAC Address, competing WBSSs, interested applications, priorties, etc • Overall state logic needs to be refined • Improved definitions • Role and use of priorities • Multiple RSEs with multiple WBSS’s • Need to review approach relative to WBSS content (multiple PSIDs) • Unclear how system deals with WBSS joined as a result of multiple PSID matches

10. Application Operating States

11. PSIDs and Service Management • Need to better define meaning of PSID • What differentiates one PSID from another? Priority? PSC Format? Message format? • When is a new PSID appropriate • Not clear that we need huge number of PSIDs • Application unique PSIDs appear to only be required for locally provided and/or system based services that use WSMP • IP address partially duplicates function of PSID for IP comm • IP address binds messages to app by default, so for IP PSID is only used for service discovery • No need to advertise services that pass through system using IP • Only need to advertise availability of general IP connectivity • Don’t necessarily need WRA if system has DNS capability (most apps already know IP address of network service) • Avoids huge WSAs • DNS for system would be useful, although it is not necessary in the standard

12. Priorities • Extensive confusion on priorities • Need to substantially refine this area • Service Priority should be based on PSID • Allows radio to chose between offered WBSS’s based on services available and relative priorities of desired services • Priority enforced through certificates • Message Transmission Priority • Used for message transmission priority in radio medium • No good way to enforce this specific priority • Display Priority • Need some consistent method for identifying message content to allow OEMs to determine their display priority • Response to priority should be determined by each OEM, based on OEM policies

13. RF Observations • Range is impressive • Have observed up to 800 meters in open environment • Multipath and signal fading cause significant issues • Automatic join is impractical - radio joins WBSS at first WSA received, even if PER is very high • Need some form of QOS determination prior to join • Significant RF dropouts noted at about 120-150 meters • Long range can mean WBSS is joined prior to encountering dropout • Non-acknowledged communications is problematic for long messages • WSMP broadcasts seem OK if repetition rate is high enough • UDP performance is variable, depends on vehicle speed and data set size

14. Effect of Channel Synchronism on CSMA Process • Have observed systematic loss of heartbeat messages depending on sending rate • Believe explanation is that synchronized channel switching invalidates basic assumption of random user sending times • CSMA is based on random user timing • DSRC has 100 msec timing so users with high rep rate apps are all trying to send at the start of the cycle • Random user timing assumption is not valid • Appears that contention window is not large enough to prevent collisions after back off • Listen to channel, see it is busy during guard interval, pick backoff, wait, listen and send. • Problem is that other users are doing the same thing. If they listen at the same time the channel will appear clear, and they will send at same time (collide)

15. Guard Interval CCH Interval Channel Busy Channel Available Unit 1 Tries to Send Unit 2 Tries to Send

16. Guard Interval CCH Interval Channel Busy Channel Available Slot 1 Slot 2 Slot 3 Slot 4 Slot 5 Slot 6 Slot 7 Slot 1 Slot 2 Slot 3 Collision Both Units listen, and since channel is open, send messages Unit 1 Tries to Send; Picks Slot 7 Back-off Unit 2 Tries to Send; Picks Slot 7 Back-off

17. Security • Implemented anonymous certificate and certification process • Double blind process • Certifying authority and Authorizing authority • Have developed concept for device validation, but not implemented in POC • Based on “trusted computing module concept” • Device/vehicle must prove it has not been tampered with in order to gain access to certs and keys