Wireless LAN Power Control in an Automotive Environment

Christopher A. Hedges and Timothy D. Bolduc

September 30, 2002

Christopher A. Hedges and Timothy D. Bolduc

	ABOUT THE AUTHORS Christopher A. Hedges received his MS and BS degrees in electrical engineering from Purdue University in 1995 and 1988, respectively. Hedges has worked for Delphi Corp. since 1989 designing vehicular navigation systems, powertrain controllers, and entertainment systems. He has recently led several short-range, wireless network projects for Delphi's Advanced Engineering group. Timothy D. Bolduc received his MS degree in electrical engineering from Stanford University in 1995 and his BS degree in electrical engineering in 1991 from Marquette University. He has worked for Delphi Corp. since 1991 in various capacities. Currently, Bolduc is serving as a project leader in Delphi's Advanced Engineering group where he is responsible for developing wireless networks and services.

Embedding a WLAN (wireless local-area network) node in a vehicle enables interactions with hotspots (access points). One such hotspot is merely a user's home PC. A vehicle with a WLAN and a mass storage device becomes a network drive when parked in the user's garage. The home PC can manage the vehicle's digital music and video files. This is convenient, since the PC is the natural place to download or encode such files. The home PC could also retrieve diagnostic data from or send firmware updates to the vehicle. Another possible hotspot could be a fuel dispenser at a service station. MP3 music, MPEG-4 videos, audio books, or navigation directions could be received while the vehicle is stopped during refueling. Other public hotspots could be rest areas, restaurants, or shopping malls.

While the engine is running, the WLAN can be operating at full power, since the vehicle alternator is supplying current. However, many network interactions will take place where the power is limited—parked at a public hotspot or at home in the garage. If the battery is excessively drained, the vehicle will not start and the battery will need to be charged.

The WLAN node will likely be comprised of three major components—a SBC (single-board computer), WLAN chipset/module, and mass-storage device. A WLAN chipset requires power to receive and transmit data. Most chipsets have low-power sleep modes, but even in these modes current drain is still on the order of tens of milliamps. An automotive telematics device typically has a limited current budget between ignition cycles. Couple the current needed for the SBC along with the WLAN radio and the result is that the node cannot be active the entire time a vehicle is parked without the engine running.

This article describes actions performed by a vehicle's WLAN node to enable adequate network performance while still ensuring the vehicle battery will have enough energy to start the engine. Figure 1 shows a block diagram of the node and potential hotspots.

Figure 1:  Vehicle wireless node and potential hotspots

First and foremost, a current budget between ignition cycles will need to be established for the node. 1500 mA-hours is a typical allowance for an automotive telematics device. Quiescent current draw for a device is traditionally less than 1 mA from the 12V vehicle battery. Later in this article, we will discuss several power-saving techniques to limit the active listening time. The node will have to totally cease operation when it hits the budget limit. In addition to the WLAN chipset, the SBC (single-board computer) and a mass-storage device will also be drawing current. Tables 1 and 2 show some typical power-requirements in Listening Mode (listening for hotspot activity) and Download Mode (receiving and storing files).

	Typical Current Draw	Power
WLAN chipset (power-savings mode)	30 mA @ 3.3V	0.1 W
Mass Storage (off)	—	—
SBC	1500 mA @ 5V	7.5 W
5V/3V Regulator (85% efficiency)	111 mA @ 12V	1.34 W
Total (listening mode)	745 mA @ 12V	8.9 W

Table 1:  Typical power consumption in listening mode

	Typical Current Draw	Power
WLAN chipset (continuous receive)	250 mA @ 3.3V	0.825 W
Mass Storage (hard disc drive write)	540 mA @ 5V	2.7 W
SBC	1500 mA @ 5V	7.5 W
5V/3V Regulator (85% efficiency)	160 mA @ 12V	2 W
Total (download mode)	1080 mA @ 12V	13 W

Table 2:  Typical power consumption in download mode

A WLAN transmits at varying rates depending on range and interference. However, this data rate is not the actual file transfer rate. On average, the observed file transfer rate is comparable to roughly 60% of the WLAN bit rate. Table 3 takes this into account and shows typical download times for various media files over an 802.11 WLAN.

		802.11 bit rate (Mbps)
		54	11	5.5	2
File Size	5 MB (MP3 song)	2 seconds	6 seconds	12 seconds	33 seconds
	700 MB (MPEG-4 movie)	2.9 minutes	14 minutes	28 minutes	78 minutes
	4 GB (MPEG-2 DVD)	16.5 minutes	80 minutes	2.7 hours	7.4 hours

Table 3:  Typical file transfer times over an 802.11 WLAN

If all power were available for receiving and storing, the following formula would apply:

Time^{Receive & Store} = Current Budget^Total / Current^{Receive & Store}

In this ideal situation, Time^{Receive & Store} = 1500 mA-hour / 1080 mA = 83 minutes. This is adequate to download an entire DVD. However, in reality, we must use the following formula that takes Listening Mode into consideration:

