0018-9162/98/$10.00 © 1998 IEEE January 1998 69

Web on Wheels:Toward Internet-Enabled Cars

The services provided to customersthrough the Internet can be extended tothe automobile. Early versions ofInternet-enabled cars might hit the roadin five years or less. Portions of the tech-

nology could be available to customers in as little astwo years as an after-sales solution. Indeed, such inte-gration could become essential, given the constantaccess to information our just-in-time world seems torequire. Integration could also be two-way: Your carmight also provide information to the Internet for thepurposes of remote diagnostics, among other things.Unlike the portable method of accessing the Internetwith a laptop computer, an Internet-integrated vehi-cle is truly mobile. Mobility serves as both a challengeand a distinguishing factor in the design of our com-munication and service architecture.

With the advancement of the Global PositioningSystem (GPS) and other position-tracking technolo-gies, location awareness emerges as a distinctive char-acteristic of combining mobile computing andautomobiles. This knowledge will be used to buildcommunication and service architectures. For exam-ple, a service could provide information about thenearest gas station or restaurant.

A safe and easy-to-use human interface for driversand passengers must be designed to bring Internet-based services to moving vehicles. For example, an e-mail service must not require that drivers take theireyes off the road. We employ various alternatives, suchas speech-based technologies, to address safety con-cerns.

SCENARIOSOur overall goal is to provide “telematik” (telecom-

munications and computer science) services to driversand passengers. What types of services are interesting

to our customers and how we serve them are open ques-tions. The Internet appears to be the most appropriateinfrastructure through which to conduct car-based services.

Services range from the obvious to the innovative,and include the following:

• Integration of personal data to the car using per-sonal devices such as smart cards and handheldpersonal computers.

• Interactive audio and video games for passengers.• Personalized services on demand, for example,

personalized commuting information.• Location-based information on demand, for

example, the nearest Chinese restaurant.• Seamless access to office or home computers.• Roadside assistance and remote diagnostics.

These services can be grouped as generic and loca-tion based. Generic services, for example, real-timestock quotes, are not directly car-related but are ofinterest to drivers and passengers. In general, theinfrastructure for such services can be supported inthe same way as a desktop environment.

Location-based services directly relate to the car-dri-ving experience. Because the car moves, its locationchanges and thus brings new demands for services:Where is the nearest gas station? Location-based ser-vices are possible because a car’s position can beknown at all times with current GPS technology.

An Internet car is similar to any other node on theInternet. Although highly mobile, an Internet car canuse the standard transmission-control protocol/Internet protocol (TCP/IP) to communicate with othernodes on the Internet. The Internet car can be a clientand a server, and in essence becomes an open platformfor services to be delivered over the Internet.

An open system that conforms to standard Internet protocols for communication to and from automobiles could greatly enhance driving.Existing Internet resources can be leveraged to integrate a car into theInternet. Service providers will subsequently produce innovative servicesfor drivers and passengers that will improve safety and security as well asprovide infotainment.

AkhtarJameelMatthiasStuempfleDaniel JiangAxel FuchsDaimler-BenzResearch andTechnology,North America

Cove

r Fea

ture

.

.

70 Computer

CHALLENGESThe design of Internet access for automobiles

involves three major issues: mobile wireless commu-nications, system architecture, and user interfacedesign.

Mobile wireless communicationsNetworking requires a variety of wireless tech-

nologies. In a local area, infrared (IR) and radio frequency

(RF) technologies generally provide high-speed wire-less access of several megabits per second at relativelysmall or no cost.

At the metropolitan level, technologies such asMetricom’s Ricochet network are capable of accessspeeds of tens of kilobits per second with a flatmonthly fee.

For a wide area, cellular digital packet data(CDPD) and emerging standards, such as the GeneralPacket Radio System (GPRS), achieve speeds of about10 kilobits per second at a higher cost. Furthermore,a plethora of new satellite-based systems are pro-posed. When realized, these satellite systems willdeliver globally from a few kilobits per second up toone megabit per second at a premium. Of course,when all else fails, the wireless modem over theAdvanced Mobile Phone System (AMPS) cellular sys-tem is still available.

These technologies provide the basic infrastructurefor maintaining access to and from a vehicle. The mainchallenge lies in selecting the appropriate technology

