Abstract

Sensornets are becoming more widely adopted for commercial and scientific use and, in settings where battery replacement or recharging is difficult, it is important that sensornets have long and predictable lifetimes. We thus expect energy management to play an increasingly important role in meeting user requirements. Today, system developers seek a balance between network lifetime and performance, but recent history shows that unexpected and dynamic environmental conditions often scuttle expected energy budgets. For example, many nodes in the Great Duck Island deployment were conjectured to have died prematurely because unexpected overhearing of traffic caused radios to become operational for longer than originally predicted [22]. This pattern was repeated in the Redwoods deployment, but for a supposedly different reason: some nodes seemingly died prematurely because they became disconnected from the wireless network and depleted their batteries trying to reconnect [24]. Even systems augmented with energy harvesting are still susceptible to this type of problem. In the Trio Testbed, seasonal and daily variations in solar power, the angle of inclination of the solar cell, the effect of dirt and bird droppings on the cells, and the inefficiencies in power storage and transfer resulted in node duty cycles ranging from 20% to 100% [5]. The issues with these deployments arise from mistaken assumptions, unforeseen difficulties, and unpredictable environmental dynamics. Solutions to these issues take two extreme approaches. At one extreme, some have proposed runtime adaptation to meet lifetime requirements [16] or energy availability [11, 10]. While promising, these efforts have addressed rather coarse-grained, high-level adaptation – for example, by adjusting sampling rates or varying the system-wide duty cycle – but they remain silent on prioritizing energy usage in a fine-grained and flexible manner. At the other extreme, low-level energy management mechanisms that give direct control over the hardware to multiple entities (e.g. network protocols) can be tedious to implement and difficult to debug because of the lack of any isolation. Arbitration can address the isolation problem, but it does not enable runtime adaptation to varying workloads [12]. We believe that using an energy management architecture would alleviate or even prevent these types of problems. SecEnforcement

Full Text
Published version (Free)

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call