PAR DSRC Electronic FeeToll Collection

1
October 2008Albany, NYJustin McNew
Dedicated Short-Range Communication Electronic
Toll/Fee Collection
2
Overview

• PAR submission, Verbiage
• Objectives and non-objectives
• Architectural representation
• Features considered
• Features Supported

2
3
PAR Verbiage

• The scope of this standard is to specify the
  application for DSRC based Electronic Toll/Fee
  Collection incl. profile definition of the
  communication layers between fixed roadside
  devices and vehicle-based devices using Wireless
  Access in Vehicular Environments.
• The purpose of this standard is to provide an
  open standard for the relevant interface in DSRC
  based Electronic Toll/Fee Collection systems so
  to allow for interoperability between systems of
  different vendors and/or operators.

3
4
Objectives and non-objectives

• This Standard provides for a coherent set of
  requirements of the EFC application incl. the
  communication layers that may serve as a common
  technical platform for EFC-interoperability.
• The definition of application data and function
  in this standard freely allow each operator to
  define the relevant tariff and vehicle classes.
• This standard defines a basic level of technical
  interoperability for EFC equipment, i.e. onboard
  unit (OBU) and roadside equipment (RSE) using
  DSRC. It does not provide a full solution for
  interoperability, and it does not define other
  parts of the EFC-system, other services, other
  technologies and non-technical elements of
  interoperability.
• This standard does not defined technology and
  processes to activate and store data into the OBU
  (personalisation)

4
5
Architectural representation
DSRC Electronic Fee/Toll Collection
5
6
Features Considered

• Standard API
• Specification of the interface between EFC
  application and communication stack. The EFC
  application interface is the EFC application
  process interface to the DSRC communication
  layers
• EFC Data
• Specification of data addressing procedures
• Specification of EFC data incl. syntax and
  semantics, to be made available in the OBU
• EFC functions
• Specification of specific EFC application
  functions, incl. application level security
• Specification of application level security
  algorithms
• EFC transaction model
• Definition of the common elements and steps of
  any EFC transaction
• Application profile
• Definition of application profiles, incl.
  related transactional model and used services and
  data
• Communication stack profile
• Selection of services and configuration of
  attributes of the communication layers

6
7
Features Supported

• Complex EFC system architecture
• This standard supports complex architectures of
  EFC system where the issuer of the OBU and EFC
  contract is a different entity then the toll
  charger
• Both entities are considered as non-trusted
  partners.
• The end-user is not directly known to the toll
  charger
• Declaration of vehicle characteristics
• This standard supports EFC systems where vehicle
  characteristics cannot be measured in the lane
  (multi-lane free flow) and are declared by the
  OBU to the roadside.
• Security features specific to the EFC realm
• Authentication and integrity of EFC transactions
  to be checked by different entities within the
  system before billing
• Access protection of OBU data
• Protection against cloning of OBUs

8
Justin McNew Kapsch TrafficCom Inc. 2035 Corte
del Nogal, Suite 105 Carlsbad, CA 92011 Phone
[phone] x 175 Fax [phone] Email
justin.mcnew_at_kapsch.net www.kapsch.net