Power Management Implementation

Transcription

1 1 Background Power Management Implementation -Santosh Kumar, Anish Arora, OSU, and Young-ri Choi, Mohamed Gouda, University of Texas at Austin 1.1 Sleep Modes There are six power level states in the MCU. The sleep mode depends on the value of three bits in the MCU Control Register SM2, SM1, SM0. In the following these three bits are referred to as the sleep register. The SE bit has to be set to 1 to make the CPU enter the sleep mode when the SLEEP instruction is executed. It is recommended to set the SE bit before the execution of the SLEEP instruction and to clear it after waking up. 1. Idle Mode When the sleep register has value of 000 and the SLEEP instruction is executed, the processor goes into Idle mode. The CPU is stopped but the SPI, USART, Analog Comparator, Two wire serial interface, Timer/Counters, Watchdog, and the interrupt system continue operating. This mode halts clk CPU, and clk flash. If wakeup from Analog Comparator interrupt is not required, the Analog Comparator can be powered down by setting the ACD bit in the Analog Comparator and Control Status Register ACSR. If the ADC is enabled, a conversion is started automatically when this mode is entered. Wakeup From: External triggered interrupts as well as internal ones like the Timer overflow and USART Transmit Complete. 2. ADC Noise Reduction Mode When the sleep register has value 001, and the SLEEP instruction is executed, the CPU enters the ADC Noise Reduction mode. As compared to the Idle mode, SPI, USART, and the Analog Comparator are also stopped in addition to the CPU. Compared to the Idle mode, clk I/O is also stopped. This mode improves the noise environment for the ADC. Wakeup From: Apart from the ADC conversion complete, only an External Reset, a Watchdog reset, a Brown-out Reset, a Two-wire Serial Interface address match interrupt, a Timer/Counter0 interrupt, an SPM/EEPROM ready interrupt, an External Level interrupt on INT7:4, or an External Interrupt on INT3:0 can wake up the MCU from this sleep mode. 3. Power-down Mode - When the sleep register has value 010, and the SLEEP instruction is executed, the CPU enters the Power-down mode. In this mode, the External Oscillator is stopped, while the External Interrupts, the Two-wire Serial Interface address match, and the Watchdog continue operating (if enabled). This sleep mode halts all generated clocks, allowing operation of asynchronous modules only. If a level triggered interrupt in used to wake up the CPU, the changed level must be held for some time to wake up the CPU. Wakeup From: an External Reset, a Watchdog Reset, a Brown-out Reset, a Twowire Serial Interface address match interrupt, an External Level Interrupt on INT7:4, or an External Interrupt 3:0 can wake up the MCU from this mode. 1/10 1/25/2005

2 4. Power-save Mode - When the sleep register has value 011, and the SLEEP instruction is executed, the CPU enters the Power-save mode. This mode is identical to the Power-down mode with one exception If Timer/Counter0 is clocked asynchronously, i.e., the AS0 bit in ASSR is set, Timer/Counter0 will run during sleep. The MCU can wakeup either from a Timer Overflow or Output Compare event from Timer/Counter0 if the corresponding Timer/Counter0 interrupt enable bits are set in TIMSK, and the global interrupt enable bit in SREG is set. 5. Standby Mode - When the sleep register has value 110, and the SLEEP instruction is executed, the CPU enters the Standby mode. This mode is identical to the Power-down mode with one exception The oscillator is kept running. The CPU wakes up in six clock cycles from this mode. 6. Standby Mode - When the sleep register has value 111, and the SLEEP instruction is executed, the CPU enters the Extended Standby mode. This mode is identical to the Power-save mode with one exception The oscillator is kept running. The CPU wakes up in six clock cycles from this mode. 1.2 Minimizing Power Consumption The following guidelines should be used for minimizing the energy consumption. ADC If enabled, the ADC will be enabled in all modes. To save power ADC should be disabled before entering a sleep mode. Analog Comparator When entering Idle or ADC Noise Reduction mode, the Analog Comparator should be disabled if not used. In other sleep modes, the Analog Comparator is automatically disabled. However, if the Analog Comparator is set up to use the Internal Voltage Reference as input, the Analog Comparator should be disabled in all sleep modes. Brown-out Detector This module should be turned off (if not needed). If the Brown-out detector is enabled by the BODEN fuse, it will be enabled in all sleep modes. Internal Voltage Reference The Internal Voltage Reference will be enabled when needed by the Brown-out Detector, the Analog Comparator, or the ADC. If these modules are disabled, the Internal Voltage Reference will be disabled and will not consume power. Watchdog Timer This module should be turned off, if it is not needed. If it is enabled, it will be on in all sleep modes. Port Pins When entering a sleep mode, all port pins should be configured to use minimum power. In sleep modes where both the I/O clock and the ADC clock are stopped, the input buffers of the device will be disabled. This ensures that no power is consumed by the input logic when not needed. In some cases, the input logic is needed for detecting the wakeup conditions, and it will then be enabled. JTAG Interface and On-chip Debug System If the On-chip debug system is enabled by the OCDEN Fuse and the chip enter Power don or Power save mode, the main clock source remains enabled. There are three alternative ways to avoid this: Disable OCDEN Fuse. 2/10 1/25/2005

