Power Management Support to Optimal Duty-Cycling in ... - IEEE Xplore

5 downloads 0 Views 890KB Size Report
Power Management Support to Optimal Duty-Cycling in Stateful Multitasking WSN ... infrastructure for WSN, with support for heterogeneous, concur-.
2013 12th IEEE International Conference on Trust, Security and Privacy in Computing and Communications

Power Management Support to Optimal Duty-Cycling in Stateful Multitasking WSN Carlo Brandolese, William Fornaciari, Luigi Rucco Politecnico di Milano – DEIB Piazza L. Da Vinci, 32 – 20133 Milano, Italy {brandole,fornacia,rucco}@elet.polimi.it

Abstract—The present work proposes a power management infrastructure for WSN, with support for heterogeneous, concurrent applications that need to preserve their status during deepidle periods. There are two main original contributions: i) the definition and implementation of an integrated and general power management infrastructure, transparent to the end user and supporting heterogeneous concurrent applications; ii) a rigorous model for the optimal choice of the power management policy, considering also set points at the lowest possible power state (power-off) with no memory retention. The power management infrastructure is based on the framework proposed in a previous work and this paper details the architecture and the interaction of its core modules. The whole system has been implemented on a prototype version of the PoliNode infrastructure and Miosix operating system. Results show energy gain up to 98%, varying with the period and size of the applications.

field. For these reasons, though largely considered as a promising technology, WSN encountered low-acceptance outside academia and research contexts. The only possible way to foster the diffusion of such a technology passes through the gradual pruning of the limitations affecting the hardware, the operating system and the application support layers. In this direction we proposed a general framework [1] which combines high-end performances—thanks to a more powerful hardware architecture and OS features—with a very low-power operation profile obtained through an hibernation mechanism and a smart sensing paradigm, both transparent to the end user. In particular, support to multitasking in the network has been provided by introducing process-based programming paradigm, memory isolation and protection, dynamic linking, standard C and C++ libraries and a power management layer for optimizing the duty cycle in presence of multiple application periods and requirements. To fully understand the role of the proposed power management mechanism a description of the whole framework is provided, with particular attention to the interaction between the various modules and how they concur to optimize the duty-cycle of a node transparently to the end user. The key idea driving the entire framework is the completely decoupling of the three main operation phases of a WSN, that is sensing from processing and both from communication. This is actually a change of perspective with respect to classical approaches that consider sensing as part of the application. The paper is organized as follows. The motivation will be presented in Section II, while Section III provides on overview on the related work. Section IV describes the overall approach, with particular focus on the interactions between the various modules and the hibernation mechanism, while Section VI provides an explanatory example of the system operation. Section V details the hibernation scheme, which, as said, is the focus of the present paper. Results obtained from intensive simulation and from a prototype implementation of the proposed framework are summarized in Section VII. Finally, Section VIII collects some concluding considerations.

I. I NTRODUCTION Wireless Sensor Networks(WSN) are a class of embedded, pervasive systems composed by small and inexpensive computing devices—the nodes—typically provided with a low-power microcontroller, a transceiver and some sensors for monitoring environmental parameters (e.g. temperature, pressure, etc.). These nodes are battery-operated and one of the major concerns with these systems is the need for energy consumption minimization for prolonging the operating lifetime of the network. In some cases the nodes have energy harvesting capabilities, enabled by devices such as micro solar panels or piezoelectric mechanisms and the like. Energy harvesting WSN can have an operational life considerably longer than that of battery-operated only systems, but finding the optimal duty cycle that ensures neutrality between consumed and harvested energy constitutes an optimization problem for which many proposals can be found in literature. The need for energyefficient operation pervades the world of WSN in every aspect, from the hardware devices, which must have ultra low-power characteristics at the cost of very resource constrained features, to the tight requirements in software engineering that must tackle both memory and computing constraints, as well as the direct management of the hardware peripherals due to the limited support offered by the tiny embedded operating systems. The network layer, finally, has the highest impact on energy efficiency and the greatest part of the scientific production on wireless sensor networks concentrates on routing protocols as well as on network topology or MAC-level duty cycling. Due to the harsh constraints, working with WSN is a very challenging task for non-specialized programmers and, in many cases, even for those who actively operate in the 978-0-7695-5022-0/13 $26.00 © 2013 IEEE DOI 10.1109/TrustCom.2013.136

II. M OTIVATION In classical approaches to WSN programming the phases concerning data sensing and data processing are strictly mingled in the application layer: programs are, in fact, usually developed as cycling loops in which measurements are performed on the considered physical parameter and, soon after, the retrieved data are processed or sent toward the sink 1123

