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. This has not happened, and in fact the FCC has no proposed converting the spectrum for unlicenced WiFi style use.

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. Large groups of people say 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.

More recently, a counter-proposal to DSRC has come from Qualcomm and the mobile operators. It is called C-V2X. This protocol offers both a peer-to-peer form, very similar to DSRC but more modern, and a version using cell towers for relays. It is superior, but does not solve many of the key problems outlined below.

A common phrase in the community to promote the idea is "Connected Autonomous Vehicles." I say "Connected Autonomous Vehicles -- Pick 2."

Executive Summary

It can't be very valuable to robocars

For robocars, which must already fully detect everything in their world and surpass the high bar called "safe enough" without any V2V data, the most that V2V can ever do is move the safety needle a little in the short distance between "safe enough" and "nearly perfect." By definition, that distance must be short, so V2V can't ever be that valuable.

It won't be that valuable to human driven vehicles

The immense investment in robocars will pay a dividend in low cost sensors and other tools which regular human-driven cars are already using. This will make them safer without requiring other vehicles to install V2V transponders. It won't do absolutely everything V2V does for safety, but it will do a very large fraction.

Deployment has a critical chicken-and-egg problem

V2V technologies won't get any deployment without being legally mandated. Even with the proposed legal mandate requiring the technology in all new cars starting in the early 2020s, it will be 2030 before deployment is wide enough to gain even the limited utility offered above. But by 2030 it will be a 25 year old communications technology as obsolete as your 20 year old cell phone.

It creates a serious security risk

Securing the driving systems of cars is a difficult and vital computer security challenge. All security professionals will advise that a good first step is to limit who your system communicates with. Like young children, you teach them "don't talk to strangers." V2V communications, demanding regular interactions with random unknown parties, open new "attack surfaces" which make the security problem harder. Generally, such openings should only be made when there is a very compelling value proposition worth that risk.

It will not be that dependable

