Vii proof of concept program summary l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 17

VII Proof Of Concept Program Summary PowerPoint PPT Presentation


  • 60 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

VII Proof Of Concept Program Summary

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 l.jpg

VII Proof Of Concept Program Summary

Scott Andrews

VII Consortium

4/29/08


Vii system objectives l.jpg

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 l.jpg

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


Poc scope l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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


Application operating states l.jpg

Application Operating States


Psids and service management l.jpg

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


Priorities l.jpg

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


Rf observations l.jpg

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 l.jpg

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)


Slide15 l.jpg

Guard Interval

CCH Interval

Channel Busy

Channel Available

Unit 1 Tries to Send

Unit 2 Tries to Send


Slide16 l.jpg

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


Security l.jpg

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


  • Login