diff simulators

IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 7, NO. 4, NOVEMBER 2011 601

Power-Aware System Design of WirelessSensor Networks: Power Estimation and

Power Profiling StrategiesJan Haase, Senior Member, IEEE, Javier Moreno Molina, Member, IEEE, and Dietmar Dietrich, Senior Member, IEEE

(Invited Paper)

Abstract—Modern design of wireless devices requires the de-signers to have a special focus on power consumption to prolongthe battery life of the final system. The designer therefore needspower consumption information very early in the process to beable to decide on system parameters, design methods, communica-tion protocols, functionality restrictions. Typically, this is done byrunning simulations of the system to be developed and performingdesign space exploration. However, there is a tradeoff betweenspeed and accuracy of simulation, therefore the designer has tobe aware of available tools and simulation methods he can choosefrom to achieve the best possible solution for his case.

This paper gives an overview over the currently existing simu-lators and simulation methods for fast system simulation with re-spect to power consumption and concludes with a vision of futuresimulator opportunities.

Index Terms—Power estimation, power profiling, power-awaresystems, simulation, simulator, wireless sensor network (WSN).

I. INTRODUCTION

T HE TYPICAL wireless device of today is from one oftwo classes. There are portable consumer products, small,

easy to use, fun to use, smart helpers in daily life. Examples aremobile phones, MP3 players, portable electronic games, GPSdevices, etc. The second class are wireless sensors in cars, air-planes, building automation or even at every single item found ina building or private home—the vision of the internet of things[1].

As the device is wireless, it has to run on battery power. Thegrowing number of features of today’s consumer products needmore and more power, so that battery lifetimes shrink consider-ably—e.g., many mobile phones have to be recharged every day[2]. In the area of sensor networks, sensors are part of a wire-less network using up much energy for sending and receivingmessages [3]. Typical examples are wireless light switches inmodern buildings, or pressure monitors in car tires, which haveto be able to send information about suddenly changing tirepressures. A low battery may render a safety device like thisinoperable and thus be dangerous. Some of these devices are in-stalled at remote or hard to reach places and hence cannot be

Manuscript received April 13, 2011; revised May 13, 2011; accepted July18, 2011. Date of publication September 06, 2011; date of current versionNovember 09, 2011. Paper no. TII-11-220.

The authors are with the Institute of Computer Technology, Vienna Universityof Technology, Vienna 1040, Austria (e-mail: [email protected]).

Digital Object Identifier 10.1109/TII.2011.2166793

recharged easily. Energy efficiency is therefore very importantin Wireless Sensor Networks (WSNs) [4].

To tackle the problem of short battery lifetimes, system de-signers take the power consumption of the devices into accountalready at the time when they are developed. One approach is toinclude power saving features at run time like automatic shut-down of displays or clock gating to switch off unused parts of thedevice [5]. Another way is the estimation of power consumptionfor different sets of system parameters (e.g., duty cycles, com-munication protocols, bus widths, or processor types) in order tochoose the design solution having the lowest energy consump-tion. This is mainly done by means of simulation, which has tobe performed anyway to assure the correct function of the de-vice. However, simulation is in most cases slow, i.e., in order tosimulate all details of a system, the run time of the simulationis often higher by orders of magnitude than the run time of thefinal device itself [6]. This slowdown is further increased by in-cluding power consumption analyses into the simulation.

This paper gives an overview over the existing solutionsfor fast system simulation with respect to power consumption.Section II explains the new dimension acquired by poweraware and low-power approaches in the case of WSNs’ designcompared to those in other embedded systems. Section IIIportrays the different motivations for simulation in WSNs,which are the foundations for WSN simulators presentedin Sections IV–VI. Section VII focuses in power simula-tion, describing the required tasks. Section VIII introducesstate-of-the-art approaches and tools for power simulation andprofiling. This paper concludes in Section IX.

II. POWER CONSUMPTION IN WIRELESS SENSOR NETWORKS

(WSNS)

The first concept that shall be clarified, in order to understandpower concerned design is the difference between low-powerand power-aware design. The former consists on consuming asless power as possible in every moment, no matter the long-term efficiency of the decision made. The latter tries to reach thehighest efficiency, in terms of the metric the designer is tryingto optimize, for a specific power budget. This distinction wasalready defined by Pedram et al. [7]. Even though both strategieshave a lot in common, sometimes decisions to make may differfrom one to the other.

The essential starting point on the way to power optimiza-tion, is gathering knowledge about power consumption of the

1551-3203/$26.00 © 2011 IEEE

602 IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 7, NO. 4, NOVEMBER 2011

system. In traditional embedded systems, this can be done bytracking energy consumption values of different subsystems.There is already, however, a semantic gap between hardwarepower consumption and software power consumption. Manysoftware tasks involve several subsystems, and therefore profilesare required in order to sum all the related energy consumption.These profiles enable identifying the contribution of softwareparts to power consumption. Hence, the designer can focus onoptimization of those tasks whose impact in power consumptionis more significant.

Software profiles are an old concept, that emerged due toprogram complexity. Complex programs involve many rou-tines, processes and threads and therefore, information aboutresources utilization is difficult to obtain [8]. Rialto softwareprofiler [9] classified different threads into so called “activi-ties.” By grouping threads into coherent semantic categories,they could be fairly and efficiently scheduled in the CPU.

In WSNs, the same concept is needed, although oriented topower consumption. This kind of profiling has already beenported to WSN in AEON [10], Quanto [11], and SNOPS [12].

Nonetheless, WSNs cannot be just evaluated as traditionalembedded systems, even those with network connectivity. Inthose cases, the power efficiency which concerned the designerwas always within the boundaries of the embedded system.However, WSN must usually be considered as a whole singledistributed system.

One of the main characteristics of most WSNs is redundancyand fault tolerance. Maximizing a node lifetime can be com-pletely different from maximizing the network lifetime, as a net-work may be completely functional in spite of having nodes withdepleted batteries. Therefore, not only the node local knowledgeis required for power optimization, but a global network-wideknowledge as well.

Thus, in addition to hardware and software profiles, commu-nication and network-wide profiles are crucial in order to beable to optimize the network as a whole [13]. Network profilespermit evaluating and improving protocols, topologies, appli-cations and even hardware architectures, as some requirementscan be tuned finer after evaluating the network behavior.

III. WSNS SIMULATION

The need of a whole network model to evaluate applicationsand algorithms was one of the first motivations for simulation.

Simulation is a useful technique that assists the designer atmany different stages and levels of the system development.

A preliminary simulation is one of the most valuable sourcesof information to make the best decisions when designing yoursystem architecture. High-level simulation, through behavioralor functional models, provides a good overview of the systemeven at the very beginning of the project.

Virtual prototyping, provides reliable data about the systemoperation and can be used by the designer to test differenthardware architectures before producing the real prototype.Emulation permits executing nodes source code or instructionsin a different machine and is usually combined with simulators.Although accurate models are preferred, even the notion of thesystem behavior provided by rough simulation models with

coarse granularity can assist the designer to get an idea aboutwhat components have the most significant impact in overallpower consumption.

Besides, in systems with many nodes, testing the networkbehavior of different protocols implementation in the protocolstack would be very expensive. Furthermore, even when propa-gation conditions are difficult to simulate, special conditions areeasier to model on simulation rather than recreating them on atest platform.

Simulation is also a very powerful tool for software optimiza-tion. Although software can easily be tested on a real device, andthere are profiling add-ons in operating systems [11], doing iton simulation permits gathering network-wide knowledge aboutresources utilization. Operating system emulators execute realcode applications, making possible the development of softwareat the same time as hardware and independent from it, once theoperating system is fixed.

Hence, simulation helps with all hardware, software and net-work design. In WSNs, all these levels are strongly coupled, andeven when focusing in one of them, the others shall still be takeninto account in order to obtain satisfactory results.

Finally, another important use of simulation is validation. Val-idating big networks or evaluating nodes and network lifetime,which can reach several years, is completely impractical in areal platform. In addition, corner cases are easier to recreate insimulation than in a demonstrator.

Once the different aspects and motivations of simulation forWSNs have been presented, it is easier to understand which ofthem have more presence in the available simulators and wheretheir robustnesses and weaknesses are.

