V2V vs. the paths to a successful networked technology (Part 1)


A few weeks ago, in my article on myths I wrote why the development of "vehicle to vehicle" (V2V) communications was mostly orthogonal to that of robocars. That's very far from the view of many authors, and most of those in the ITS community. I remain puzzled by the V2V plan and how it might actually come to fruition. Because there is some actual value in V2V, and we would like to see that value realized in the future, I am afraid that the current strategy will not work out and thus misdirect a lot of resources.

This is particularly apropos because recently, the FCC issued an NPRM saying it wants to open up the DSRC band at 5.9ghz that was meant for V2V for unlicenced wifi-style use. This has been anticipated for some time, but the ITS community is concerned about losing the band it received in the late 90s but has yet to use in anything but experiments. The demand for new unlicenced spectrum is quite appropriately very large -- the opening up of 2.4gz decades ago generated the greatest period of innovation in the history of radio -- and the V2V community has a daunting task resisting it.

In this series I will examine where V2V approaches went wrong and what they might do to still attain their goals.

I want to begin by examining what it takes to make a successful cooperative technology. History has many stories of cooperative technologies (either peer-to-peer or using central relays) that grew, some of which managed to do so in spite of appearing to need a critical mass of users before they were useful.

Consider the rise and fall of fax (or for that matter, the telephone itself.) For a lot of us, we did not get a fax machine until it was clear that lots of people had fax machines, and we were routinely having people ask us to send or receive faxes. But somebody had to buy the first fax machine, in fact others had to buy the first million fax machines before this could start happening.

This was not a problem because while one fax machine is useless, two are quite useful to a company with a branch office. Fax started with pairs of small networks of machines, and one day two companies noticed they both had fax and started communicating inter-company instead of intra-company.

So we see rule one: The technology has to have strong value to the first purchaser. Use by a small number of people (though not necessarily just one) needs to be able to financially justify itself. This can be a high-cost, high-value "early adopter" value but it must be real.

This was true for fax, e-mail, phone and many other systems, but a second principle has applied in many of the historical cases. Most, but not all systems were able to build themselves on top of an underlying layer that already existed for other reasons. Fax came on top of the telephone. E-mail on top of the phone and later the internet. Skype was on top of the internet and PCs. The underlying system allowed it to be possible for two people to adopt a technology which was useful to just those two, and the two people could be anywhere. Any two offices could get a fax or an e-mail system and communicate, only the ordinary phone was needed.

The ordinary phone had it much harder. To join the phone network in the early days you had to go out and string physical wires. But anybody could still do it, and once they did it, they got the full value they were paying for. They didn't pay for phone wires in the hope that others would some day also pay for wires and they could talk to them -- they found enough value calling the people already on that network.

Social networks are also interesting. There is a strong critical mass factor there. But with social networks, they are useful to a small group of friends who join. It is not necessary that other people's social groups join, not at first. And they have the advantage of viral spreading -- the existing infrastructure of e-mail allows one person to invite all their friends to join in.

Enter Car V2V

Car V2V doesn't satisfy these rules. There is no value for the first person to install a V2V radio, and very tiny value for the first thousands of people. An experiment is going on in Ann Arbor with 3,000 vehicles, all belonging to people who work in the same area, and another experiment in Europe will equip several hundred vehicles. With V2V you can't simply get a group of cooperators together and get much value. V2V only works with the cars that happen to be around you at any given instant. Unlike Fax or E-mail, where you could pick a partner anywhere in the world and start using the tool with them, you don't pick the cars that are around you. The Ann Arbor test is trying to get around that by using a group of people who work together. In their case, there is a decent chance, particularly during rush hour, that they will encounter other users, particularly close to the workplace but also on the common commute routes. This will create some V2V encounters that will be learned from.

But in the real world? As I noted, even if 2.5 million US cars had V2V, and you are one of them, only one in 100 of the cars you encounter will be able to talk to you. And the odds that any 2 random cars who might have a collision would have it are 1 in 10,000 -- close to valueless as a collision reducer.

So if a cooperating technology does nothing even for the first million to buy it, it can never take off without a legal mandate. And a legal mandate is exactly what the ITS community seeks, hopefully using the Ann Arbor demonstration as evidence it should be done. That means every new car would be required to have such a radio in it (currently expected to cost $100 or so.) That's $1.5B per year in added expenses, though hopefully the price of the radios and associated gear drops with time. Once installed into all 250M US cars that's $25B at $100 but probably closer to $10B as it gets cheaper.

