Brad Templeton Home
V2V and the challenge of cooperating technology
A great deal of effort and attention has gone into a mobile data technology that you may not be aware of. This is "Vehicle to Vehicle" (V2V) communication designed so that cars can send data to other cars. There is special spectrum allocated at 5.9ghz, and a protocol named DSRC, derived from wifi, exists for communications from car-to-car and also between cars and roadside transmitters in the infrastructure, known as V2I.
This effort has been going on for some time, but those involved have had trouble finding a compelling application which users would pay for. Unable to find one, advocates hope that various national governments will mandate V2V radios in cars in the coming years for safety reasons. In December 2016, the U.S. Dept. of Transportation proposed just such a mandate.
To promote safety, the plan is to have cars broadcast messages showing their location history (from GPS) along with their speed, direction, braking state and other useful information. Other cars could receive this and learn where some (a few in the first decade, growing over time) of the other cars on the road say they are. The hope is that this would allow cars to detect cars that the driver or sensors can't see, such as ones hidden by a big truck, or ones coming from around blind corners or blind intersections. The V2V radio could, in theory, help you notice another car is running a red light and warn you to stop even before you can see the car. You could also learn about vehicles which are hitting the brakes or steering suddenly, if they broadcast that.
Some believe this sort of signal is important, even a "must" before cars can drive themselves, but it turns out efforts to make robocars are going very well even without the radio signals. While the signals would have some utility in these hidden car situations, self-driving cars need to see everything on the road, not just cars with transmitters, so they already need very good sensors. With such sensors, the radios don't add nearly as much value as was hoped.
In fact, this plan suffers from many serious flaws, several of which would be enough to recommend against it on their own. At the same time there are huge forces pushing the idea and its outdated technology. They need a government mandate as that is the only way the technology will not quickly vanish into obsolescence.
I say that DSRC and V2X in general are an emperor that has no clothes. Everybody says it's important, they go so far to say that self-driving cars actually need this sort of connectivity if they are to work at all. This falsehood has become so common than only a few stand out against it. On top of that, some of those who speak against it are those who offer an superior alternative (namely mobile telco technology providers) which makes their motives naturally suspect, even if they are correct.
A DSRC mandate won't end the world. But it could do harm, by forcing all vehicles to waste money on obsolete technology, and slowing the development and deployment of newer technology. People will naturally gravitate towards a legally mandated technology as other choices become harder, even if it is the wrong tech. For security reasons, cars may include DSRC radios as legally required, but leave them disconnected from the car's driving and safety systems for good reasons.
A common phrase in the community to promote the idea is "Connected Autonomous Vehicles." I say "Connected Autonomous Vehicles -- Pick 2."
The Chicken and Egg problem
The problem in getting something like this going is that V2V communication requires a very different network effect to get kickstarted when compared with other networked technologies, such as Cellular, the internet, e-mail or fax. A car with V2V has to encounter another car on the road with V2V to get some benefit. Even if 25 million cars in the USA (10%) spoke compatible V2V, the odds that any 2 cars would be able to communicate and prevent an accident would be just 1%. Even preventing 1% of the 2,000 or so such fatal accidents is a great thing for the 40 cars protected, but the cost is so high that more lives might be saved spending the resources elsewhere.
With V2V, you don't get to pick who you are communicating with. Contrast that with fax -- while fax worked best once everybody had a fax, the truth was a company could buy 2 fax machines for 2 offices and get immediate benefit. If all your friends joined a social network or e-mail, it didn't matter if nobody else was on it. Since cell phones can talk to landlines, the first cell phone was still hugely useful.
To face this, the DSRC designers originally hoped to offer internet like services over the protocol. With local relays, bandwidth could be much higher than the cellular data services that existed back then. But while they were waiting, mobile data services got ubiquitous and fast, and now a large fraction of cars have mobile radios in them and offer internet applications, and an even larger number of people carry smartphones to do this. By 2020, almost all cars will have a live connected smartphone inside them, and that will remain true from then on, except the phone will tend to be much newer than the car, with more modern technologies.
Without the internet applications, it's hard for V2V to show its value. You can't sell a product that's of no value to the first buyer, and almost no value to the 25 millionth buyer. There is a value in communication from the infrastructure -- for example, it would be nice if all traffic lights announced their intentions over radio so cars could time the lights efficiently and reliably. However, the planned mandate is for the cars, not the lights, and there's no money in all the towns and cities to pay for the lights.
The V2V world teaches a worthwhile lesson for all networked and mobile products. A tool must be useful to the first buyer or it has a very hard hill to climb.
In particular, all applications must now be compared with communication over public data networks, done "vehicle to cloud-server to vehicle." This comparison is necessary because this mode of communication is certain to exist, and in fact already exists in a serious fraction of vehicles, either due to data services installed in the car, or by virtue of the driver of the car having a smartphone running a driving app. Deployment of V2Cloud is all but certain, and it will be near ubiquitous by the early 2020s if not sooner.
Waze is an early example of V2Cloud done in phones. Cars transmit traffic data and incident reports to the cloud, and other cars receive them. Waze and its competitors have traffic data on almost every road in the world through this method, at minimal cost and no incremental cost per car or city.
The Use Cases
Advocates for V2V have suggested many applications for it over the years. Some are valid, but only mildly so. Others used to be valid but have become supplanted by other technologies. Some are highly speculative.
Here are the criteria which can allow a V2V application to have special value. Without these, other solutions are superior.
With these criteria in mind, the following applications can make use of V2V
Notably, several popularly proposed applications are not on the list of compelling reasons for V2V:
As can be seen, the list of useful applications is disturbingly small, but as noted above, it has to be, because the most it can do is take us from "safe enough" to safer, a gap that must by definition be minor. The use in platoons is a special one, because only the vehicles wishing to join platoons need install the V2V radio. There is not the same "random encounter" problem.
With such a small list of benefits, the serious downsides of V2V, notably the security ones, seem to overwhelm its value.
Potential benefit is inherently limited
When it comes to robocars (self-driving cars) none of the teams developing these vehicles are planning to depend on DSRC for anything. They want to deploy in the next few years, and DSRC will not be available for a few years, and even should it start being deployed, it is many years before it will be widely deployed.
These teams instead need to make a car that meets very high safety goals now. It must meet those goals when dealing with other cars and infrastructure that do not speak DSRC. Further, it must do this forever, because even with 99.9% deployment of DSRC there will still be some vehicles not using it, and pedestrians, cyclists and animals will never be widely using it. We will not get all the deer to wear transponders. According to insurance sources, there are 2 million deer strike accidents per year in the USA, out of 12 million total insurance reported accidents.
This means the vehicles need sensors capable of perceiving risks on the road well enough to reach the desired safety levels. Most concur these safety levels must exceed human safety performance.
While teams say they would use DSRC data if it were available, the reality is it can never help very much. That's because the systems must be "safe enough" without any use of DSRC. The most DSRC can do is move them up slightly. The gap between "safe enough" and "nearly perfect" must be small, or we will not deploy robocars on the roads. The most DSRC can do is move the needle very slightly within that small region.
It can never be that useful because if it's being really useful, something is very wrong.
For non-robocars, there is a similar analysis. However, the sensors that are becoming cheap thanks to robocars and ADAS are becoming available for use in human driven vehicles. These are already increasing the safety levels of these vehicles, and again reducing the difference that DSRC can make.
Because robocar sensors must perceive all that they can see, V2V's value lies in things that are occluded. One useful application is detection of brake application by occluded vehicles. Another is detection of occluded cross traffic. These are real things, but they are small things. The vast majority of safety work will be done by robocar sensors like LIDAR, cameras and radar. Those sensors detect all vehicles, and all other road users, whether they have transponders or not. They are a must, while V2V is optional.
Today, most people envision this level of sensing ability only on robocars, but in reality, almost all electronics technologies and computer technologies have historically followed the "Moore's Law" curve for price/performance. It is a very reasonable prediction that this, combined with volume manufacturing, will make these sensors available at very low prices and very soon. Several companies (the author is an advisor to one) promise LIDAR sensors for costs of around $100. Cameras cost just tens of dollars today, and the neural network tools to understand what the cameras provide are going through revolutions of performance.
As a result, one must consider that low cost sensor tools will be available in the early 2020s for all sorts of cars. They are already available on higher end cars and some medium cars. Imagine not what they do and cost today, but what they will do and cost in the 2020s, when DSRC will just begin deployment. They will almost certainly provide far more effective solutions to automotive safety problems.
The DSRC reports outline large numbers of accident statistics, however they don't indicate that most of those accidents would be better prevented by sensors than DSRC, because sensors will see all visible vehicles and other road users, while DSRC will allow the detection only of new vehicles equipped with transponders, with the one advantage that it will allow detection of occluded vehicles.
We are at least a decade if not more from a time when DSRC would be a more effective choice for detecting a potential accident than sensors would be. DSRC or other V2V will also get cheaper thanks to Moore's law, but they will not get much better. Their success rate is governed not by the technology or quality of the radios, but simply by the penetration of the equipment.
As such, the value of DSRC is governed by only what it can do over and above sensors (which is minimal) minus its failures because of low market penetration and permanent non-penetration among animals, old cars and most pedestrians and cyclists. That value is not enough to justify significant effort. Resources are better spent in other ways. More lives will be saved and more accidents will be prevented.
There are multiple levels of security risk
Other comments will address the many security concerns. There are three broad problems.
Here are more details:
People building robocars are very concerned about the reliability of their sensors. They want to specify their equipment precisely. They want to pick the vendors. They want to test and certify the equipment to make sure it's reliable. This is very different form receiving information from unknown sources. The sources may not be malicious, but they are also completely outside your control, and were never tested or certified by you.
That can be OK for general information, but is risky if safety decisions are to be made based on these unknown sources. You can't certify the reliability of your system if it will make safety decisions based on unreliable data from unknowns.
Sadly, there are people out there who like to disrupt "for the lulz" as they like to say. It is misguided to think that transmitting systems can be secured so well that nobody can make transmitters broadcast false data. However, even if that is somehow possible, people can take perfectly secured and functioning equipment out of junk cars and place it on a bridge. The result would be a transponder correctly announcing it is stopped at the coordinates of the bridge. To other vehicles that will look like a stalled car under the bridge, since altitude measurements from GPS are not accurate enough.
Such a true but misleading signal would cause cars to give out warnings, or in some cases even brake for the ghost car. This is just one such attack which would involve misleading information. As such, developers will prefer to trust their sensors.
Design of secure systems is, to put it mildly, extremely difficult. Security researchers accept this, and thus feel that one good strategy is simply to not accept communication from parties unless you need to. The "gold standard" -- though far from perfect -- is known as "air gapping," and it means having no network connections at all. In many ways, to keep a computer secure, you teach it the same thing you teach young children, "don't talk to strangers."
Because robocars must have some connectivity, they can't quite be air gapped. However, a wise strategy will be for them to communicate with as few other parties as possible, and to only communicate if there is a very compelling reason.
As such, it is possible the typical robocar will communicate only with the trusted servers at its HQ, and it will do so in a limited manner, and if smart it will be paranoid even about the signed and authenticated messages it receives from its own owner or maker.
The DSRC use cases are simply not very compelling. As long as this is true, the security risk of opening another "attack surface" by receiving messages from random other cars encountered on the road, or roadside equipment, is simply too high to do it just for the minor benefits DSRC messages might provide.
This is compounded by the fact that the DSRC messages are intended for the systems in the car that control all the safety critical driving functions. It is one thing if the infotainment system listens to random signals. It is another if the steering or braking system does.
Perhaps with great effort, we can build a protocol and security tools to improve the safety of receiving these messages. Make no mistake, that is a major task. As the complexity of the messages increases, many would say it is an unsolved problem. Because intrusion into the driving systems can turn a car into a 1500kg weapon, this is not a risk to be taken lightly. You do not wish to open up a new attack surface to get messages that might prevent only a small number of accidents.
Instead, a logical approach is to let most of those messages -- including messages about things like stalled cars, road hazards and even red light runners -- be sent to servers designed to rebroadcast them with low latency. Let the servers scrub and simplify the data before sending it to cars that trust them.
Other commentaries will point out the difficulty of securing any direct portal into the driving systems, but they don't go far enough. We must judge that security risk against the modest benefits that come from the DSRC messages. In the early days of the proposed deployment of DSRC, those benefits are even less, simply because only a small fraction of cars will transmit those messages.
It is thus a serious suggestion that if a robocar comes with DSRC, the purchaser should disconnect it until such time as DSRC deployment becomes so widespread as to actually be useful. This means at least 50% deployment, which does not occur until the late 2020s on proposed time-lines. By which time it seems DSRC might be obsolete for other reasons.
There are a few alternatives to V2V which exist or have been proposed.
5G and beyond
The mobile data providers have many powerful features planned for 5G. This includes the ability to do sub-millisecond latency communication between radios talking to the same towers, or even competing towers in the same area. Signals may simply go from car to tower to car without going through the larger network. This allows close to zero latency, and also has far more range, because the towers are up high and cover more territory. Vehicles can talk as long as they can reach a tower, even if they have no line of site or reflected path between them, regardless of distance.
The main downside is that this infrastructure is not everywhere, and belongs to mobile data carriers and thus depends on them (and may mean they demand fees.) However, it is so superior, those risks seem minor.
Also planned for 5G are guaranteed service levels and network virtualization to isolate communications from other network activity.
Car to Server (Cloud)
The existing 3G/4G mobile data networks and internet infrastructure are already in wide use. They offer the virtues and problems of using cell towers, but they can mean varying latency. While it is common for local traffic within a city to travel with latency of 100ms or less when using servers designed for low latency -- voice calls become unacceptable at a 200ms round trip time after all -- there are certainly times when it is longer. This approach makes up for that with the huge advantage that it is already there. Many new cars come with mobile data systems for telematics, and have done so for many years. Almost all new cars plan something of this sort, or can do it by tying a phone to the car.
Phone to Phone
Before the end of this decade, smartphone penetration will be very high in the USA. Well over 90% of cars will have a mobile data equipped smartphone in them as they travel according to typical analyst forecasts. Most will be plugged in to charging and many will be running a driving app, such as navigation.
Phones, however, go through a complete redesign every 2 years. This is vastly faster than anything else in the world. The functionality of the 2020 smartphone is yet to be designed. It could be considered, for example, that the DSRC spectrum could be offered to handset makers if they implement some sort of phone-in-car to phone-in-car protocol for them to use when they notice they are in a car. Within a few years of approval of such a plan, a large fraction of cars would be speaking this protocol. In addition, the hardware and software for that would be updated on a very regular basis. (This is unlike DSRC radios in cars which, if released in 2020, might well continue to drive the roads with that version for 15 to 20 years to come, if not longer. With the protocol having been designed in the 2000s, one has to wonder how many people are still using 25 year old cell phones.)
If this were done, cars might relegate themselves to simply assuring better signal for these phones, by implementing analog relays in the specified bands, or having a means for a phone connected via USB to use a repeater to an external antenna. The hardware in the car would be kept very simple because it has to last a decade. The phone hardware would follow the accelerated path of phones.
An ATSC-M channel
Another technology not exploited is that used for digital television broadcasting. The ATSC protocol provides 19 megabits of bandwidth per channel with penetration into canyons and vehicles. Receivers are mass produced for TVs and very low cost. The mobile version of the protocol is designed for use in moving vehicles. In reality, however, broadcast TV is dying and being supplanted by cable, satellite and internet.
It could be worth exploring the use of a digital channel in every city which would be able to transmit to every car. It would transmit any traffic signal timings or other infrastructure information. It would transmit map updates and traffic info. It would transmit about any detected road hazards, including stalled cars and cars detected running traffic lights. 19 megabits is more than enough for all this information and then some. There would be room for transmission about the presence of all cars that are in risky situations, such as places where they might be occluded by buildings or around blind corners.
Information from RSEs and cars would travel to the server for inclusion in that stream over the mobile data networks or other networks. (Traffic signal timings would probably come from the city's central light control centers if available there.) Signals over the mobile data network, if given priority, particularly in the 5G world, would reach the transmit time in under 100ms. This would be adequate for almost all safety applications, as well as non-safety ones.
Low Latency is Rarely Needed
As discussed above, one of the few advantages of a direct protocol is the ability to have extremely low latency, counted in milliseconds or sub-milliseconds. There are certain applications where such latency is valuable, such as in platooning, where vehicles follow closely behind one another.
Many of the other planned applications work well with latencies of 10 to 100 milliseconds. Such latencies are not guaranteed on the general internet, but they could be within modified mobile networks and are available in most 5G plans. Indeed, even on the general internet, latencies in these ranges are commonly delivered.
Some may question whether a system which "usually" delivers low latency but is occasionally slower could be considered for safety applications. In fact, all proposed approaches, including DSRC, do not work in all situations. DSRC packets will fail to transmit due to noise, lack of line of sight, and other problems, but the most common reason they will fail is low deployment. A system present in 50% of cars that works 100% of the time is still inferior to a system deployed in 90% of cars which has high latency 10% of the time. DSRC will be well behind mobile data network deployment for at least 1-2 decades, and it may never catch up. Certainly, by the time it catches up, the mobile data networks will offer sufficiently low latency.
As noted, many of the DSRC applications work perfectly well with latencies above 100ms, or in fact with multi second latencies. These include things like reports of problems down the road (such as stalled car notifications,) upcoming changes to the state of traffic signals and even detection of vehicles running red traffic lights.
My colleagues at the Electronic Frontier Foundation and others are preparing reports on some of the privacy concerns. While the DSRC design teams are attempting to protect privacy in their designs, the hard reality is that this is much harder than expected, and privacy holes in designs are often only revealed after deployment. DSRC is not a protocol that is robust to dynamic problems. Making changes to the protocol after deployment is going to be challenging, since many vehicles will come with radios that can't do easy firmware upgrades, and hardware upgrades will be even more difficult. This is in contrast with software on general purpose devices like computers and phones, where software updates are frequent, and problems can be fixed and solutions widely deployed in short times.
The privacy concerns should be examined in contrast with the minimal benefits that DSRC offers over other alternatives. It should be noted that many of the other alternatives will also face privacy concerns of their own. Their only advantage will be the ability to fix those problems more quickly.