As WSNs are the convergence of different existing technolo-gies, first simulators were an evolution of previous ones but in-corporating specific models that are important in WSNs.

There are mainly two starting points for WSN simulators.• Network simulators: either general purpose, such as ns-2

[14], or more focused in mobile ad hoc wireless networks,such as OMNeT++[15].

• Machine simulators: such as Embra [16], based on SimOS[17].

When specific operating systems appeared, new simulatorsassociated to them appeared as well, such as TOSSIM (forTinyOS) or COOJA (for Contiki), where real code applicationscould be simulated.

In Fig. 1, the simulators presented in this paper are classifiedaccording to their predominant abstraction level.

Also, energy simulation in microprocessor based systems wasnot a novel issue. Apart from hardware energy consumptionmodels, there were also analysis of energy consumption reduc-tion by software optimization [18] and even energy simulationof a Real-Time Operating System (RTOS) [19].

IV. NETWORK AND PROPAGATION SIMULATORS

Before the arising of WSNs, several simulator extensions al-ready existed for ad hoc mobile networks, being among themost representatives those developed in Monarch project [20]or GloMoSim [21] and its commercial version QualNet [22].

Soon, extensions for those existing simulators were devel-oped, just before specific tools, designed with WSNs in mind,

HAASE et al.: POWER-AWARE SYSTEM DESIGN OF WIRELESS SENSOR NETWORKS: POWER ESTIMATION AND POWER PROFILING STRATEGIES 603

Fig. 1. Abstraction levels of simulation in WSNs, from cycle accurate simulation to pure functional simulation. Simulators are classified in their predominantlevel, although some of them permit cross-level simulation.

TABLE INETWORK SIMULATORS SUMMARY TABLE

were released. Table I outlines some of these tools, which arebriefly described in Sections IV-A–IV-I.

A. General Network Simulators

First, WSN simulators consisted on extensions for more gen-eral network simulators.

One of those simulators was the network simulator ns-2 [23],a very popular free discrete-event network simulator based onREAL simulator [24].

ns-2 was not optimized for wireless ad-hoc networks. Scal-ability was an issue as WSNs are usually large networks witheven more than thousand nodes. Modifications were made tosolve this issue. For instance, whenever a node sent a message,all the other nodes received the signal, even when its strengthwas so low that influence in communication was negligible: nei-ther can these signals be received by those nodes nor contributeto the received noise. A truncation algorithm which preventsvery far allocated nodes from receiving a signal was proposedin [25], making ns-2 much more scalable.

While independent from ns-2 and not compatible, there isa new simulator intended to be a new improved version andeventual replacement of ns-2, named ns-3 [26].

The most important commercial general network simulator isOPNET [27], which also includes a wireless library.

The best advantage of ns-2, ns-3, and OPNET tools is theamount of protocol implementations which already exist, whichcan be reused in new projects. However, apart from reusabilityof algorithms and protocols, their performance is, in general,poorer than in more specific simulators.

Besides, although it is possible to include new modules, theyare not conceived for hardware modeling, which is necessary toestimate power consumption.

B. SensorSim

The first documented sensor network simulator was Sen-sorSim [28]. It was based on the ns-2 simulation core. Due tothe high-level abstraction of ns-2, which is a general purposenetwork simulator, SensorSim added specific models requiredfor sensor networks.

First, SensorSim was already concerned about power as arestricting factor for WSNs deployment. Therefore, it addedpower models for the hardware components.

Second, ns-2 applications are mostly generic traffic genera-tors. SensorSim permitted simulating real applications as wellas interacting with real nodes (hardware-in-the-loop).


Finally, it provided also a Graphical User Interface (GUI).Unfortunately SensorSim was soon discontinued and not

available anymore.

C. Prowler

Prowler [29] is a probabilistic WSN simulator, written inMATLAB.

Prowler includes a radio propagation model able to evaluatereception parameters and collisions. The advantage, in compar-ison with radio models included in other simulators, is that itnot only models the deterministic attenuation along distance,but also includes a time variant factor. As a result of a collision,a message can be marked as corrupted or not corrupted, no moregranularity is provided.

Prowler has also the advantage of being able to exploitMATLAB visualization possibilities.

While Prowler provides a very complete channel estimationmodel, it does not support hardware modeling. MATLAB sim-ulation performance is good at channel estimation because it in-volves many calculations. Nonetheless, hardware models wouldinvolve general purpose object-based or component-based sim-ulations, and performance would quickly deteriorate.

Prowler has also been migrated to Java. The name of this Javaversion is JProwler [30]. The mathematical computation andvisualization possibilities of MATLAB are lost, in favor of agreater flexibility which would permit modeling hardware com-ponents directly as Java objects. However, no specific supportfor those models is included in JProwler. In addition, the onlyimplementation supplied is a MICA2 mote implementation withalmost no modularity, and therefore not suitable for reuse.

To sum up, Prowler and JProwler provide a complete andreusable radio propagation model, but node implementationsother than MICA2 would require starting from the scratch.

D. J-Sim

Another simulation framework for WSNs is J-Sim [31],former JavaSim, an open source, component-based generalpurpose network simulation environment [32]. It is developedin Java and based on the SensorSim simulation framework (seeSection IV-B). It is therefore, closely related to ns-2.

The sensor simulator part of J-Sim differentiates betweenthree types of nodes: sensor nodes, target nodes and sink nodes.Sensor nodes gather the information, target nodes encapsulate itinto a message and send them to the sink nodes, which consumeand process the information.

Power models are provided for both energy sources (e.g., bat-teries) and energy-consuming components (e.g., transceiver).Another key feature of J-Sim is that it allows simulating mo-bile nodes. It includes several propagation models to estimatesignal power loss. Nevertheless, it does not model noise.

J-Sim supports network emulation, where protocols can betested in a real environment, while other components are ex-ecuted in a virtual environment, i.e., using a testbed with realnodes in the laboratory to execute some tasks, while the rest isexecuted in the simulation. This hardware-in-the-loop is donein both top-down and bottom-up directions. In the former case,a socket layer is provided which replicates the interfaces of theactual operating system, so that the application communicates

with the virtual environment in the same way it communicateswith the operating system. In the latter case, real packets are in-tercepted and translated into J-Sim simulated packets.

J-Sim, as ns-2, is difficult to use, due to its general purposenature. This difficulty is tried to be compensated by providinga module library. However, in spite of having components forpower and sensor modeling, it is difficult to understand whythe only wireless MAC protocol distributed with J-Sim is IEEE802.11, while in WSNs, protocols like IEEE 802.15.4, basis,among others, of ZigBee specification, are of great importance.

Furthermore, simulators like J-Sim and ns-2 are still ineffi-cient in comparison with more specific simulators, even thoughthey incorporate some optimizations to model WSNs. Simula-tion performance is a constant problem in WSN simulation, dueto the low-level details required to capture power consumptionaccurately, and the high number of nodes integrating the net-work. Therefore, in a flexibility versus performance tradeoff, thebalance tips in favor of performance.

E. VisualSense

VisualSense is a modeling framework, built on top of PtolemyII [33], for simulating component-based WSNs models [34].

Ptolemy II is an open-source framework for actor-orienteddesign which enables the construction of domain-specific tools.It supports several models of computation: process networks(PNs), discrete-events (DEs), dataflow (SDF), synchronous/re-active(SR), rendezvous-based models, 3-D visualization, andcontinuous-time models [35].

VisualSense exploits and extends the discrete-event domainof Ptolemy II. It provides a wireless sound detection model as anapplication scenario. VisualSense includes models for packets,packet losses, battery power, power loss, collisions, and transmitantenna gain (directional antennas).

The propagation model included in VisualSense is accurate,based on a general model which can be applied to other physicalphenomena, so that it is also valid for sensor physics, i.e., thephysical phenomena captured by sensors, such as temperature,pressure, etc.

There is also the possibility of executing TinyOS programs inPtolemy, through Viptos [36], an integrated graphical develop-ment and simulation environment. Viptos is able to transforma diagram into a nesC program [37] (see Section V-A) whichcan be executed in a TinyOS platform. It can create Ptolemy IImodels from nesC files as well.

