A Software-Hardware Emulatorfor Sensor Networks

Jingyao Zhang, Yi Tang, Sachin Hirve, Srikrishna Iyer, Patrick Schaumont, and Yaling YangDepartment of Electrical and Computer EngineeringVirginia Polytechnic Institute and State University

Blacksburg, Virginia 24060Email: {jingyao, yt22, hsachin, skr, schaum, yyang8}@vt.edu

Abstract—Simulators are important tools for analyzing andevaluating different design options for wireless sensor networks(sensornets) and hence, have been intensively studied in the pastdecades. However, existing simulators only support evaluationsof protocols and software aspects of sensornet design. Theycannot accurately capture the significant impacts of varioushardware designs on sensornet performance. As a result, theperformance/energy benefits of customized hardware designs aredifficult to be evaluated in sensornet research. To fill in thistechnical void, in this paper, we describe the design and imple-mentation of SUNSHINE, a scalable hardware-software emulatorfor sensornet applications. SUNSHINE is the first sensornetsimulator that effectively supports joint evaluation and designof sensor hardware and software performance in a networkedcontext. SUNSHINE captures the performance of network pro-tocols, software and hardware up to cycle-level accuracy throughits seamless integration of three existing sensornet simulators:a network simulator TOSSIM [1], an instruction-set simulatorSimulAVR [2] and a hardware simulator GEZEL [3]. SUNSHINEsolves several sensornet simulation challenges, including dataexchanges and time synchronizations across different simulationdomains and simulation accuracy levels. SUNSHINE also pro-vides hardware specification scheme for simulating flexible andcustomized hardware designs. Several experiments are given toillustrate SUNSHINE’s simulation capability. Evaluation resultsare provided to demonstrate that SUNSHINE is an efficient toolfor software-hardware co-design in sensornet research.

I. INTRODUCTION

Over the past few years, we have witnessed an impressivegrowth of sensornet applications, ranging from environmentalmonitoring, to health care and home entertainment. A remain-ing roadblock to the success of sensornets is the constrainedprocessing-power and energy-budget of existing sensor plat-forms. This prevents many interesting candidate applications,whose software implementations are prohibitively slow andenergy-wise impractical over these platforms. On the otherhand, in the hardware community, it is well-known that thespecialized hardware implementation of demanding sensortasks can outperform equivalent software implementations byorders of magnitude. In addition, recent advances in low-powerprogrammable hardware chips (Field-Programmable Gate Ar-rays) have made flexible and efficient hardware implementa-tions achievable for sensor node architectures [4]. Hence, thejoint software-hardware design of a sensornet application is avery appealing approach to support sensornets.

Unfortunately, joint software-hardware designs of sensornet

applications remain largely unexplored since there is no effec-tive simulation tool for these designs. Due to the distributednature of sensornets, simulators are necessary tools to helpsensornet researchers develop and analyze new designs. Devel-oping hardware-software co-designed sensornet applicationswould have been an extremely difficult job without the helpof a good simulation and analysis instrument. While a greateffort has been invested in developing sensornet simulators,these existing sensornet simulators, such as TOSSIM [1],ATEMU [5], and Avrora [6] focus on evaluating the designsof communication protocols and application software. Theyall assume a fixed hardware platform and their inflexiblemodels of hardware cannot accurately capture the impact ofalternative hardware designs on the performance of networkapplications. As a result, sensornet researchers cannot easilyconfigure and evaluate various joint software-hardware designsand are forced to fit into the constraints of existing fixedsensor hardware platforms. This lack of simulator support alsomakes it difficult for the sensornet research community todevelop a clear direction on improving the sensor hardwareplatforms. The performance/energy benefits that are availableto the hardware community therefore remain hard to reach.

To address this critical problem, we developed a new sensor-net simulator, named SUNSHINE1 (Sensor Unified aNalyzerfor Software and Hardware in Networked Environments), tosupport hardware-software co-design in sensornets. By theintegration of a network simulator TOSSIM, an instruction-set simulator SimulAVR, and a hardware simulator GEZEL,SUNSHINE can simulate the impact of various hardwaredesigns on sensornets at cycle-level accuracy. The performanceof software network protocols and applications under realistichardware constraints and network settings can be captured bySUNSHINE.

The rest of the paper is organized as follows. Section II pro-vides a description of SUNSHINE’s architecture. Section IIIdiscusses cross-domain techniques used in SUNSHINE. Sec-tion IV describes SUNSHINE’s hardware simulation support.Section V provides experiment results and evaluation of SUN-SHINE. Section VI introduces some related network simula-tors and makes comparisons between SUNSHINE and other

1SUNSHINE is an open source software, the code is keeping updated andcan be checked at http://sunshine-sim.sourceforge.net.

2

sensornet simulators. Section VII discusses future work ofSUNSHINE. Finally, Section VIII provides some conclusions.

II. SYSTEM DESCRIPTION

SUNSHINE combines three existing simulators: networkdomain simulator TOSSIM [1], software domain simulatorSimulAVR [2], and hardware domain simulator GEZEL [3]. Inthe following, we first briefly introduce these three simulators.Then, we introduce SUNSHINE’s system architecture and itssimulation process.

A. System Components

1) TOSSIM: TOSSIM [1] is an event-based simulator forTinyOS-based wireless sensor networks. TinyOS is a sensornetwork operating system that runs on sensor motes. TOSSIMis able to simulate a complete TinyOS-based sensor networkas well as capture the network behaviors and interactions.TOSSIM provides functional-level abstract implementationsof both software and hardware modules for several exist-ing sensor node architectures, such as the MICAz mote. InTOSSIM, an event-based network simulator, sensor nodes’behaviors are regarded as functional-level events, which arekept in TOSSIM’s event queue in sequence according to theevents’ timestamps. These events are processed in ascendingorder of their timestamps. When the simulation time arrives atone event’s timestamp, that event is executed by the simulator.