In order to get a legal mandate, it's necessary to demonstrate a compelling safety case. If V2V could prevent all blind intersection accidents -- which would be only after it reached very high penetration some decades from now -- that might be as many as 2,000 lives/year, so about $750K per life which is a quite reasonable value. But this is a big if. First, there are a lot of other ways to prevent those accidents, and that includes not just robocars but more advanced sensors in human driven cars and traffic lights.

Sensors on the cars don't have the network problem. If you buy a collision warning or braking system for your car, it provides value for you today. While it can't see a hidden car running a red light around a blind corner, it can brake for you (and the other car might have such braking too) and reduce the severity of the incident. And of course it will work in many other incidents.

I often quote what I call the first law of robocars "don't change the infrastructure." Mandating radios in everybody else's car is a huge infrastructure change, but there's another type of infrastructure change that might make sense here, namely sensors at intersections. Cameras are getting cheap and the cost of this could come down to be a tiny part of the cost of an intersection. An intersection camera that can detect somebody running a red light is able to make the light red-in-all-directions, and that benefits everybody in every car using that intersection from day one, not just cars that have installed new equipment. (Naturally the intersections could also transmit the alert over radio for cars that have got a radio.)

There are over 500,000 signalized intersections in the USA, so adding such sensors to all of them is also a multi-billion dollar project, though it's pretty reasonable if it's done during upgrades and new installs. While there are lots of intersections, the number of dangerous intersections with blind corners and a history of fatalities from intersection crashes is actually fairly small. All signals have an interface for the "conflict monitor" which prevents double-green. This interface can be used to turn the signal to all-flashing-red.

As a result, you meet that very important criteria I named above. You get value on your very first install of an intersection safety system. Value for all users of the intersection. Perhaps a mandate will speed things up, but in this case the cities buying more expensive traffic signal equipment due to the mandate would not resent paying money to get no present day value.

But it goes beyond this. If intersections start transmitting useful data -- not just safety warnings about people running lights, but simple reports on when the lights plan to change -- there is now an incentive for the people who use these intersections to want to get V2V/I2V radios in their cars. Not to talk to the few other cars out there, but to hear from the traffic lights. With this information they can time their arrival at lights to avoid stopping at reds. This produces a more comfortable ride and saves quite a lot of fuel in city driving. (This application can also be done over the wide-area cellular networks because it does not require low latency.)

Consider the following offering from some fraction of the traffic lights on your regular drives:

  • They will send you an electronic warning if somebody is running the light in the other direction, which your car can use to hit the brakes for you even before you see the red light.
  • They will tell you in advance when they will turn, so you can reduce speed rather than racing up to red lights and then breeze through.
  • As a result, your car will also warn you or hit the brakes if you are about to run the red light.
  • You can tell them you are coming, before they detect you, so that they can change ahead of time for you during low-traffic periods. (Right now you have to drive onto their buried loop sensor and wait for the light to change.) Even when they can see you they don't know you're turning until you get there.

While such sensors previously would have been considered expensive additions, it turns out that all the hardware needed for such functionality can be found in the old smartphones we are today throwing away by the millions. These contain cameras, processors, radios and run on low power. Because they are not designed for outdoor use, I am not suggesting we just glue a phone to the traffic lights. What this does mean is such sensors could be built at a low price from cheap, off-the-shelf parts. Even after the 10x increase in price that comes from government contractors, they would still be cheap.

This is just one basic alternate plan. However, a plan I think is even better, which involves embracing the opening of the spectrum and the use of the hundreds of millions of phones and other devices which would quickly have radios that work in that spectrum, comes in part two -- putting V2V into the mobile phone. Also look at part three -- using broadcast data.


Interoperability concerns, between legacy automobiles with human drivers, existing infrastructure, road markings and other furniture, and "robocars", suggest that your automated vehicles are going to have to be able to optically read existing traffic signals and road signs. Indeed, we're already seeing optical systems that go beyond follow-distance and LDW and are reading road signs to give you speed limit warnings.

Further, if you start to equip every traffic signal with some sort of transponder broadcasting its state, nobody's going to notice when it fails. At least not in the first decade of deployment. Whereas when a light fails, everyone can see.

So it seems to me that the right solution to this issue is to have signals transmit their state information optically. Yeah, with a standard 60Hz camera there's not a lot of bandwidth to pass data that humans aren't aware of, but it's conceivable that you could use higher refresh rate cameras to sense the road and signal data, or that you just encode this information in additional lights in a way that humans could interpret the information as well.

Yes, I have considered optical signals and they do make some sense. At least with LED lights, which is what you get after any signal retrofit.

As noted, you either need a camera to find the light (which is not a high frame rate) or you have a more general sensor which can read higher speed data. You want every light to transmit its ID as well as its state, so you need a decent but not very high data rate. You want enough so that it's not easy to forge a signal.