VisualSense provides a graphical user interface (GUI) forboth building the simulation and showing the results. Modulescan be dragged and dropped and connected to build the desiredscenario. If modules included in VisualSense are not sufficient,new modules can be created by connecting some of them, or bydirectly programming them in Java.

The graphical orientation and the flexibility concerningmodels of computation, make of VisualSense a very useful andeasy to use simulator for small and generic high-level simula-tions, mainly focused on specific proof of concepts. However,the value of these positive features falls when modeling biggerand more complex simulation scenarios which require highsimulation performance and automatic scenario generation.


F. SENSE

Another network simulator for WSNs is SEnsor NetworkSimulator and Emulator (SENSE) [38], which is built on top ofComponent Oriented Simulation Toolkit (COST) [39].

COST is a component-based general purpose discrete eventsimulator. Component-based design is more suitable for net-work simulations, as all interaction is captured by interfaces, sothat interdependence is restricted. As a result, components aremore reusable and extensible than ordinary objects.

In order to improve performance, SENSE exchanges thepointer to a message instead of the actual message. This way,all nodes receive the same message instead of one copy, andmuch less message allocation is required. The message is notsupposed to be modified during a transmission (except fromnoise, delay and distortion, which are modeled separately), sothat sharing the same message is safe. The only problem is deal-location, which is achieved through a reference counter whichtracks the number of components referencing the message. Ifthe counter reaches 0, the message is deleted.

SENSE includes a rudimentary propagation model. There aretwo options. In the first and simpler option, a message is fullytransmitted (without errors) to all the nodes within the stipulatedrange. There is a second model which includes some fluctua-tions. In this case, there is a range in which the 100% of the mes-sages are always fully received. Outside this range, the proba-bility of receiving the message decreases linearly with distance.No noise or interference is modeled.

There are also components for battery models, applications,routing algorithms and MAC protocols [40]. As in J-Sim, theMAC protocol included is IEEE 802.11, which is not the mostsuitable standard for power aware sensor networks.

While more focused in WSN than other general purpose sim-ulators, and in spite of being easier to use, SENSE is still a com-ponent-based simulator with a very poor component library. Thepropagation model is quite deceiving as it models neither accu-rate attenuation nor noise. It provides no special assistance orintegration for hardware models.

G. PAWiS

Another popular network simulator is OMNeT++[15].OMNeT++ is a component-based discrete-event simulationlibrary for building network simulators. One of those simula-tors, focused in power aware WSNs is PAWiS (Power AwareWireless Sensors) [41].

The PAWiS project consists of several elements: a framework,a module library and a visualization tool.

The PAWiS Framework models the physical layer and in-cludes a propagation model. This propagation model simulatesattenuation due to distance as well as interferences and noise.Dynamics of the network can be simulated at runtime throughLua scripting language [42].

The module library consists of implementations of specificdevices and protocols using the framework. It includes not onlysimple examples but specific power aware algorithms, such asS-MAC [43], CSMA-MPS [44], and hardware models, likeChipcon low-power transceiver CC2420 [45].

CPU time estimation is left in hands of the system designer,which provides some parameters about his algorithms, which

then are computed to get the estimation of the number of CPUcycles required to execute them. However, there is also an ex-tension which provides time annotation, increasing the accuracyof the application simulation [46].

Simulation’s graphical user interface (GUI) is the one pro-vided by OMNeT++, which permits the inspection of the dif-ferent elements at runtime, but also makes the simulation veryslow. Anyhow, GUI can be simplified or even deactivated forhigher speed simulations.

PAWiS Framework is not an extension of OMNeT++,as a general purpose simulator, but takes advantage ofOMNeT++core classes, such as modules, message passinginfrastructure and discrete event simulation kernel, to build aspecific WSN simulator. The module library includes simpleimplementations with basic functionality. This makes PAWiSeasy to use, as the user can always start with a basic workingsimulation and progressively extend it.

The main drawbacks of PAWiS are some inefficiencies, suchas message replication for each peer to peer transmission, whichin dense networks lead to huge memory allocation, and prob-lems related to OMNeT++core, which is designed for networkmodeling and runs into granularity problems when using it forhardware modeling.

H. SNOPS

SNOPS (Sensor Networks Optimization by Power Simula-tion) is a simulation library to develop WSNs [47]. SNOPS isbased on SystemC [48] and TLM 2.0 (Transaction-Level Mod-eling) [49], both intended for system-level design.

Even though SystemC and TLM are not designed for net-work simulation, the event-driven SystemC simulation kerneland TLM communication interfaces are abstract enough to beapplied to network simulation. Besides, it enables the use ofSystemC and TLM for system-level design of the node archi-tecture without incurring co-simulation, which increases com-plexity and is costly in terms of simulation performance.

The main feature of SNOPS is its transaction concept, whichabstracts all end-to-end communications in a single data struc-ture, while keeping low-level accuracy. This transaction com-prehends the message generated by the sensor node and all itsreplicas generated through a multi-hop path. This supposes notonly a performance improvement, based on allocation reduc-tion, but also provides a data structure able to gather meaningfulinformation about effects on the whole network of node infor-mation exchanges. This information is very valuable for energyoptimization, as it will be discussed later.

The radio model is an enhancement of PAWiS’ model, sothat it can include time-variant effects in the attenuation cal-culation, such as fading or mobility. With this enhancement,SNOPS propagation model becomes one of the most accurate,with time-variant effects, as Prowler, but with bit-level collisionsimulation, which permits a more accurate simulation of noiseand collisions, as it is not the same to receive an erroneous bitin the preamble as in the body of a transmission.

The SNOPS library is independent from hardware models,to keep it generic and maintain its flexibility. At the moment,no module library with implementations of either systems orprotocols is provided. The user has therefore to provide his


TABLE IIOPERATING SYSTEM EMULATORS SUMMARY TABLE

own models. However, SNOPS provides structures to integratethose models. For instance, there is a data structure to createfinite state machines and power consumption information canbe recorded through an unified power logger. This unificationis necessary to provide energy profiles, which have to beregistered at low-levels to present high-level information [12].

I. SCNSL

Simulation of networked embedded systems motivated thedevelopment of SCNSL (SystemC Network Simulation Li-brary), which, as SNOPS (see Section IV-H), uses SystemC tosimulate networks, so that both system and network design canbe modeled in a single tool [50]. SCNSL is, at the moment,work in progress and is still in beta status [51].

Propagation model is not as detailed as in SNOPS, but isable to calculate attenuation as a distance function and to de-tect collisions.

SCNSL Framework has been extended in IDEA1, addingsome protocol and hardware implementations and a graphicaluser interface (GUI) [52].

V. OPERATING SYSTEMS EMULATION

With the development of different hardware platforms andoperating systems, it become necessary to test applications.However, migrating the code from simulations to the real noderequired reprogramming and correcting bugs coming frombad assumptions, which worked in simulation but failed inembedded systems, which have very restricted resources. Thenecessity to test the new supply of operating systems, togetherwith the need of testing real-code applications before deploy-ment, motivated the appearance of operating system emulationenvironments. Table II is a short reference to the simulatorsanalyzed next.

A. TOSSIM

One of the first and most used simulators for WSN isTOSSIM [53]. TOSSIM is a simulator for TinyOS, an oper-ating system for wireless sensor nodes [54], and it is includedin the TinyOS distribution package.

The main purpose of TOSSIM is to develop and test TinyOSapplications in a simulation environment without installingthem in the actual node. Those applications are written in nesC,an extension of C programming language specially designed forsensor networks [37]. TOSSIM permits simulating a networkof thousand of nodes running the same application.

To be able to simulate many nodes efficiently, they are all sim-ulated in the same process. During compilation, variables arestored in arrays, where each element belongs to a specific node.

Simulating many nodes is therefore feasible without having toexecute many virtual machines. However, there is the drawbackof not being able to simulate heterogeneous networks, with dif-ferent node architectures, operating systems or applications.

Radio propagation environment is modeled as a statisticalprocess. TOSSIM includes an ideal environment model and adirected graph of bit error probabilities. The simplicity of theradio model increases scalability, but details about network be-havior are lost.

TOSSIM is an operating system-level simulator. Precise CPUtiming, such as interrupts are not captured, as it is in more de-tailed cycle-accurate models. Moreover, it does not capture en-ergy consumption itself. However, there are extensions for thatpurpose, such as PowerTOSSIM for TinyOS v1.x [55] and Pow-erTOSSIM 2 or PowerTOSSIMz for TinyOS v2.x [56], [57].

