MobiCom 2010 Poster: SUNSHINE: A Multi-DomainSensor Network Simulator ∗

Jingyao Zhang Yi Tang Sachin Hirve Srikrishna Iyer Patrick Schaumont Yaling Yang

jingyao@vt.edu yt22@vt.edu hsachin@vt.edu skr@vt.edu schaum@vt.edu yyang8@vt.eduECE Department, Virginia Polytechnic Institute and State University, Blacksburg, VA, U.S.

In this paper, we describe the design and implementation of SUNSHINE, a scalablehardware-software simulator for sensornet applications. SUNSHINE captures the perfor-mance of network protocols, software and hardware up to cycle-level accuracy. SUNSHINEsolves challenging design problems, including data exchanges and time synchronizationacross different simulation domains and simulation accuracy levels. SUNSHINE also pro-vides hardware specification scheme for simulating flexible and customized hardware de-signs. An experiment demonstrates that SUNSHINE is an efficient tool for sensornet proto-typing.

I. Introduction

Existing sensornet simulators, such as TOSSIM [1],ATEMU [4], and Avrora [5] focus on evaluating thedesigns of network protocols and routing algorithms.They assume a fixed hardware platform and their over-simplified models of hardware cannot accurately cap-ture the impact of alternative hardware designs on theperformance of network applications. As a result, sen-sornet researchers cannot easily configure and evalu-ate various joint software-hardware designs and areconstrained for their applications by existing, fixedsensor platforms. This lack of simulator supportmakes it difficult for the sensornet research commu-nity to develop a clear direction on how to improvethe sensor hardware platforms.

To address this problem, we developed a sensornetsimulator, named SUNSHINE (Sensor Unified aNa-lyzer for Software and Hardware in Networked En-vironments), to support hardware-software co-designin sensornets. By the integration of a network simu-lator TOSSIM [1], an instruction-set simulator Sim-ulAVR [2], and a hardware simulator GEZEL [3],SUNSHINE can simulate the impact of various hard-ware designs on sensornets at cycle-level accuracy.The performance of software network protocols andapplications under realistic hardware constraints canbe captured by SUNSHINE.

II. SYSTEM DESCRIPTION

SUNSHINE seamlessly combines three existing sim-ulators: TOSSIM [1], SimulAVR [2], and GEZEL [3].

∗This work is supported by National Science Foundationaward CCF-0916763.

TOSSIM [1] is an event-based network simulatorthat is able to simulate a complete TinyOS sensor net-work with abstract models of network components.SimulAVR [2] is an instruction-set simulator that sim-ulates software executions over Atmel AVR family ofmicrocontrollers. GEZEL [3] is a hardware simulatorthat includes a simulation kernel and a hardware de-scription language for custom hardware development.

Figure 1 shows the sensornet’s design flow usingSUNSHINE. SUNSHINE is composed of a simula-tion kernel and a user interface to configure the net-work. In the configuration step, the users first needto configure the network topology and select a sub-set of nodes (co-sim nodes) to be simulated by Sim-ulAVR and GEZEL at cycle-level accuracy. The otherremaining nodes are simulated by TOSSIM and onlythe high-level functional behaviors of these nodes(TOSSIM nodes) are simulated. For the cycle-levelco-sim nodes, the users should configure the co-simnodes’ software modules and hardware platforms. Af-ter configuration, the users can run simulation. SUN-SHINE emulates the AVR microcontroller, and theTinyOS application executing on top of it, with cycle-level timing accuracy.

After getting satisfactory simulation results, theusers can directly load the binaries executed on cycle-level co-sim nodes to real sensor boards and run theapplication on real testbeds.

III. CROSS-DOMAIN INTERFACE

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

40

Network Configuration

Simulated hardware architecture

Real TinyOS Modules

Real Application Modules

Abstract TinyOS Modules

Real Application Modules

Abstract Hardware Modules

SW & HW domain Simulation (Instruction-set simulator + GEZEL)

Network Domain Simulation (TOSSIM)

Hardware and software

performance

Network performance

Configuration

Simulation

microcontrollerRadiochip

Real Hardware Platforms

Real OS Modules

Real Application Modules

Prototype

Secure application

Digital signature

Key agreement

EncryptionActive message

Radio driver Software ECC code

coprocessor

Microcontroller chip

Radio chip

FPGA

Simulated microcontroller

Simulated FPGA

Simulated radio chip

Node simulated by TOSSIM

Node simulated by SimulAVR and GEZEL at cycle-level accuracy

Code generation

Software Configuration

Hardware Configuration

Figure 1: Network Design Flow using SUNSHINE

III.A. Timing Synchronization

SUNSHINE integrates different domain simulatorsthat run at different step sizes. To synchronize thesesimulators, SUNSHINE includes an efficient algo-rithm as shown in Figure 2.

In this design, TOSSIM uses the Event Schedulerto handle all discrete network events, while GEZELuses the Cycle-level Simulation Engine to control thesimulation of hardware modules and the AVR micro-controller at every clock cycle. All network events arein the Event Queue and are sorted according to theirtimestamps that record their occurrence time. TheEvent Scheduler processes the head-of-line event inthe Event Queue only when the Cycle-level Simula-tion Engine has progressed to the event’s time stamp.By selecting either an event or a clock cycle to besimulated next, SUNSHINE will maintain the correctcausality between different simulation schemes in thewhole network.

Active Node List

Node 4Node 5Event

Scheduler

Cycle-level Simulation

Engine

Event Queue

pop the head-of-line 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

���

Figure 2: Synchronization Algorithm

III.B. Cross-Domain Data Exchange

