ISSN 1055- 1425
August 2009
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 5217
CALIFORNIA PATH PROGRAM
INSTITUTE OF TRANSPORTATION STUDIES
UNIVERSITY OF CALIFORNIA, BERKELEY
VII California: Development and
Deployment— Lessons Learned
UCB- ITS- PRR- 2009- 35
California PATH Research Report
Jim Misesner, et al.
CALIFORNIA PARTNERS FOR ADVANCED TRANSIT AND HIGHWAYS
Task Order 5217 Final Report
VII California: Development and Deployment
Lessons Learned
Authors
Jim Misener
Susan Dickey
Joel VanderWerf
Ashkan Shrafasaleh
Kang Li
Han- Shue Tan
Meng Li
Zhi- jun Zou
Fanping Bu
Ching- Ling Huang
Guan Xu
Steven Shladover
Tom Kuhn
Matt Barth
Michael Todd
Wei- Bin Zhang
ACKNOWLEDGEMENTS
The authors would like to thank Dr. Karl Wunderlich of Noblis for providing the TCA software
and advice about its use. We also wish to thank our PATH colleagues Kun Zhou and Yoa Mao
for their support and discussion. The authors would like to thank Toyota ITC and Volkswagen of
America ERL colleagues for their significant inputs in developing this curve over- speed warning
system in the VII- CA project. The authors are also grateful to NAVTEQ for providing digital
maps.
The authors would like to thank Miguel Egea, James Lao, Lindy Cabugao and numerous other
Caltrans District 4 personnel who helped us with installation, repairs, troubleshooting and
understanding traffic signal controllers. Special thanks go to Jim Arnold with FHWA for
consistently providing updated information on the status, cost, and implementation details
associated with the HA- NDGPS.
Additionally, the authors would like to acknowledge San Francisco Department of Parking and
Traffic for the use of their facilities. We would also like to thank Bart Duncil for work in
designing the gumstix assemblies and initial testing of the system, Bernard Liang for his work
developing GPS utilities, Shel Leader for organizing the work with the San Francisco roadside
equipment and for setting up vehicle equipment and antennas, and Thang Lian and Tim Duff for
many hours spent driving around the block.
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. Finally, the mention of commercial products, their sources, or their
uses in connection with material reported herein is not to be construed as either an actual or
implied endorsement of such products.
i
ii
ABSTRACT
This PATH Research Report covers the ( Vehicle- Infrastructure Integration) VII California
Development and Deployment ( Task Order 5217) efforts from October 2005 – December 2007.
Because TO 5217 is followed by the continuation TO 6127, it is a compendium of very
applications- oriented research to date as well as a final report to TO 5217.
It is organized to impart the very specific and generally very pragmatic implementation details
first, beginning with an introduction ( Section 1), description of VII hardware, general network
and installation ( Section 2), then progressing to a more detailed description of the network and
operating software ( Section 3) and finally to applications in development and prospective
applications ( Section 4). Because it is not yet a final report but rather a ‘ research in progress’
report, it does not comprehensively address every task in the VII California family of task orders;
specifically, several of the applications described in Section 4 are represented as works in
progress ( as they are at this writing), and the on- ramp metering study is not yet reported. Again,
the purpose, of this report is to provide the reader with an understanding of how VII California
was implemented.
KEYWORDS
Vehicle Infrastructure Integration, Curve Overspeed, Traffic Probe Data, HA- NDGPS, Roadside
Equipment, Onboard Equipment, DSRC, RSSI
iii
iv
EXECUTIVE SUMMARY
This PATH Research Report covers the ( Vehicle- Infrastructure Integration) VII California
Development and Deployment ( Task Order 5217) efforts from October 2005 – December 2007.
Because TO 5217 is followed by the continuation TO 6127, it is a compendium of very
applications- oriented research to date as well as a final report to TO 5217.
The report is organized to impart the very specific and generally very pragmatic implementation
details first, beginning with an introduction ( Section 1), description of VII hardware, general
network and installation ( Section 2), then progressing to a more detailed description of the
network and operating software ( Section 3) and finally to applications in development and
prospective applications ( Section 4). Because it is not yet a final report but rather a ‘ research in
progress’ report, it does not comprehensively address every task in the VII California family of
task orders; specifically, several of the applications described in Section 4 are represented as
works in progress ( as they are at this writing).
Moreover, the report addresses a series of lessons learned as results of encountering issues and
complications, and provides future insights to overcome to these impasses. These insights will
potentially provide invaluable knowledge for future implementation in California and throughout
the nation.
As highlighted in Section 2, the installation of roadside equipment ( RSE) requires a large degree
of cooperation between various institutions. Furthermore, cooperation between these institutions
must also extend to maintenance and updating hardware.
In Section 3, the report discusses in extensive detail the network and operating software that
accompanies the VII California testbed. Various prototype operating software are used in
monitoring and troubleshooting the RSEs without the physical intervention of the operator. The
report lists several constraints arise from networking problems and discuss several working
solutions. Networking problems have been encountered and largely addressed during the course
of work; this experience engenders the expectation of more constraints and ‘ more of the same’
but at a larger scale as work progresses to address security, scalability, and conformance to the
emerging national VII standard.
Additionally, Section 3 also discusses the details in implementation. PATH has developed a
middleware for the exchange of these messages between in- vehicle client software and back- end
application servers.
Lastly, the report discusses current ongoing work on several applications of VII, described to
further detail within the document:
1. Curve Overspeed Warning System
The Curve Overspeed Warning System ( COWS) is one of the two cooperative active
safety applications of VII California. ( The other such time- critical safety of life
v
applications that requires low latency, highly reliable and available vehicle- to-infrastructure
and infrastructure- to- vehicle communication is Cooperative Intersection
Collision Avoidance Systems ( CICAS), not covered in this report.) The COWS system is
aimed to integrate on- board sensors, digital map, GPS and the broadcasted information
from the RSE to predict safety speed and provide speed advisory or warning messages to
the driver.
2. Traffic Probe Data Processing
The advent of VII offers the opportunity to revolutionize transportation data collection by
eventually enabling virtually all road vehicles to serve as traffic data probes, collecting
information about their motions and transmitting it to roadside receivers. This has
profound implications for the future of transportation planning and operations by
providing most, if not all, of the data they have dreamt of having, and probably providing
much more data than they have ever had to manage before. The primary challenge could
quickly shift from determining how to extract as much information as possible from
limited available sources of data to determining how to efficiently identify and extract the
most relevant and important information from an avalanche of largely redundant data.
3. Application of VII Data on Real- time Arterial Performance
The VII communication between cars and roads could benefit both parties and could be
very powerful, as it would enable the full vision of intelligent transportation system ( ITS).
For example, the information transmitted from the roadside to the vehicle could warn a
driver that it is not safe now to enter an intersection. On the other hand, vehicles could
serve as data collectors and anonymously transmit traffic and road condition information
from all major roads which are equipped with such communication infrastructures. Such
information would significantly improve the quality and quantity of traffic data, which in
turn will help transportation agencies and all other stakeholders to better understand, plan,
and manage the transportation system.
4. Intersection Application
Traffic signal timing is a mature and sophisticated study in its own right. Many existing
traffic controllers already run software that supports communication protocols, such as
the National Transportation Communications for ITS Protocol ( NTCIP) [ 17] and
California’s Assembly Bill 3418 ( AB3418) protocol, designed to communicate signal
phase and loop detector information to traffic management centers. However, these
protocols were designed for monitoring and control of actuated and coordinated
intersection timings, from a central location over a modem, at a time granularity of
seconds. They were not designed to notify vehicles of real- time signal phase count-down,
needed for the signal violation countermeasures over a high bandwidth DSRC
connection. Traffic signal controller protocol messages also contain information that it is
difficult to interpret without access to the timing plan for the intersection developed by
the maintaining entity ( state or local traffic operations), and do not contain
geographical/ mapping information needed by vehicles in order to recognize what part of
vi
the signal phase information applies to the vehicle’s approach to the intersection.
Nevertheless, the experiments in this application have successfully reconstructed
sufficient information to broadcast the signal phase count- down needed for prototype
vehicle applications.
5. High Accuracy- Nationwide Differential Global Position System
The U. S. Department of Transportation and U. S. Coast Guard in conjunction with the
Interagency GPS Executive Board are currently developing a High Accuracy- Nationwide
Differential Global Positioning System ( HA- NDGPS), targeted at a variety of
transportation- related applications. The HA- NDGPS program provides the capability to
broadcast corrections to Global Positioning System ( GPS) receivers over long ranges to
achieve a better than 10 centimeter ( cm) ( 95 percent of the time) accuracy throughout the
coverage area. HA- NDGPS is currently undergoing a research and development phase
with a future implementation pending U. S. congressional budget approvals.
Implementation of this technology will assist in providing advanced safety features for
transportation, including lane departure warning, intersection collision warnings, and
railroad track defect alerts. It also could be used for economic enhancements such as
precision container tracking and automated highway lane striping.
Again, all work described in this TO 5217 final report is ‘ work in progress’ and therefore it is not
a finalized product; that will be done as a result of TO 6127. That being said, this report serves
independent value in providing the reader an idea of why VII California was implemented and
some of the challenges faced and overcome. Thus, it gives the reader the sense of distance in
which VII California has covered and how far it will need to travel to reach its destination, and
potentially find an extension of a new road that would lead into a greater development.
vii
viii
TABLE OF CONTENTS
ACKNOWLEDGEMENTS ............................................................................................................. i
ABSTRACT ............................................................................................................................... ... iii
KEYWORDS ............................................................................................................................... . iii
Vehicle Infrastructure Integration, Curve Overpseed, Traffic Probe Data, HA- NDGPS, Roadside
Equipment, Onboard Equipment, DSRC, RSSI............................................................................. iii
EXECUTIVE SUMMARY ............................................................................................................ v
TABLE OF CONTENT ................................................................................................................. ix
LIST OF FIGURES AND TABLES........................................................................................... xvii
1. INTRODUCTION ...................................................................................................................... 1
2. VII CALIFORNIA TESTBED DESIGN.................................................................................... 5
2.1 ELEMENTAL BUILDING BLOCK WITHIN NETWORK: ROADSIDE EQUIPMENT .... 5
2.2 NETWORK: TRANSPORT LAYER ...................................................................................... 7
2.3 TESTBED – INSTALLATION, OPERATIONS, AND MAINTENANCE ISSUES .............. 9
2.3.1 RSE Installation ..................................................................................................................... 9
2.3.1.1 Institutional Issues .............................................................................................................. 9
2.3.2.2 Hardware Issues ................................................................................................................. 9
2.3.3 Installation Cost ................................................................................................................... 11
2.3.4 Maintenance Issues .............................................................................................................. 12
2.3.4.1 Hardware Maintenance ..................................................................................................... 12
2.3.4.2 Institutional Considerations .............................................................................................. 14
2.3.4.3 Network Operations and Maintenance .............................................................................. 14
2.4 IMPLICATIONS FOR THE FUTURE .................................................................................. 14
2.4.1 Hardware .............................................................................................................................. 14
2.4.2 Backhaul Options ................................................................................................................. 15
2.4.3 Institutional Issues ............................................................................................................... 15
2.4.4 Summary of Key Lessons Learned ...................................................................................... 15
2.5 FUTURE DEVELOPMENTS ................................................................................................ 16
3. PROTOCOLS AND PERFORMANCE................................................................................... 18
3.1 RSE MONITOR...................................................................................................................... 18
3.1.1 Introduction .......................................................................................................................... 18
3.1.2 Variables .............................................................................................................................. 18
3.1.3 Corrective actions ................................................................................................................ 19
3.1.4 Web Interfaces ..................................................................................................................... 19
3.1.4.1 Current reports ................................................................................................................. 20
3.1.4.2 Detail pages ...................................................................................................................... 21
3.1.4.3 Full report ......................................................................................................................... 22
3.1.4.4 Time- history graphs .......................................................................................................... 22
3.1.4.5 Map of testbed with status indicators ............................................................................... 27
3.1.4.6 Technical details ............................................................................................................... 27
3.2 NETWORK: MIDDLEWARE FOR VII- CA MESSAGES ................................................... 28
3.3 EVALUATION OF DSRC COMMUNICATION PERFORMANCE USING LOW COST
PROTOTYPE SYSTEMS WITH MULTIPLE RADIOS PER VEHICLE .................................. 30
ix
x
3.3.1 Introduction .......................................................................................................................... 30
3.3.2 Computer and Radio Equipment .......................................................................................... 31
3.3.3 Data Acquisition Software ................................................................................................... 32
3.3.4 Baseline Testing ................................................................................................................... 33
3.3.5 Effects of Channel Switching .............................................................................................. 37
3.3.6 Mobile Radios ...................................................................................................................... 47
3.3.7 Urban Intersection Testing ................................................................................................... 49
3.3.7.1 Packet length and interarrival time .................................................................................. 49
3.3.7.2 Data rate and queuing ...................................................................................................... 54
3.3.8 Conclusion ........................................................................................................................... 57
4. APPLICATIONS ...................................................................................................................... 58
4.1 CURVE OVERSPEED WARNING SYSTEM ( COWS) APPLICATION PART I:
DYNAMIC ROAD CURVE RECONSTRUCTION USING DIGITAL MAP ........................... 58
4.1.1 Introduction .......................................................................................................................... 59
4.1.2 Digital Map as a Virtual Sensor for Advanced Driver Assistance System .......................... 61
4.1.2.1 Overview of Digital Map and ADAS ................................................................................. 61
4.1.2.2 Architecture and Advantages of the ADAS and COWS Enhanced by VII ........................ 62
4.1.3 Dynamic Road/ Lane Curve Reconstruction Using Digital Map Data ................................. 63
4.1.3.1 Conventional Approach ─ Spline ..................................................................................... 64
4.1.3.2 New Approach ─ Data Pre- filtering and Parametric Curve Fitting ................................ 65
4.1.3.2.1 Data Pre- Filtering by Circle Center Search ( CCS) and Circle Selection ( CS)
Algorithms ............................................................................................................................... ..... 67
4.1.3.2.2 Parametric Curve- Fitting ............................................................................................... 68
4.1.4 Curve Overspeed Warning Experiment ............................................................................... 70
4.1.5 Conclusion and Future Work ............................................................................................... 72
4.2 TRAFFIC PROBE DATA PROCESSING FOR FULL- SCALE VII DEPLOYMENT ........ 74
4.2.1 Introduction ......................................................................................................................... 74
4.2.2 Background ......................................................................................................................... 75
4.2.3 Simulation Model................................................................................................................ 76
4.2.4. Baseline Probe Data Sampling Approach .......................................................................... 77
4.2.5 Probe Data Aggregation Issues ........................................................................................... 82
4.2.6. Probe Data Aggregation for Binary Data ( Windshield Wiper Status Example) ............... 85
4.2.7 Probe Data Aggregation for Location- Critical Event ( Dropped Load Example). .............. 85
4.2.8. Probe Data Aggregation for Traffic Speed Estimation ....................................................... 87
4.2.9 Key Findings and Future Direction ...................................................................................... 92
4.3 APPLICATION OF VII DATA ON REAL- TIME ARTERIAL PERFORMANCE
MEASUREMENTS ...................................................................................................................... 94
4.3.1 Introduction ......................................................................................................................... 94
4.3.2 Data Characteristics ............................................................................................................. 95
4.3.2.1 VII Probe Data .................................................................................................................. 95
4.3.2.2 Traffic Data ....................................................................................................................... 97
4.3.2 Models Formulation ............................................................................................................. 98
4.3.2.1 VII Probe Data ( VPD) Model ........................................................................................... 98
4.3.2.2 Model for Downstream Section ........................................................................................ 98
4.3.2.3 Model for Upstream Section ........................................................................................... 100
xi
xii
4.3.2.4 Point- Based Detection ( PBD) Model.............................................................................. 101
4.3.2.5 Fusion Model .................................................................................................................. 104
4.3.3 Model application .............................................................................................................. 105
4.3.3.1 Simulation- Based Testbed ............................................................................................... 105
4.3.3.2 Preparation of Fusion Model.......................................................................................... 106
4.3.3.2 Application Results ......................................................................................................... 106
4.3.4 Discussion .......................................................................................................................... 107
4.3.5 Conclusion and Future Direction ....................................................................................... 108
4.4 INTERSECTION SIGNAL CONTROLLERS AND VEHICLE- INFRASTRUCTURE
INTEGRATION: PUTTING SAFE INTERSECTIONS TO PRACTICE ................................ 110
4.4.2 Signal Phase and Timing Acquisition ................................................................................ 110
4.4.2.1 NTCIP ............................................................................................................................. 111
4.4.2.2 California AB3418 Protocol ........................................................................................... 111
4.4.2.3 Non- invasive Current Sniffer .......................................................................................... 111
4.4.3 Interface to Dedicated Short Range Communication ........................................................ 113
4.4.4 Communications Latency for Signal Phase and Timing Information ............................... 115
4.4.5 Communications Latency for Signal Phase and Timing Information ............................... 116
4.5 HIGH ACCURACY- NATIONWIDE DIFFERENTIAL GLOBAL POSITION SYSTEM
( HA- NDGPS) .............................................................................................................................. 118
4.5.1 Introduction ................................................................................................................. 118
4.5.2 Background ................................................................................................................. 119
4.5.2.1 Vehicle- Infrastructure Integration ( VII) Program ...................................................... 119
4.5.2.2 Global Positioning System .......................................................................................... 119
4.5.2.3 Differential GPS and Carrier- Phase GPS .................................................................. 121
4.5.2.3.1. Real- Time Differential Corrections ............................................................................ 122
4.5.2.3.2. Wide Area Augmentation System ( WAAS) ............................................................... 123
4.5.2.3.3 Real Time Kinematic ( RTK) and CORS ..................................................................... 124
4.5.2.3.4 United States Coast Guard National Differential GPS System ................................... 126
4.5.3 Differential GPS Evaluation ....................................................................................... 129
4.5.3.1 High- Accuracy Nationwide DGPS ( HA- NDGPS) ...................................................... 130
4.5.3.2 WAAS Accuracy .......................................................................................................... 134
4.5.3.3 Accuracy of RTK and Other Systems .......................................................................... 134
4.5.4 DGPS and VII CALIFORNIA Integration Architectures ........................................... 136
4.5.4.1 VII CALIFORNIA Architecture ................................................................................... 136
4.5.4.2 Potential Implementation Methodologies ................................................................... 139
4.5.4.2.1 HA- NDGPS Options .................................................................................................... 140
4.5.4.2.2 WAAS Integration Architecture with VII California .................................................. 141
4.5.4.2.3 Integrating the CORS Network with VII California .................................................... 142
4.5.5 Recommendations ....................................................................................................... 145
4.5.5.1 HA- NDGPS Recommended Architectures .................................................................. 145
4.5.5.2. WAAS Recommended Architecture ................................................................................ 147
4.5.5.3 Other DGPS Architectures ......................................................................................... 148
4.5.5.4 RSE Integrated Recommended Architecture ............................................................... 149
4.5.5.5 Implementation Cost and Implementation Summary .................................................. 150
4.5.6 SUMMARY ....................................................................................................................... 151
xiii
xiv
4.5.7. NEXT STEPS ................................................................................................................... 152
5. CONCLUSION ....................................................................................................................... 154
APPENDIX: THROUGHPUT PERFORMANCE MEASUREMENTS INVOLVING DSRC
WIRELESS COMMUNICATION CHANNELS ....................................................................... 156
A. 1 Introduction .......................................................................................................................... 156
A. 2 UDP Throughput Tests ........................................................................................................ 156
A. 3 Comparison of UDP Throughput ......................................................................................... 157
A. 4 Sample Iperf Commands ...................................................................................................... 158
A. 5 Probe client and server components ..................................................................................... 158
A. 6 Monitor component .............................................................................................................. 158
A. 7 OBU proxy component support for HTTP over DSRC ....................................................... 159
A. 8 Process controller ( procon) component ............................................................................... 159
A. 9 Signage injector component ................................................................................................. 159
A. 10 Denso telnet utility ............................................................................................................. 159
A. 11 Probe shell .......................................................................................................................... 160
A. 12 " Remote" mode for control of running components .......................................................... 160
A. 13 Dependency- graph based system administration ............................................................... 160
REFERENCES: .......................................................................................................................... 162
xv
xvi
LIST OF FIGURES AND TABLES
FIGURE 1.1 A Map of the VII California Network ( November, 2007) ........................................ 3
FIGURE 2.1 Roadside and Backhaul Communications Architecture. This allows data to move
from the vehicle, through the roadside infrastructure and to the VII California network. ..... 5
FIGURE 2.2 Schematic of VII California RSE Components ......................................................... 6
Figure 2.3 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. ........................................................................................................ 7
TABLE 2.1 Costs ($) associated with VII California RSE installation. ....................................... 12
TABLE 2.2 ............................................................................................................................... .... 15
Table 3.1 VII Monitor Report ....................................................................................................... 20
Figure 3.1 Example detail page, California at El Camino ............................................................ 21
Figure 3.2 Example full report ...................................................................................................... 22
Figure 3.3 Graph of Packet Loss................................................................................................... 23
Figure 3.4 Temperature Graph ...................................................................................................... 24
Figure 3.5 Graph of ssh responsiveness ........................................................................................ 24
Figure 3.6 Resource graph of an RSE ........................................................................................... 25
Figure 3.7 Graph of Memory Usage ............................................................................................. 26
Figure 3.8 Testbed map ................................................................................................................. 27
Figure 3.9 Architecture of Monitor System .................................................................................. 28
Figure 3.10 Assembly of three gumstix netduo expansion boards. .............................................. 31
Figure 3.11 Antenna placements with 8 active OBUs on one vehicle .......................................... 32
Figure 3.12 Baseline operation, 1480 byte data per packet, 10 millisecond interval between sends,
different pairwise runs of the four stations used for desk checking ..................................... 34
Figure 3.13 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) ............................................................................................ 35
Figure 3.14 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. .................................................... 36
Table 3.2 Parameters used for tests of frequent and in frequent channel switching. .................... 37
Figure 3.15 Baseline case: no channel switching, light load. ....................................................... 38
Figure 3.16 Infrequent channel switching, messages sent at 10 Hz. ( t1); each channel switch is
indicated by a vertical line, at that point the channel changes .............................................. 39
Figure 3.17 Close- ups, in case of infrequent channel switching ( t1). ........................................... 40
Figure 3.18 In this case, sw2, the send rate is half that of sw1, and round trip time remains low.
............................................................................................................................... ............... 41
Figure 3.19 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. .......... 42
Figure 3.20 Case sw4, with increased overall load and increased channel switching. ................. 43
Figure 3.21 Close up of switching and sequence number loss for case sw4. ............................... 44
Figure 3.22 Case sw5 has increased loading and likewise increased latency and packet loss
compared to case sw4. .......................................................................................................... 45
xvii
xviii
Figure 3.23 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. ............................... 46
Figure 3.24 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. ............................................................................................................................... ...... 47
Figure 3.25 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. ............................................................................................................................... .. 48
Figure 3.26 Location of RSU at 6th and Brannan in San Francisco. ............................................. 49
Figure 3.27 Plot of average of remote and local RSSI by GPS locationfor all received packets in
runs at 6th and Brannan. ........................................................................................................ 50
Figure 3.28 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.
............................................................................................................................... ............... 52
Figure 3.29 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 6th and Brannan. ..................................................................................... 53
Figure 3.30 Location of RSU at 3rd and Townsend in San Francisco, and direction of test runs. 54
Figure 3.31 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.......................................................................................................................... ........... 55
Figure 3.32 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 ............................................................................................................................... ...... 55
Figure 3.33 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.......................................................................................................................... ........... 56
Figure 3.34 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.......................................................................................................................... ........... 56
Figure 3.35 Illustration of regions of performance for successful transmission. .......................... 57
Figure 3.36 Illustration of regions of performance for transaction times. ................................... 57
Figure 4.1 Functional Components of a COWS system ............................................................... 60
Figure 4.2 Concept of ADAS Enhanced by VII ........................................................................... 62
Figure 4.3 ( a) Road curve fitted by splines ( b) Radius of curvature derived from splines ........... 64
Figure 4.4 Concept of Circle Center Search algorithm................................................................. 66
Figure 4.5 Proposed road curve reconstruction method ............................................................... 66
Figure 4.6 Exit ramp from northbound I- 580 to Bayview Ave. ( Google Map) ............................ 67
Figure 4.7 ( a) Preliminary Curvature Estimates by CCS Algorithm ( b) Preliminary Estimates of
Curvature Radii by CCS Algorithm ...................................................................................... 68
Figure 4.8 ( a) Optimized estimates of road curvatures through parametric curve- fitting ( b)
Optimized estimates of curvature radii ................................................................................. 69
Figure 4.9 On ramp from Marsh Rd. to southbound US 101 ( Google map) ................................ 69
Figure 4.10 ( a) Preliminary curvature estimates by CCS algorithm ( b) Preliminary estimates of
curvature radii by CCS algorithm ......................................................................................... 70
xix
xx
Figure 4.11 ( a) Optimized road curvature estimates through curve- fitting ( b) Optimized curvature
radius estimates ..................................................................................................................... 70
Figure 4.12 Example of COWS Field Test at the RFS Test Track ............................................... 71
Figure 4.13 Vehicle speed and GPS condition when approaching the curve ( when the GPS is in
outage, the resultant HDOP is set to zero by the GPS receiver) ........................................... 72
FIGURE 4.15 Case Study Network for Probe Vehicle Simulations. ........................................... 76
FIGURE 4.16 Snapshot Sampling at a Busy Intersection. ........................................................... 78
FIGURE 4.17 Examples of Delays between Probe Snapshot Sampling and Message Uploading
to RSE. ............................................................................................................................... .. 79
FIGURE 4.18 Cumulative Distribution of Snapshot Latencies for Events Just Within and Just
Without the RSE Range ........................................................................................................ 81
FIGURE 4.19 Snapshot Latencies for Alternative Broadcast Protocols. ..................................... 82
Table 4.1 Probe Data Aggregation Approaches, Based on Data Types and Applications ........... 83
FIGURE 4.20 Probe Sampling of Wiper Status to Detect Rain at Five RSE Locations. ............. 86
FIGURE 4.21 Average Speeds Derived from Five Minutes of Probe Snapshots. ....................... 88
FIGURE 4.22 Effects of Probe Snapshot Sampling on Speed Estimates at 50- 100 m from
Intersection. ........................................................................................................................... 89
FIGURE 4.23 Aggregation of complete vehicle trajectories at 20% market penetration ............ 90
FIGURE 4.24 Aggregation of probe snapshots at 20% market penetration ................................. 90
FIGURE 4.25 Raw simulation speed profile averaged over 2 s and 10 s intervals and 20% market
penetration averaged over 10 s ............................................................................................. 91
FIGURE 4.26 Simulation snapshot data averaged over 2 s and 10 s intervals and 20% market
penetration averaged over 10 s. ............................................................................................ 92
FIGURE 4.27 VII Probe Data Collection Process ........................................................................ 96
FIGURE 4.28 Typical snapshots distribution near around downstream section .......................... 99
FIGURE 4.29 Performance of the Cruise Speed Estimation Model .......................................... 102
FIGURE 4.30 Delay Calculation Model with Typical Semi- actuated Control Layout .............. 104
FIGURE 4.31 The Structure for the Neural Network Fusion Model ......................................... 105
FIGURE 4.32 Simulation network and RSEs deployment ......................................................... 106
FIGURE 4.33 Model Performance Comparisons for a NB Link ................................................ 106
TABLE 4.2 Model Performance Comparison ............................................................................ 107
FIGURE 4.34 Installation and operation of “ clamp- on” signal current sniffer at VII California
intersection. ......................................................................................................................... 112
FIGURE 4.36 Modular design of signal phase acquisition and broadcast system ..................... 113
FIGURE 4.37 Types of information that must be specified to configure signal phase and timing
broadcast. ............................................................................................................................ 114
FIGURE 4.38 Difference in transition time between AB3418 and sniffer acquisition, run
simultaneously .................................................................................................................... 116
Table 4.3 Summary of GPS Error Sources. [ Trimble, 2006]. ..................................................... 122
Table 4.4 Summary of GPS signal correction methods. [ Magellan, 2006]. ............................... 123
Figure 4.39 Recently installed WAAS Ground Uplink Facility in Napa California [ SatNav, 2005].
............................................................................................................................... ............. 124
Figure 4.40 USCG NDGPS broadcast site [ FHWA, 2005]. ....................................................... 126
Table 4.5 Status of California NDGPS broadcast stations [ USCG NAVCEN, 2006]. .............. 127
Figure 4.41 Planned and Operating NDGPS sites [ Wolfe et al., 2003]. ..................................... 128
xxi
xxii
Figure 4.42 Projected NDGPS coverage [ Wolfe et al., 2003]. ................................................... 128
Figure 4.43 HA- NDGPS broadcast station hardware architecture [ USCG NAVCEN, 2001]. .. 131
Figure 4.44 Hagerstown, HA- NDGPS broadcast station rack and receiver antennas
[ FHWA, 2002]. .................................................................................................................... 131
Figure 4.45. HA- NDGPS evaluation of compaction of RTCM 18/ 19 message types
[ FHWA, 2005]. .................................................................................................................... 132
Figure 4.46 HA- NDGPS real time rover data compared with post processed carrier phase
[ FHWA, 2002]. ................................................................................................................... 133
Figure 4.47 Independent accuracy test of WAAS capable receiver [ Wilson, 2006]. ................. 134
Figure 4.48 HA- NDGPS rover results [ FHWA, 2005]. .............................................................. 136
Figure 4.49 Positioning error for uncorrected ( green) and corrected ( black) local differential GPS
system [ Du et al., 2006]. ..................................................................................................... 136
Figure 4.50 VII California Field Operational Test Location [ VII CALIFORNIA, 2006a]. ....... 138
Figure 4.51 RSE cabinet and wireless communications antenna installation [ VII CALIFORNIA,
2006b, c]. ............................................................................................................................ 139
Figure 4.52 VII CALIFORNIA proposed RSE architecture [ VII CALIFORNIA, 2006a]. ....... 139
Figure 4.53 WAAS base stations showing Fremont as the closest to the Northern VII California
Field Operational Test [ SatNav, 2003]. .............................................................................. 142
Figure 4.54. California CORS stations with RCTM 2.3 carrier phase corrections [ CSRC, 2006].
............................................................................................................................... ............. 143
Figure 4.55 Real time carrier phase DGPS base station utilized for RTK applications
[ CSRC, 2006]. ...................................................................................................................... 144
Figure. 4.56 Proposed WAAS architecture for potential VII CALIFORNIA implementation. . 147
Figure 4.57 Proposed RTK architecture for potential VII CALIFORNIA implementation. ...... 148
Figure 4.58 Proposed RSE integrated DGPS architecture for potential VII CALIFORNIA
implementation. .................................................................................................................. 149
xxiii
xxiv
VII California: Development and Deployment
Lessons Learned
1. INTRODUCTION
______________________________________________________________________________
This PATH Research Report covers the ( Vehicle- Infrastructure Integration) VII California
Development and Deployment ( Task Orders 5217 and 6217) efforts from October 2005 –
December 2007. It is not a final report ( although it is expected that elements from this research
report will be repeated in the final report); rather, it is an organization and report of collective
and very applications- oriented research to date.
It is organized to impart the very specific and generally very pragmatic implementation details
first, beginning with an introduction ( Section 1), description of VII hardware, general network
and installation ( Section 2), then progressing to a more detailed description of the network and
operating software ( Section 3) and finally to applications in development and prospective
applications ( Section 4). Because it is not yet a final report but rather a ‘ research in progress’
report, it does not comprehensively address every task in the VII California family of task
orders; specifically, several of the applications described in Section 4 are represented as works
in progress ( as they are at this writing), and the on- ramp metering study is not yet reported.
Again, the purpose, of this report is to provide the reader with an understanding of how VII
California was implemented.
______________________________________________________________________________
Let us begin with the question, “ Why VII California was implemented?” It is important to begin
with an understanding of a significant impetus: the national VII “ movement”. The VII system in
the United States would be enabled by roadside wireless hotspots generated by Dedicated Short
Range Communication ( DSRC) transceivers operating within 75 MHz of free, FCC- licensed
bandwidth near 5.9 GHz [ 1]. These transceivers are incorporated in Roadside Equipment ( RSE),
which are connected by edge backhaul communications into a network architecture that
addresses security, privacy and other design considerations ( FHWA, 2005). Applications,
standards and architecture are under active development. The goal of these efforts is a roadside-based
network delivering low- latency, highly reliable data communications to support safety and
mobility services to users. The coverage would be extensive: the proposed VII system has the
potential to cover all urban roads within 2- minute travel times, 70% of all signalized
intersections in 454 urban areas and up to 15 new million vehicles per year would be DSRC- and
therefore VII- equipped ( Cops, 2006).
The VII initiative is intended to lead to nationwide deployment of cooperating vehicle and
infrastructure devices, producing an integrated transportation data network of unprecedented
scope and complexity. The fully deployed system would include onboard equipment ( OBE)
installed on new vehicle manufactured after a specified date and roadside equipment ( RSE)
installed at all signalized intersections in major urban areas, at primary intersections in other
areas, at all highway interchanges and along major intercity and many rural highways
( representing about 240,000 RSE locations nationwide). This network would make it possible to
1
VII California: Development and Deployment
Lessons Learned
collect transportation operations data of great breadth and depth, to implement sophisticated
traffic safety systems, and to manage traffic flows with previously unthinkable precision.
To assess the feasibility and desirability of VII, many technical, economic and institutional
questions need to be answered. Considering the magnitude of the commitments that will be
needed by a wide range of public and private sector organizations in order for VII to be deployed,
these questions must be answered very convincingly before deployment can proceed. The
process of developing the answers is just beginning, and is likely to require considerable time
and effort.
Lessons for deployment might be learned from regional efforts, notably in Florida, Michigan and
California ( Florida DOT, 2004, Michigan DOT, 2007, Misener and Shladover, 2006) and most
certainly in the forthcoming US DOT VII Proof of Concept experiments ( Henry, 2007).
Certainly, California is at the nexus of VII need and innovation. The same reasons to create a
national VII program are acutely recognized in California: an obligation to better manage the
safety and productivity of our highway system, and the understanding that a fusion of public,
automotive and other private sector innovations can make this a reality.
However, California and regional stakeholders have specific transportation infrastructure,
operating policies and needs than what may be universally addressed with a national VII
program. These needs have led to a partnership between Caltrans and the San Francisco Bay
Area Metropolitan Transportation Commission. Caltrans and MTC are addressing these needs
with a multiyear effort to develop, demonstrate and deploy VII in a key corridor in Northern
California. This corridor is comprised of roughly ten- mile segments of two routes North of Palo
Alto and South of the San Francisco Airport. It encompasses two highways: State Route 82 and
US 101. We note that this selection addresses both a high- volume freeway ( US 101) and a major
arterial complete with signalized intersections ( SR 82), shown in Figure 1.1:
2
VII California: Development and Deployment
Lessons Learned
FIGURE 1.1 A Map of the VII California Network ( November, 2007)
Overall, Caltrans and MTC aim to:
• Evaluate exemplar public use cases from which we can generalize VII feasibility;
• Evaluate institutional, policy and public benefit issues;
3
VII California: Development and Deployment
Lessons Learned
• Explore wireless communication deployment issues and options;
• Resolve key technical issues involving implementation and operation;
• Assess implementations of the VII infrastructure, architecture and operations; and
• Support private sector evaluation interests.
In support of VII California, PATH has conducted this project, VII California Development and
Demonstration Deployment ( VIIC D3 or simply D3) where the testbed was built and operated and
where deployment and applications issues are investigated. Why? Because some of the technical
questions can be addressed through analysis and simulation studies, while others need field
testing under realistic conditions. Some of the most challenging questions, which will require
the largest investments of time and effort, involve the scalability of system performance in
advancing from small numbers of OBEs and RSEs to large numbers of OBEs for each RSE and
then to large numbers of RSEs as well. Other questions involve the practical aspects of
implementing RSEs in the real world of roadway operations, which can only be answered by
starting to install and operate those RSEs and learning about the physical and institutional
constraints, the failure modes and the maintenance needs that are encountered there. These have
important ramifications for the design of the VII technology and for the long- term costs of
deploying, operating and maintaining it in the field.
This report describes the lessons learned in the all phases of the PATH effort.
4
VII California: Development and Deployment
Lessons Learned
2. VII CALIFORNIA TESTBED DESIGN
2.1 ELEMENTAL BUILDING BLOCK WITHIN NETWORK: ROADSIDE
EQUIPMENT
The hardware experience accrued in developing the VII California testbed focuses on the RSE
and its connection to the existing Caltrans roadside appurtenances and their function. The RSE
is the basic infrastructure building block for VII. Each RSE serves as an in- the- field gateway
between locally transmitted vehicle data and the roadside communications infrastructure. At top
level, an RSE is a computer with a radio transceiver and an antenna. The computer must have
sufficient processing and storage capability to run a gateway application between its two network
interfaces, DSRC and back- haul ( to the Traffic Management Center and other servers), and to
run additional local safety processor software, with data filtering, buffering, aggregation, and
formatting, as needed, and illustrated in Figure 2.1.
Vehicle Bus
Interface
Data Acquisition and
Aggregation
GPS
Interface
DSRC Comm
Interface
Comm
Management
Data Recording Application
DSRC Comm
Interface
Data Filtering
and Aggregation
Interface to
TMC
Data Formatting
Gateway Application
Interface to field unit
Applications
Vehicle Data Recorder
DSRC- TMC Gateway
Caltrans TMC
Roadside
Infrastructure
Vehicle
Data
Storage
FIGURE 2.1 Roadside and Backhaul Communications Architecture. This allows data to move
from the vehicle, through the roadside infrastructure and to the VII California network.
The RSE is therefore between the vehicle and the roadside backhaul network ( which might
already exist), providing the necessary interface. Physically, it could sit in Type 332 cabinet, and
it would consist of a wireless transceiver ( with antenna) atop the cabinet and a computer within
the cabinet, with connections.
The initial VII California computer was designed to explore a variety of applications and
therefore consists of a PC- 104 stack with processor and a PCMCIA card with connection to the
5
VII California: Development and Deployment
Lessons Learned
Wireless Access to Vehicular Environments ( WAVE) DSRC radio and antenna. To fit within
the Type 332 cabinet, form factor is low: approximately 6” x 6” x 12”. Power is standard 120V
AC, with low current draw. A schematic of the VII California connected RSE, residing within a
National Electric Manufacturer’s Association ( NEMA) environmentally rated traffic controller
cabinet, is shown in Figure 2.2.
FIGURE 2.2 Schematic of VII California RSE Components
The hardware is split into two main clusters. One resides in the roadside cabinet and the second
in a separate weatherproof enclosure. This design minimizes the length of the 5.9 GHz antenna
cable to maximize signal strength. Some installations require a separation of up to 200 feet
between the existing roadside cabinet and the location where the 5.9 GHz antenna needs to be in
order to provide coverage of the approaching roadways. Figures 2.3 illustrate a typical RSE
installation.
6
VII California: Development and Deployment
Lessons Learned
DSRC Antenna
GPRS Antenna
( wireless
GPS Antenna backhaul )
NEMA
Enclosure
PC 104
computer
Figure 2.3 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.
2.2 NETWORK: TRANSPORT LAYER
A major goal of the VII California testbed is to support an initial set of applications, including
probe vehicles, public information providers, and bidirectional non- public services ( such as
navigation and tolling). The testbed has been used as a development laboratory, with
experiments and small- scale demonstrations of these applications conducted with public and
vehicle manufacturer partners, starting with the 2005 ITS World Congress and continuing
through the TRB ITS, Vehicle- Highway Automation and Traffic Signal Systems committee
meetings and to the VII Coalition and RITA Administrator demonstrations in 2007. Heavy use
of this testbed has exposed a number of issues for future VII implementations and has motivated
development of a message transport layer built on top of IP networking, a set of VII application
servers, in- vehicle libraries, and administration tools. The characteristics of this software are
best examined against the background of the constraints on the project:
1. The compressed development schedule has required the use of prototype- quality
hardware. The Denso DSRC Wireless Access for Vehicular Environment ( WAVE)
( 1) Radio Modules used initially in the RSE is particularly limited: they cannot
transmit packets to more than four hosts on their wired side and they cannot assign
dynamic IP addresses to vehicles. Firmware for several components ( including
DSRC radios and cellular modems) evolved to new generations during the project.
2. The backhaul network is heterogeneous, ranging from cellular modem to dedicated
T1 landline. Hence, not all sites can support all services. Furthermore, this diversity
7
VII California: Development and Deployment
Lessons Learned
3. The inherent unreliability of mobile wireless networks requires a degree of
robustness. Packet loss is likely in an environment with nodes traveling at high
speeds with limited range, line- of- sight occlusions, and RF interference. No
application can expect to have long- lasting, consistently available connections.
4. Application messages can be long. Probe messages can be up to 64 KB with multiple
snapshots.
5. The transport layer should present VII California application code with an interface
for communication between vehicles and servers that is message oriented ( like UDP,
User Datagram Protocol) but has inherent quality of service controls ( to some extent
like TCP, Transmission Control Protocol). It must be somewhat reliable, but not at
the cost of excessive use of the channel.
6. Information from the vehicle must be kept as private as possible.
Within these constraints, the VII California transport layer succeeds in several ways:
1. The first packet from the vehicle to the server is a data packet; there is no delay for
dynamic IP address assignment ( DHCP) association, internet transmission control
protocol ( TCP) session initialization, or other handshaking. The reduction in delay
increases the chance that a return message ( if any) will be received before the
vehicle goes out of range.
2. Message reception probability is robust in the face of short- term failures. The
transport layer can detect the loss of a fraction of the packets in a message and
retransmit the missing fragments. If packet loss is not extensive, this will quickly
and efficiently complete the message transmission. Unlike TCP, if no fragments
arrive, no bandwidth is wasted resending them, and no bandwidth is wasted on
acknowledgment packets.
3. The suite includes a proxy which runs on the vehicle side to insulate vehicle code
from the complexity of the wireless user datagram protocol ( UDP protocol) and
provide it with a TCP socket interface for sending and receiving messages.
4. On the server side, similarly, the interface to the transport layer is a TCP socket, with
multiple vehicle sessions multiplexed in one TCP session using transaction IDs.
5. Message addressing is encapsulated across the wireless link to overcome the Denso
limitations.
6. No identifying information from the vehicle ( outside of the application payload)
propagates farther than the roadside or is stored anywhere.
Certain aspects of a complete VII architecture are not fully addressed by this prototype software,
including security, scalability, and conformance to emerging national VII standards ( IEEE, 2007;
SAE, 2006; Kurihara, 2003).
8
VII California: Development and Deployment
Lessons Learned
2.3 TESTBED – INSTALLATION, OPERATIONS, AND MAINTENANCE
ISSUES
2.3.1 RSE Installation
2.3.1.1 Institutional Issues
Like any other new addition to existing systems, the inclusion and acceptance of RSEs as a
standard traffic engineering device presents a series of challenges. The main challenge is to get
the local agencies to buy into its usefulness for their constituencies. In the case of highways, the
potential sites are normally the property of state DOTs and this single ownership makes it easier
for approval purposes. In case of intersections, the owner may be the city, county, or State DOT,
making the approval process more involved.
The original design of the RSE and any changes thereafter need to be approved by the
infrastructure owner prior to any installation. This includes the approval from the owner
agency’s electrical, structural, and maintenance groups. The design should conform to
specifications used by owner agency.
For the electrical group, the power requirements, type of components, and weather and
temperature resistance are important issues. For the structural group, the size and weight of the
components as well as the manner by which they are attached to the signal poles and mast arms
are important. For Maintenance, the ease of installation and follow- up maintenance are most
important.
In our case, all of our installations are on Caltrans rights of way and attached to Caltrans
infrastructure. Our design and installations have complied with Caltrans Standard Specification
( California DOT, 2006) and Caltrans Standard Plans ( California DOT, 2006). Also, since
Caltrans maintenance crews have done the installations, everything has conformed to Caltrans
safety and standard practices.
Our original design and follow- up changes to it have been rigorously evaluated by Caltrans
electrical and structural engineers. There is no specific limit to the size and weight of the
equipment that is attached to signal poles and other infrastructure parts, but the structural
engineers review each proposed equipment installation based on the weight and size of the
equipment and its exact attachment spot.
2.3.2.2 Installation Process – Hardware Issues
The installation process consisted of surveying potential sites, pre- installation infrastructure
work if needed, physical installation, and on- the- spot testing and troubleshooting upon
completion of the installation.
2.3.2.2.1 Surveying potential sites
Multiple survey trips were taken by engineers and researchers and the infrastructure owner
( Caltrans) to identify potential sites for RSE installations from among every intersection and
controller cabinet along the freeways and arterials of our corridor. This surveying effort included
9
VII California: Development and Deployment
Lessons Learned
examining:
Line of sight issues and potential placements for DSRC antennae: DSRC radio antennas are
specified to have a range of up to one mile in every direction. It is necessary for them to have a
clear line of sight with the OBEs in the vicinity of the RSE. They also must be placed a
minimum of 14 ft above the road surface in order to clear the top of large trucks and transit buses.
For installations along the freeways, the selected site might already have an ideal location for the
DSRC antenna. For example, it might be placed atop the freeway ramp meter signal poles or
mast arms, the nearby over- crossing structure, or another infrastructure feature that is at least 14
ft above the road surface and can be used for this purpose. If not, a pole that is at least 14 ft high
can be mounted next to the freeway controller cabinet, and the DSRC antenna can be attached
atop it.
For intersection installations, it is imperative that the DSRC antenna be placed at a position
where it has a clear line of sight to all intersection approaches relevant to the intended
intersection safety applications ( Cohen, et al, 2007). In many intersections, this antenna can be
affixed to the mast arms or atop signal poles. The DSRC antenna cable must not be too long, or
the signal strength losses will not be acceptable, and may obviate the nominal ( 6 or 9 dB) gain of
the antenna. In our VII California design and for the type of cable we have selected, the
maximum DSRC antenna cable length is 20 ft. The low loss cables we typically use have
attenuation ( loss) numbers that are in range of 10.8 to 26.4 dB per 100 foot length at 5.8 GHz.
Placement of RSE: The exact placement of each component of the RSE needs to be planned,
including the selection of wire routes to components. One major factor to be considered is how
much space is available inside the conduits for RSE wires. Many existing conduits are already
full of cables and cannot be used, and some may also be full of water and mud.
Communication cables are prohibited from running inside the power conduits due to safety
concerns and in accordance with safety codes. The National Electrical Code ( National Electrical
Code, 2002) prohibits installing power and broadband conductors in the same conduit. A few
locations have dedicated communication conduits that can be utilized for communication cables.
The enclosures that are exposed to the environment and are attached to the poles need to be
NEMA specified, and should be as small and light weight as possible to minimize concerns of
the structural engineers about their weight and seismic, wind and snow loads.
Space availability in controller cabinet: Controller cabinets provide a safe, weatherproof place
for RSE components as well as power. Space availability within the cabinet - or within the
Uninterrupted Power Supply ( UPS) cabinets that are attached to the fully- packed controller
cabinets to provide extra space- needs to be determined prior to installation of the RSE. In
freeway installations, there is usually enough space in the controller cabinet. In intersection
installations, cabinet space availability is a more serious concern. The simple solution to address
this issue is to add an UPS cabinet to the controller cabinet.
Investigation of backhaul: For backhaul, availability of an existing telephone line in the cabinet
as well as the proximity of " phone demarcation boxes" to the RSE site should be determined
10
VII California: Development and Deployment
Lessons Learned
prior to the installation. In some locations, such as cabinets for Field Master controllers along
major city streets or arterials and closed circuit TV installations along the freeways, phone lines
are already connected to the controller in the cabinet. If the telephone landline option is
available, then a T1 line provides more upload and download capacity than a dial- up line. If the
landline does not exist or is too far away from the cabinets, then wireless options should be
investigated. Even though the VII California testbed is located in a heavily urbanized area in one
of the most technologically sophisticated regions in the country, only about 10% of the potential
RSE locations that were investigated were already equipped with landline connections.
Use of bucket trucks: In many instances with the VII California RSE design, shown in Figure 2.3,
the installation requires one or two bucket trucks, which adds to the cost and potential traffic
disruption of the installation. Prior to the installation of any RSE, the use and manner by which
these trucks will be used need to be carefully planned. For freeway installations, if a lane closure
of the ramp or the mainline is needed, then this closure should be approved by the agency in
charge. For intersection installations, the date and time of installation should be chosen to have a
minimum effect on the local traffic. In any event, these issues highlight the kind of cost,
resource allocation, traffic disruption and agency approval attention that will be involved in a
large- scale RSE deployment.
2.3.2.2.2 Pre- installation infrastructure work
In some cases, it is necessary to perform pre- installation infrastructure work on the chosen site.
This work could include a variety of improvements to the existing infrastructure to get it
prepared for the actual installation, such as the erection of a pole, installation of pull boxes and
conduits, or running cables through the existing conduits to make sure there is enough space
within them.
2.3.2.2.3 On- the- spot testing and troubleshooting on the day of installation
At the conclusion of the physical installation, a complete test needs to be performed to make sure
the system is up and running. This is usually done via a laptop computer that simulates an OBE
by sending and receiving data from the RSE. If the system is not working, then the trouble
shooting should begin immediately, while the installation crew and their tools, equipment, and
vehicles are available to solve the problem.
2.3.3 Installation Cost
Table 2.1 provides actual costs for a typical installation of RSE using current- generation
equipment along Caltrans right of way. The use of MCNU RSUs ( the latest generation of DSRC
radios) has been approved for installations that will be used during the Proof of Concept ( POC)
phase of the National VII program, but the purchase cost of the MCNU is not included in Table 1.
The costs in Table 1are associated with installations where the controller is the legacy and
widely- used 170 model.
11
VII California: Development and Deployment
Lessons Learned
TABLE 2.1 Costs ($) associated with VII California RSE installation.
Item Parts
($)
Labor ( man-hours)
Labor cost ($)
DSRC/ WAVE Antenna 100
DSRC/ WAVE Antenna Mounts 50 12 600
DSRC/ WAVE cable (~ 20 ft) 60
Base Plate for MCNU and NEMA Box 200 28 1,680
GPS ( unit plus antenna) 500
GPS Mounts 75 12 600
Fiber Cable ( up to 200 ft) 200
Fiber Converter ( 4 per site if backhaul is
wireless)
250
Fiber Connectors ( 8 per site if backhaul is
wireless)
120
Power Supply and Its Base and Circuit
Breaker Switch
130
Uninterrupted Power supply 150
Signal sensing circuit or sniffer
including processing and data transfer
modules
2000 80 4,000
Software configuration and testing to match
phase timing of each site
80 4,000
Site Survey 2 - 4 160 - 320
Installation ( maintenance at $ 30/ hr) 25 – 50 750 – 1,500
Installation ( engineering at $ 50/ hr) 12 – 20 600 - 1,000
TOTAL 3865 251 – 268 12,390 – 13,700
This shows a parts cost of ~$ 4,000 per RSE installation, exclusive of the cost of the DSRC radio
itself, plus an additional ~$ 12,500 to ~$ 14,000 in labor costs for these early installations. Each
installation takes about a week of preparations and one full day to physically install and test an
RSE by a crew of three to four maintenance workers and two engineering staff. In the long term,
when RSE installations are done in large volume, the parts costs are unlikely to decline
significantly since these are already relatively common parts rather than custom- built equipment
( except, of course, for the DSRC radio). The labor costs could be expected to decline
significantly, except for the unavoidable installation and testing labor.
2.3.4 Maintenance Issues
2.3.4.1 Hardware Maintenance
After more than a year and half since the installation of the first RSE, the research team has
gained valuable insights about maintaining RSEs in the real world. Lessens learned are
described below.
Reliable and current information is essential to maintenance. To assist in rapidly acquiring and
12
VII California: Development and Deployment
Lessons Learned
assimilating information about our testbed, we developed a set of software components that run
constantly on the RSE hosts and on a designated server. The RSE host components measure the
status of the RSE and send reports to the server. The reports are processed into web pages, maps,
and time- history graphs, which can help diagnose ( and even predict) failures. The information
includes:
• Temperature, fan speed, and voltage in the RSE hosts.
• Backhaul and DSRC network data rates -- actual traffic and maximum capacity.
• Packet loss on network segments.
• Host computer status, such as CPU and disk usage.
• Status of devices connected to the host computer.
• VII application status and performance ( number of messages, message queue lengths).
• Configuration settings of various components.
The specific maintenance issues that we have encountered so far include:
• Thermal issues related to the fiber converters have been a source of some
breakdowns of RSEs. As shown on Figure 2.2, fiber cables are used to communicate
between the PC- 104 which is placed inside the controller cabinet and DSRC radio in
a separate NEMA box. The fiber converters are needed at both ends of the fiber
cable. A clear correlation between high ambient temperature and the breakdown of
these converters has not been established, but their higher rate of breakdowns in the
hotter months of the year points to this conclusion. In recent months, most of the
original fiber converters were replaced with another brand that is more heat resistant,
but unfortunately the performance of these converters has not been completely
satisfactory either. A third brand of fiber converters with higher heat resistance
capacity is under evaluation by the research team for future installations, but the
higher heat tolerance incurs higher cost as well. The temperature requirements of
Caltrans (- 40 to + 70 C) exceed the specifications of most commercially available
electronics, including the fiber converters.
• The most unusual and least preventable failures were caused by animals and nature.
Rodents can damage underground cables including the very sensitive fiber cables in
the pull boxes. To prevent these animals from doing their damage, the bottom of
pull boxes needs to be covered by concrete. This can easily be done for new pull
boxes but not for the existing ones. Also, if water and mud get into the conduits,
they can damage the underground cables.
• Another source of failure is the interference and unfamiliarity of the local
maintenance crew who may unintentionally cause damage. For example, they can
damage the very delicate fiber by stretching it while working on another cable
underground or while working on RSE equipment in the controller cabinet.
13
VII California: Development and Deployment
Lessons Learned
• One type of cellular modem failed due to firmware that had not been updated. It is
important to be aware of updates from manufacturers and the problems that they
solve.
Clearly, the long term cost of maintenance is difficult to determine at this point, while the
technology is still maturing.
2.3.4.2 Institutional Considerations
The cooperation of the owner agency; in our case Caltrans District 4 Maintenance, is essential to
get any down RSE back up and running in a reasonable time. The access to the right of way,
controller cabinet and infrastructure is only possible if the owner agency’s representatives are
present. Thus no repairs or regular maintenance can take place without their direct support.
2.3.4.3 Network Operations and Maintenance
The network designed for the initial stages of the project has continued to work well, within the
constraints initially identified. Some additional constraints arose later:
1. Some cellular network providers timed out an inactive TCP session after a short
period, and data transmitted after this time is simply lost with no error reported. To
fix this in Linux, we send a heartbeat packet every 45 seconds.
2. Firewall issues can appear to be network connectivity problems. The issues need to
be revisited when new hosts are added or networking equipment is swapped.
3. Updating many ( even 12) RSU hosts with new software versions can be time
consuming, so we automated this process.
2.4 IMPLICATIONS FOR THE FUTURE
2.4.1 Hardware
From what we have learned thus far, the design of the RSE must be compliant with all national
and local standard specifications and requirements. The design must be practical and the overall
system must be very reliable. The design should compensate for infrastructure limitations. It
should take into account the ease of installation and later on the ease of access to components for
repairs and routine maintenance. Another factor is to design for simplicity so that maintenance
crews can repair and maintain it with less time and effort. If the repair or regular maintenance
requires lane closures, it is best that this task be completed in a minimum period of time and with
minimal danger for the crew. The main objective is to put the maintenance crew in hanging
buckets as infrequently as possible.
If the system is reliable; there is less need to repair the RSE. If the owner/ operator of the RSEs
finds it troublesome to keep up with its repair and maintenance, and if the data obtained from the
RSEs are not reliable and data flow is not continuous, then RSEs become a burden and lose their
utility.
14
VII California: Development and Deployment
Lessons Learned
It is best that the system be designed in such a way that repairs and regular updates for software
in particular can be done remotely. A local wireless connection between a laptop computer and
the RSE site can also be used to make rapid on- site software updates, provided that security can
be maintained.
2.4.2 Backhaul Options
Since the installation of our first RSE, we have tried a variety of backhaul options, some using
landlines like T1 and some using wireless. The availability and dependability of each backhaul
option is a local issue. The fixed and monthly cost of service is a function of the bandwidth and
the competition among the service providers. Another local issue is the pre and post installation
level of service that one might get from the service provider. Table 2 shows telecommunication
transmission costs and bandwidth for the backhaul alternatives considered by VII California. It
is intended to serve as a snapshot of currently available backhaul alternatives.
TABLE 2.2
2.4.3 Institutional Issues
The RSE owner could be either State DOT, county, or city. These diverse infrastructure owners,
each possibly with different specifications and standards, can present a challenge for future
installations. Interestingly, some intersections belong to the State DOT but are maintained by
county or city. For these locations, both agencies need to accept the design, installation method,
and maintenance of the RSE. A robust design that can satisfy the specifications and meet the
standards of these diverse owners can be the answer.
2.4.4 Summary of Key Lessons Learned
The experience of implementing the first RSEs in the Bay Area has provided some important
lessons that should be kept in mind when planning for the national VII deployment and
estimating its costs:
15
VII California: Development and Deployment
Lessons Learned
• Even though we were working in the high- density and technology- intensive Silicon
Valley region of California, the large majority ( almost 90%) of the candidate locations
( major intersections and freeway interchanges) for VII testbed RSE installation were not
already equipped with landline backhaul connectivity. This meant that backhaul
connectivity had to be installed as part of the process of installing the RSE, incurring
significant up- front costs. Nationwide VII implementation is therefore likely to require
significant investments in backhaul communications.
• The selection of backhaul technology for the RSE installations had to be made on a site-by-
site basis, depending heavily on local conditions ( availability of technologies close to
the host controller cabinet). This means that full- scale VII deployment is likely to have
to depend on a heterogeneous mixture of backhaul technologies rather than only one or
two preferred technologies.
• The cost and performance of backhaul communications ( see Table 2) have been more
challenging than anticipated at the onset of VII California. This implies that the VII
architecture design should seriously consider how best to minimize the backhaul burden
from the RSEs in order to contain backhaul capital and operating costs and minimize the
losses of data associated with interruptions of the backhaul communication link. These
considerations point toward distribution of intelligence throughout the VII network,
including some data processing and storage resources at each RSE.
• Over time, multiple versions of RSEs may enter the market. It is imperative that they all
work together transparently for the equipped vehicles. This will encourage not only the
vehicle manufacturers and after market suppliers but also the agency owners to be more
willing to invest in VII.
2.5 FUTURE DEVELOPMENTS
The VII California testbed is expanding, with a network of DSRC roadside units ( 12 at this
writing and plans for up to 40), applications with on- board equipment ( on light duty and transit
vehicles), and a backhaul network ( with heterogeneous backhaul links including T1 landline, 3G
modem and soon coming online, WiMAX). Strategic outreach efforts are underway to bring
onboard a variety of public and private entities that can benefit from and provide benefits to this
project. Development and operation of this testbed has provided a wealth of technical and
institutional knowledge in several domains: hardware and software on one hand; and installation,
maintenance and operations on the other. Issues raised and overcome include:
• agency cooperation by different divisions that were not involved with the initial decision
to conceive this project,
• installation, maintenance and operation under practical operational constraints ( standards
of practice and codes,
• use of legacy systems on the roadside and
• to transport data via heterogeneous means to ‘ back office’ operations).
16
VII California: Development and Deployment
Lessons Learned
Significant network and architecture issues remain. The VII California implementation is
admittedly experimental and designed to expedite applications development and experiments,
but the questions asked and solutions implemented with regard to architecture and ‘ distribution
of intelligence’ to the roadside are important to consider as part of the larger VII picture.
These lessons learned will be brought to more mature practice as the VII California testbed
transitions from an experiment of VII applied to State and regional needs toward informing
Federal- level decisions. This transition is institutional, as VII California may become a
development test environment to support the US DOT VII Proof of Concept experiments and to
develop important applications, e. g., bridge tolling. Through this transition, testbed plans will
transform into evolving design standards, and the cross- fertilization between what has been
practical and already implemented versus what is conceived by the US DOT VII program will be
an interesting convergence. Throughout this experience, the lessons learned by the VII
California program should be carefully considered in VII and in any widespread deployment of
networked technology in transportation.
17
VII California: Development and Deployment
Lessons Learned
3. PROTOCOLS AND PERFORMANCE
3.1 RSE MONITOR
3.1.1 Introduction
The RSE monitor software automates the tasks of monitoring the hardware and software
installed on the roadside. The primary function of the monitor is to detect events and to record
the status of hardware and software components and to periodically send reports to a central
server. Reports are aggregated on the server and processed into useful forms, such as web pages,
maps, and time- history graphs. The secondary function is to repair error conditions when it is
possible to do so without operator intervention.
The intended users and use cases of the system are:
1. Administrators: detect, diagnose, and predict failures.
2. Testbed users: before driving out on a test run, determine which parts of the testbed are
likely to be able to support the testing they have planned.
3.1.2 Variables
The monitor system collects and reports the following time- varying data:
Network
backhaul packet loss from PATH server to RSE computer ( avg/ max/ min/ dev)
backhaul ssh delay from PATH server to RSE computer1
traffic data rates, broken down by DSRC/ backhaul, in/ out bound
capacity backhaul capacity, broken down by in/ out bound
beacons received how many and from which RSE sites2
signage contents of recent signage, travel time, and other public broadcasts
signal phase contents of recent broadcasts of signal state
Denso Wave Radio Module ( WRM)
configuration channel, power level, data rate, etc.
status WRM status fields
packet loss between pc104 and WRM
Software
CPU usage broken down by process
memory usage broken down by process
configuration VII- CA software configuration
status recent errors, process uptime
1 ssh is " secure shell", the primary tool for administration of remote systems.
2 This information is useful in detecting overlap between nearby DSRC antennae.
18
VII California: Development and Deployment
Lessons Learned
diagnostics monitoring system diagnostics
VII- CA applications recent VII- CA message activity
Hardware ( pc104)
voltage on- board voltage sensor
fan speed on- board fan speed sensor
temperature 3 on- board temperature sensors
clock skew between RSE computer and PATH server
disk usage
system uptime
3.1.3 Corrective actions
The monitor system can correct some of the problems that it detects.
Signal current Restart sniffer software if phase data is not detected or is obviously
Indicator ( sniffer) incorrect.
VII- CA software Restart VII- CA programs if they have crashed or become
unresponsive.
Denso WRM Send " wakeup" packets to WRM if WRM incorrectly detects its
host interface.
Send channel/ power packets to WRM to correct settings.
3.1.4 Web Interfaces
Access to the monitor data is through several web interfaces, available at
http:// path. berkeley. edu/ vii/ monitor.
Current reports Show the most recently received data in a summary table and in
detail pages.
Time- history graphs Show history of variables over hours, days, or weeks.
Google map Quick overview of testbed status, overlaid on Google map.
19
VII California: Development and Deployment
Lessons Learned
3.1.4.1 Current reports
The current reports are summarized in a table like Table 3.1:
Table 3.1 VII Monitor Report
20
VII California: Development and Deployment
Lessons Learned
3.1.4.2 Detail pages
Each site has a page, to which the summary table links, showing more of the variables collected
for that site, plus a link to a page with the full report:
Figure 3.1 Example detail page, California at El Camino
21
VII California: Development and Deployment
Lessons Learned
3.1.4.3 Full report
The full report is the entire database contents for a particular RSE site.
Figure 3.2 Example full report
3.1.4.4 Time- history graphs
The history database and graphs managed using the RRDTool, which has become a standard for
system administration. RRD stands for Round Robin Database; " round robin" means that the
database stores only the last N data points, where N is a fixed number. RRDTool also aggregates
the data ( average, min, max) and differentiates ( converts byte counts to rates, for example).
Graphs are generated based on user input, such as site ID, variable name, time window, and
averaging period. The following kinds of graphs are currently available:
1. SSH responding for all sites
2. SSH response time for one site
3. Round- trip ping rate for all sites over 24 hours
4. Round- trip ping rate for selected sites and duration
22
VII California: Development and Deployment
Lessons Learned
igure 3.3 Graph of Packet Loss
5. WRM ping packet loss for selected sites and duration
6. WRM ping packet loss for selected site, duration, and averaging period
7. Temperature inside pc104 boxes
8. Fan speed inside pc104 boxes
9. Voltage inside pc104 boxes
10. Memory usage
11. CPU usage
12. Process uptime
13. Network usage, DSRC and backhaul
14. Network usage, DSRC only
15. Network usage, backhaul only
16. Backhaul network capacity
The following graph shows packet loss on the fiber- optic cable between the host computer and
the WRM3:
F
3 This failure mode is still not completely understood, even though it has a sharply defined diurnal cycle. It
may be temperature related, but there is apparently no simple cause- effect relation.
23
VII California: Development and Deployment
Lessons Learned
nother graph used to diagnose this situation was the temperature graph:
here are also summary graphs that show some aspect of the status of the whole system. The
llowing graph shows the periods during which sites were not accessible using ssh:
A
Figure 3.4 Temperature Graph
T
fo
Figure 3.5 Graph of ssh responsiveness
24
VII California: Development and Deployment
Lessons Learned
Resource usage graphs are essential to checking the health of a system4. The following graph
shows four variables at one site: outgoing and incoming data rates on the DSRC and backhaul
networks. The graph also shows how some of the image generation capabilities of RRDTool can
enhance the visualization of complex information:
Figure 3.6 Resource graph of an RSE
4 A recent intrusion in one of the RSE hosts was detected using the memory and CPU resource graphs.
25
VII California: Development and Deployment
Lessons Learned
he following graph was used to detect and diagnose a software bug that caused unexpectedly
high memory usage:
igure 3.7 Graph of Memory Usage
T
F
26
VII California: Development and Deployment
Lessons Learned
y of a Google map with data from recent reports. The color of the dot is
reen if no serious problems are detected, and red otherwise.
Figure 3.8 Testbed map
.1.4.6 Technical details
he architecture of the monitor system involves two kinds of components:
• A monitor client, which runs on each RSU host device.
• A monitor server, which runs on a host somewhere on the Internet.
hese programs are installed and running on the active field RSE and testing RSE and on the
path. berkeley. edu server. The client software is installed on new RSE hosts as they become
vailable.
eports are sent from client to server periodically ( typically, at 5 minute intervals). Data is sent
ver UDP, rather than TCP, because packets lost due to network problems are less important than
ewer packets containing newly sampled data. The monitor client takes care not to use too much
3.1.4.5 Map of testbed with status indicators
The map is an overla
g
3
T
T
a
Ron
27
VII California: Development and Deployment
Lessons Learned
ed with minimal interference.
).
constraints on the project:
1. The compressed developm ed the use of prototype- quality
ponents ( including the Denso WAVE Radios
cellular modems) evolved to new generations during the project. Most
icularly limited: they
heir wired side and they cannot
t they cannot support TCP- based
not fully support the
- line. Hence, not all sites can support all services. Furthermore, this diversity
bandwidth, so that VII applications can proce
The architecture is shown in the following figure:
Figure 3.9 Architecture of Monitor System
3.2 NETWORK: MIDDLEWARE FOR VII- CA MESSAGES
A major goal of the VII California testbed is to support a diverse initial set of applications,
including probe, public information, and non- public services ( such as navigation and tolling
The VII- CA partners, led by PB Farradyne in 2005, defined an initial message set to support
these applications, and PATH developed a middleware for the exchange of these messages
between in- vehicle client software and back- end application servers.
The characteristics of this middleware are best examined against the background of the
ent schedule has requir
hardware. Firmware for several com
Modules and the
components have bugs and limitations. The Denso radios are part
cannot transmit packets to more than four hosts on t
assign dynamic IP addresses to vehicles. This means tha
networking between vehicles and servers. Also, the Denso radios do
WAVE standards; they only support IP networking.
2. The backhaul network is heterogeneous, ranging from cellular modem to dedicated T1
land
requires built- in limits on roadside- to- server communication, such as buffering,
prioritizing, and possibly probe data aggregation.
3. The inherent unreliability of mobile wireless networks requires a degree of robustness.
28
VII California: Development and Deployment
Lessons Learned
speeds with limited
erference. No application can expect to have
ions.
l
of
or
ived
2. Message reception probability is robust in the face of short- term failures. The
middleware can detect the loss of a fraction of the packets in a message and retransmit
ss is not extensive, this will quickly and efficiently
complete the message transmission. Unlike TCP, if no fragments arrive ( likely because
esending them, and no
are is a TCP socket, with
g is encapsulated across the wireless link to overcome the Denso
Packet loss is likely in an environment with nodes traveling at high
range, line- of- sight occlusions, and RF int
long- lasting, consistently available connect
4. Application messages can be long. In the initial VII- CA message set, probe messages can
be up to 64 KB with multiple snapshots. Media file downloads could be severa
megabytes.
5. The middleware should present VII California application programs with an interface for
communication between vehicles and servers that is message oriented ( like UDP, User
Datagram Protocol) but has inherent quality of service controls ( to some extent like TCP,
Transmission Control Protocol). It must be somewhat reliable, but not at the cost
excessive use of the channel or complexity from the point of view of the application.
6. Information from the vehicle must be kept as private as possible.
Within these constraints, the VII California middleware succeeds in several ways:
1. The first packet from the vehicle to the server is a data packet; there is no delay f
dynamic IP address assignment, TCP session initialization, or other handshaking. The
reduction in delay increases the chance that a return message ( if any) will be rece
before the vehicle goes out of range.
the missing fragments. If packet lo
nodes are out of range or occluded), no bandwidth is wasted r
bandwidth is wasted on acknowledgment packets.
3. The suite includes a proxy which runs on the vehicle side to insulate vehicle code from
the complexity of the wireless user datagram protocol ( UDP protocol) and provide it with
a TCP socket interface for sending and receiving messages.
4. On the server side, similarly, the interface to the middlew
multiple vehicle sessions multiplexed in one TCP session using transaction IDs.
5. Message addressin
limitations.
6. No identifying information from the vehicle ( outside of the application payload)
propagates farther than the roadside or is stored anywhere.
7. The middleware supports general HTTP access ( though it was not required for the initial
set of applications), so that web- based applications can run from within vehicles,
regardless of the Denso limitations.
Certain aspects of a complete VII architecture are not fully addressed by this prototype software,
including security, scalability, and conformance to emerging national VII standards ( Henry,
2007; FHWA, 2005; Cops, 2006).
29
VII California: Development and Deployment
Lessons Learned
EE 1609 Dedicated Short Range Communication ( DSRC) / Wireless
by
erica World Congress,
m technology
ents ( Misener
rsections is high compared to the typical
lar systems because the set- up time is
unication possible using real
and error percentages, and do not measure the latency of individual
ed to rise to a rate that will
ce issues for multiple OBEs approaching a RSE. A
major motivation for this research is the scenario described in the proceedings of the December
3.3 EVALUATION OF DSRC COMMUNICATION PERFORMANCE USING
LOW COST PROTOTYPE SYSTEMS WITH MULTIPLE RADIOS PER
VEHICLE
3.3.1 Introduction
The adoption of the IE
Access in a Vehicular Environment ( WAVE) family of standards for trial use in 2006 ( USDOT,
2006) has given the public sector and the auto industry a well- worked- out framework for
conducting proof of concept testing. However, there are many performance issues that require
further research to ensure a safe and robust highway communication system. Simulation work
such as that in ( Yin, et al, 2004) and radio prototype and application feasibility development, as
has been done by the Vehicle Safety Communications Consortium ( Krishnan, 2006) and
exhibitors at the Innovative Mobility Showcase at the 2005 ITS Am
among others, provides a solid basis for continued development, but changes fro
specifications in the current trial use standards may be required before full deploym
and Shladover, 2006; Larson and McKeever, 2006).
Performance under congested traffic conditions remains an open issue. The density of vehicle
communications on crowded freeways and busy inte
office WiFi hotspot, and furthermore highway communications are expected to include an
unusually large number of broadcasts. Analysis and simulations cannot accommodate the full
complexity of practical systems with large numbers of vehicles in close proximity. Overall
performance depends not only on physical layer channel effects and on the performance of
backoff at the 802.11 MAC layer, but on operating system and application structuring and
scheduling of messages. Some standard 802.11 techniques for congestion mitigation, such as the
Point Coordination Function, are not possible with vehicu
too long to be effective in a situation where many transmitters and receivers are entering and
leaving the network in a short period of time. More research is needed to characterize the
magnitude of congestion problems and the total amount of comm
hardware in the field and to investigate methods of congestion mitigation.
In addition to the problem with the density of communications, safety applications have critical
latency requirements. Communication measurements tools are often only concerned with the
aggregate data transfer rates
messages. However, in DSRC systems the latency may be the limiting parameter on the data
transfer rate of the system, since the system load cannot be allow
delay crucial safety communications.
The work described in this section represents first steps in using inexpensive computer hardware
with prototype radios to explore performan
2004 DSRC workshop ( Cash, 2004) in which many vehicles come in range of a transaction
service advertised by a Road Side Unit simultaneously and immediately switch to a service
channel and begin broadcasting.
30
VII California: Development and Deployment
Lessons Learned
characterize the performance of the radios under test in conditions where all the
dios were in range.. Section 3.3.5 describes some preliminary tests with channel switching and
ts data with mobile radios at Richmond Field Station. Section 3.3.6 also
The next section ( 3.3.2) in this report provides a description of the hardware used for testing.
Following that, Section 3.3.3 gives a description of the testing software. Section 3.3.4 describes
baseline testing done in the lab to validate the software and hardware as tools for measuring
latency and to
ra
Section 3.3.6 presen
details experiments that were carried out at two intersections in San Francisco to emulate
transaction processing on the service channel and investigate performance in an urban setting.
Section 3.3.7 presents conclusions and plans for future research.
3.3.2 Computer and Radio Equipment
The equipment used for our tests takes advantage of the availability of inexpensive miniature
microprocessor portable assemblies. Four assemblies were constructed; each containing three
400 MHz gumstix expansion boards with two Ethernet ports ( Gumstix Inc, 2007) ( see Figure
3.10). Funding for the equipment was provided by ARINC Corporation, as part of their work on
DSRC for USDOT. ARINC also supplied 12 Mobile Mark magnetic mount antennas specially
constructed for the 5.9 GHz frequency.
Figure 3.10 Assembly of three gumstix netduo expansion boards.
Each of the 12 individual computers runs an embedded Linux system and has two Ethernet
interfaces. On one Ethernet interface it is paired with its own Denso WAVE Radio Module and
rooftop antenna; on the other it can be connected to a host computer for data storage.
The assemblies were designed for flexible configuration. All the assemblies can be connected via
a router and deployed in one vehicle for tests to an RSU, or individual assemblies can be placed
31
VII California: Development and Deployment
Lessons Learned
in different vehicles for vehicle to vehicle research or to test multiple approach paths to an RSU
simultaneously. See Figure 3.11 for the test configuration used.
For most of the tests described in this section, the gumstix processors are connected through the
router to a laptop, which provides a networked file system where trace data from the test run can
be stored. In some tests, the laptop is also connecting through a USB port to a GPS unit, so that
location can be saved as well. All processors are synchronized through the router.
Figure 3.11 Antenna placements with 8 active OBUs on one vehicle
3.3.3 Data Acquisition Software
There are issues with measuring latency, the delay in receiving a message, as well as overall rate.
While many utilities, such as the ubiquitous ping and the widely used iperf, exist to give
estimates of the performance of a network link, more thorough tracing is required in the case of
DSRC. Because the characteristics of the link change as stations come closer together and move
apart, average data transfer and round trip time measurements do not provide enough information
to diagnose and elucidate link breakdown conditions. We developed programs for this project
that allowed us to trace round- trip time on a message by message basis, accounting for clock
ew in the process.
he basic prog and a monitor
rocess. The monitor process runs on the same system as the sender and records the round trip
sk
T rams developed une34 this effort included a sender, a receiver
p
information when a return packet is received from a receiver. Two additional convenience
programs evaluate the clock skew between a system and its network neighbor, and set the clock
based on a message received from the clock skew program.
These processes use a library API for communicating with the Denso WRMs that implements the
low- level processing of the IP headers and raw IP packets that is required in order to record
Received Signal Strength Indication values for each packet.
32
VII California: Development and Deployment
Lessons Learned
number of bytes per packet, the
me interval between sends in milliseconds, and the total number of sends in a run.
ed at remote
stem ; time return packet was received by monitor program; estimated one- way transmission
time; average one- way transmission times over course of run; estimated absolute value of clock
skew between OBU and RSU; RSSI at remote host ; and RSSI read at sender
Clocks on hosts and gumstix were synchronized at the start of the experiment, and post
processing was used to interpolate GPS data and assign values for UTC time, latitude and
longitude to all received packets.
3.3.4 Baseline Testing
As part of our base line testing, we first needed to determine that we were able to measure
communication delays, and delays due to interference in communication. There was a question at
the start as to whether operating system scheduling delays would make it difficult to measure
communications effects. Figure 3.12 below shows that the basic trip time between two systems
in good communication, with no competition from other stations for the airwaves, is typically 2-
3 milliseconds. While the actual time transferring the symbols on the radio medium is much less
than this, this includes the time buffering and cop ing the message on transmission and reception,
and scheduling the application processes that ar essage.
igure 3.13 sh pairwise at a
oderate rate. Competition for the airwaves between the two pairwise streams causes the round
illiseconds. Figure 3.14 shows how a high rate of transfer
The processes can all be configured for different power, channel and rate settings of the Denso
WRM. The send process can additionally be configured with the
ti
Data recorded by the monitor process at the originating sender for each round- trip packet were:
time that the monitor process recorded the data; destination ( RSU) IP; sequence number; number
of bytes in packet; time packet was originally sent; time packet was receiv
sy
y
e the source and destination of the m
F ows the situation when two different stations are sending messages
m
trip time to rise to between 3- 5 m
between two computers can cause greatly increased delay on a pairwise stream between two
other computers communicating at a more moderate rate. Note that the trip time scale on this
graph is in seconds, not in milliseconds as for the previous trip time graphs. See on the lower
graph in Figure 3.14 that on the higher rate stream packets were actually dropped, due to
exceeding the retry limit, between sequence numbers 1454 and 1746.
33
VII California: Development and Deployment
Lessons Learned
Figure 3.12 Baseline operation, 1480 byte data per packet, 10 millisecond interval between
sends, different pairwise runs of the four stations used for desk checking
34
VII California: Development and Deployment
Lessons Learned
35
Figure 3.13 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)
VII California: Development and Deployment
Lessons Learned
Figure 3.14 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.
36
VII California: Development and Deployment
Lessons Learned
3.3.5 Effects of Channel Switching
The prototype Denso WAVE Radio Modules that we were using for this preliminary testing were
not designed to switch channels fast enough in order to allow a 50 ms control channel period and
a 50 ms service channel period, as specified in the IEEE 1609.4 standard. However, we were
interested in seeing how well communication could be maintained across channel switches even
under adverse circumstances. We also wanted to test how well the gumstix processors were
synchronized across the router. We found that, while for infrequent channel switching it was
possible to continue communications with only a small percentage of lost packets, when channel
switching was more frequent it was impossible with our current equipment to maintain
synchronization well enough to avoid significant losses.
We began by performing a set of tests, with stationary equipment in close range. Five gumstixs
acted as “ vehicles” sending to a sixth used as the “ road side unit” or receiver. Channels were
switched between Channels 172 and 178 by a background process running on the host laptop that
sends a message through the router telling each gumstix processor when it is time to switch
channels. The gumstix processor writes a record to the shared file system of the time of the
switch. Clocks on all gumstix processors are synchronized before the start of testing. Parameters
are shown in Table 3.2 below.
Table 3.2 Parameters used for tests of frequent and in frequent channel switching.
Testname Switch interval
( between
channel changes)
Packet Interval
( between sends)
Packet size
( data bytes)
Load at
Receiver
( bytes/ sec from
all senders)
sw0 No change 100ms 200 10K
sw1 5 sec 100ms 200 10K
sw2 5 sec 200ms 200 5K
sw3 5 sec 50ms 200 20K
sw4 100ms 25ms 200 40K
sw5 100ms 10ms 200 100K
Figure 3.15 below shows the baseline case with no channel switching. Note that in these graphs
the sequence numbers for the different processors have had a constant added so that they appear
in different Y ranges; in fact the sequence numbers begin at 1 for every invocation of the
program.
or no
the
is amount. Figures 3.18 and 3.19,
ases sw2 and sw3, show no appreciable difference from case sw1. However, for case sw4, as
own in Figure 3.20 the increased overall load and increased channel switching. have caused
some dropped packets ( evidenced by missing sequence numbers) and some round trip times over
Figure 3.16, with case sw1 indicates that infrequent channel switching causes little
degradation in performance. Figure 3.17 shows that for this run the channel changes on
different gumstix processors are clustered within about 10- 15 ms of each other, with delays
through the router from the host laptop where the channel switch directive is initiated and
scheduling delay on the individual processors adding up to th
c
sh
37
VII California: Development and Deployment
Lessons Learned
5ms. Notice in the close- ups in Figure 3.21 how for some processors, the time they are on a
channel is skewed enough away from the time of the receiver that they may successfully send
only one or two messages while they are connected on the same channel. Figures 3.22 and 3.23
show that these effects are more pronounced with the larger load. Overall system load on the
router may also be contributing to the greater skew on channel switch times, when sw5 is
compared to sw4.
Figure 3.15 Baseline case: no channel switching, light load.
38
VII California: Development and Deployment
Lessons Learned
Figure 3.16 Infrequent channel switching, messages sent at 10 Hz. ( t1); each channel switch is
indicated by a vertical line, at that point the channel changes
39
VII California: Development and Deployment
Lessons Learned
Figure 3.17 Close- ups, in case of infrequent channel switching ( t1).
40
VII California: Development and Deployment
Lessons Learned
Figure 3.18 In this case, sw2, the send rate is half that of sw1, and round trip time remains low.
41
VII California: Development and Deployment
Lessons Learned
Figure 3.19 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.
42
VII California: Development and Deployment
Lessons Learned
Figure 3.20 Case sw4, with increased overall load and increased channel switching.
43
VII California: Development and Deployment
Lessons Learned
Figure 3.21 Close up of switching and sequence number loss for case sw4.
44
VII California: Development and Deployment
Lessons Learned
Figure 3.22 Case sw5 has increased loading and likewise increased latency and packet loss
compared to case sw4.
45
VII California: Development and Deployment
Lessons Learned
Figure 3.23 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.
46
VII California: Development and Deployment
Lessons Learned
3.3.6 Mobile Radios
As further validation of the test set- up, we carried out experiments with 8 radios on a single van
at Richmond Field Station. We ran a variety of different loads and packet sizes, in a stable
scenario where the van was parked at about 100 feet from the RSU, and in a moving scenario in
which it drove a short distance along the test track. More of that data will be presented in a
separate report, but as an example we show in Figures 3.24 and 3.25 two runs under the same
conditions, except that one was moving and the other parked. In both cases the background
channel switching is causing some disturbance. In the case of the moving vehicle the round trip
time is higher almost from the start, and gets higher still as the vehicle moves out of range. Note
for comparison with the next section that the overall load on the receiver is 160Kbytes/ second.
Figure 3.24 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.
47
VII California: Development and Deployment
Lessons Learned
48
Figure 3.25 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.
VII California: Development and Deployment
Lessons Learned
3.3.7 Urban Intersection Testing
3.3.7.1 Packet length and interarrival time
Figure 3.26 Location of RSU at 6th and Brannan in San Francisco.
The data in this section were taken with the RSU that was installed at 6th and Brannan in San
Francisco as part of the Innovative Mobility Showcase for the ITSA World Congress in the fall
of 2005 ( ITSA, 2005). The Denso WRMs for these RSUs were mounted on the signal arm, see
the location in Fig 3.26. The wired interface of the WRM was connected by fiber to a PC104 in
the traffic signal controller cabinet, running Linux. The software in the PC104 during this test
was source identical with the data acquisition software running on the gumstix computers in the
vehicle. These tests were conducted on September 24, 2006.
For all runs, data gathering started at the intersection with 5th and Brannan and continued for
two minutes, while driving straight along Brannan to 7th street, turning right, coming back along
Bryant, and then turning right at 5th. See illustration with dotted line in Fig. 3.26 of active part of
the run.
There were three types of run, with low, medium and high overall load. For each set, the
intervals between message sends were adjusted to maintain a constant load of messages at the
RSU. In the first case the load was 40K bytes per second, in the second it was 100K, in the third
200K. For all runs on this day of testing the data rate setting in the Denso WRMs was set at
6M
49
RS
U
bs.
VII California: Development and Deployment
Lessons Learned
Figure 3.27 Plot of average of remote and local RSSI by GPS location for all received packets in
runs at 6th and Brannan.
This data included two fields for local and remote RSSI, measured in dBm. RSSI values for all
the runs are plotted together in against latitude and longitude in Fig. 3.27.
Variable parameters for each run were: Denso WAVE Radio Module rate setting, in
Mbits/ second; number of senders in run; packet size in bytes for this run; number of milliseconds
in interval between packets; number of sends in the test ( in some cases continuous and halted by
user when out of range).
To approximate a model of transaction processing in which the traffic is predominantly
generated on a service channel in response to short broadcasts on a control channel received,
post- processing created the following summary data for each run: run type identifier string ; B
total load for run ( in kilobytes); R rate setting of Denso WRM in Mbs; S number of senders; M
bytes per packet; I time interval between packet sends;• N number of sends in test; successful
sends in test; average RSSI ( over round trip);• start time ( time of first reception); message time
( time of reception for 8000 bytes -- line 8000/ P); end time ( time of last reception);• message
period ( message time - start time); connected period ( end time - start time); minimum distance
50
VII California: Development and Deployment
Lessons Learned
from RSE; maximum distance from RSE; average distance from RSE; success rate ( line count /
possible transmissions; between start time and end time, i. e. while in range);• gumstix processor
ID number.
In our figures we have graphed two measures of communications performance with respect to
interval between sends. In Fig. 3.28 the success rates for each run are used as a measure of
probabilities of successful round trip transmissions. In Fig. 3.29, the time required for successful
reception of 8000 bytes is used as a measure of transaction time. Reading the graphs, for each
line with a fixed packet size, the values on the left represent higher overall loads than the ones at
the right. Due to testing time limitations, the set of run types with the highest load was completed
only for 2 nodes and 8 nodes.
Looking at the highest load values for 2 nodes and 8 nodes, in these tests, for the same overall
load, the 400 and 800 byte packet size tests ( with smaller send intervals) have better performance
in terms of success rate of packet transmission than the 200 byte packet size. While this is
interesting, clearly much more testing is required to characterize the regions of operation for this
effect.
Note that even with 8 nodes, although the probability of individual packet success is low for
smaller sending intervals, because of collisions, at the overall loading used in these tests the time
until an 8000 byte transaction is completed, from the time of first connection, stays under 2.5
seconds.
51
VII California: Development and Deployment
Lessons Learned
Figure 3.28 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.
52
VII California: Development and Deployment
Lessons Learned
Figure 3.29 Time ( in seconds) until the first 8000 bytes has been transmitted, as a function
interval between packet sends, for 1, 2, 4 and nodes, with varying packet sizes of 200, 400 an
of the
d
800 for tests at 6th and Brannan.
53
VII California: Development and Deployment
Lessons Learned
54
3.3.7.2 Data rate and queuing
Figure 3.30 Location of RSU at 3rd and Townsend in San Francisco, and direction of test runs.
The data described in this section was taken with the 3rd and Townsend RSU in San Francisco
( see Figure 3.30), another RSU that had been installed as part of the Innovative Mobility
Showcase. Data was taken on June 15, 2006, just before the PC104 computer connected to the
Denso WAVE Radio Module was removed because space in the traffic signal control cabinet
was required for other uses.
Three different approaches were made to the RSU, from 2nd and Townsend past the RSU at 3rd
to 4th and Townsend, from 4th and Townsend past the RSU to 2nd and Townsend, and from 3rd
and Berry traveling on 3rd past the RSU. Additional data was taken while sitting still and with a
background process switching channels. The channel switching data is not analyzed in this
paper. No RSSI data was taken with this run; the code to record this data had not yet been
integrated into the testing code.
For all approaches, packets were sent every 10 milliseconds, with either a short ( 200 bytes) or a
long ( 1400 bytes) packet length. This gives an overall load, for 9 gumstix senders of 1.44 Mbps
for the smaller packet size, and 10.08 Mbps for the larger packet size. In the presence of lost
messages due to marginal RSSI or contention, backoff appeared to cause the transmission rate of
the receiver to be lowered to the point where queues saturated the receiver, so that delays of
several seconds for round trips were observed on some runs. On other runs, some of the senders
seemed to either be completely blocked out or have dropped out for some other reason, so for
these runs there were fewer than nine vehicles.
Fig. 3.31, 3.32, 3.33 and 3.34 show the transaction delay and the standard deviation of this delay
as a function of the data rate setting. The most striking feature of the data is the high standard
deviations and the very poor performance on the run on 3rd Street and the run from Townsend
and 2nd to Townsend and 4th compared to the run in the other direction on Townsend and the
run that was taken from a car parked in 3rd Street in close range to the RSU. In the presence of
al
erved on some runs. On other runs, some of the senders seemed
RSU
lost messages due to marginal RSSI or contention, the transmission rate of the receiver appeared
to be lowered to the point where queues saturated at the receiver, so that delays of sever
seconds for round trips were obs
VII California: Development and Deployment
Lessons Learned
out or have dropped out for some other reason, so for these runs
ther