VII Program Overview and V2 Standards Expectations

1
VII Program Overview and V2 Standards Expectations

• Presented to the IEEE P1609 Working Group
• October 4, 2006
• VIIC Systems Engineering

2
Program Overview

• VII Program is aimed at a proof of concept
  demonstration
• Goal is to test ability of system to deliver
  public and private services
• Identify technical issues that require additional
  work
• Provide testbed for applications and services
• Implemented through contracts and cooperative
  cost share agreements with FHWA

3
VII Program Overview

• Two main development components
• Vehicle components, services and applications
• Performed by VIIC
• Infrastructure
• Performed by Booz Allen Hamilton
• Proof of Concept testing is collaborative effort
  between both teams
• Component testing spring 2007
• Road testing summer/fall 2007

4
Vehicle Infrastructure Integration Consortium
(VIIC)

• 8 car makers
• BMW, DCX, Ford, Honda, GM, Nissan, Toyota, VW
• Partnered with about 15 suppliers to implement
  POC
• Headquarters in Novi, MI

5
VIIC POC Work Orders

• 1 Program Management
• 2 Systems Engineering
• 3 Radio
• 4 Policy
• 5 OBE Subsystem
• 6 Applications

• 7 Positioning
• 8 Security
• 9 Policy
• 10 Field Tests
• 11 Alternative Analyses
• 12 Network Service Enablers
• 13 File and Software Management

6
DSRC Related Work Orders

• Radio
• Implementing
• 802.11p (Transcore)
• 1609.3 (TechnoCom)
• 1609.4 (DENSO)
• Some aspects not implemented, some additional
  elements added
• Security
• Implementing 1609.2 in its entirety (NTRU)
• Separates protocol functions from ECC crypto
  functions

7
External System Interfaces
8
System Architecture
DSRC Interfaces
9
Anticipated Additions and Changes to 1609.2 (V2)

• Add formats for anonymous certificates
• Anonymous certificates will exist
• Standard need not say how they are generated or
  managed
• Standard should say what the content and format
  is
• Add guide for use of 1609.2 certificates in IP
  transactions
• Modification to DTLS
• X.509 certificates too large

10
Anticipated Additions and Changes to 1609.3 (V2)

• Add MAC address changing requirements
• Required to meet privacy requirements
• Remove ACF
• No use case may be misused to allow low priority
  apps to communicate on high priority WSA
• Remove some requirements on responses to WSA
• Standardized decision process for joining WBSS
  not required for interoperability
• Modify criteria for ending WBSS current approach
  could be spoofed by fake WSA causing everyone to
  end WBSS (bad credentials)
• Possible guide/requirements for RSU serving as
  proxy for a OBU

11
Anticipated Additions and Changes to 1609.4 (V2)

• No known changes yet, but expect many detailed
  corrections and refinements as a result of
  implementation

12
Other Comments

• Do NOT recommend any standardization of
  application layer functions (e.g. API, resource
  manager, dispatcher, etc)
• These functions are not required to assure
  interoperability
• These functions are subject to many different
  implementation decisions, and none of these
  impact other DSRC systems
• DSRC messages will not have any direct control
  over, or interface to, internal vehicle systems
• Any indirect vehicle control would need to be
  performed by a vehicle based application
  developed by the OEM
• The IEEE 802.11p/1609 standards stop at the top
  of the stack