3 Disable JTAGEN Fuse. Write one to the JTD bit in MCUCSR. The TDO pin is left floating when the JTAG interface is enabled while the JTAG TAP controller is not shifting data. If the hardware connected to the TDO pin does not pull up the logic level, power consumption will increase. Note that the TDI pin for the nest device in the scan chain contains a pull-up that avoids this problem. Writing the JTD bit in the MCUCSR register to one or leaving the JTAG fuse unprogrammed disables the JTAG interface. 1.3 Precautions The following precautions should be exercised during power management implementation: When entering Power-save or Extended Standby mode after having written to TCNT0, OCR0, or TCCR0, the user must wait until the written register has been updated if Timer/Counter0 is used to wakeup the device. Otherwise, the MCU will enter sleep mode before the changes are effective. This is particularly important if the Output Compare0 interrupt is used to wakeup the device since the output compare function is disabled during writing to OCR0 or TCNT0. If the write cycle is not finished, and the MCU enters a sleep mode before the OCR0UB bit returns to zero, the device will never receive a compare match interrupt, and the MCU will not wakeup. If Timer;/Counter0 is used to wakeup the device from Power-save or Extended Standby mode, precautions must be taken if the user wants to re-enter one of these modes: The interrupt logic needs one TOSC1 cycle to be reset. If the time between wakeup and re-entering sleep mode is less than one TOSC1 cycle, the interrupt will not occur, and the device will fail to wakeup. If the user is in doubt whether the time before re-entering Power-save or Extended Standby mode is sufficient, the following algorithm can be used to ensure that one TOSC1 cycle has elapsed: 1. Write a value to TCCR0, TCNT0, or OCR0. 2. Wait until the corresponding Update Busy flag in ASSR returns to zero. 3. Enter Power-save or Extended Standby mode. When the asynchronous operation is selected, the khz Oscillator for Timer/Counter0 is always running, except in Power-down and Standby modes. After a Power-up Reset or wakeup from Power-down or Standby mode, the user should be aware of the fact that this Oscillator might take as long as one second to stabilize. The user is advised to wait for at least one second before using Timer/Counter0 after power-up or wakeup from Power-down or Standby modes. The contents of all Timer/Counter0 Registers must be considered lost after a wakeup from Power-down or Standby mode due to unstable clock signal upon start-up, no matter whether the Oscillator is in use or a clock signal is applied to the TOSC1 pin. Wakeup from Power-down or Extended Standby mode when the timer is clocked asynchronously: When the interrupt condition is met, the wake up process is started the following cycle of the timer clock, i.e., the timer is always advanced by 3/10 1/25/2005