HPLPowerManagement.Enable() in its Init core and HPLPowerManagement.adjustPower() [13] in the Stop services to assure that processor sleeps whenever certain conditions occur in the radio, processor and task statuses. MantisOS provides functionality to bring peripherals in sleep state, as well as power-aware scheduling, which enables sleeping cycles of the processors when the threads running in the system go in a sleep state, by also dynamically tuning the kernel operation parameters. SenOS has a module called DPM [14], Dynamic Power Management, for managing the sleep-rate cycles of the microcontroller through a state-machine logic. Nano-RK exposes several API for querying and setting the energy status, while event-driven systems such as PEEROS often autooptimize the duty cycle of the system by putting it in idle state till specific events occur. Other systems give visibility on the task or event status queues, allowing the developer to implement a specific logic to optimize the duty cycle of the system at application-level. It should be noted, however, that all the previous approaches represent isolated and applicationspecific functionalities for power management at OS level. A general framework, capable of optimizing energy consumption transparently to multiple end-users, has not been defined yet and most of the effort is demanded to application-level protocols, which strongly vary depending on the scenario. This, moreover, poses serious challenges on the integration between applications deployed by heterogeneous sources. Many duty cycle optimization techniques for power management in WSN have been proposed to date [5]. A foremost distinction of duty cycling techniques can be done among scheduled rendezvous approaches ([12], [11], [10]), asynchronous([8]) and on-demand ([7],[6]) scheduling. These are just few examples, but many other proposals can be found in literature and the research on this field is still producing interesting contributions. Other forms of duty cycling regards optimal MAC-level protocols and topology control, which however fall beyond the scope of this paper. At the best of our knowledge, no specific studies have been carried out on multitasking WSN that require stateful operation in presence of hibernation periods, which entail saving and restoring the memory status of the applications between subsequent active periods. In particular, no rigorous analysis have been yet performed on the energy consumption profile of a system undergoing hibernation. The present work represents an original contribution in this direction, which tags along with the definition of a general power management infrastructure with support for heterogeneous concurrent applications.

via the radio channel. From this parading ensues a general behavior of the network which can be very energy consuming, tough partially mitigated through suitable optimizations of the communication flow as data aggregation [2]. We designed the operation of our framework starting from the consideration that analyzing data on the end device can often help in strongly reducing the energy consumption [3][4] of the network, because of the higher costs associated to data transmission over the radio channel with respect to local processing. From this standpoint, the isolation of the sensing phase from data processing and both from data transmission, introduces an higher level of flexibility in optimizing the three phases separately, each presenting very peculiar characteristics. This allows breaking the bounds between sensing and processing at application level, relieving thus the programmers from managing both this aspects. Furthermore, this becomes even more critical in WSNs where multiple applications concurrently run on the nodes, each performing sensing and processing with different and misaligned periods. In such scenarios, the risk of wasting non-negligible amount of energy to face fragmented duty cycles is more than a mere possibility. By delegating data sensing to a dedicated service of the operating system, in the following referred to as smart drivers, the control flow passes from the applications to a common power management infrastructure, which organizes and merges sensing requests from multiple applications in the most energy efficient way. The abstraction layer introduced through the smart drivers allows a transparent and efficient organization of the sensing phases. We will refer to this approach as smart sensing. According to this model, it is also possible to extend idle periods in which the whole system can be brought to the lowest possible power state, loosing the memory status when the microcontroller is powered-off or put in stand-by. This brings to another problem, mainly concerning the preservation of the status (registers, stack, heap) of the applications between two subsequent active periods. This implies the need for a power-efficient hibernation mechanism. In a future perspective, the possibility to completely divide the management of the network infrastructure from the application layer represents a key success factor for WSNs, especially in a multitasking scenario. Such a paradigm introduces a new stakeholder in the WSN field: the WSN provider. In this context, specialized companies deploy and maintain networks composed by a large number of nodes on area of interests (urban or natural environments, industrial districts and so on) while end-users interested in monitoring certain parameters pay for downloading one or more applications on the network—or on a subset of it—to retrieve specific information. The potential presence of multiple, independent applications over the network pushes even more for a general, efficient and transparent power management layer. III. R ELATED

IV. A PPROACH OVERVIEW This section describes the power management approach at three different levels of abstraction. • Processing Model. The processing model distinguishes the three logic layers presented in Section II, namely Data Processing, Data Sensing and Data Transmission. As said, a first main goal of the power management processing model is to completely decouple each phase from the others, such that the most appropriate duty cycling can be

WORKS

Power management services are offered by various small WSN operating systems: TinyOS provides the functions

1124

Application-specific protocols Processing Data Measure complete

Processing results Timer expired

Set timers Set RTC Management Event RTC / timer expired

Synchronization on global time

Set timers Set RTC





Transmission Data

Optimize events

Management Power

Sensing Data

Fig. 1.

