Energy is the most limiting resource in sensor networks. This is particularly true for dynamic sensor networks in which the sensor-net application is not statically planned. We describe three components of our energy management system for nodes in such dynamic sensor networks: A flexible energy model and an accounting infrastructure for making sensor nodes energy-aware, and Resource Containers for managing the energy accounting information

Bellosa, Frank

Kellner, Simon

KITopen

Energy Accounting Support in TinyOSSimon Kellnerkellner@ira.uka.deFrank Bellosabellosa@ira.uka.deSystem Architecture GroupUniversita¨t KarlsruheABSTRACTEnergy is the most limiting resource in sensor networks. Thisis particularly true for dynamic sensor networks in which thesensor-net application is not statically planned. We descri-be three components of our energy management system fornodes in such dynamic sensor networks: A flexible energymodel and an accounting infrastructure for making sensornodes energy-aware, and Resource Containers for managingthe energy accounting information.1. INTRODUCTIONEnergy still is the most critical resource in sensor networks.Current energy supplies already take up most of a sensornode’s space, but can provide the desired node lifetimes ofyears only when sensor-net application designers give a highpriority to a long sensor-net lifetime. Sensor-Net OperatingSystems (OSes) like TinyOS [2] encourage energy saving bynot providing a convenient CPU-abstraction such as threads,which could, for example, tempt application developers intocreating CPU-intensive waiting loops and thus into wastingenergy.Database interfaces to sensor nets like TinyDB [5] make iteasy for users to retrieve sensor data: A sensor-net applica-tion is formulated as a request in an SQL-like language andinterpreted by the sensor network until the request expi-res. The program on the sensor nodes only needs the abilityto interpret and execute such requests. This eliminates theneed to reprogram sensor nodes and allows multiple queriesto be processed simultaneously.Such dynamic systems can support multiple users in a sensornet, each with his own set of queries. In this scenario it isdesirable to account the energy consumption of each query,e.g. to bill users based on their sensor-net usage, or to findthe query with the highest energy consumption and cancelit before it wears down the energy supplies.In this paper we describe several parts of a solution to energymanagement on sensor nodes that addresses multi-user dy-namic sensor networks. The presented solution is currentlybeing implemented for MICAz nodes in TinyOS 2. First wedescribe our energy model for a sensor node, then the infra-structure used in taking measurements and accounting theenergy. As a third part, we describe the concept of ResourceContainers, which will be employed to fairly distribute theaccounted energy in our dynamic sensor-net setting.2. RELATEDWORKThe management of energy in sensor networks has received asignificant share of research over the last years, as it concernsthe primary resource of such networks.PowerTOSSIM[6] is perhaps the approach most similar toour own model and accounting infrastructure. It instrumentsOS components or simulations thereof to track power statesand uses an energy model to compute energy consumptionfor one or more sensor nodes. However, there is no implemen-tation for current versions of TinyOS. Its energy model onlyconsiders hardware states, not the transitions in-between.The most significant difference is in the intended use: Ourinstrumentation and model are designed to be used in on-line energy accounting as opposed to off-line simulation.AEON[4] is the energy model used in the AVRORA[7] si-mulator. It models the hardware states of a MICA2 node.Our model is based primarily on the MICAz node and ad-ditionally considers transitions between hardware states.Energy measurements of a MICAz node can be found in [3].The measurements of the AtMega128 controller are detailed,but the measurements of the ZigBee controller (CC2420) se-verely lack details. Our measurements show a real differencebetween the listen and the transmit state, regardless of theprogrammed output power in the latter.Resource Containers are an OS-abstraction introduced byBanga, Druschel and Mogul [1] in 1999 for accounting onweb-servers and consist basically of OS-provided storage foraccounting data. The idea is to separate OS abstractionsfor CPU and resource accounting, so one can base accoun-ting on other, more suitable abstractions. In the PC world,for example, Resource Containers (RCs) give administratorsand users the ability of accounting all activity connected toa user request, which usually has a higher significance thanprocess-based accounting.3. ENERGYMODELOur sensor node energy model is designed to be used bothfor off-line simulations and on-line accounting. To this end,the model is specified in a more formal manner than usual.Our energy model is based on finite state machines thatclosely model the hardware’s power states and transitions.To account for the concurrency possible on typical hardwa-re, each subsystem on a sensor node is modeled by its ownCC2420SHT11sht11_idlename: measuringpower: 0.505 mAtime: 204 msparameters:Pl: Packet lengthpwr: Output power settingcc2420_idlelistenpower=22.37 mAtransmit_15power=17.08 mAtime: 0.125 ms + 0.76 us * Pltransmit_31power=21.62 mAtime: 0.125 ms + 0.76 us * Pltime: 0.60 msname: stxoncondition: pwr == 15energy: 6.96 uAsname: start_tempenergy: 3.5 uAstime: 7 msenergy: 0time: 0time: 0.41 msname: set_output_powerset: pwrtime: 0.40 msenergy: 6.8 uAstime: 0.37 msname: stxoncondition: pwr == 31energy: 8.55 uAsenergy: 13.3 uAsFigure 1: Energy models for the CC2420 and SHT11chipsstate machine. For example, the OS can finish instructingthe radio controller to send a packet, start taking a measu-rement on a sensor, and get interrupted by a preset timer. Inthis example, the radio controller, the sensor, and the micro-controller each are modeled by one finite state machine.States and transitions of these machines are attributed withtheir physical characteristics such as time (duration), energy,or power. These characteristics often depend on parametersfrom outside such as the battery voltage or packet length.Values for these parameters have to be supplied by eachprogram that uses this model.The model states describe the hardware states in as muchas they can be distinguished by their power consumption.A small part of such an energy model is shown in Figure 1.Simple hardware like sensors or LEDs can be modeled by asmall number of states. The model for the SHT11 chip inFigure 1, for example, covers the whole process of measuringthe temperature. For other chips like the ZigBee controllerCC2420 this approach can result in multiple transmit states,one for each selectable transmission power. Of the 32 availa-ble and 8 documented power settings, only two are shownin Figure 1 due to space constraints. Furthermore, the tran-sitions from cc2420 idle to the transmit states have beenomitted to avoid cluttering.Transitions in the model describe the time and energy spenton changing the hardware state. A transition can be namedor unnamed. Unnamed transitions are used for state changeswhich are predictable from the hardware layer. For exam-ple, upon completing a transmission the CC2420 controllerautomatically switches back into the listening state whereit could then receive an acknowledgment message. The timespent transmitting is known from the length of the packet,which is known, as a packet must be stored in the CC2420’stransmit buffer prior to transmission. Named transitions, onthe other hand, describe changes that are not predictablefrom a hardware viewpoint, e.g., when the software sendsa command to the radio chip to transmit a packet that iscurrently in the chip’s buffers. In the example, start temp,set output power and stxon are of this type.Some models are further equipped with parameters that canbe used to reduce the number of model states or to calculateenergy consumption. The packet length parameter in Figu-ApplicationOther Timer Mcu CC2420_1 CC2420_2McuAccountingC CC2420AccountingCAccountingCAccountingXC_null AccountingXC_accounting AccountingXC_signalsleepwakeFigure 2: Accounting infrastructure overviewre 1 determines the time the CC2420 spends transmitting, sothe energy consumed for the transmission directly dependson the packet length. The other parameter, output powersetting, is not strictly necessary for modeling. Its primaryuse is to reduce the number of states in the model: Withoutit, the number of states would almost triple: As the out-put power can be programmed in the idle and listen states,there would have to be 32 versions of both states with bi-directional transitions between all versions of a state. So notonly would the number of states nearly triple, the numberof transitions would grow quadratically with them.4. ACCOUNTING INFRASTRUCTUREInformation required to use the model for on-line energyaccounting has to come from various places deep inside asensor node operating system. Usually, this means placeswhere a driver issues commands to or receives interruptsfrom the hardware it manages. Due to the high degree ofmodularization in TinyOS 2, the relevant code places for onehardware chip could be scattered over several directories.The purpose of our accounting infrastructure is to collectthis information in a consistent manner.The process of gathering the accounting information shouldalso be transparent to the sensor-net application. This allowsdevelopers to base energy-aware applications on traditional,statically planned applications without the need to changea lot of code.Energy-relevant code fragments are instrumented by an ad-ditional function call. These function calls are routed firstto a module for the subsystem and then to a central mo-dule named AccountingC, as shown in Figure 2. Here theyarrive as (component , event) pairs, where component refersto a finite state machine of the energy model, and event to anamed transition in this machine. The central module thenuses a back-end to process the gathered information. Thechoice of back-end is configurable from the command lineat compile time. The default back-end (AccountinXC null)simply discards the information. Thus, in spite of introdu-cing these additional function calls in the source code, thisdoes not result in additional object code, as the compilerinlines all involved functions.Aside from the actual accounting process, the infrastruc-ture has shown its flexibility in combination with the Ti-nyOS build system by providing convenient options to in-dicate the energy-relevant events using a GPIO pin to themeasurement hardware outside. For this scenario, the cen-tral accounting component is given a different back-end mo-dule (AccountingXC signal) to use, which in turn uses aplatform-dependent signaling module to access a GPIO pin.This proved to be very helpful for extracting the physicalcharacteristics of our energy model from measurements ofsensor nodes. Parts of the data analysis could be automa-ted, as phase lengths and transitions can be detected moreeasily by these additional signals.5. RESOURCE CONTAINERTo make energy accounting work not only on a single nodebut in a large network, we employ the concept of ResouceContainers (RCs). RCs can be used to account energy con-sumption for each query being executed on the node andaggregate this information throughout the network.In the following we assume that the sensor-net applicati-on responds to user-generated queries and that all packetsrelated to one query carry the same unique ID.5.1 Normal Resource ContainersA normal RC is associated with a query. As soon as an app-lication learns the ID of the query currently being processed,it informs TinyOS that it wishes to switch to the RC asso-ciated with this query. The selected RC is then bound to thecurrent TinyOS task.The energy consumption of all further activities coming fromthis TinyOS task is accounted to the selected RC. If theTinyOS task posts a new TinyOS task or sets up a newtimer, this binding can be stored by the scheduler or timersystem, and can be used to switch back to the stored RCautomatically on the corresponding wake-up call.The OS here clearly depends on the application for cor-rect accounting, but this is both feasible and necessary ina sensor-net application. It is necessary to prevent produ-cing hard-to-maintain code, and it is feasible because thereshould be only few places where this RC-switching occurs,namely when a sensor-net application starts processing aquery.5.2 Anonymous Resource ContainersSince TinyOS applications spend most of their time sleepingand perform only minimal amounts of processing, energyconsumed during interrupt handling is not negligible. Forexample, a timer interrupt may cause the activation of acommunication device, which is subsequently used to sendstored sensor data to other nodes. The sensor node is notaware of the query ID until it accesses the packet it is aboutto send. In the meantime, the activation of the communi-cation device can consume a substantial amount of energythat cannot be assigned to the correct RC at that moment.As a solution, the interrupt handler can allocate a tempora-ry, anonymous RC and use it to account both its own energyconsumption and the device activation. Later, when the ap-plication becomes aware of the query ID, it can switch tothe RC associated with the query, causing the temporaryRC to be merged and released.5.3 Special Resource ContainersIt may be necessary to employ special RCs to provide addi-tional information or to handle cases where the correct RCis not known.5.3.1 Root Resource ContainerOne RC worth mentioning is the RC for the whole node. It isused to collect the amount of energy consumed by the wholenode, regardless of queries. This information is of interest tothe nodes themselves in order to estimate the amount ofremaining energy. It can also be regarded as another datasource and can itself be the target of a query.5.3.2 Idle Resource ContainerSome energy consumption can not be clearly accounted to aquery, e.g., the energy spent during sleep (idle energy). Wecall the problem of accounting this energy consumption ina fair manner accounting fairness.One way to address the issue of idle energy accounting isto distribute the accounted idle energy among all queriesknown to the sensor node. To achieve this, a special RC forthis energy class is present in the system. At certain times,this RC is cleared and its content distributed among all exis-ting normal RCs. This has to be done both periodically andon creation/expiration of a query:• Periodically so that the accounting information remainsrecent.• At query instantiation to avoid penalizing this queryby accounting sleeping energy spent before its instan-tiation.• At query expiration to avoid losing accounted energy.The fairness of this distribution is subject to discussion andthus should be handled by a project-dependent policy. Policyexamples include equal distribution and partitioning accor-ding to duty-cycle or used energy.Concluding, one can picture the RCs in a 3-level hierarchy:the root RC for the node, named RCs for the queries andanonymous RCs to account energy consumed for a (yet) un-known purpose. In this hierarchy, the root RC contains theaggregated accounting data of the named RCs, while theanonymous RCs will eventually be merged with one of thenamed RCs.5.4 Shared DataCaching the acquired sensor data introduces another instan-ce of the accounting-fairness problem. Without additionalmeasures, the first query to sample data bears the cost ofacquiring it, subsequent queries can use it at almost zerocost. If the accuracy of timing or accounting can be relaxed,some trade-offs between one of them and accounting fairnesscan and should be considered.A trade-off between timing accuracy and accounting fairnesscan be implemented as a subscriber model for sensor data:The sensor data is sampled either on time-out after the firstsubscription or when enough parties subscribed to this sen-sor data. The energy is split among all of the subscribedparties.A trade-off between accounting accuracy and fairness can beimplemented by assigning a value to the sampled sensor datathat decays with every access. For example, the initial querybears 3/4 of the costs, the next query 3/4 of the remainingcosts, and after a time-out, the rest is distributed across allqueries that acquired this data.5.5 Resource Container AggregationThe usefulness of Resource Containers becomes apparentwhen they are shared between all network nodes. With thecollected information in these RCs it is possible to accountthe energy consumption of the whole network individuallyfor each query.RCs lend themselves quite naturally to sensor nets with dy-namically created queries. When receiving a new query, asensor node allocates an RC for this query, accounts thequery’s energy costs to that RC and sends the accounteddata back together with the responses to this query.RC contents can easily be aggregated by summation overall RCs with the same query ID. The design of RCs to storeall of the energy accounted to it since its creation makes itresilient to occasional packet loss. When accounting infor-mation is lost in the network due to occasional packet loss,the aggregated accounting information at the data sink maybe incorrect, but it will be correct again after reception ofthe next packet.To allow the data sink to compare aggregated RC valuesfrom different queries and to detect packet loss, a nodeshould additionally send the number of sensor nodes invol-ved in an aggregate, if this information is not already presentin the aggregated sensor data.6. CONCLUSIONIn sensor networks with dynamically created queries, on-lineenergy accounting is necessary to make the network energy-aware. We presented three parts of an on-line energy ac-counting solution currently being developed for TinyOS 2.An accounting infrastructure uses an energy model to makeeach sensor node energy-aware. Resource Containers allowto extend this accounting mechanism to cover the wholenetwork. Together, this is an energy management solutionfor multi-user dynamic sensor networks.7. ACKNOWLEDGMENTSThis work is done as part of the BW-FIT project ZeuS.8. REFERENCES[1] G. Banga, P. Druschel, and J. Mogul. Resourcecontainers: A new facility for resource management inserver systems. In Proceedings of the Third Symposiumon Operating System Design and Implementation(OSDI’99), Feb. 1999.[2] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, andK. Pister. System architecture directions for networkedsensors. In ASPLOS-IX: Proceedings of the NinthInternational Conference on Architectural Support forProgramming Languages and Operating Systems, pages93–104, New York, NY, USA, 2000. ACM Press.[3] M. Kra¨mer and A. Geraldy. Energy measurements forMicaZ node. In 5. GI/ITG KuVS Fachgespra¨ch”Drahtlose Sensornetze“, number 2006/07, pages61–68, Universita¨t Stuttgart, Institut fu¨r Parallele undVerteilte Systeme, July 2006.[4] O. Landsiedel, K. Wehrle, and S. Go¨tz. Accurateprediction of power consumption in sensor networks. InProceedings of The Second IEEE Workshop onEmbedded Networked Sensors (EmNetS-II), May 2005.[5] S. Madden, M. J. Franklin, J. M. Hellerstein, andW. Hong. The design of an acquisitional queryprocessor for sensor networks. In SIGMOD ’03:Proceedings of the 2003 ACM SIGMOD internationalconference on Management of data, pages 491–502,New York, NY, USA, 2003. ACM Press.[6] V. Shnayder, M. Hempstead, B. Chen, G. W. Allen,and M. Welsh. Simulating the power consumption oflarge-scale sensor network applications. In SenSys ’04:Proceedings of the 2nd International Conference onEmbedded Networked Sensor Systems, pages 188–200,New York, NY, USA, Nov. 2004. ACM Press.[7] B. L. Titzer, D. K. Lee, and J. Palsberg. Avrora:scalable sensor network simulation with precise timing.In IPSN ’05: Proceedings of the 4th InternationalSymposium on Information Processing in SensorNetworks, page 67, Piscataway, NJ, USA, 2005. IEEEPress.

Energy Accounting Support in TinyOS

https://publikationen.bibliothek.kit.edu/1000026907/2042627

Energy Accounting Support in TinyOS

Abstract

Similar works

Full text

Available Versions

KITopen