according to such factors as cost, performance, andavailability.

System architectureIn connecting cars to the Internet, a system archi-

tecture must provide a flexible distribution of com-puting power and communication between theautomobile and the infrastructure. Basically, a carcould be treated as either a thin or thick client. Carswith only input/output devices and a modem to requestand receive information are thin clients; cars with state-of-the-art computing power and onboard storagemedia to receive raw data and to process it are thickclients. The key factor influencing this overall archi-tectural choice is the cost of wireless communication.

The form of the final architecture will be determinedby technologies and business models. In any case, theintegrity, security, reliability, and speed of communi-cation must be maintained. The software architectureshould also allow for the development of new servicesand benefits that adapt easily to new and evolvingInternet technologies.

User interfaceIntroducing multimedia information in a moving

vehicle creates a potential hazard. A human interfaceboth safe and convenient while mobile at vehicularspeeds significantly challenges the utility of services tobe delivered over the Internet to drivers. The require-ments for a safe human interface also have a drasticimpact on the design of services for vehicles.

The Internet

Customer assistance centeror other service providers

SatelliteIP

GPS

CDPD

Metricom

Vehicle functions• Onboard diagnosis• Comfort functions

URL: VIN.mercedes-benz.car

• Smart card• HPC/PDA• Smart phone

Personal devices

Audio

Bus Entertainment

Storage deviceNavigation

CAN

Infraredtransceiver

Internet clientsInternet servers

Figure 1. The Internet-on-wheels concept carintegrates a mobilevehicle with servicesavailable on the Inter-net.

.

SYSTEM DESIGNThe initial intent of the project was to design a sys-

tem to meet the challenges of wireless communicationand the issues relating to a user interface in a car. Atthe same time, the growth of the Internet and the Webbrought to the fore a new way of network comput-ing. The design that emerged from these factors led tothe concept of total integration of vehicle functions,personal data, position awareness, seamless access,and Internet-based services. Figure 1 shows this con-cept, which we call Internet-on-wheels.

Our system design has three major components: thecommunication layer, the service infrastructure, andthe user interface. The reliability, security, perfor-mance, and scalability of the system are also essentialaspects of our design but are beyond the scope of ourdiscussion here.

Communication layerThe communication layer must be both open and

convenient:

• Openness. In today’s networking world, TCP/IPis the de facto standard for communication. Mostapplications use TCP/IP for communication, andmany resources and services available on net-works are accessible through TCP/IP, includingthe Web. It therefore must be used in any opennetworking solution. TCP/IP enables the use ofmany of today’s existing applications, providesaccess to numerous resources, and encouragesnew service development. Furthermore, it doesnot make sense to require the current servers onthe Internet to change their software or hardware.

• Convenience. Many wireless data communicationtechnologies exist and more are coming. We needto support these technologies without additionalburden. First, we need to work with the avail-ability of a technology in a particular geographi-cal region. Second, customers should not have tochange the technology they currently use. Forexample, a user might be a Global Standard forMobile Communications (GSM) subscriber, inwhich case the GSM handset should plug into theuser’s car to enable communication through theGSM network. To provide connectivity anywhereand to account for the coverage of different tech-nologies, one wireless network should be able tohand off to another. We cannot expect a customerto have the technical understanding to managethe handoff, nor can we expect a driver to havethe time or attention to deal with such details.Furthermore, a constant identity needs to bemaintained. Therefore, the necessary handoffamong various wireless networks must be seam-less and transparent.

We omit performance as a basic requirement of thecommunication layer. Although we want as much net-working performance as possible, our ability to pro-vide this in the communication layer is limited byavailable technologies and wireless service providers.So we try to provide an architecture that supports asmany existing or emerging wireless technologies aspossible, but we cannot dictate the performance ofthose wireless channels directly. Therefore, the appli-cation design should adapt to the communicationlayer’s capabilities rather than the other way around.Of course, we will try to improve the networking per-formance as much as possible in our capacity.

Basic communication architecture. With augmentedhandoff support, the Mobile IP’s capability of main-taining the same identity over various network accesspoints provides a natural solution.1,2 Mobile IP supports

January 1998 71