On the contrary, during the processing phases—since it is supposed that the system locally processes and analyzes a bunch of measurements from previous sensing—the system requires full support from the microcontroller, that should thus be operated at its maximum clock frequency. Support from the operating system is needed and the applications in charge of analyzing the measurements should be restored after the hibernation period. The processing phase can be longer by some order of magnitude if compared to simple sensing operations. Results of the data processing can be then stored, aggregated and sent in a subsequent moment, rather than forwarded to the sink if certain trivial conditions occur. In the latter case, a sort of spooler can collect data transmission requests from multiple applications, possibly merge them, and send a single packet (or the lowest possible number of packets) to the destination(s). Alarms and other urgent communications can be immediately forwarded to the destination in any case. By making the data transmission phase independent from the data processing phase it is possible to break the bounds between user-defined applications and the radio policy. In such a way, transmissions can be optimized according to a common energy-efficient routing and MAC-level protocols. The possibility of independently optimizing these layers, in particular, preserves the system from the risks related to the heterogeneity of the programming sources. It is very common, in fact, that different subjects deploy on the same network their own applications disregarding the operation profile of the others. This entails a chaotic fragmentation in the periodicity of transmissions, which results in maintaining the transceiver active for long intervals, rather than always turned-on or, even worse, subject to frequent and energy consuming on/off cycles. To enforce the separation between applications and data transmission, the structure of the radio driver has been optimized such that send and receive operations (requested by the application) make the control flow to pass to a dedicated power-aware service of the operating system that gathers and manages transmission requests from multiple processes. Some remarks are needed in reference to the events management layer, which, as said, is an abstraction necessary to allow the different logic layers interacting among them. Examples of events are the invocation of a system call to read a sensor, the requests for sending or receiving data, rather than the event signaling that all processes are blocked on a system call, such that the system can be hibernated or put in a sleeping state. The event management layer, similarly to all other layers, does not coincide with a particular hardware or software module, but it is rather a sort of middleware space. Multiple devices concur to generate and manage events: RTC, system timers, or a dedicated ASIC possibly interacting with the transceiver and capable of in-circuit time synchronization. Events are generated from the various layers and cause state transitions among them: the power management infrastructure is in charge of intercepting and orchestrating such events to optimize the duty cycle of the whole system. This perspective completely changes the point of view with respect to the classical two-phase approach. By enforcing

Redraw: processing model

chosen for each. To obtain this effect, introducing another abstraction layer is necessary, following referred to as Events Management. This layer interacts with the power management to optimize the events of the system and the related transitions. Operating Model. The operating model, describes the evolution of the system duty-cycle as a consequence of the transitions between the different processing phases. Power Management Model. The power management model details the architecture of hibernation and smart drivers, pointing out the interactions between these modules according to the evolution described by the operating model of the system.

In the following subsections these three level of analysis will be presented in details. A. Processing model The overall structure of the processing model is shown in Figure 1. It should be noted that the three logic layers— data processing, data sensing and data transmission—are considered completely separated and interacting through a common abstract middleware acting as events manager. The power management infrastructure monitors and optimizes the sequence of the events occurring in the system. The three layers represent, indeed, an abstraction: they are not executed by a single software module or hardware device, but can rather involve multiple entities. What this subdivision points out is the common operating profile characterizing each macro-phase. For example, during the data sensing phase, simple operations only are required (read the sensors and store the measurements), such that: • • • •

the microcontroller does not need to be operated at its maximum frequency; support from the operating system is not necessary; the applications should not be restored since the control passed to the smart drivers; the transceiver can be safely switched-off, provided that no synchronization operations and MAC-level active windows occur meanwhile.

1125

Tof f

Ton

tk

1

Fig. 2.

2

Ton

System Hibernated

πss

Tss

3

4

Sleep timeout 5

Nss

tk+1

t

Driver call or sleep

the independence of each phase, the power management infrastructure can leverage an higher degree of flexibility in optimizing the system operation. B. Operating model The main phases characterizing the operating model of the system are smart sensing and full active. Smart sensing just consists of reading a measure from a sensor and pushing it in a queue to be processed later, once the required bunch of measurements have been collected. In this phase there is no need to operate the system in its full active mode (highest microcontroller clock frequency, operating system support, applications status retrieval, and so on). During the full active phase, on the contrary, the system is fully restored and operated at its maximum frequency to perform data processing and data transmission activities. Once a full active period terminates, it is then possible to hibernate the system by bringing it to the lowest possible power state. During the hibernation period, if some smart sensing operations have to be performed, the system can be awakened in a low-power mode, with a lightweight boot (which lasts from less than 100μs to 300–500ms in the worst cases) that just executes the smart driver ISR without loading the entire operating system and the applications. The system can be clocked at a low frequency for the time strictly necessary to read the sensor and store the measure in a queue of the permanent memory. Then it can be turned off again. A system of deferrable timer has been implemented to merge misaligned periods, strongly reducing the number of sleep/wake-up transitions. Such mechanism has the goal of finding a trade-off between energy consumption and quality of service related to the penalty introduced by changing task deadlines. The complete description of this mechanism goes beyond the scope of this paper and has thus been omitted. Figure 2 shows a typical operation trend, where Ton represents a full active period, Tof f the interval during which the system is hibernated and Tss a smart sensing operation. The next section presents the power management infrastructure, with particular detail on the interaction between the smart driver and the hibernation modules, while the key concepts of the hibernation policy are presented in Sections V (see [15] for the full mathematical model).

16MHz light-boot

60MHz boot

Swap out

Redraw: Typical system operation

Event or RTC

Kernel load

Full Active

Queue not full

Queue full

Swap in

Sense

Data Processing

Smart Sensing

Data Transmission