General design would be fail-safe. Ie. systems advise stopping in the absence of a green where one is expected. Red doesn't even really matter, what matters is you don't go (or proceed with caution) if you did not get a green.

All traffic lights today use a "conflict monitor" circuit which is independent of the light's main systems. This circuit detects any instance of green in both directions, and sends an override to the light which turns it to all red or flashing red. Here the monitor would also need to look at the transmitted codes. Though one simple safety is to have the green light transmit green codes and the red light transmit red codes. The receivers, looking for the correct frequency of light, could never physically see a green code from a red light. You don't see the green code, transmitted with green light, you don't go.

Of course in some streets you will get multiple lights in view, including the next intersection a short distance away, views of the cross-intersection light, and of course multiple lights at the same intersection (left and right arrows etc.) So it's physically possible for a light to transmit a code different from its visible purpose to humans (ie. a left arrow light might somehow transmit a "green to go straight" code) but it seems like it should be possible to make that extremely unlikely.

As noted though, a lot of this can also be done over WANs -- most signals change with a few seconds of advance notice. Only emergency all-red needs super low latency.

In order to get any traction, the system will have to detect and read legacy traffic lights anyway. So the signal you want to put on top of the light state includes stuff like timing and vehicle coordination information, and you can leave the position and identification issues to the location of the light. Which the vehicle is already sensing.

There's some potential issue with security, spoofed signals and whatnot, but the vehicles have to be failsafe in the absence of light or in the cases of interoperation with human piloted vehicles, so operating safety margins still need to be maintained.

Robocars must see all lights. (Well, sort of. They mainly just follow the rule of not going if you don't see green. If you can't figure out the light you ask the occupant for help, which gets you honked at if you are first in line, probably.)

However, for just reducing red light running, it is not necessary the system work in all cases. The more lights it works on, the more chance it has to warn you if you are running a red, or if somebody else is running one.

In theory V2V does this without seeing the light. It just warns both of you if you both are approaching the intersection and neither is slowing down, regardless of what the light says. You would expect after this alert people would hit the brakes and double-check the light. It would probably alert you if you do that thing where you zoom up to a light watching the hand signals or opposite direction, knowing it will change. Though lights are getting longer inter-green gaps to reduce the risk from that.

Knowing the timing actually makes it more likely you would pull that trick, though the prime value is to slow you down so you don't waste your time and fuel at red lights.

The V2V community plans to have their systems work on their own, ie. no other sensors in the car. That's probably a poor assumption given what will be available later in this decade when V2V deployment would begin.

Yeah, I think we're in violent agreement. The thing about V2V is that any system which takes advantage of it has to work in the absence of V2V, and thus if it fails, nobody will know. Things will just work slightly less efficiently (and even that's not clear, I have yet to read the "here's the awesome collaborative improvement that V2V will enable, and for all of the reasons we've enumerated, V2V safety isn't a real thing).

So if you spend an extra thousand bucks to put a *2V capable transponder on something, you either have to also have ongoing protocols to test that it's still working, or you have to accept that some portion of your transmitters are going to fail and you'll never know that they did. If those transmitters work through mechanisms humans can detect, there's a chance they'll continue to work, otherwise they're just dead silicon.

While the DSRC test radios are expensive, at quantity I expect them to become cheaper, in the $100 range, but that's still a lot for a car add-on.

One of my key disagreements is based on the realization that V2V will never be a reliable system. It will fail most often because the other car simple doesn't have V2V at all. Once you accept it as unreliable, you can focus on other than trying to make it work perfectly for those cases when both people have it, and find it more valuable to have it work less reliably but in more situations. Legal liability can play a role here, you don't want to be blamed for an accident.

I agree that V2I is the way to go. Seems you would need driverless cars to really take advantage of it though.

I think the problem with the vision for V2V is that everyone expects it to only be useful if it does the complete suite of V2V potential communication. There is another way...

I was in Florida vacationing with my family, and I used Waze (social GPS) as my GPS system. Now clearly this is about as crude a V2V system as possible (and even calling it V2V is probably a stretch,) it essentially sends traffic updates/location and speed to a central server, and the clients then get that information back from the server to make better decisions. By using Waze to plan my trips, I didn't see a whole lot of heavy traffic - and I know it's because waze was routing me around traffic, since going to the same place on subsequent days, it guided me via different routes.

I would hesitate to guess what percentage of drivers in the area were using Waze, but it was probably well less than 1%, and the value was certainly there.

