US push to mandate V2V radios -- is it a good choice?

Topic: 
Tags: 

It was revealed earlier this month that NHTSA wishes to mandate vehicle to vehicle radios in all cars. I have written extensively on the issues around this and regular readers will know I am a skeptic of this plan. This is not to say that I don't think that V2V would not be useful for robocars and regular cars. Rather, I believe that its benefits are marginal when it comes to the real problems, and for the amount of money that must be spent, there are better ways to spend it. In addition, I think that similar technology can and will evolve organically, without a government mandate, or with a very minimal one. Indeed, I think that technology produced without a mandate or pre-set standards will actually be superior, cheaper and be deployed far more quickly than the proposed approach.

The new radio protocol, known as DSRC, is a point-to-point wifi style radio protocol for cars and roadside equipment. There are many applications. Some are "V2V" which means cars report what they are doing to other cars. This includes reporting one's position tracklog and speed, as well as events like hitting the brakes or flashing a turn signal. Cars can use this to track where other cars are, and warn of potential collisions, even with cars you can't see directly. Infrastructure can use it to measure traffic.

The second class of applications are "V2I" which means a car talks to the road. This can be used to know traffic light states and timings, get warnings of construction zones and hazards, implement tolling and congestion charging, and measure traffic.

This will be accomplished by installing a V2V module in every new car which includes the radio, a connection to car information and GPS data. This needs to be tamper-proof, sealed equipment and must have digital certificates to prove to other cars it is authentic and generated only by authorized equipment.

Robocars will of course use it. Any extra data is good, and the cost of integrating this into a robocar is comparatively small. The questions revolve around its use in ordinary cars. Robocars, however, can never rely on it. They must be be fully safe enough based on just their sensors, since you can't expect every car, child or deer to have a transponder, ever.

One issue of concern is the timeline for this technology, which will look something like this:

  1. If they're lucky, NHTSA will get this mandate in 2015, and stop the FCC from reclaiming the currently allocated spectrum.
  2. Car designers will start designing the tech into new models, however they will not ship until the 2019 or 2020 model years.
  3. By 2022, the 2015 designed technology will be seriously obsolete, and new standards will be written, which will ship in 2027.
  4. New cars will come equipped with the technology. About 12 million new cars are sold per year.
  5. By 2030, about half of all cars have the technology, and so it works in 25% of accidents. 3/4 of those will have the obsolete 2015 technology or need a field-upgrade. The rest will have soon to be obsolete 2022 technology. Most cars also have forward collision warning by this point, so V2V is only providing extra information in a tiny fraction of the 25% of accidents.
  6. By 2040 almost all cars have the technology, though most will have older versions. Still, 5-10% of cars do not have the technology unless a mandate demands retrofit. Some cars have the equipment but it is broken.

Because of the quadratic network effect, in 2030 when half of cars have the technology, only 25% of car interactions will be make use of it, since both cars must have it. (The number is, to be fair, somewhat higher as new cars drive more than old cars.)

Forms of Connected Car

There are 3 other ways I have proposed for moving data to and from a car. These are:

  1. The mobile data networks -- 4G today, and some "5G" form in the 2020s. This is already widely deployed in cars (and basic mobile connections are mandated in all cars in some locations for emergency services.) These are very widespread and are being developed without any demand from the automotive sector. In addition, protocols could be established for low-latency "urgent" messages on the mobile data networks, either relayed to other clients or to the global network.
  2. A special stream on an ATSC-M (Digital TV for Mobile) spectrum, allocated from a local TV channel, combined with the mobile data networks which act both as a backup, and a means to send information to the network for broadcast in the stream. This stream would report all traffic signal timings, traffic data and special events seen by cars on the road.
  3. A point-to-point protocol built into cell phones (Ph2Ph,) said phones either simply carried by drivers, or slotted into a standardized holder in the cars. Cell phone generations are less than 2 years, and volumes dwarf car sales, allowing a rapid pattern of innovation. Expect tech in smartphones to be 10-20 years ahead of tech in cars, based on past history.