Even though TOSSIM is able to capture the sensor motesbehaviors and interactions, such as packet transmission, recep-tion and packet losses at a high fidelity, it does not consider thesensor motes processors’ execution time. Therefore, TOSSIMcannot capture the fine-grained timing and interrupt propertiesof software code.

2) SimulAVR: SimulAVR [2] is an instruction-set simulatorthat supports software domain simulation for the Atmel AVRfamily of microcontrollers which are popular choices forprocessors in sensor node designs. SimulAVR provides ac-curate timing of software execution and can simulate multipleAVR microcontrollers in one simulation. SimulAVR is alsointegrated into the hardware domain simulator in SUNSHINE,and through this integration, the detailed interactions betweensensor hardware and software can be evaluated. Currently,SimulAVR does not support simulation of sleep mode orwakeup mode of sensor nodes. We have added sleep andwakeup schemes to provide simulation support for energysaving mode of sensor networks.

3) GEZEL: GEZEL [3] is a hardware domain simulatorthat includes a simulation kernel and a hardware descriptionlanguage. In GEZEL, a platform is defined as the combina-tion of a microprocessor connected with one or more otherhardware modules. For example, a platform may include amicroprocessor, a hardware coprocessor, and a radio chip mod-ule. To simulate the operations of such a platform, one has tocombine software simulation domain, which captures softwareexecutions over the microprocessor, and hardware simulationdomain, which captures the behaviors of hardware modulesand their interaction with the microprocessor. GEZEL is able

SimulAVR

peripherals

ncc

RadioChip

Module

Cycle-accurate co-sim node

TOSSIM node

GEZEL & SimulAVR: cycle accurate TOSSIM: event-driven

TinyOS application

Binaries for hardware

mote

SensorNode

HardwareSpecification

GEZEL TOSSIM

Binaries for TOSSIM

simulation

Fig. 1. Software architecture

to provide a hardware-software co-design environment thatseamlessly integrates the hardware and software simulationdomains at cycle-level. GEZEL has been used for hardware-software co-design of crypto-processors [7], cryptographichashing modules [8], and formal verification of security prop-erties of hardware modules [9], etc. GEZEL models can beautomatically translated into a hardware implementation thatenables a user to create his/her hardware, to determine thefunctional correctness of the custom hardware within actualsystem context and to monitor cycle-accurate performancemetrics for the design.

GEZEL is the key technology to enable a user to optimizethe partition between hardware and software, and to optimizethe sensor node’s architecture. With the support of GEZEL,the simulator can capture the software-hardware interactionsand performance at cycle-level in a networked context.

B. System Architecture

SUNSHINE integrates TOSSIM, SimulAVR and GEZELto simulate sensornet in network, software, and hardwaredomains. A user of SUNSHINE can select a subset of sensornodes to be emulated in hardware and software domains.These nodes are called cycle-level hardware-software co-simulated (co-sim) nodes and their cycle-level behaviors areaccurately captured by SimulAVR and GEZEL. Other nodesare simulated in network domain by TOSSIM and only thehigh-level functional behaviors are captured. These nodes arenamed TOSSIM nodes. SUNSHINE is able to run multiple co-sim nodes with TOSSIM nodes in one simulation. The networktopology in the right part of Figure 1 illustrates the basicidea of SUNSHINE. The white nodes are TOSSIM nodes,which are simulated in network domain, while the shadednodes are co-sim nodes, which are emulated in software andhardware domains. When running simulation, these TOSSIMnodes and co-sim nodes interact with each other according tothe network configuration and sensornet applications. Cycle-level co-sim nodes can show details of sensor nodes’ behav-iors, such as hardware behavior, but are relatively slower tosimulate. TOSSIM nodes do not simulate many details ofthe sensor nodes but are simulated much faster. The mixof cycle-level simulation with event-based simulation ensuresthat SUNSHINE can leverage the fidelity of cycle-accuratesimulation, while still benefiting from the scability of event-driven simulation.

3

The simulation process in SUNSHINE is illustrated by Fig-ure 1. Firstly, for co-sim nodes that emulate real sensor motes,executable binaries are compiled from TinyOS applicationsusing nesC compiler (ncc) and executed directly over theseco-sim nodes. This is because co-sim nodes emulate hard-ware platform at cycle level. Therefore, TinyOS executablebinaries can be interpreted by SimulAVR, the AVR simulationcomponent of SUNSHINE, instruction-by-instruction. At thesame time, GEZEL interprets the sensor node’s hardwarearchitecture description, and simulates the AVR microcon-troller’s interactions with other hardware modules at everyclock cycle. One of the hardware modules that GEZELsimulates is the radio chip module. This radio chip moduleprovides an interface to TOSSIM, which models the wirelesscommunication channels. Through these wireless channels,co-sim nodes interact with other sensor nodes, which aresimulated either as co-sim nodes by GEZEL and SimulAVR, oras functional-level nodes by TOSSIM. To maintain the correctcausal relationship, the interactions between TOSSIM nodesand co-sim nodes are based on the timing synchronizationand cross-domain data exchange techniques, which will beintroduced in the following sections.

III. CROSS-DOMAIN INTERFACE

In this section, we will discuss how we interface thethree components of SUNSHINE, each working in a differentdomain of simulation.

A. Integrate SimulAVR with GEZEL

GEZEL is able to provide co-simulation interfaces withARM cores, 8051 microcontrollers, and PicoBlaze processorcores, to form a hardware-software emulator.

