Wireless Networks 6 (2000) 263–277
`
`263
`
`Application-driven power management for mobile communication
`
`Robin Kravets a and P. Krishnan b
`a Department of Computer Science, University of Illinois, Urbana-Champaign, Urbana, IL 61801, USA
`b Bell Labs, Lucent Technologies, 101 Crawfords Corner Rd., Holmdel, NJ 07733-3030, USA
`
`In mobile computing, power is a limited resource. Like other devices, communication devices need to be properly managed
`to conserve energy.
`In this paper, we present the design and implementation of an innovative transport level protocol capable of
`significantly reducing the power usage of the communication device. The protocol achieves power savings by selectively choosing
`short periods of time to suspend communications and shut down the communication device. It manages the important task of queuing
`data for future delivery during periods of communication suspension, and decides when to restart communication. We also address the
`tradeoff between reducing power consumption and reducing delay for incoming data. We present results from experiments using our
`implementation of the protocol. These experiments measure the energy consumption for three simulated communication patterns as well
`as three trace-based communication patterns and compare the effects of different suspension strategies. Our results show up to 83%
`savings in the energy consumed by the communication. For a high-end laptop, this can translate to 6–9% savings in the energy consumed
`by the entire mobile computer. This can represent savings of up to 40% for current hand-held PCs. The resulting delay introduced is
`small (0.4–3.1 s depending on the power management level).
`
`1. Introduction
`
`In today’s world of mobile communications, one of the
`most precious commodities is power. The mobile host can
`only operate as long as its battery maintains power. New
`machines are being made to use less power allowing for
`smaller batteries with smaller capacities. The trend in mo-
`bile computing is towards more communication-dependent
`activities, with mobile users switching from traditional
`wired Ethernet communication to wireless communication
`(using wireless Ethernet cards, for example). When in-
`serted, many wireless communication devices consume en-
`ergy continuously. Although dependent on the specific ma-
`chine and wireless device, this energy consumption can
`represent over 50% of total system power for current hand-
`held computers and up to 10% for high-end laptops. These
`trends make it imperative that we design power-efficient
`communication subsystems.
`Various techniques, both hardware and software, have
`been proposed to reduce a mobile host’s power consumption
`during operation. Most software-level techniques have con-
`centrated on non-communication components of the mobile
`host, such as displays, disks and CPUs. In particular, re-
`searchers have looked at methods to turn off the display af-
`ter some period of inactivity (as often implemented in BIOS
`or screen savers), to spin down the hard disk of the mobile
`host [12,16,22], and to slow down or stop the CPU depend-
`ing on work load [15,23,30]. The principle underlying the
`techniques for controlling these components is to estimate
`(or guess) when the device will not be used and suspend
`it for those intervals. Stemm et al. [29] have identified the
`problem of excess energy consumption by network inter-
`faces in hand held devices, and have provided trace-driven
`simulation results for simple software-level time-out strate-
`gies. The new IEEE 802.11 standard that is being adopted
`
`J.C. Baltzer AG, Science Publishers
`
`by some vendors adopts lower level solutions (at the MAC
`and PHY layer) to support idle-time power management.
`Hardware-level solutions for managing the communication
`device focus on modulating the power used by the mobile
`transmitter during active communication [24,26,28].
`Our research presented in this paper focuses on software-
`level techniques for managing the mobile host’s communi-
`cation device through suspension of the device during idle
`periods in the communication. We present a novel transport
`level protocol for managing the suspend/resume cycle of the
`mobile host’s communication device in an effort to reduce
`power consumption. The management of communication
`devices creates a new and interesting challenge not present
`when managing other devices’ power consumption. Sim-
`ilar to hard disks and CPUs, the communication devices
`continuously draw power unless they can be suspended.
`A suspended hard disk or CPU can be restarted by any
`user requiring that device. However, when a communica-
`tion device is suspended, the mobile host is effectively cut
`off from the rest of the network. A mobile host with a sus-
`pended communication device can only guess about when
`other hosts may have data destined for it. If the suspension
`of the mobile host’s communication does not match prevail-
`ing communication patterns, the isolation can cause buffers
`to overflow both in the mobile host and in other hosts try-
`ing to communicate with it. Additionally, other hosts may
`waste precious resources trying to communicate with the
`mobile host if they have no knowledge about whether or
`not the mobile host’s communication is suspended.
`Our goal is to provide mechanisms for managing and
`reducing the power consumption of the communication de-
`vice. We present a simple model for mobile communication
`that provides adaptable functionality at the transport layer
`for suspending and resuming communication. By exposing
`this functionality to the application, we enable application-
`
`Page 1 of 15
`
`GOOGLE EXHIBIT 1017
`
`(cid:211)
`