To contrast DSRC with these other methods, the following factors stand out:

  • DSRC and Ph2Ph offer low latency, the mobile data network offers the risk of high latency.
  • As part of cars, generations are long and the innovation cycle is slow. To match other technologies, the DSRC module must be built so that frequent field replacement is the norm. That's expensive and not usual thinking in the car world.
  • DSRC provides a mostly line-of-sight protocol. The 5.8ghz signals are capable of going around corners and vehicles, but less reliably. ATSC-M is a long-wave protocol that goes through buildings and transmits with very high power. The mobile data protocols are a middle-ground but the infrastructure is so widespread and market forces so strong that it's available everywhere as well.
  • DSRC and Ph2Ph would be able to do V2V even out in rural areas where there is no digital TV or mobile data
  • As a dedicated safety protocol, DSRC is likely to use more reliable equipment
  • The centralized ATSC-M approach fails for everybody if the TV station goes down. This can be mitigated somewhat with backup TV-station availability, as well as use of the mobile data networks as a more expensive backup.
  • The introduction of a low-latency protocol into mobile networks combined with ATSC-M could provide for a broadcast protocol of low latency and high penetration
  • Reworking the 500,000 US signalized intersections for DSRC is a very expensive proposition for which there is no money available. Many traffic signals already report their data back to HQ over mobile data modems with longer latency, and modifying older signals to do this is comparatively inexpensive. DSRC antennas must be put high for line-of-sight, but mobile data modems can be put anywhere there is cell signal.
  • Mobile data equipment is already present in many cars, and will continue to be, and it's also in all phones. ATSC-M is not yet present but as a consumer technology it is quite cheap. Even $150 TV sets have ATSC decoders.
  • Mobile phones can do all the methods. They could do a DSRC-like protocol to cars and other phones. They all have mobile data. Many will also integrate ATSC-M as it becomes available to let you watch TV on your phone.

Unlike the DSRC timeline above, a timeline for Ph2Ph might look like this:

  1. In 2014, the FCC and NHTSA together announce that the DSRC band will be open to unlicenced use, provided all mobile handsets which use it support a Ph2PH protocol
  2. In 2015, phone chip designs start supporting this protocol
  3. In 2017, new smartphones all support the new band and protocol
  4. In 2019, most people have a device supporting the protocol and carry it with them everywhere they drive, walk or bicycle. (Though in the latter cases, battery life restricts use moderately.)
  5. In 2020, 90% of cars are talking Ph2Ph. New versions of the protocols are being deployed and will spread within 2 years. Meanwhile, on the DSRC timeline, the first cars are now being sold with the technology.

It should be noted that without an authenticated GPS in the phone (as tall an order as authenticated V2V,) messages from phones would be informational only and not to be trusted.

Do we need the latency and reliability?

DSRC's main advantages are latency and reliability, but its main disadvantage is non-deployment. So the question becomes, just how important is the low latency.

The answer, surprisingly, is not that much.

  • Traffic signals never change instantaneously. They always know they will change with a few seconds notice, even when doing a change due to an emergency vehicle.
  • Hidden stalled cars are there for many minutes, low latency would only be needed when the car is in the process of stopping. In that case, sensors will reveal this and are a better choice.
  • Hidden cars running red lights (one of the prime applications for DSRC) may still not be detected due to lack of line-of-sight. Cameras on the lights themselves may do a better job (and can turn the light red for all cars, not just those with radios.) The short 100ms latency of DSRC is superior here, but the 500ms latency of a low-latency mobile data plus ATSC protocol is not much different, and even the 2 second latency of mobile data will catch most problems.

Curiously, reliability, while seen as a "motherhood" issue may be a distraction as well. Because DSRC doesn't work at all if the car is not equipped with it, it turns out that a 99.9% reliable system found only in 50% of cars is not as good as a 95% reliable system found in 90% of cars. The latter actually helps in more events.