B. TOSSF

TinyOS Scalable Simulation Framework (TOSSF) [58], is aTinyOS simulator, that broadens TOSSIM scope beyond appli-cation verification, increasing its scalability and improving theenvironmental models.

TOSSF is based on two previous mobile ad-hoc networkssimulation tools: Dartmouth Scalable Simulation Framework(DaSSF) [59] and Simulation of Wireless Ad-hoc Networks(SWAN) [60].

Unlike TOSSIM, it permits simulating heterogeneous net-works, with different nodes, which may differ in architecture,operating systems and applications.

It includes also more sophisticated radio propagation and en-vironmental models. Environmental models recreate the physicsand metrics that stimulate the sensors. Therefore, a more real-istic network and application behavior is achieved, in compar-ison with TOSSIM.

Nevertheless, CPU execution time is also missing in TOSSF.As a result, while satisfactory behavioral models of a WSNcan be simulated, there is a lack of accuracy that is required toachieve reliable power estimation.

C. EmSim/EmCee

EmSim is a pure simulation environment which is providedas part of Emstar software environment [61]. Emstar is a frame-work to develop WSNs applications. It runs over Linux. It pro-vides a set of useful interfaces at very different levels to makethe development of applications easier. It can understand evensome TinyOS applications through EmTOS [62], which trans-lates the TinyOS system API into the Emstar API.

As TOSSIM, EmSim enables real-code simulation [63].When used in pure simulation mode, EmSim provides a radiochannel simulator and a sensor simulator.


An advantage of EmSim is that it supports an emulationmode, which allows hardware-in-the-loop simulations, i.e.,using real hardware, such as radio transceivers or sensors,while running the other elements in a simulation machine.

Interfaces for hardware-in-the-loop simulation are providedby EmCee and are very useful when the environment of the ap-plication scenario is easy to recreate and propagation and sensedphysical magnitudes can be tested with realistic values. How-ever, if environmental conditions are hard to reproduce, realhardware values may not be better than simulated ones.

Another difference regarding TOSSIM is that EmSim offersinterfaces for heterogeneous simulation, which means that it hasthe ability to simulate nodes with different hardware architec-tures or operating systems, in the latter case by wrapping theMote code in the already mentioned EmTOS tool.

D. COOJA

COOJA is a simulator for the Contiki [64] operating systemfor sensor nodes [65]. It is implemented in Java. AlthoughCOOJA is really flexible and permits cross-level and heteroge-neous simulation, it is primarily a Contiki emulator.

The best advantage of COOJA is its flexibility, which permitsexecuting simultaneous simulations of nodes at all the network,operating system or hardware levels.

Apart from operating system emulation, where real Contikicode can be tested, COOJA permits high-level Java nodemodels, with network functionality and coarse granularity. Onthe other hand, it includes also MSPsim, an instruction setsimulator, to simulate cycle-accurate models [66].

Hardware emulation permits also simulating nodes with otheroperating systems other than Contiki, such as TinyOS.

Communication between COOJA and the compiledevent-driven Contiki kernel is done through Java NativeInterface (JNI) calls.

Concerning the propagation models, custom models can beeasily plugged in in COOJA. In the distribution, a unit disk graphmodel is included. There are also extensions for ray-tracingbased radio medium model [67], in order to model obstacles,and a radio interference simulation model [68].

All this flexibility makes of COOJA a very interesting simu-lation environment, with the possibility of modeling heteroge-neous networks and creating cross-level simulations, in orderto evaluate WSNs in all network, operating system and hard-ware levels. The main drawback of such flexibility is the effectof maintaining so many interfaces in scalability, in terms of thenumber of nodes that can be simulated, and in the overall sim-ulation efficiency.

VI. HARDWARE EMULATION

Both network simulators and operating system emulatorsdo not provide enough granularity level in order to validateand verify some aspects of wireless sensor nodes. In order toaccurately evaluate power consumption, timing informationabout the CPU is required. Although some estimations or codetransformations can be made, one important approach is touse instruction set simulators and cycle-accurate models of thehardware.

Apart from the effect on performance of cycle-accurate mod-eling, the main drawback of these models is that such a degree ofaccuracy prevents them from being generic, and they have to becreated for an specific hardware architecture. Hence, althoughthese models are the only to provide fine granularity about hard-ware models, they are not practical enough for hardware archi-tecture design, due to their lack of flexibility which preventsfrom easily replacing models in the simulation. Before using acycle-accurate model, at least the micro-controller family musthave been already decided.

A. ATEMU

The first simulator to provide a low-level cycle-accurate CPUmodel was ATEMU [69]. While there were already emulatorsfor processors, ATEMU was the first emulator tool actually fo-cused on WSNs, and able of emulating several nodes composinga network.

Unlike TOSSIM, ATEMU depends only on the hardware itemulates, and therefore is not restricted to a specific operatingsystem. It could even help to develop an operating system itself.

ATEMU includes an AVR emulation core, and is suited there-fore to emulate nodes based on AVR micro-controllers, such asthe MICA2.

ATEMU also includes a radio propagation model based ondistance attenuation which takes into account interferences fromother nodes, making the algorithm that keeps track of receivedpower a n-squared algorithm.

Cycle-accuracy, together with the interference radio model,makes of ATEMU a very accurate but inefficient model, withsignificant scalability problems.

B. AVRORA

The second simulator presented here is the well-known AVRemulator AVRORA [70].

AVRORA provides a cycle-accurate model of MICA andMICA2 motes, and was created to overtake ATEMU perfor-mance while keeping the cycle-accurate granularity [71]. Theobjective was accomplished resulting in a cycle-accurate andscalable WSN simulator. Nevertheless, it is still slower thanTOSSIM.

The last official release is from 2005 and supports AT-Mega128, ATMega32 and ATMega16 micro-controller models.

AVRORA radio model does not include noise simulation, butcalculates interference by doing an arithmetic OR with bytes re-ceived (correctly synchronized). However, this approach is veryinaccurate, and should take into account the modulation of thereceived signals.

AVRORA, as most simulators, is extensible, and some suc-cessful extensions have been developed, like AVRORAz [72],which allows emulation of the Crossbow MICAz mote and in-cludes an indoor radio model.

In addition AVRORAz extends AVRORA to create IEEE802.15.4 Standard [73] compliant simulations [74]. Theseextensions include the address recognition algorithm, frameacknowledgement, Link Quality Indicator (LQI) and ClearChannel Assessment (CCA), as well as the already mentionedindoor radio model.


C. MSPsim

MSPsim is an instruction level emulator of the MSP430 mi-croprocessor series [75]. It is also based in Java. MSPsim isspecifically designed for sensor network simulation and for in-tegration in COOJA. Therefore, multiple instances can run ina single process. It includes also an event-based simulation oftypical WSN peripherals, such as sensors, communication ports,etc. The rest of its features are those obtained from COOJA in-tegration described in Section V-D.

VII. POWER SIMULATION AND PROFILING APPROACHES

In power simulation, there are two main tasks to take intoaccount: the first one is to create accurate power models for bothproducers and consumers. The second is to take the informationprovided by those power models and order it in what are calledprofiles, so that it becomes meaningful for the designer.

A. Power Consumer Models

Power models of energy consumer devices usually dependon the accuracy they are modeled with. The most extendedapproach of power models consist on Finite State Machines(FSM). Power consumed by a specific subsystem is calculatedas the product of the different power values of everystate and the time spent by the subsystem at thecorresponding state. The energy consumed by a node is the sumof the energy consumed by its subsystems .

Different states and the power consumption at each state areusually specified in the device datasheets. The unknown factor,which has to be determined by simulation is therefore, the timespent at each state. In transceivers, state transitions are usuallytriggered by the CPU or determined by the protocols and areeasy to predict and track. Nevertheless, modeling state tran-sitions on CPUs requires accurate information about the pro-cessing time needed to execute the implemented algorithms.This information is provided by cycle-accurate models. How-ever, such a fine grained detail level not only slows the simu-lation but is also strongly dependant on the processor, so thatsimulation of different architectures at that level becomes un-feasible. This tradeoff determines the different approaches inpower simulation, in search of the best balance depending onthe designer needs.