In SUNSHINE, in order to let the simulated AVR micro-controller exchange data with the simulated hardware mod-ules, GEZEL creates cycle accurate hardware-software co-simulation interfaces according to the AVR microcontroller’sdatasheet [10]. Once these interfaces are established, datacan be changed between GEZEL-simulated hardware entitiesand SimulAVR-simulated microcontroller. The details of theco-simulation interfaces can be found in GEZEL’s docu-mentation [11]. With the support of GEZEL’s co-simulationinterfaces, SUNSHINE is able to form an emulator to capturethe sensor nodes’ hardware-software interactions and per-formance. In the following, we call this resulting emulatoras P-sim, which combines the software domain simulatorSimulAVR and the hardware domain simulator GEZEL.

B. Timing Synchronization

SUNSHINE integrates network simulator TOSSIM andhardware-software emulator P-sim for the purpose of scal-ability. However, simulations in these three domains run atdifferent step sizes. Without proper synchronization, we caneasily get mismatches in simulation time between event-drivensimulation and cycle-level simulation as shown by Figure 2.The wall clock time is the time required by the simulatorto complete a simulation, i.e., the simulator’s run time. The

Wall clock time

Sim

ula

tio

n t

ime

Event in network domain simulation

Time in cycle-level simulation

Time in event-level simulation

Infidelity caused by time difference

Execution time for processing

an event

Execution time for simulating a cycle

Fig. 2. Simulation time in dif-ferent domains

Event in network domain simulation

Time in cycle-level simulation

Time in event-level simulation

Switching from cycle-level simulation domain to network simulation

domain

Wall clock time

Sim

ula

tio

n t

ime Switching from

network domain simulation to cycle-level simulation

domainNode sleeping eventNode wakeup event

Fig. 3. The synchronized simu-lation time in SUNSHINE

simulation time is the simulator’s prediction of the executiontime of a sensornet application based on the simulation of thesensornet. As shown in Figure 2, P-sim runs at cycle-levelsteps, where each simulation step captures the behaviors of anAVR microcontroller or a hardware component at one clockcycle. Therefore, the simulation time is gradually increasing.However, in TOSSIM, a discrete event simulator, each simu-lation step captures the occurrence and handling of a networkevent. As the time durations between events are irregular,the simulation time in TOSSIM also increases at irregularsteps. This difference in simulation time may cause potentialviolations in causal relationship among different sensor nodesin simulation.

To solve this issue, SUNSHINE includes a time synchro-nization scheme as depicted in Figure 4. In the design,TOSSIM uses the Event Scheduler to handle all the networkevents while P-sim uses the Cycle-level Simulation Engineto control the simulation of hardware modules and the AVRmicrocontroller every clock cycle. All network events are inthe Event Queue and are sorted according to their timestampsthat record their occurrence time. The Event Scheduler pro-cesses the head-of-line (HOL) event in the Event Queue onlywhen the Cycle-level Simulation Engine has progressed to theevent’s timestamp. By selecting either an event or a cycle-levelsimulation to be simulated next, SUNSHINE will maintain thecorrect causality between different simulation schemes in thewhole network.

Active Node ListNode 4

Node 5

Node 25

Node 8

Event Scheduler

Cycle-level Simulation

Engine

Event Queue

pop HOL event

proceed to the next cycle

run next cycle∀∀∀

time for executing the next cycle (t2)

timestamp of the head-of-line event (t1)

t1 < t2Yes No

∀∀∀

run next event

∀∀∀

Fig. 4. Synchronization Scheme

The design in Figure 4 also provides synchronization sup-ports for co-sim nodes in sleep mode by maintaining an ActiveNode List. This list holds the active nodes that need to besimulated with cycle-level accuracy. The Event Scheduler addsor removes nodes from the list upon node wakeup or nodesleep events. At each cycle-level simulation step, the Cycle-level Simulation Engine only processes a clock cycle for the

4

nodes of the Active Node List. As a result, a node’s sleep orwakeup state does not need to be checked every clock cycle.Given the fact that in sensornets, a sensor node spends mostof its time in sleep mode, this design will greatly accelerateSUNSHINE’s simulation speed.

Based on the synchronization scheme, the desired behaviorof a synchronized simulation can be achieved as shown inFigure 3. Events in the network domain are processed withthe correct causal order compared to the cycle-level simulation,and the SUNSHINE simulator correctly interleaves cycle-levelprocessing with event-driven processing.

C. Cross-Domain Data Exchange

Since SUNSHINE integrates simulation engines working inthree different domains, it is necessary to implement interfacesfor cross-domain data exchange between these simulators. Thedata exchange between SimulAVR and GEZEL is explained inSection III-A. In this section, we focus on discussing how dataexchanges between hardware-software emulator P-sim withevent-based simulator TOSSIM.

1) Noise Models: A wireless network simulator needs tobuild radio and noise models to simulate wireless packetdelivery. Since SUNSHINE integrates P-sim with networksimulator TOSSIM, it is convenient to adopt TOSSIM’s radiomodel to simulate wireless packet transmission and reception.TOSSIM also uses the closest-fit pattern matching (CPM)noise model [12] to simulate whether the packets can besuccessfully received from the channel.

Since TOSSIM simulates high functional level network be-havior, if there is a collision of the packets in the channel (i.e.,two nodes send packets to the third node at the same time),TOSSIM simply assumes that the packets are corrupted anddrops the packets. This is different from the real radio chip. Inreality, the radio chip performs Frame Check Sequence (FCS)scheme to check whether the packet is received correctly andmarks its CRC bit accordingly [13].

To simulate the radio chip’s real performance in SUN-SHINE, the CPM model is modified by adding a receiveFIFO (RXFIFO) to the radio chip module to store the receivedpackets. In the simulation, when the CPM model determinesa node successfully receives a packet, the received packet isstored in the RXFIFO with CRC bit set to 1 to demonstrate thepacket is received successfully without error. However, if theCPM model determines a node receives a corrupted packet,the RXFIFO stores the received data with CRC bit set to 0 tomention that the data is not received correctly. This process isin accordance with the real radio chip’s behavior [14].

