Deployment of the New York City (NYC) Connected Vehicle Pilot (CVP) project relies on the ability to manage Aftermarket Safety Device’s (ASD) firmware, configuration, and data recording logs over the Dedicated Short-Range Communications (DSRC) medium. These capabilities allow the project team to begin installation of the ASDs while providing for ongoing testing and tuning of the CV applications in the dense urban environment. As such, these are critical capabilities that directly impact the project schedule and the application of tuning operations that will occur while the devices are installed in the project’s large fleet of up to 8,000 vehicles.
The solution chosen uses network coding which provides a scaleable approach to simultaneously broadcasting the update (download) to many vehicles [all vehicles within listening range] at the same time – as well as allowing individual vehicles to request the broadcast of specific updates they need or may have missed. The WAVE Service Advertisement (WSA) from the Roadside Unit (RSU) announces the availability of the updates and indicates the vehicle groups targeted. It should be noted that the file sizes are expected to be in the 20 MB range and unicasting such downloads to thousands of vehicles is not practical given the time needed to complete the transaction.
This article provides an overview of the Over-The-Air (OTA) testing performed by the project team in early October 2018. It describes the test planning, testing environment, and summary the results. Testing was performed by the City’s three sub-contractors: Danlaw, Siemens, and TransCore at TransCore’s Norcross, Georgia Facility.
The OTA download process has two forms supporting continuous broadcast of the target file contents and an individually requested on-demand file transfer. A WAVE Service Advertisement (WSA) is broadcast by the RSU to identify the service’s availability and channel assignment(s). Downloads are network-coded using the CodeOn library to allow for efficient transmission in a lossy environment.
Management of the OTA upload process utilizes remote synchronization (rsync) and secure tunnel (stunnel) open source applications built on the open secure sockets layer (openSSL) libraries. These applications enable the ASD and RSU to connect over a secure session and perform file (i.e. log) transfers.
The test site is depicted in Figure 1. Each RSU was isolated by the building to prevent the ASD from simultaneously receiving from both RSUs. This isolation was verified using a DSRC “sniffer” while driving around the building and identifying “dead” zones with respect to the service channels being used.
The test plan covered several areas of system requirements. The first area focused on the downloading of data from RSUs to the ASDs to accomplish firmware/software updates as well as distribution of configuration parameters. It included tests with single and multiple files of various sizes as well as vendor-specific file targets needed by the project to support ASDs from multiple vendors.
Several scenarios were used in the test environment. These included stationary vehicles, moving vehicles in contact with single or multiple RSUs, and interrupted data connection scenarios. These scenarios modeled expected operations at the vehicle terminal facilities where one or more RSUs will be installed to support the data exchanges. File sizes were also varied to assess anticipated application/media performance as the expected contact time between an ASD and RSU for the transfer will vary by location. The download mechanism also supports weighting of individual files for prioritization purposes. This weighting capability was also tested.
The following table summarizes the results of downloading from the RSU to the ASD and uploading from the ASD to the RSU in various scenarios. These scenarios incorporate the expected vehicle/infrastructure interactions in the project’s terminal areas, taxi holding lots, bridge crossings and installation facilities where RSU support sites are anticipated.
Scenario ID |
Scenario Description |
File Quantity |
File Size |
Download Time (seconds) |
1 |
Vehicle stationary – single tiny files |
1 |
10 KB |
0.3 - 1 |
2 |
Vehicle stationary – single small file |
1 |
1 MB |
3 - 4 |
3 |
Vehicle stationary – single large file |
1 |
50 MB |
200 – 230 |
4 |
Vehicle stationary – receiving two files at the same time |
1 |
1 MB |
3 - 4 |
5 |
Vehicle moving and ASD restarted during download |
1 |
20 MB |
250 – 270 |
6 |
Vehicle moving from one RSU at beginning of download to another RSU for completion of download |
1 |
20 MB |
360 – 370 |
7 |
Vehicle stationary receiving two files at the same time with different weightings |
1 |
5 MB |
58 - 62 |
Scenario ID |
Scenario Description |
File Quantity |
File Size |
Upload Time (seconds) |
1 |
Vehicle Stationary – many small files |
100 |
1 KB |
12-15 |
2 |
Vehicle Stationary – single large file |
1 |
21 MB |
12-15 |
3 |
Vehicle Moving out of range of RSU1 and coming back to range of RSU1 (Short drive – Within parking lot) |
10 |
2 MB |
49-55 |
4 |
Vehicle Moving out of range of RSU1 and coming back to range of RSU1 (Long drive – Going outside parking) |
10 |
2 MB |
70-75 |
5 |
Vehicle Stationary, same set of files which are already present in RSU |
10 |
2MB |
2-5 |
From the observed file transfer times, it appears that the project’s objectives for managing the vehicle fleet’s firmware, configuration files, and data logs can be accomplished at the RSU support locations. It is anticipated that firmware downloads will be on the order of 20 MB and the download times appear to be well within the contact time anticipated at the RSU support sites. While the quantity/size of data logs for uploading is still theoretical, the results indicate that there will be adequate margins to perform the required data transfers. The NYC Pilot team has taken these results and used them as inputs towards formulating templates for RSU installations under the various operating scenarios that it will be deploying throughout New York City.