I think the right answer is to put everything into mobile phones, and start establishing a generalized rough standard for a mobile dock. The mobile dock would be a simple slot featuring wireless charging and a secured data channel to the car to receive information from the car like speed, brake and turn signals. For security reasons, the phone would not be able to control the car (like hit the brakes) but it could give alerts to the driver to do so. The dock could either be in the ceiling (for best antenna visibility) or it could be lower if there is a way to boost the external antenna signal with an analog signal booster that works over all present and likely future bands. This hardware, should it exist, should be modular so it can be replaced as mobile phone and radio standards change, but it would of course include the DSRC bands, wifi bands, mobile bands and ATSC bands.

Will it work?

All this discussion presumes that V2V can be made to work. Unfortuantely, there are still many unresolved issues:

  • DSRC still need to sync up, which can cause latency and range issues, and it is still mostly line-of-sight
  • GPS simply isn't reliable enough to tell what lane a car is in, or if it's on the shoulder or in a lane, or if it's on a bridge or on the road. V2V planners hope to fix that with maps and tracking the history of GPS readings.
  • People might lie to you, so the protocol has to be secured, with a certificate system and a certificate revocation system -- something challenging in a protocol meant to work offline. We have not managed to properly secure TLS on the web in 20 years, so having cars do it is a tall order.
  • Further of that, it is suggested a popular application for a pirate V2V radio would be to tell all cars ahead of you there is an obstacle in their lane, so they all change lanes and get out of your way. (Though some might brake, defeating the purpose.)

So what is it good for?

There are a few applications that make sense, but they aren't always the ones talked about.

  • Some V2I technology is already used for toll collection and for management of congestion charging. Because all cars in Singapore have such a system, you can usually pay at parking lots with it as well.
  • Robocars could eventually use it (decades from now) to cooperate on the road to pack the roads more densely.
  • It has been tested to do cooperative adaptive cruise control, to keep vehicles more in sync.

Comments

This is an absolutely terrible idea. I predict mayhem, property damage, traffic jams, injury, and death if this is put into service.

For this to actually work it would seem to require the protocol participants cooperate, but what if they don't? What compels a car to tell the truth about what it is doing to the other cars around it? Claiming that this will rely on "tamper-proof, sealed equipment" is a hand waving move on a par with "and then a miracle happens".

Indeed, what ensures that one of the participants in the protocol is even a car? A couple of bucks of hardware and a some software hacking and you've got a little box that can cause all kinds of mischief.

I already see lots of folks getting passionate about the privacy angle, but I don't see many commenting on security.

This is indeed an issue. Yes, the plan is to have a tamper-proof module in the car, and a certificate system, and an (as yet unresolved) certificate revocation system for compromised and decommissioned units. And yes, those of us from the security world know how tall an order that is, but the ITS community soldiers on.

Because of this, they say the plan is only to give warnings. You would not have the system hit the brakes for you, but it would warn you that somebody is about to run a red light as you are heading for an intersection, or you're about to turn where somebody is coming around a blind corner. At least it will do that in 20 years when widely deployed. People toying with the system could create ghost vehicles and calls false warnings, and if that happens with high frequency the system is not useful, but to give them credit, while this will happen, I don't think it will be super common.

This is why having your own sensors is better, if more expensive. Your own sensors won't lie to you (though radar can be tricked, it's much harder to trick LIDAR or cameras.) And your own sensors detect all obstacles, not just ones with transponders. However, your own sensors don't detect hidden vehicles.

A common hidden vehicle problem is a vehicle stopped on the roadway. However, that does not require low latency, and can be served through mobile data or broadcast approaches.

Brad,

