vii proof of concept program summary
Skip this Video
Download Presentation
VII Proof Of Concept Program Summary

Loading in 2 Seconds...

play fullscreen
1 / 17

VII Proof Of Concept Program Summary - PowerPoint PPT Presentation

  • Uploaded on

VII Proof Of Concept Program Summary. Scott Andrews VII Consortium 4/29/08. 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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'VII Proof Of Concept Program Summary' - luna

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
vii proof of concept program summary

VII Proof Of Concept Program Summary

Scott Andrews

VII Consortium


vii system objectives
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
vii system overview
VII System Overview





Roadside Infrastructure



















On Board



















External Data Sources

poc scope
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
poc project status
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
poc project status cont d
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)
key general findings
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!
key general findings8
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
state logic in 1609 3 needs refinement
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
psids and service management
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
  • 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
rf observations
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
effect of channel synchronism on csma process
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)
Guard Interval

CCH Interval

Channel Busy

Channel Available

Unit 1 Tries to Send

Unit 2 Tries to Send

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


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

  • 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