Time^{Receive & Store} = (Current Budget^Total - (Current^Listening × Time^Listening)) / Current^{Receive & Store}

If Listening Mode lasts one hour, Time^{Receive & Store} = (1500 - (745 × 1)) / 1080 = 42 minutes.

There are obviously going to be design choices that can reduce current draw. In our example, we used a hard disc drive (HDD) for mass storage. Utilizing an alternate storage technology, such as FLASH memory, could reduce consumption. Cost, density, and performance will all have to be considered. Perhaps the best solution is a hybrid one that utilizes a HDD while the vehicle is running and Flash memory during "ignition-off" downloads.

The next section moves away from any specific node design and discusses some general "listening" techniques.

A simple solution is to delay the shutdown of the node when the vehicle ignition is turned off. This scheme lends itself well to stopping at a public WLAN hotspot such as a service station or restaurant. If a timeout period of 10 minutes is used, this should provide ample time for a user to exit the vehicle, conduct business at the hotspot (start fueling or order food), and initiate a wireless download as shown in Figure 2. This mode is very power-efficient because the node is completely powered down after it reaches its timeout.

Figure 2:  10-minute timeout

In Point Coordination Function operation, the Timing Synchronization Function will use broadcast beacons to inform the node of impending traffic. The node will poll for incoming traffic. If the node determines that it has traffic, it will begin a negotiation with the hotspot for any pending downloads as seen in Figure 3. The details of this negotiation can vary and are beyond the scope of this discussion. If the result of this negotiation is a download, it can continue past the 10-minute timeout (as long as the 1500 mA-hour current budget is not exceeded).

Figure 3:  Download occurs within 10 minutes

This scheme could also be used at home. However, it is unlikely that a user will arrive home and immediately begin downloading files to the vehicle—thus, this scheme can prove to be cumbersome for the user. The vehicle must be re-awakened to download data. This could be triggered by a user-initiated event, such as unlocking the doors, which is shown in Figure 4.

Figure 4:  Door-unlock event to wake up the WLAN

Another simple power scheme involves using a real-time clock on the SBC. The node can wake up at a predetermined time, such as 4 AM, and initiate negotiations with the hotspot. As shown in Figure 5, if the hotspot is not awake or has no files to download, the node will shut down. The SBC needs to keep a real-time clock running until Wake-Up occurs and this will consume a modest current. However, overnight downloads can now be achieved without any user intervention at the vehicle.

Figure 5:  Wake-up at a predetermined time

If a hotspot is found and a positive negotiation occurs, queued files will be downloaded. The SBC will download these files and then go back to sleep until the vehicle is started in the morning as shown in Figure 6.

Figure 6:  Wake up and download queued files

A final listening-mode is to periodically wake up (every 30 minutes) and initiate negotiations with a hotspot. As shown in Figure 7, if there is a positive negotiation, the files will be downloaded and then the node will go back into periodic sleep. There is a trade-off between frequency of queries and how much the battery is drained. In Figure 7, if a user logs on their home PC at 8:35 PM and attempts to download some music to their vehicle, they will have to wait 25 minutes until the download occurs. A shorter period will reduce delay and possibly prevent user frustration. However, each boot-up of the node may consume a large in-rush current. The severity of this effect will vary depending on hardware specifics and is not quantified here. The number of overnight boot-ups versus periodic rate is shown in Table 4.

	Wake-Up Period (Minutes)
	5	10	30	60
SBC Boot-Ups	96	48	16	8

Table 4:  Number of SBC boot-ups over eight-hour period

Figure 7:  Periodic WLAN wake-up

This mode is the least efficient due to power consumed by repeatedly booting up the node. However, user intervention at the vehicle is not required and download latency is reasonably low.

A vehicular WLAN node must stay within a 1500 mA-hour budget between ignition cycles. Regardless of download progress, the node should be shut off when this limit is met. Beyond refining the hardware design, we proposed three listening techniques to reduce power consumption—Delayed Shutdown, Predetermined Wake-Up, and Periodic Wake-Up. A comparison of the three techniques is shown in Table 5.

	Benefits	Drawbacks
Delayed Shutdown	• Most power efficient	• Needs vehicle User Event for download
Predetermined Wake-Up	• Good power efficiency • No vehicle User Event for download	• Large download latency
Periodic Wakeup	• Reduced download latency • No vehicle User Event for download	• Least power efficient

Table 5:  Listening mode comparison

These methods allow intelligent listening to determine if a node-hotspot transfer should occur. Downloading large video files requires high efficiency. If our node is purely a digital audio player, efficiency may not be as important. If automatic downloads of weather and news are a major feature, the latency associated with Predetermined Wake-up would not be considered a negative factor. A budget lower than 1500 mA-hours may force a User Event to be required for Wake-up. The system's design requirements for efficiency, latency, and ease of use will determine which combination of modes to use.

Stranding a driver at a hotspot is a safety concern. The driver needs to have a fully operational vehicle after all the data has been transferred. We developed the methods discussed in this article to maximize the convenience of a wireless network without jeopardizing vehicle safety.