Fig. 3.

Power Management Infrastrcuture

When the system is hibernated, a smart sensing is triggered by an external interrupt (e.g. an RTC), the boot is performed at a low frequency (16MHz), sensing is performed and data is stored in the queue associated to the smart driver. If the queue is filled up to the required bunch of measurements then the smart driver triggers a full boot, the operating system is loaded and the status of the application in charge of processing the specific data is restored. If the queue is not full, then the system is put in stand-by again. If from an hibernation state the system has to be resumed directly in full active, due, for example, to an expired sleep system call in application(s) that must perform processing or transmission at that moment, then the microcontroller is pulled to an higher frequency (60MHz), the kernel is loaded, the application(s) status(es) swapped-in and resumed. The application(s) then processes data and eventually blocks again on a system call. Once all the applications are blocked, the hibernation module determines if it is convenient to hibernate the system or not. In the following the two modules—smart drivers and hibernation— are presented in detail. The smart driver operation is described in Figure 4. As anticipated, the smart driver module consists of two branches, Pre-boot ISR

OS daemon

System Hibernated

System Full Active

Hibernation Manager

Timer

RTC Read sample Push in queue

Queue full?

Y

Boot

N

C. Power Management Model The power management support to the optimal duty cycling of the system is modeled by the state machine in Figure 3. The specific microcontroller used in our prototype [1] is the STM32F2, but similar operation can be obtained with almost every mid/high range microcontroller on the market.

Y

Queue full? N

Event Manager

Set next RTC Shut-down

Fig. 4.

1126

Read sample Push in queue

Power Manager

Smart Drivers

Set Timer to next event

main() { int results;

t7

hibernate

t3

// Initialize the data queue of 15 integers queue_t q = queue( 15, sizeof(int) );

t9

// Opens the sensor (temperature) device int fd = open( "/dev/temp", O_RDONLY ); start

R(Q)

t4

RB(Q)

Hibernation State Diagram

TABLE I H IBERNATION S TATES

} } Example of a Smart Driver call

State

Meaning

R(Q) RB(Q) B(Q) sleep hibernate (re)boot

All processes Q are running or ready Some processes are running/ready and some blocked All processes are blocked All processes blocked; low-power with memory retention System is hibernated (power-off or stand-by) First boot or system reboot after hibernation TABLE II T RANSITIONS TERMS

the pre-boot ISR routine and the run-time daemon running in the operating system. The operations are the same described so far and just consist of performing measurement and populating the queue. What is interesting to point out here is how a smart driver is called, how it determines the type of boot (light boot vs. full active) and, finally, how it triggers the transition to the full active processing phase. A call to a smart driver is shown in Figure 5, as part of a typical application performing the following sequence of operations.



t2

Fig. 6.

// Eventually sends the result send( p );



sleep

t2 t1

(re)boot

// On completion, process data in the queue result = process_data( q );



t6

t5