4 at least one before the processor can read the counter value. After wakeup, the MCU is halted for four cycles, it executes the interrupt routine, and resumes execution from the instruction following SLEEP. 2 Power Management Functionality in TinyOS 2.1 Putting a Mote to Sleep The power management application should call HPLPowerManagement.Enable() in its StdControl.Init() and ensure the following: The radio is off (call CC1000RadioC.StdControl.stop()). All high speed clock interrupts are disabled. SPI interrupt is disabled. The task queue is empty. Then, the mote will enter sleep mode upon the next clock tick. In addition to the radio, each service has to be stopped. Further, in the Stop() function, each service should call HPLPowerManagement.adjustPower(). Applications need not call HPLPowerManagement.adjustPower(). 2.2 Wake Up If the mote is put to sleep using HPLPowerManagement, then it will wakeup on the next 32 khz Timer interrupt. 3 Usage Scenario The following usage scenario are under consideration: 1. The motes will either be in a POWER_DOWN state or completely off, depending on whether there is a on-off button or not. 2. The motes will be either sent an interrupt via pressing the user button or put on by pressing the on switch. 3. Upon first activation (either via on switch or via user button), the motes will execute the factory image power management code. 4. After all the motes and stargates have been deployed, the network will be woken up at about the same time for network reprogramming. The ExScal power management code will be part of this new program. 5. After reprogramming all the sections, except for a few will be put to sleep. It is assumed that time synchronization will be completed before the network is put to sleep. The few sections that are awake (or are woken up after the entire network was put to sleep), will be used for the testing purpose. After testing is complete, these sections will also be put to sleep. 6. Every day of testing, some new sections will be woken up (if the testing scenario does not force the usage of the same section that was tested on an earlier day). The rest of the network will continue to sleep. 4/10 1/25/2005

5 7. The entire network will be woken up under three conditions: a. It is a demo day. b. The entire network needs to be reprogrammed. c. It is a dry run, although it is not necessary to wakeup the entire network for dry run since all sections are homogenous. The dry run is also a form of testing. 8. In order to conserve even more energy, we may want to allow some motes to sleep even when the sections to which these motes belong, is active. In this case Randomized Independent Sleeping proposed in [1] may be used. The sleeping will with such a probability that a communication cover is maintained. This strategy may get the lifetime of the network to a lifetime of 30 days or more. 3 Power Management Protocol Proposals for Off-Duty Sleeping There are currently three proposals for a Power Management Protocol: 3.1 Using 1% Duty Cycle In this approach, proposed by UCB, the processor is put into POWER_SAVE or POWER_DOWN mode (yet to be known), all components are put off. However, the radio is still on, but on a 1% duty cycle. The energy consumption of this sleeping mode is 130 ua on mica2. The processor wakes up periodically to check if any preamble bits have arrived. The checking is done at 1/100 th the frequency it is done when the radio is fully on. When it is time to wakeup the motes, a message (soft-on) is flooded in the network. The first mote to propagate this message and every other mote forwarding this message should send a long preamble in order to communicate with the sleeping motes. This message is retransmitted by the receiving motes several times before a timer expires. After the timer is expired, the motes come to short preamble mode. To take care of waking up 100% of the network, it is proposed that in the event of having knowledge of some motes missing the wakeup message, the motes will come back to the long preamble mode and will repeatedly transmit the wakeup message. A good model is yet to be found by which we can compute how long it will take the network to wakeup since the initiation of the wakeup message. A rough model has been proposed for now. It takes seconds to transmit one long preamble. Combine this with random delay introduced at the MAC layer, and combine it with probability of losing a message, we can derive the time it will take to wake up a multi-hop network. A different type of message (soft-off) is propagated to put the motes back to sleep. The motes put their processor to sleep, and bring their radio down to a 1% duty cycle. Again, the exact protocol that ensures 100% of the intended portion of the network is put to sleep, is yet to be established. Advantages: 5/10 1/25/2005