B. Battery Models

Apart from modeling power consumption, in order to accu-rately evaluate the lifetime of a node, power supplies must alsobe modeled. However, batteries, which are the most commonpower supply, have a nonlinear behavior depending on so manyvariables, such as temperature, that even most detailed modelscan significantly deviate from reality.

Simplest models consider fixed capacity of the batteries andsimply subtract energy consumption costs until capacity isdepleted.

There are also analytical models which are able to pre-dict battery lifetime and model nonlinearities, such asRakhmatov–Vrudhula (R-V) battery model [76], based ontwo parameters which can be either estimated or obtained fromdatasheets, when provided.

There is also an extensible framework for OMNeT++, wheredifferent battery models can be easily attached. However, at themoment only a simple linear battery implementation is docu-mented [77].

C. Power Profiling

While most simulators focus on power modeling, creatingprofiles is even a more crucial task. Power consumption infor-mation is normally associated to the hardware subsystems, aspower models are defined based on hardware models and speci-fications. This information has to be gathered at a very low-levelin order to be accurate. However, software tasks involve severalhardware subsystems at the same time. Furthermore, commu-nication and network tasks involve subsystems from differentnodes all over the network.

There is therefore, a semantic gap between power consump-tion information and software and network designers.

Profiles aim to provide meaningful information associatedwith software and network power consumption in order to opti-mize it. Fig. 2 depicts the different directions in which low-levelpower consumption data has to be abstracted, giving examplesof some abstractions made in all the three perspectives: hard-ware, software, and network.

VIII. EXTENSIONS TO WSN SIMULATORS

Due to the importance of power consumption in WSNs, mostsimulators include different strategies to estimate it. In mostpopular simulators, where power simulation was not consideredat first, specific extensions were developed later on top of them.

Some of these extensions also deal with power profiling, sothat the application and network protocols developer can obtainknowledge about power consumption referred to both softwareand network tasks.

A. Energy Framework for NS-3

As ns-3 is a very generic network simulator, specific energyframeworks have been developed. An integrated, modular, andextensible framework is presented in [78].

This framework provides models for energy sources and con-sumers and interfaces between them.

In the case of energy sources, it includes not only a basiclinear battery model, but also a R-V model, which also considersthe nonlinear behavior.

Energy consumer devices are assumed to be modeled as finitestate machines, with each state associated with its correspondingcurrent draw value. However, the framework is also able to sim-ulate devices with an undefined number of states, as long as thecurrent draw value can be estimated as a function of any othermagnitude, e.g., an electric motor whose power consumption isa function of the rotation speed.

Unfortunately, this energy framework provides no energyprofiling tools.


Fig. 2. Data about power states and states transitions is recorded and interpreted in three different directions: hardware, software, and network.

B. PAWiS

Power simulation is not supported directly in the framework.However, the framework includes an interface to model CPUsand a power meter class where power related information canbe reported to be logged.

In the PAWiS module library, there are implementations oftransceivers and CPUs. However, granularity of CPU models isnot fine enough to obtain accurate timing.

In addition, PAWiS includes a power visualization postpro-cessing tool which graphically represents the information fromthe power logs.

Profiles are associated with components reporting powerstate transitions, which are hardware simulation components.Although there are also software components, there is notracking of the power consumed below, so that software profilescannot be created.

C. SNOPS

SNOPS was designed with power optimization in mind. Itdoes not provide energy models itself, but includes the glue tointegrate different power models with different accuracies andto create unified and configurable power profiles from them.

As the main approach to power modeling is the definition offinite-state machines, SNOPS provides its own finite-state ma-chine object. Once defined by the user, the SNOPS state ma-chine prevents from triggering forbidden transitions, relievingthe designer from manually checking transitions. In addition,whenever a state transition occurs, it is automatically registeredin a unified power logger.

Information in the power logger is not only labeled with nodeand hardware device information, but also with so called activ-ities, which can be defined by the software developer, and withthe SNOPS transaction identifier.

The accuracy of energy consumption estimations depend onthe system-level models, created with both SystemC and TLM.There are TLM cycle-approximate RTOS [79] and OpenRISCTLM models [80], which can provide fine grained simulationof the CPU. In addition, an Instruction Set Simulator (ISS) hasalso been used together with the SNOPS library [81].

D. IDEA1

An energy consumption model has been developed also forIDEA1 simulator, introduced in Section IV-I [82].

This model is based on finite-state machines. Accuracy of themodel is subject to IDEA1 accuracy. In IDEA1, timing of themicrocontroller unit is estimated from software assembly code,and is therefore not cycle-accurate. Moreover, IDEA1 is not areal-code emulator, so that these estimations are not as reliableas in other simulators.

This energy consumption model can organize the informationbased on the hardware device and their states. No software ornetwork profiling tools are included.

E. PowerTOSSIM

PowerTOSSIM is an extension to TOSSIM to model energyconsumption. It creates per-node and per-component energyprofiles, based on state transitions logged at runtime. Thismeans that, as long as the state machine scheme remains thesame, several power models, with different power consumptionvalues for each state, can be applied after execution.


Accuracy of PowerTOSSIM is restricted by TOSSIM limita-tions, which are mainly the network and propagation behaviorand the inaccuracy capturing CPU timing. In the former case,PowerTOSSIM does not enhance TOSSIM’s propagationmodel. In the latter case, PowerTOSSIM separates tasks inblocks and uses a code-transformation technique to estimatethe number of CPU cycles they require. Nevertheless, deviationstill exists in comparison with cycle-accurate models whenmany asynchronous events (like interrupts) take place.

The network-wide energy profiling problem is not addressedby PowerTOSSIM.

PowerTOSSIM was developed on top of TOSSIM for TinyOS1.x. When TinyOS 2.x. was released, a newer version, Power-TOSSIM2, was created. PowerTOSSIM and TOSSIM are bothdistributed together with TinyOS.

PowerTOSSIM and PowerTOSSIM2 were created forMICA2 motes. PowerTOSSIMz extends the latter one forMICAz nodes [57]. However, apart from the different targetarchitecture, PowerTOSSIMz includes a battery postprocessormodel which simulates the nonlinear discharging of the battery.In spite of being a postprocessor, it can also work at runtime. Itimplements a stochastic approach to battery model.

F. AEON

There is a power extension for AVRORA, called AEON andincluded from version 1.4 [10]. As AEON runs over AVRORA,it is able to capture low-level details which are crucial for anaccurate energy consumption estimation.

AEON also includes a free-space radio propagation modelfor AVRORA, with distance attenuation but without modelingnoise.

The pros and cons of AVRORA and AEON are determinedbecause of emulation. On one hand, emulation is independentfrom the operating system. On the other hand, emulation is onlyvalid for a specific hardware configuration. Thus, even when itis possible to simulate applications for different operating sys-tems, the results are still restricted to MICA2 motes. In additionnot all the node components are supported by AVRORA andAEON.

Apart from estimating the energy consumed by every nodecomponent, AEON creates also profiles on what they calledroutines, which are the specific tasks realized during operation,such as routing, sensing, low-level transmission, or reception.

G. COOJA

The power profiling tool used in COOJA consists of an in-tegration of the power profiler used in the Contiki operatingsystem [83] into the COOJA/MSPsim simulation.

Energy estimation in Contiki consists on recording timestamps whenever a component is activated and making thecorresponding calculations based on the time difference whenthe component is deactivated.

Timeline is a visualization tool for COOJA with special focuson power consumption [84].

The advantage of COOJA is that the model has been validatedand can work over MSPsim, which is cycle-accurate. However,power consumption information is not interpreted beyond the

local node perspective. Hence, it is possible to estimate the life-time of a node, but neither software profiles nor network profilesare provided.

IX. CONCLUSION

As described in previous sections, there are several difficul-ties in energy aware WSNs design. All of them could be eval-uated and solved through simulation. However, there are manytools with different approaches and no clear winner.

The previous classification and brief description of some no-table simulators aims to assist the designer making the deci-sion of what simulator to use and to calibrate the expectationsabout what can be obtained through simulation depending onthe chosen simulator.