2) Event Converter: Sensor nodes in network domain sim-ulated by TOSSIM need to exchange messages with nodesin software-hardware domain simulated by P-sim through theTOSSIM simulated channel. However, network domain simu-lation and hardware-software domain emulation have differentsimulation abstractions. For TOSSIM, it abstracts the functionsand interactions among network components as high-levelabstracted events. For example, as shown in Figure 5, thetransmission or reception of an entire packet is regarded as a

single event in TOSSIM. In hardware-software domain emu-lation, the packet transmission and reception related functionsand interactions among hardware modules are simulated asseries of behaviors in many cycles. For example, to simulatethe reception of a packet, the bits received and read from theradio chip module should be simulated at each clock cycle.Therefore, a time converter is needed to bridge this gap intime granularity.

Event arrival time

Detailed simulation

time

Time converter

TOSSIM P-sim

Packet converter

Packet transmission/

reception event

Bits transmitted/received by the radio chip each

clock cycle

Event converter

Fig. 5. Converting a functional-level event to cycle-level events

Another issue is the message format defined in TOSSIM isdifferent from the message format in the real mote according tothe radio chip’s datasheet [3]. Therefore, a package converter isbuilt to facilitate the conversion of packets between TOSSIMand P-sim.

Figure 6 illustrates the event conversion process. If a co-simnode transmits a data packet, it should follow several steps insimulation. The simulated AVR microcontroller first sends thepacket to the radio chip module at cycle level. The radio chipmodule stores the packet in a transmit FIFO (TXFIFO). Assoon as the radio chip module receives a send command fromthe simulated microcontroller, the time converter transformsP-sim’s simulation time to TOSSIM’s simulation time, whilethe packet converter changes the real mote’s packet format toTOSSIM’s packet format, and sends the packet to the TOSSIMsimulated channel. Based on this scheme, both TOSSIM nodesand co-sim nodes in the receiver side are able to receive thepackets from the sender.

TOSSIM Radio Chip Module

Simulated AVR microcontroller

event queue

RXFIFO

registersCycle

Accurate(1 bit/cycle)

TXFIFO

Packet transmis-sion event

Packet reception

event

Packetconverter

Timeconverter

Event Converter

Fig. 6. Event conversion process

If an event that indicates a co-sim node to receive a packetfrom the TOSSIM simulated channel is fired from the EventQueue, the packet converter modifies the abstract TOSSIMpacket to the real bytes of the packet, and puts these bytes intothe RXFIFO of the radio chip module. In addition, the timeconverter converts TOSSIM’s current event time to severaldetailed simulation time, such as the start of frame delimiter(SFD) time, the length field time, etc, on the basis of the radiochip’s datasheet [14]. These timing information are provided

5

for the simulated AVR microcontroller to read data from theRXFIFO according to the datasheet [14].

Using the event converter, SUNSHINE is able to convertcoarse packet communication events to the cycle-level packetreception and transmission behaviors and vice versa. Based onthis mechanism, SUNSHINE satisfies both P-sim’s cycle-leveland TOSSIM’s event-level requirements.

IV. HARDWARE SIMULATION SUPPORT

As SUNSHINE is able to simulate hardware behavior, inthis section, we discuss SUNSHINE’s support for hardwaresimulation.

A. Hardware Specification Scheme

One of the primary contributions of SUNSHINE is tosupport hardware flexibility and extensibility. SUNSHINEdescribes sensor motes hardware architecture at simulation’sconfiguration level using GEZEL-based hardware specificationfiles. Users of SUNSHINE can make various modifications tosensor motes architecture, such as using different microcon-trollers, adopting multiple microcontrollers, adding hardwarecoprocessors, connecting with new peripherals and performingother customizations on the platform. The syntax of a validhardware specification file based on GEZEL is relativelysimple. Users are able to write their own specification filesaccording to GEZEL semantics [15].

To demonstrate this point, Figure 7 shows specific details ofhow hardware architecture of a MICAz mote is described inSUNSHINE. We listed a snippet of the hardware specificationfile in Figure 7. The file is divided into three pieces, eachof which is dedicated to a relevant hardware part. From thecode snippet, we would see that users could pick hardwarecomponents using “iptype” statements to configure a sensornode’s hardware platform. In this specific example, micro-controller Atmega128L and radio chip CC2420 are chosento form the MICAz hardware platform. The components’corresponding ports are interconnected through virtual wiresthat are also described in the specification file. For example,“Atm128sinkpin” wires the input pin B3 of the AVR micro-controller’s core to the output pin MISO of the CC2420 chip,while “Atm128sourcepin” wires the output pin B0 of the AVRmicrocontroller’s core to the SS input pin of the CC2420 chip.While our example shows the MICAz platform, a user can alsopick other components to form a different hardware platform intheir sensornet simulation. For example, one can use ARM or8051 microcontroller instead of Atmega128L by modifying thehardware specification file. Based on this mechanism, SUN-SHINE can easily combine different hardware components toform different hardware platforms for sensornet simulation. Inother words, SUNSHINE supports running network simulationover flexible hardware platforms that are created based oneither commercial off-the-shelf sensor boards or the user’scustomized platform designs.

The example in Figure 7 also shows how SUNSHINEenables different co-sim nodes to run different software appli-cations through the use of “ipparm” statements. The “ipparm”