6 The motes wakeup only when they are needed. This can lead to a simpler protocol as well as energy savings. Time synchronization is not required. Disadvantages: The protocol to take care of stragglers in both phases (sleep and wakeup) is yet to be decided. Unknowns: The exact protocol for sleep and wakeup of a multi-hop network. A model to compute the latency of waking up the entire network (one section). Proposal for enhancement: In every flood, only the first message received by any mote is forwarded, provided the hop count is positive. After receiving the first message, any mote does not forward similar messages. Instead, it sends the wakeup (or sleep) message by itself. It tries to send it k times, once every 2 seconds. Further, every time the mote tries to send the message, it decides to send it with probability p. The hop count in these messages is the same as was received in the original wakeup (or sleep) message, after decrementing it by one. The values of k and p will be chosen based on the number of neighbors in order to minimize the probability of hidden terminal collision, but ensuring that at least one message is sent in every neighborhood successfully with a high probability. 3.2 Real Time Clock-based Sleeping In this approach, proposed by UIowa and UTexas, there is only one type of message is used. This message has two parameters: TBS and TTW, where TBS is the time before the motes should go to sleep (typically in seconds), and TTW is the time to wakeup, i.e. time the motes should sleep for (typically in hours). When it is time to put the network to sleep (or a portion of it), a user decides how many hours the motes should be put to sleep, and send a sleep message to the intended sections of the network. This message is flooded sufficient number of times (to be found by experimentation) to ensure all the intended motes receive it. All the motes receiving this message go to sleep, wakeup every 8 minutes to decrement a counter, and go back to sleep. When the counter hits zero (time to wakeup received in the sleep message), the motes wakeup. If it is desired to make them sleep longer, another sleep message set has to be initiated. Advantages: The protocol is simple. It uses only one type of message. Except for a processor wakeup every 8 minutes to decrement the counter, motes do not wakeup. As a result, they consume very little energy when they are asleep. Disadvantages: It is not possible to wakeup the sleeping motes before TTW. 6/10 1/25/2005

7 It is hard to decide how much time the motes should be put to sleep. Further, if the motes need to continue to sleep longer than was originally decided, a sleep message should be sent immediately after they wakeup. If the sleep message is not sent immediately, the motes may be active for no reason and will waste energy. However, it is possible to write an application at Tier3 that will keep track of the TTW expiration of each section and will continue sending a sleep message with a preconfigured TTW, if it has not heard otherwise from a user for a particular section. Unknowns: Whether it is possible to implement a Real-Time Clock in XSM motes. TBS value to be used in ExScal network. 3.3 Request-Reply based Sleeping In this approach, proposed by OSU and UTexas, there are three types of messages: RTW, PTW, and CTS, where RTW is the request for wakeup, PTW is the permission to wakeup, and CTS is the command to sleep. There is a preconfigured time that motes sleep for SP, (e.g. 15 minutes) and a preconfigured time that they wakeup to check if they should remain awake WP, (e.g. 2 seconds). When it is time to put the motes to sleep, a CTS message is propagated via the routing tree that is already in place. After receiving an acknowledgement for the receipt of this message the sender motes go to sleep. The CTS message is flooded only once. Upon analysis, it will be decided whether there is a need to flood it more than once. The CTS message will have a hop count to limit its reach. The motes are in three states, Sleeping, Active_Self, and Active_Others. If they are in Sleeping mode, they sleep for SP time units, wakeup for WP time units, broadcast a RTW message after a delay chosen exponentially in the WP interval, and go back to sleep for SP time units, if they do not hear a CTS message. The CTS message is a broadcast message and so it wakes up all motes hearing such a message. Upon receipt of a CTS message, the motes change state to Active_Self or Active_Others, depending on whether the CTS message had a zero hop count or a positive hop count. If during the Active_Others state, a mote hears a RTW message, it sends a CTS message after decrementing the hop count by one. Advantages: The protocol guarantees that 100% of the network will be woken up, within 2 SP with a high probability. The protocol is suitable to wakeup only intended sections of motes without disturbing the motes who should be sleeping. The energy consumption during the SP is minimal. User intervention is minimized since a user needs to intervene only when it is time to wakeup a section and when it is time to put a section to sleep. Timer based or real time clock based sleep/wakeup can be easily implemented. The protocol is reusable across other networks/platforms. 7/10 1/25/2005