You sure seem pessimistic about the deployment of V2V. Yes, it might be a while before 90% of the cars have it installed, but I would guess that the software in these modules will be upgradable so that the first cars will simply upgrade to get the newer protocols. Granted if the protocol changes in a way that forces a hardware upgrade, then you're correct, but a little foresight might prevent that.

I'm not sure that an "organic" network would be better. Google and Microsoft (or AT&T and Verizon) would have different networks and applications that are probably not compatible. It seems to me that the players would have to agree on some points to implement this, which is a standard, which would become obsolete and need to be changed.

Will be need to worry about liability if the car broadcasts the wrong information or even broadcasts it too slow? Would we simply let the courts and juries decide these questions?

And I really don't see trust as an issue. I would never worry about someone spoofing a signal to create a wreck or make everyone stop. I would almost worry more about someone wanting to create a lane for himself. Hmmmmm....my car broadcasts "Left lane blocked ahead" just to clear the lane. Just...might...work.

V2V will never work. :-)

Peace,
Randy.

Yes, I think planning for field upgrade is a must. Software upgrade is easy but I think hardware upgrade is also needed. Problem is, nobody is ready to put in a legal mandate for that, so what's the incentive for the car owner to pay for this? Do we make car vendors insist or do the upgrades at service appointments? This is why cell phones are a win, they are upgraded very frequently and no law is required to make it happen.

People hack stuff just for the sake of hacking it. Yes, teens would find it fun to sit by the highway and create a ghost car or traffic jam. But once you get to the level of clearing a lane in front of you or making a traffic signal change, then you have a real risk of people wanting to play with it.

"I would never worry about someone spoofing a signal to create a wreck or make everyone stop."

Meanwhile, in the real world, we have people who use laser pointers to blind airline pilots. Just for kicks.

See, it's great to say "organic evolution will solve this problem!", but you need a regulatory and litigatory envirovnment that supports that. Right now it really seems like regulators are unwilling to just Let Stuff Happen, and if they did, the risk of lawsuits resulting from an accident would be so huge that nobody would want to try. Google is doing it, but nobody is expecting that Google will be doing mass-production of its autonomous vehicles any time soon.

The problem we face when stuff just happens is that most people are surprised by it. Car companies certainly didn't expect that most people would prefer to get their GPS navigation, music, etc. from their phone and not from their car.

The problem I outline here is that mandating it in the cars is not likely to work at all.

But I have proposed (in earlier articles) a clever trick. DSRC owns some valuable spectrum at 5.9ghz. The FCC has issued a letter saying they want that back. The NHTSA mandate request is a counter to that. I have said they should "give" it back on the condition that phones can use it freely but must support a Ph2Ph protocol while on the roads.