can also be used to set parameters for hardware components.In Figure 7, the statement ipparm “exec = app” means thesimulated AVR microcontroller would interpret the executablebinary named ”app”, which is compiled from a softwareapplication using ncc compiler. Users can also configure thesimulated AVR microcontroller to execute other binaries ina co-sim node through ipparm statements. By configuringdifferent co-sim nodes to execute different software binaries,SUNSHINE can simulate a sensornet that has multiple dif-ferent applications. This is a significant improvement overTOSSIM, which can only run one application in a wholenetwork. Essentially, SUNSHINE’s simulation configurationsteps are as follows. First, the executable binaries of applica-tions are compiled from their source codes. Then, as shown inFigure 7, a Hardware Specification file is created to describehow hardware components form the hardware platforms inthe sensornet. The Hardware Specification file also links thegenerated executable binaries to the corresponding hardwareplatforms. After the configuration, SUNSHINE simulation canstart.

ATmega128L

B7E6D6D4B0B1B2B3

A2

A1

A0

CC2420

FIFOFIFOPCCASFDSS

SCKMOSIMISO

LED0

LED2

LED1

ipblock avr{iptype ``atm128core '’; ipparm``exec=app'’;}

ipblock m_miso (out data: ns(1)){ iptype ``atm128sinkpin '’; ipparm ``core=avr '’; ipparm ``pin=B3 '’;}ipblock m_ss (out data : ns(1)) { iptype "atm128sourcepin"; ipparm "core=avr"; ipparm "pin=B0"; }

ipblock m_cc2420 (out fifo,fifop,cca,sfd:ns(1); in ss,sck, mosi:ns(1); out miso:ns(1)){ iptype``ipblockcc2420'’;}

HardwareSpecification

file

TinyOS executable binary named ``app '’

Fig. 7. Hardware specification for a single node. Multiple nodes can becaptured by instantiating multiple AVR microcontrollers and multiple radiochip modules.

From the above description, one would see that SUNSHINEcan be used to simulate various hardware platform designs tofind the most suitable hardware module for a given networkenvironment and a given set of application requirements.Therefore, SUNSHINE is an efficient tool to help hardwaredesigners develop better sensor motes. In addition, researchersin the field of software can also use SUNSHINE to easilyconfigure novel hardware architectures and then evaluate theirsensornet applications and protocols over these customizedarchitectures. Because SUNSHINE can change hardware com-ponents easily at simulation’s configuration level, even soft-ware researchers with little hardware knowledge can configuresensornet hardware platforms themselves.

B. Hardware Behavior

Unlike other sensornet simulators, SUNSHINE is able toaccurately capture sensor nodes’ hardware behaviors. Usersare able to know whether the microcontroller is in sleep mode

6

or active mode as well as identify the radio chip’s currentradio control state. In addition, through interpreting GEZELcode, a hardware description language, SUNSHINE is ableto display cycle-level behavior of hardware components whenapplications are running on co-sim nodes. This would helphardware designers know how hardware module behaves insensornet applications.

Fig. 8. Traces for TinyOS Reception application

For example, users can track hardware pins’ activities whenrunning a sensornet application on a co-sim node in SUN-SHINE by doing the following. The signal tracing mechanismof SUNSHINE records stimuli files when the simulation isset in debug mode. These stimuli files, named Value-ChangeDump (VCD) files, can be read by digital waveform viewingtools, such as GTKWave, to produce graphic illustrations ofhardware pins’ values. An experiment is provided to showSUNSHINE’s capability of capturing the sensor nodes’ hard-ware performance. In the experiment, a TinyOS TxThroughputapplication runs on one co-sim node and the Reception ap-plication runs on the other co-sim node. In the TxThroughputapplication, the sensor node keeps sending packets to the radiochannel using the largest message payload size. In the Recep-tion application, the node listens to the channel and receivespackets from the channel. Figure 8 shows the hardware pins’detailed activities of the receiving node. Through these traces,users are able to detect how the AVR microcontroller interactswith the CC2420 radio chip.

V. EVALUATION OF SUNSHINE

We performed the experiments on a Dell laptop that has Intel(R) Core (TM) 2 Duo CPU T5750 @ 2.00GHz, 3G RAM andruns Linux 2.6.32-23-generic. SUNSHINE integrates TinyOSversion 2.1.1, SimulAVR and GEZEL version 2.5. We used thelatest version of the simulators available at the time of per-forming the experiments. The hardware platform configuredin these simulations is MICAz.

A. Scability

In the following, we simulated several applications to ana-lyze SUNSHINE’s scability. In the first application, we variedthe number of nodes that are randomly distributed in a fixedarea from 2 to 128. Nodes are paired to communicate witheach other. We wrote an application to let the paired nodessend packets between each other. The simulation ends whenall of the nodes receive one message from its neighbor. Weconsidered four cases: the first case is pure co-sim nodes

network, the second one is pure TOSSIM nodes network,the third is the combination of 50% co-sim nodes with 50%TOSSIM nodes network, and the fourth is 25% co-sim nodeswith 75% TOSSIM nodes network.

Figure 9 shows SUNSHINE’s wall clock time which repre-sents the time required by SUNSHINE to complete the sim-ulation. As expected, pure TOSSIM simulation outperformsSUNSHINE in terms of simulation speed by abstracting awaythe detailed behaviors of sensor nodes, such as hardware clockcycles and microprocessor’s instructions. On the other hand,SUNSHINE’s low execution speed comes from its fine-grainedsimulation accuracy. However, Figure 9 shows that SUN-SHINE has the ability of simulating hybrid network consistsof co-sim nodes and TOSSIM nodes. When simulating themixed network, SUNSHINE’s execution speed is acceleratedand hence can be suitable for even large networks.

Figure 10 shows the memory utilization of the simulation.The simulation with 100% co-sim nodes utilizes large CPUmemory because cycle-level simulation needs to cache a lotof co-sim nodes’ data and states from GEZEL, simulAVR andTOSSIM. These data and states can take a large amount ofmemory space when simulating a large network. To reducethe memory consumption, SUNSHINE can combine TOSSIMnodes with co-sim nodes to decrease the memory utilization.

Given these information, combining co-sim nodes withTOSSIM nodes becomes an advantage of both speeding up thesimulator’s run time and decreasing memory usage. Also, thiscombination is acceptable since in most network scenarios,only important nodes need to be simulated at cycle-levelfine granularity (i.e. simulated as co-sim nodes) to evaluatetheir hardware and software performance. Other nodes, whosedetailed behaviors are not important, can be simulated inTOSSIM. Several specific examples are given as follows.

1) Ring Network: We simulated a packet relaying appli-cation based on a 320 nodes’ ring network. In the packetrelaying application, the first node sends a packet with twobytes payload length to the next hop. As soon as the secondnode receives the packet from the previous one, it forwards thesame packet to the next node. The application ends when thefirst node receives the two bytes packet from its previous node.In this case, most of the sensor nodes have the same behaviors(e.g. receiving and forwarding the data to another node). Sinceco-sim nodes are used to analyze sensor nodes’ cycle levelsoftware-hardware performance, only simulating a few co-simnodes are sufficient to analyze the network behavior. In thisexperiment, we used 5% co-sim nodes and 95% TOSSIMnodes to consist the network. We randomly chose co-simnodes’ positions in order to show the interconnection betweenTOSSIM and co-sim nodes. We simulated the application tentimes with different co-sim nodes’ positions and calculatedthe average of the simulator’s run time. In the experiment,simulating 320 nodes only takes 217.35s. Using ring networkavoids packets collisions in the channel. Dense networksare deployed to illustrate SUNSHINE’s performance in thefollowing experiments.

7

0 20 40 60 80 100 1200

10

20

30

40

50

number of nodes

wal

l clo

ck ti

me

(s)

100% co−sim nodes50% co−sim nodes25% co−sim node100% TOSSIM nodes

Fig. 9. Scability

0 20 40 60 80 100 1200

2

4

6

8

10

12

14x 10

7

number of nodes

mem

ory

utili

zatio

n (k

iloby

tes)

100% co−sim nodes50% co−sim nodes25% co−sim nodes100% TOSSIM nodes

Fig. 10. Memory Utilization

0 1 2 3 4

x 105

−0.5

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

computation intensity (loops)

time

(s)

SUNSHINEreal moteTOSSIM

Fig. 11. Validation Results

2) Star Network: A nine nodes’ star network is simulated inSUNSHINE. The network topology is shown in Figure 12(a),which includes one base station placed at the center, thatreceives data from other nodes, and eight normal sensors,that take turns to send one packet to the base station. Thesimulation ends when the base station receives all the leafnodes’ packets. In this application, to analyze fined-grainednetwork behavior, we only need to simulate the base stationand one leaf node as co-sim nodes, while other leaf nodes canbe set to TOSSIM nodes. SUNSHINE finishes simulation in3.71s using two co-sim nodes, compared to 19.75s run timeusing all (nine in this case) co-sim nodes.