Network simulators provide protocols and propagationmodels but lack low-level details which are crucial to ac-curately estimate power consumption. Operating systememulators provide real code emulation but still do not cap-ture microcontroller timing, required for energy consumptioncalculation. Hardware emulators are the only to accuratelyestimate energy consumption. Nevertheless, they have severedeficiencies, mainly in simulation performance and networkand propagation modeling, and they tend to forget the impor-tance of higher levels, such as software and network, so thataccurate energy consumption estimations become meaninglessand therefore useless for energy optimization at those levels,which have a huge impact in overall WSN lifetime.

There are therefore both bottom-up and top-down evolutionsfrom cycle-accurate and high-level simulation models, respec-tively. While simulation performance tends to be less a problemwith newer simulation machines, the main difficulty seems to befilling the semantic gap between low-level details and high-levelsimulation, which has to be accomplished through profile cre-ation, in this case power profiles.

It can be expected that in the future, some simulators willreach completeness, so that a single simulator will be able tomodel everything needed in WSNs, avoiding simulator cou-pling. This not only would suppose a boost to simulation per-formance, but would also enable multilevel, and above all, realcross-level design.

Simulators are continuously increasing their range of modelsand applications. Nevertheless, while increasing complexity,the amount of data available from a simulation grows enor-mously. In order to provide real versatility, a big effort mustbe made in data representation, i.e., to provide the users withrelevant information depending on their interests. If the data setkeeps growing, log files become unmanageable, and it will benecessary to apply data mining techniques in order to handlesuch an amount of information. This way, the same simulatorcould realistically be used for such disparate applicationsas network traffic simulation or temperature estimation on amulticore system.

Furthermore, new possibilities for simulation have arisenwith multicore processors. Distributed simulation attemptshave been made, but synchronization was a bottleneck [85].However, with multicore processors, simulation could be dis-tributed among the cores within a single machine (currentlyup to 1024 cores in a single commercial Graphical Processing


Unit), where synchronization overhead is lower. Exploring thispossibility and leveraging this technology is going to be animportant task in the next few years.

REFERENCES

[1] J. Conti, “The internet of things,” Commun. Eng., vol. 4, no. 6, pp.20–25, 2006.

[2] A. Shye, B. Scholbrock, G. Memik, and P. A. Dinda, “Characterizingand modeling user activity on smartphones,” Northwestern Univ.,Evanston, IL, 2010, Tech. Rep..

[3] H.-Y. Zhou, D.-Y. Luo, Y. Gao, and D.-C. Zuo, “Modeling of node en-ergy consumption for wireless sensor networks,” Wireless Sensor Net-work, vol. 3, pp. 18–23, Jan. 2011.

[4] A. Willig, “Recent and emerging topics in wireless industrial commu-nications: A selection,” IEEE Trans. Ind. Inform., vol. 4, no. 2, pp.102–124, May 2008.

[5] Q. Wu, M. Pedram, and X. Wu, “Clock-gating and its application to lowpower design of sequential circuits,” IEEE Trans. Circuits and Syst. I:Fundamental Theory and Appl. , vol. 47, no. 3, pp. 415–420, Mar. 2000.

[6] E. Egea-Lopez, J. Vales-Alonso, A. Martinez-Sala, P. Pavon-Mario,and J. Garcia-Haro, “Simulation scalability issues in wireless sensornetworks,” IEEE Commun. Mag., vol. 44, no. 7, pp. 64–73, Jul. 2006.

[7] M. Pedram and J. Rabaey, Power Aware Design Methodologies. Nor-well, MA: Kluwer , 2002, pp. 2–3.

[8] S. L. Graham, P. B. Kessler, and M. K. Mckusick, “Gprof: A call graphexecution profiler,” in Proc. SIGPLAN Symp. Compiler Construction,SIGPLAN’82, New York, 1982, pp. 120–126.

[9] M. B. Jones, D. L. McCulley, A. Forin, P. J. Leach, D. Rosu, andD. L. Roberts, “An overview of the Rialto real-time architecture,” inProc. 7th Workshop on ACM SIGOPS Eur. Workshop: Syst. Supportfor Worldwide Appl., New York, 1996, pp. 249–256.

[10] O. Landsiedel and K. Wehrle, “AEON: Accurate prediction of powerconsumption in sensor networks,” in Proc. IEEE 2nd Workshop on Em-bedded Networked Sensors (EmNetS-II), 2004, pp. 37–44.

[11] R. Fonseca, P. Dutta, P. Levis, and I. Stoica, “Quanto: Tracking energyin networked embedded systems,” in Proc. 8th USENIX Conf. Oper-ating Syst. Design and Implementation, OSDI’08, Berkeley, CA, 2008,pp. 323–338.

[12] J. M. Molina, J. Haase, and C. Grimm, “Energy consumption esti-mation and profiling in wireless sensor networks,” in Proc. 23th Int.Conf. Architecture of Comput. Syst. Workshop, ARCS’10, Feb. 2010,pp. 259–264.

[13] D. Agrawal, “Designing wireless sensor networks: From theory to ap-plications,” Central Eur. J. Comput. Sci., vol. 1, pp. 2–18, 2011.

[14] K. Fall and K. Varadhan, “The NS Manual,” 2010. [Online]. Available:http://www.isi.edu/nsnam/ns/doc/ns_doc.pdf

[15] “OMNeT++Network simulator framework,” OMNeT++Community,accessed 2011 [Online]. Available: http://www.omnetpp.org/

[16] E. Witchel and M. Rosenblum, “Embra: Fast and flexible machine sim-ulation,” in Proc. Int. Conf. Meas. Modeling of Comput. Syst., SIGMET-RICS’96, New York, 1996, pp. 68–79.

[17] M. Rosenblum, S. Herrod, E. Witchel, and A. Gupta, “Complete com-puter system simulation: The SimOS approach,” IEEE Parallel Distrib.Technol.: Syst. Appl., vol. 3, no. 4, pp. 34–43, 1995.

[18] V. Tiwari, S. Malik, and A. Wolfe, “Power analysis of embedded soft-ware: A first step towards software power minimization,” IEEE Trans.Very Large Scale Integr. (VLSI) Syst., vol. 2, no. 4, pp. 437–445, Dec.1994.

[19] R. P. Dick, G. Lakshminarayana, A. Raghunathan, and N. K. Jha,“Power analysis of embedded operating systems,” in Proc. 37th Annu.Design Autom. Conf., DAC’00, New York, 2000, pp. 312–315, ser. .

[20] D. B. Johnson, “Validation of wireless and mobile network modelsand simulation,” in Proc. DARPA/NIST Network Simulation ValidationWorkshop, May 1999.

[21] X. Zeng, R. Bagrodia, and M. Gerla, “GloMoSim: A library for parallelsimulation of large-scale wireless networks,” in Proc. 12th Workshopon Parallel and Distributed Simulation, PADS’98, Washington, DC,1998, pp. 154–161.

[22] S. N. Technologies, “Qualnet,” accessed 2011. [Online]. Available:http://www.scalable-networks.com/products/qualnet/

[23] The Network Simulator—ns-2, accessed 2011. [Online]. Available:http://www.isi.edu/nsnam/ns/

[24] S. Keshav, “REAL: A network simulator,” Univ. California at Berkeley,Berkeley, CA, Tech. Rep., 1988.

[25] V. Naoumov and T. Gross, “Simulation of large ad hoc networks,” inProc. 6th ACM Int. Workshop on Modeling Analysis and Simulation ofWireless and Mobile Syst., MSWIM’03, New York, 2003, pp. 50–57.

[26] T. R. Henderson, S. Roy, S. Floyd, and G. F. Riley, “ns-3 project goals,”in Proc. Workshop on ns-2: The IP Network Simulator, WNS2’06, NewYork, 2006, pp. 13–20.

[27] “OPNET.” [Online]. Available: http://www.opnet.com/[28] S. Park, A. Savvides, and M. B. Srivastava, “Sensorsim: A simulation

framework for sensor networks,” in Proc. 3rd ACM Int. Workshop onModeling, Anal. Simulation of Wireless and Mobile Syst., MSWIM’00,New York, 2000, pp. 104–111.