(That Ph2Ph protocol might be almost identical to DSRC and certainly compatible with it, but I would suggest it's time for a new generation already.)

I am expecting a bunch of things to "just happen" with high confidence:

  • 90% or more of drivers will soon be carrying a smartphone in the car
  • These phones will include inductive charging
  • The cars will include slots to inductively charge phones, so most phones will be driving when in a car, and those that are not will be able to beep to remind you to put them in the charging slot.
  • Cars will all support bluetooth, both for the radio/music/speakerphone, but also for the basic car data. (This latter one could be useful to mandate, but it's pretty easy to do.)
  • By the 2020s, new cars will all feature forward collision warning systems based on cameras or lasers. I think that will become an NCAP star pretty soon, and like ESC, airbags, etc., become a mandate not long after. FCW is much more effective than V2V.
  • Given the chance to advertise, "Our phone might save your life in certain accident situations," phone makers will jump at the chance, even if the probability of such situations is pretty rare.

" I have said they should “give” it back on the condition that phones can use it freely but must support a Ph2Ph protocol while on the roads."

Wow, so my phone is not only going to continuously track my location and provide it to anyone who requests, but this is going to be sold as a *feature*? That's...an interesting suggestion. I can't really see it going anywhere in a world where people spaz out at the thought that someone might be recording whether they made a phone call (not the content itself, just the fact of the call.)

I will sadly point out your phone is already doing that. At the least, because the V2V community worried about this a little, they designed their protocols so your identity code in the system switches every minute or two, reducing the ability of it to be used for tracking. Your phone, however, is talking with the same ID codes in cellular, wifi and bluetooth everywhere you go, at least for now.

However, if Ph2Ph were put into phones, it would only do its broadcasts, in my view, when you were on the road, something it would generally be able to figure out. (Easy to figure you're driving, a bit harder to figure when you're walking on the road but not impossible. Probably wise to figure out you're on a bus that is already broadcasting and shut down.)

Brad, one of your proposed organic technologies that will rapidly advance is the cell phone. The prices, availability, security and quality of the smartphone is a huge danger if they are used in an SDC environment. This is the quintessential hackers playground, and it will never be secure, but it's cheapness will make its adoption very broad (for general communication), and broad deployment makes it a hacker target.
The prices of smartphones are dropping rapidly, with Nokia just announcing phones near $100: http://www.canadianbusiness.com/business-news/nokia-makes-low-cost-android-phone-as-maker-of-rival-windows-software-buys-its-phone-business/
Would you really want to include hardware like this into a communication system that might potentially have life and death decisions to make.
You don't like DSRC, but I can't see how smartphone technology can give you a secure alternative.

The point is that the effectiveness of a V2V technology is the product of the performance of the tech and the market penetration of the tech. 100% reliable V2V in 10% of cars is inferior in most ways to less reliable tech that's in 95% of cars. It's hard numbers. And DSRC won't be in 10% of cars for many years go come, while we already have smartphones in over 80% of cars and are on the way to near-100%.

So you want phone based because it gives you the best result, and is on track to continue to do so as it innovates at an immense pace. And it will be vastly greater long before DSRC approaches smartphone penetration.

What I'm amazed is the suggestion anybody would want to "trust their life" to a technology with such low effectiveness if they had a better alternative.

Now, fortunately, it is not planned for DSRC tools to make "life and death decisions" to any serious degree. ITS engineers do not think it is reliable enough for that, and their plan is for warning systems, not decision systems. (This is one of the reasons DSRC V2V is not that interesting to the robocar community, as its data is not adequately reliable.)

The one area of discussion of the data being used in decisions is in the I2V department, in particular transmissions from traffic signals. While all robocars will have cameras able to read the traffic signals, it is hoped that in situations where the camera is not getting a good read on a signal visually, it might trust a data transmission saying it is green. (In the event the camera says red and the I2V says green, it would probably still stop and wait for human input.)

Here, I agree that DSRC would be superior, if implemented. The problem is, it's not on offer, as there is no clear path to a budget for it. Even at a much lower-than-forecast cost of $5,000 per intersection, it's not happening. There are 500,000 signalized intersections owned by many thousands of jurisdictions. New traffic lights could and probably will support it.

The ATSC proposal is based on the fact that large numbers of lights are already talking to central servers in many towns, and so that data could be made available to cars without any truck rolls. Working with older lights requires more data volume as the central server must receive regular updates on the plans of all lights to assure their plans are not stale by more than a few seconds.

And in the end, you want the best, but you also have to get the best bang for your buck. Because bucks are finite, and if you spend them all one place, you don't have them to spend on other things that might do better.

It's difficult to summon the imagination to thoroughly analyze the technologies as there are so many possible use cases. Consider curve-speed warning? Wouldn't that Voice feature be tremendously valuable even with very few equipped cars?

On the recent tour of Caltrans Oakland Traffic Managreement Center, I was struck by how much space is available in the signal-control cabinets at intersections: colo! Think of how valuable that real estate is, and how tightly controlled. I can't tell you which as yet non-existent business will pay for the right to put their hardware at every intersection, but somebody will, especially given that there's power. The space is potentially as limited and valuable as spectral bands.

Add new comment