3) Tree Network: A three-layered tree network is consid-ered as shown in Figure 12(b). Nodes 1 to 12 send packets totheir parent nodes, 13 to 15, respectively. After receiving thepackets from all their children nodes, nodes 13 to node 15 firstperform several computational tasks (e.g. compressing the datareceived from its children nodes) and then send the packetsto the root node 16. As soon as node 16 receives the packetsfrom nodes 13 to 15, simulation ends. Since in a real sensornetwork, the bottleneck node is highly likely to be node 16, toinvestigate the bottleneck node’s behavior under heavy load,it is reasonable to simulate the root node 16 as co-sim node.In addition, several nodes that perform computational tasksand can become overloaded, such as nodes 13 to 15, can alsobe considered as co-sim nodes. In this experiment, simulatingfour co-sim nodes (nodes 13 to 16) with 12 TOSSIM nodes(nodes 1 to 12) takes 159.00s. However, using the root node16 as co-sim node while others (nodes 1 to 15) are TOSSIMnodes only takes 24.64s.

According to the above experiments, we can draw a con-clusion that SUNSHINE is able to capture sensor nodes’cycle accurate hardware-software performance while keep thesimulator’s execution speed fast by mixing co-sim nodes with

6

57

8

9

2

3

41

(a) Star Network

16

1 432

13

5 876

14

9 121110

15

(b) Tree Network

Fig. 12. Network Topology

TOSSIM nodes in the network simulation. Therefore, usersshould choose important nodes as co-sim nodes running atcycle level, while other nodes as TOSSIM nodes to ensureSUNSHINE’s simulation can scale to large networks.

B. Simulation Fidelity

In this section, we conducted two real-mote experimentson Crossbow MICAz OEM reference boards to show thesimulation fidelity of SUNSHINE. Each result is the averagevalue of ten experiment runs.

(a) (b)

Fig. 13. Testbed

In the first experiment as shown in Figure 13(a), wedeployed a five node sensor network to analyze SUN-SHINE’s channel performance. Since SUNSHINE utilizes theTOSSIM’s radio and noise models which have been validatedin [1], [12], in this experiment, it is sufficient to consider asimple ring network topology with a focus on packet relayingapplications (that are introduced in Section V-A1).

As measured in real motes, the average network throughputis 1568.6 b/s, which is close to that of using SUNSHINE, i.e.,1699.3 b/s (both values are measured without ack). As canbe inferred from the results, SUNSHINE is able to providefairly reliable results as reference for the sensor networkapplications.

In the second experiment, we evaluated SUNSHINE’s ca-pability of executing computational tasks. On the testbed asshown in Figure 13(b), we ran the TinyOS TxThroughputapplication (mentioned in Section IV-B). The sensor nodeexecutes a dummy computational task of multiple emptyloops before sending packets to other nodes, and we variedthe number of empty loops to represent various levels of

