NATIONAL CONNECTED VEHICLE
FIELD INFRASTRUCTURE
FOOTPRINT ANALYSIS
Design Gaps Analysis
Contract No. DTFH61-11-D-00008
Submitted to:
U.S. Department of Transportation
Federal Highway Administration
By the:
American Association of State Highway
and Transportation Officials
Version 1
Draft
June 28, 2012
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
Document Versions
Version
1
Description
Draft submitted for review, June 28, 2013
1
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
Table of Contents
1. Introduction ..............................................................................................................................1
1.1. Background .......................................................................................................................1
1.2. Document Purpose ............................................................................................................1
1.3. Document Overview .........................................................................................................2
2. Design Gaps ..............................................................................................................................3
2.1. Connected Vehicle System Architecture ..........................................................................3
2.1.1. System Architecture Description and Requirements...........................................3
2.1.2. System Boundary ................................................................................................4
2.1.3. Non Extensible Architecture ...............................................................................5
2.1.4. Relationship between RSE and Applications ......................................................6
2.1.5. Relationship between RSE Location, Applications and Latency ........................7
2.2. Equipment Installation ......................................................................................................8
2.3. Connected Vehicle Data Needs and Standards .................................................................8
2.3.1. Infrastructure Data Message Standards: the BSM ..............................................8
2.3.2. Infrastructure Data Message Standards: Extensibility ........................................9
2.3.3. Location-based Warning in the Map Linkage Structure. ..................................10
2.3.4. Map Database Assumptions ..............................................................................10
2.4. Security ...........................................................................................................................11
2.4.1. WWAN Messaging and Security ......................................................................11
2.4.2. Field Equipment/Application Certification/Tamper Resistance .......................12
2.4.3. Vehicle/Application Certification .....................................................................12
2.4.4. Retirement/End of Life ......................................................................................13
2.4.5. Revoked Device Management...........................................................................13
2.4.6. Bootstrap and Device Certification ...................................................................14
2.5. Backhaul Network ..........................................................................................................16
2.6. Mapping Support ............................................................................................................17
2.6.1. Road Geometry Data Standards ........................................................................18
2.6.2. Map Message Content .......................................................................................18
2.6.3. Road Geometry Data Maintenance ...................................................................19
2.7. International Land Border Crossings ..............................................................................19
2.7.1. Organizational and Technical Capabilities........................................................19
2.7.2. Border Information Flow Architecture..............................................................20
2.7.3. Physical and Communication Security..............................................................20
2.7.4. Bi-National Data Exchange Protocols and Standards .......................................21
2.8. Policy/Governance Gaps .................................................................................................22
ii
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
2.8.1.
2.8.2.
2.8.3.
2.8.4.
Appendix A.
Infrastructure Data Business Models ................................................................22
RSU Management and Access Requirements ...................................................23
Cross Border Identified Certificate Administration ..........................................23
Deployment Goals and Strategy ........................................................................24
Acronyms .........................................................................................................26
iii
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
List of Identified Gaps
Gap 1: Lack of Consistent Systems Engineering Documentation
3
Gap 2: System Boundary and Associated Interfaces Not Well Defined
4
Gap 3: Architecture and Supporting Messaging Standards Are Inflexible and May Suffer From
Early Obsolescence
5
Gap 4: Inconsistent Understanding of Range of Applications for a Single RSE
6
Gap 5: Lack of Consensus on Relationship between RSE Location, RSE Applications and
Latency Requirements
7
Gap 6: Lack of Installation Guidelines for DSRC Field Equipment
8
Gap 7: Basic Safety Messages Are Inadequate As a General Means for Collecting Road Data
8
Gap 8: Current Messaging Standards and Data Dictionaries May Not Support Current or
Future Needs of Infrastructure Implementers
9
Gap 9: No Explicit Linkage between Warning Messages and the Underlying Map
10
Gap 10: Inconsistency in Assumptions about Map Data Sources
10
Gap 11: Security Standards for Local and Wide Area Networks Are Not Aligned
11
Gap 12: Security Requirements for Field Equipment Are Not Defined
12
Gap 13: Vehicle Certification Does Not Adequately Constrain Terminal Elements
12
Gap 14: No Method for Destruction of Vehicle Equipment
13
Gap 15: Requirements for Revoked Device Behavior
13
Gap 16: Security Credential Management System Design Is Not Deployment Ready
14
Gap 17: Misbehavior Reporting and Detection Processes Are Not Sufficiently Defined, and May
Not Be Effective
16
Gap 18: IPv6 for Backhaul Not Yet Widely Accepted or Demonstrated
16
Gap 19: No Requirements for Road Geometry Content and no Standards for Accuracy
18
Gap 20: Current SAE J2735 MAP Message Standard is Incomplete and Inflexible
18
Gap 21: Dynamic Updating of Road Geometry Data
19
Gap 22: International Coordination
19
Gap 23: Unbalanced Cross-Border Capabilities
20
Gap 24: Border Information Flow Architecture (BIFA) is Inconsistent with ITS National
Architecture
20
Gap 25: No Established Standards for Cross-Border Information Exchange and Information
Security
20
Gap 26: No Established Standards for Cross-Border Real-time Information Exchange
21
Gap 27: Business Models for Connected Vehicle Data Have Not Been Developed or Validated 22
iv
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
Gap 28: No Obvious Incentive for Data Providers to Provide Data beyond Any Mandate
22
Gap 29: RSU Management Access and Security Requirements Not Defined
23
Gap 30: No Established International Passenger Vehicle Certificate Information Exchange
Platform
24
Gap 31: No Consensus on Public and Private Sector Roles in Deployment
24
v
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
1. INTRODUCTION
1.1. BACKGROUND
This technical memo is part of a study sponsored by the US Department of
Transportation (USDOT) and performed by the American Association of State
Highway and Transportation Officials (AASHTO). The purpose of this project is to
conduct analyses leading to a preliminary, general concept of a national connected
vehicle field infrastructure footprint. Describing such a footprint satisfies many
requirements in developing a policy foundation for the connected vehicle
environment, including development of a set of desired outcomes which include:

A description, for State and local investment and decision makers, of the
justification for and value of deployment of connected vehicle infrastructure.

A compilation of the data, communications, and infrastructure needs of the
priority applications.

A set of generic, design concepts (at a high-level of engineering detail) that
relate the infrastructure to the applications (or bundles of applications) and
their needs under different operational conditions.

A set of State- and local-based scenarios identifying how and where agencies
might implement secure, connected vehicle infrastructure and what funding
strategies might use to support such deployment, and a synthesis of these
scenarios into a preliminary national footprint of connected vehicle field
infrastructure.

A phased deployment plan which identifies the actions and funding
strategies needed over a period of time for coordinated implementation of a
national connected vehicle field infrastructure.

Cost estimates for deployment, operations, and maintenance.

Estimates of workforce and training requirements; and identification of policy
and guidance needs.

