You are here

V2V and connected car part 3: Broadcast data


Earlier in part one I examined why it's hard to make a networked technology based on random encounters. In part two I explored how V2V might be better achieved by doing things phone-to-phone.

For this third part of the series on connected cars and V2V I want to look at the potential for broadcast data and other wide area networking.

Today, the main thing that "connected car" means in reality is cell phone connectivity. That began with "telematics" -- systems such as OnStar but has grown to using data networks to provide apps in cars. The ITS community hoped that DSRC would provide data service to cars, and this would be one reason for people to deploy it, but the cellular networks took that over very quickly. Unlike DSRC which is, as the name says, short range, the longer range of cellular data means you are connected most of the time, and all of the time in some places, and people will accept nothing less.

I believe there is a potential niche for broadcast data to mobile devices and cars. This would be a high-power shared channel. One obvious way to implement it would be to use a spare TV channel, and use the new ATSC-M/H mobile standard. ATSC provides about 19 megabits. Because TV channels can be broadcast with very high power transmitters, they reach almost everywhere in a large region around the transmitter. For broadcast data, that's good.

Today we use the broadcast spectrum for radio and TV. Turns out that this makes sense for very popular items, but it's a waste for homes, and largely a waste for music -- people are quite satisfied instead with getting music and podcasts that are pre-downloaded when their device is connected to wifi or cellular. The amount of data we need live is pretty small -- generally news, traffic and sports. (Call in talk shows need to be live but their audiences are not super large.)

A nice broadcast channel could transmit a lot of interest to cars.

  • Timing and phase information on all traffic signals in the broadcast zone.
  • Traffic data, highly detailed
  • Alerts about problems, stalled vehicles and other anomalies.
  • News and other special alerts -- you could fit quite a few voice-quality station streams into one 19 megabit channel.
  • Differential GPS correction data, and even supplemental GPS signals.

The latency of the broadcast would be very low of course, but what about the latency of uploaded signals? This turns out to not be a problem for traffic lights because they don't change suddenly on a few milliseconds notice, even if an emergency vehicle is sending them a command to change. If you know the signal is going to change 2 seconds in advance, you can transmit the time of the change over a long latency channel. If need be, a surprise change can even be delayed until the ACK is seen on the broadcast channel, to within certain limits. Most emergency changes have many seconds before the light needs to change.

Stalled car warnings also don't need low latency. If a car finds itself getting stalled on the road, it can send a report of this over the cellular modem that's already inside so many cars (or over the driver's phone.) This may take a few seconds to get into the broadcast stream, but then it will be instantly received. A stalled car is a problem that lasts minutes, you don't need to learn about it in the first few milliseconds.

Indeed, this approach can even be more effective. Because of the higher power of the radios involved, information can travel between vehicles in places where line of sight communications would not work, or would actually only work later than the server-relayed signal. This is even possible in the "classic" DSRC example of a car running a red light. While a line of sight communication of this is the fastest way to send it, the main time we want this is on blind corners, where LoS may have problems. This is a perfect time for those longer range, higher power communications on the longer waves.

Most phones don't have ATSC-M/H and neither do cars. But receiver chips for this are cheap and getting cheaper, and it's a consumer technology that would not be hard to deploy. However, this sort of broadcast standard could also be done in the cellular bands, at some cost in bandwidth for them.

19 megabits is actually a lot, and since traffic incidents and light changes are few, a fair bit of bandwidth would be left over. It could be sold to companies who want a cheaper way to update phones and cars with more proprietary data, including map changes, their own private traffic and so on. Anybody with a lot of customers might fight this more efficient. Very popular videos and audio streams for mobile devices could also use the extra bandwidth. If only a few people want something, point to point is the answer, but once something is wanted by many, broadcast can be the way to go.

What else might make sense to broadcast to cars and mobile phones in a city? While I'm not keen to take away some of the nice whitespaces, there are many places with lots of spare channels if designed correctly.


Why not just use the cell network for stalled vehicle data? You can probably use the GPS to infer the locations of stalled vehicles even if the stalled vehicles don't report the data at all, if the stalled vehicles are slowing traffic.

Just as real time bus preditions are available over the Internet in many places (often with the data collected with GPS + cell modems), the traffic light controllers could make their expected timing information available over the Internet.

If the data rates are going to be small as you seem to be saying, we shouldn't have to worry about this data clogging the LTE networks.

Yes, I think the cell network can do stalled vehicles. (Still has same problem as V2V in figuring out the lane of course.)

One of the key arguments for V2V (and against cellular) is the latency. The use of a broadcast channel cuts out half the latency, and so helps in this area. Because of the high bandwidth of an ATSC channel, I figure if you have it you might as well send out the stalled vehicles. However, without that, the cell network makes a lot of sense.

Low latency is desired for collision warning with moving vehicles, notably blind corners and intersections, it isn't needed in most other places.

We could "easily" create very precise GPS data for local precision - a low power transmitter on a cellular tower would do the trick.

Yes, I forgot to mention that. There have been companies even working to improve GPS using ATSC transmissions which have suitable timesync in them.

Note that one problem with big tower transmissions is that they are quite powerful and as such they generate a lot of multipath above your noise floor.

Augmented HA-NDGPS in theory can be very accurate, though multipath is always a killer.

The problem with cell usage for V2X is multifacted. The USDOT/FHWA believe safety should be free to the driver/consumer, and the use of cell technology would balloon cell bills. Also, dependency is crucial, and during peak periods must be available for the safety features of V2X. Typical cell congestion, dropped calls, during peak periods (which coincide with traffic peak periods) would be unacceptable. Also, latency is an extreme issue for safety V2X features such as intersection red light running warning,etc. I see cell being used for other, less demanding, non-safety relatyed features. See my post at

This ignores the biggest point in this article series. "Not deployed is zero percent reliable."

Of course the use of cellular networks (or even DSRC-like protocols by handheld mobile devices) has flaws and places where it may not work. The issue is that DSRC in cars would have far, far, far more instances where it would not work because it simply isn't there at all.

Already a large fraction of cars on the road have a data-connected smartphone with GPS somewhere in the vehicle. Many of these are plugged into power, and with the adoption of inductive charging this will become the norm. A decent number even have a telematics system with data built right into the car. This is already here, and will grow to near-100% this decade. DSRC deployment, even if a mandate is given requiring its deployment in cars, will only start showing up late in this decade and only reach decent deployment a decade later.

So which is better, the system that might fail due to latency or congestion from time to time, or the system that fails all the time because even after it's in 25 million cars still only has less than a 1% chance of connecting any two given cars which might need it?

You're also making the mistake of presuming the cell network won't improve exponentially. That's always been a wrong prediction since the dawn of the network, why is it a right prediction today?

My personal view as stated in part 1 is that you would do better for red-light running by having the lights detect that, rather than the cars.

It is good to hear that the latency of the broadcast would be very low of course, but yes what about the latency of uploaded signals?

  • On this website internet gambling I've noted that I can discover the many online casino chips and get additional internet gambling dollars compared to each and every gambling web page.

Add new comment

Subscribe to Comments for "V2V and connected car part 3: Broadcast data"