ServiceVirtual home

Homeagent

ISP

Wireless

Internet

TCP connection

Sender Homeagent

Basestation

Mobilehost

Internet Wired networkconnection

Wirelessconnection

TCP

IP

TCP

IPIP

Figure 2. A typical Mobile IP communication network has a virtual home address.

Figure 3. The basic Mobile IP architecture seamlessly hands off among interfaces.

72 Computer

a seamless handoff among multiple wirelessinterfaces in a manner that is transparent to thehigher layers.

Figures 2 and 3 show the workings of the pro-posed Mobile IP. As Figure 2 shows, the vehiclehas a virtual home IP address. Any serviceprovider or corresponding host would alwayssee the vehicle at that IP address, which is con-nected to the Internet at large via a home agent.

The vehicle connects through a particularwireless network and an Internet serviceprovider (ISP) and uses an IP address issued bythe ISP. The vehicle registers its current addresswith a stationary host known as its home agent.In communicating with a service provider, theincoming IP traffic from the service providerwould be intercepted by the home agent and

forwarded to the current address of the vehicle.Likewise, all traffic to the service provider would besent to the home agent before being forwarded to theservice provider.

In the event of a handoff from one wireless networkor ISP to another, the actual IP address of the vehiclechanges. Such a change would be reported to the homeagent, and all subsequent IP traffic would be routed tothe vehicle at the new address. None of these activitiesis visible from the applications that use the commu-nication layer.

Communication performance. Two issues affect per-formance in this environment: TCP performance overwireless links and the handoff from one wireless net-work provider to another.

TCP3 was designed to work for the wire-line-basedInternet, which rarely creates errors in the transmissionof IP packets. In such an environment, TCP assumesthat failure to receive a packet results from congestion.In the event of a packet loss, TCP slows and sends fewerpackets to lessen the congestion. Such an algorithmworks well in the wire-line network, but not so well overthe wireless link. However, when a TCP connectionincludes a wireless link, packet loss is far more likely tobe caused by errors in a wireless channel. Consequently,TCP data should be sent faster, not slower.

The networking research community has done muchto improve performance over lossy wireless links. Ingeneral, the proposed solutions fall into three groups:

• An end-to-end connection is intended to improveTCP performance relative to that of wireless com-munication.

• A split TCP connection divides a TCP connec-tion into two end-to-end parts.

• The reliable link layer has some knowledge of theTCP.4

The end-to-end and link-layer solutions work com-

paratively well. However, any end-to-end solutionrequires changes at the TCP layers of both the senderand the receiver. All servers on the Internet that ourcustomers might contact cannot be expected toupgrade their TCP software, leaving the link-layersolution as the most feasible measure for improvingTCP performance.

One link-layer solution employs a snooping agent.5

A snooping-agent observes and caches the TCP pack-ets going out to the mobile host on the wireless link.When the agent senses that some packets are lost (bymonitoring the acknowledgment packets coming backfrom the mobile host), it retransmits the cached TCPpackets. In this way, the snooping agent effectivelyprevents the effect of packet loss on the wireless linkfrom being propagated to the TCP sender and trig-gering a TCP slowdown.

The snooping-agent method works well in a wire-less local area network (LAN), in which the snoopingagent sits in the wireless base station. For wireless widearea networks (WANs), the snooping agent must beplaced a little further away from the wireless link. Thelogical location would be that of the home agentthrough which all traffic goes. Our research will focuson the snooping agent’s impact on performance rela-tive to its distance from the vehicle.

The issues concerning handoffs and their effect oncommunication performance are twofold. First, hand-offs exist among cells in a wireless network infra-structure. Although transparent to the mobile host,the handoff’s impact on the communication layer per-formance is unclear. Second, the handoff from onewireless network provider to another has a muchlarger effect. During the change of an actual IPaddress, the registering of the change to the homeagent, and finally the rerouting of traffic to reflect thechange, some IP packets might be lost.

The impact of such a handoff could be lessened byholding onto the existing wireless connection andsimultaneously routing the same packets to the newaddress as well as the existing one. With the new con-nection fully operational, the previous connectioncloses. The vehicle has the advantage of knowingwhere it is and where it is going to be and at whattime.