Identification of implementation challenges and institutional issues and
identification of the timing by which those issues need to be resolved to
achieve deployment.
This technical memo specifically relates to the identification and analysis of design
gaps.
1.2. DOCUMENT PURPOSE
The purpose of this document is to identify, describe, and make recommendations to
address apparent gaps between the National Connected Vehicle Field Infrastructure
1
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
Footprint Analysis Design Concepts developed in Task 5 of the study and the ongoing
technology development, design, implementation, policy development and
governance of connected vehicle applications.
1.3. DOCUMENT OVERVIEW
Following this introductory section, the document consists of a series of design gap
discussions, structured loosely around topical areas of concern. The discussion of
each gap consists of a one-sentence description or label, a summary of the key issues
from which the gap arises, and recommendations for addressing the perceived gap.
2
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
2. DESIGN GAPS
2.1. CONNECTED VEHICLE SYSTEM ARCHITECTURE
The Systems Engineering Guidebook for ITS sets forth a detailed process for describing
ITS systems and developing requirements for the various system elements. This
process includes the identification of the elements inside the system, and those
specifically outside the system (the system boundary), the development of concepts
of operations for known applications and system functions, and specific high-level
requirements for each of the identified elements. Using these documents, a
practitioner can then develop procurement specifications and design details for their
particular implementation. This unified design is especially important for the
connected vehicle system since it is a nationwide system that will likely be deployed
incrementally region by region through the work of state and local agencies and
private industry. Providing a unified design will assure regional compatibility and
continuous interoperability for vehicles as they cross jurisdictional boundaries.
2.1.1. System Architecture Description and Requirements
Gap 1: Lack of Consistent Systems Engineering Documentation
While a variety of system descriptions have been developed, there is currently no
fully-consistent set of documents describing the entire connected vehicle system
architecture, and there are no corresponding requirements for all elements of the
system as it might be deployed. As a result, a practitioner seeking to implement the
system would not have a complete and consistent set of specifications and functional
descriptions upon which to implement the system.
For example, the core system architecture documentation identifies a variety of
functional elements that are part of the connected vehicle system, but are not within
the system boundary of the core system. As such these are not treated in the Core
System Concept of Operations, and are not addressed from a requirements
perspective in the Core System requirements documentation or architectural
description. The Core System documentation thus is not by itself sufficient to
implement the connected vehicle system.
The Connected Vehicle Reference Implementation Architecture (CVRIA) project
appears to be developing a broader architectural description (encompassing
elements outside the Core System), but it is not clear that this effort is aimed at
generating a complete suite of system requirements and operational concept
descriptions, but rather is aimed at identifying interfaces and required standards for
interfaces.
3
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
The National ITS Architecture appears to be a very high level description into which
the connected vehicle system may fit, but it does not appear to address the level of
detail required to, for example, assure application interoperability across different
implementations.
There have also been a variety of efforts aimed at developing applications-related
concepts of operations, but these are not part of any overall systems engineering
process, and it is unclear how they relate to the overall unified system. For example,
they may or may not include the same functional components and interfaces as the
other systems documents.
In general, all of these documents have been developed at different times by
different organizations for different purposes, and thus they do not necessarily
provide a complete resource for system implementation
Recommendation: Compile a complete set of end-to-end system design documents
with concepts of operations for all safety and mobility applications and security
management, together with component requirements. These may draw from
existing documentation and work done to date, and they may require additional
systems engineering work to develop. The result should be a unified system
description that clearly sets forth the operations of the system for the primary
functional tasks they are to perform, and lays out requirements that will assure
interoperability across all implementations of hardware and software.
2.1.2. System Boundary
Gap 2: System Boundary and Associated Interfaces Not Well Defined
Many of the existing system descriptions include the concepts of mobile, field and
center elements. However, the distinction between which parts of these elements are
within the system boundary (and thus subject to system requirements), and which
elements are outside this boundary (and thus not addressed by system
requirements) is not explicitly clear. For example the “field” elements may include
roadside DSRC units and associated application processors, but there are also field
elements (such as signal controllers, access gates, etc.) that are clearly not subject to
connected vehicle requirements. The currently available documentation for the Core
System and the CVRIA do not clearly specify these boundaries, and thus there is
significant confusion about the interfaces between the connected vehicle system and
the existing infrastructure.
Recommendation: Draw system boundary to leave existing field, center and vehicle
equipment outside the system, and to require the definition of interfaces between
these elements and the connected vehicle system.
4
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
2.1.3. Non Extensible Architecture
Gap 3: Architecture and Supporting Messaging Standards Are Inflexible and May
Suffer From Early Obsolescence
Many aspects of the connected vehicle architecture are based on application-specific
designs. For example, most of the SAE J2735 messages are oriented toward
supporting specific applications. This means that as new applications are conceived
these standards will need to be revised to provide new messages to support them.
This issue is also exhibited in the IEEE 1609 WAVE standards, which are intended to
support delivery of messages to applications based on fixed identifiers that are
generally specific to particular applications and in some cases particular
organizations. To support possible future growth, the standard has set aside a space
of 4 billion possible “provider service identifiers.” In addition, most connected
vehicle development activities are organized around applications to such an extent
that in many cases the architecture is refined specifically for these applications. As
an example, the current anonymous security design is set up to support certificates
for anonymous Basic Safety Messages. As it is currently conceived, the addition of
any other applications requiring anonymous certificates will require extending the
number of certificates and the supporting management and delivery operations, and
these operations are already seen as barely able to handle the currently imagined
system scale. If, for example ten applications require anonymous certificates, then
the security apparatus and corresponding communications will need to be an order
of magnitude larger. Essentially, as currently designed, the system can only support
the anonymous BSM and various other V2I applications.
In contrast, the Internet, to which the Connected Vehicle system is often likened, is
very generalized, and architected in a way that insulates it from changes in
technology and changes in applications. It has withstood massive changes in both
and has simply grown to support them. It is likely that under the current application
specific and non-generalized architecture and approach, the Connected Vehicle
system will be in a perpetual state of technical obsolescence, and many potential
applications that might otherwise add enough incremental value to make the
equipment and operational costs worthwhile may move to other more easily
adaptable media such as the internet and the cellular data system.
Recommendation: Examine the connected vehicle architecture (as much as it is
defined - See Gap 1), and identify ways in which it can be made more technology
neutral and more application independent. Perform trade studies and analyses to
determine if, for example, conventional flexible internet related protocols (e.g., XML)
can be supported given the available bandwidth. Seek ways to minimize system
dependencies on specific technologies and applications/uses.
5
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
2.1.4. Relationship between RSE and Applications
Gap 4: Inconsistent Understanding of Range of Applications for a Single RSE
Because of the lack of any unified architectural description, there is a significant
diversity of opinion about the relationship between an RSE and the application(s) it
may support. At one extreme is the view that each RSE must support only a single
application. If this is the case, then the RSE will only broadcast the messages
associated with that specific application. At the other extreme, an RSE is seen as a
terminal that may host a variety of local applications, and may be connected to a
variety of remote center elements (e.g., traffic management centers) for which it
forwards messages. In this case, the range of applications that the RSE may serve is
unbounded. There is no fundamental architectural reason that the unbounded case
cannot be supported, but there are practical limitations on the scope of applications
on any given RSE.
The deployment impact of this divergence of views is significant. If each RSE is
expected to support only one application, then the number of RSEs that must be
deployed may be enormous, and the problem of RSE-to-RSE interference will need
to be addressed. On the other hand, if each RSE can serve an unbounded set of
applications, then managing the RSE processing and radio resources will become
increasingly important, and choosing geographic locations that are compatible with
all of the RSE applications may be problematic.
Recommendation: Develop a description of the various operational configurations
for RSEs that are allowed under the standards. For example:

RSE broadcasting messages for a single stand-alone local application

RSE broadcasting messages for a multiple local applications

RSE broadcasting messages for a single locally-connected field system such as
a traffic signal controller

RSE receiving and immediately forwarding/broadcasting messages from a
single center facility

RSE receiving and immediately forwarding/broadcasting messages from
multiple center facilities

RSE receiving and storing messages from one or more center facilities and
then broadcasting them according to a provided schedule

RSE aggregating data received from passing vehicles and periodically
forwarding aggregated or bundled data to one or more repository or
distribution facilities (e.g., a Core System distribution function)
6
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis

RSE Providing IP backhaul/routing services to OBEs in the radio footprint
(e.g., for remote services or for security management operations)
This description should include a discussion of the policies and technical
considerations associated with supporting these various uses of RSEs.
See Related RSE Siting and RSE Location/Latency gaps.
2.1.5. Relationship between RSE Location, Applications and Latency
Gap 5: Lack of Consensus on Relationship between RSE Location, RSE Applications
and Latency Requirements
There is a significant diversity of opinion about the relationship between the RSE
location, the applications the RSE may support, and the latency that the applications
can tolerate. One view is that the RSE should always be physically associated with
the location that the application relates to. For example, a curve speed warning
application must be located proximate to the curve. In some applications this view is
further supported by concerns about message latency. For example, an RSE
supporting SPaT messages must be located at the intersection and the messages
must be sent with low latency to vehicles about to encounter the signalized
intersection.
In general, these views and concerns are a result of not having a unified system
definition where the system architecture is related directly to the applications
through a ConOps document that clearly illustrates the steps each architectural
element takes to carry out a specific application (See Gap1). An alternative view is
that messages can be sent from any RSE that the host vehicle passes prior to
encountering the area to which the hazard applies. In that approach the message
would include an activation zone and it would lie dormant in the OBE until the OBE
entered the geographic activation zone or the message expired (this is how roadway
alerts were implemented in the Michigan Proof of Concept system).
In the first approach all messages are acted upon as soon as they are received. This is
a valid approach, and it is attractive because it requires no coordination between the
message provider and the OBE application developer (i.e., nothing other than a
message format standard), but it is nearly impossible to implement since it requires
that an RSE be placed at every hazard. Since the hazards are not known in advance
it limits the scope of the connected vehicle system to only cover hazards at locations
where an RSE is or can be located.
In the second approach, the RSEs may be located at strategic points where they can
seed the passing vehicles with messages that may or may not be activated down the
road. This is attractive because it substantially limits the number of RSEs, but it
7
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
assumes coordination and standardization of the operational aspects of the
messages and the user applications beyond simple message formatting rules.
Recommendation: See Gaps 1 and 3.
2.2. EQUIPMENT INSTALLATION
Gap 6: Lack of Installation Guidelines for DSRC Field Equipment
The installation of DSRC equipment includes the installation of radio antennas to
provide communications coverage for a given area. There have been several efforts
to develop site survey and siting guidelines, but none of these has been published as
a definitive source.
Recommendation: Develop and publish comprehensive RSU siting and installation
guidebook, or update the MUTCD with this information. The guidelines may be
extensions to existing field equipment standards, or they may be application-specific
and unique to connected vehicle installations. However this is done, practitioners
will need some form of technical support to assure that the site and installation are
appropriate for the intended applications
Some of this work may be being addressed by other FHWA activities, but a bestpractices document specific to this topic would be very useful
2.3. CONNECTED VEHICLE DATA NEEDS AND STANDARDS
Standards for vehicle-to-vehicle communications are very well developed. However,
there are significant gaps in defining messages for use in vehicle–to-infrastructure
communications. In particular, communicating data from vehicles to the
infrastructure and in providing location specific information to vehicles that is
accurate to lane level, or can provide more than driver advisories, has been
languishing due to lack of commercial development or clear definition of
infrastructure interests.
2.3.1. Infrastructure Data Message Standards: the BSM
Gap 7: Basic Safety Messages Are Inadequate As a General Means for Collecting
Road Data
The SAE J2735 message standard describes a variety of messages generally
associated with connected vehicle applications. However, while the standard does
include roadway alert and probe data message types, most of the recent
development effort in the standard has been devoted to the Basic Safety Message
Part One (BSM-1). Recently the BSM has assumed the role of providing “probe data”
as well as fulfilling its vehicle-to-vehicle safety role. This message provides
reasonable knowledge of a vehicle’s kinematic state to other vehicles within range of
8
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
that vehicle’s DSRC radio. Other than providing a small amount of data about the
recent past path of the vehicle (i.e., the path of the prior few seconds), the message
content is specific to the current location of the vehicle at the time of transmission
and it is oriented specifically toward safety. As such, it does not provide any insight
into road conditions or vehicle behaviors at other prior locations. It is specific to the
transmission and collection point.
Additional messages, specifically the BSM Part Two and the probe vehicle data
message have been proposed, but details of the content of these messages is still not
well defined, and the conditions under which this data will be delivered, if at all, are
unknown. This issue is discussed at some length in the report “Vehicle Information
Exchange Needs for Mobility Applications Exchange” which identifies the
significant limitations of using the BSM message for infrastructure applications.
Recommendation: Revise the system operational concept to explicitly include the
collection and delivery of probe data, and develop next generation probe data
messages and collection protocols with heavy involvement of AASHTO
stakeholders to assure the collected data is useful and relevant. This effort needs to
also consider Gaps 27 and 28 which deal with the motivations and value chains so
that there is a clear motivation for car makers to include this functionality. In effect,
the rationale should be that the AASHTO stakeholders will install and maintain the
infrastructure elements of the system, which benefits the vehicle users and facilitates
V2V safety in exchange for providing probe data.
2.3.2. Infrastructure Data Message Standards: Extensibility
Gap 8: Current Messaging Standards and Data Dictionaries May Not Support
Current or Future Needs of Infrastructure Implementers
In addition to the general uncertainty about whether specific data will be available
or not, the J2735 standard is somewhat rigid about data structures and tends to
package the data into fairly large and somewhat application-specific elements. For
example, the BSM Part Two may contain many data elements whereas the receiver
may only be interested in one or two of those elements. This is both inefficient from
a communications perspective and is inflexible for implementers who may or may
not be motivated to provide all assumed data elements. While suppliers may
provide data when they understand where the data is going and how it will be used,
they are unlikely to supply data elements if it is not clearly useful to somebody.
In addition, these messages are not easily adapted to support data elements that are
not yet identified but may become interesting in the future. One of the great
strengths of the Internet is that the underlying protocol assumes nothing about the
types of data that are being transmitted. This protocol, initially envisioned to
9
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
support email and small file exchanges, has enabled developers to support voice,
video, gaming, and a virtually unlimited array of other applications. While there has
been no effort specifically to curtail future expansion, the current approach has been
to define message sets that support all projected future needs, even though there is
relatively little certainty that these needs can be anticipated accurately
Recommendation: In addition to known application-specific messages, such as the
BSM, extend and/or revise the messaging standards to support data objects rather
than application specific sets of data. For example, SPaT is effectively a time-based
statement of the pass-ability of specific pathways through an intersection, and as
such is only marginally different from a closed lane or other lane-specific alert. This
more abstract and general approach would separate the message definitions from
the user applications and would provide for a much wider and more diverse set of
applications.
2.3.3. Location-based Warning in the Map Linkage Structure
Gap 9: No Explicit Linkage between Warning Messages and the Underlying Map
The current messaging scheme treats warnings and advisories as independent from
maps that may provide context for those warnings (e.g., curve speed advisories,
intersection warnings, etc.). Typically the map data necessary to understand the
warning includes localized geometric data for a particular localized section of
roadway.
Since, in this scheme, the warning is delivered separately from the map there is a
finite possibility that the vehicle may not have the required map when it receives the
message. Assuring that the vehicle does have every map for every message thus
adds complexity to the deployment of an application, because the system has two
messages instead of one, and the deployer must consider how to efficiently deliver
the map, and how to assure that the map version is up-to-date, while the user
developer must guess as to how long to retain such map data.
Recommendation: Review warning applications and messages to determine if the
map data needed to make use of the warning message can be included in the
warning message itself. If so, consider revising the message standards to support
this.
2.3.4. Map Database Assumptions
Gap 10: Inconsistency in Assumptions about Map Data Sources
There are various approaches to referencing road hazard information to the actual as
built road. All of these generally rely on some sort of road description or map.
However, the source of the map data is subject to a wide range of opinions. Some
10
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
implementers assume that commercial maps will be available, while others assume
that if the data is necessary in order to use the data, then it should be provided by
the same jurisdiction providing the road hazard information. The first approach is
simple, but it risks issues from both map availability and inconsistency between the
location reference of the hazard and the location reference and accuracy of the map.
This inconsistency is especially likely since there are many map makers, and there
are few standards for map accuracy and content. The second approach requires that
the map data associated with the messages be provided in a timely manner, and it
means that practitioners must be concerned with generating this data. Either way
works, but since the vehicle will travel through multiple jurisdictions, whichever is
used must be consistent. If one jurisdiction provides map data while another
assumes that it is commercially available, then implementation of the system must
include the complexity of both approaches. The lack of consistency about which
source to use introduces a great deal of uncertainty and interdependency across the
implemented community, a substantial portion of which is based on speculation
about what the commercial map makers may or may not do.
Recommendation: Settle on one approach for map data sources, and develop
appropriate standards to support the approach.
2.4. SECURITY
2.4.1. WWAN Messaging and Security
Gap 11: Security Standards for Local and Wide Area Networks Are Not Aligned
The system architecture as described for purposes of this project includes local area
(e.g., DSRC) and wide area (e.g., cellular) communications channels. In general the
SAE J2735 standard defines messages independently from the communications
media, so it appears that these messages could be used for either medium. However,
the IEEE 1609.2 standard specifically defines the mechanisms used to secure the
WAVE/DSRC communications link and to ensure anonymity. This standard
includes, among other things, mechanisms for validating the integrity of messages
and for encrypting messages. There are currently no standards identified for
securing messages sent across wide area networks such as cellular, and these links
are inherently non-anonymous. It appears that the 1609.2 approach could be applied
to messages sent over a cellular channel, but the standard is not currently oriented
toward this application, and it has not been analyzed to determine if it is compatible
or appropriate. For example, if a vehicle system signs probe data using anonymous
certificates and then sends this data over a non-anonymous link (e.g., cellular) the
user’s identity is then bound to the 1609.2 certificate, and anonymity is lost.
11
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
Recommendation: Determine what security and assurance standards should be
applied to data provided over WWAN.
2.4.2. Field Equipment/Application Certification/Tamper Resistance
Gap 12: Security Requirements for Field Equipment Are Not Defined
It appears that the requirements for the DSRC terminal elements of field equipment
(e.g., RSUs) are limited to FCC licensing, and conformance to the WAVE/DSRC
standards. The WAVE DSRC standards simply require that messages sent from an
RSU must be signed, either by the RSU or by the message originator. However, since
there are no security requirements that apply to the generating application, it is
unclear what is actually being certified. Stated differently, lacking any security
requirements or performance standards for applications, the certification authority,
the certificate simply attests to the fact that the RSU requested and received
certificates. It currently says nothing about the integrity of the RSU or the
application that generated the message. These requirements may emerge as a result
of the certification process, and if applications are developed prior to the
development of these requirements, the applications may need to be modified.
Similarly, there are no requirements or specified standards for tamper resistance or
tamper detection. Without such requirements it may be possible to tamper with an
RSU so that it sends improper messages that are signed using the RSU certificates.
Recommendation: Develop physical and application security standards for field
equipment.
2.4.3. Vehicle/Application Certification
Gap 13: Vehicle Certification Does Not Adequately Constrain Terminal Elements
It appears that the requirements for the DSRC terminal elements of field equipment
(e.g., RSUs) are limited to FCC licensing, and conformance to the WAVE/DSRC
standards. The WAVE DSRC standards simply require that messages sent from an
OBU must be signed. However, since there are no security requirements that apply
to the generating application, it is unclear what is actually being certified. Stated
differently, lacking any security requirements or performance standards for
applications, the certification authority, the certificate simply attests to the fact that
the OBU requested and received certificates. It currently says nothing about the
integrity of the OBU or the application that generated the message. These
requirements may emerge as a result of the certification process, and if applications
are developed prior to the development of these requirements, the applications may
need to be modified. Similarly, there are no requirements or specified standards for
tamper resistance or tamper detection. Without such requirements it may be
possible to tamper with an OBU so that it sends improper messages that are signed
12
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
using the OBU certificates. This issue is especially concerning since vehicles engage
in peer-to-peer message exchanges (V2V communications), which means it is
possible to use the connected vehicle system to deliver malware to the entire
national vehicle population in a matter of days. This represents a serious risk with
substantial potential negative consequences.
Recommendation: Determine how to link a DSRC terminal element to a vehicle so it
will not work outside of the car or in another vehicle without re-certification, and so
that the certificates are linked logically to the applications that use the certificates.
Include association with vehicle ECUs and positioning technology. Include/develop
requirements for tamper resistance that extend to application software.
2.4.4. Retirement/End of Life
Gap 14: No Method for Destruction of Vehicle Equipment
Currently there is no provision for and no requirements associated with how
connected vehicle terminal equipment is to be handled when it is retired. For field
equipment this may be handled by the licensing processes or by voluntary
revocation of certificates (assuming some administrative mechanism is in place to
support this). For vehicles this represents a substantially larger problem. First there
are many more vehicles retired every year than RSUs (about 10 M to 15 M vehicles
go out of service each year). Second, unlike RSUs, vehicles are not site licensed, so
implementing and enforcing any sort of administrative control and retirement
processes is problematic. Not only does this make it difficult to revoke every retired
unit, but such a revocation level would swamp the certificate revocation list and
would overwhelm the OBU (which needs to download, maintain and use the
revocation list). Ideally the OBU should be coded to the vehicle at certification, and
some provision should be made such that if the OBU is activated in the absence of
its host vehicle it erases its certificates and must be re-certified. This type of
approach or something of a similar nature will allow for a second-hand parts
market, but will avoid the need for keeping track of which units are in service and
also will avoid a huge revocation list.
Recommendation: See Gap 13 above.
2.4.5. Revoked Device Management
Gap 15: Requirements for Revoked Device Behavior
Currently there is no provision for and no requirements associated with how
connected vehicle terminal equipment is to behave when its certificates are revoked.
If nothing is done the unit will continue to transmit messages that will then be
ignored by a receiver that finds that unit’s credentials on the CRL. A more efficient
approach would be to have units that determine they are on the CRL or are
13
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
otherwise misbehaving to remove themselves from service by transitioning to quiet
mode where no messages are transmitted. This is not a critical issue, but it would
make for a more orderly system and would potentially provide a mechanism for
identifying true bad actors, since only bad actors would fail to remove themselves
from the system.
Recommendation: Develop a requirement for devices to turn themselves off after
certificate revocation.
2.4.6. Bootstrap and Device Certification
Gap 16: Security Credential Management System Design Is Not Deployment Ready
The current Security Credential Management System (SCMS) includes a variety of
inconsistencies and known issues. For example:
A. There is uncertainty about the scope of pseudonym certificates. One
interpretation of the security standard is that certificates are associated with
only a single application. However, if this is the case, then each vehicle will be
required to support a full set of certificates for each application that requires
pseudonym certificates (there are currently five such applications identified
in the SAE Message sets). This approach will result in much larger revocation
lists and substantially more SCMS activity that currently envisioned. The
alternate interpretation is that each pseudonym certificate will include
permissions for all applications installed in the vehicle that require
anonymity. While this is a simple approach in concept, and it substantially
reduces the number of certificates and the size of the revocation list, it carries
the added burden that the vehicle system must be re-certified when new
software is installed. While this is useful from a platform assurance
perspective (See Gap 15), the details of such application related certification
have not been worked out.
B. Related to the above issue, the Safety Pilot SCMS bootstrap process did not
include methods to limit the capabilities for certificates requested from
devices authorized using a specific bootstrap ID. For the Safety Pilot, a valid
bootstrap ID authorized a device to request any certificates that the SCMS
was configured to produce.
C. The Safety Pilot bootstrap ID process was an ad hoc approach meant to
overcome a security weakness exposed by the fact that the bootstrap process
would not occur via a secure connection to the SCMS. The implications of
requiring a secure hardwired interface for bootstrap processing have not been
addressed.
14
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
D. The standards that define connected vehicle messages use PSIDs to restrict
the messages that can be authorized with a certificate. However, there is no
specific process for associating PSIDs with operations and connected vehicle
messages – this is a gap related to connected vehicle security management
rather than the certificate management system in particular. There are similar
gaps that are related directly to the certificate management system.
E. The SCMS does not include any specific features for managing information
about PSIDs. For example, the SCMS does not include a list of valid PSIDs, so
cannot verify that the PSIDs in a bootstrap or certificate request are valid. The
SCMS does not include features for implementing device-specific restrictions
based on PSIDs (as suggested previously).
F. The number of certificates installed each vehicle and the period of update for
these certificates as defined in the current (and rapidly evolving) security
design is such that moderate levels of revocation (resulting from moderate
levels of misbehavior, faults, and attacks) will produce a significantly large
revocation list (50MB to 150 MB). This large list may require excessive data
storage, and processing in the vehicles, and itself may present a viable denial
of service attack surface (create enough revocations that the system collapses
because the CRL is too large).
Counter arguments to these issues include a variety of inconsistencies. For example,
one argument is that the level of revocation is likely to be so low that the CRL will
never become significantly large. But, if such a low level of revocation were to occur,
then there would hardly be any need to revoke any vehicles. In addition if the
system has a known limitation like this, then a simple attack is to cause enough
revocations that the system is overwhelmed. Others include the extension of the
certificate update period to avoid the need for frequent contact with the SCMS
(requiring numerous roadside units). However, the system already includes an
assumption that the CRL is updated daily, so there is already a requirement for
frequent SCMS contact. In addition, extending the update period means that
revoked units remain on the CRL for a longer time, causing the CRL to grow,
thereby requiring more memory, more processing and longer CRL download times.
There appear to be multiple parties involved in the security system design and the
design appears to be in flux as the system is changed to address newly identified
issues. It is unclear if this approach is convergent. As noted above, some changes are
taken to address issues and these changes invalidate basic system assumptions, or
create additional vulnerabilities.
Recommendation: The entire security system should be described in a single
definitive document and “frozen” for some period during which problems
15
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
associated with deployment feasibility, management feasibility, vulnerabilities, etc.
are identified by parties other than the designers of the system (so called “white hat”
attackers, for example). These vulnerabilities should then be addressed by a second
round of design, and the process repeated.
Gap 17: Misbehavior Reporting and Detection Processes Are Not Sufficiently
Defined, and May Not Be Effective
The current implementation of the certificate management system does not include
any capabilities related to misbehavior identification other than support methods
that allow devices to submit messages to the SCMS for misbehavior report
processing. These methods support submission of casual reports (i.e., samples of
messages) and suspicious messages. However, the SCMS does not include specific
processes for acting on these reports, such as:

Processes for reviewing casual reports to identify suspicious behavior.

Processes for reviewing reports of suspicious behavior and determining
whether the suspicious behavior (identified by the SCMS from casual reports
or from device reports of suspicious messages) warrants revocation of
certificates.
In fact, the entire process of misbehavior detection with connected vehicle messages
is not well understood.
Recommendation: Research is needed on how to identify misbehaving devices
before those methods can be implemented in both connected vehicle devices and the
certificate management system.
2.5. BACKHAUL NETWORK
Gap 18: IPv6 for Backhaul Not Yet Widely Accepted or Demonstrated
The current DSRC standards identify IPv6 as the mechanism for OBUs to generate
IP addresses on the fly and to exchange IP packets with an RSU. While there are no
complete system specifications (see Gap 1) the Safety Pilot system has required an
IPv6 backhaul as well. The VII Proof of Concept also used an IPv6 backhaul. This
approach has proven to be problematic for both of these systems since not all
backhaul networks support IPv6. Mechanisms to allow IPv6 tunneling through IPv4
networks are partially effective, but are complex to set up and have been observed
to suffer from a variety of performance and stability issues. Left unaddressed each
implementer will need to solve these problems themselves on a case-by-case basis,
with presumably inconsistent results.
Recommendation: It is unclear how to best address this issue. One approach might
be to define a specific mechanism to implement such tunnels and interfaces. Another
16
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
might be to define the architecture in such a way that the RSU maintains two related
IP sessions: An IPv6 session over-the-air with the OBU and an IPv4 session with the
remote server. Currently no standards or reference implementations that address
this issue exist. Regardless of the solution, there is no advantage to the current
approach that requires an end-to-end IPv6 link between the OBU and remote service
providers. This requirement should be revisited and modified to only require IPv6
where the capabilities of the standard add value.
2.6. MAPPING SUPPORT
Maps provide contextual information for many connected vehicle applications, and
for several applications lane geometry, stop bar locations, or speed limits are
critically important. Map content has always been a component of the connected
vehicle data stream, although there are several proposals for implementation. When
it is necessary for understanding or using hazard information, road geometry data
associated with point specific hazards could be included in the hazard messages
themselves since that way the hazard message is self-contained and usable without
external information (See Gap 10). Road geometry data that are not necessarily point
specific, for example wider area information or information about hazards well
ahead in the road network (See Gap 5) may be supported by larger scale
conventional road network maps, and this data may or may not be essential to
understanding and using the hazard information. Examples of this might include
receiving traffic information for a wide area, and then only presenting incidents to
the driver that actually lie on the intended route.
It is important to draw a distinction between map data, which typically represents
the road network, and the relationships between road segments (i.e., which road
segments are connected to which other road segments to form the road network)
and road geometry data, which represents accurate dimensional information about a
particular section of road or a particular feature on a road. Examples of this include
the locations of stop bars for intersection lane approaches, the curvature and superelevation of specific curved road segments, widths and heights of tunnels and other
partial barriers, etc. These features lie on road segments, and therefore are associated
with the road and possibly with a larger road network map, but they are more or
less independent of each other. They represent data about specific locations that may
also be included on the larger road network map. These two types of data are often
confused with one another, a situation made worse by the fact that the SAE J2735
message set uses the term MAP for the geometric road data message. For purposes
of this discussion we will use the term map when referring to road network
databases and information that relates to the larger scale road network and road
geometry when referring to roadway dimensional and feature data.
17
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
2.6.1. Road Geometry Data Standards
Gap 19: No Requirements for Road Geometry Content and no Standards for
Accuracy
Roadway geometry data for locations related to safety messages will be location
specific, and thus must be produced for each situation. The data content and
accuracy must be consistent between providers if the data is being provided from
multiple sources (e.g. commercial map companies). If the data is provided
individually by each jurisdiction responsible for each road area, for example as part
of a warning message, the data content and accuracy must be consistent across
jurisdictions, regardless of how the data was generated (i.e., locally, commercially,
etc.).
Recommendation: Specify and implement standards for road geometry data content
and accuracy for specific types of roadway features. Consider establishing some
form of validation process to assure that road geometry data meet these standards.
2.6.2. Map Message Content
Gap 20: Current SAE J2735 MAP Message Standard is Incomplete and Inflexible
The J2735 MAP message specification is limited generally to intersection approach
data. It provides some support for 3D geometry (i.e., overpasses), but does not
support bank angles, surface conditions, and many other road geometry or
dimensional attributes that one may need to support a connected vehicle
application. The standard alludes to future content, but this content is not yet
developed, and it appears that the plan is to develop a variety of different message
types to address specific road situations.
This will limit the opportunities for many applications requiring road geometry
data, such as Curve Speed Warning, toll/lane payment zone definition, border
crossing and freight management lane directions, etc. Furthermore, specifications for
accuracy and integrity do not exist, so receiving such data, even in the existing MAP
message gives no assurance that data received from one location will be of the same
accuracy or integrity as that received at another location.
Recommendation. Consider revising existing message standards to provide an
extensible format that allows efficient provision of identified road elements and the
dimensional/geometric parameters associated with them. Without specifying the
solution in too much detail, it may be much more efficient and flexible to convert
from the current fixed structured format for each type of roadway element (e.g.
intersection geometry message, road curve message, etc.) to defining a road
geometry data object that has a variety of attributes that can be dynamically
identified (for example, using an XML tag approach). If a suitable schema of possible
18
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
road attributes is defined, then one can convey the appropriate road geometry
elements and their values in a single message type, but that message type can
support an unbounded array of different roadway situations and structures. It can
also be easily extended as new structures are created (for example, dedicated lanes
and entry points for automated vehicles).
2.6.3. Road Geometry Data Maintenance
Gap 21: Dynamic Updating of Road Geometry Data
In many cases the degree of accuracy of road geometry data required for a particular
application may not be high. This is especially true for situations where the
geometric feature is not defined by construction, such that the feature may change
relatively quickly. For example if a specific lane is closed, then it may be desirable to
alert approaching motorists that the “right lane is closed, merge left.” However to
determine this requires considerable human resources to identify locations where
such transient hazards may exist, and to then determine the geometric changes
required.
It appears that it may be feasible to capture such information from vehicle probe
data instead. This allows the simultaneous detection of road geometry changes and
the quantification of those changes with minimal human staff involvement. Ideally
such an approach would simply require human validation and approval of
automatically generated road geometry data (particularly for road data that does not
require survey grade accuracy and that may change rapidly).
Recommendation: Determine how quickly road geometry features may change, and
how many changes are likely to occur (to assess the approximate cost of human
detection and updates). Determine the required dimensional accuracy and required
integrity for these measurements, and assess the feasibility of using probe data to
automatically detect and generate such updates. Identify requirements for validation
and authentication of the data and the updates.
2.7. INTERNATIONAL LAND BORDER CROSSINGS
2.7.1. Organizational and Technical Capabilities
Gap 22: International Coordination
Adoption and deployment of Connected Vehicle technology at international border
crossings (IBC) will rely on collaboration and coordination between agencies in the
U.S., Canada and Mexico. To meet the needs of stakeholders at IBCs, fullycoordinated inter-jurisdictional systems are required. While technology may not be
the barrier, institutional issues certainly may. In addition, agencies within a country
(e.g., federal and state agencies) will have to coordinate and collaborate to share data
19
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
on agreeable terms and conditions. Working groups such as the US-Canada
Transportation Border Working Group (TBWG) and the US-Mexico Joint Working
Committees (JWC) will have to play a pivotal role to ensure coordination at all levels
of government, as well as to frame policies and funding mechanisms to plan and
deploy Connected Vehicle technology at IBCs.
Recommendation: Ensure groups such as the US-Mexico JWC and TBWG start
formally discussing policies, collaborative opportunities, and applications related to
Connected Vehicle technology at IBCs.
Gap 23: Unbalanced Cross-Border Capabilities
When it comes to implementing technology systems at the borders, Canada and the
United States are ahead of Mexico. US and Canadian agencies have experience in
planning, developing, and maintaining ITS at IBCs; specifically wait time
measurement systems. It may be assumed that Mexico will require significant
assistance in identifying funding, as well as developing technical capabilities to
operate and maintain the necessary systems at IBCs.
Recommendation: Explore mechanisms for assessing cross-border capabilities and
for facilitating development of IBC systems.
2.7.2. Border Information Flow Architecture
Gap 24: Border Information Flow Architecture (BIFA) is Inconsistent with ITS
National Architecture
In 2005, the FHWA in cooperation with Transport Canada developed the Border
Information Flow Architecture (BIFA) to assist agencies in planning deployment of
ITS applications at IBCs. BIFA identifies the needs of stakeholders on both sides of
the US-Canada border regarding wait time measurement, approach management
etc. However, the architecture has not kept up to date with both countries’ National
ITS architectures.
An architecture similar to BIFA does not exist for the US and Mexico. There are
however plans to develop one. There are also plans to revise/update Mexico’s
National ITS architecture, which will consider stakeholder needs at IBCs.
Recommendation: Add a Vehicle Short Range Traveler Information equipment
package to BIFA to allow in-vehicle signage (e.g., to display roadway signs specific
to border crossings on on-board equipment using DSRC).
2.7.3. Physical and Communication Security
Gap 25: No Established Standards for Cross-Border Information Exchange and
Information Security
20
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
Sharing data between agencies in different countries requires the agencies to agree
on data exchange protocols, standards, and data transmission security. While
countries may adopt existing Center to Center (C2C) standards and protocols as
provided in BIFA and/or their respective ITS architectures, it is not clear what kind
of data transmission security will be agreeable to these agencies. Because the
proposed application is not safety related, it is anticipated that the security
requirements for transmission of wait times and related data may not be stringent.
Therefore, some level of data encryption and server firewalls should be expected.
The IBC applications are not related to a vehicle’s or occupant’s safety; hackers and
intruders posting false wait time messages may not be a direct safety risk. However,
such incidents are undesirable since they might disrupt the flow of traffic through
IBCs. In the absence of proper security apparatus, hackers may use RSEs and/or
wireless communication links to gain access to other RSEs that are part of safety
applications.
Physical security of RSEs at border crossings, especially in Mexico is a concern, if
they are to be located at locations where there are no commercial activities. Batteries,
solar panels, and communication equipment inside the cabinets are targets for thefts.
Given the geographic scope requirements to enable a seamless data exchange, and
the mobility of vehicles across the international border, it is anticipated that security
of data communication between bi-national agencies should be designed and
implemented as a single multi-national North American system. As a result,
individual states and provinces will not be required to setup independent security
systems/models and responsibility for design and implementation of the security
standards will be incumbent upon federal agencies. The role of state and local
agencies in system security can be primarily centered on providing connectivity
from roadside devices to the network, and security of data collected locally.
Recommendation: Establish North American data exchange policies and security
framework.
2.7.4. Bi-National Data Exchange Protocols and Standards
Gap 26: No Established Standards for Cross-Border Real-time Information
Exchange
A recent study performed by Texas A&M Transportation Institute with funding
from United States Department of Transportation showed that there are no binational real-time data exchange standards/protocols between Mexico, Canada, and
the US systems. Connected Vehicle technology deployments at border-crossings will
require systems in US communicating to their counterparts in Mexico and Canada.
21
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
The majority of large IBCs on both the US-Canada and US-Mexico borders have
sophisticated communication technology, including fiber optics, that connect toll
systems, dynamic message signs, etc. to traffic management centers. These centers
should be one of the key components of deploying the proposed connected vehicle
applications at IBCs. Data exchange protocols (e.g., frequency of data transmission,
refresh rates, exceptions handling) between TMCs in each country will have to be
agreed upon. Fortunately, both Canada and Mexico use or are committed to use the
same C2C and Center to Field (C2F) standards as adopted by US.
Recommendation: To facilitate real-time data sharing between two countries,
establish C2C standards with support for translation of attributes into different
languages.
2.8. POLICY/GOVERNANCE GAPS
Policy/Governance gasp relate to areas that are not necessarily subject to technology
or implementation shortcomings, but instead arise from issues associated with
organizational structure and rules, or represent complex organizational or legal
interdependencies. Policy and governance gaps may be filled by identifying and
describing organizational roles, responsibilities and processes by creating the
needed organizations (if they do not already exist), and by developing the legal and
management structures to address these non-technical issues.
2.8.1. Infrastructure Data Business Models
Gap 27: Business Models for Connected Vehicle Data Have Not Been Developed or
Validated
Gap 28: No Obvious Incentive for Data Providers to Provide Data beyond Any
Mandate
There are a variety of existing businesses established around traffic data over the
past 20 years. Some of these have been more successful than others. Currently these
businesses focus almost exclusively on traffic travel time and incident data, together
with a few other commercial data elements such as location-based fuel prices. These
businesses exist today with no connected vehicle system. It is unclear if these
businesses can or will collect the types of data that would be of most benefit to
AASHTO members. Assuming that the connected vehicle system can produce other
useful data and provide useful applications for AASHTO members, there is a need
to a) identify that data, b) understand how the connected vehicle system business
models fit into the existing road data market, and c) identify, at least conceptually,
what sort of value chains and business arrangements are most likely to work, given
the value chain participants (vehicle makers, vehicle users, wireless carriers or DSRC
deployers, data collectors and aggregators and data users). These value chains are
22
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
likely to be indirect, since those paying for collection hardware and/or
communications may not be the same parties that directly benefit from the collection
of this data. Understanding the benefit relationships, and being able to articulate the
value proposition is a critical element of justifying deployment expenditures and
assuring that the overall market can support the system. Currently these
motivations and relationships are assumed, but have not been sufficiently defined to
test if these assumptions are valid.
Recommendation: Develop a conceptual business model that illustrates the end-toend value chain (who provides what and what they get back in return) for vehicle
data. This model would then illustrate the motivations for each party to participate
in the value chain. This model would include models for the manufacture and
deployment of connected vehicle equipment, and models for the ongoing operations
and maintenance of that equipment. These models should clearly identify both
explicit exchanges of tangible value elements (e.g., money for goods and services) as
well as monetized implicit exchanges of intangible value elements (e.g., “soft
factors” such as reduced risk, avoided losses or costs, etc.) to provide a
comprehensive description of which parties are expected to do what in the
connected vehicle economic ecosystem, and what each of those parties can expect to
receive from the system. Using this framework together with existing cost-benefit
analyses it will then be possible to identify areas where the costs and benefits are
unbalanced (in value or in time) for any given party, and the model or the system
can be adjusted to compensate for this.
2.8.2. RSU Management and Access Requirements
Gap 29: RSU Management Access and Security Requirements Not Defined
Currently the requirements for physical and logical access control for RSUs (and
OBUs) are not defined. This may be a policy issue that is at the discretion of the
implementing jurisdiction. However, since vehicle users are likely to encounter
RSUs deployed by a wide variety of jurisdictions, such policies should include
provisions for authenticating the sources of information, and securing the channels
over which this information is provided. Lacking this, each implementing
organization would need to define and implement these aspects independently.
Recommendation: Study and develop policy recommendation to determine if a
uniform policy is necessary. If so, develop policy and requirements and identify
where this policy should reside (e.g. MUTCD, AASHTO Green Book, or other
equivalent).
2.8.3. Cross Border Identified Certificate Administration
23
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
Gap 30: No Established International Passenger Vehicle Certificate Information
Exchange Platform
OBEs are issued certificates on a periodic basis over the air and from the back-office
systems responsible for distribution of such certificates. These certificates are used to
validate their presence on the network and enable V2V as well as V2I
communications between other authorized devices and users. RSEs also require
security certificates in order to validate communications from authorized vehicle
equipment and maintain valid secure connection with back-office systems.
For the proposed IBC applications, agencies responsible for operations will need to
identify the OBEs registered in another country when those vehicles cross the
border. For example, when Canadian registered vehicles are waiting to cross back
into Canada from the US, RSEs installed on the US side will have to identify OBEs
registered in Canada. This will require Canadian provinces to share certificate
information with the US. This will require a policy decision and agencies may face
public concerns regarding privacy issues.
Registration information for commercial vehicles is already shared between the US
and Mexico and the US and Canada at the federal level. Prior to a commercial
vehicle’s entry at a border they submit an electronic manifest to customs agencies.
These manifests contain detailed information on drivers and owners of those
vehicles, including their operating authority.
In the US, CBP would have to share a portion of these electronic manifests with state
agencies operating the proposed application. Similarly, in Canada, CBSA will have
to do the same with provincial agencies operating the proposed application. In
Mexico, the situation is slightly different since the federal government operates and
maintains all aspects of IBCs that may include federal roadways connecting with
IBCs.
On the other hand, privately operated vehicles are not required to submit electronic
manifests to customs agencies prior to their arrival at the border. In addition,
registration information of personal vehicles is not shared with agencies from
neighboring countries. However, individuals participating in trusted traveler
programs such as SENTRI and NEXUS do register their vehicles with customs
agencies. However, such vehicles constitute a very small portion of the overall
population of vehicles crossing the border.
Recommendation: Establish bi-national vehicle certificate information exchanges.
2.8.4. Deployment Goals and Strategy
Gap 31: No Consensus on Public and Private Sector Roles in Deployment
24
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
There appear to be multiple competing visions of how the Connected Vehicle system
may be deployed. At one extreme some stakeholders argue for and promote a
hybrid organic approach involving an undefined mix of public and private
activities. At the other extreme, a few stakeholders argue that the system should be
entirely publicly funded and defined through a top down process. Neither of these
visions is supported by concrete strategies that include the concurrence of those who
would be required to deploy the system or provide the funds. For example, it is
suggested that the connected vehicle system represents a commercial opportunity,
yet few commercial entities have articulated their interest in this opportunity.
Analysis of a commercial implementation raises questions about the feasibility of a
commercial entity providing applications to serve the public good unless the
government pays for these services. The long running discussion of this issue has
slowed progress toward deployment, and may continue to do so.
Recommendation: Develop a set of basic governance principles for the connected
vehicle system(s), and focus industry and government efforts on those approaches
that are consistent with the principles.
25
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
APPENDIX A. ACRONYMS
ABS
Antilock Braking System
AACN
Advanced Automatic Crash Notification
AASHTO
American Association of State Highway and Transportation
Officials
AERIS
Applications for the Environment: Real-Time Information
Synthesis
ASC
Adaptive signal control
ATIS
Advanced Traveler Information Systems
AVI
Automatic Vehicle Identification
BIFA
Border Information Flow Architecture
BMM
Basic Mobility Message
BSM
Basic Safety Message
BWT
Border wait time
C2C
Center-to-center
C2F
Center-to-field
CACC
Cooperative Adaptive Cruise Control
CBP
Customs and Border Protection
CBSA
Canadian Border Safety Administration
CCTV
Closed caption television
CDMA
Code Division Multiple Access
CE
Consumer electronic
CICAS
Cooperative Intersection Collision Avoidance System
26
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
COV
Commercially-operated vehicle
CSMA
Carrier sense multiple access
CVISN
Commercial Vehicle Information Systems and Networks
CVRIA
Connected Vehicle Reference Implementation Architecture
DHCP
Dynamic Host Configuration Protocol
DMA
Dynamic Mobility Applications
DMS
Dynamic message sign
DOT
Department of Transportation
DRG
Dynamic Route Guidance
D-RIDE
Dynamic Ridesharing
DR-OPT
Drayage Optimization
DSL
Digital subscriber line
DSRC
Dedicated Short Range Communications
ESS
Environmental sensor station
ETC
Electronic toll collection
[EV] DRG
Dynamic Routing of Emergency Vehicles
EVAC
Emergency Communications and Evacuation
F-ATIS
Freight Real-time Traveler Information with Performance
Monitoring
FCC
Federal Communications Commission
F-DRG
Freight Dynamic Route Guidance
FHWA
Federal Highway Administration
FMCSA
Federal Motor Carrier Safety Administration
27
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
FRATIS
Freight Advanced Traveler Information Systems
FSP
Freight Signal Priority
GID
Geometric intersection description
GIS
Geographic Information System
GNSS
Global Navigation Satellite Systems
GPS
Global Positioning System
GSM
Global System for Mobile Communications
HAR
Highway advisory radio
HAZMAT
Hazardous material.
HOT
High Occupancy Tolling
I2V
Infrastructure-to-vehicle
IBC
International Border Crossing
IDTO
Integrated Dynamic Transit Operations
INC-ZONE
Incident Scene Workzone Alerts for Drivers and Workers
INFLO
Integrated Network Flow Optimization
IP
Internet Protocol
I-SIG
Intelligent Traffic Signal System
ITIS
International Traveler Information Systems
ITS
Intelligent Transportation Systems
ITS JPO
Intelligent Transportation Systems Joint Program Office
LAN
Local area network
LPR
License Plate Reader
28
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
LTE
Long-term Evolution; a type of 4G cellular network
M-ISIG
Multi-Modal Intelligent Traffic Signal System
MDSS
Maintenance Decision Support System
MHz
Megahertz
MMITSS
Multi-Modal Intelligent Traffic Signal System
MS
Mobile station
MTBF
Mean time between failures
MTU
Maximum Transmission Unit
MUTCD
Manual on Uniform Traffic Control Devices
NCFRP
National Cooperative Freight Research Program
NHS
National Highway System
NHTSA
National Highway Traffic Safety Administration
NTCIP
National Transportation Communications for ITS Protocol
OBD
On-board diagnostics
OBU
On-board Unit
PED-SIG
Mobile Accessible Pedestrian Signal System
PKI
Public key infrastructure
POE
Point/Port of Entry
PoE
Power over Ethernet
POV
Privately-operated vehicle
PREEMPT
Emergency Vehicle Preemption with Proximity Warning
Q-WARN
Queue Warning
29
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
RAMP
Next Generation Ramp Metering System
RAP
Roadside access point
RDE
Research Data Exchange
RESP-STG
Incident Scene Pre-Arrival Staging and Guidance for
Emergency Responders
RF
Radio frequency
RFID
Radio frequency identification
RITA
Research and Innovative Technology Administration
RSU
Roadside Unit
RTCM
Radio Technical Commission for Maritime Services
RWIS
Road Weather Information System
SDARS
Satellite Digital Audio Radio Service
S-PARK
Smart Park and Ride
SPAT
Signal phase and timing
SPD-HARM
Dynamic Speed Harmonization
TCONNECT
Connection Protection
T-DISP
Dynamic Transit Operations
TFE
Transportation field equipment
TIS
Transportation information system
T-MAP
Universal Map Application
TBD
To Be Determined
TMC
Traffic Management Center
30
National Connected Vehicle Field Infrastructure Footprint Analysis
Design Gaps Analysis
TSA
Transportation Security Administration
TSP
Transit Signal Priority
USDOT
United States Department of Transportation
V2I
Vehicle-to-infrastructure
V2V
Vehicle-to-vehicle
VII
Vehicle Infrastructure Integration
VIN
Vehicle Identification Number
WIM
Weigh-in-Motion
WAN
Wide area network
WAVE
Wireless Access in Vehicular Environments
WLAN
Wireless local area network
WSM
WAVE Short Message
WSMP
WAVE Short Message Protocol
WWAN
Wireless wide area network
WX
Weather
WX-INFO
Real-Time Route Specific Weather Information for Motorized
and Non-Motorized Vehicles
WX-MDSS
Enhanced MDSS Communication
31