`

`264
`
`R. Kravets, P. Krishnan / Application-driven power management for mobile communication
`
`driven solutions to power management. Power savings are
`attained by suspending communications and the commu-
`nication device for short periods of time. During these
`suspensions, data transmissions are queued up in both the
`mobile host and any other host trying to communicate with
`the mobile host. The key to balancing power savings and
`data delay lies in identifying when to suspend and restart
`communications. By abstracting power management to a
`higher level, we can exploit application-specific informa-
`tion about how to balance power savings and data delay.
`Intuitively, power conservation is achieved by accumu-
`lating the power savings from many small idle periods.
`We, however, need to be careful to monitor any addi-
`tional energy consumption caused while executing the sus-
`pend/resume strategies. Additionally, we need to consider
`the effect on other hosts who are trying to communicate
`with the suspended mobile host. A base station using our
`protocol has enough knowledge about the state of the mo-
`bile host to know when it is suspended and can use this
`information to help employ scheduling techniques. We im-
`plemented our protocol and experimentally determined its
`effect on power consumption and the quality of communi-
`cation. Using three simulated users designed to capture typ-
`ical mobile communication patterns and three trace-based
`web users, we obtained 48–83% savings in the power con-
`sumed by the communication subsystem, while introducing
`a small additional response delay (0.4–3.1 s depending on
`the power management level) that is acceptable for many
`applications, like web browsing.
`In section 2, we present our basic mobile communication
`model, and the important issues in power management for
`communication. In section 3 we present our power man-
`agement protocol and discuss the effect of timing issues on
`the effectiveness of our protocol. Section 4 describes our
`experimental setup and the communication patterns used
`in our experiments. We then present measurements from
`the implementation of our power management protocol and
`discuss the results in the context of several real systems.
`In section 5, we discuss adaptive control strategies and we
`present our conclusions in section 6.
`
`2. Communication model and power management
`
`The introduction of wireless links into communication
`systems based on wired links has posed a number of prob-
`lems. These problems include different loss characteristics
`and different bandwidth capabilities on the wired and the
`wireless line, synchronization of disconnected operations,
`and issues involving packet forwarding. These problems
`pose significant challenges for end-to-end communication
`protocols. Two types of models have been studied [4]. The
`first model exploits the natural hop existing in the commu-
`nication route to a mobile host. Standard communication
`protocols are used by wired hosts to a base station and spe-
`cialized protocols are used for the final hop from the base
`station to the mobile hosts [3]. The second model utilizes
`
`and tunes existing end-to-end protocols, providing help and
`hints along the way [5].
`In this paper, we focus on the first model of communi-
`cation described above, which allows us to isolate the com-
`munication between the base station and the mobile host.
`With some extensions, the technique is also applicable to
`the second model. We target our approach at the transport
`layer, where we provide a set of mechanisms that allow
`communication to be suspended and resumed. We assume
`a model where the mobile host is communicating with the
`rest of the network through a base station. This base sta-
`tion may be a proxy, or it may be the connection point for
`end-to-end communication with other hosts. Often, deal-
`ing with mobility does not fit into the standard seven layer
`model. By exposing power management techniques to the
`application, we provide a system-level solution aimed at
`end-to-end communication. For our experiments in this
`paper, we concentrate on the communication between the
`mobile host and the base station, and for clarity assume
`that all communication to and from the mobile host is di-
`rected through one specific base station. This work can be
`extended to include changing base stations through tech-
`niques similar to those used in [3,5].
`Current wireless communication devices typically oper-
`ate in two modes: transmit mode and receive mode. The
`transmit mode is used during data transmission. The re-
`ceive mode is the default mode for both receiving data and
`listening for incoming data. Much of the time, the wireless
`communication device sits idle in receive mode, and, while
`the power required for reception is less than the power
`required for transmission, this power consumption is not
`negligible. A number of solutions aimed at power manage-
`ment at the MAC or PHY layer have been proposed. With
`the IEEE 802.11 standard, compliant cards can exchange
`information about outstanding data to decide on when to
`wake up suspended cards. There are ongoing efforts to
`provide IEEE 802.11 compliant support for power manage-
`ment by introducing new features into the next generation
`wireless communication cards [17]. A comparison of ad-
`ditional MAC layer protocol solutions can be found in [6].
`Such approaches that rely solely on techniques provided
`by the device cannot take application specific information
`into consideration when determining power management
`strategies.
`In comparison, our approach exposes power
`management efforts to the application, allowing for better
`informed decisions as how much and when to use power
`management techniques. Researchers have also considered
`hardware-level solutions to provide low power communi-
`cation capabilities [24,26,28]. Such solutions reduce the
`power cost of operating in either one of the modes, and are
`orthogonal to our approach which addresses the amount of
`time the device spends in each mode.
`Logical areas to look for software-level power conserva-
`tion in communication are two-fold. Since data transmis-
`sion is expensive, we can reduce the time spent in trans-
`mission. This can be achieved by data reduction techniques
`and intelligent data transfer protocols. The obvious tech-
`
`Page 2 of 15
`
`

`

`R. Kravets, P. Krishnan / Application-driven power management for mobile communication
`
`265
`
`nique of data compression reduces the amount of transmis-
`sion time, but requires additional CPU cycles for perform-
`ing compression. The connection between compression and
`communication rates is studied in [10]. Through simple ex-
`periments, we observed that, considering the current power
`requirements of CPUs versus wireless communication de-
`vices, the benefit in terms of power savings from reduced
`communication time often outweighs the increased energy
`consumption costs for compression. Intelligent data trans-
`fer protocols can be used to reduce the effect of noisy con-
`nections that cause power-expensive retransmission of lost
`messages. Our continuing research addresses the assess-
`ment of the effects of different techniques for data reduc-
`tion, including reduced reliability requirements, and their
`effect on both power reduction and communication quality.
`The second area, and the emphasis of this paper, is the
`cost of leaving the communication device sitting idle dur-
`ing periods of no communication activity. During such idle
`periods, the communication device draws power listening
`for incoming data. Our goal in this work is to reduce the
`amount of time the device sits idle drawing power by ju-
`diciously suspending it. Suspending a wireless communi-
`cation device is similar to slowing a CPU in that there are
`some small power costs associated with suspension and re-
`sumption. As mentioned in section 1, the difficult part here
`is to deal with when to suspend and resume the commu-
`nication device, how to deal with the mobile host being
`unreachable at times, and how to address the issue of not
`losing en-route data. Our protocol and its implementation
`presented here address these problems. Since the protocol
`itself generates additional communication during these idle
`periods, there needs to be a balance between when it is
`beneficial to use the power management techniques, and
`when we should leave the device on continuously.
`In contrast to the solutions proposed by the IEEE 802.11
`standard, we believe that power management should be
`controlled by the mobile host, potentially even the appli-
`cation. By providing power control at the transport layer
`(or above), we can provide power management interfaces
`to the application, allowing the application to better control
`the communication, enabling adaptive power management
`driven by the needs of the application. Specifically, com-
`munications using the IEEE 802.11 standard will always
`pay the overhead of delays imposed by using power man-
`agement, while our techniques allow the application to de-
`termine when such delays are too high, and so adapt power
`management levels. Stemm et al. [29] have also investi-
`gated methods for reducing power consumption of network
`interfaces, specifically targeting their research at hand-held
`devices. Their research suggests application-specific solu-
`tions to such problems. In contrast, our research provides a
`general solution capable of hosting various strategies, both
`static and adaptive. Our measurements are with a real im-
`plementation of a power management protocol in an exper-
`imental setup. We are, therefore, able to observe the effects
`of the queuing of data and the real effect of extra energy
`consumption by such a protocol. We measure the power
`
`consumption in the context of the entire system, consider-
`ing such costs as message processing and disk accesses, for
`various simulated workloads that we expect mobile users
`to perform.
`
`3. Communication-based power management
`
`leaves its wireless
`Currently, a typical mobile host
`Ethernet card in receive mode during the time it is not be-
`ing used, unless the user explicitly removes the card. The
`technique described in this section provides mechanisms to
`extend battery lifetime by suspending the wireless Ethernet
`card during idle periods in communication. At the heart of
`the technique lies a protocol where the mobile host acts as
`a master and tells the base station when data transmission
`can occur. When the mobile host wakes up, it sends a query
`to the base station to see if the base station has any data
`to send. This permits communication device suspension at
`the mobile host, and enables the implementation of com-
`munication scheduling techniques at the base station. The
`suspend/resume cycle results in bursts of communication
`that may be followed by periods of inactivity. Although
`producing such bursty communication may incur additional
`delay, bursty communication patterns lend themselves well
`to efficient scheduling techniques.
`With the suspension of a communication device, a mo-
`bile host will experience an additional delay in data trans-
`mission since data on both the sending and receiving sides
`may be held up during suspension. The mobile host can
`monitor its own outgoing communication patterns to insure
`that, despite these suspension times, communication contin-
`ues smoothly without buffer overflow. The base station, on
`the other hand, has no means to restart communication if it
`notices that it is running out of buffer space. It is up to the
`mobile host to understand the base station’s expected com-
`munication patterns so that the buffers at the base station
`do not overflow. In order to efficiently use our power man-
`agement techniques, our communication layer must monitor
`the communication patterns of the mobile host and match
`the suspend/resume cycle to these patterns.
`The protocol we describe in this section allows a mobile
`host to suspend a wireless communication device. Periodi-
`cally, or by request from the application, the protocol wakes
`up and reinitiates communication with the base station. In
`the rest of this section, we will describe our power man-
`agement protocol in detail and discuss the significance of
`some of the timing parameters. Appendix A describes in
`detail the commands used by the protocol and the possible
`states and state transitions for both the master and slave.
`
`3.1. Power management control protocol
`
`In this protocol, the mobile host is the master and the
`base station acts like a slave. The slave is only allowed to
`send data to the master during specific phases of the proto-
`col. During non-transmit phases, the slave queues up data
`
`Page 3 of 15
`
`

`

`266
`
`R. Kravets, P. Krishnan / Application-driven power management for mobile communication
`
`Figure 1. Slave (base station) protocol state diagram.
`
`Figure 2. Master (mobile host) protocol state diagram.
`
`and waits for commands from the master. Idle periods for
`both the master and the slave can be detected through the
`use of idle timers or indicated to the protocol from the ap-
`plication. In the protocol state diagrams for the master and
`the slave (figures 1 and 2), IN: indicates an input event that
`can be either an incoming message or a timeout, Q: indi-
`cates the state of the queue, and OUT: indicates an outgoing
`response message.
`As shown in figure 1, the slave is initialized to be in
`the SLEEPING mode. It can only leave that mode upon a
`WAKE UP message from the master. If the slave has data
`to send, it will enter the SEND RECV mode. The slave will
`stay in this mode until it has detected that it has no more
`data to transmit, whereupon, it will send a DONE message
`to the master, enter the RECEIVING mode, and continue
`
`receiving until it receives a SLEEP message. If during this
`time the slave detects that there is new data to transmit,
`it will send a NEW DATA message to the master and enter
`the RECEIVING WAIT mode. The slave can only start
`to transmit when it receives a WAKE UP message from the
`master. If a SLEEP message is received first, the waiting
`data stays buffered and is not transmitted until the next
`resume cycle.
`Although the state diagram for the master (figure 2) is
`much more complex, we can see that the states may be
`partitioned into three sets. The first set (SLEEPING) con-
`cerns the master when it is sleeping. When the master is in
`the SLEEPING mode, it can be woken up by one of two
`triggers: a wakeup timer or new data to transmit.
`If the
`wakeup timer expires, the master sends a WAKE UP mes-
`
`Page 4 of 15
`
`

`

`R. Kravets, P. Krishnan / Application-driven power management for mobile communication
`
`267
`
`sage along with any new data to the slave. If there is new
`data to transmit to the slave before the wakeup timer ex-
`pires, the master has the option to wake up and transmit
`this new data, or continue sleeping and queue up the data
`until the timeout expires.
`The second set of states (SENDING WAIT, WAITING,
`and WAIT FOR OK) concerns the master when it is waiting
`for a response from the slave about whether or not the slave
`has data to send. In the SENDING WAIT mode, the master
`is transmitting data and in the WAITING mode it has no
`data to transmit. When the master receives a response from
`the slave in the form of a DATA or a NO DATA message,
`the master enters the appropriate state in the third set. Ad-
`ditionally, if while in the SENDING WAIT mode an idle
`timer expires indicating that the master has no more data to
`send, the master enters the WAITING mode and continues
`waiting for a response from the slave. In the WAIT FOR OK
`mode, the master has told the slave that it should sleep and
`is waiting for a SLEEP OK message.
`When the master is in one of the final set of states
`(SENDING, SEND/RECV, and RECEIVING), it is actively
`sending and/or receiving data. In the SENDING mode, the
`master may receive a NEW DATA message from the slave.
`The master responds with a WAKE UP message and enters
`the SENDING WAIT mode. When neither the master nor
`the slave have any more data to send, the master sends a
`SLEEP message and enters the WAIT FOR OK mode.
`Wireless connections are very susceptible to interference
`from both external devices and other wireless devices using
`the same settings or talking to the same base station. By
`using this protocol, we provide the base station with useful
`information about the communication patterns of the mo-
`bile host. Although not required by the protocol, the master
`can inform the slave of its sleep time, or the slave can sug-
`gest appropriate sleep times to the master. If the protocol
`is used such that only prespecified timeouts trigger restart-
`ing communication, the slave can design a communication
`scheduling algorithm based around the known sleep time of
`the master. Additionally, if the sleep times for the master
`are sufficiently long, the slave can save any data destined
`for the master to disk. This will free the buffer space being
`used by the data destined for the master so it can be used
`for other active communications.
`
`3.2. Timing considerations
`
`Timing is a key issue for both the performance of the
`mobile host as well as the amount of power that can be
`saved. If the wireless Ethernet card is suspended too often,
`the user will see lags in data transfer performance. On the
`other hand, if it is not suspended long enough, the gain in
`battery life time may be undetectable.
`In order to determine when the card should be sus-
`pended, the protocol needs to determine the communica-
`tion patterns for both sender and receiver. There are two
`ways by which idle periods in the communication can be
`detected. The first, and simplest, is when the application
`
`can actually inform the protocol that it does not have any
`data to send. This requires a more complex application that
`has information about its communication patterns. The sec-
`ond method is to use a timer set with a timeout period. If
`the timer expires and no communication has occurred since
`the last expiration, the protocol concludes that there is an
`idle period in the communication. The appropriate time-
`out period depends on the requirements of the application.
`Timeout periods that are too short may cause the proto-
`col to go to sleep prematurely, resulting in poor response
`time for applications dependent on communication. On the
`other hand, timeout periods that are too long may cause the
`protocol and the communication device to remain active
`for unnecessarily long periods of time, wasting precious
`energy.
`The other timing parameter is the sleep duration which
`defines how long the master should keep the communica-
`tion suspended. The appropriate sleep duration also de-
`pends on the requirements of the application. Longer sleep
`periods will cause longer lags in any interactive applica-
`tions. Shorter sleep periods will not extend battery life-
`time appreciatively. The application needs to determine the
`appropriate tradeoff for battery lifetime versus delay.
`In
`many instances, the expected time and data size for the
`response to a request initiated by the mobile host can be
`estimated. This includes, for example, applications like
`mail, web browsing, and file transfer. In this context, hints
`provided by the application could be very helpful. In our
`experiments reported in section 4, we examine the effects
`of fixed timeouts that require no application support and
`can be implemented within the transport layer. Adaptively
`varying the timeouts or using learning techniques are dis-
`cussed in section 5.
`A mobile host that is running multiple applications can-
`not base its power strategy on the expected communication
`patterns of a single application. In this situation, the power
`management protocol must take hints about sleep/wake up
`durations for all executing applications. By exposing power
`management to the application, and hence to the user, our
`power management protocol can be guided in the appropri-
`ate allocation of resources.
`A final consideration is the time required to wake up
`and shut down the specific wireless network card. Our
`protocol is designed to be independent of the specific card
`being used. Since our techniques address issues regarding
`the end-to-end transmission of data, we assume that this
`wakeup time is minimal in comparison to the total trans-
`fer time. Although this may not be true for all devices
`currently, the interface standards proposed in [1] suggest
`that future devices will provide relatively inexpensive tran-
`sitions between waking and sleeping states.
`
`4. Experiments
`
`The goal of our experiments is to show that, by using our
`power management techniques, we can save a significant
`
`Page 5 of 15
`
`

`

`268
`
`R. Kravets, P. Krishnan / Application-driven power management for mobile communication
`
`amount of the power consumed by the wireless Ethernet
`card. The tradeoff is an increased transmission delay ob-
`served by the receiver. First we will present our experimen-
`tal setup and the user communication patterns used in our
`experiments. We will then show the impact of the power
`management techniques in the context of these user com-
`munication patterns. Finally, we will discuss our results in
`the context of several real systems.
`
`4.1. Power measurement
`
`In order to understand how to accomplish such commu-
`nication-based power management, we first need to define
`what we mean by the amount of power consumed by data
`communication. Previous work in this area has defined this
`to be the amount of power consumed by the communication
`device itself. We believe this is too limited a view, since it
`does not take the impact of the system power consumption
`into consideration. Our model considers three aspects of
`power consumption that cover the whole system.
`Our measurement model is derived from the actual mea-
`surement of power consumed by the whole machine. By
`doing this, we limit ourselves from being able to single out
`the power consumption of individual devices, but instead,
`we are able to consider the power consumption of actions
`performed on the machine. Figures 3 and 4 show two
`sample power measurements for a mobile host. Figure 3
`represents no power management and figure 4 represents
`the effects of power management.
`If we consider the actions taken by the mobile host in
`figure 3, the first time period represents the power con-
`
`Figure 3. Example power consumption without power management.
`
`Figure 4. Example power consumption with power management.
`
`sumption of the idle machine over time. This is the base
`amount, indicated by the power level A, that will always be
`consumed even when the machine is idle. In the next time
`period, a wireless communication device is activated, and
`this area represents the power consumed by the idle ma-
`chine and the wireless communication device. The power
`consumed by the communication device is the section be-
`tween power levels A and B. Next, the mobile host is
`actively communicating. This area represents the power
`consumed by the wireless communication device for data
`transmission as well as any power consumed by the CPU
`during data and protocol processing for transmission and
`reception.
`In this paper, we aim our efforts at reducing the amount
`of power consumed when the communication is idle. From
`the power management techniques reflected in figure 4, we
`see that there is a fluctuation of the amount of power con-
`sumed during idle periods in the communication. The lower
`levels of power consumption represent the effort of our
`power management techniques. The spikes in the power
`consumption represents the overhead, both CPU power con-
`sumption and communication device power consumption,
`during our power management efforts. For all of the ex-
`periments described in the next section, we consider the
`power consumption above power level A to be attributed
`to communication.
`This view of power management allows the individ-
`ual devices to perform their own power management tech-
`niques. For example, our techniques do not tell the CPU
`when to suspend or sleep or tell the wireless communica-
`tion device how to manage power during active communi-
`cation. Instead, we are concerned with reducing the power
`attributed to ongoing communication. Therefore, we do not
`try to separate the power consumed by the CPU during pro-
`tocol and data processing and power management from the
`power consumed by the wireless communication device.
`
`4.2. Experimental setup
`
`In order to determine the impact of our power man-
`agement techniques, we measure the power consumption
`of a wireless Ethernet card under varying conditions.
`In
`our experiments, we use a 915 MHz Lucent WaveLAN
`PCMCIA wireless Ethernet card that can transmit data up
`to 150 KBps.
`It provides three power modes:
`transmit,
`receive and suspend, and does not perform power man-
`agement at the MAC layer. The system is configured as
`shown in figure 5, with a wireless Ethernet in a NEC Versa
`6320 laptop (the mobile host) communicating with a Gate-
`way Solo 2200 (the base station) using a second WaveLAN
`PCMCIA card, both machines running Linux. We plugged
`the laptop into a universal power supply (UPS) to filter out
`any fluctuations in the wall voltage. Our multimeter sam-
`ples the current 11–12 times a second. From these samples
`and the output voltage of the UPS, we can monitor the
`power being used by the computer.
`
`Page 6 of 15
`
`

`

`R. Kravets, P. Krishnan / Application-driven power management for mobile communication
`
`269
`
`Table 1
`Power requirements of the Lucent WaveLAN PCMCIA wireless Ethernet
`card.
`
`State
`
`Documented
`
`Measured
`
`WaveLAN – suspended
`WaveLAN – receive
`WaveLAN – transmit
`
`0 W
`1.48 W
`3.00 W
`
`0 W
`1.52 W
`3.10 W
`
`period of 30 min to provide sufficiently long samples. To
`ensure stability in our reported numbers, we repeated our
`experiments several times for each scenario. The results
`presented in this section were taken from specific sample
`runs. Each individual run was chosen from a set of quali-
`tatively similar runs of a particular experiment.
`According to manufacturer specifications [31], the power
`requirements of the WaveLAN card are those shown in ta-
`ble 1, column 2. Column 3 in table 1 shows the power
`requirements measured during our experiments without any
`power management. The measurements for receive mode
`were taken while the computer was idle, which implied no
`extra disk or CPU activity. As mentioned earlier, the power
`consumption for transmission includes any incidental CPU
`and hard disk power consumed to effect communication.
`It is interesting to note that the transmitter is rarely at full
`power for long periods of time. We observe that our mea-
`surements of the power required while the device is in either
`mode are very close to the documented specification.
`For an example of the different levels of power con-
`sumption, again consider figures 6 and 7, which show sam-
`ple traces for the power consumed over a period of time for
`the NEC Versa. From our measurements, we determined
`that the laptop consumes around 14 W when idle. With
`the WaveLAN card inserted, the laptop consumes 15.5 W
`when idle. From this information, we consider any power
`consumed over the 14 W idle power consumption to be
`contributed to the ongoing communication. Our goal is
`to conserve as much of the 1.5 W consumed by the idle
`communication device. Addition