Combining such information with the knowledge ofwhere the coverage of a wireless network begins andends, a new connection can be preestablished beforethe current connection runs out of coverage. Such infor-mation might be cached by the vehicle through theexperience of driving in a familiar region, for example,a daily commute from home to work, or it could beprovided by service providers that measure and collectthe coverage of various wireless data networks.

In-car network. Most of the automotive industrysupports some types of bus architectures for control

Services for an Internet car are

bidirectional. In themore common

services, the caracts as a client and

the serviceinfrastructuresupports such

services.

.

.

and data transmission. A bus system with bandwidthlarge enough to support multiple video and audiochannels is needed to support the Internet-based mul-timedia information in the car. The Universal SerialBus (USB), the IEEE 1394 standard Firewire, or theIntelligent Transportation System Data Bus (IDB-I andIDB-II) could be considered for such a task.

Multiple inputs and outputs—such as screens, con-trol units, and audio channels—must be available foruse by all occupants in a car without any interferencewith each other. This flexibility is relatively easilyachieved for screens and control units, but it is harderto separate audio sources without using headphones.

Merging the in-car network with Internet commu-nication services will provide an integrated internaland external environment for the occupants. A mul-timedia infrastructure in a vehicular environment chal-lenges the design. The storage media is an essentialcomponent of an Internet information-based multi-media environment in a car. At a basic level, the mediamight be just a cache or simply a readable media suchas the minidisc or digital video disc, but the ultimatesolution will be a hard-disk-like unit for storing largeamounts of data that can be dynamically changed.

Docking of personal devices has wide acceptancein the personal computing arena. People will likely usedevices such as smart phones, smart cards, and per-sonal digital assistants (PDAs) to integrate with thecar’s multimedia system. These devices might also bea means through which to exchange personal infor-mation between the occupants and the car for seatadjustment, climate, and computer interface.

Service infrastructureServices for an Internet car are bidirectional. In the

more common services, the car acts as a client and theservice infrastructure supports such services.

Service infrastructure functions. The service infra-

structure has four main functions: It must search forservice providers, manage the user profile, deliver theservice, and use the service. Here we will not discussissues like billing and so on.

A location-indexed database is necessary if the caroccupants are to easily search geographical location-based services. The database must contain things likeservice providers, Web pages, and other information,indexed by the relevant geographical area. The vehi-cle’s location determines the scope of the search.

A service profile specifies what and how serviceswill be delivered to the customers in an Internet car.The service infrastructure provides storage and man-agement of a customer’s service profile.

After selecting a service provider, the communica-tion layer offers data transport functions. However, theability of the devices in the car to use the service con-tent must be determined. For example, large images ofa Web page cannot be displayed on a tiny PDA screen.Service delivery also needs to adapt to wireless linkcapabilities. A service proxy works well in such a situ-ation.6 By doing data transformation at the well-con-nected side of the Internet, the data load can be reducedand something easy to present can be created. By sym-metry, a car-side proxy for the vehicle must act as aserver in certain applications like remote diagnostics.7

The need to support ad hoc service types and serviceproviders means that we need to support automateddownloading, installation, and update of client soft-ware for future, unknown services.

Service architecture design. Figure 4 diagrams thehigh-level components in the service architecture.8 Theservice register and locator is essentially the location-indexed database. This database accepts and respondsto queries from the vehicle for services and serviceproviders. Once a customer finds a service provider,services can be requested and transactions begun. Suchservice transactions might go through a proxy.

January 1998 73

Internet

Service registerand locator

Serviceprovider

Serviceproxy

Query andresponse of services

Service informationregistration and update

Service transactions

Figure 4. The servicearchitecture designcontains these high-level components.

.

74 Computer

Placement of the user profile and determination of thecomponent responsible for the profile managementmust be determined. This is essentially the issue ofhow to distribute the intelligence in the system.

User interface designThere is no precedent for the user interface of a Web

car. Obviously, there are safety issues involved in theplacement of screens, hand control units, hands-freephones, and buttons.

User interfaces can range from a simple one-touchoperation to a fully interactive audio and video expe-rience. Clearly, the driver, navigator, and passengershave differing circumstances when the vehicle is parkedor in motion. A taxonomy of the driver, navigator, andpassengers with different human interface needs is agood starting point to understand the basic differencesin the design of interfaces for these positions.9