In addition to security against active attackers, information from random parties over DSRC may be inaccurate (you don't know how reliable the data from other cars is) or even worse, trying to mislead you. Consider disruptive attackers known as "griefers" trying to jam traffic with the illusion of cars stalled in the road. Members of the DSRC committee have expressed the belief that they will produce a working PKI (public key infrastructure) system for cars, when their internet colleagues still have not done it with much higher incentives and better tools for the last 30 years.

It is inferior to alternatives

Alternatives now exist and continue to be developed for all V2V technologies, and to the specific DSRC protocols, which are superior, more modern, more reliable and already being deployed for other reasons. Most notable are the coming 5G technologies from cell vendors, and communications that go from cars to servers over the mobile data networks, and thus from car to server to car when that is valuable and available.

As noted above, DSRC's design is already old by the standards of digital technology, and while there are efforts to refine it, once it is deployed in cars, the old vehicles will speak the legacy protocol for decades. Because phones are replaced every 2 years, their hardware goes through generations much faster.

Low latency applications are surprisingly rare

With these alternatives present, DSRC presents value only in some very rare and limited situations where super low latency is a must. The alternatives are also developing their own low latency approaches. While the value of the low-latency DSRC applications is not zero, it is not very large.

It creates serious privacy concerns

There are privacy implications to the plan of having all cars transmit their locations at all times along with a certificate chain to authenticate the equipment. The DSRC specs require that cars regularly change their identity tokens as they drive the road to avoid correlation and tracking of individual vehicles, but keeping anonymity in these situations has historically been shown to be extremely challenging.

Its cost is high, and those resources could be much better spent

V2V does not come without cost. Early estimates suggested $100 per vehicle, though certainly that will drop with time. But even at $20 added to the cost of each vehicle, doing a 250 million cars means $5B spent at the wholesale level and $20B or more at the retail level. Unless it is estimated to save thousands of lives that would not be better saved through other methods it is a low priority choice.

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 kick-started 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.

1. The application must demand very low latencies, under a hundred milliseconds. Otherwise, V2Cloud will be able to perform the function with vastly greater success rates because of its very wide deployment. A technology that is not even present in the car is 0% reliable, so it is far better to use a 90% reliable technology present in 90% of cars than a 99% reliable technology present in 20% of cars.
2. The application must need only communication between cars roughly in line-of-sight and relatively close proximity. Otherwise V2Cloud, with its ability to work regardless of distance or line of sight will have significantly greater efficacy.
3. The application might need to work in the absence of public data networks. There are dark spots on those networks, though they are expected to be close to nil by the 2020s and certainly by 2030. Note again that an application which works everywhere for 20% of cars is still greatly less effective than one that works on 95% of roads for 90% of vehicles. (In addition, the areas without cell towers tend to be sparse areas with low traffic and risk.)
4. The application must work with vehicles that can't be detected by on-vehicle sensors such as LIDAR, radar or cameras. The sensors are necessary since some vehicles, most pedestrians and cyclists and all deer will not have transponders.
5. The application might make use of information sensors can't determine, like the use of brakes or turn signals by a vehicle where those indicators can't be seen, or changes in speed in convoy.
6. Applications dedicated to underground locations like parking lots which do not have public data network access.

With these criteria in mind, the following applications can make use of V2V

• The detection of surprise actions by "occluded" vehicles which can't be detected by on-board sensors. (In particular, braking by a car hidden from view by a larger vehicle in between you and that car.)
• The creation of platoons where vehicles follow one another with very short headways in order to save fuel.
• Specialized car cooperation activities in the event of a dangerous situation. (For example, cars cooperating over how to react to an out of control vehicle.)

Notably, several popularly proposed applications are not on the list of compelling reasons for V2V:

• Detection of vehicles hidden from you by trucks and SUVs in front of you -- radar sees these vehicles if there is a radio path to them.
• Awareness of stalled vehicles in the road or on the side of the road -- cloud services can be aware of this and report it within a few hundred milliseconds of the stall. The marginal gain from knowing it 10 milliseconds after the stall is insignificant.
• Vehicles attempting to run red lights -- this is far better detected by inexpensive neural network based camera systems on traffic lights, which have a better and faster vantage point, and which can then tell the light to turn all-red, protecting everybody, not just people with V2V equipped cars, from the potential accident. Cars with data connections can learn more about what the camera saw.
• Vehicle to Infrastructure communications, which are better done by having infrastructure talk to the cloud, and then down to the cars.
• Traffic signal timing information, because changes in timing are known in advance, long latencies on issue reports of upcoming signal changes are entirely acceptable.
• Detection of other vehicles and obstacles on the road which are not occluded from sensors. New generations of low cost sensors provide a far better solution, since they detect all obstacles, not just those with transponders.

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 at least a decade 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 is an important, but simple equation when evaluating the safety potential of any safety technology that hopes to prevent accidents by knowing where other road users are. You must multiply:

1. The probability that your Vehicle has the technology. (ie. what fraction of cars have it) 2. The probability that the other vehicle or road user has it. 3. How reliably it detects information about the other party

Numbers 1 and 2 mean the power of the technology goes as the square of the market penetration. If 20% of road users (50 million) have transponders, then 4% (20% times 20%) of safety incidents will be detected if the technology works perfectly. Sensors don't have that squaring problem. If 20% of cars have sensors, and they do the job 80% of the time, we get 16% of safety incidents. A car safety application in smartphones might only work 70% of the time due to their bad placement in cars, but if 90% of cars have smartphones -- as they do -- the technology works in 90% times 90% times 70% or 57% of incidents -- much better than 4% or 16%.

There are multiple levels of security risk

Other comments will address the many security concerns. There are three broad problems.

1. The data comes from untrusted sources, namely cars you didn't make using systems and sensors you had no control over. It may not be accurate. You are reluctant to make safety decisions based on data from unknown and untrusted sources.
2. The other source may be deliberately misleading you. For example, it might be from "griefers" who just want to publish false data to cause traffic jams or other disruptions.
3. The messages from other parties may be actively trying to attack you, performing computer intrusions through the additional "attack surface" opened by accepting messages from a large array of unknown parties. It's almost akin to being a web server on the open internet.

Here are more details:

Unreliable data

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.

Misleading data

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.

Attack messages

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.

C-V2X

C-V2X comes in two forms. One is almost identical in use to DSRC, in that it works peer to peer between vehicles with no cell towers involved. It uses the exact same messages that are planned for DSRC. It has some technical advantages, being more modern in design, but everything said about DSRC applies to this mode.

The other mode works when cell towers are present. This mode provides more robust delivery of signals Two cars can communicate even if they can't talk directly by radio, relaying through the cell tower. That's good, but again the messages and approaches are the save as DSRC.

C-V2X uses LTE based radio technologies and chips rather than WiFi based. This has some modest advantages. The real advantage comes when the vehicles talk not to other vehicles, but to servers in the cloud, which they will do using these cell towers. C-V2X (and other 5G technologies) can make Car to Cloud to Car messages very low latency as well, and more reliable, as outlined below. C-V2X wants to operate in the 5.9ghz band but can use any of the LTE bands, but needs permission from and presumably payment to the "owners" of these bands (cellular carriers.)

The Alternatives

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.

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 are acceptable.

Such protocols (as well as the relaying modes of C-V2X) won't work away from the mobile data networks, in other words, rural areas. However, areas without cell phone coverage are shrinking, and they tend to be areas of low traffic, few intersections, and few places where V2V communication could prevent many safety incidents that sensors don't do better on.

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 Roadway Safety

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.

Privacy concerns

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.