Drive-by-wireless: why the future of cars is P2P mesh, 4G cellular, and the cloud

In this in-depth interview, Ars talks with a former AT&T exec turned startup …

In this four-part series, Ars Technica takes an in-depth look at the future of driving. This is a topic we've covered in the past, but recent developments in wireless and consumer electronics are poised to have a huge impact on automotive technology. You may not think that things like 4G or multicore processors have anything to do with cars, but you'd be wrong. They have everything to do with what driving will be like in the next five to ten years.

Ars recently sat down with Kaveh Hushyar, a former senior VP at AT&T and current CEO of Telemetria, makers of the DashTop in-car compute appliance. In this fascinating interview, we talk about the ultimate evolution of not just the car, but of the complete automotive experience. The car of the future will be more like a mobile office, and the traffic of the future will be a moving mesh of real-time, cloud-connected data sensors, with each car acting as a node on a giant peer-to-peer network. Read on for a look at how all of this will work.

JS: Tell me a bit about your background, for our audience.

KH: I graduated from Stanford with a masters in industrial engineering about 35 years ago, and since then I've worked in a number of companies outside the US and in the US. The last 25 years I was at ATT. I started at Bell Labs, where I started looking into automation of ATT manufacturing's global operations, and then I moved into product development [where I worked on] a whole bunch of products, including PBX. And then I moved into the telecommunications side for almost half of my time at ATT, and this is where I grew from developing the operational support systems for the company all the way to my last position where I was the senior VP of network engineering and planning engineering for ATT's global network.

In that time, I had responsibility for building the overall network—the backbone and the quad-play network—inclusive of wireline, wireless, data, and video. So that was my overall responsibility at ATT, and I also come from the old ATT. SBC bought the old ATT—"Ma Bell"—and it became the ATT that it is today.

JS: So how did you get into the car space from that?

KH: When I retired from ATT I had intended to just invest in technology, rather than doing any specific kind of job. I did a lot of that [along with some consulting], until I came across this startup company. When I looked at what they were doing, I got passionate about it.

Technology today causes a lot of problems when we're driving. I myself have three devices, and I'm juggling them all when I get into the car. It really raises concerns.

When I came across [DashTop], I became really passionate about it, and in the following sense: what does it take to transform the way people drive, making sure that the same environment they have at home in the office is enabled inside of the car while also ensuring the safety of drivers and passengers? This was the element that made me passionate about this.

When I looked at this area, I became convinced that the last piece of technology needed to make all of this work was 4G. And now we know where 4G is and where it's headed, so the technology is ready and it's a matter of making the inside of the car as exposed to the technology as every other aspect of our lives is.

Driving in 2015 and 2020

JS: Let me take a step back and ask you what it will mean to drive in the year 2020. What is the driving experience in 2020 or 2018, after these developments have taken hold, and how is it different from the driving experience that I have now?

KH: Let me answer the question in two ways, by talking about two milestones. One milestone is more like 2015 or 2016, and the other milestone is in 2020 and afterwards.

I believe in 2020, the car will drive itself. The infrastructure will be in place, and that infrastructure will be very significant and hefty. But in that target environment, you and I don't have to be sitting behind the wheel. In that environment, everyone will be a passenger, and you want to have full connectivity with full access to any media, or any person anywhere via the best videoconferencing available. So you need a rich media experience in the car.

At the same time, there will be a significant amount of safety applications that will be running in the car, making sure that the car is fully protected and is communicating through the infrastructure to other cars. That would be the nature of how I see the driving experience transforming in ten years plus.

In the 2015 timeframe, I see a significant presence of voice enablement technology inside the car. You and I still have to drive, but pretty much all of the applications that are available to us when we're sitting at home or in the office will be available to use through voice enablement. Voice technology will be much more advanced, so that you'll be sitting in the car and you'll be directing music, searching for any point of interest or anything else on the Internet, or whatever you normally do at home or in the office. At the same time, there will be a variety of safety applications running in the car.

For example, a sleepy eye detection application will be watching your eyes, and if you're getting a little bit tired it will respond to you. There will be a series of applications for pointing out, for example, if there's an ice patch ahead of you, and on and on. So I would think that in five years, voice enablement will revolutionize the way you and I drive.

And in ten years, there's not going to be a driver. It's going to be a totally different environment.

Processing on the client side

JS: For the voice interface, is that going to be done on the client side, or is it going to be done on the server side like we see with Android, where the client just grabs the voice sample and uploads it to a server that does the recognition remotely?

KH: To be honest, it should be done on the client side. That's the way it should be, and must be, regardless of the communication technology. You want to have as much of the basic infrastructure—and voice would be basic infrastructure—on the client side. However, having said that, there are going to be cases where parts of that processing will have to be done in the cloud and there is no other way. Even today, we're building our technology so that a good portion of it is running on the client, but there are pieces of it running in the cloud. But strategic parts of the technology will have to be client side.

JS: For the processing that's going to happen on the client side, will that be Intel or ARM, or some mix?

KH: From where I'm sitting right now, it doesn't matter whether it's ARM-based, or Intel, or whatever. I can take that, and through sound engineering turn it into a crash-proof, cost-effective product that can enable us to run the apps that are critical for us.

And to make another point: I feel very strongly that, when we talk about the smartphone and the environment that you want to have in car to enable the kind of experience that we talked about, the smartphone has a long way to go. I'm not saying it's not possible, but it's a long way to go.

We selected Intel and the Atom, but I could've selected some other processors. One of the requirements that I have is the operating range. As long as the operating range is the right range, I see a lot of these processor companies that are very competitive in terms of overall device performance.

JS: To continue in that vein, you guys are using multicore processors from Intel, right?

KH: Right now as we speak, it's single-core, but we're going to dual-core and then to multiprocessor with dual-core.

JS: And that's because you need the concurrency to handle all of the different real-time datastreams that you get out of the vehicle. Is that correct?

KH: I have been talking to God-knows how many people, and you are the first one who got the essence of it—that concurrency is at the heart of what we're trying to do. Anyone who's trying to do things in this area has to be very sensitive to concurrency issues.