If a group of automakers put similar functionality into their onboard GPS systems, you've got that foot in the door. There's value to people fairly early on in the adoption scale, and as an automaker, it's a feature that you can sell. Once you've got vehicles communicating simple stuff like that, you can gradually start sending out more and more information to make different decisions better. It's going to be a long road though.

Anyway - I don't think that V2V is going to be the be all and end all of autonomous cars, but I certainly see a future where it helps make the roads safer for everyone.

Yes, Waze works. It started providing you just nav and imported traffic, providing value, and so people used it and now they have enough users they can get traffic data from them.

Waze is not V2V though, it all goes through the server. So every user can talk to every user. It does not require the combination of the random encounter and the deployment that V2V does.

Even the ITS people know this. They see V2V as aimed at very low latency, collision prevention. They feel sending the signal to the server and getting it back takes too long when milliseconds can make a difference. This is true -- but at what cost? Relaying actually had advantages in that it can relay around blind corners that 5.9ghz doesn't. But it adds latency and the reliability of the relay. V2V is based on a pure concept, which is good, but it has the network problem I describe above.

It's interesting that there is no mention of bicycles and pedestrians in this piece. They are the ones that need their safety protected.

The V2V standards did not expect non-cars to do V2V, though there were a number of proposals for units that might be carried by people who cared a lot, including children, seniors, people in wheelchairs etc.

There are problems though -- such road users do not have a power source the way cars do so an always transmitting radio eats up a bunch of battery. And even though you could legally mandate all cars to have a transmitter and eventually most of them would have one, you could not easily do that for pedestrians.

What about stop signs? Are we saying that robocars can only operate on roads with traffic lights? (Or did I miss something?)

P.S. An electronic traffic light system would be a good intermediate step before full robocars. (Robo-assisted driving?) I'd love to know the color of the upcoming light despite the sun blazing in my eyes, or the huge truck blocking my vision.

It would also (possibly) get traffic flowing earlier, instead of everyone inchworming their way up, one by one, when the light turns green. (One of my many driving-related pet peeves...).

Everybody stops at the line, and there they can see the cross traffic, including, if they look out, people running the stop sign. Well, a lot of the time. At traffic lights, you might find yourself going through a green light at high speed, unable until too late to see somebody blowing through the red light of cross traffic.

At a non-all-way stop, you can have a problem but usually people don't miss those.

But yes, things can be done at stop signs of value, though they tend to be small volume intersections with lower accident rates.

A robocar world would work even better in a traffic-circle world. (well, traffic-circles IME work better than traffic lights anyway)

Quite probably, though one challenge is that traffic circles are uncomfortable for passengers. I think there are ways to fix that with passenger compartments which can tilt. Still not the comfort of going in a straight line and being timed to never hit red lights, even if the circles are more efficient. (They also take more land of course.)

First, I just can't imagine you would only care about V2V crash notifications (e.g. 'hey, I am about to crash into you LOLZ.') and you would want to just know all threats including walls, barriers, pot holes, etc. This requires each car to be good at its own sensors, monitoring and re/action planning.

Second, I love the idea of red-lights or other infrastructure being the first step rather than vehicles.

Do they need to worry about V2V in that case though? Why not have a network of lights that report back to some shared infrastructure. In fact, they could piggy back on the cameras that use internet to send tickets and/or feeds.

If you had this in some machine readable format then any service (including Waze, who I work for) could take advantage of it as they see fit. It could be a traffic monitoring application, roadway optimization application, public watchdog, in-car operation for automated driving, etc.

I am not sure that the low latency issue is one that can/should be solved this way other than different management techniques by the light itself...

The main argument put forward for V2V is that low latency short range communications could help prevent a large number of accidents by warning drivers of dangerous situations. However, some of the numbers I have seen in this area include the situations where warnings could also be given by radar or cameras or other sensors.

As those sensors become cheaper -- and they are valuable to the first customer to buy them, people already buy them -- the question is what accidents can be prevented with V2V that are not detected by sensors.

These are:

  • Cross traffic at blind corners, in particular somebody is running a red light. You can alert the person running the light and those who are about to go through the green.
  • Hidden vehicles: A vehicle is stalled on the road ahead. You're following a minivan and can't see it. The van veers left coming up to it and you are surprised and can't react in time. V2V warns you. This requires highly accurate knowledge of what lane the stalled car and your car are in.
  • Other occluded traffic, in particular coming in from the sides at stop signs. Lower cost sensors like cameras and radars usually only point forward, though at they come down in price they will widen their view.

Robocars would also want to know about all these, and in fact robocars will always find it handy to have a second confirmation of what their sensors are telling them, or a warnign about something their sensors might be missing.

Add new comment