8 Disadvantages: The protocol is complex since it involves multiple states and multiple types of messages. The protocol requires motes to wakeup after every SP. Unknowns: SP, WP 4 Power Management Protocols for On-Duty Sleeping Sleeping during active duty is being explored because in a sensor network deployed for intrusion detection, most of the time there are no activities for a given mote, but it remains active nevertheless, drastically reducing the network lifetime. Furthermore, due to the hard constraints on the latency of notification in the event of an intrusion render most of the power management schemes proposed in the literature unsuitable. We are considering the following three alternatives for On-Duty Sleeping: 4.1 Maintaining a Communication Backbone The radio consumes 8mA of current when it is active. Transmitting a packet consumes 16mA of current. In a sensor network deployed for classification and tracking, typically there is k-coverage, where k > 1. Further, the communication radius is typically larger than sensing radius of most sensors. As a result, connectivity redundancy exists in such sensor networks. Exploiting this redundancy presents one solution to the On-Duty Sleeping for intrusion detection. During active duty, all the sensors are active. The microprocessor can be put to sleep as well, if the sensors (or one of the sensors) have the ability to reliably detect an event in the hardware. In such a case, microprocessor can be put to sleep in all the motes (saving 8mA of current). The radio can be put to sleep on all motes except those necessary to maintain a communication backbone (additional saving 8mA or more of current). The exact method of how to select the backbone and how to rotate this job is yet to be decided. When an event of interest happens, the sensors wakeup the microprocessor, the detection data is analyzed and should a packet be sent, the radio is turned on and the message is sent to one of the motes that is part of the backbone. The exact protocol of deciding the first-hop neighbor for a sleeping mote is yet to be decided. Using this protocol, significant lifetime extension is achievable. If x fraction of the motes are needed to maintain a communication backbone, then approximately the new active 8/10 1/25/2005

9 lifetime can be as much as 20/(20*x+5*(1-x)) times the original active lifetime 1. For instance, if x=0.25, then the new active lifetime will be as much as times the original active lifetime, while preserving the level of coverage and a micro increase in the latency of notification (due to the startup of the radio). If the hardware detection of no sensor is reliable enough, then the microprocessor will have to remain. In this case, only 8mA of current will be saved on a sleeping mote and the lifetime increase will be 20/(20*x+13*(1-x)) times. 4.2 Radio-Based Wakeup This protocol is a step further from the one proposed in 0Section 4.1. In this protocol, it is assumed that the motes can be woken up by sending a wakeup message. If this is the case, then the radio (and microprocessor, if the hardware wakeup on some sensor is reliable) on all motes can be turned off. When an intrusion happens, the sensors wakeup the microprocessor, the microprocessor wakes up its parent mote for propagating the notification towards the base station (if its parent was not already woken up by the intrusion detection event). The energy saving in this protocol can be as much as 20/5 = 4 times of the original active lifetime, if the microprocessor can be put to sleep, and 20/13 = times, if the microprocessor has to remain awake. However, the latency of event notification in this case may be longer because the motes on the way from the detection region up to the base station may have to be woken up taking one radio wakeup time on every hop. For example, if the radio is put on 1% duty cycle, then the radio wakeup latency is large as 2 seconds for a single hop. If the duty cycle of radio is increased to 11.5%, the not only the energy consumption of the radio increases to close to 1mA but the microprocessor has to wakeup more often to check for a preamble. If the microprocessor has to be awake anyway because of the unreliable detection of sensors in the hardware, then energy consumption of microprocessor is no longer an issue. Another problem to be solved in this protocol is the issue of routing since all the radio are off. One solution is to periodically wakeup the entire network (or just the communication backbone) to maintain a routing structure. 4.3 Partitioning the Network This protocol exploits the observation that often sensor networks have more redundancy of coverage than necessary. In such a case, the network can be partitioned into t parts such that one of the parts is enough to reliably detect and classify an intruder. Using the localization information, the motes are given a partition number and a sleeping schedule from the base station. The active time is divided into periods and only one part is active in any period. If the network can be divided into two equal parts, then the network 1 We have assumed that the average current in a fully active mote is 20 ma and that in a mote with only the sensors on is 5 ma. 9/10 1/25/2005

10 lifetime can be increased by twofold. The different periods will have a little overlap, i.e. the motes going to sleep will wait for some time before falling asleep, so that all the motes in the part to become active in this period have woken up and taken charge. The implementation of this protocol is simpler in the Extreme Scaling architecture, since the localization information can be used to partition the network and one wrapper can be put around routing which filters out any routing messages from motes not part of the same partition. This protocol however, reduces the level of coverage present in the network. References: [1] S. Kumar, T. H. Lai and J. Balogh, On k-coverage in a Mostly Sleeping Sensor Network, To appear in ACM MobiCom 2004, Philadelphia, USA. 10/10 1/25/2005