Sensor nodes in network domain simulated byTOSSIM need to exchange data with nodes simu-lated in software-hardware domain by GEZEL + Sim-ulAVR through wireless channels. However, net-work domain simulation and hardware-software do-

main simulation have different simulation abstrac-tions. For TOSSIM, it abstracts the functions and in-teractions among network components as high-levelabstract events, while in hardware and software do-main simulation by GEZEL and SimulAVR, the func-tions and interactions among components are simu-lated at much finer granularity. To bridge this gap,SUNSHINE creates an event converter that consistsof packet converter and time converter. Packet con-verter supports packets’ format conversion betweenTOSSIM and GEZEL + SimulAVR. Time converterconverts TOSSIM’s current time to detailed simula-tion time.

Event arrival time

Detailed simulation

time

Time converter

TOSSIM SimulAVR+GEZEL

Packet converter

Packet transmission/

reception event

Bits transmitted/received by the radio chip each

clock cycle

Event converter

Figure 3: Converting a functional-level event to cycle-level events

Using the event converter, SUNSHINE is able toconvert coarse packet communication events to thecycle-level packet reception and transmission behav-iors and vice versa.

IV. HARDWARE SIMULATION SUP-PORT

One of the primary contributions of SUNSHINE is tosupport hardware flexibility and extensibility. SUN-SHINE describes sensor node’s hardware architecturevia GEZEL-based hardware specification files. Usersof SUNSHINE can program the specification file to

41

make arbitrary modifications to a sensor node’s plat-form architecture, such as using different microcon-trollers, adopting multiple microcontrollers, addinghardware coprocessors and connecting with new pe-ripherals, etc. The syntax of a valid hardware specifi-cation file based on GEZEL is straightforward. Userscan write their own specification files according toGEZEL semantics [3].

In addition, users can track co-sim nodes’ hardwarepins’ activities in SUNSHINE. To be specific, the sig-nal tracing mechanism of SUNSHINE records stimulifiles when the simulation is set in debug mode. Thesestimuli files (Value-Change Dump (VCD) files) canbe read by digital waveform viewing tools, such asGTKWave, to produce graphic illustrations of hard-ware pins’ values. As an example, Figure 4 shows apart of hardware interactions of sensor board’s com-ponents (AVR microcontroller and the CC2420 radiochip) when the sensor node is in the reception mode.As it can be seen, very detailed activities of hardwarepins are captured by SUNSHINE.

Figure 4: Traces for TinyOS Reception application

V. AN EXPERIMENT

To demonstrate the capabilities of SUNSHINE, weconfigure an 8 nodes’ ring network as shown in Fig-ure 5 to run the packet relay application. Each nodereceiving the packet from the previous hop first per-forms a computation intensive task and then sends thepacket to the next hop. We first use TOSSIM to runthe application and then adopt 8 co-sim nodes to runthe same application in SUNSHINE. We varied thelevel of computation intensity in terms of the numberof loops used in the intensive computation. When run-ning the simulation, we record the prediction of theapplication’s real execution time for a packet trans-mitting around a circle. This estimated time is repre-sented by “simulated time”.

8 7 6 5

4321

-10dB -10dB -10dB

-10dB -10dB

-10dB-10dB-10dB

Figure 5: Simulation configurations.

As we can see from Figure 6, with the increasingcomputation intensity, SUNSHINE’s simulated timeincreases linearly. While in TOSSIM, the simulatedtime does not change when the computation intensity

of applications increases. This means that TOSSIMdoes not have the ability to capture AVR microcon-troller’s constraints on the execution time of appli-cations. This limits the applicability of TOSSIM totime-sensitive protocols. For example, some securityprotocols, such as distance-bounding protocol, requireprecise time-out behavior to thwart physical man-in-the-middle attacks. SUNSHINE is able to test andverify such protocols since it correctly captures theimpact of computation intensity on sensornet perfor-mance.

Figure 6: Simulated time in terms of computation intensity

VI. CONCLUSION

In this article, we have presented SUNSHINE for thedesign, development and implementation of sensor-net applications. By the integration of different do-main simulators, the performance of network proto-cols and software applications under realistic hard-ware constrains can be captured by SUNSHINE withnetwork-event, instruction-level, and cycle-level ac-curacy. SUNSHINE outperforms other existing sen-sornet simulators because it can support user-definedsensor node platform architecture. SUNSHINE canalso capture hardware behavior which is the uniquefeature of sensornet simulators. SUNSHINE canserve as an efficient tool for sensornet prototyping.

References

[1] P. Levis, N. Lee, M. Welsh, and D. Culler, “Tossim: ac-curate and scalable simulation of entire tinyos applica-tions,” In Proc. of the 1st international conference on Em-bedded networked sensor systems, New York, NY, USA,pp. 126–137, 2003.

[2] T. Roth, “Simulavr: an avr simulator,” http://www.

nongnu.org/simulavr/.[3] P. Schaumont, D. Ching, and I. Verbauwhede, “GEZEL:

Hardware/Software Codesign Environment,” http://

rijndael.ece.vt.edu/gezel2/.[4] J. Polley, D. Blazakis, J. McGee, D. Rusk, and J. Baras,

“Atemu: a fine-grained sensor network simulator,” Sensorand Ad Hoc Communications and Networks. pp. 145–152,Oct. 2004.

[5] B. L. Titzer, K. D. Lee, and J. Palsberg, “Avrora: Scalablesensor network simulation with precise timing,” In Proc.of the 4th Intl. Conf. on Information Processing in SensorNetworks (IPSN), pp. 477–482, 2005.

42