Energy Management for Wireless Sensor Networks - CiteSeerX

0 downloads 0 Views 251KB Size Report
Given the motivation for energy management in sensor- nets, we .... other system components, their identity should be a priori information for both ... easy cognizance for the user. ... algorithm to conveniently access and understand the priority.
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

System Architecture

Given the motivation for energy management in sensornets, we propose an architecture consisting of three basic components, reminiscent of classic OS resource management architectures: a specification component, an energy monitor, and an energy manager, as seen in Figure 1. The

Energy Monitor Energy States

Application

Enforcement Mechanisms

API

Translation

EMI

Energy Manager Specification

The advent of the field of wireless sensor networks (hereafter, sensornets) encourages application of Moore’s Law in the opposite direction - instead of more transistors in the same space, sensornets seek to shrink the real estate necessary to maintain the number of transistors needed for computation. As the nascent field matures and market forces drive sensornet nodes to be as cheap as possible and operate for longer while maintaining the same processing power, this reversal of a principle prevalent in microprocessor design for the last four decades indicates that energy efficiency will remain the chief concern as nodes seek to remain within ever-tightening power constraints. Currently, most sensornet protocols, platforms, and applications are designed for low-power operation. However, this term is often loosely applied; systems are designed with limited knowledge of actual energy consumption. In order to remedy this shortcoming, we propose an architecture that places energy as the foremost design consideration, classifying energy as a first-class operating system resource [1]. This distinction enables the underlying system to intelligently arbitrate usage of this scarce shared resource, allowing fair accounting of energy usage as well as graceful degradation of service and predictable failure despite a fluctuating and often inhospitable environment. Visibility and control over allocation of energy also enables the user to dictate networkwide quality-of-service, including desired lifetime and sensing rates, despite dynamic conditions. We begin by introducing our Energy Management Architecture in Section 2, outlining the components and their basic functions. Next, we delve into the design and rationale for the focus of this work, namely the high-level language used to describe user policy, the low-level programming interface, and the algorithm for enforcing the aforementioned user policy. We evaluate the feasibility of this language and our design by performing experiments using an implementation in Section 4. Next, we examine related work in Section 5 and conclude in Section 6.

2

EMA

Introduction

User Policy

1

Component E. Usages

Hardware Energy Monitor

Figure 1. Energy Management Architecture specification component provides a set of interfaces to the programming paradigm and communicates the energy policy to the monitor and the manager. The monitoring component observes granular component energy usages via a set of interfaces to the application. It also monitors overall system energy such as remaining battery energy and incoming harvested energy. The management component uses energy information from the monitoring component to enforce user policies conveyed by the specification component and performs admission control on activities via interfaces to the application similar to the interfaces used by the monitoring component. While some of these ideas have been well-studied in other areas of computer science, they have not been applied to sensornets effectively due to the unique resource challenges of the paradigm. This work focuses on three components of the architecture: (1) the User Policy Specification, (2) the API, and (3) the Enforcement Algorithm within the Energy Management (EM) component.

3

Design

After identifying the key components necessary to realize the energy management architecture described thus far, it was necessary to identify the key requirements for each component. In this section, we examine these design directives and introduce our solutions.

3.1

User Policy Specification

The question of how users interact with a sensornet remains open and is under constant debate. Though some pre-

