ISSN 1055- 1425
April 2010
This work was performed as part of the California PATH Program of the
University of California, in cooperation with the State of California Business,
Transportation, and Housing Agency, Department of Transportation, and the
United States Department of Transportation, Federal Highway Administration.
The contents of this report reflect the views of the authors who are responsible
for the facts and the accuracy of the data presented herein. The contents do not
necessarily reflect the official views or policies of the State of California. This
report does not constitute a standard, specification, or regulation.
Final Report for Task Order 6214
CALIFORNIA PATH PROGRAM
INSTITUTE OF TRANSPORTATION STUDIES
UNIVERSITY OF CALIFORNIA, BERKELEY
ITS Band Roadside to Vehicle
Communications in a Highway Setting
UCB- ITS- PRR- 2010- 17
California PATH Research Report
Susan Dickey, Jared Dulmage,
Ching- Ling Huang, Raja Sengupta
CALIFORNIA PARTNERS FOR ADVANCED TRANSIT AND HIGHWAYS
Caltrans Contract 65A0206, Task Order 6214:
( Continuation of T. O. 5214)
Caltrans report number: CA10- 0817
UC report number: UCB- ITS- PRR- 2010- 17
April 2010
ITS Band Roadside to Vehicle Communications
in a Highway Setting
Final Report
Susan Dickey
California PATH, University of California, Berkeley
Jared Dulmage
Department of Electrical Engineering, University of California, Los Angeles
Ching- Ling Huang, Raja Sengupta
Department of Civil and Environmental Engineering, University of California, Berkeley
Traffic Signal
Transit Vehicle
Transit Vehicle Stop
up to 1000 ft
Not to Scale
Landscaped divider
Collision
Avoidance
E- Transaction: gas, toll, etc
Transit Signal Priority
Gas Pumps
IDB Data
Transfer
Appendix 3
STATE OF CALIFORNIA DEPARTMENT OF TRANSPORTATION
TECHNICAL REPORT DOCUMENTATION PAGE
TR0003 ( REV. 10/ 98)
1. REPORT NUMBER
CA10- 0817
2. GOVERNMENT ASSOCIATION NUMBER
3. RECIPIENT’S CATALOG NUMBER
5. REPORT DATE
April 2010
4. TITLE AND SUBTITLE
ITS Band Roadside to Vehicle Communications in a Highway
Setting ( Continuation) 6. PERFORMING ORGANIZATION CODE
7. AUTHOR( S)
Susan Dickey, California PATH, University of California, Berkeley
Jared Dulmage, Department of Electrical Engineering, University of
California, Los Angeles
Ching- Ling Huang and Raja Sengupta, Department of Civil and
Environmental Engineering, University of California, Berkeley
8. PERFORMING ORGANIZATION REPORT NO.
UCB- ITS- PRR- 2010- 17
10. WORK UNIT NUMBER
9. PERFORMING ORGANIZATION NAME AND ADDRESS
California PATH, University of California
Berkeley, CA
http:// www. path. berkeley. edu/
11. CONTRACT OR GRANT NUMBER
65A0208 TO 6214
13. TYPE OF REPORT AND PERIOD COVERED
Final
12. SPONSORING AGENCY AND ADDRESS
California Department of Transportation
Division of Research and Innovation, MS- 83
1227 O Street
Sacramento CA 95814
14. SPONSORING AGENCY CODE
15. SUPPLEMENTAL NOTES
16. ABSTRACT
Researchers investigated the testing and evaluation of radio and communication protocol standards for the
5.9 GHz spectrum that has been approved by the Federal Communications Commission for exclusive
transportation use. This spectrum allocation is intended for use as Dedicated Short Range Communications
( DSRC) in the context of high- value Intelligent Transportation Systems ( ITS) applications. In this report, we
summarize the Wireless Access in a Vehicular Environment ( WAVE) standardization effort for 5.9 GHz
DSRC, its current status, and related issues of the IEEE 802.11p and IEEE 1609 family of standards. We
also present an overview of current DSRC development activities in the world context, in the United States,
and in California, describing and comparing some of the current commercial implementations. To verify the
performance of DSRC prototype radios, we conducted a series of testing in different scenarios. A physical
layer simulation and FPGA testbed was developed at the UnWiReD Lab, University of California, Los
Angeles, and a software applications programming interface ( API) used in tests with different commercial
hardware was developed at California PATH, UC Berkeley. The WAVE standards effort, in which we
participated, is described, and testing procedures and results are presented. An architecture for DSRC
testbeds for safe intersections is reported, focusing on the hardware/ software issues, performance and
possible future enhancements. Finally, a user‘ s guide to our developed software for testing DSRC/ WAVE
systems is provided as an appendix.
17. KEY WORDS
Wireless Access in Vehicular Environments ( WAVE),
Dedicated Short Range Communications ( DSRC),
radio, telecommunications, wireless vehicular networks,
roadside infrastructure, testbeds and simulation
platforms, 802.11p, IEEE 1609, roadside to vehicle
communications, 5.9 GHz Band, Intelligent
Transportation Systems Radio, IntelliDrive, VII
18. DISTRIBUTION STATEMENT
No restrictions. This document is available to the
public through the National Technical Information
Service, Springfield, VA 22161
19. SECURITY CLASSIFICATION ( of this report)
Unclassified
20. NUMBER OF PAGES
􀀔 􀀔 􀀙
21. PRICE
ii
iii
Acknowledgments
This is the final report of the project “( Continuation of T. O. 5214) ITS Band Roadside to Vehicle
Communications in a Highway Setting”, which was sponsored by the Department of
Transportation of California ( Caltrans) under Task Orders 5214 and 6214. We would like to
acknowledge the Project Manager for Caltrans, Gloria Gwynne, Senior Transportation Electrical
Engineer, Office of Technology Applications, and Ramez Gerges, Chief, Office of
Communication Systems, Caltrans Department of Research and Innovation, for their technical
insights and tremendous organizational support. We are also grateful to John Slonaker, Caltrans
Senior Transportation Electrical Engineer, DRI, and Ed Fok, FHWA Resource Center, San
Francisco, for their participation in project reviews and helpful comments. We would like to
thank ARINC Corp for providing the equipment used in the testing described in Section 3.2, and
express our appreciation for the visionary enthusiasm, engineering skill and years of effort that
Broady Cash, as an engineer at ARINC, gave to the establishment of DSRC/ WAVE
communications for vehicle safety.
Disclaimers
The contents of this report reflect the views of the authors who are responsible for the facts and
the accuracy of the data presented herein. The contents do not necessarily reflect the official
views or policies of the State of California. This report does not constitute a standard,
specification or regulation.
The State of California does not endorse products or manufacturers. Trade and manufacturers’
names appear in this report only because they are considered essential to the object of the
document.
vi
v
Abstract
Under Caltrans Task Orders 5214 and 6214, researchers at UC Berkeley and UCLA investigated
the testing and evaluation of radio and communication protocol standards for the 5.9 GHz
spectrum that has been approved by the Federal Communications Commission for exclusive
transportation use. This spectrum allocation is intended for use as Dedicated Short Range
Communications ( DSRC) in the context of high- value Intelligent Transportation Systems ( ITS)
applications. In this report, we summarize the Wireless Access in a Vehicular Environment
( WAVE) standardization effort for 5.9 GHz DSRC, its current status, and related issues of the
IEEE 802.11p and IEEE 1609 family of standards. We also present an overview of current
DSRC development activities in the world context, in the United States, and in California,
describing and comparing some of the current commercial implementations. To verify the
performance of DSRC prototype radios, we conducted a series of testing in different scenarios.
A physical layer simulation and FPGA testbed was developed at the UnWiReD Lab, University
of California, Los Angeles, and a software applications programming interface ( API) used in
tests with different commercial hardware was developed at California PATH, UC Berkeley. The
WAVE standards effort, in which we participated, is described, and testing procedures and
results are presented. An architecture for DSRC testbeds for safe intersections is reported,
focusing on the hardware/ software issues, performance and possible future enhancements.
Finally, a user’s guide to our developed software for testing DSRC/ WAVE systems is provided
as an appendix.
Keywords: Wireless Access in Vehicular Environments ( WAVE), Dedicated Short Range
Communications ( DSRC), radio, telecommunications, wireless vehicular networks,
roadside infrastructure, testbeds and simulation platforms.
vi
i
Caltrans Task Order 6214:
( Continuation of T. O. 5214)
ITS Band Roadside to Vehicle Communications
in a Highway Setting
Final Report
Susan Dickey
California PATH, University of California, Berkeley
Jared Dulmage
Department of Electrical Engineering, University of California, Los Angeles
Ching- Ling Huang, Raja Sengupta
Department of Civil and Environmental Engineering, University of California, Berkeley
ii
iii
Acknowledgments
This is the final report of the project ―( Continuation of T. O. 5214) ITS Band Roadside to Vehicle
Communications in a Highway Setting‖, which was sponsored by the Department of
Transportation of California ( Caltrans) under Task Orders 5214 and 6214. We would like to
acknowledge Gloria Gwynne, Caltrans Senior Transportation Electrical Engineer and the
manager for this project, Homar Noroozi, Chief, Office of Technology Applications, and Ramez
Gerges, Chief, Office of Communication Systems, Caltrans Department of Research and
Innovation, for their technical insights and tremendous organizational support. We are also
grateful to John Slonaker, Caltrans Testbed Center for Interoperability, UC Santa Barbara, and
Ed Fok, FHWA Resource Center, San Francisco for their participation in project reviews and
helpful comments. We would like to thank ARINC Corp for providing the equipment used in the
testing described in Section 3.2, and express our appreciation for the visionary enthusiasm,
engineering skill and years of effort that Broady Cash, as an engineer at ARINC, gave to the
establishment of DSRC/ WAVE communications for vehicle safety.
iv
v
Abstract
Under Caltrans Task Orders 5214 and 6214, researchers at UC Berkeley and UCLA investigated
the testing and evaluation of radio and communication protocol standards for the 5.9 GHz
spectrum that has been approved by the Federal Communications Commission for exclusive
transportation use. This spectrum allocation is intended for use as Dedicated Short Range
Communications ( DSRC) in the context of high- value Intelligent Transportation Systems ( ITS)
applications. In this report, we summarize the Wireless Access in a Vehicular Environment
( WAVE) standardization effort for 5.9 GHz DSRC, its current status, and related issues of the
IEEE 802.11p and IEEE 1609 family of standards. We also present an overview of current
DSRC development activities in the world context, in the United States, and in California,
describing and comparing some of the current commercial implementations. To verify the
performance of DSRC prototype radios, we conducted a series of testing in different scenarios.
A physical layer simulation and FPGA testbed was developed at the UnWiReD Lab, University
of California, Los Angeles, and a software applications programming interface ( API) used in
tests with different commercial hardware was developed at California PATH, UC Berkeley. The
WAVE standards effort, in which we participated, is described, and testing procedures and
results are presented. An architecture for DSRC testbeds for safe intersections is reported,
focusing on the hardware/ software issues, performance and possible future enhancements.
Finally, a user‘ s guide to our developed software for testing DSRC/ WAVE systems is provided
as an appendix.
Keywords: Wireless Access in Vehicular Environments ( WAVE), Dedicated Short Range
Communications ( DSRC), radio, telecommunications, wireless vehicular networks,
roadside infrastructure, testbeds and simulation platforms.
vi
vii
Executive Summary
The Wireless Access in Vehicular Environments ( WAVE) Amendment P to the IEEE 802.11
Wireless LAN standard is currently in the last stage of sponsor ballot and is expected to receive
final approval by fall 2010. Implementations of 802.11p will support the U. S. Department of
Transportation‘ s Intelligent Transportation Systems ( ITS) Program and the Federal Highway
Authority‘ s IntelliDrive SM Initiative. These automotive networking services will operate in a
special licensed Dedicated Short Range Communication ( DSRC) 5.9 GHz frequency band that
has been allocated by the Federal Communications Commission ( FCC) for use in transportation,
with emphasis on safety of life and public safety. With Task Orders 5214 and 6214, Caltrans
sponsored ground- breaking research that has prepared California to take advantage of this
exciting new technology.
Section 1 describes a simulation and FPGA- based testbed of the WAVE/ DSRC physical
Orhogonal Frequencey Data Multiplexing ( OFDM) physical layer in the 5.9 GHz band that was
designed and implemented as part of Task Orders 5214 and 6214. This testbed demonstrated the
use of an integrated set of Commercial Off- the- Shelf ( COTS) tools enabling rapid and intuitive
progression through development stages. The common simulation and automated hardware
testing environment realized time- savings in both development and debugging through the reuse
of test benches across several stages of the research and evaluation process. This toolchain and
methodology provides a cost- effective method to develop testbeds for conformance testing of
vendor products, to evaluate evolving standards specifications, and to facilitate development and
testing of novel wireless algorithms in a real- world environment. Descriptions of this testbed and
of OFDM model results obtained as part of this work have appeared in the proceedings of ACM
WiNTech 2006 and IEEE Tridentcom 2007.
Section 2 of this report describes the DSRC standardization effort, including IEEE 802.11p and
IEEE 1609 family standards, in which Caltrans participated as a part of this project. The IEEE
P1609 family standards address functionalities above the physical ( PHY) and medium access
( MAC) layer that have been designed for communications in a ground transportation setting.
Current status and related issues of those standards are also discussed in Section 2. While the
standards effort has lagged behind the initial expectations of the ITS community, and the initial
US DOT projections for deployment were over- optimistic, the work that has been carried out
over the past 6 years has explored many important issues and provides a solid foundation for
deployment.
In Section 3, we first provide an overview of DSRC development in the world context, in the
U. S., and in the California. Since analysis and simulations cannot accommodate the full
complexity of practical systems with large numbers of vehicles in close proximity, we conducted
radio testing using prototype 802.11p/ WAVE equipment. The second part of Section 3 presents
our testing procedures and results on DSRC performance. We used inexpensive computer
hardware with prototype radios to explore performance issues for multiple On- Board Units
( OBUs, radios in the vehicles) approaching a Road Side Unit ( RSU). In the third part of Section
3, we describe DSRC testbed architecture for safe intersections. Implications for the future, when
the intersection crash problem may be addressed through dynamic red light running
countermeasures and other DSRC- enabled systems that ― talk‖ ( in a data sense) between the
intersection and car are multi- fold. Parts of the research results presented in Section 3 have
viii
appeared in the Handbook on Vehicular Networks, in the proceeding of the 1st IEEE
International Symposium on Wireless Vehicular Communications, and in the proceedings of the
Transportation Research Board, January 2008.
In Appendix A, a user guide and web references are provided for our developed software. This
guide has been written to describe the software originally developed as part of Caltrans Task
Orders 5214 and 6214. This software is currently running on the Kapsch/ Technocomm
Multiband Configurable Networking Unit and on the Savari Networks Mobiwave On- board Unit
that have been used as part of the Safetrip 21 and VII California projects. Porting of this software
to the Denso Wireless Safety Unit is underway as part of the FHWA Exploratory Advanced
Research Program ― Development and Evaluation of Selected Mobility Applications for VII.‖
This software is also being used as the underlying layer for sending SAE J2735 messages in a
joint project with an automobile OEM to study the use of Signal Phase and Timing ( SPAT)
messages for in- vehicle fuel economy applications. Note that, our WAVE API is documented in
a separate user manual available on the software web site.
ix
Table of Contents
Contents
Acknowledgment ........................................................................................................................... iii
Abstract ............................................................................................................................... ........... v
Executive Summary ...................................................................................................................... vii
Table of Contents ........................................................................................................................... ix
1. A COTS Testbed for Rapid Algorithm Development, Implementation and Test of 5.9GHz
OFDM DSRC........................................................................................................................... ...... 1
1.1. Rationale for physical layer radio testbed ........................................................................ 1
1.2. Matlab and Simulink Implementation .............................................................................. 4
1.3. FPGA and Radio Hardware.............................................................................................. 8
1.4. Channel Model Research ................................................ Error! Bookmark not defined.
1.5. Contributions and Future Work ..................................................................................... 11
2. Standards Development for Wireless Access in Vehicular Environments ( WAVE) ........... 12
2.1 Introduction .................................................................................................................... 12
2.2 The FCC- approved DSRC frequency band .................................................................... 13
2.3 Amendment P to IEEE 802.11 ....................................................................................... 14
2.3.1 Fundamentals of IEEE 802.11 ................................................................................ 15
2.3.2 IEEE 802.11p History and Current Status .............................................................. 16
2.4 IEEE 1609 Family of WAVE Standards ........................................................................ 17
2.4.1 IEEE 1609 Trial Use Standards .............................................................................. 19
2.4.2 Current issues in IEEE 1609 WAVE ...................................................................... 22
2.4.2.1Timing Information .................................................................................................... 22
2.4.2.2Vendor Specific Action Frame ................................................................................... 23
2.4.2.3Transmission Power Constraint ................................................................................ 25
2.4.2.4Channel Switching and Time Alignment .................................................................... 25
2.4.2.5Service Initialization Decision Making ...................................................................... 27
2.4.2.6Resource Manager ..................................................................................................... 28
2.4.2.7Toll Transaction ......................................................................................................... 28
2.4.2.8Security ...................................................................................................................... 30
2.5 Summary ........................................................................................................................ 31
x
3. Architecture and Design of Vehicle- Infrastructure Testbeds for Dedicated Short- range
Communication ............................................................................................................................. 32
3.1 Overview of DSRC Development .................................................................................. 32
3.1.1 Introduction to Vehicle- Infrastructure Cooperation ............................................... 32
3.1.2 Development during 2004- 2008 ............................................................................. 34
3.1.2.1World Context ............................................................................................................ 34
3.1.2.2VIC in the United States ............................................................................................. 36
3.1.3 Making the US Technology Work – VII California Testbed ................................. 38
3.1.3.1Elemental Building Block within Network: Roadside Equipment ............................ 40
3.2 DSRC Testing Procedures and Results .......................................................................... 44
3.2.1 Introduction ............................................................................................................. 44
3.2.2 Computer and Radio Equipment ............................................................................. 45
3.2.3 Data Acquisition Software ...................................................................................... 45
3.2.4 Baseline Testing ...................................................................................................... 46
3.2.5 Effects of Channel Switching ................................................................................. 50
3.2.6 Mobile Radios ......................................................................................................... 61
3.2.7 Urban Intersection Testing ...................................................................................... 64
3.2.7.1Packet length and inter- arrival time .......................................................................... 64
3.2.7.2Data rate and queuing ............................................................................................... 69
3.2.8 Summary ................................................................................................................. 72
3.3 DSRC Testbed of Safe Intersections .............................................................................. 74
3.3.1 Concept of wireless communications to enable Intersection safety ....................... 74
3.3.1.1The Intersection Crash Problem ................................................................................ 74
3.3.1.2Dynamic Red Light Running Countermeasures ......................................................... 74
3.3.2 VII California Testbed ............................................................................................ 75
3.3.2.1Location ..................................................................................................................... 75
3.3.2.2Roadside Equipment .................................................................................................. 75
3.3.3 Signal Phase and Timing Acquisition ..................................................................... 76
3.3.3.1NTCIP ........................................................................................................................ 76
3.3.3.2California AB3418 Protocol ...................................................................................... 77
3.3.3.3Non- invasive Current Sniffer ..................................................................................... 77
3.3.4 Interface to Dedicated Short Range Communication ............................................. 79
3.3.5 Communication Latency for Signal Phase and Timing Information ...................... 81
xi
3.3.6 Implementation Status of DSRC Hardware ............................................................ 82
3.3.7 Summary ................................................................................................................. 83
REFERENCES ............................................................................................................................. 85
Appendix A: User‘ s Guide: UCB WAVE Software ..................................................................... 90
A1. Design goals for UCB WAVE software ........................................................................ 90
A2. Software structure .......................................................................................................... 91
A2.1. Overall Structure ..................................................................................................... 91
A2.2. WAVE API ............................................................................................................. 91
A2.3. California PATH utilities ........................................................................................ 92
A2.4. Signal Phase and Timing Example ......................................................................... 93
A2.1. Probe vehicle analysis ............................................................................................. 93
A3. Getting started ................................................................................................................ 93
xii
List of Tables and Figures
Table 1: Task Group P IEEE 802.11 letter ballots ........................................................................ 16
Table 2: Types of requests provided by IEEE 1609.3 .................................................................. 23
Table 3: Regulatory class and channel number in U. S. A. ............................................................ 25
Table 4: Regulatory class and channel number in E. U. ................................................................ 26
Table 5: Channel identification using country string and regulatory class ................................... 26
Table 6: Performance comparison on OBU at 400MHz ( reported by VSC- A) ............................ 30
Table 7: Parameters used for tests of frequent and infrequent channel switching. ....................... 50
Table 8: Performance comparison of WiFi chips and Cohda chips in Field Trial ( reported by
Cohda: http:// www. cohdawireless. com/ technology/ whitepapers. html) ............................... 83
Figure 1 Evolution of physical layer development from algorithm to implementation ................. 3
Figure 2: Floating Point Transmitter Model ................................................................................... 4
Figure 3 Screen shot of testbed visualization capabilities .............................................................. 5
Figure 4: Synthesizable model block diagram of fixed- point model .............................................. 6
Figure 5 Floating- point model of a soft- demapper algorithm ........................................................ 6
Figure 6 Fixed- point model of a soft- demapper algorithm ............................................................. 7
Figure 7 Hardware components of the physical layer testbed. ....................................................... 9
Figure 8 Angle- of- Arrival distributions for ( a) JakesX, ( b) flat, and ( c) round spectra. Vehicle
and roadway included for scale reference. ............................................................................ 10
Figure 9: FCC DSRC channel allocation ...................................................................................... 14
Figure 10: WAVE standards ( from IEEE 1609 trial use standards) ............................................. 19
Figure 11: Two EDCA entities in MAC layer ( from IEEE 1609.4 trial use standard)................. 21
Figure 12: Alternative view of WAVE standards ( from Moring‘ s presentation) ......................... 21
Figure 13: Flow of timing information using WSA in trial use IEEE 1609.4 .............................. 22
Figure 14: Flow of timing information from a timing provider proposed by Morning ................ 23
Figure 15: An example of flow of Vendor Specific Action ( VSA) messages .............................. 24
Figure 16: Format of Vendor Specific Action ( VSA) that contains a WSA ................................ 24
Figure 17: Time alignment and channel switching in time/ frequency domains ........................... 27
Figure 18: Service initialization based on location information proposed by Jiang ..................... 27
Figure 19: An application is composed of application core and WIAL in 1609.11 ..................... 29
Figure 20: Illustration of ― Pre- approved‖ scenario in 1609.11..................................................... 29
xiii
Figure 21: Illustration of ― Invoice‖ scenario in 1609.11 .............................................................. 29
Figure 22: A map of the VII California Testbed ( November, 2007). ........................................... 39
Figure 23: Roadside and Backhaul Communications Architecture. This allows data to move
from the vehicle, through the roadside infrastructure and to the VII California network. ... 40
Figure 24: Schematic of VII California RSE Components ........................................................... 41
Figure 25: Left and Center: VII California RSE Mounted in Type 332 Cabinet on Caltrans Right
of Way; Right: DSRC Radio Enclosure and Antenna Mounted on Ramp Meter Signal Pole
at Freeway Onramp. .............................................................................................................. 42
Figure 26: Assembly of three gumstix netduo expansion boards. ................................................ 45
Figure 27: Antenna placement with 8 active OBUs on one vehicle ............................................. 46
Figure 28: Baseline operation, 1480 byte data per packet, 10 millisecond interval between sends,
different pairwise runs of the four stations used for desk checking ..................................... 47
Figure 29: Two runs showing interference between two pairwise communication streams causing
slightly increased trip time ( 1480 byte data per packet, 10 millisecond interval between
sends on both streams) .......................................................................................................... 48
Figure 30: Large increase in trip time due to interference between a higher rate pairwise
communications stream ( 1480 byte packets at 4 ms interval between sends) and a lower rate
stream ( 1480 bye packets at 10 ms interval between sends). Note that the scale for trip time
is in seconds; the lower graph shows sequence numbers. .................................................... 49
Figure 31: Baseline case: no channel switching, light load. ......................................................... 52
Figure 32: Infrequent channel switching, messages sent at 10 Hz. ( t1); each channel switch is
indicated by a vertical line, at that point the channel changes .............................................. 53
Figure 33: Close- ups, in case of infrequent channel switching ( t1). ............................................ 54
Figure 34: In this case, sw2, the send rate is half that of sw1, and round trip time remains low. 55
Figure 35: In this case, sw3, the send rate is twice that of sw1, and but the delivery of packets, as
shown by sequence numbers remains good and the round trip time remains low. ............... 56
Figure 36: Case sw4, with increased overall load and increased channel switching. ................... 57
Figure 37: Close up of switching and sequence number loss for case sw4. ................................. 58
Figure 38: Case sw5 has increased loading and likewise increased latency and packet loss
compared to case sw4. .......................................................................................................... 59
Figure 39: Close- up of case sw5 shows that the switching times for the different processors have
spread still more, and the latency has increased to almost 25 ms. ........................................ 60
Figure 40: Eight radios, each sending 200 byte packets at 10 ms intervals, with background
channel switching twice a second, from van parked within range of Richmond Field Station
RSU. ............................................................................................................................... ...... 62
Figure 41: Eight radios, each sending 200 byte packets at 10 ms intervals, with background
channel switching twice a second, during a short ride on a test track at Richmond Field
Station. ............................................................................................................................... .. 63
xiv
Figure 42: Location of RSU at 6 th and Brannan in San Francisco. ............................................... 64
Figure 43: Plot of average of remote and local RSSI by GPS location for all received packets in
runs at 6 th and Brannan. ........................................................................................................ 65
Figure 44: Probability of successful round trip transmission, as a function of the interval between
packet sends, for 1, 2, 4 and nodes, with varying packet sizes of 200, 400 and 800. ........... 67
Figure 45: Time ( in seconds) until the first 8000 bytes has been transmitted, as a function of the
interval between packet sends, for 1, 2, 4 and nodes, with varying packet sizes of 200, 400
and 800 for tests at 6 th and Brannan. ..................................................................................... 68
Figure 46: Location of RSU at 3 rd and Townsend in San Francisco, and direction of test- runs. . 69
Figure 47: Transaction delay for 8000 byte transaction as a function of data rate, for 9 nodes,
packet size 200 bytes, with various testing routes, 10 millisecond interval between packet
sends. ............................................................................................................................... ..... 70
Figure 48: Transaction jitter ( standard deviation of delay) as a function of data rate, for 9 nodes,
packet size 200 bytes, with various testing routes, 10 millisecond interval between packet
sends. ............................................................................................................................... ..... 71
Figure 49: Transaction delay for 8000 byte transaction as a function of data rate, for 9 nodes,
packet size 1400 bytes, with various testing routes, 10 millisecond interval between packet
sends. ............................................................................................................................... ..... 71
Figure 50: Transaction jitter ( standard deviation of delay) as a function of data rate, for 9 nodes,
packet size 1400 bytes, with various testing routes, 10 millisecond interval between packet
sends. ............................................................................................................................... ..... 72
Figure 51: Illustration of regions of performance for successful transmission. ........................... 73
Figure 52: Illustration of regions of performance for transaction times. ...................................... 73
Figure 53: Installation and operation of ― clamp- on‖ signal current sniffer at VII California
intersection. ........................................................................................................................... 78
Figure 54: Depiction of ― clamp- on‖ signal sniffer ...................................................................... 79
Figure 55: Modular design of signal phase acquisition and broadcast system ............................. 79
Figure 56: Types of information that must be specified to configure signal phase and timing
broadcast. .............................................................................................................................. 80
Figure 57: Difference in transition time between AB3418 and sniffer acquisition, run
simultaneously ...................................................................................................................... 82
1
ITS Band Roadside to Vehicle Communications
in a Highway Setting: Final Report
1. A COTS Testbed for Rapid Algorithm Development,
Implementation and Test of 5.9GHz OFDM DSRC
The IEEE 802.11 physical layer ( PHY in the IEEE nomenclature) testbed for 5.9GHz
Orthogonal Frequency- Division Multiplexinsg ( OFDM) Dedicated Short Range
Communications ( DSRC), developed by researchers at the UCLA Wireless Research and
Development ( UnWiReD) Laboratory ( UnWiReD, 2006), is meant to perform conformance
testing of vendor products, evaluate developing standards specifications, and allow development
and testing of novel wireless algorithms in a real- world environment ( Dulmage, MOBICOM,
2006).
In the following subsections we first present the rationale for a testbed which uses an
integrated set of COTS tools to
 significantly reduce the volume of tools and expertise required of the wireless algorithm
designer by
 reuse subsystem test benches in a common simulation environment across several stages
of development
 enable rapid and intuitive iteration through development stages.
We then describe the flexible testbed development environment based on Matlab, Simulink, and
Xilinx System Generator, the radio hardware interface using a Xilinx XtremeDSP radio
development daughtercard built around a programmable Xilinx FPGA, and research that was
carried out under T. O. 5214 and T. O. 6214 on a software- based vehicular channel model. We
finally note contributions of this work to WAVE/ DSRC development and continuing work by
UCLA researchers on WAVE/ DSRC.
1.1. Rationale for physical layer radio testbed
In August 2001, the Federal Highway Authority ( FHWA) sponsored performance testing of
candidate technologies for the Federal Communications Commission ( FCC) approved Intelligent
Transportations Systems ( ITS) frequency. This testing was carried out by the Dedicated Short
Range Communications ( DSRC) 5.9 GHz Standards Writing Group, a sub- group of American
Society for Testing and Materials ( ASTM) E17.51 containing representatives of public agencies
and of the private sector., The group voted 20- 2 to select 802.11a RA ( roadside applications), a
version of IEEE 802.11a modified to operate at 5.850- 5.925 GHz that was demonstrated using
Atheros AR5000 chipsets and performed well in a variety of severe multipath and high- speed
environments, at distances up to 400 meters ( Atheros, 2001). ASTM then produced an initial
standard for this technology, ― ASTM E2213- 03 Standard Specification for Telecommunications
and Information Exchange Between Roadside and Vehicle Systems — 5 GHz Band Dedicated
Short Range Communications ( DSRC) Medium Access Control ( MAC) and Physical Layer
( PHY) Specifications‖ ( ASTM 2003).
2
While the Atheros chips sets performed well on the ASTM testing, the high mobility and
the dynamic environment of DSRC applications required a reassessment of the 802.11 PHY
receiver architectures. Outdoor radio systems must contend with a considerably different
wireless environment than indoor radio systems for which the Atheros chip was originally
designed. Two major issues that must be addressed include the typically longer delay spreads in
the outdoor environment, the time- varying nature of vehicular channels, and the greater number
of sources of interference. A DSRC testbed with highly programmable components was
considered desirable to enable modification of physical layer algorithms to realize acceptable
PHY performance for a variety of applications and outdoor environments. New receiver
algorithms for channel and frequency estimation and tracking can result in significant
improvements in performance and throughput, as is currently being claimed for Cohda Wireless
technology ( Telematics 2009).
The maximum excess delay is the time difference between the first reception of a
transmitted signal at the receiver and the last reception. This phenomenon, called multipath
propagation, results when a signal travels different paths from the transmitter to the receiver .
The shortest path is usually the direct line between the two while longer paths result from the
signal reflecting off obstructions in the environment such as buildings or trees. The maximum
excess delay is often much different outdoors than indoors due to walls providing large
obstructions at close distances. Since walls often cause 30dB of loss for propagation through
them, delay spread in indoor scenarios is often limited to paths within the same room. Outdoor
environments often have the excess delays a factor of 10 times greater than indoor environments.
The 802.11a standard was designed to operate in a delay spread typical of the indoor
environment. To combat delay spread, the standard inserts a guard interval before the
transmission. The guard interval ensures that no new transmissions will be sent over some time
duration. As long as that duration is greater than the excess delay of the channel, consecutive
transmissions will not interfere with each other. ASTM E2213- 03 and the specifications being
developed as part of IEEE 802.11p ( see Section 2 of this report) call for halving the symbol rate
which doubles the guard interval, but it is not clear if this will ameliorate all of the consequences
of the longer, outdoor excess delay encountered in deployment of DSRC applications. If the
delay is much larger than anticipated, significant degradations may result. Testbed
programmability for DSRC technology allows experiments to be performed in realistic
deployments. Results of these experiments can directly impact the direction of the transmit
signal and receiver designs for people who build radios for transportation applications.
The UCLA Wireless Research and Development laboratory was well equipped with test
and measurement instruments and experience developing two wireless testbeds to facilitate
experiments on most aspects of physical layer wireless communications, ranging from individual
components such as channel characterization, synchronization, and channel codecs to a software
defined multi- antenna wireless system. Ongoing projects within UCLA were leveraged in
designing and building an operational DSRC physical layer implementation. UCLA researchers
were able to build on their experience in investigating high performance wireless modem
technologies in real wideband channels, including a particular focus on OFDM for future
wireless applications. Expertise with the physical layer aspects of DSRC was already in place at
UCLA at the start of the project.
Modern communications algorithm design requires a diverse set of tools and expertise.
From conception to design a rigorous, though not complete, development process can include
3
abstract mathematical analysis, floating- point simulation, bit- true ( functional) fixed- point
simulation, cycle- true fixed- point simulation, and real- time hardware design and implementation.
Each step is distinguished by its own set software tools, design methodologies, and developer
expertise. Often there is significant duplication of effort to develop simulation environments,
test benches, and verification plans for each stage of development. Comparison of performance
and test results between models at different stages is inconvenient at best ( e. g. data conversion)
and daunting at worst ( e. g. parametrizing hardware performance degradation with respect to a
floating- point model).
The DSRC testbed developed by UCLA researchers for T. O. 6214 consists of a set of
simulation models along with a programmable hardware platform for implementation and test.
These models facilitate algorithm development following the general evolution illustrated in
Figure 1.
The overall goal of this type of testbed design was to keep software/ hardware partitioning
flexible throughout the development cycle. Evaluation of algorithms with software and
simulation has the advantage of being easily re- programmable, with advanced debug capabilities
and the resources of a full personal computer environment available for test generation, data
storage, and data analysis and display. In contrast, hardware implementations, even FPGA
hardware, are relatively static, with limited debug capabilities, even though testing with real
hardware and radio transmissions are essential for testing model correspondence to the real
world and capturing real- world effects too complex to model. In the testbed that was developed,
the overall algorithm design could be arbitrarily partitioned between hardware and software.
Testing of the hardware could be carried out either with the fine- grained control of a
synchronous interface, or with an asynchronous interface that allowed real- time operation with
actual digital/ analog and analog/ digital conversion to the radio front- end. The synchronous
interface, while not real- time, allowed sample- by- sample debugging of the hardware; the
asynchronous interface provided high performance block data transfer for real- time
experimentation.
The various points of partitioning allowed a single model/ testbench to accomplish several goals.
Subsystem algorithms and hardware designs could be developed and debugged with a single
testbench. Integrated hardware designs could be tested in the same virtual environment used for
simulation and development for providing consistent control and monitoring capabilities. The
user interface integrated with the testbench could be used to perform both bench and field tests.
Once the baseline system was completed, rapid design iterations could be performed, including
integrating new floating- point algorithms quickly into hardware implementation.
.
Floating- point
simulation
Fixed- point
simulation
Cycle- true
simulation
Hardware
implementation
Math/ stats
analysis
Most abstract
Most accurate
Least abstract
Least accurate
Figure 1 Evolution of physical layer development from algorithm to implementation
4
1.2. Matlab and Simulink Implementation
The basic testbed design ( Dulmage/ Tsai/ Fitz/ Daneshrad, 2006; Dulmage/ Tsai/ Fitz/ Daneshrad,
2007) was modular with loosely coupled subsystems and intuitive interfaces. The testbed
software models were implemented using The Mathworks Matlab and Simulink ( Mathworks,
2006) products. Matlab and Simulink were augmented with the fixed- point arithmetic toolbox
and Simulink fixed- point respectively, tools that facilitate the extension of the simulation
environment to direct hardware synthesis of mathematical algorithms. The environment allows
the developer to graphically program simulations by connecting together basic functional blocks
( e. g. adders, multipliers, logic functions that can be directly implemented in hardware) along
with more sophisticated blocks ( e. g. matrix decompositions, encoders, modulators). Xilinx
System Generator ( Xilinx, 2006) augments these functional blocks with structural blocks ( e. g.
delay elements, registers) from which the developer can create a synthesizable hardware model
of their algorithm. Interfacing Simulink's functional blocks with System Generator's structural
blocks is straightforward and allows co- simulation of high- fidelity floating- point algorithms with
cycle- true, fixed- point algorithms. This allows a highly parameterized, flexible simulation set- up.
The top- level floating- point model is a functional model. Each major component of the
top- level is decomposed into major functional subsystems in a top- down design architecture.
Components of this model include a transmitter conforming to the 802.11p draft standard, RF
filtering, a time variant, multipath fading channel model, and a receiver implementing baseline
algorithms. Receiver algorithms that were implemented include frequency offset tracking,
simplified soft- output demapper and a soft- input Viterbi decoder. See Figure 2 for a block
diagram of the floating point transmitter model.
Figure 2: Floating Point Transmitter Model
Measurement and visualization ( e. g. spectrum analyzers, BER calculation) facilities are
also present at the top- level. Relatively generic interfaces connect the various subsystems. The
simulation environment includes DAC/ ADC hardware emulation and variable RF impairments
( time/ frequency/ phase offsets). The user interface includes visualization capabilities for a rich set
of information, including:
 Received and equalized constellation plots
 Received and equalized signal spectra
5
 Actual channel and estimated channel responses
 BER, PER, SNR vs. time, BER vs. SNR
 Successful and errored bits within each decoded symbol
See Figure 3 for a screen shot of testbed visualization capabilities.
Figure 3 Screen shot of testbed visualization capabilities
6
Figure 4: Synthesizable model block diagram of fixed- point model
In parallel to the floating- point functional model, a top- level cycle- true, fixed- point structural
model for a receiver was developed. The fixed- point structural model was synthesized using
Xilinx System Generator to a hardware description appropriate to program the FPGA. This
hardware implementation would then use the floating- point model as a testbench. The hardware
was tested via hardware- in- the- loop simulation with the floating- point transmitter, RF emulation,
multipath channel, visualization, and error statistics blocks. Because the synthesized blocks
were operating on the high- speed FPGA hardware, accelerated simulations could be run.
Several sub- modules were implemented for the fixed- point receiver model: packet detection/ time
synchronization, coarse frequency offset estimation, frequency offset tracking, soft- output
demapper, and soft- input Viterbi decoder. Figures 5 and 6 illustrate the implementation of the
soft- demapper algorithm in the floating- point and fixed- point models, respectively. Their similar
layout illustrates the intuitive nature of porting floating- point to synthesizable fixed- point models
using the chosen tool set.
Figure 5 Floating- point model of a soft- demapper algorithm
7
Figure 6 Fixed- point model of a soft- demapper algorithm
Concurrent with the model creation, a design methodology was developed. The
methodology proscribes utilizing the floating- point simulation model as a reference with which
to provide a ( sub) system performance level baseline. The floating- point model also supplies a
common testbench with which to exercise and evaluate both the floating- point models and
hardware designs. A fixed- point hardware simulation model is constructed from the initial
floating- point model in order to quantify performance degradation due to quantization and enable
debugging/ optimization of the structural hardware implementation. To utilize the same
testbench as the floating- point model, input/ output interface adaptors may be added. A fixed-point
synchronous hardware co- simulation model, synthesized from the fixed- point hardware
simulation model, ensures correct synthesis of the algorithms to their implementation on the
FPGA and enables more comprehensive performance testing due to more efficient hardware co-simulation.
In the final iteration, a fixed- point asynchronous hardware co- simulation model
implementing asynchronous ( shared- memory) interfaces in the hardware model would allow
testing of ( sub) systems as they would operate on the hardware in real- time. Asynchronous
hardware co- simulation futher improves simulation speed by an order- of- magnitude or more
over synchronous hardware co- simulation. Finally, stand- alone software ( e. g. the medium
access controller) would replace Simulink to drive the hardware using the same shared- memory
interfaces as was used during simulation.
Several subsystems were iterated completely through all of the design stages: Viterbi
decoder and control logic, FFT/ IFFT and control logic, channel estimation, and log- likelihood
ratio demapper. Several subsystems were developed through a subset of the design stages:
time/ frequency synchronization, frequency offset tracking, interleaver/ deinterleaver and control
8
logic. The design methodology established a standard procedure for reliable development of
hybrid software/ hardware testbeds and systems. Several subsystems have already been
developed and verified via this procedure each of which contributes to the final goal of a fully
functional DSRC prototype radio. Further details on subsystem development and simulation
results can be found in the Masters thesis ( Dulmage 2008).
Difficulties were found with the Xilinx System Generator development environment in the
course of work on the DSRC radio testbed for T. O. 6214. Caltrans- funded UCLA researchers
identified and reported several major bugs in the Xilinx development environment. Several of
these bugs were fixed in newer Xilinx product releases, but resulted in a considerable loss of
time in the project schedule. Researchers on this project were in contact with internal product
developers at Xilinx and able to recommend features useful for general FPGA in- the- loop
systems.
1.3. FPGA and Radio Hardware
Hardware used for the DSRC testbed was constrained to be low- cost, either COTS or low- cost
custom subsystems, and portable. The largest component of the UCLA prototype was a standard
19‖ rack- mount enclosure, which could easily be made smaller with current commercially
available systems. Reprogrammability was a priority. The basic platform was the Xilinx
XtremeDSP- II kit designed by Nallatech and consisted of a Xilinx field programmable gate array
( FPGA) coupled to dual analog- to- digital converters ( ADC) and dual digital- to- analog converters
( DAC). The number and cost of on- board FPGA parts can be tailored to the complexity of the
system to be developed. The board also contained 4MB of off- chip memory accessible through
the FPGA. Embedded or soft- core processor support could also be included on the same board
for an integrated implementation of the IEEE 802.11 MAC layer. Different hardware
implementations were achieved through automatic synthesis using Xilinx ISE tools and Xilinx
System Generator.
The FPGA board was hosted on a PCI motherboard and housed in a standard PC. A high- speed
interface to the PC is needed for development, test, and control; USB, 100Base TX Fast
Ethernet, and PCI were available interfaces at the time. 1GB TX and PCIe interfaces are
available on modern boards. The ADC and DAC ports were readily accessible from the back
panel of the PC. The custom radio frequency ( RF) front- end box converted signals to and from
the FPGA board in two stages, and operated in the DSRC band from 5.85 GHz to 5.925 GHz.
Operating frequency and transmit and receive gains were programmable from front- panel
interfaces on the RF box.
9
1.4. Development and Simulation Results
The DSRC testbed work was continued in a master‘ s thesis ― IEEE 802.11 OFDM Model for
Algorithm Development, Implementation, and Test,‖ ( Dulmage 2008) extending and
generalizing the original design work, and in papers on channel modeling in the non- isotropic
scattering environment of the open highway ( Dulmage/ Fitz 2007a, 2007b). During the course of
the testbed work, it became clear that the applications of the testbed were much more general
than 802.11p DSRC. The testbed had the potential to become a general purpose, hybrid software-hardware
development platform capable of supporting applications ranging from software
simulation to hardware field- testing . using a single development environment. The testbed
combined lower performance, more general purpose processing engine ( basically a personal
computer or PC) with a high performance but less arbitrarily reconfigurable hardware device, in
this case a field- programmable gate array ( FPGA) board, resulting in both a highly flexible and
highly accessible system.
The thesis provided a variety of preliminary results and suggested many areas for further
investigation using such a test bed. The considerable affect of clipping noise on the channel
estimation was shown. Future work could elucidate the nature of the degradation ( frequency-domain
response, relationship to input signal, etc.) and find algorithms robust to clipping noise
and/ or mitigation techniques. A procedure was outlined to compute the fixed- point dynamic
range and scaling necessary to avoid certain degrading affects on the linear soft- metric demapper
algorithm. Further exploration could determine a generalized framework with which to
analytically compute fixed- point parameters to ensure some level of performance for linear
functions. Several aspects of the system performance were explored over a variety of channels,
and channel estimation emerged as a particularly important aspect of performance. In time-invariant
tests, performance differed significantly depending on the channel characteristics.
Future work could determine the channel properties that most affect bit- interleaved coded
modulation ( BICM) systems and suggest design parameters ( e. g. code rate, interleaver design,
symbol constellation) to achieve the best performance based on those channel properties. The
Host PC
FPGA Baseband
Processor,
ADC/ DAC
RF front- end
Figure 7 Hardware components of the physical layer testbed.
10
affects of time- variant channels were also explored. Future work could explore the significance
of the loss of channel estimate coherence with the time- variant channel over long packets. The
affects of envelope vs. phase variation would suggest potential mitigation techniques such as
tracking or prediction algorithms. Special channel coding may enable greater exploitation of
diversity across amplitude or phase depending on their characteristics.
1.5. Channel Model Research
The papers on a ― Non- Isotropic Fading Channel Model for the Highway Environment‖
( Dulmage/ Fitz 2007a, 2007b) investigate the properties of several non- Jakes Doppler spectra
proposed for the vehicle- to- vehicle environment. The high- speed, mobile- to- mobile scenario
presents a unique wireless environment. The IEEE 802.11p/ D1.0 ( WAVE) draft standard
document described a channel model recommended for system development and test. The model
was derived from channel sounding experiments performed in an open highway environment
( Acosta/ Ingram/ Tokuda 2004). The draft standard specified a 10- tap multipath fading model
with the majority of taps exhibiting Rician fading. The diffuse Doppler spectrum for each tap
results from the non- isotropic nature of the environment and does not match the classic Jakes
spectrum. The exploration in ( Dulmage/ Fitz 2007a, 2007b) of the alternative Doppler spectra
identifies their properties and suggests a method of realization using a sum- of- sinusoids ( SoS)
channel model.
.
Figure 8 Angle- of- Arrival distributions for ( a) JakesX, ( b) flat, and ( c) round spectra.
Vehicle and roadway included for scale reference.
Motion in the wireless environment causes transmitted signals to experience Doppler
shifts as a function of the angle between the signal path and the direction of motion. Signals
arrive at a receiver after having experienced reflections from potentially moving scatterers at a
variety of angles. The superposition of these multipath components with a range of Doppler
shifts and received powers manifests as a Doppler spectrum at the receiver. The exact shape of
the Doppler spectrum is a function of the wireless environment.
11
The probability density functions for the angles- of- arrival of the flat and round Doppler
spectra are non- standard distributions. As such no generation functions specific to these
distributions are available. Figure 8 shows the angles- of- arrival distributions derived in
( Dulmage/ Fitz 2007b) using randomization techniques for several non- Jakes spectra considered
in highway scenario channel models. The classic Clarke channel model was modified to generate
fading signals corresponding to the non- isotropic scattering profiles. The theoretical correlations,
level- crossing- rates, and average- fade- durations were derived. The simulation results matched
well with the theoretical ideal channel. The channel model enables efficient, high fidelity
simulation of channels observed in the vehicular environment. This facilitates the investigation
of DSRC system performance in realistic channels.
1.6. Contributions and Future Work
The tools and architecture described above allow designers to analyze algorithms and implement
simulations at a high level reducing the need for programming expertise ( though such expertise
may be helpful for advanced modeling with Simulink) and hardware design expertise ( e. g.,
specialized skills such as using VHDL). Learning many disjoint, often incompatible
development environments is also avoided. Most importantly, the ease of integration of the
functional floating- point, fixed- point, and structural models enables the incremental evolution of
algorithms using a common simulation framework.
The use of Xilinx System Generator as the basis for the models allows the designs to be
easily ported to any Xilinx part supported by the company. This reduces costs for part- specific
design revisions both in time and administration. Cross- product compatibility also facilitates the
use of more complex algorithms as more powerful FPGAs become available. Nallatech provides
a variety of ready- to- use FPGA boards with integrated peripheral resources and interfaces.
Xilinx partnership with Nallatech alleviates many compatibility issues involved in porting
designs between boards. This allows the algorithm designer the flexibility to select the right
amount of processing resources for a given design without having to explicitly design the board
according to the processing needs.
Bit- error- rate results have been obtained for the current floating- point and cycle- true
models over a variety of fading channels. We have been able to integrate cycle- true, fixed- point
implementations of algorithms on the programmable hardware in co- simulation with the
floating- point model. This allows isolation of individual algorithms for performance
comparisons to the floating- point versions. It also enables us to easily integrate hardware
acceleration into our simulations.
While Xilinx provides simple facilities for integrating the FPGA into simulations and
software test benches our goal is to produce a library of high- performance, flexible, ready- to- use
interfaces to various board resources such as internal and external memory, ADC/ DAC and
multiple FPGAs. These interfaces, of course, have general applications beyond our current
testbed.
The DSRC/ WAVE physical layer testbed enables theoretical performance evaluation of a
standard 5 GHz OFDM system under a variety of use environments and hardware impairments.
Baseline performance results can be used to evaluate the sufficiency of the 802.11p/ WAVE
standard specifications. Baseline performance results can also be used to quantify the
12
degradation from theoretical optimum performance due to fixed- point, hardware implementation
of subsystems of commercial products evaluated for standards conformance.
Other contributions are related to the general purpose functionality of the design, which
provides a highly parameterized, comprehensive OFDM simulation model which can be
leveraged with potentially minor changes to other OFDM- based wireless projects ( such as
WiMax). Testbench subsystems for RF impairments, channel model and visualizations are
further applicable to a wide- range of mobile wireless research. The configuration and run- time
capabilities of this model are suitable for extensive investigation of the affects of a variety of
signal parameters and impairments. Visualizations and measurements can be disabled to enable
fast batch simulations.
The system model is also useful for demonstration and illustration of concepts during
educational instruction. The modularity of subsystems facilitates substitution of alternative
algorithms for performance comparison, proof of concept testing, and research. We do not know
of any other OFDM system model with comparable accuracy to the standard, array of
configurable options, run- time control capabilities, or visualization options.
Important Caltrans- funded DSRC/ WAVE work continues at UCLA. In one recent papers,
the use of Received Signal Strength ( RSS) to estimate distance accurately on systems using
location aware applications is studied.( Dulmage/ Cioffi/ Fitz/ Cabric 2010). In another paper,
based on extensive simulations of IEEE 802.11p, a new metric, the normalized empirical
coherence time ( NETC) is used to designate the minimum time ( as a percentage of signal
duration) over which the system achieves some performance threshold ( Dulmage/ Fitz/ Cabric
2010). This metric is explicitly a function of modulation, packet duration and the traditional
coherence time, and could be used in place of the latter when determining how to constrain
packet duration so that channel variation has negligible impact on performance.
2. Standards Development for Wireless Access in Vehicular
Environments ( WAVE)
2.1 Introduction
Intelligent Transportation Systems, empowered by wireless communication, are expected to
significantly improve the safety and efficiency of our transportation network. The idea is to inter-connect
all the physical components of a transportation system in cyber- space. Vehicles
equipped with wireless transceivers enabled for Dedicated Short Range Communication ( DSRC)
can exchange information either in vehicle- to- vehicle ( V2V) or vehicle- to- infrastructure ( V2I)
fashion. Since V2I communication requires an initial infrastructure investment before
deployment, V2V communication among vehicles organized in Vehicle Ad Hoc Networks
( VANETs) is likely to be deployed first. However, new safety, navigation, and automation
applications in vehicular environments as envisioned in the IntelliDrive SM initiative
(( USDOT/ IntelliDrive SM 2010), will be greatly enhanced by the addition of the information
available to the infrastructure, both from roadside sensors and traffic management centers. The
ubiquity of cellular communications, which can reasonably be expected to provide some access
to infrastructure information to every vehicle in the near future, enables a multitude of possible
communication architectures and applications.
13
The operation of Wireless Local Area Networks ( WLAN) on motor vehicles in a
highway environment presents many challenges. Ideally, the same on- board equipment used for
toll collection should also be available for use by roadway safety applications such as vehicle
collision avoidances, and for other applications such as traveler information, emergency services
or commercial data services. Some of these applications may require extremely short times, on
the order of 50 to 100 milliseconds, to complete a transaction, while for other applications,
extremely high data rates or long operating ranges may be required.
Before deployment of applications dependent on V2V or V2I communications can occur,
standards must be developed to allow interoperability between different automobile
manufacturers and different DSRC equipment manufacturers. Caltrans Task Orders 5214 and
6214 funded participation in standards development at the most basic layers of the wireless
network stack: an amendment to the IEEE 802.11 Wireless LAN Medium Access Control
( MAC) and Physical Layer ( PHY) Specifications, and a new family of IEEE standards providing
networking services for Wireless Access in Vehicular Environments ( WAVE), IEEE 1609. This
report summarizes the history and current status of this standard development at the lower layers
of the networking stack. It does not deal in detail with upper layer standards such as SAE J2735,
a message set dictionary ( i. e., common languages for DSRC applications to understand each
other) that describes DSRC message content ( SAE J2735 2009).
2.2 The FCC- approved DSRC frequency band
Since the mid- 1990s, transportation researchers and the US Department of Transportation have
been working towards future use of DSRC in a spectrum dedicated for transportation purposes
only. In 1997, the Intelligent Transportation Society of America ( ITS America), on behalf of the
transportation industry, petitioned the FCC for a specific band of frequencies at 5.9 GHz. In
1999, the FCC granted the petition with the stipulation that public safety uses would have
priority, but postponed defining the rules on how and to whom the spectrum would be licensed.
A standard for the physical and medium access control layers in this DSRC band, E2213- 02 -
Standard Specification for Telecommunications and Information Exchange Between Roadside
and Vehicle Systems, was defined by the American Society for Testing and Materials ( ASTM)
International in 2002 ( ASTM, 2002), and in 2004 the FCC published rules and standards for use.
14
Figure 9: FCC DSRC channel allocation
The FCC rules stated that DSRC frequencies should be used ― primarily‖ for safety
purposes, but left the eligibility requirements for licensing open in order to encourage
development of new services. The DSRC band lies between 5.850 and 5.925 GHz, and includes
7 available 10 MHz wide channels. Both public safety and non public- safety users are eligible
for licensing on all channels, with limited geographical coverage for each roadside installation.
See Figure 9 for an illustration of planned DSRC channel allocation.
It is important to distinguish between the previous DSRC standard in the 915 MHz range,
which was used primarily in electronic toll collection applications, and the Wireless Access in
the Vehicular Environment ( WAVE) standards being developed for the new 5.9 GHz DSRC
band. The previous DSRC standard had a range of less than 30 meters, a data rate of only 0.5
Mbps, and operated on a single unlicensed channel. The WAVE technology has a range of up to
1000 meters, data rates from 6 to 27 Mbps, and licensed multi- channel operation. Whereas older
DSRC applications were limited to short- distance applications with a command response
communication model, the new WAVE technology is being designed to support general Internet
access and special low- latency short messages for vehicle safety applications as well as the
existing command- response applications. A further difference is the open architecture and
standard protocol being developed for WAVE devices, compared to the custom chip sets of
previous systems.
2.3 Amendment P to IEEE 802.11
The physical layer for devices in the FCC- approved DSRC frequency band is based on IEEE
802.11a Orthogonal Frequency Division Multiplexing ( OFDM), so that existing 802.11a WI- FI
chip architectures can be used as the basis for inexpensive WAVE implementations and
deployment. Using existing WI- FI chip architectures has great advantages for economies of scale
in the production of WAVE devices, taking advantage of the large market for consumer WI- FI.
15
There are also reliability advantages in using a proven commercial architecture. Changes that are
required to support WAVE, in addition to the basic change in frequency from the unlicensed
802.11a channels to the 5.9GHz DSRC channels, include adjustments to the Physical Layer
( PHY) for the rapid changes in distance between wireless stations during high- speed travel and
changes needed to the Medium Access ( MAC) layer to deal with the short communication
latency required to exchange time- critical safety information between vehicles.
2.3.1 Fundamentals of IEEE 802.11
IEEE 802.11 was originally developed to provide a ― wired- equivalent‖ wireless network that
could provide reliable transmission to higher layers of the network stack. As such the 802.11
standard was written to include authentication and association features that require handshaking
between nodes that are part of a Basic Service Set ( BSS) before any data communication is
allowed to occur, mimicking the privacy and security of a wired Local Area Network ( LAN)
using Ethernet. This handshaking precludes the short communication latency when vehicles
come in range of each other that is required for V2V and V2I communications.
From the beginning 802.11 chip sets have been able to go into ― promiscuous‖ mode and pass
all communications received to higher layers of the networking stack, but this has not been part
of the operation of these chip sets according to the standard. The fundamental necessity for use
of these radios in vehicles for safety applications is to relax this constraint. Early testing of
existing 802.11a chipsets by Atheros ( Atheros, 2001) and others ( Armstrong, 2008) showed
adequate performance of the PHY at vehicle speeds, so changes to the 802.11 PHY as part of
Amendment PHY have been relatively minor. Physical layer changes to 802.11a OFDM that are
required to support WAVE include:
 Support for the higher frequencies, since the 802.11a band stops at 5.825 GHz, just
below the DSRC channels.
 Adjustments to the physical layer for the rapid changes in distance between wireless
stations during high- speed travel. These include the use of 10 MHz channels and
consequent tighter margins for adjacent channel rejection.
While there is reluctance among some chip manufacturers to support the tighter margins, and
some uncertainty among researchers about whether these changes will be sufficient to provide
reliable communications at highway speeds, the physical layer emendations do not seem to have
been controversial to the 802.11 Working Group as a whole.
The 802.11 Medium Access Control ( MAC) layer is typically implemented partially in
software and partially in firmware; the physical layer ( PHY) particular to the radio frequency is
typically a combination of firmware and hardware. Amendments to the standard have included a
variety of features to improve quality of service and security, as well as to extend the standard to
different parts of the spectrum, and are very complex. The current version of the standard is over
1,000 pages. The descriptions in the standard of the MAC Layer Management Entity ( MLME)
and the Station Management Entity ( SME), as well as the Service Access Points between
different layers and entity within an 802.11 radio ( called a station or STA) are conceptual rather
than a strict specification of internal functions. While implementers often use the descriptions of
these entities as a guide, only information that is exchanged between STAs or that is specified in
a Management Information Base ( MIB) variable for configuring the STA is normative. For this
reason, it is quite difficult to use the 802.11 MAC standard as a guide to implementation ― from
16
scratch‖ of the required capabilities, and existing 802.11 chipsets represent considerable
intellectual property.
2.3.2 IEEE 802.11p History and Current Status
The initial drafts of the IEEE 802.11p amendment were system specifications written
from the point of view of the Intelligent Transportations Systems ( ITS) community, not
communications standards designed to specify the minimum requirements for interoperable
systems. These initial drafts were written by ITS experts, and there was a culture clash between
their expectations and that of the communication experts who dominate 802.11. There was also
difficulty in harmonizing with the ASTM standard ( ASTM, 2002) and the FCC rulings
specifying 7 bands. These rules apply to the U. S. only, and IEEE is an international standard.
Additional problems were caused by the difficulty of writing standards in advance of any
implementations of applications or networking services. IEEE 802.11 was initially designed with
respect to existing higher networking layers based on wired Ethernet. As different groups
developed requirements for possible DSRC networking applications, the boundary between what
would be implemented in 802.11 and what would be implemented in the higher networking
layers being specified in the IEEE 1609 family of standards was fluid.
Table 1 shows how revised drafts made by IEEE 802.11 Task Group P gradually gained
approval to pass Letter Ballot, the first and most important stage of approval for inclusion in
IEEE 802.11. Draft 1.0 was 59 pages and included diagrams for how to install WAVE hardware
in vehicles as well as a special appendix on WAVE in North America.
Recirculation TGp Draft 8.0 Approve 89% Wed Aug 05, 2009
Recirculation TGp Draft 7.0 Approve 92% Fri Jun 19, 2009
Recirculation TGp Draft 6.0 Approve 89% Tue, Mar 31, 2009
Recirculation TGp Draft 5.0 Approve 85% Fri, Dec 05, 2008
Letter Ballot TGp Draft 4.0 Approve 79% May 3, 2008 ( passed, > 75% approved)
Letter Ballot TGp Draft 3.0 Approve 74% Sep 12, 2007 ( failed)
Letter Ballot TGp Draft 2.0 Approve 67% Jan 5, 2007 ( failed)
Letter Ballot TGp Draft 1.0 Approve 59% Apr 11, 2006 ( failed)
Table 1: Task Group P IEEE 802.11 letter ballots
Gradually the vehicle specific scenarios and specifications were transferred to an Appendix, and
eventually eliminated altogether, and Task Group P produced drafts that took into account the
style and conventions of 802.11 as a whole.
The overall ITS concept for using WAVE communications involved advertisement to neighbors
of ITS services available. In the context of IEEE 802.11, the question of what kind of
management frame would be used to communicate this information provoked much controversy.
Initially the use of a special kind of management frame called an Action Frame was proposed.
17
These were proposed to be used to form a special kind of intercommunicating WAVE Basic
Service Set. This drew criticism from the 802.11 Working Group that since many of the fields
that were being communicated were part of the Beacon Frame that was used to establish ordinary
802.11 BSS communication, WAVE communication should use Beacons. A revised draft was
prepared with this change.
However, the idea of a WAVE BSS actually represented a confusion with groupings of
networked services that really ought to be provided at the IEEE 1609 higher layers, not in the
802.11 MAC. The 802.11 BSS concept was firmly connected to the authentication and
association operations that would make low latency operation impossible. The next major
advance in the development of the draft was to eliminate the concept of a WAVE BSS or of a
special WAVE mode, and replace it with simply allowing data frames to be exchanged outside of
the context of a BSS whenever a MIB variable is set to allow this to occur.
Elimination of the WAVE BSS concept from the 802.11p draft resulted in considerable
simplification and clarity. However, now Task Group P received feedback from other members
of the 802.11 Working Group that it was not appropriate to use a Beacon to send WAVE Service
advertisements and timing information when no BSS was being formed. The essential needs for
coordination and maintenance of security by the IEEE 1609 higher layers between different
WAVE stations are a mechanism to advertise WAVE services and a mechanism to send global
timing information. The current draft uses the existing Vendor- Specific information element to
encapsulate the WAVE service advertisement, and uses a new management frame for Timing
Information. The key feature of using a special management frame is that it, like the Beacon
Frame, can be sent with hardware insertion of the current 802.11 timestamp into the frame at the
moment it is sent, so that the timestamp can be read at the receiver with no intervening delays
from queuing or higher layer processing in the network stack. Along with information that
specifies the offset of the timestamp from a WAVE STAs global time ( expected to be obtained
from a reliable source like GPS), this Timing Information can be used to reconstruct the sender's
global time for the message at the receiver.
As part of Task Orders 5214 and 6214, Caltrans funded California PATH researcher Dr. Susan
Dickey to attend IEEE 802.11 Working Group sessions. Dr. Dickey began attending the sessions
in January 2006 and became secretary of Task Group P in May 2007. As secretary, she made a
considerable contribution to the discussions and functioning of the Task Group. In Fall 2009
Task Group P resolved the last remaining comments on the Letter Ballot Draft 8.0, formed a
Sponsor Ballot pool and begin the Sponsor Ballot process for final polishing of Amendment P.
As of March 2010, after the few comments for the second Sponsor Ballot recirculation were
resolved, the 802.11p Sponsor Ballot Comment Resolution Committee received conditional
approval to submit the 802.11p Draft 10.0 to the IEEE 802 Review Committee ( RevCom). Final
approval of the 802.11p Draft by RevCom may occur as early as June 2010.
2.4 IEEE 1609 Family of WAVE Standards
Four of the IEEE 1609 family of WAVE standards have so far been passed for trial use.
 IEEE P1609.1 Resource Manager – As currently written for trial use, this provides
application- level services heavily based on legacy 900 MHz toll tag reading
mechanisms.
18
 IEEE P1609.2 Security Services for Applications and Management Messages –
defines secure message formats and processing, the circumstances for using secure
message exchanges and how those messages should be processed based upon the purpose
of the exchange.
 IEEE P1609.3 Networking Services defines network and transport layer services, in
support of secure WAVE data exchange, as well as Wave Short Messages, which provide
an efficient WAVE- specific alternative to IPv6 ( Internet Protocol version 6) for direct use
by applications.
 IEEE P1609.4 Multi- Channel Operations provides enhancements to the IEEE 802.11
Media Access Control ( MAC) to support WAVE operations.
The earliest of these was passed in December 2006 and the latest in September 2007. There is a
two year trial period after passage for trial use, during which prototype systems are to be built
and evaluated. At the end of 18 months after passage, IEEE begins collecting comments on the
standards, and at the end of the trial use period the standard will be either confirmed, revised or
dropped.
Currently the IEEE 1609 Working Group is involved in active revision and addition to
the standards, based on experience of various groups with testbeds and DSRC WAVE
prototypes. Full use versions of 1609.3 and 1609.4 were put out for the first sponsor ballot in
March 2010. The fact that different members of the family were approved for trial use at
different times has caused some problems with consistency that are being addressed during this
revision. Problems with stability of the standards were also induced by the changing assumptions
at the 802.11p level of how much functionality would be included in the 802.11 MAC. As more
prototypes and products are implemented and tested, real requirements are fed back into the
IEEE 1609 standards process, which are currently being rewritten for full use.
Under Task Orders 5214 and 6214, Caltrans funded the participation of PATH
researchers Dr. Susan Dickey and Somak Datta Gupta in the IEEE 1609 Working Group
standards revision process. Dr. Dickey has been involved since fall of 2005, and has functioned
as the secretary and keeper of the errata lists. On consultation with colleagues at PATH, she
submitted the following list of bullet points to Tom Kurihara, 1609 Working Group chair, for
consideration during the revision at the end of the trial use period:
• Include mechanism to handle priority of communications not just on the air link but throughout
backhaul communications.
• Include possibility of communication filtering and certificate handling at RSU, to deal with
restricted backhaul communication bandwidth.
• Allow DSRC communication between RSUs and stationary sensor processors for the purpose of
safety and traffic control applications.
• Provide a mechanism for multihop routing vehicle- to- vehicle, with possible gateways at RSUs.
• Design transparent certificate handling procedures that preserve security without enforcing
proprietary monopolies for services.
• Explicitly allow that some applications which do not exchange data with immediate roadside
consequences ( e. g. probe data applications) may not require certificates.
19
• Re- evaluate provider/ service ID and context mark terminology and mechanisms, to make usage
and terminology more sensible and more consistent with existing network middleware.
• Consider the possibility of ensuring the ITS band mandate for low latency safety
communications be dedicating one channel for this purpose, and, assuming two radio
configurations are possible, running 1609 protocol with less critical communications on the
remaining channels.
Somak Datta Gupta of California PATH is actively involved in a complete rewrite of
1609.1 with a different emphasis as described in section 2.4.2.6. In the following subsections, we
first summarize the characteristics of the 1609 trial- use standards, and then discuss issues in the
on- going revision process.
2.4.1 IEEE 1609 Trial Use Standards
The layers of the networking stack associated with the different IEEE 1609 WAVE standards are
illustrated in Figure 10 below.
Figure 10: WAVE standards ( from IEEE 1609 trial use standards)
A legacy system for toll tag reading in the previous 900 MHz DSRC standard was
originally the basis for 1609.1. This became almost completely irrelevant to planned
implementations for 5.9 GHz DSRC. At the higher levels of networking and application services,
the 1609.1 DSRC Resource Manager trial use standard described the application level services
and interfaces designed to support command- response applications of the style supported under
the old DSRC standard and currently used by Electronic Toll Collection ( ETC) applications, thus
providing an easy transition to WAVE technology for the installed base of ETC applications.
However, for new applications based on more modern models of programming and network
middleware, this method is unnatural and inflexible, so this standard has been made optional.
20
Since 1609.1 was approved first, there is an inconsistency in the use of data fields that are called
Application Context IDs and Context Marks in 1609.1 and Provider Service IDs and Context
Marks in 1609.3.
The P1609.2 Security Services for Application and Management Messages trial use
standard defines secure message formats and processing of secure messages, within the
DSRC/ WAVE system, defines methods for securing WAVE management messages and
application messages, with the exception of anonymity- preserving vehicle safety messages, and
describes administrative functions necessary to support the core security function. This method is
certificate- based, cleverly avoiding the latency of handshaking, but introducing problems of
certificate distribution.
The 1609.3 Networking Services trial use standard defines services operating at the
network and transport layers to support vehicle- to- vehicle as well as vehicle- to- roadside and
roadside- to- vehicle communication using the 5.9 GHz DSRC/ WAVE mode. In particular,
P1609.3 describes a WAVE Short Message protocol ( not based on the IP suite of Internet
protocols), that can be used for low- latency vehicle- to- vehicle communication, in conjunction
with IP protocols for other applications. It also defines application registration services that so
that applications may announce their services to neighboring stations, as well as registering
application priorities for use by lower layers.
The 1609.4 Multichannel Operations trial- use standard describes multi- channel wireless
radio operations using the WAVE mode at the MAC and physical layers, including the operation
of control channel and service channel interval timers, parameters for priority access, channel
switching and routing, management services, and primitives designed for multi- channel
operations. The MAC contains two EDCA entities ( from IEEE 802.11e QoS enhancement) for
control channel and service channel respectively ( see Figure 11). The basic multi- channel
operations scheme is to have every station return to the Control Channel to listen for WAVE
service announcements and WAVE short messages for a part of a fixed interval and the switch to
service channels as desired for IP traffic for the rest of the interval. Note that even if some
stations are able to have two radios and dedicate one to the Control Channel, if any stations are
switching between Control and Service, all stations must do their Control Channel broadcasts
during the interval when the single radio stations are listening. There are still many unanswered
questions in this area about the best possible channel scheme to ensure low latency, have
reasonably good utilization of available bandwidth, and keep the radios inexpensive, and these
questions are an active area of discussion at the IEEE 1609 Working Group meetings ( see
Kenney 2009, Hong/ Rai/ Kenney 2009, Hu 2009).
21
MAC ( with Muti- Channel Operation)
Transmission
Attempt
Channel Selector and Medium Contention
Internal Contention
AIFS[ AC]
CW[ AC]
TXOP[ AC]
AIFS[ AC]
CW[ AC]
TXOP[ AC]
AIFS[ AC]
CW[ AC]
TXOP[ AC]
AIFS[ AC]
CW[ AC]
TXOP[ AC]
Internal Contention
AIFS[ AC]
CW[ AC]
TXOP[ AC]
AIFS[ AC]
CW[ AC]
TXOP[ AC]
AIFS[ AC]
CW[ AC]
TXOP[ AC]
AIFS[ AC]
CW[ AC]
TXOP[ AC]
CCH ( WSM data only) SCH ( WSM and/ or IP data)
LLC
Channel Routing
802.11p MAC ( CCH)
802.11p MAC ( SCH)
Management
frames
Management
frames
AC= 1 AC= 2 AC= 3 AC= 4 AC= 1 AC= 2 AC= 3 AC= 4
Figure 11: Two EDCA entities in MAC layer ( from IEEE 1609.4 trial use standard)
An alternative view of 1609 protocol stacks is also shown in Figure 12, taken from a
recent presentation at the 1609 Working Group by John Moring of Kapsch/ Technocom: ( Moring,
2009a)
Figure 12: Alternative view of WAVE standards ( from Moring’s presentation)
22
2.4.2 Current issues in IEEE 1609 WAVE
In this section, we describe open issues and current development in WAVE standards regarding
the networking services ( IEEE 1609.3) and multi- channel operations ( IEEE 1609.4), including
the distribution of timing information, vendor specific action frame, transmission power
constraint, channel switching, and service initialization decision making. We also describe open
issues regarding the resource manager ( IEEE 1609.1), electronic payment via WAVE ( IEEE
1609.11), and security algorithms ( IEEE 1609.2).
2.4.2.1 Timing Information
In the trial use standard of IEEE 1609.4, timing information is provided only by the service
provider, and ( based on information from the provider) a user can then estimate UTC ( Universal
Coordinated Time). A common practice is to assume Gaussian noise and use a Kalman filter to
get a mean and variance of UTC time estimates. Initially, the possibility of using WAVE stations
( STAs), that are not providers, to provide only timing information. A STA may want to obtain a
more accurate update but doesn‘ t want to wait until it gets into coverage of a provider. If there
are other STAs around that have UTC, then it may get timing information from them. This
information flow may be operating only on an SCH. Figure 13 shows the path of timing
information flow from a service provider to a user in the trial standard. There may also be cases,
e. g. 1609.1, of devices which don‘ t want WSA but may want UTC to a coarser accuracy than
that required for sync. Figure 14 shows a design from a timing provider ( not necessarily a service
provider) to a timing user; for more details see ( Moring, 2009b).
Figure 13: Flow of timing information using WSA in trial use IEEE 1609.4
23
Figure 14: Flow of timing information from a timing provider proposed by Morning
2.4.2.2 Vendor Specific Action Frame
In the trial use standard of IEEE 1609.3, all WAVE management information was distributed via
a ― WAVE Announcement‖ frame. Time Advertisement ( TA) frame contains the critical
Timestamp field set by 802.11. A type of frame, called Vendor Specific Action ( VSA) frame, is
proposed to include WAVE Service Advertisements and perhaps other announcements, e. g.,
regulatory information, country of operation, channel sets in use, transmit power constraints, and
device configuration info per 1609.1. Table 2 lists all types of requests provided by IEEE 1609.3
( Moring 2009c).
Table 2: Types of requests provided by IEEE 1609.3
Service
Request Type
Primary Purpose Channel/ interval
assignment
Message
Generation
Provider
Service advertisement/
SCH participation
WSA on CCH in CCH
interval; service on SCH in
SCH interval
VSA frame
containing WSA
User
Service notification/ SCH
participation
SCH in SCH interval, plus
optionally SCH in CCH
interval
none
WSM Received message routing none none
CCH
Control channel
participation
CCH in CCH interval none
Management
data
Management data
distribution
CCH or SCH; CCH or
SCH interval or both
VSA frame
Timing
advertisement
Time distribution
CCH or SCH; CCH or
SCH interval or both
TA frame
24
To streamline the sending of WAVE management information via the VSA, generic VSA
SAP ( Service Access Point) is proposed to be included in 1609.3 WME, which schedules the
announcements in concert with data plane services. This allows ― other‖ management entities,
e. g., 1609.1, to exchange info via management frames. Figure 15 shows the flow of VSA
messages. Data routed to receiving entity via new Management ID in the Organization Identifier.
WME may still exchange WAVE Service Advertisements ( WSAs) via interaction through
MLME.
Figure 15: An example of flow of Vendor Specific Action ( VSA) messages
A generic VSA SAP is also provided at 1609.4 MLME. This allows opaque management
information to be sent and received on SCH or CCH. However, the 1609.4 performs no
processing on content, including WSAs. The Vendor Specific Content is completely under
control of the management entity identified by Management ID ( in this case 1609.3 WME),
including any security processing. Figure 16 shows the format of VSA that contains a WSA.
Figure 16: Format of Vendor Specific Action ( VSA) that contains a WSA
25
2.4.2.3 Transmission Power Constraint
IEEE 1609 allows higher layers to set transmit power on individual messages, e. g., the
transmission power for WAVE short messages ( WSMs) can be set on a per frame basis.
However, there are regulatory constraints limiting the maximum transmission power. Thus, it is
important to make sure the 1609 stack does not transmit at illegal power levels. In trial use
standard, WAVE distributes Transmit Power Level for each SCH in the WSA.
To prevent such illegal transmissions in SCH, the 802.11 MAC/ MLME should prevent
transmissions from exceeding the allowed maximum, even if requested by higher layers. For
CCH, trial use standard does not distributed power constraints for the CCH. It is thus proposed to
include this power constraint in the Channel Info of the WSA and to include this feature in
1609.3 and 1609.4. That is, Providers may broadcast regulatory information in WSA, including
Country String in WSA header and Power levels in Channel Info. Users override default power
limits on receipt of valid WSA. Meanwhile, Users retain latest received Country String, and
Users revert to default power levels on leaving Provider coverage; for more details see ( Moring
2009d).
2.4.2.4 Channel Switching and Time Alignment
In 1609, channel information is used in several places. First, in WSA, channel information is
carried for each advertised service. This channel information is provided by higher layers at
Provider, accepted by User, indicating channel number, power, rate, EDCA parameters. Second,
in Transmitter Profile, it is registered with lower layers for each channel carrying traffic IP and
the same channel information is carried in WSA. Third, in WSM, channel number and other
parameters are provided by higher layer at transmitter. Forth, in 1609.4 MIB, channel list
identifies usable channels, including CCH. Finally, in 1609.3 MIB, channel number is included
in Available Service Information ( from received WSA) and User/ Provider Service Information
( from higher layer). It is proposed to use both country string and channel number to identify a
regulatory class. Table 3 and 4 show the regulatory classes used in U. S. A. and Europe. Table 5
shows the idea of using both country and channel number information to identify a channel.
Table 3: Regulatory class and channel number in U. S. A.
26
Table 4: Regulatory class and channel number in E. U.
Table 5: Channel identification using country string and regulatory class
In addition, in trial use 1609.4, a channel switch is accomplished via MLME sending, but
dot11CurrentFrequency ( in 802.11p) does not uniquely identify a channel. In 802.11 MIB
( Management Information Base), dot11CurrentFrequency, dot11CountryString,
dot11ChannelStartingFactor, and dot11PhyOFDMChannelWidth are available. These four
parameters are necessary and sufficient to specify a unique Regulatory Class as defined in
802.11 Annex J. The Country String is configured in the MIB and can be updated via the WSA.
The dot11CurrentFrequency is set at each channel switch. The dot11ChannelStartingFactor and
dot11PhyOFDMChannelWidth are set at each channel switch.
Time alignment is another important issue. Some devices may need to switch channels on
channel interval boundaries to participate in multiple services. Some devices base security
verification of received messages on knowledge of time. Some of these same devices may not
have a local absolute timing source. Figure 17 illustrate this channel switching behavior. To
above purposes, WAVE must provide an over- the- air time synchronization option with better
than 1 ms accuracy. It is thus proposed to design devices that periodically transmit timing
information. With received information, receiving devices may derive time synchronization
27
adequate for switching within the guard intervals occurring on channel interval boundaries. See
more details in ( Moring 2009e, 2009f).
Figure 17: Time alignment and channel switching in time/ frequency domains
2.4.2.5 Service Initialization Decision Making
In current design of IEEE 1609, service link quality assessment is used as a basis for service
initiation decision. For example, a vehicle would consider starting a service only if it
successfully receives 5 WSAs in a row or the signal quality of the received WSAs are
consistently good. At the 1609 Working Group meeting in August 2009, Daniel Jiang of
Mercedes- Benz Research and Development North America proposed to include service provider
location information in WSA ( Jiang 2009). By comparing provider location information and self
location information, a vehicle can decide the distance to service provider and decide when to
start services. This method is simple and straightforward. This also enables optimizations based
on vehicle path considerations. See details in
Figure 18: Service initialization based on location information proposed by Jiang
28
2.4.2.6 Resource Manager
One of developing concepts for 1609.1 is to support low- end devices, e. g., intelligent cones.
Those low- end devices may include a single application or limited applications. Those devices
are not service providers, and they are not autonomous, i. e., they are managed. It is proposed to
add new functionalities in 1609.1 to support over- air management of those low- end units, e. g.,
their sleep mode, the triggering on message or event, etc. Alastair Malarky of Mark IV has taken
the lead in producing an initial draft. ( Malarky 2009). It is proposed that specific RSEs/ OBEs
may configure low- end units using over- air management, including 802.11 and WME defaults,
device identity, sleep settings, trigger settings, and activation of application on unit. Besides,
RSEs/ OBEs can also request device configuration/ status.
For low- end devices, their 1609.1 Identities include physical and logical identities. For
the physical identity, its Vendor Identity is permanent and globally unique. For the logical
identity, its Session Identity is assigned by its Management device. This session ID is used for
higher layer access on Management device and is only used over the air. This session ID allows
for anonymity. This identity is in protected data fields. This kind of over- air- management is done
by using 802.11 Vendor Specific Action frame.
Specifically, to save energy consumption, those low- end devices can be configured to
― sleep‖ with timeout and triggers. Those devices support Wake on message capability so that
they resume operations upon receiving control message and application message. Those devices
also support Wake on external trigger capability so that they can be activated by physical ports
on device or feedback signals from a sensor or loop detector.
2.4.2.7 Toll Transaction
A new standard IEEE 1609.11 is in development for electronic payment over WAVE, e. g., toll
transactions; an outline was proposed at the June 2009 IEEE 1609 Working Group meeting by
Justin McNew of Kapsch Technocom ( McNew 2009). In this outline, the concept of Application
contains an Application Core and the WAVE Interface Application Layer ( WIAL). The
Application Core mains application- specific processing which WAVE might be unaware of. The
WAVE Interface Application Layer ( WIAL) performs application- specific interfacing with
Application Core and the WAVE Stack. Payment Service provides services for Application Core
or WIAL, depending on the system. Figure 19 illustrates this concept.
Two basic payment options were identified. They are User and network preapproval ( i. e.,
― Preapproved‖ scenario) and User approval of at time of invoice and network approval at time of
payment (― Invoice‖ scenario). Both Payee and Payer Payment Service should support operations
for encryption and decryption of octet sequences. For the ― Pre- approved‖ scenario, user approves
payments in advance of over- the- air transaction. Payee generates receipt and sends account
information to central payment entity offline. For the ― Invoice‖ scenario, end user approves
invoice ( e. g. via HMI). Payee may send payment information to a central payment entity or
entities. The ― Pre- approved‖ scenario and the ― Invoice‖ scenario are shown in Figures 20 and 21
respectively.
29
Figure 19: An application is composed of application core and WIAL in 1609.11
Payer
Application/
Payment
Service
Account Information
Receipt
Payee
Application/
Payment
Service
Figure 20: Illustration of “ Pre- approved” scenario in 1609.11
Payer
Application/
Payment
Service
Payment confirmation
Payee
Application/
Payment
Service
Invoice
End- user
approval
( out of scope)
Payment information
Payment
approval
( out of scope)
Figure 21: Illustration of “ Invoice” scenario in 1609.11
30
2.4.2.8 Security
Some studies of the security algorithm in trial use standard 1609.2 indicate that it may be too
expensive in terms of hardware capability to carry out the required computations. New algorithm
have been proposed to reduce the computation requirements. A presentation by Andres
Weimerskirch at the February 2009 meeting gave an excellent exposition of these issues, from
the point of view of the Vehicle Safety Consortium group of automotive manufacturers
( Weimerskirch 2009).
The objective of the privacy algorithm is to ensure security of WAVE operations while
avoiding long- term tracking via infrastructure. For example, security algorithms need to handle
change of all identifiers of the vehicle: MAC address, J2735 sender ID, certificate, etc. More
specifically, security for WAVE should address the following: First, an application should only
accept a valid message from a valid unit, within the intended reception time, within valid
geographic location. Secondly, devices should not be locked out of the system, which might
results in failure of important applications. A good algorithm should satisfy both requirements.
1609.2 ECDSA TESLA TADS
Authentication
generation
6.5 ms* ( ECC-
224) / 10 ms
( ECC- 256)
1.5 ms
8 ms* ( ECC- 224) /
11.5 ms ( ECC- 256)
Authentication
verification
26 ms* ( ECC-
224) / 39 ms
( ECC- 256)
1.5 ms
1.5 ms ( TESLA) /
40.5 ms ( ECDSA- 256)
CPU Load for 2
OBEs at 10 messages
per second: Signing /
Signing + Verifying
13% / 67% 3% / 3.8% 14.3% / 21.7%
Latency: Min. / Max. 61 ms / 90 ms
piggy-back
separate
piggy-back
separate
91 ms /
123 ms
26 ms / 28
ms
116 ms /
145ms
40 ms* / 42
ms*
OTA packet size
( send certificate with
each 3rd message and
using ECC- 256)
115 bytes 102 bytes 167 bytes 141 bytes 210 bytes
Table 6: Performance comparison on OBU at 400MHz ( reported by VSC- A)
31
Currently in 1609.2, ECDSA ( Elliptic Curve Digital Signature Algorithm) is supported to
change certificate/ MAC/ sender ID during service channel and have it available at beginning of
control channel. Other authentication protocols for V2V safety applications have been presented.
For example, TESLA ( Timed Efficient Stream Loss- tolerant Authentication) is computationally
efficient than ECDSA. TESLA change certificate/ MAC/ sender ID during service channel and
have it available at beginning of control channel. It tries to disclose TESLA key during the same
CCH interval in which the TESLA message was broadcast. This is already implemented by
generating and broadcasting heartbeat messages at the beginning of the CCH interval. However,
this algorithm increases delay. The TADS ( TESLA Authentication and Digital Signatures)
combines benefits of TESLA ( computational efficiency) and ECDSA ( low latency on demand,
non- repudiation). However, TADS increases bandwidth overhead. Another algorithm, Verify- on-
Demand, only verifies messages that have actual impact and it‘ s compatible with current 1609.2
standard. The performance of ECDSA, TELSA, and TADS is compared in Table 6. The optimal
algorithm that balances those factors is still under investigation.
2.5 Summary
Looking at the DSRC standards effort, IEEE 802.11p specifies high- speed short- range wireless
communication among vehicles and surface transportation infrastructure. Similar to IEEE
802.11a, 802.11p radio is based on matured Orthogonal Frequency- Division Multiplexing
( OFDM) technology. The 802.11p MAC layer functionality is slightly modified to include
provision for rapid communication of DSRC devices with no need for authentication or
authorization processes as in the original 802.11 standard. In addition to the 802.11p standard,
IEEE 1609 defines higher layer functionalities such as networking and multi- channel operations
for VANETs. As part of these standards, a new type of message, WSM ( WAVE Short Message)
is defined in 1609.3, which supports frame- by- frame power and modulation assignment and thus
provides new possibilities for cross- layer optimization. To ensure that DSRC applications are
inter- operable, other standards may be employed in this architecture For example, SAE J2735 is
a message set dictionary ( i. e. common languages for DSRC applications to understand each
other) that describes DSRC message content. The standardization effort has been equally
supported by industry and government entities.
The Wireless Access in Vehicular Environments ( WAVE) proposed Amendment P to the
IEEE 802.11 Wireless LAN standards ( the specifications underlying WI- FI and the related IEEE
P1609 family of standards for higher- level networking and applications services, have been
designed to meet these challenges. Implementations of these standards will support U. S.
Department of Transportation‘ s Intelligent Transportation Systems ( ITS) Program and the
Federal Highway Authority‘ s Vehicle Infrastructure Integration Initiative. These automotive
networking services will operate in a special licensed Dedicated Short Range Communication
( DSRC) frequency band that has been set aside by the Federal Communications Commission
( FCC) for public safety use.
32
3. Architecture and Design of Vehicle- Infrastructure Testbeds for
Dedicated Short- range Communication
3.1 Overview of DSRC Development
3.1.1 Introduction to Vehicle- Infrastructure Cooperation
The inclusion of the roadside element is a logical extension of Vehicular Ad- hoc Networks
( VANET), from the perspective of those with vehicle- centric and also those with infrastructure-centric
network applications backgrounds. Consider that stationary motes – or roadside
equipment ( RSE) – intersect moving cars, and represent the edge of and therefore access to an
extensive landside network, replete with existing, or with vehicle- infrastructure cooperation
( VIC) replete with new user services. The idea of onboard equipment ( OBE) and RSE
connecting offers a plethora of information- based applications and, important to the traveler, a
plethora of information- based services. And what is this plethora of services? Mobility
applications should have the basic attribute to deliver dynamic traveler information and may
include:
 Traffic and travel conditions, including route specific travel times and delays
 Route assistance and route diversion
 Map database assistance
 Adverse weather information
 Multi- modal trip planning: transit connections, fare information, schedules, and real- time
bus/ train arrival information, airport and port authority information
 Parking information, to include transit and commercial vehicle parking
 Signal phase timing information ( for signal coordination)
 Road surface conditions
Moreover, safety services may include:
 Vehicle- based sensor and communication systems, to include vehicle- vehicle
communications
 Cooperative intersection collision avoidance systems, to potentially include signal
violation warnings
 Merge assistance systems
 Rear- end collision warning systems
 In- vehicle signing for both static and dynamic and dynamic advisories
 Transit applications such as precision docking and automation
These applications lists are not comprehensive; they are merely a list, and given VIC as an
enabler, transportation services that depend on telematics would have the attribute of real time or
on- demand information – and the list may grow as large as the marketplace of useful service and
application providers and willing subscribers ( and their road authorities) allow. Another
33
dimension to this marketplace is provision of on- demand infotainment, as the delivery of these
products to vehicles may provide economic incentive to build an infrastructure that provides
additional mobility services and to some, the safety imperative.
The real question, then, is how do these services begin to be delivered? A key to the
answer will be the existence of RSE which are in two- way communication to cars, or VIC.
Given VIC and the existence of a backhaul network to landside operations there can be delivery
to and from the first equipped vehicle of existent telematics and infotainment services, e. g., travel
time information. Subsequently, as OBE- equipped vehicles proliferate, market- penetration-based
services available by information exchange between vehicles and the stationary RSE
become more real. Take for example, the VII California test bed along North- South corridor in
the San Francisco Bay Area, circa 2007: a ― mere‖ presence of 12 RSE intersects an average of
400,000 vehicles a day, traveling three major routes, two limited access freeways and one major
signalized arterial. Presuming applications delivered from these RSE provide some benefit to
travelers, there is no need to await market penetration to allow acceptable peer- to- peer
connectivity and VANET.
In fact, a compelling aspect of having some installation of RSE is that the roadside
component and services it may provide could engender bringing OBE into vehicles; what may
make this even more compelling is that these OBEs brought into vehicles may not only be
automotive company installations, they could be handheld consumer electronic devices that
make this short- and medium- range connectivity: mobile phones, perhaps equipped with WiFi or
even Dedicated Short Range Communication ( DSRC). Imagine dynamic route advisories given
to drivers to route themselves out of traffic jams; imagine windshield wiper data giving roadway
authorities insight to a moving storm front; imagine the wealth of services that could enhance
travel, traffic management and indeed, transportation efficiency and our quality of life.
However, the real DSRC case is safety, and how to deliver the quality of service – that is,
low latency and highly available – safety- of- life messages necessary to enact an OBE- to- OBE or
OBE- to- RSE/ RSE- to- OBE wirelessly- delivered safety message. In this case, the entire network
need not be present; rather, the edge of the network car- to- road or road- to- car can exchange
detailed in- vehicle information which can be displayed in a nearly immediate and indeed urgent
manner to the driver. Imagine an intersection that warns the inattentive driver that the yellow
phase will imminently turn to red – and prevent a red light violation; imagine a car that brakes
hard or conversely one that brakes moderately, with that safety information communicated via
DSRC to the car or string of cars behind such that onboard processors and displays could provide
or not provide a warning; imagine again the wealth of services that could enhance safety and
along the way also increase transportation efficiency.
The arguments above, one a mobility and efficiency argument and another a safety
argument, have led institutions in the United States to mobilize around the 75 MHz of free
unlicensed bandwidth from 5.85 – 5.925 GHz and to begin to standardize and institutionalize
Dedicated Short Range Communications ( DSRC). This, until recently, has been the thrust of the
United States efforts in VIC, and this is the starting point of this chapter. However, in order to
impart a better understanding of the state of VIC, we will begin a bit more broadly by briefly
covering the worldwide context, then describe more pointedly the case in the United States ( and
probably by de facto precedent all of North America). We will describe some of the emergent
research with DSRC, some of the conceptual applications, and then we will point toward a
possible future that transcends a ― just DSRC‖ wireless paradigm, in work enabled by the United
34
States Department of Transportation ( US DOT), California Department of Transportation
( Caltrans) and conducted by the authors. This potential future comes full circle, placing work
across many regions of the world into the same trajectory, by recognizing the proliferation of
consumer handheld devices in the world and therefore taken by travelers on most trips, and then
by leveraging multi- band attributes beginning to appear on these devices and finally transitioning
into a world where applications, safety and mobility alike, may be ubiquitously applied across
the heterogeneous base of portable consumer devices.
In this section, we first discuss the development of VIC in the Europe, Japan, and the
United States. We discuss the current VIC communication technology in the United States and
present results on its performance derived using our VII California Testbed. Finally we conclude
with our reading of the future of VIC.
3.1.2 Development during 2004- 2008
3.1.2.1World Context
The idea of VIC captures the imagination worldwide, and it is interesting to observe the regional
and in some cases nation- by- nation ideas and means to instantiate them into a true VIC
deployment, and in all dimensions: in wireless communication frequency, in degree of
infrastructure at the roadside, in complexity of onboard equipment, in timeline to deployment
and in applications or services considered. Clearly, transportation needs, legacy infrastructure
and existent policy and other institutional arrangements dictate the degree and ubiquity of ideas.
While there are several world- regional ideas, in this section we describe the European
Commission‘ s Continuous Air interface for Long and Medium distance ( CALM) and the
Japanese SmartWay efforts. The description is topical and brief, as the primary message is that
despite the focus on this chapter on VIC in the United States, there are indeed other ideas, efforts
and flavors underway to effect VIC. These ideas – and CALM and SmartWay in particular –
have recently influenced thinking and policy in the United States, namely the work therein has
posed the questions, ― Is there a better way?‖ and ― Isn‘ t better defined as deployment sooner, not
in the distant future?‖ These are excellent questions and continually asked, they will always
point toward new and more relevant research.
The Continuous Air interface for Long and Medium distance ( CALM) is integral to the
European Commission‘ s Cooperative Vehicle- Infrastructure System ( CVIS) effort, as it provides
both an architecture and a means to interweave existing protocols such that multiband
communications may occur simultaneously, and in principle seamlessly. Therefore, in essence,
transportation applications may be delivered to a consumer device which has, for example, a 3G
communication channel. As market forces drive the consumer device to more and more
connectivity, such as 4G ( such as WiMax), WiFi or even IEEE 802.11p DSRC, the handheld
device operating under the CALM architecture will be able to still enact two- way
communication.
Therefore, CALM aims to integrate into an intelligent agent that arbitrates between and
provides security between nearly 25 different standards, many still in progress, and if and when
those standards roll out, CALM- compliant handheld platforms may be a communications link-neutral
or - independent applications environment. Via CALM and potentially as applied by
35
CIVIS, the transportation system manager will receive traffic probe data, and the traveler will in
turn receive local map data and that hoped- for plethora of various other services.
In October, 2007, several years‘ work in leveraging existing infrastructure and programs,
― Smartway 2007‖ was demonstrated by the Ministry of Land, Infrastructure and Transport and
the Transport National Institute for Land and Infrastructure Management. Smartway was hosted
on the Tokyo Metropolitan Expressway and was the culmination in delivering a prototype of
what the Japanese call an ― on- board ITS experience‖. It delivered in demonstration fashion an
ensemble of mobile services, either via integrated center console driver interface or through an
aftermarket audio- only version. Central to Smartway is VIC, as services were all delivered by
wireless. Services delivered fall under three categories:
 Near real- time driver assistance
 In- vehicle messaging
 Two- way communication, which enables e- payment or tolling.
In Japan, there are unique technological and institutional underpinnings and years of public- and
private- sector investment the Japanese surface transportation system. To wit, virtually every
new car sold in Japan is equipped with an in- vehicle navigation system additionally equipped
with a Vehicle Information and Communication System ( VICS) component. Therefore, as a
significant Smartway enabler, road and congestion state information for major arterials and
limited access highways is aggregated by the Japan Road Traffic Information Center, transported
to the VICS Center, then delivered by optical ( IR) beam or 2.4 GHz radio beacon back to cars.
The widespread adoption of VICS has allowed cars to serve as probes, which multiplies the
efficacy of this system.
As a second significant Smartway enabler, at the time of the demonstration,
approximately 75% of all cars using toll roads in Japan were equipped with 5.8 GHz DSRC-based
Electronic Toll Collection ( ETC), developed to Japanese standards and implemented by
most expressway authorities in Japan. This particular DSRC range is 30 meters, sufficient to
accomplish its primary purpose providing the short range communications link for an automated
tolling transaction.
Therefore combining the two enablers, or fusing VICS and ETC onto one OBE, allows
probe information already available from VICS to be sent via DSRC from the infrastructure to
the vehicle and vice versa. This new OBE serves as a gateway for telematics applications to be
delivered from the roadside to the vehicle and then displayed in the VICS- equipped navigation
unit. Importantly to VIC deployment, hardware development with such a system based on this
unique Japanese legacy was not difficult. Essentially, the primary tasks are to develop
applications delivered through the landside portion of the network and deliver by existing
communication means to the Smartway OBE and to the customize user interfaces. Thus, a total
of eight Smartway applications were demonstrated:
 Milepost (‗ positional‘) Information: Delivery of Changeable Message Sign- and overhead
sign panel- equivalent in- vehicle signage of distance to exits or significant destinations.
 Audio Messaging: Link times provided through in- vehicle auditory means, e. g, ― 10
minutes to Exit A.‖
 Merging Assistance: Visual and audio information provided at merge point when other
vehicles, perhaps occluded, merge onto the mainline or vice versa.
36
 Information on Conditions Ahead: Visual and audio information – to include a still- frame
video detection camera output – of congestion on the upcoming roadway. In Japan, the
particular siting would be at tunnel entrances or other known bottlenecks, e. g., ― Current
traffic flow ahead of Gaien entrance about 1 km ahead‖ as caption to a surveillance
camera image.‖
 Parking Lot Payment: E- transactions conducted via credit card- through- DSRC
transaction at a parking lot adjoining the Metropolitan Expressway
 Internet Connection: Delivery of http via 5.8 GHz DSRC brought to the vehicle within
the aforementioned parking lot. Internet content is carefully controlled in the
demonstration, but the attendee can envision the freedom of the internet through this
demonstration.
 Road Alignment: Use of an onboard map database, which when combined with vehicle
speed, enable delivery of curve overspeed warnings, e. g., ― Sharp curve ahead! Drive
carefully.‖
 Obstacle Warning: Particularly important with upcoming blind curves, visual and audio
information on stopped vehicles around the bend of the curve is provided, e. g.,
― Congestion ahead! Drive carefully.‖
3.1.2.2VIC in the United States
The roots of DSRC in the United States may be formally traced to 2003, when the Federal
Communications Commission ( FCC) adopted what is termed a Report and Order that provided
licensing and service rules for DSRC in the ITS Radio Service. This enabled free, licensed use
of the 5.850- 5.925 GHz frequency range, primarily for use in safety but also for other
transportation and commerce applications. It was originally conceived as a general purpose
RFID technology. In making implementation decisions, however, it was quickly recognized that
the IEEE 802.11 wireless local area networking technologies represented a better base for
DSRC. In particular, DSRC came to be based on the IEEE 802.11a OFDM sub- family which
over time came to be the dominant home and enterprise wireless LAN product. The economies
of scale obtainable by piggybacking DSRC on 802.11a mad