IntroductionBackgroundApplicationOperating SystemsHardwareManaging EnergyICEM DriversVirtualizedDedicatedSharedExample: CC2420 StackIntegrated ManagementDriver Energy ManagementSplit-phase Power LocksComponent LibraryArbitersPower ManagersConfiguratorsSleep Energy ManagementEvaluationMicrobenchmarks: Telos EnergyMicrobenchmarks: Power Lock LibraryApplication PerformanceCode ComplexityExample DriversAtmega128 ADCMTS300 Photo SensorMSP430 USART0StorageRelated WorkConcurrency ControlEnergy ManagementI/O SchedulingFuture WorkConclusionReferencesSource CodeIntegrating Concurrency Control andEnergy Management in Device DriversKevin Klues†∓?, Vlado Handziski?, Chenyang Lu∓, Adam Wolisz?,David Culler•, David Gay‡, and Philip Levis††Stanford University∓Washington University?Technische Universität BerlinStanford, CA St. Louis, MO Berlin, GermanyUniversity of California, Berkeley•Arch Rock Corporation‡Intel Research, BerkeleyBerkeley, CA San Francisco, CA Berkeley, CA{klueska, pal}@cs.stanford.edu {handzisk, wolisz}@[email protected] [email protected] [email protected] management is a critical concern in wireless sensornets. De-spite its importance, sensor network operating systems today pro-vide minimal energy management support, requiring applications toexplicitly manage system power states. To address this problem,we present ICEM, a device driver architecture that enables simple,energy efficient wireless sensornet applications. The key insightbehind ICEM is that the most valuable information an applicationcan give the OS for energy management is its concurrency. Us-ing ICEM, a low-rate sensing application requires only a single lineof energy management code and has an efficiency within 1.6% ofa hand-tuned implementation. ICEM’s effectiveness questions theassumption that sensornet applications must be responsible for allpower management and sensornets cannot have a standardized OSwith a simple API.Categories and Subject DescriptorsD.4.7 [Operating Systems]: Organization and Design; D.2.11[Software Engineering]: Software ArchitecturesGeneral TermsDesign, ManagementKeywordsConcurrency, Energy, Device Driver Architecture, TinyOS1. INTRODUCTIONEnergy efficiency is a critical concern in mobile and battery pow-ered systems. Reducing energy consumption improves system life-time. An OS can improve energy efficiency by putting peripheralsinto low power modes and dropping the processor to a sleep statePermission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.SOSP’07, October 14–17, 2007, Stevenson, Washington, USA.Copyright 2007 ACM 978-1-59593-591-5/07/0010 ...$5.00.when idle. The challenge lies is deciding when and how to do so: tomanage energy well, an OS must infer future application behavior.Prior work has shown us two things are generally true when an OSoptimizes for energy: simple models are rarely effective and a bit ofapplication knowledge can go a long way. For dynamic CPU volt-age scaling, Vertigo [6] showed that having a process tell the OS itsworkload class greatly outperforms simple hardware heuristics andfixed-interval averaging [11], and GRACE-OS demonstrated that re-ceiving explicit real-time deadlines from applications allows an OSto reduce energy further [41]. For disk spindown, Coop-I/O exploredhow application-specified timeouts on disk operations allow the OSto batch requests, outperforming even an oracle spindown policy forstandard file interfaces [39].Despite all of these advances, most modern operating systems stilluse very simplistic energy management policies. The problem isthat, beneath all of their advanced libraries, applications still useAPIs which were designed before energy constraints were a ma-jor concern. At first glance, wireless sensor networks (sensornets)seem to be a domain of computer systems that would avoid these pit-falls. Intended to last for months or years on small batteries, sensor-nets have harsh energy requirements, making energy management acritical component of almost every application. As sensornets havelimited resources and very different use cases than traditional time-sharing systems, they tend to run small, customizable operating sys-tems with flexible abstraction boundaries.In practice today, however, sensornet operating systems, like theirembedded siblings, provide minimal energy management support.They leave all complexity to the application. Embedded OSes suchas eCos [29] and VxWorks [40], for example, have interfaces forprocessor power control but peripheral device control is left to theapplication. Sensornet OSes such as TinyOS [16], Contiki [5],MOS [1], and SOS [12] have power control interfaces which anapplication must explicitly invoke in order to change power states.Pushing all this logic into the application means that the OS doesnot prevent energy saving strategies, but this flexibility comes at thecost of application code complexity. For example, the core code forthe TinyOS Great Duck Island deployment [33] – the first success-ful long-term deployment of the OS – is 500 lines filled with specialcases such as “if forwarding a packet, defer powering down.” In con-trast, if this application were to be implemented using the featuresprovided by ICEM, it would be fewer than 50 lines.In this paper, we present ICEM (Integrated Concurrency and En-ergy Management), a sensornet device driver architecture that allows1a sensornet OS to automatically minimize energy consumption with-out requiring additional explicit information from an application.The key insight behind ICEM is that the most important informa-tion a sensornet application can provide is the potential concurrencyof its I/O. As most sensornet OSes are completely event-driven, anapplication simply needs to make a set of asynchronous system callsand let the OS schedule the underlying operations.The research challenge in ICEM lies in the fact that some op-erations must occur serially. While application-level requests canuse a single API call, peripherals often have complex call/return se-quences, some of which have tight timing constraints. This