vious approaches will be examined in Section 5, here we aim to characterize what goals an appropriate language will meet. First and foremost, the projected users for sensornets are employing the network to monitor and/or control a system. These users often have extensive prior experience with both the sensor equipment as well as the system under observation, but may be limited in programming and device networking knowledge. Thus, the language should emphasize the sensing capabilities of the underlying sensornet while abstracting away the complexity of network interaction. However, masking the intricacies of a system hinders the capability of its user to fully take advantage of the capabilities of the system. In light of this concern, the second goal we identify deals with making the language sufficiently expressive for the user to direct the system as desired while maintaining the ease-of-use necessary for the inexperienced programmers we target. Another important consideration is the complexity of the algorithms needed to support this language versus the execution speed in response to dynamics of the environment. Since sensornets are often embedded in an environment and subjected to volatile ambient conditions, the system must quickly adapt. Coupled with the memory, processing, and energy constraints of sensornet nodes, the appropriate language should command computationally tractable algorithms that can adjust either in real time or quick enough to respond to environmental fluctuations. For addressing these chief needs, we have developed a specification language that incorporates a prioritized list of user requirements, enabling expression of a simple enforcement policy that can be carried out by the energy management system with relatively low complexity on a running basis. An example of a complete user policy specification is below: Light.sense > 10 AND Light.send = 0.5 Humidity.sense = MAX The user specification consists of a series of rules, with each rule composed of one or more terms joined by logical operators (e.g. AND, OR). Terms allow the user to describe policies for logical groupings of operations, identified by a two-item pair of accounts and transactions, within the system. Accounts are intended to be representative of energy consumers (e.g. Light or Humidity sensors) within the system while, on the other hand, transactions represent energyconsuming operations (e.g. sensing or sending directives). To more closely examine what constitutes a term, consider the first term in the first rule in the above user policy specification. A term should be composed of one account (Light), one transaction (sense), a binary operator (> above, but must come from the set {}), and a desired frequency, which must be a real number or from a list of predefined constants (INF for infinity, MIN for minimize, and MAX for maximize). INF indicates to the energy management algorithm that all requests for this account.transaction pair should be granted, given rules with higher priority is met. MIN and MAX provide an optimization clause, where the system attempts to perform the indicated action as much or as little as possible based on the directive; since it is unclear how priority would apply to multiple optimization

clauses, we currently limit each set of rules to one optimization clause. For these logical groupings to be relevant in other system components, their identity should be a priori information for both the user and application programmer. An important clarification for this language is the behavior of AND and OR, the only two possible logical operators. AND dictates that the terms it adjoins must both be satisfied for the rule (or part thereof) to be satisfied, consistent with what AND means in other contexts. OR, on the other hand, is a slight departure from the conventional OR; this OR is exclusive and embodies a notion of priority, such that only one of the terms will be explicitly obeyed at any one time and the first operand is more important to satisfy than the second operand. This idea of priority pervades throughout the specification, and is one of the key principles enabling rules in this language to quickly be evaluated. Among rules, strict priority is adopted for both computational efficiency as well as easy cognizance for the user. Strict priority entails that a rule lower on the list may not use any energy at all if a rule higher on the list is unable to run due to energy limitations. Thus, at each evaluation, the system verifies whether every rule above the one relevant to this evaluation has been satisfied; first, the highest-priority rule is verified, then the next highest, and so on. Understanding this notion lets the user decide which consumers and operations should see the least interruption in the case of an energy shortage. In order to translate these written rules into computationally-friendly data structures, we built a parser that identifies the outermost logical operator, splits the rule at that operator, and processes the left and right children. This parser operates in a recursive fashion, descending the tree until inidividual terms are reached. Using this divide-and-conquer method of processing rules, our parser creates a tree data structure for input onto each node at compile-time. This preprocessing step allows our algorithm to conveniently access and understand the priority relationships between the terms in the rules. An example of a relatively complex rule and the tree produced by the recursive parser can be seen in Figure 2.

3.2

API

The API provides the low-level node programmer an interface for deciding which lines of code belong to which account and transaction, creating the functional groupings mentioned in the previous section. In our design, the contents of the API stem directly from our choice to separate the functions of the user of the sensornet from the programmer. As stated before, the identity of the various accounts and transactions present in an application should be known in advance by both the programmer as well as the user so the former can appropriately annotate the code with ownership and the latter can establish meaningful priority and rate decisions. We suggest that the programmer provides a listing and short description of each account and transaction so the end user is able to make intelligent decisions when expressing a policy; this listing serves a similar function to javadoc for the Java library. The exact form of this API is below. In each case, the

AND

AND

Lifetime.length = 100

OR

Light.sense > 5

Comm.send 1

Lifetime.length = 100 AND ((Light.sense > 5 OR Humidity.sense > 1) AND Comm.send