8

computation intensity. We compared SUNSHINE, TOSSIMand the real mote in terms of the task execution time insimulation/experiment, and the results are shown in Figure 11.

From the results, we are able to observe that (1) TOSSIMruns fastest as expected, and its predicted task executiontime is much less than the real task execution time; and (2)SUNSHINE is able to provide a simulated task executiontime that coincides with that of the real mote experiment.TOSSIM’s fast simulation speed is attributed to its inability ofcapturing the task execution time on the microcontroller, whichwill apparently limit its applicability time-sensitive applica-tions/protocols. Many security protocols, such as the distance-bounding protocol [16], require precise time-out behaviorto thwart physical man-in-the-middle attacks. When testingand verifying these protocols, SUNSHINE will out-competeTOSSIM since SUNSHINE is able to correctly capture theimpact of computation intensity on sensornet performance.

VI. COMPARISONS OF SUNSHINE WITH EXISTINGSIMULATORS

Due to the difficulties in setting up sensor network testbeds,sensornet researchers prefer to simulate and validate their ap-plications and protocols before experimenting in real networks.This makes sensornet simulators an important tool in sensornetresearch. A number of wireless network simulators have beenproposed including TOSSIM [1], ATEMU [5], Avrora [6], andNS-2 [17] to name a few. In this section, we made severalcomparisons between SUNSHINE and other existing networksimulators.

A. Existing event-based network simulatorsNS-2 [17] is the classical network simulation framework

that is used in the context of wired and wireless networks. NS-2 is a discrete event-based simulator that simulates networksat packet level. It is widely used in wireless network area toevaluate lower layer communication algorithms. Even thoughNS-2 is a useful network simulation framework, it is notsuitable for wireless sensor networks for several reasons.

Firstly, NS-2 lacks an appropriate radio module that fits forsensor networks. In addition, NS-2 is focused on evaluatingnetwork protocols using general models, such as routingmodel, mobility model and MAC layer model, etc. It fails tomodel application behaviors which can have a greater impacton sensor’s performance and life estimation.

Similar to NS-2, TOSSIM is also an event-based networksimulator. TOSSIM is a widely used simulator in sensornetresearch community due to its higher scalability and moreaccurate representation of sensornet compared to NS-2 [1].However, TOSSIM simulates wireless nodes at functional leveland does not provide enough details at cycle-level. Therefore,TOSSIM cannot capture and compare the performance ofvarious hardware designs and the software implementationsof sensornet applications.

B. Existing cycle-level sensornet simulatorsATEMU [5] and Avrora [6] are the existing sensornet

simulators that venture out of the event-based simulations in

TABLE ICOMPARISON BETWEEN SIMULATORS

XXXXXXXXAspectName TOSSIM Avrora/ATEMU SUNSHINE

HW Flexibility No No Yes& ExtensibilityUser-defined No No Yes

Platform ArchitectureUser-defined Yes Yes YesApplication

User-defined Yes Yes YesNetwork Topology

Applications 1 ≥ 1 ≥ 1Cycle Accuracy No Yes Yes

Transition betweenevent-based and No No Yes

cycle-accurate simulator

network domain. They provide cycle-accurate software domainsimulation to evaluate the fine-grained behaviors of softwareover AVR microcontrollers of MICA2 sensor nodes.

Though ATEMU and Avrora are cycle-level sensornet sim-ulators, they can only simulate MICA2 sensor motes. Theycannot accurately capture the impact of alternative hardwaredesigns on the performance of sensornet applications. In otherwords, they do not support flexibility and extensibility inhardware beyond very simple parameter settings.

C. SUNSHINE

SUNSHINE provides hardware flexibility where a user canmake changes in hardware design of sensor platforms andverify his/her sensornet application’s feasibility. SUNSHINEis able to simulate different potential hardware architectures.For example, SUNSHINE can simulate a sensor board with anFPGA to handle heavy computational intensive tasks, such asadvanced data packets encryption/decryption and data packetscompression. This provides a new direction to sensornet designand enables network researchers to evaluate their designsunder different hardware platforms. SUNSHINE provides avaluable instrument to both sensornet community and hard-ware development community.

Further, each existing simulator can only work in onedomain. For example, NS2 and TOSSIM only work in event-based network simulation domain while ATEMU and Avroracan only execute cycle-accurate simulations. Different fromthese existing simulators, SUNSHINE offers its user flexiblemiddle ground between cycle-accurate and event-based sim-ulations. It can combine a variety of nodes that simulated atcoarse event-level and nodes that are simulated at fine cycle-level.

Table I summarizes the differences between TOSSIM,Avrora, ATEMU and SUNSHINE. As shown in Table I,hardware flexibility is one of the most significant advantages ofSUNSHINE. Also, SUNSHINE’s ability of capturing hardwarebehavior is another improvement for sensornet simulators.

VII. FUTURE WORK

In this paper, we focus on simulating the network, soft-ware and hardware behavior of MICAz mote. Based on the

9

characteristics of GEZEL, different instruction-set simulatorsare able to be connected with GEZEL to emulate the mi-crocontrollers’ hardware and software performance. We havealready interfaced GEZEL with ARM, 8051 microcontroller,etc. GEZEL is also able to connect to other instruction-set simulators, for example, MSPsim [18], an simulator forMSP430, to emulate MSP430 microcontroller’s hardware andsoftware performance. In other words, SUNSHINE would beable to capture other existing sensor motes’ (for example,TelosB) hardware and software behaviors in a networkedcontext.