while( 1 ) { // Reads a bunch of 15 measurements (blocking) read( fd );



t8

t1

t1

// Configures the smart driver for periodic // operation (12s) with maximum slack of 2s ioctl( fd, SD_CONFING_PERIODIC, q, 12, 2 );

Fig. 5.

B(Q)

t4

Instantiates a queue of N elements, where measurements will be stored. The system call queue() allocates the queue in a permanent section of the memory, always retained (e.g. the backup RAM, the main Flash or an external memory). Opens the sensor device that will be sampled through a standard open() call. Sets the parameters of the smart driver, i.e. the type (periodic or threshold-based), the period or the threshold value (depending on the type) and possibly a non-zero slack for the deferrable timers. This is done by the ioctl() call. Invokes the smart driver through a call to read().

Term

Meaning

R B |R | |B | qr qb

List of running processes List of blocked processes Cardinality of the running processes list Cardinality of the blocked processes list The process q becomes ready or running (R++, B--) The process q becomes blocked (R--, B++)

hibernation module that the queue for that application is ready, such that the related process can be restored for processing. In the pre-boot phase events are scheduled by programming the external RTC, while, when the system in full active, they are scheduled by programming an internal timer. The second core module of the power management infrastructure is responsible of managing the hibernation mechanism. The operation of the hibernation module is modeled by the FSM in Figure 6, and the meaning of the states is reported in Table I. The behavior of the hibernation mechanism is fully described by the following transitions, whose terms are explained in Table II: t1 t2 t3 t4 t5

From this moment on, control passes from the application to the smart driver that will perform the required measurements either until the queue is full or the threshold is reached, depending on the type of the smart driver. Then, once the queue is ready to be processed, if the system was hibernated the ISR branch of the smart driver triggers the full active processing by calling the OS Kernel boot, after which the hibernation module will restores the status of the application that was suspended on the smart driver. If the system was already in full active, the smart driver daemon signals to the

: qr ∧ (|B| = 1) t6 : qb ∧ (|R| > 1) : qr ∧ (|B| > 1) t7 : P olicy → Hibernate : qr t8 : P olicy → Sleep : qb ∧ (|R| = 1) t9 : RT C → W akeup : (qb ∧ (|R| > 1)) ∨ (qr ∧ (|B| > 1))

Hibernation is managed through the Hibernation and the Resume daemons, running in the operating system. • The Hibernation daemon monitors the running processes: when all are blocked, it determines whether to hibernate

1127

or not according to the policy described in Section V, saving their status on a non-volatile memory. • The Resume daemon restores the status of the applications that must perform data processing or transmission. The described mechanism has been implemented on the architecture presented in [1]. Its formulation, however, is general enough to be potentially ported on a broader range of embedded scenarios with periodic operation profile. Section VI provides an explanatory example clarifying the role of the power management infrastructure in a typical WSN use case.

Hibernation unused

q4

t!

Sk = [sk,1 sk,1 . . . sk,p ]

(t0 , S0 ), (t1 , S1 ), . . . , (tk , Sk ), . . .

An example of state transition is shown in Figures 7, where the evolution between the two states can be expressed as: (tk , [01011]), (tk+1 , [11001])

(3)

If state Sk+1 and the subsequent state Sk+2 are close enough in time, hibernation may not be convenient and the system, as

q3

swap-out / swap-in

q1

q2 q1

swap-in tk+1

tk

Memory status in two subsequent processing phases: Hibernation TABLE III T ERMS OF THE ENERGY BALANCE EQUATIONS

Term

Meaning

W Ei Eo EOS Pss PS ||Sk ||

Sizes of the processes memory statuses Energy to read a byte from the non-volatile memory Energy to write a byte into the non-volatile memory Energy consumed to shut-down and to reboot the OS Average power to perform smart sensing operation over a period Power consumption of the system in memory-retention sleep Total memory occupied in a state (||Sk || = Sk · W )

said, is put in a sleep state with memory-retention. In such a case, the state at tk+2 will have in main memory both the status of the processes of Sk+1 and those of Sk+2 : remembering the boolean formulation of the state vector, we will express this condition as Sk+1 ∨ Sk+2 . Extending this rule to the next n (n) states, we can define Sk+1 as: (n)

Sk+1

(1)

(2)

q4

swap-out

q3

q2

Fig. 7.

where Sk is a boolean vector whose element sk,j is equal to 0 if process qj is currently swapped-out onto the non-volatile memory, while equals 1 if the process status is currently in RAM. The evolution of the system over subsequent time instants ti can thus be modeled as a sequence of pairs

q5

unused

V. H IBERNATION POLICY This section shortly describes the mathematical model used as hibernation policy, to determine the optimal decision between hibernation and sleep after active periods (see [15] for full details). Since we are targeting a multitasking WSN, in which a non negligible number of heterogeneous applications are deployed, the decision depends on the number and the characteristics of the processes at the end of the current active period tk , as well as on those that will be run in the next active period tk+1 . We consider processes that are periodic or aperiodic with deterministic next-resume time 1 , recalling that the behavior of a periodic process is known for the entire future, while for an aperiodic deterministic application the future is known only for the available prediction window. We denote with Q = [q1 q2 . . . qp ] the ordered set of processes deployed on a node. The size (byte) of the memory statuses—registers, data, stack, heap—of these processes is represented by the vector W = [w1 w2 . . . wp ] . We can then define the state Sk of the system at time tk as:

swap-out / swap-in

q5

=

Sk+1 ∨ Sk+2 ∨ . . . ∨ Sk+n (1)

(4) (n)

where, for n = 1, we have Sk+1 = Sk+1 . We refer to Sk+1 as the transitive closure of the system states over the next n active (n) periods. The transitive closure Sk+1 accounts for the worstcase condition in which, from the next active period to the nth active period in the future, the system cannot be hibernated. This means that between two subsequent active periods, of the n considered, the system will sleep with memory retention. From this follows that restoring at the next state Sk+1 the status of all the processes that will run in the next n states, is equivalent to restoring these statuses as they arrive in time. In the light of this consideration, we can state the equations of the energy consumed to hibernate EH and the energy consumed for the memory-retention sleep ES as: (n)

EH = ||Sk ||Eo + ||Sk+1 ||Ei + (tk+n − tk+1 )PS + EOS (5)

1 We

only consider periodic and aperiodic deterministic processes since our analysis on stochastic or indeterministic processes led to a solution whose computational burden is unacceptable for a run-time approach. We will consider stochastic process as unpredictable events, the arrival of which has limited and sporadic impact on the energy efficiency of the node. This is coherent with most real applications, mainly structured with periodic or eventbased processes, the latter generally having very long interleaving periods. For rare cases of stochastic events with high frequency of arrival, it is always possible to encompass their impact on the energy balance by considering the expected value of the Poisson distribution—or other stochastic variables— describing their occurrences.

(n)

(n)

ES = ( ||Sk+1 || − ||Sk ∧ Sk+1 || )Ei + (tk+n − tk )PS

(6)

where the terms in the equations are described in Table III, while the two equations are clarified in the following. Equation (5) represents the energy consumed for hibernating the system between the current state Sk and the next state Sk+1 , under the hypothesis that no hibernation will be possible between Sk+1 and Sk+n . The equation considers the energy

1128

(n)

spent to save the current state on the non-volatile memory and the energy to restore the memory for the next n states, as well as an upper-bound approximation of the energy consumed for maintaining the system in sleep (with memory retention) between the active periods occurring in (tk+1 , tk+n ). Moreover, also the energy consumed for the shutdown and the reboot of the operating system is included. Equation (6) represents the case in which the system is brought to sleep (with memory retention) between Sk and Sk+1 . In this case there is no contribution to swap-out the memory state on the non-volatile memory. The energy contribution to restore the status of the applications is limited to those that are not already present in memory at Sk . Also here, the term (tk+n − tk )PS is an upper-bound approximation for the energy spent to maintain the system in sleep between the active periods occurring in the prospection window(tk ,tk+n ). It should be noted that the energy (tk+1 − tk )Pss spent for smart sensing has not been considered in the equations because the difference between the two cases (hibernation and not hibernation) is negligible, thanks to the ultra-low energy consumed for a light-boot of the smart-driver ISR branch. By considering a prospection of n states, the decision regarding hibernation between the current state Sk and the next state Sk+1 is not simply local but is taken by explicitly considering all the applications that would eventually need to be restored for the whole prospection period (tk+1 , tk+n ), for which, in the worst case, the system would never be hibernated. Given the previous equations, hibernation is convenient when EH < ES , that is when ΔE = EH − ES < 0. Since (tk+n − tk ) = (tk+n − tk+1 ) + (tk+1 − tk ) this last condition can be written as:

closure Sk+1 and is verified2 when the maximum of Cn is (n) reached, i.e. when maxn ||Sk ∧ Sk+1 || = ||Sk ||. We denote with f (nM ) = fM the condition in which f (n) tops its maximum at time tk+nM . When τk > fM , hibernation is guaranteed to be optimal. The global minimum condition CL applies when the function f (n) reaches its lower bound fL , (n) that is when Sk ∧ Sk+1 = ∅. If CL is satisfied, hibernation is guaranteed not to be convenient. Both the conditions CM and CL are sufficient but not necessary. This implies that the optimal choice can be taken only by solving Equation 8 after having determined the optimal prospection n, which has been shown to be a combinatorial problem. To overcame this issue, a new heuristic condition: Cα :

fα = fL + α(fM − fL )

VI. E XAMPLANOTRY EXAMPLE Figure 8 shows an example of evolution of the system according to the proposed model in presence of two simple concurrent applications running on a node and referred to as process P1 and process P2 in the figure. Process P1 performs sensing on a given device every 1 unittime, while it processes data when a queue of 7 measurements has been collected. Process P2 performs sensing every 2.5 unit times and processes data on a queue of 2 measurements. Smart sensing operations are represented in figure as small, dark-gray ticks, while full active processing period are the bigger lightgray boxes. Note that the smart sensing activity must continue with its periodicity also during full active periods: in this case, smart sensing is performed by the operating system daemon branch of the smart driver. During hibernation periods, on the other hand, smart sensing lightweight boots are performed by the ISR branch of the smart driver. The bar below the time axis indicates the state of the system, which can be: • A – Full Active. System performing data processing. • H – Hibernated. System powered-off, only RTC on. • S – Sleeping. System not hibernated, i.e. not powered-off, with memory retention. The deferrable timer effects can be seen at times 3, 8, 13, 18, where the sensing activity of the process P2, supposed to have lower priority than process P1, are deferred such that they coincide with the smart sensing of process P1, reducing the number of times that the system must be awaken. After each full active period, the hibernation daemon decides whether to hibernate or not according to the policy described in Section V. Note that this decision depends on the

where τk = (tk+1 − tk ). Solving for the interval τk leads to: (n)

||Sk ||Eo + ||Sk ∧ Sk+1 ||Ei + EOS (8) PS

which states the condition for which hibernation is convenient between tk and tk+1 . This condition, as said, requires considering the next n states, but how to determine the optimal length n of the prospection constitutes a problem of combinatorial complexity. To avoid incurring in this issue (which depends on the number and types of the applications) and to preserve the generality of the model, we study the properties of the condition Cn . The discussion in [15] shows that Cn has a global maximum and a global minimum, leading to the following two limiting conditions: CM : CL :

||Sk ||(Eo + Ei ) + EOS PS ||Sk ||Eo + EOS τk < PS τk >

(12)

and 0 ≤ α ≤ 1. The optimal value of α can be determined experimentally for broad classes of application scenarios, as shown in Section VII.

(n)

τk > f (n) =

(11)

is defined, where:

ΔE = ||Sk ||Eo + ||Sk ∧ Sk+1 ||Ei + EOS − τk PS < 0 (7)

Cn :

τk > fα

(9) (10)

Condition CM comes from the monotonicity of the transitive

2 Always

1129

true for periodic processes, an upper bound for aperiodic ones.

P2 P1 A

H

0

3

A 5

H

A 7

H 8

A

Fig. 8.

13

Running at 60MHz Sleeping at 60MHz Running at 16MHz Sleeping at 16MHz Stand-by, unclocked

18

20

t

21

Period

Current drawn

Current drawn

System

0.1s

1s

10s

100s

System S1 System S2 System S3

87 368 18

843 381 30

8,403 502 151

84,003 1,711 1,360

proposed policy. The entire flow, after an initial phase of Matlab prototyping, has been implemented in C++ to face the computational burden entailed by the model complexity. We first explored the energy gain by comparing the three following systems: • S1 – A system that leverages duty cycle by putting the system in a sleeping state with memory retention. • S2 – A system that leverages duty cycle by putting the system in hibernation, without smart drivers. • S3 – A system based on the proposed framework and integrating both hibernation and smart drivers. For each system we have estimated the energy consumption of a simple sensing application, whose period has been set to 0.1, 1, 10 and 100 seconds. The processing period coincides here with the sensing period. The results obtained are reported in Table V. We focused on the energy consumed by the system, without considering the contribution for reading the sensor since it is equal for the three cases and does not represent a differential contribution. It can be noted how our approach (system S3) always outperforms the two others. Specifically referring to system S2, the improvement is achieved since hibernation, on one hand, permits switching the system off, but, on the other, entails writing and reading the external non-volatile memory: this trade-off is not convenient for very short sensing periods, since the cost to operate on the MRAM cannot be compensated by a sufficiently long idle time. In Section V we defined the policy Cα for the optimal choice between hibernation and sleep with memory retention. An appreciable trend for the α parameter would be a stability on the limiting values 0 and 1, indicating that one of the two general conditions CL or CM apply, which are not depended on the prospection window n. We simulated more than one million application test cases, varying the ratio Eactive /Psleep of a factor 2, 4, 8, 12, 16 and 20 to observe the stability and robustness of the policy as a function of the best α value. The simulations targeted a set of 10 concurrent applications, with

7 μA 3.75 mA 13.4 mA

Quiescent Reading at 15MHz Writing at 15MHz

A S A

H 15

TABLE V C OMPARISON WITH STANDARD APPROACHES (E NERGY IN nJ)

12 mA 5 mA 4 mA 2.1 mA 300 μA

Magneto-resistive memory operating state

14

Hibernation - Explanatory Example

TABLE IV P OWER CONSUMPTION SUMMARY Microcontroller operating state

A S

H

10

trade-off between hibernation and not hibernation (i.e. sleeping with memory retention). In the considered example the decision to hibernate has been taken after the full active periods starting at 0, 5, 7, 10, 15 and 21. Between these active periods and the following, in fact, there is enough time to make more convenient swapping-out the status of the running process, shutting-down the system and restoring the status of the following process, but maintaining the system powered-off in the meanwhile, rather than bringing the system in a more energy-consuming sleeping state with memory retention. A different decision, that is to put the system in sleep with memory retention, has been taken after the active periods at times 14 and 20, since the time between these active periods and the following is not enough for hibernation to be convenient. VII. R ESULTS We implemented the power management infrastructure on a prototype version of the PoliNode platform and Miosix operating system, described in [1]. This implementation allowed evaluation of the proposed framework. As non-volatile memory we used an external magneto-resistive RAM (MRAM), that allows unlimited number of writing cycles. A summary of the electrical characteristics of the platform are reported in Table IV. The operating system has a boot time of 450 μs. We also defined a simulation flow for assessing the mathematical model in perspective scenarios with many concurrent applications with misaligned periods and different sizes of the memory images. Through this flow it has also been possible to perform a sensitivity analysis on the operating parameters to assess the properties of robustness and stability of the

1130

Fig. 10.

Fig. 9.

Energy gain w.r.t. classical operation

approach steadily overcomes the classical duty cycling thanks to its adaptive behavior, to the ultra-low power profile of the smart drivers in performing measurements and, as the average period grows, to the negligible energy consumption of bringing the system in deep stand-by. The energy gain reaches 98% for an average sensing period of 250s,

Policy stability and robustness

varying average sensing period (from 5s to 200s). Results are shown in Figure 9. It can be noted how the best value of α is equal to 0 before a certain minimum average period pmin and stable on the value 1 after the average period pmax . This means that before a certain minimum average period pmin , the CL condition always apply and the policy will decide to sleep in memoryretention mode, since there is not enough idle time to amortize the costs of an hibernation for operating on the non-volatile memory. For periods longer than pmax , on the contrary, the system always undergoes hibernation, since the costs of operating on the MRAM are largely counterbalanced by the possibility to power-off the system for longer idle intervals. The spread between pmin and pmax grows as the perturbation Eactive /Psleep increases. Between pmin and pmax the system is in an uncertainty zone, for which the best value of α must be experimentally determined. Since the ratio Eactive /Psleep can be determined for each target microcontroller, the experimental calibration of α can easily be done once and for all at compile time. This will result in a small lookup table to be provided to the hibernation module of the node. When the system realizes that the average period of the applications running on it falls in the uncertainty zone, it choses from the lookup table the best value of α for the current conditions. Aside from this very thin margin of uncertainty, easily mitigated, the policy shows a very high degree of stability and robustness. We finally compared the energy saving obtained by our approach with respect to a classical duty cycling approach that switches between active and sleeping mode (without hibernation and smart driver). The test concerned a pool of ten concurrent applications, whose average sensing period have been varied from 0.1 to 250 seconds. Data processing is triggered when the queue of measurements reaches ten units and lasts for 10 ms. The relative energy gain of using our approach with respect to the classical duty cycling model is reported in Figure 10. It should be noted that for very short sensing periods (0.1s) the gain is very close to zero, since the two approaches are equivalent—being the CL condition always verified—and our model will never choose hibernation. Our

VIII. C ONCLUSIONS This paper presented a power management infrastructure and a model for optimizing the duty cycle in multitasking wireless sensor networks that require memory preservation during idle periods. The whole architecture is conceived to support multiple concurrent applications from heterogeneous sources, with different periods an image sizes. The proposed approach enables ultra-low power operation in microcontrollers in the mid/high range of the market, characterized by non-negligible energy consumption in memory retention sleep states, mainly because of the static leakage currents affecting these devices as the nanometer scale steps down. By reducing the energy consumption in more powerful microcontrollers, it is possible to make their adoption more attractive by providing more flexibility and a more usable environment to the end programmer. Results showed excellent performance of the proposed approach in reducing energy consumption and also a very good degree of stability and robustness of the hibernation model. Future work will be focused on the integration of this framework in presence of autonomous code mobility, to adaptively balance the computational burden among the various nodes of the network. R EFERENCES [1] Brandolese,C., Fornaciari,W. Rucco,L. and Terraneo, F. Enabling ultralow power operation in high-end wireless sensor networks nodes. In Proc. of CODES+ISSS ’12. ACM, New York, NY, USA, 433-442.2012. [2] Rajagopalan, R.; Varshney, P.K.; , Data-aggregation techniques in sensor networks: a survey, Communications Surveys and Tutorials, IEEE , vol.8, no.4, pp.48-63, Fourth Quarter 2006 [3] Estrin, D. and Girod, L. and Pottie, G. and Srivastava, M., Instrumenting the world with wireless sensor networks, In Proc. of ICASSP ’01, pp. 2033–2036 vol.4, 2001. [4] Estrin, D., Tutorial on Wireless Sensor Networks, In MobiCom’02, Atlanta, Georgia, USA, 2002. [5] Anastasi,G., Conti,M., Di Francesco,M. and Passarella,A. Energy conservation in wireless sensor networks: A survey. Ad Hoc Netw. 7, 3 (May 2009), 537-568. 2009. [6] Schurgers,C., Tsiatsis,V., Srivastava,M. B. STEM: Topology Management for Energy Efficient Sensor Networks. In IEEE Aerospace Conference ’02, Big Sky, MT, March 10-15, 2002.

1131

[7] Schurgers,C., Tsiatsis,V. , Ganeriwal,S., Srivastava, M. B. Optimizing Sensor Networks in the Energy-Latency-Density Design Space. IEEE Trans. on Mobile Computing, Vol.1, No.1, pp. 70-80. 2002. [8] Tseng,Y., Hsu,C. , Hsieh,T. Power Saving Protocols for IEEE 802.11 Ad Hoc Networks. In Proc. Infocom’02, New York (USA).2002. [9] Rmer, K., Blum, P. and Meier, L. Time Synchronization and Calibration in Wireless Sensor Networks. Handbook of Sensor Networks: Algorithms and Architectures (ed I. Stojmenovic), John Wiley & Sons, Inc., Hoboken, NJ, USA. 2005. [10] Keshavarzian, A., Lee, H., Venkatraman,L. Wakeup Scheduling in Wireless Sensor Networks, In Proc. of MobiHoc’ 06. pp. 322-333, Florence, Italy.2006. [11] Hohlt, B., Doherty, L., Brewer, E. Flexible Power Scheduling for Sensor Networks. In Proc. of ISPN’04, Berkeley (USA). 2004. [12] Lu, G., Sadagopan, N., Krishnamachari, B., Goel, A. Delay Efficient Sleep Scheduling in Wireless Sensor Networks. In Proc. of Infocom’05. Miami, Florida, USA. 2005. [13] P. Levis, S. Madden, D. Gay, J. Polastre, R. Szewczyk, A. Woo, E. Brewer, and D. Culler, The emergence of networking abstractions and techniques in TinyOS. In Proc. of the 1st conference on Symposium on Networked Systems Design and Implementation Volume 1 (NSDI’04), Vol. 1. USENIX Association, Berkeley, CA, USA, 1-1. [14] A.Sinha, A.Chandrakasan, Dynamic power management in wireless sensor networks Design & Test of Computers, IEEE , vol.18, no.2, pp.62-74, Mar/Apr 2001 [15] Brandolese,C., Fornaciari,W. Rucco,L., Hibernation Model for Energy Optimization of Multi-Tasking Wireless Sensor Networks, Tech. Rep. n. 2103.4 Politecnico di Milano - DEIB, Italy.

1132