Drivers might find a primarily speech-driven inter-face most suitable, whereas passengers and navigatorscan use a richer and more interactive interface. Weexpect that a conversational, dialogue-based speechsystem will be used in the future.

Large speech-recognition systems, especially thosethat support natural-language processing, are expen-

sive and difficult to support in cars. Therefore, a net-work-based solution makes sense. Such a solution iswell suited to a dynamic, on-the-fly vocabulary, andconversational natural-language processing approach,and it is cheaper to maintain and upgrade. A hybridbetween in-car recognition for the car controls and anetwork-based approach for external information-based services would be ideal.

The type of user interface chosen will be closely tiedwith the nature and type of services that can be deliv-ered to drivers and passengers. Mobility is no longeronly driving the car but incorporates also the states ofbeing at home, in the garage, on the road, and at thedestination. A driver’s safety depends on the state ofmobility, the time available, and the driver’s goals. Weintend to define a metric on the basis of the relation-ship between these four human factors and the ser-vices that can be delivered to car drivers andpassengers.9 This metric will be used to define userinterfaces that are safe and match the measures usedby Mercedes-Benz, the Society of AutomotiveEngineers, or similar established safety standards. SeeFigures 5 and 6.

The presentation and user interface architectureshown in Figure 7 assumes that content providers sup-ply the data and the semantics to describe the archi-tecture’s structure. The presenter uses this informationalong with the user input and status information (vehi-cle speed, user being the driver or passenger) to renderand deliver content to appropriate output devices.

CONCEPT DEMONSTRATIONIn the first implementation of the Internet-on-wheels

concept car,10 we designed multimedia units for twodifferent zones (drivers and passengers) with the userinterfaces as shown in Figures 5 and 6. Each of thesehas a color screen, channel select buttons, an infraredtransceiver to support handheld devices, and an audiooutlet.

Access to applications differs in these two zones.The driver and the navigator have access to a singlemultimedia unit in the front (Figure 5), and the pas-sengers in the back seat have access to individual mul-timedia units (Figure 6). The demonstrativeapplications in the front zone access informationrelated to traffic and navigation. In the rear zone,access expands to include navigation tools, officeapplications, interactive games, and infotainment.

Drivers can access voice-mail, e-mail, and travel-related information such as restaurant guides andmovie theater locations. By integrating the GPS andmapping technologies, the Internet car becomes loca-tion-aware, which allows for a new class of servicesthat go well beyond classical navigation. The driverwill have access to these services in a hands-free, eyes-free manner through voice commands and speechtechnology. In addition, the armrest in the driver’szone has a slot for a personal device to enable the dri-ver to bring in personal preferences.

Passengers can access richer interactive applicationssuch as onboard or Internet games, audio-on-demand,and the Web. They can access information about cities

Figure 5. The frontmultimedia zone ofthe Internet car isaccessible to both thedriver and the naviga-tor.

Figure 6. The rearpassengers haveaccess to multimediaunits that containscreens, channelselectors for games, acomputer, navigationtools, infrared trans-ceivers, and audiooutlets.

.

and historical places during a drive as they pass them.Passengers can also enjoy an enhanced multimediaenvironment for navigation, stereo, or streamingaudio and video. The built-in infrared transceivers willallow PDAs, handheld PCs (HPCs), and smart phonesto interact with the systems in the car and the Internet.For these new services, user interfaces will allow easyand safe handling of the interactive media.

For the customer assistance centers that currentlyrely on telephony-based service, the Internet car pro-vides an expanded datacentric multimedia environ-ment to deliver new services, including operator’s helpmanuals, intelligent roadside travel assistance, andremote diagnostics.

T he intelligent transportation systems commu-nity intends to stimulate research and industryto build an infrastructure that will lead to bet-

ter traffic and transit resource management andenhanced safety. From the perspectives of cost andreusability, a single infrastructure must provide mostof the functionality as opposed to a separate infra-structure for each service. The Internet has the poten-tial to be such an infrastructure. The car acts essentiallyas a probe in this model, collecting and sending data toservice centers, which in future navigation systems willbe used to build dynamic real-time traffic models foron-demand route guidance for individual vehicles.