Currently, the CC2420 radio chip module is built for SUN-SHINE’s simulation. Constructing different radio chip mod-ules, for example, CC1000, is also practicable. Then, MICA2mote (Atmega128L microcontroller with CC1000 radio chip)is able to be emulated using SUNSHINE.

The radio channel and noise model used in SUNSHINEfollows TOSSIM’s scheme. In other words, receiving or drop-ping packets in the radio channel is according to TOSSIM’sdecision. Improving TOSSIM radio and noise models arefeasible. Several works are provided as references [12], [19],[20].

Though SUNSHINE’s slow run time is reasonable, becauseit needs to simulate sensor node’s hardware and softwarebehavior at every clock cycle, it is still possible to increaseSUNSHINE’s execution speed. One way is to change the sim-ulator design from single process to multi-process to leveragemulti-core capability of modern computers.

We are considering transiting SUNSHINE simulation mod-els into real sensor prototypes. To do so, we will create a de-sign flow to map simulations of software and hardware designsto real software and hardware implementations. SUNSHINEsupports simulation reusability since it can map simulations ofsoftware and hardware designs to real software and hardwareimplementations on sensor prototypes. This can reduce the de-velopment time for sensor networks. We consider developing areconfigurable hardware platform based on low-power FPGAsto demonstrate this design flow. This hardware platform canalso serve directly as a novel flexible platform that enablesthe sensor network community to quickly prototype varioussensor architectures.

VIII. CONCLUSION

In this article, we have presented SUNSHINE, a novelsimulator for the design, development and implementation ofwireless sensor network applications. SUNSHINE is realizedby the integration of a network-oriented simulation engine, aninstruction-set simulator and a hardware domain simulationengine. By the seamless integration of the simulators in differ-ent domains, the performance of network protocols and soft-ware applications under realistic hardware constraints and net-work settings can be captured by SUNSHINE with network-event, instruction-level, and cycle-level accuracy. SUNSHINEoutperforms other existing sensornet simulators because it cansupport user-defined sensor platform architecture, which is asignificant improvement for sensornet simulators. SUNSHINE

can also capture hardware behavior which is the unique featureof sensornet simulators. SUNSHINE serves as an efficienttool for both software and hardware researchers to designsensor platform architectures as well as develop sensornetapplications.

ACKNOWLEDGMENT

This work is supported by National Science Foundationaward CCF-0916763. We thank the anonymous reviewers fortheir suggestions on revising the paper.

REFERENCES

[1] P. Levis, N. Lee, M. Welsh, and D. Culler. Tossim: accurate and scalablesimulation of entire tinyos applications. In Computer Communicationsand Networks, International Conference on Embedded networked sensorsystems, pages 126–137, 2003.

[2] Simulavr: an avr simulator. http://www.nongnu.org/simulavr/.[3] P. Schaumont, D. Ching, and I. Verbauwhede. An interactive codesign

environment for domain-specific coprocessors. ACM Transactions onDesign Automation for Embedded Systems, 11(1):70–87, 2006.

[4] S. Ohara, M. Suzuki, S. Saruwatari, and H. Morikawa. A prototype ofa multi-core wireless sensor node for reducing power consumption. InInternational Symposium on Applications and the Internet, July 2008.

[5] J. Polley, D. Blazakis, J. McGee, D. Rusk, and J. Baras. Atemu:a fine-grained sensor network simulator. In Sensor and Ad HocCommunications and Networks, pages 145–152, October 2004.

[6] B. L. Titzer, K. D. Lee, and J. Palsberg. Avrora: Scalable sensor networksimulation with precise timing. In In Proc. of the 4th Intl. Conf. onInformation Processing in Sensor Networks (IPSN), pages 477–482,2005.

[7] P. Schaumont and I. Verbauwhede. A component-based design envi-ronment for electronic system-level design. IEEE Design and Test ofComputers Magazine, special issue on Electronic System-Level Design,2006.

[8] M. Knezzevic, K. Sakiyama, Y. Lee, and I. Verbauwhede. On thehigh-throughput implementation of ripemd-160 hash algorithm. InIn Proceedings of the IEEE International Conference on Application-specific Systems Architectures and Processors (ASAP’ 08), pages 85–90,July 2008.

[9] B. Kopf and D. Basin. An information-theoretic model for adaptiveside-channel attacks. In In CCS ’07: Proceedings of the 14th ACMconference on Computer and communications security, pages 286–296,2007.

[10] ATmega128/L datasheet.http://www.atmel.com/dyn/resources/prod documents/doc2467.pdf.

[11] Gezel library blocks. http://rijndael.ece.vt.edu/gezel2/library.html.[12] H.Lee, A. Cerpa, and P.Levis. Improving wireless simulation through

noise noise modeling. In IPSN ’07: Proceedings of the 6th internationalconference on Information processing in sensor networks, 2007., pages21–30. ACM, 2007.

[13] 802.15.4 standards.http://standards.ieee.org/getieee802/download/802.15.4d-2009.pdf.

[14] Texas instruments cc2420 radio transceiver.http://focus.ti.com/docs/prod/folders/print/cc2420.html.

[15] Gezel language reference. http://rijndael.ece.vt.edu/gezel2/manual.html.[16] S. Capkun and J. P. Hubaux. Secure positioning in wireless networks.

IEEE Journal of Selected Areas in Communications, 24, Feburary 2006.[17] The network simulator-ns-2. http://www.isi.edu/nsnam/ns/.[18] Mspsim-a java-based simulator of msp430 sensor network platforms.

http://www.sics.se/project/mspsim.[19] M. Varshney and R. Bagrodia. Detailed models for sensor network

simulations and their impact on network performance. In 7th ACMMSWiM, pages 70–77, 2004.

[20] J. Zhao and R. Govindan. Understanding packet delivery performancein dense wireless sensor networks. In ACM SenSys, 2003.