[29] G. Simon, P. Volgyesi, M. Maroti, and A. Ledeczi, “Simulation-basedoptimization of communication protocols for large-scale wirelesssensor networks,” in Proc. IEEE Aerosp. Conf., Mar. 2003, vol. 3, pp.1339–1346.

[30] “JProwler.” [Online]. Available: http://w3.isis.vanderbilt.edu/projects/nest/jprowler/

[31] “J-Sim Official.” [Online]. Available: http://sites.google.com/site/jsi-mofficial/

[32] A. Sobeih, J. Hou, L.-C. Kung, N. Li, H. Zhang, W.-P. Chen, H.-Y.Tyan, and H. Lim, “J-Sim: A simulation and emulation environmentfor wireless sensor networks,” IEEE Wireless Commun.”, vol. 13, no.4, pp. 104–119, Aug. 2006.

[33] E. A. Lee, “Finite state machines and modal models in ptolemy II,”EECS Dept., Univ. California, Berkeley, CA, 2009. [Online]. Avail-able: http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-151.html

[34] P. Baldwin, S. Kohli, E. A. Lee, X. Liu, Y. Zhao, C. C. T. Ee, C.Brooks, N. V. Krishnan, S. Neuendorffer, C. Zhong, and R. Zhou, “Vi-sualSense: Visual modeling for wireless and sensor network systems,”UCB ERL Memorandum UCB/ERL M04/8, Tech. Rep., 2004.

[35] Ptolemy II EECS Dept., Univ. California, Berkeley, CA, accessed2011. [Online]. Available: http://ptolemy.berkeley.edu/ptolemyII/

[36] E. Cheong, E. A. Lee, and Y. Zhao, “Viptos: A graphical developmentand simulation environment for TinyOS-based wireless sensor net-works,” EECS Dept., Univ. California, Berkeley, CA, 2006. [Online].Available: http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-15.html

[37] D. Gay, P. Levis, R. von Behren, M. Welsh, E. Brewer, and D. Culler,“The nesC language: A holistic approach to networked embedded sys-tems,” in Proc. Conf. Programming Language Design and Implemen-tation, ACM SIGPLAN’03, New York, 2003, pp. 1–11.

[38] G. Chen, J. Branch, M. Pflug, L. Zhu, and B. Szymanski, “SENSE:A wireless sensor network simulator,” in Advances in Pervasive Com-puting and Networking, B. K. Szymanski and B. Yener, Eds. NewYork: Springer, 2005, pp. 249–267.

[39] G. Chen and B. Szymanski, “COST: A component-oriented discreteevent simulator,” in Proc. Winter Simulation Conf., 2002, vol. 1, pp.776–782.

[40] “SENSE: Sensor network simulator and emulator,” C. of PervasiveComputing and Networking, accessed 2011. [Online]. Available: http://www.ita.cs.rpi.edu/sense/

[41] S. Mahlknecht, J. Glaser, and T. Herndl, “PAWiS: Towards a poweraware system architecture for a SoC/SiP wireless sensor and actornode implementation,” in Proc. 6th IFAC Int. Conf. Fieldbus Syst.Their Appl., 2005, pp. 129–134.

[42] R. Ierusalimschy, L. H. de Figueiredo, and W. C. Filho, “Lua: An exten-sible extension language,” Softw. Pract. Exper., vol. 26, pp. 635–652,Jun. 1996.

[43] W. Ye, J. Heidemann, and D. Estrin, “An energy-efficient MAC pro-tocol for wireless sensor networks,” in Proc. IEEE 21st Annu. JointConf. Comput. Commun. Societies, 2002, vol. 3, pp. 1567–1576.

[44] S. Mahlknecht and M. Bock, “CSMA-MPS: A minimum preamblesampling MAC protocol for low power wireless sensor networks,”in Proc. IEEE Int. Workshop Factory Commun. Syst., Sep. 2004, pp.73–80.

[45] “Chipcon CC2420 Datasheet. Texas Instruments,” 2007. [Online].Available: http://focus.ti.com/lit/ds/symlink/cc2420.pdf

[46] G. Möstl, R. Hagelauer, A. Springer, and G. Müller, “Accurate power-aware simulation of wireless sensor networks considering real-life ap-plication code,” in Proc. 13th ACM Int. Conf. Modeling, Anal. Simu-lation of Wireless and Mobile Syst., MSWIM’10, New York, 2010, pp.31–38.

[47] M. Damm, J. Moreno, J. Haase, and C. Grimm, “Using transaction levelmodeling techniques for wireless sensor network simulation,” in Proc.Conf. Exhibition, Design, Autom. Test in Europe, DATE, Mar. 2010, pp.1047–1052.


[48] SystemC Open SystemC Initiative, accessed 2011. [Online]. Available:http://www.systemc.org

[49] “Transaction-level modeling,” Open SystemC Initiative—Transaction-Level Modeling Working Group, accessed 2011. [Online]. Available:http://www.systemc.org/downloads/standards/tlm20/

[50] F. Fummi, D. Quaglia, and F. Stefanni, “A SystemC-based frameworkfor modeling and simulation of networked embedded systems,” inForum on Specification, Verification and Design Languages, FDL’08,2008, pp. 49–54.

[51] “SystemC Network Simulation Library,” accessed 2011. [Online].Available: https://sf.net/projects/scnsl/

[52] W. Du, F. Mieyeville, and D. Navarro, “IDEA1: A SystemC-basedsystem-level simulator for wireless sensor networks,” in Proc. IEEEInt. Conf. Wireless Commun., Networking and Information Security,WCNIS’10, Jun. 2010, pp. 618–622.

[53] P. Levis, N. Lee, M. Welsh, and D. Culler, “TOSSIM: Accurate andscalable simulation of entire tinyos applications,” in Proc. 1st Int. Conf.Embedded Networked Sensor Syst., SenSys’03, New York, 2003, pp.126–137.

[54] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K. Pister,“System architecture directions for networked sensors,” SIGPLANNot., vol. 35, pp. 93–104, Nov. 2000.

[55] V. Shnayder, M. Hempstead, B.-R. Chen, G. W. Allen, and M. Welsh,“Simulating the power consumption of large-scale sensor network ap-plications,” in Proc. 2nd Int. Conf. Embedded Networked Sensor Syst.,SenSys’04, New York, 2004, pp. 188–200.

[56] T. Prabhakar, S. Venkatesh, M. Sujay, J. Kuri, and K. Praveen, “Simu-lation blocks for TOSSIM-T2,” in Proc. 3rd Int. Conf. Commun. Syst.Softw. Middleware Workshops, COMSWARE’08, Jan. 2008, pp. 17–23.

[57] E. Perla, A. O. Catháin, R. S. Carbajo, M. Huggard, and C. M. Goldrick,“PowerTOSSIM z: Realistic energy modelling for wireless sensor net-work environments,” in Proc. 3nd ACM Workshop on PerformanceMonitoring and Meas. Heterogeneous Wireless and Wired Networks,PM2HW2N’08, New York, 2008, pp. 35–42.

[58] L. Perrone and D. Nicol, “A scalable simulator for TinyOS appli-cations,” in Proc. Winter Simulation Conf., Dec. 2002, vol. 1, pp.679–687.

[59] J. Liu and D. M. Nicol, “DaSSF 3.1 User’s Manual,” ac-cessed 2011. [Online]. Available: http://users.cis.fiu.edu/liux/re-search/projects/dassf/papers/dassf-manual-3.1.ps

[60] J. Liu, L. F. Perrone, D. M. Nicol, M. Liljenstam, C. Elliott, and D.Pearson, “Simulation modeling of large-scale ad-hoc sensor networks,”in Proc. Eur. Simulation Interoperability Workshop, 2001.

[61] L. Girod, J. Elson, A. Cerpa, T. Stathopoulos, N. Ramanathan, andD. Estrin, “EmStar: A software environment for developing and de-ploying wireless sensor networks,” in Proc. Ann. Tech. Conf. USENIX,ATEC’04, Berkeley, CA, 2004, pp. 24–24.

[62] L. Girod, T. Stathopoulos, N. Ramanathan, E. Osterweil, T. Schoell-hammer, and R. Kapur, “EmTOS: A development tool for heteroge-neous sensor networks,” 2004. [Online]. Available: http://escholarship.org/uc/item/2wx27188