The spectrum of service possibilities ranges from ahighly integrated, PC-like environment to a fullyautonomous network computer-like system. A safeand convenient human interface design will leveragethe vast pool of potential services from the Internetfor drivers and passengers.

Our research aims to investigate and prototypefuture Internet-based services for cars. By groundingthe concept and architecture of information technol-ogy for a car around the Internet and open standards,the Internet car can take full advantage of the tidalwave of Internet-based services, technologies, anddevices for many years to come. ❖

AcknowledgmentsWe thank Paul Mehring for his vision in support-

ing this research. Many thanks to Klaus Eitzenbergerand Peter Stiess from Daimler-Benz in Stuttgart whoseresearch and ideas have helped us in this project.

References1. M. Stemm and R. Katz, “Vertical Handoffs in Wireless

Overlay Networks,” ACM Mobile Networking, Fall1997.

2. C. Perkins, “Mobile IP,” IEEE Comm., May 1997, pp.84-99.

3. W.R. Stevens, TCP/IP Illustrated: The Protocols, Addi-son Wesley Longman, Reading, Mass., 1996.

4. H. Balakrishnan et al., “A Comparison of Mechanismsfor Improving TCP Performance over Wireless Links,”Proc. ACM SIGCOMM Conf., ACM Press, New York,1996.

5. H. Balakrishnan, S. Seshan, and R. Katz, “ImprovingReliable Transport and Hand-off Performance in Cellu-lar Wireless Networks,” Proc. ACM Mobile Comput-ing & Networking Conf., ACM Press, New York, 1995.

6. A. Fox and E.A. Brewer, “Reducing WWW Latency andBandwidth Requirements via Real-Time Distillation,”Proc. Fifth Int’l World Wide Web Conf., 1996.

January 1998 75

Display

Speech

MicrophonePointer deviceAlphanumeric device

HTMLHDMLXML

Externaldevices

InfrastructureCar data

Multimedia

Contentprovider

Userinput

Statusinformation

Configurationinformation

Controlreception

Content

Contentplug-in

Presenter

Figure 7. Contentproviders define thedata and semantics forthe presentation anduser interface archi-tecture.

.

7. M. Stuempfle, D. Jiang, and A. Jameel, “Aspects of anIP-Based Communication and Service Architecture UsingWireless Networks,” RTC Report 31, DB-RTNA, 1997.

8. D. Jiang, M. Stuempfle, and A. Jameel, “Service Archi-tecture for Internet-Enabled Automobiles,” RTC Report32, DB-RTNA, 1997.

9. M. Tschudy, M. Braun, and A. Jameel, “MB-BrowserTechnologies,” RTC Report 33, DB-RTNA, 1997.

10. A. Jameel, A. Fuchs, and M. Stuempfle, “Internet Mul-timedia on Wheels: Connecting Cars to Cyberspace,”Proc. IEEE ITS Conf., IEEE Press, Piscataway, N.J.,1997, p. 291.

Akhtar Jameel is the principal researcher and managerfor the Internet Multimedia on Wheels project atDaimler-Benz’s Research and Technology Center. Hereceived a PhD in computer science from TulaneUniversity, New Orleans.

Matthias Stuempfle is a research scientist at Daimler-Benz’s Research and Technology Center with a major

interest in communication architectures and softwareengineering. He finished the research toward his PhDand has submitted the thesis to the faculty of EE at theUniversity of Stuttgart. He is a member of VereinDeutscher Elektrotechniker and the IEEE ComputerSociety.

Daniel Jiang is a research scientist at Daimler-Benz’sResearch and Technology Center. He received a BS in com-puter science from Rutgers University and is an MS can-didate in computer science from the University ofCalifornia at Berkeley.

Axel Fuchs heads the Transportation and MobilityGroup at Daimler-Benz’s Research and TechnologyCenter. He received a PhD in electrical engineeringfrom the University of Darmstadt.

Contact the authors at Daimler-Benz Research andTechnology North America, Palo Alto, CA 94304;{jameel, stuempfle, jiang, fuchs}@rtna.daimlerbenz.com.