Get documents about "Energy Management for Wireless Sensor Networks
Document Sample
Energy Management for Wireless Sensor Networks
- CS270 Project Report, Spring 2007 -
Xiaofan Jiang and Jay Taneja
Dept. of Computer Science, University of California, Berkeley
Berkeley, California 94720
{fxjiang,taneja}@cs.berkeley.edu
1 Motivation and Background • Binary predicates: each statement in the specification
consists of three elements: transaction name of a named
Frequently, the chief concern in designing wireless sen-
account, a binary operator, and a real number or a pre-
sor networks (hereafter, sensornets) is energy, usually sup-
defined symbol. For example, in
plied by battery or solar harvesting and often severely con-
strained. Minimizing operational use of this shared resource Account.Xact > 5
is often a primary guideline in the design of protocols and Account is the name of the account that represents a
applications in this space. Despite the importance of energy logical energy consuming activity. Xact is the name
as a determining design factor, it has received little architec- of a transaction that belongs to the named account.
tural consideration. Our recent work [?] classifies energy as a The binary operator can be from the set {<, >, =, ≤, ≥
first-class operating system resource, allowing it to be intelli- }. The last element can be any real number or from
gently arbitrated by the underlying system. This architecture the set {MIN, MAX, NULL, INF}: MIN:=minimize,
enables prioritization of user requirements on the system, MAX:=maximize, NULL:=deny all, INF:=allow all.
enabling predictable failure, graceful degradation, and fair • Logical combination: statements can be logically com-
accounting in the face of scarce resource availability. Ad- bined (only AND and OR are allowed) to form com-
ditionally, use of admission control and other enforcement pound statements. ANDed statements have no order but
practices by the energy management facilities allows a user ORed statements are prioritized and is implicitly XOR.
to dictate desired network lifetime, a capability previously For example, in the statement:
unachievable yet fundamental for observing certain phenom-
Light.sense > 5 AND
ena.
Light.send = INF OR
Our intent of this course project is twofold: (1) to cleanly Light.store = INF
specify the language for the user to express a prioritized list
of sensornet requirements and (2) to design and implement The system should first try to sample light sensor and
an enforcement algorithm for realizing these requirements. send the reading through radio; if there is not enough
It is necessary for our user-level specification to be signifi- energy, the system should sample light sensor and store
cantly expressive and flexible, yet remain intuitive and high- into stable storage; last, if there is not enough energy,
level, as we expect our user population will be unfamiliar the system should do neither.
with detailed network operation. Additionally, the question • Strict prioritization: statements are composed together
of enforcement presents many interesting challenges, includ- in strict priority to form the specification. For example,
ing accounting considerations and failure conditions. 1. Light.sense >= 5
2. Temp.sense = MAX
2 Design Points the system should first enforce statement 1, and, if there
In this section, we formulate the primary design points is sufficient available energy, then statement 2. Strict
in this project. We also propose our initial plan for attacking prioritization reduces the complexity of the run-time en-
the following problems, which provides the starting point for gine significantly.
this project. One realistic example for using sensornets for Arctic ob-
servations, where motes are required to operate for a pro-
2.1 User Policy Specification Syntax longed period of time (e.g. 1 year) without maintenance.
The formulation and expressiveness of the specification With a minimum lifetime encoded as the first requirement,
language for the user policy is directly related to the com- reporting and sampling rates can be modulated in order to
plexity of the run-time engine. The specification language is achieve the foremost requirement of lifetime, as shown be-
also intimately related to the API for the application code. low:
One important aspect of this project is to define a set of
possible primitives and grammar rules, in order to be expres- 1. Node.life >= 1
sive and powerful, yet computationally tractable. 2. Humidity.sense >= 10 AND Temperature.sense = MAX AND
(Humidity.send = INF AND Temperature.send = INF) OR
We propose to use the following grammar and syntax: (Humidity.store = INF AND Temperature.store = INF)
The account Node is special and transactions under it rep- an online algorithm that will efficiently determine whether
resents system properties (e.g. life). This user policy reads the syscall can be performed, depending on the current en-
as follows: first make sure the node survives for a year; then ergy states and the user policy.
sample humidity and temperature sensors and first attempt to
Our online algorithm essentially marches through the pri-
send the readings to the basestation. If there is not enough
oritized specification statements at some frequency and dy-
energy to send (since radio usually consumes a lot of en-
namically determines if a set of pending commands can be
ergy), try to store the readings to local storage.
granted. From the API perspective, the statements between
2.2 API transactions are all requests pending approval of the EM, via
For accounts and transactions to make any sense, the ap- a shim layer. The EM looks up the remaining energy of the
plication code running on the motes needs to be correlated, system, estimates the average power of the current statement
via some sort of API to the energy management (EM) en- (via a weighted moving average of the past history of the
gine. In some sense, the end user of the sensornet and the current account.Xact), and grants or denies the related pend-
application programmer need to agree on the set of accounts ing requests depending on the whether the remaining energy
and transactions and their meanings. It may prove useful for is sufficient. The EM adds the average power of the current
the application programmer to provide the users with a short stated account.Xact to a sum of all power consumptions of
description of what each transaction does via some standard account.xacts from statements that have been looked, then
way of documentation, similar to javadoc for the java library. moves down to next statement, repeating.
In terms of the API between application code and the en- For example, we wrote a very simple proof-of-concept
ergy management engine, the API needs to inform the EM algorithm that performs uniformly-weighted average and
when energy should be accounted and under which account. strictly prioritized admission control.
There also should be some way for the program to query
the EM for energy-related information, in order to make rea- event result_t Timer.fired() {
sonable requests. Additionally, there must be some way of uint8_t i,j;
enforcing user policies. We propose the API to be of the power = 0;
if (t < 20)
form: t++;
... // runTime is in increaments of Res!
EM.beginXact("Account", "Xact"); runTime++;
... // Energy injection
EM.endXact("Account", "Xact"); if (E < 0)
... call Leds.redOff();
else {
beginXact and endXact indicate to the run-time engine the for (i=0; i<numAcc; i++) {
account and transaction under which the sandwiched code power += accounts[i].power;
should be debited. For example, typical code using the EM if ((accounts[i].req != 0) &&
(E > power*(float)(Life - (float)runTime/20.0))) {
API would look similar to: accounts[i].grant = TRUE;
// Indicate the beginning of light sensing if ((float)(accounts[i].req) == 0.0)
EM.beginXact("Light", "sense") call Leds.redToggle();
// Checks how much energy is left in "Light" account E -= (float)(accounts[i].req * accounts[i].cost);
EM.queryBalance("Light") accounts[i].history[accounts[i].ptr] = accounts[i].req;
... accounts[i].req = 0;
// CHECK energy costs of actions I want to perform }
// by querying the database else {
... accounts[i].history[accounts[i].ptr] = 0;
// PERFORM the actions by invoking calls to commands }
// commands are intercepted by the EM shim layer accounts[i].ptr = (accounts[i].ptr+1) % Window;
// and admission control is performed accounts[i].power = 0;
// If not enough energy, fail it for (j=0; j<Window; j++)
... accounts[i].power += accounts[i].history[j];
// Indicates the end of light sensing accounts[i].power = accounts[i].power*accounts[i].cost/
EM.endXact("Light", "sense") ((float)t/20.0)/4.0;
... }
... for (i=0; i<numAcc; i++) {
// Begin another transaction if (accounts[i].grant) {
EM.beginXact("Temp", "sense") accounts[i].grant = FALSE;
... signal EM_oneshot.granted[i]();
}
}
We also propose to allow the application to place periodic }
triggers into the EM, suitable for periodic actions. The EM return SUCCESS;
}
automatically triggers an event when energy becomes avail-
able.
2.3 Enforcement Algorithm This only represents our initial brainstorming. We foresee
To enforce the user specification during run-time of the the final algorithm to be very different from the proposed as
system, our EM engine inserts a shim layer, at the OS level, we try to implement and evaluate computationally efficient
under high level syscall (command) invocations. We propose enforcement engine.
3 Evaluation
We will evaluate the correctness of our system by com-
paring systems coded using conventional TinyOS and using
EM. We will also evaluate the performance of our system by
analyzing the energy efficiency when compared to applica-
tion without using EM. Finally we will evaluate the compu-
tational efficiency of our online enforcement algorithm.
4 References
[1] X. Jiang, J. Taneja, J. Ortiz, A. Tavakoli, P. Dutta,
J. Jeong, D. Culler, P. Levis, and S. Shenker. An Ar-
chitecture for Energy Management in Wireless Sensor
Networks. ACM IPSN-SPOT, appearing, 2007.
Related docs