[63] L. Girod, N. Ramanathan, J. Elson, T. Stathopoulos, M. Lukac, and D.Estrin, “EmStar: A software environment for developing and deployingheterogeneous sensor-actuator networks,” ACM Trans. Sen. Netw., vol.3, p. 24, Aug. 2007.

[64] “Contiki operating system,” accessed 2011. [Online]. Available: http://www.sics.se/contiki

[65] F. Osterlind, A. Dunkels, J. Eriksson, N. Finne, and T. Voigt, “Cross-level sensor network simulation with COOJA,” in Proc. 31st Conf.Local Comput. Networks, Nov. 2006, pp. 641–648.

[66] J. Eriksson, F. Osterlind, N. Finne, A. Dunkels, N. Tsiftes, and T. Voigt,“Accurate network-scale power profiling for sensor network simula-tors,” in Wireless Sensor Networks, U. Roedig and C. Sreenan, Eds.Berlin/Heidelberg: Springer, 2009, vol. 5432, pp. 312–326.

[67] F. Österlind, “A ray-tracing based radio medium in COOJA,” 2006.[Online]. Available: http://www.sics.se/contiki/news/a-ray-tracing-based-radio-medium-in-coo

[68] C. A. Boano, K. Römer, F. Österlind, and T. Voigt, “Demo abstract:Realistic simulation of radio interference in COOJA,” in Proc. Eur.Conf. Wireless Sensor Networks (EWSN 2011), Feb. 2011.

[69] J. Polley, D. Blazakis, J. McGee, D. Rusk, and J. Baras, “ATEMU:A fine-grained sensor network simulator,” in Proc. 1st Annu. IEEECommun. Soc. Conf. Sensor and Ad Hoc Commun. Networks, Oct.2004, pp. 145–152.

[70] “Avrora: The AVR simulation and analysis framework,” UCLA Com-pilers Group,, 2011 [Online]. Available: http://compilers.cs.ucla.edu/avrora/

[71] B. L. Titzer, D. K. Lee, and J. Palsberg, “Avrora: Scalable sensor net-work simulation with precise timing,” in Proc. 4th Int. Symp. Inform.Process. Sensor Networks, IPSN’05, Piscataway, NJ, 2005.

[72] R. de Paz Alberola and D. Pesch, “AvroraZ: Extending Avrora with anIEEE 802.15.4 compliant radio chip model,” in Proc. 3rd ACM Work-shop on Performance Monitoring and Measurement of HeterogeneousWireless and Wired Networks, PM2HW2N ’08, New York, 2008, pp.43–50.

[73] Wireless Medium Access Control (MAC) and Physical Layer (PHY)Specifications for Low-Rate Wireless Personal Area Networks(WPANs), IEEE Standard 802.15.4-2006, 2006.

[74] “Avroraz: Enabling IEEE 802.15.4 compliant emulations,”Center for Adaptive Wireless Systems, 2011. [Online]. Available:http://citavroraz.sourceforge.net/docextensions.html

[75] J. Eriksson, A. Dunkels, N. Finne, F. Österlind, T. Voigt, and N.Tsiftes, “MSPsim—An extensible simulator for MSP430-equippedsensor boards,” in Proc. Eur. Conf. Wireless Sensor Networks (EWSN),Poster/Demo Session, Jan. 2007.

[76] D. Rakhmatov, S. Vrudhula, and D. A. Wallach, “Battery lifetime pre-diction for energy-aware computing,” in Proc. Int. Symp. Low PowerElectronics and Design, ISLPED’02, New York, 2002, pp. 154–159.

[77] L. M. Feeney and D. Willkomm, “Energy framework: An extensibleframework for simulating battery consumption in wireless networks,”in Proc. 3rd Int. ICST Conf. Simulation Tools and Techniques, SIMU-Tools’10, Brussels, Belgium, 2010, pp. 20:1–20:4.

[78] H. Wu, S. Nabar, and R. Poovendran, “An energy framework for thenetwork simulator 3 (ns-3),” in Proc. SIMUTools 2011, Mar. 2011.

[79] Y. Hwang, G. Schirner, S. Abdi, and D. G. Gajski, “Accurate timedRTOS model for transaction level modeling,” in Proc. Conf. De-sign, Autom. Test Europe, DATE’10, Leuven, Belgium, 2010, pp.1333–1336.

[80] J. Bennett, “Building a loosely timed SoC model with OSCI TLM 2.0,”2008,, embecosm Application Note 1.

[81] M. Lang, J. Haase, and J. Wenninger, “Distributed multi-level simula-tion of wireless sensor networks,” in Proc. 24th Int. Conf. Architectureof Comput. Syst. Workshop, ARCS’11, Feb. 2011, pp. 251–256.

[82] W. Du, F. Mieyeville, and D. Navarro, “Modeling energy consumptionof wireless sensor networks by SystemC,” in Proc. Int. Conf. Syst. Net-works Commun., 2010, vol. 0, pp. 94–98.

[83] A. Dunkels, F. Osterlind, N. Tsiftes, and Z. He, “Software-basedon-line energy estimation for sensor nodes,” in Proc. 4th Workshopon Embedded Networked Sensors, EmNets’07, New York, 2007, pp.28–32.

[84] F. Österlind, J. Eriksson, and A. Dunkels, “Cooja TimeLine: A powervisualizer for sensor network simulation,” in Proc. 8th ACM Conf.Embedded Networked Sensor Syst., SenSys’10, New York, 2010, pp.385–386.

[85] Z.-Y. Jin and R. Gupta, “Improving the speed and scalability ofdistributed simulations of sensor networks,” in Proc. Int. Conf. Inform.Process. Sensor Networks, IPSN’09, Washington, DC, 2009, pp.169–180.

Jan Haase (M’07–SM’09) received the Diplomadegree in computer sciences at Goethe University,Frankfurt, Germany. He then became a Research As-sistant at the Department of Technical Informatics,Frankfurt University. There he focused on the fieldof computer architectures, dynamic and distributedparallel computation, middlewares, and embeddedsystems, resulting in his Ph.D. thesis on the scalable,dataflow-driven virtual machine (SDVM).

Since 2007, he is a Senior Researcher and ProjectLeader at Vienna University of Technology. His re-

search interests include hardware/software co-design, design methodologies forheterogeneous (AMS+HW/SW) systems, wireless sensor networks, power con-sumption optimization, and automatic parallelization. He is author and coauthorof more than 70 reviewed publications.

Dr. Haase is currently IEEE Austria Section Chair. He is an Associate Editorof the IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS and served and servesas Program (Co-) Chair or Member in several program committees of inter-national conferences like IECON, AFRICON, DATE, FDL, CSNDSP, ICIEA,Austrochip, and smaller workshops.


Javier Moreno Molina (M’08) received the M.Sc.degree in telecommunications engineering from theUniversidad Politecnica de Madrid, Madrid, Spain.Currently, he is working towards the Ph.D. degree atthe Institute of Computer Technology, Vienna Uni-versity of Technology, Vienna, Austria.

He has worked in several research projects aboutnetwork simulation, wireless sensor networks, smartenergy demand, and home automation. His researchinterests are network engineering, HW/SW/networkcodesign, power consumption simulation, and opti-

mization and wireless networks simulation.

Dietmar Dietrich (M’96–SM’04) became Professorof Computer Technology in 1992. He founded theCenter of Excellence for Fieldbus Systems in 1994,and the International Biennial Fieldbus ConferenceFeT, in 1995. He has been Head of the Instituteof Computer Technology, Vienna University ofTechnology, Vienna, Austria, from 1999 to 2008. Hisresearch interests are digital ASIC design, fault-tol-erant systems, cognitive science and communicationsystems, especially on fieldbus and communicationsystems for smart grids. He was a delegate of the

OVE and ON in CEN and CENELEC. He became a member of the board ofthe OVE in 2002 and was Vice President until 2008.

Dr. Dietrich was Chair of Section Austria from 2006 to 2008. He has beenAssociate Editor for EURASIP, the IEEE TRANSACTIONS ON INDUSTRIAL

INFORMATICS (TII), and Industrial Electronics (TIE), He was ADCOMmember, and initiator of IEEE/IES/TC BACM and twice its TC Chair.

diff simulators

Documents