rapid design and evaluation framework for wireless sensor networks · 2009. 7. 21. · tossim and...

Available online at www.sciencedirect.com

Ad Hoc Networks 6 (2008) 909–935

www.elsevier.com/locate/adhoc

Rapid design and evaluation framework forwireless sensor networks

Mauri Kuorilehto a,*, Marko Hannikainen b, Timo D. Hamalainen b

a Nokia Technology Platforms, Visiokatu 3, FIN 33720, Tampere, Finlandb Tampere University of Technology, Institute of Digital and Computer Systems, Korkeakoulunkatu 1, FIN 33720, Tampere, Finland

Received 29 October 2004; received in revised form 12 July 2006; accepted 21 August 2007Available online 11 September 2007

Abstract

The diversity of applications and typically scarce node resources set very tight constraints to Wireless Sensor Networks(WSN). It is not possible to fulfill all requirements with a general purpose WSN, for which reason the rapid development ofapplication specific WSNs is preferred. We present a new framework called WIreless SEnsor NEtwork Simulator (WISE-NES) for the design, simulation, and evaluation of WSNs. The target WSN is designed in Specification and DescriptionLanguage (SDL), simulated in WISENES, and implemented on target platform either through automatic code generationor manually. The high-level WSN model is back-annotated with the measured values from a real platform. In this way,very accurate WSN simulations can be performed with a rapid design cycle. WISENES itself has been verified with TUT-WSN (Tampere University of Technology Wireless Sensor Network) and ZigBee protocols. The MAC protocol of ZigBeewas designed in two weeks from scratch by one designer, which shows the effectiveness of WISENES. For accuracy com-parison, the results show 6.7% difference between the modeled and measured TUTWSN prototype power consumption.WISENES hastens the evaluation of new protocol and application configurations, especially for the large scale andlong-term WSN deployments.� 2007 Elsevier B.V. All rights reserved.

Keywords: Wireless Sensor Network (WSN); Network simulation; Medium access control (MAC); Energy efficiency

1. Introduction

Wireless Sensor Network (WSN) applications arediverse ranging from toys to military systems. Typ-ical challenges for WSN are large scale, constantly

1570-8705/$ - see front matter � 2007 Elsevier B.V. All rights reserved

doi:10.1016/j.adhoc.2007.08.003

* Corresponding author. Tel.: +358 71 800 8000; fax: +358 33115 4561.

E-mail addresses: [email protected] (M. Kuori-lehto), [email protected] (M. Hannikainen), [email protected] (T.D. Hamalainen).

changing network topology, and error prone com-munications, while in WSN nodes processing andstorage capacities, as well as energy resources arelimited. Most often WSNs are demanded to berobust against environmental strains, and able toautonomously recover from error situations. Fur-ther, depending on the applications and the interac-tion with environment, time synchronization andsecurity requirements can be strict [1,2].

Opposite to general expectations, an all-purposeWSN is not a reasonable goal, since it is impossible

.

mailto:[email protected]




910 M. Kuorilehto et al. / Ad Hoc Networks 6 (2008) 909–935

to meet all the real life constraints simultaneously.Instead, WSN protocol layers and their configura-tion parameters must be tailored to meet the specificapplication requirements. However, the designspace is very large and makes the design automationthe most important challenge for real workingWSNs. A designer simply cannot handle all theparameters, functions, and their complicated depen-dencies without a tool support.

Prototyping can be applied to a single node func-tionality and small scale WSN testing. However, pro-totypes are not applicable for verifying the operationof e.g. a thousand-node network during a five yeardeployment. Even moderate sized networks benefitfrom extensive simulations, but the accuracy ofsimulation is very important. According to our expe-riences on real WSNs, the smallest and a minor-look-ing issue might cause severe changes for example inthe network power consumption. Therefore, theaccuracy of the design and performance estimationsis not an option but essential for any real WSN.

Several legacy computer network simulators existfor the testing and modeling of communicationprotocols, but they omit WSN specific aspects. Pro-posed WSN simulators vary in their implementa-tion, scale, and in the accuracy and coverage ofthe modeling of node platforms, protocols, and realworld phenomena. Common features are themodels for dedicated platforms, sensing, and wire-less networking. However, none of the previousWSN simulators offers a complete and seamlessdesign flow from abstract sketching to the realimplementation.

Our WIreless SEnsor NEtwork Simulator(WISENES) framework is the first tool that enablesthe design, simulation, implementation and evalua-tion of WSNs with measured back-annotated infor-mation. WISENES is targeted to the design ofdeployable, real WSN networks. The main differenceto the other proposed frameworks is that there is noneed to carry out a separate high abstraction WSNmodeling project and another development projectfor the actual implementation. Instead, WISENESsupports all phases in the design flow. However, ifpreferred, WISENES can also be used for the plainsimulations like other WSN simulators. In all cases,WISENES eases the assessment of the protocol andapplication interoperability, and the evaluation theirapplicability for different sensor node platforms.

The key benefit of WISENES is that the evalua-tion of protocols, applications, and their differentconfigurations is carried out starting from the

design phase. The framework defines rules andinterfaces for a designer to the protocol stack andapplication implementation. The functionality,type, or composition of the protocols is not limitedby the framework. Sensor nodes, transmission med-ium, and inspected phenomena are modeled sepa-rately in the WISENES framework. The WSNprotocols and applications are implemented in Spec-ification and Description Language (SDL) [3]. Themodels of high abstraction level SDL are compiledto executables used for both simulation and finalimplementation. Unlike in the other WSN simula-tors, target node platforms are not restricted to aspecific pre-defined platform.

WISENES has been tested and its own perfor-mance evaluated with large TUTWSN (TampereUniversity of Technology Wireless Sensor Network)[4] and ZigBee networks [5]. For the evaluation ofWISENES accuracy, real and simulated TUTWSNsare compared. However, the comparison of differentWSNs themselves is not the primary scope of thispaper.

This paper is organized as follows. Section 2 dis-cusses the related work in the area of WSN simula-tion and presents the comparison of WISENES withthe other WSN simulators. WISENES design is pre-sented in Section 3 and Section 4 introduces theWISENES framework. The use of WISENES forTUTWSN and ZigBee protocol implementation ispresented in Section 5. Section 6 gives the evalua-tion of WISENES, and the TUTWSN and ZigBeesimulation results. Finally, conclusions are givenand future work projected.

2. Related work

Legacy computer network simulators, such as ns-2 [6], GloMoSim [7], Qualnet [8], OPNET [9],OMNeT++ [10], Scalable Simulation Framework(SSF) [11], and J-Sim [12] enable the simulation ofwireless network behavior and protocol stack oper-ation but lack accounting for WSN characteristics.This is overcome in the simulators proposed specif-ically for WSNs, which we have categorized tonetworking oriented and sensor node simulators.The networking oriented simulators model thetransmission medium in detail and are more suitablefor the large scale WSN simulations. The sensornode simulators mainly simulate the operation ofa single node but implement a lightweight commu-nication model. Currently, there exist eleven rele-vant proposals for the networking oriented WSN

M. Kuorilehto et al. / Ad Hoc Networks 6 (2008) 909–935 911

simulators and six proposals targeting to the sensornode modeling. These are compared with WISENESin Section 2.3.

2.1. Networking oriented simulators for WSN

Most of the proposed networking oriented simu-lators are based on the legacy computer networksimulators. SensorSim [13] and Naval ResearchLaboratory’s (NRL) sensor network simulator [14]extend ns-2 with general WSN features. sQualnet[15] is built on top of Qualnet and Simulator forWireless Ad-hoc Networks (SWAN) [16] is basedon SSF. SENSIM [17] and simulation template forEYES [18] utilize OmNet++ environment, whileJ-Sim sensor simulator [19] adds WSN features toits parent simulator. VisualSense [20] is an extensionto Ptolemy II [21], Prowler [22] utilizes MATLAB,and H-MAS [23] and SENSE [24] implement cus-tom simulation environments.

The most realistic transmission media and proto-col stacks are available in SensorSim, NRL simula-tor, sQualnet, and J-Sim sensor simulator. While thefirst two rely on the models available in parentsimulators, the last two include also a set of WSNprotocols. VisualSense has several models for trans-mission medium, which vary in their accuracy.SWAN and Prowler include abstracted transmissionmedia and lowest layer protocol models that esti-mate the network operation. SENSIM, EYES simu-lator, H-MAS, and SENSE have error freetransmission medium models, in which the signalpropagation is dependent only on the transmissionrange. Simple protocol stacks are available forSENSIM, H-MAS, and SENSE. In VisualSenseand EYES simulator, the protocol stack is imple-mented by the designer.

A separate sensing channel containing also thesensed targets is used for phenomena modeling inSensorSim, NRL simulator, sQualnet, and J-Simsensor simulator. VisualSense has also a dedicatedchannel for modeling the propagation of differentphenomena. Of the other related simulators, SWANmodels catastrophic plume dispersion, and H-MASgenerates random sensor readings. Prowler, SEN-SIM, EYES simulator, and SENSE do not supportphenomena sensing.

Concerning the node platform capabilities, onlythe power consumption is accounted in the relatedsimulators. SensorSim, sQualnet, SENSE, SEN-SIM, and J-Sim sensor simulator have detailedpower models, which consider battery discharge

rate and relaxation. NRL simulator and EYES sim-ulator use linear battery models, in which the max-imum energy capacity is available independent onthe discharge rate. Prowler and VisualSense esti-mate the power consumption based on activity,whereas in SWAN and H-MAS power consumptionis not taken into account.

The simulated code is applicable directly forhardware platforms in SensorSim, sQualnet, J-simsensor simulator, and partly in VisualSense. In Sen-sorSim, simulated SensorWare applications arecompatible with custom hardware platforms [25].The other three simulators enable the execution ofapplications, and sQualnet also higher layer proto-cols, on Berkeley motes [26] on top of well-knownWSN Operating System (OS) TinyOS [27].

VisualSense uses a graphical notation for thedesign and supports a combination of differentModels of Computation (MoC) of Ptolemy II.Abstracted application scripts can be simulated alsoin Prowler.

2.2. Sensor node simulators

Most of the proposed sensor node simulators aretargeted to TinyOS motes. Complete TinyOS sys-tem can be simulated with TinyOS SIMulator(TOSSIM) [28], ATmel EMUlator (ATEMU) [29],and TinyOS Scalable Simulation Framework(TOSSF). TOSSF itself is an extension to SWAN[30]. SENS [31] supports only TinyOS applicationsimulation. EmSim implements a simulation envi-ronment for custom Em* Linux applications andprotocols [32]. Sensor Network Asynchronous Pro-cessor (SNAP) [33] is a hardware emulator, whichconnects several processors on a Network-on-Chip(NoC).

The TOSSIM transmission medium model isdirected graphs with individual bit error rates,whereas in ATEMU and EmSim the transmissionmedium is error free accounting only the transmis-sion range. TOSSF utilizes a transmission mediummodel from SWAN and in SENS transmission med-ium and networking protocols are combined into asimple model. In SNAP, NoC models the trans-mission medium. Protocol stacks in TOSSIM,ATEMU, and TOSSF are dependent on TinyOSconfiguration. EmSim and SNAP implement simpleprotocols for the system testing.

Phenomena sensing is modeled in TOSSF by theplume dispersion model of SWAN. TOSSIM andEmSim retrieve a sensor reading from an external


source. SENS incorporates a separate environmentmodel that supports sensing and actuating. InSNAP and ATEMU phenomena are not modeled.None of the simulators models power consumption.

The applications from all sensor node simulators,and protocols from other than SENS, can bedirectly mapped to the hardware platforms. How-ever, the platform is restricted to a specific one.

2.3. Comparison of WISENES with related

simulators

The comparison of WISENES and the otherWSN simulators is summarized in Table 1. Thecomparison is based on the public informationavailable about each simulator and the possible par-ent simulator engine. If exact scalability informa-tion is not available, the simulator is assessedaccording to the largest reported simulations.

The scope of input parameterization is vital whencomparing the configurability of simulators to dif-ferent kinds of platforms, protocols, and applica-tions. Also, the availability of Graphical UserInterfaces (GUI) and the type of information outputby the simulator are accounted in the comparison.The possibility to use simulated protocols and appli-cations for the final implementations on physicalplatforms defines the applicability of a simulatoras a complete design and development environment.

The term accurate results denotes a very close cor-respondence of the simulation results to the realworld measurements with physical WSN prototypes.Accurate results in full-scale simulations need tocombine at least realistic models for communica-tions (application, transmission medium, transceiverunit, and low-level communication protocols) andnode platform (energy, memory, peripheral I/O,and computation). The node state changes, periphe-ral activation, and leakage currents contribute to theaccuracy of energy consumption. The memory allo-cation and thread scheduling in simulator depend onthe accuracy of the OS model of the simulator.

As shown in the table, most of the simulators arecapable of simulating WSN scenarios consisting ofthousands of nodes. This is an acceptable limit forthe current WSNs, but in future the capability tosimulate networks with in order of magnitude largerscale is required.

Major differences between the simulators are ininput and output parameterization. Although sen-sor node simulators emulate a single node platformin detail, they do not allow the testing and evalua-

tion of applications and protocols on other typesof sensor nodes. Further, they omit the modelingof node power consumption. From the simulators,WISENES incorporates the most comprehensivemodeling of node platforms, which allows a detaileddescription for virtually any real node platform. Inaddition to power consumption, which is consi-dered also in several other simulators, WISENESaccounts memory and computation capacities.From the related simulators, the possibility to definedifferent platforms is available only in sQualnet,but its modeling is not as detailed as that ofWISENES.

Most of the simulators visualize network topol-ogy and key parameters through GUI. The eventinformation is gathered to trace or log files withvarying level of detail. From the related simulators,ns-2 based simulators output extensive trace files.Compared to the other simulators, WISENES out-puts extensive event and data statistics but in addi-tion also detailed information about the noderesource usage. Further, in WISENES a designercan add own log items e.g. to obtain the values ofa desired parameters during the simulated period.

The simulated code is directly applicable for nodeplatforms in sensor node simulators. In networkingoriented simulators, two approaches are taken forthe final implementation. Either the simulated pro-tocols and applications are converted to executablesfor node platforms, or an existing code library isused for emulating a node in a large scale simula-tion. In the latter, the node implementation alreadyexists, and only the configuration parameters for thefinal implementation are acquired by the simula-tions. WISENES is the only simulator that supportsboth of these. The SDL generated C from WISE-NES with a custom lightweight kernel is also appli-cable for the resource constrained sensor nodes [34].

A rapid protocol evaluation for a specific appli-cation is possible only if the simulator protocolstack is modular and its layers interchangeable.Most of the simulators that descend from a legacycomputer network simulator incorporate a modularprotocol stack. In WISENES, the protocol layerscommunicate through pre-defined interfaces, whichallow the replacement of simulated protocols atthe different layers. Graphical design of protocolsand applications is possible only in WISENES andVisualSense. In both simulators the high abstractionlevel designs can also be embedded to node plat-forms. However, WISENES provides significantlymore accurate results compared to VisualSense.

Table 1Comparison of WISENES and existing WSN simulators

Simulator Simulatorengine

Scalability Simulator input Simulator output Finalimplementation

Benefi Deficiencies

WISENES ExtendedtelelogicTAU SDL

�10,000 [34] Nodes, protocols,applications,mediums (XML)

GUI, log files, (data,energy, memory,CPU, errors)

SDL codegeneration/Cmodules directly

Grap design, accurateresult dular,scalab back-annotation

Sensing channel

Networking oriented simulators

SensorSim ns-2 �2000 [17] Power model,protocols (TCL)

ns-2 nam UI, tracefiles (data, energy,errors)

Applications forSensorWare, ns-2protocols

Accur esults, variety ofproto ns-2), modular

No memory and CPUmodeling

sQualnet Qualnet �10,000 Nodes, traffic,protocols (scripts)

Qualnet Visualizer,statistics files (data,energy)

nesC applicationsdirectly

Accur esults,integr to HW,modu calability

No memory and CPUmodeling in simulator

NRLsimulator

ns-2 �2000 [17] Nodes, protocols,sensing (TCL)

ns-2 nam UI, tracefiles (data, energy,errors)

ns-2 protocols Varie protocols (ns-2),modu

No memory and CPUmodeling

SWAN DaSSF �10,000 Nodes, plumedispersion (DML)

GUI, systemprintouts (datacounters, delay)

WiroKit routingprotocol directly

Scala Inaccurate medium model,no node and sensingmodeling, no modularity

SENSIM OmNet++ �5000 Protocols (ini-file(for OmNet++))

OmNet++ GUI(data)

None Modu No sensing, memory, andCPU modeling

EYESsimulator

OmNet++ <1000 Protocols (ini-file(for OmNet++))

OmNet++ GUI(data,errors)

None Modu Inaccurate energy andmedium modeling, nomemory and CPU models

J-Sim sensorsimulator

J-Sim >1000 [35] Protocols (script) Text output, GUIpossible, (data)(1)

Applicationsdirectly

Modu No GUI, no memory andCPU modeling

VisualSense Ptolemy II �100 MoCconfigurations(Ptolemy II)

Ptolemy II GUI(topology, nodeinformation)

Algorithmsintegrated toTinyOS [36]

Grap design, algorithmintegr

No protocol stack, nodesmodeled by power model

Prowler MATLAB <1000 Application (script) GUI (data) None MAT for algorithmtestin

Inaccurate protocol, node,and medium modeling

H-MAS Custom >100 Nodes, protocols(text)

GUI, event files(data)

None Inaccurate protocol andmedium modeling, nomodularity, scalability

SENSE Custom �1000 Topology, traffic(script)

None(2) None Modu No output, inaccuratemedium modeling, no nodeand sensing modeling

(continued on next page)

M.

Ku

orileh

toet

al.

/A

dH

oc

Netw

ork

s6

(2

00

8)

90

9–

93

5913

ts

hicals, moility,

ate rcols (

ate rationlar, sty oflar

bility

lar

lar

lar

hicalation

LABg

lar

Table 1 (continued)

Simulator Simulator engine Scalability Simulator input Simulatoroutput

Finalimplementation

Benefits Deficiencies

Sensor node simulators

TOSSIM Custom �10,000 TinyOS code TinyViz, debug(data, node)

Directly Applicability ofcode for mores

No energymodeling, samecode for all nodes

ATEMU Custom �100 TinyOS codenetwork, nodes(XML)

XATDBdebugger (debugdata)

Directly Applicability ofcode for mores

No sensing andenergy models,scalability

SENS Custom �10,000 Node profiles(text)

GUI, text files(data, energy,errors)

Applicationsdirectly

Scalability Only forapplications, nodeand mediummodels

TOSSF DaSSF (SWAN) �10,000 TinyOS code,SWANparameters

SWAN output(3) Directly Scalability Inaccurate mediummodel, no nodeand sensingmodeling

Em* EmSim Custom <100 Simulation case(script) [37]

Debug traces(node)

Directly Applicabilityof code

Inaccurate mediummodel, no nodeand sensingmodels, scalability

SNAP FPGA Emulator �100(4) Configuration(for FPGA)

FPGA debuginterface (node)

Directly Emulation Inaccurate mediummodel, no sensingmodeling,scalability

(1) J-Sim outputs simulation related data to an ‘‘instrument channel’’, to which user can implement a custom UI.(2) No information about output is given, only results given show simulation times and simulator memory consumption.(3) TOSSF I/O is not specified, but we assumed SWAN I/O due to the relation.(4) SNAP emulators can be connected to increase scalability, but no evaluation is given.

914M

.K

uo

rilehto

eta

l./

Ad

Ho

cN

etwo

rks

6(

20

08

)9

09

–9

35


Generally, the networking oriented simulatorsare more suitable for the network-wide evaluation,whereas the strength of the sensor node simulatorslies in the testing and optimization of a single nodeoperation. From the related simulators, SensorSimand sQualnet implement the most comprehensivesimulation environment. Compared to WISENES,their battery and sensing models are currently moreaccurate. The distinctive features of WISENES arethe complete design flow from the high abstractionlevel graphical models to the final node implementa-tion, the accurate full-scale simulations with config-urable protocol stack and node platform models,and the back-annotation of performance informa-tion from real platforms.

3. Designing WSNs with WISENES

WISENES defines the rules and interfaces for theWSN design and provides a library that containsexisting protocols and a set of implementations forknown functions. A reference WSN protocol stackused in WISENES is depicted in Fig. 1 in correspon-dence to the OSI model [38].

The key layer for WSN topology creation, chan-nel access, and power management is the MediumAccess Control (MAC) protocol. The topology inWSNs is either clustered or flat. In a clustered topol-ogy, nodes are grouped to clusters, in which a cen-tral cluster headnode coordinates the networkingand associated subnodes. In a flat topology allnodes are equal. A routing protocol creates multi-hop paths for the end-to-end communication. Amiddleware layer hides the heterogeneities of under-

Applicationlayer

Transportlayer

Sessionlayer

Presentationlayer

Networklayer

Data linklayer

Physicallayer

OSI stack

Applicationlayer

Middleware

MAC protocol

Transceiver unit

WISENES WSN stack

Applicationlayer

Transportlayer

Sessionlayer

Presentationlayer

Networklayer

Data linklayer

Physicallayer

Applicationlayer

Multi-hoprouting protocol

MAC protocol

Transceiver unit

Fig. 1. WISENES WSN and OSI model protocol stacks.

lying protocol stacks and node platforms fromapplications [1].

The composition of the protocol stack is net-work and application dependent, thus all layersare not mandatory in WISENES. The transceiverunit at the physical layer is part of the WISENESframework and the lowest layer protocol sendsdata to the transmission medium through itsinterface.

Multiple WSN applications can be simulatedsimultaneously in WISENES. Applications aredesigned as a set of tasks communicating together.Tasks initiate sensing, perform data processingand aggregation, and initiate data transfers. Theapplication layer, which implements a host environ-ment for application tasks, is a part of the WISE-NES framework.

Applications are implemented either in detailusing SDL or by a task graph. The task graph is asimple data dependency graph described by the sim-ulator input parameters. In addition to the task datadependencies, it defines the task activation frequen-cies, and task sensing and data characteristics. Thisapproach enables the testing of different types ofapplications with minimum effort.

3.1. WISENES input and output

The input parameter and output result groups ofWISENES are summarized in Fig. 2. WISENESinput parameters are defined using eXtensibleMarkup Language (XML), each parameter set hav-ing a dedicated file with a pre-defined structure.

WISENES

file input (.xml)

file output (.log) socket connection

• Node parameters• Transceiver unit parameters• Peripheral parameters• Protocol parameters• Transmission medium parameters• Sensing parameters• Application parameters

• Power consumption• Memory consumption• Network performance• Protocol performance• Application performance

• Node population• Network topology• Node battery levels

GUI

WISENES

file input (.xml)

file output (.log) socket connection

• Node parameters• Transceiver unit parameters• Peripheral parameters• Protocol parameters• Transmission medium parameters• Sensing parameters• Application parameters

• Power consumption• Memory consumption• Network performance• Protocol performance• Application performance

• Node population• Network topology• Node battery levels

GUI

Fig. 2. WISENES input parameter groups and output results.

Table 2WISENES input parameters and their types

Parameter Type Description

Node parameters

Execution capacity Integer (MIPS) Instructions CPU can execute in a secondInstruction memory size Integer (instruction) Available instruction memoryData memory size Integer (byte) Available data memoryPower unit capacity Float (mAh) Initial energy capacity in node batteryActive state power

consumptionFloat (lW) Consumed power in active state

Sleep state information [Float, float] array (ms, lW) Required idle time before activation and power consumption in sleepstate

Harvesting capacity Float (lW) Power node can harvest from environmentTransceiver unit(s) Integer array (identifier) Transceiver unit(s) on the nodePeripherals Integer array (identifier) Peripherals attached to the nodeNode coordinates Float array (m) Three-dimensional coordinates for node (x,y,z)

Transceiver unit parameters

Throughput Integer (bps) Transceiver unit data rateStart-up transient period Float (ms) Start-up transient time before receiver/transmitter is readyData loading information [Integer, float] pair (bps, lW) Throughput and power consumption during transceiver to CPU

communicationReceiver power Float (lW) Power consumption while receiver is activeTransmit power levels [Integer, float] array (dBm,

lW)Available transmit powers and corresponding power consumption

Carrier sensing power Float (lW) Power consumption during carrier sensing operation (if available intransceiver)

Peripheral parameters

Type Constant string (identifier) Defines the peripheral type, e.g. sensor, ADC, location-finding system,mobilizer

Phenomena Integer array (identifier) Phenomena the peripheral is related to, if sensorRelations Integer array (identifier) Relations to other peripheralsActivation time Float (ms) Time the peripheral is active once activatedActivation power Float (lW) Power consumption when peripheral is active

Protocol parameters (for each protocol layer)

Instruction memoryconsumption

Integer (instruction) Instruction memory required by the protocol layer

Data memory consumption Integer array (byte) Protocol static and dynamic data memory consumption

Transmission medium parameters

Signal attenuation curve Float array (constant) Define signal attenuation curve coefficients (k,b,v)Minimum PER Float (constant) Minimum PER in the transmission mediumSensing parameters

Active phenomena Integer array (identifier) Phenomena that can inspectedLimits Float array (dependent unit) Lower and upper limits separately for each sensed phenomenon value

Application parameters

Task activation interval Float (ms) The interval between task activationsTask data activation Integer (constant) After how many activations task initiates a data transferTask data amount Integer (byte) The amount of data sent by the taskTask data relations Integer array (identifier) Task to which the data is sentTask peripheral relations Integer array (identifier) Peripherals required by the taskInstruction memory

consumptionInteger (instruction) Task instruction memory consumption

Data memory consumption Integer array (byte) Task static and dynamic data memory consumptionTask executed operations Integer (constant) Executed operations per task activationTask population Integer array (identifier) A list of node identifiers defining the nodes, in which the task binary is

located


Node parameters are given in two separate files. Thefirst defines the capabilities of node platforms, and

the other per-node platform type and nodecoordinates.


WISENES outputs information in two forms.Detailed information about the simulated WSNand nodes is collected to log files. Each protocoland data event during a simulation is logged withthe parameters that define the cause and the conse-quence of the event. Log data are written to per-node directories, each protocol layer, application,and a control instance modeling OS routines havinga dedicated .log-file. During an active simulationrun, the progress of a simulation is illustratedthrough GUI presenting the node population, net-work topology, and node energy level.

Input parameters at each group and their typesare presented in detail in Table 2. Node, transceiverunit, and peripheral parameters define the capabili-ties of sensor node platforms. Protocol related inputparameters define the static memory consumptionfor each protocol, while the rest of the characteris-tics are specified in the protocol SDL implementa-tion. Transmission medium parameters define itsmodeling and sensing parameters active phenom-ena. An application task graph and an initial appli-

Table 3WISENES output results and their types

Result Type Descript

Power consumption (final and variation during time)

Node, total Float (lW) Total poCPU Float array (lW) Power cTransceiver unit Float array (lW) TransceiPeripherals Float (lW) PeripherProtocols Float array (lW) Power c

node)Application tasks Float array (lW) Power c

node)

Memory consumption (final and variation during time)

Application tasks, instruction Integer array (instructions) InstructiApplication tasks, data Integer array (byte) Static an

nodeProtocols, data Integer array (byte) Static an

Network performance (averaged and variation during time)

Throughput Integer array (bps) ThroughDelays Float array (ms) TransferPER Float array (constant) Packet eCollisions Integer Number

Protocol performance (averaged and variation during time)

Delays Float array (ms) Delays dBuffering Integer array (constant) Buffer leThroughput utilization Float array (constant) Utilized

Application performance (averaged and variation during time)

Delays Float array (ms) CommuActivation accuracy Float array (ms) The varData coherence Float array (constant) The accu

cation task population are described in theapplication parameters.

Table 3 shows the output results and their types.As the events are logged as they occur, the momen-tary values of the presented results are stored intothe logs. Depending on the type of the result, thevalues are also accumulated or averaged to obtainan overall knowledge about the system behavior.

3.2. WISENES user interfaces

WISENES has two UIs for controlling and mon-itoring simulation runs. Simulations are started andcontrolled through a command line interface. Theprogress of the simulation and the topology of asimulated WSN are visualized in WISENES GUI.GUI is implemented in Java using Java foundationclasses Swing packages [39]. The communicationbetween GUI and WISENES is implemented by asocket interface. A screenshot of GUI visualizing ahundred-node TUTWSN simulation is depicted inFig. 3.

ion

wer consumption in nodeonsumption in CPU in execution and different sleep statesver unit power consumption in sending, receiving, and scanningal power consumption separately for eachonsumption in the execution of different protocols (network vs.

onsumption in the execution of application tasks (network vs.

on memory consumption in application tasks per noded dynamic data memory consumption in application tasks per

d dynamic data memory consumption in protocols per node

put per link in the networkdelays per link

rror rate per linkof collisions in a node

ue to buffering and control in different protocol layersngths in the protocolvs. available throughput

nication delays between tasksiance in task activation times vs. to expected activation times

racy and sufficiency of provided data

Fig. 3. WISENES GUI screenshot from a hundred-node TUT-WSN simulation.


Different node roles, in this case cluster head-nodes and subnodes, are shown by different colors.Remaining energy levels and the received signalstrengths of the active communication links are pre-sented in a pop-up window when a node is selected.By double clicking a node, its transmission rangeswith different transmit powers are illustrated. Fur-thermore, nodes can be moved by dragging anddropping them in GUI.

3.3. WISENES tools

A set of Tool Command Language (TCL) scriptsis implemented for WISENES initiation and resulthandling. The initiation scripts facilitate a simula-tion case construction from different protocols anda random node population generation for large sim-ulation cases. The possible relations between differ-ent types of platforms can be given as a parameterto the population generation script, e.g. in orderto force ten low power nodes in the vicinity of amore powerful one.

The result handling scripts facilitate power con-sumption, data packet tracing, and link utility eval-uations. The power consumption information isgathered from individual nodes and a listing defin-ing detailed power characteristics for different com-ponents in each node is created. The packet tracingtracks the hops of a packet from its source to thedestination node, and determines the delays on dif-

ferent hops and protocol layers. The link utilityevaluates activity and congestion of node to nodeconnections.

4. WISENES framework

The WISENES framework consists of models fortransmission medium, sensing channel, sensor node,and of a central simulation control that managessimulations and handles simulator Input/Output(I/O). Networking protocols and node platformmodeling are embedded to the sensor node model.

In addition to application tasks and protocolsdescribed by the designer, SDL is used for theimplementation of the WISENES framework. Thetool used for SDL development is Telelogic [40]TAU SDL Suite [41], version 4.5. The SDL suiteuses a graphical notation for SDL design, and pro-vides tools for simulation, integration, andimplementation.

4.1. SDL introduction

SDL is used for designing systems ranging fromgeneral software to embedded applications. MoCin SDL is parallel communicating Extended FiniteState Machines (EFSM). SDL hierarchy has multi-ple levels, of which the system level consists of anumber of blocks that clarify the representation.They can be recursively divided into sub-blocks.The behavior of a block is implemented in processesdescribed by EFSMs. The representation of a pro-cess can be simplified by implementing a part ofthe functionality in a procedure. Blocks and pro-cesses can be implemented using the type conceptof SDL, which allows their instantiation. These typedefinitions can be included with other type defini-tions to SDL packages that facilitate modular sys-tem design. The maximum number of instantiatedblocks must be defined at a compile time, whereasprocesses can be created dynamically during run-time [42].

Processes in a same or in different blocks commu-nicate by asynchronous signals that can carry anynumber of parameters. Each process has an infiniteFirst-In-First-Out (FIFO) buffer for incoming sig-nals. Signal routes define which type of signals aprocess can send and to which processes. An outgo-ing signal is routed according to the signal route ora Process IDentifier (PID). Communicationbetween processes can also be executed synchro-

Application

Node

WIS

EN

ES

framew

ork

SDL implementation

Transceiver unit

Peripheral

XML configuration files

Transmission medium

Sensing

Protocols

Protocol n

Protocol n-1

Protocol 0

...

Applicationtask procedures

Designer

SDL DataParameters Commands

SDL

Sensor node model

Application layerNode

control

Transceiver unit

Centralsimulation

control Nodesimulation

control

Sensorinterface

Transmission medium

Sensing channel

Environment functions

Simulator execution environmentSocket interface

Application

Node

WIS

EN

ES

framew

ork

SDL implementation

Transceiver unit

Peripheral


Transmission medium


Transmission medium

Sensing

Protocols

Protocol n

Protocol n-1

Protocol 0

...

Applicationtask procedures

Designer

SDL DataParameters Commands

SDL

Sensor node model

Application layerNode

control

Transceiver unit

Centralsimulation

control Nodesimulation

control

Sensorinterface

Transmission medium

Sensing channel

Environment functions

Simulator execution environmentSocket interface

Fig. 4. The architecture of WISENES instantiation.


nously by calling remote procedures, which areexported on the process interface [42].

Due to its formality, SDL can be automaticallyconverted for example to C source code, whichcan then be used to make an executable applicationor simulation. Telelogic TAU SDL simulationengine supports discrete event simulations and real-time simulations. In WISENES we utilize discreteevent simulation, in which events are processedand handled in the order of occurrence. This makesthe time concept fully parallel and avoids an activewaiting during the idle times.

Environment functions are needed for the inter-action between SDL and its execution environment.Dedicated functions are defined for environmentinitialization, unloading, signal output, and signalinput. The output function is called when a signalis sent from the SDL system to the environment.Because a method for interruption is absent inSDL, the input function must be polled for receivingsignals from the environment. In Telelogic TAUSDL simulation engine, the input function is calledafter every transaction, which is an execution flowfrom a state to another triggered by an incomingsignal. An SDL procedure can be substituted byan external function, in a case where SDL lacksexpressivity or a more efficient implementation isdesired. Both environment and external functionsare implemented in C for WISENES.

4.2. WISENES instantiation

The instantiation of WISENES is depicted inFig. 4. The designer selects the protocols from thelibrary or implements new ones in SDL and inte-grates them to the WISENES framework. Theupper and lower interfaces of the protocol stackare the pre-defined interfaces to the applicationlayer and transceiver unit, respectively. Applicationfunctionality is either implemented as SDL proce-dures or described by a task graph.

The protocol stack consists of data link, network,and middleware layers that are instances of blocktypes implemented in SDL packages. The interfacesbetween the layers are fixed, but a layer can bebypassed, i.e. a network layer can communicatewith the application layer at its upper interface.The internal implementation of layers is notrestricted in any way.

Node platforms are parameterized in the XMLconfiguration files that are parsed by Central Simu-

lation Control. The parameters are passed to Sensor

Node model. Node coordinates are relayed also toTransmission Medium and Sensing Channel, bothof which have also dedicated parameters.

The interfacing of WISENES GUI is imple-mented in environment functions that maintainthe socket connection. Information to GUI isupdated only periodically in order to lessen commu-nication. A data structure that defines sensor nodeparameters is sent to the environment functions asa signal parameter and parsed to the socket.

The SDL system of WISENES framework isillustrated in Fig. 5. The framework consists ofSDL blocks that implement the main functionalmodels and the central simulation control. The sen-sor node is a dynamic block of type Node_Type, andthe number of its instances is specified by NODE_COUNT. The figure depicts also the signal routesbetween the blocks and a dedicated signal route tothe environment.

4.3. Central simulation control

The central simulation control initiates theWISENES framework, controls active simulation

system WISENES_Framework

Sensing_Channel

Central_Simulation_Control

Sensor_Node(count):Node_Type

Node_TypeTransmission_Medium

SensingCtrlCh(SensingToCtrlSignals)

(CtrlToSensingSignals)SensingCh

(SensingToNodeSignals)

(NodeToSensingSignals)

SensingEnvCtrlCh

(CtrlToEnvSignals)

(EnvToCtrlSignals)

NodeCtrlCh

(CtrlToNodeSignals)

(NodeToCtrlSignals)Ctrl

MediumCtrlCh

(CtrlToMediumSignals)

(MediumToCtrlSignals)

Medium

MediumCh(NodeToMediumSignals)

(MediumToNodeSignals)

Fig. 5. The SDL system level of WISENES framework.


runs, and performs event logging. The informationgathering for the control and logging is imple-mented in remote procedures that are presentedwith their parameters in Table 4.

The input parameters of UpdateNodeInformation

procedure specify the node identifier, current bat-tery level, role, and the connectivity to other nodes.The node role defines whether a node is a headnode,a subnode, or a sink. Sensor nodes call the proce-dure whenever any of the parameter values changes.The information is relayed to GUI and utilized fordetermining whether the simulation end conditionis satisfied. The end condition is set by the designerand it defines a simulation time limit, a percentageof dead nodes, or e.g. a limit for an application taskactivation count.

Distinct remote procedures for event and datapacket logging are exported for each protocol layer,application tasks, and for framework components.Their parameters vary depending on the layer. Logsare stored in dedicated data structures and writtento files either periodically when WISENES memoryconsumption exceeds a pre-defined limit, or at theend of the simulation.

Table 4The remote procedures exported by the central simulation control

Procedure Parameters

UpdateNodeInformation NodeId, NodeRole, BatteryState,TransceiverUnit, Connectivity

LogXxxEvent NodeId, EventName, Cause,Consequence, . . .

LogXxxData NodeId, PacketId, DataLength,DataAction, . . .

4.4. Transmission medium

The transmission medium model provides theconnectivity between sensor nodes. It is imple-mented as an SDL process that redirects signalsfrom a source to the destination sensor node SDLblocks. Sensor nodes register their node identifierand transceiver unit PID to the transmission med-ium for enabling the data redirecting. Due to thenature of SDL data typing, transmitted data areseparately copied for each destination node.

The signal propagation in the transmission med-ium is based on the transceiver unit dependent sig-nal attenuation. The curve S defining the PacketError Rate (PER) is

S ¼ kd � bþ Pv

� �; ð1Þ

where d is the distance between the source and des-tination nodes (m), and P is the transmit power(dBm). Constants k, b, v are derived from the mea-sured signal attenuation curve. PER for a packet is

PER ¼1; if S P 1

S; if L < S < 1

L; if S 6 L

8><>:

9>=>;; ð2Þ

where L is the lower limit for the PER.In order to realistically model the hidden node

problem and collisions, S is calculated separatelyfor each node within the coverage of the transmis-sion. The transmit power is specified by the sourcenode. After the PER evaluation, a random number0 6 r < 1 is generated again separately for eachnode. A transmission is successful, if r > PER. If


S > 1, the signal attenuates during the transmission,otherwise the signal is relayed to the destination. IfS < 1 and r < PER, the unsuccessful transmission isindicated to the recipient but the copying of theactual data is not performed.

A delay during a transmission is calculated bydividing the packet length by the transceiver unitthroughput. The delay of the signal propagation inthe medium is omitted. Thus, a packet is relayedto the destinations immediately after the transferdelay.

4.5. Sensing channel

The sensing channel model simulates physicalphenomena. Similarly to the transmission medium,the sensing channel utilizes node coordinates.Each phenomenon is modeled separately with indi-vidual propagation characteristics. The propagationdepends also on the media in the vicinity.

Our current sensing channel implementation gen-erates random stimuli for phenomena, except forthe location queries that return node coordinates.The upper and lower limits are defined for eachphenomenon. Currently simulated phenomena aretemperature, humidity, vibration, sound, luminance,and location information. The selected approach isapplicable for environmental monitoring, but amore detailed sensing channel must be implementedfor e.g. object tracking applications.

4.6. Sensor node

The sensor node SDL block implementing thenode model is depicted in Fig. 6. On the sensor nodemodel, Physical layer, Sensor Interface, ApplicationLayer, and Node Control blocks are part of theWISENES framework, while the instantiated proto-col layers are selected or implemented by thedesigner. The signal routes between the protocollayers are for data communications, whereas the sig-nals sent from the node control to the other blocksare for the initiation and shutdown.

4.6.1. Physical layer

A transceiver unit process at the physical layermodels the hardware and its device driver. The pro-cess implements the interface to the transmissionmedium, performs collision detection, and modelsthe internal delay in a transceiver unit. Dependingon the modeled hardware, additional features suchas Cyclic Redundancy Check (CRC) [38] for error

detection or an algorithm for encryption are incor-porated to the model. No real CRC or encryptioncalculation is performed, but the data consistencyis validated from the parameters of the signalreceived from the transmission medium. The upperinterface of the transceiver unit defines signals forthe lowest protocol layer. Dedicated signals aredeclared for the transceiver unit control, transmitteror receiver enabling, carrier sensing, data sending,send confirmation, and data reception indication.

Transferring data to or from the transceiver unitcauses delay, because a transceiver unit is typically adistinct hardware component on a node platform. Adelay, which is calculated by dividing the datalength in bits by the interface bit rate, is generatedwhen data is loaded to or from transceiver unit.

4.6.2. Sensor interface

The sensor interface block implements a processthat models the Analog-to-Digital Converter(ADC) and sensor operations. When an applicationtask initiates sensing, it sends a signal to the sensorinterface process. The process activates the sensorand other required peripherals (e.g. ADC for sam-pling the analog sensor output) for that phenome-non. The sensor interface process acquires a valuefrom the sensing channel by signal exchange. Theoperation delay depends on the associated sensorand possibly on the ADC sampling frequency,which are defined in the input parameters. The usedperipherals are reserved during the operation.

4.6.3. Application layer

The application layer consists of a process thatimplements the scheduling of application tasks. Thisapproach is selected to facilitate the task schedulingwhen they are implemented as SDL procedures.When an application is described as a task graph,the application layer process emulates the executionof tasks. In this case no real functionality apartfrom the sensing and data transfer initiation isimplemented.

The application task procedures are implementedby the designer. They define the functionality of thetasks, while the task state control and scheduling areimplemented in the application layer process. Taskstate is running when it is executed, ready when itis ready for execution but another task is running,or wait when the task requires either a timer, data,or sensor event to occur before running. Supportedscheduling algorithms are round robin and staticpriority scheduling.

block type Node_Type

SensorInterface

ApplicationLayer

Middleware:MiddlewareLayer

Network:NetworkLayer

DataLink:DataLinkLayer

Physical:PhysicalLayerNodeControl

Sensing(NodeToSensingSignals)


Ctrl(NodeToCtrlSignals)

(CtrlToNodeSignals)Medium

(NodeToMediumSignals)


SensorSensingCh(NodeToSensingSignals)


AppSensorCh(SensorToAppSignals)

(AppToSensorSignals)

AppMiddleCh(AppToMiddleSignals)

(MiddleToAppSignals)

App

MiddleNetCh(MiddleToNetSignals)

(NetToMiddleSignals)

Net

Middle

NetDlCh(DlToNetSignals)

(NetToDlSignals)

Net

DlMiddleDlCh

(DlToMiddleSignals)

(MiddleToDlSignals)Middle

Dl

DlPhyCh(DlToPhySignals)

(PhyToDlSignals)

Phy

Dl

PhyMediumCh

(NodeToMediumSignals)


Medium

CtrlSensorCh

(CtrlToSensorSignals)

CtrlAppCh

(CtrlToAppSignals)

CtrlMiddleCh

(CtrlToMiddleSignals)Ctrl

CtrlNetCh

(CtrlToNetSignals)Ctrl

CtrlDlCh

(CtrlToDlSignals)Ctrl

CtrlPhyCh

(CtrlToPhySignals)Ctrl

NodeCtrlCh(NodeToCtrlSignals)

(CtrlToNodeSignals)

Fig. 6. The SDL block type for WISENES sensor node.


When a task is ready and scheduled for process-ing, the application layer process calls the procedurethat implements the task. The event that moved thetask to the ready state and the payload associated tothe event are given in the parameters of the proce-dure. When the task completes its next transitionit enters to the wait state. The waited event isreturned to the application layer process. In occur-rence of an event, all tasks waiting for it are set tothe ready state.

4.6.4. Node control

The node control block consists of two processes,Node control and Node simulation control. The nodecontrol process implements OS routines in WISE-NES. The possible states of a sensor node and the

actions triggering node state transitions are depictedin Fig. 7. When the node is in an active state, itsCentral Processing Unit (CPU) and transceiver unitare powered. Transceiver unit dependent statesreceiving and transmit are substates of the activestate. The node enters to a transceiver sleep state,when its transceiver unit is not needed during a con-stant period. When there is nothing to process onCPU, the node is set to a sleep state that dependson the length of the inactive period. The periodsand corresponding sleep states are defined in theinput parameters. Tasks can be executed and sens-ing activated when the node is in the active state,one of its substates, or in the transceiver sleep state.

The remote procedures exported by the nodecontrol for implementing OS routines are presented

activetransmit receiving

data sent AND TX disable

Tx enable

RX enable

received dataOR RX disable

transceiversleep

nodesleep

datatimer

no timewindow

sleeptimer

off timeperiod

sensingactive

CPUsleep

sleep timeperiod

sleeptimer

activetransmit receiving

data sent AND TX disable

Tx enable

RX enable

received dataOR RX disable

transceiversleep

nodesleep

datatimer

no timewindow

sleeptimer

off timeperiod

sensingactive

CPUsleep

sleep timeperiod

sleeptimer

Fig. 7. Sensor node states and state transitions in WISENES.


in Table 5. Periodically activated protocols andapplication tasks call SetNextActiveTime procedureto indicate their next wakeup time. When all proto-cols and application tasks are inactive, the nodecontrol sets the node to a sleep state. The memorymanagement for application tasks and protocols isimplemented in ReserveMemory and FreeMemoryprocedures. Protocols and applications reserveCPU time slots by calling Execute procedure. Theexecuted operations are given as a parameter. Aprotocol may check remaining energy resources of

Table 5The remote procedures exported by the node control and nodesimulation control

Procedure Parameters

Node control

SetNextActiveTime CallerId, ActivationTime,TransceiverUnitControl

ReserveMemory CallerId, Type, AmountFreeMemory CallerId, Type, AmountExecute CallerId, OperationCountGetCurrentBatteryLevel Returns CurrentLevel

Node simulation control

UpdateNodeRole NodeRoleUpdateConnectivity NearbyNodeIds,

NearbyNodeSignalStrengthsConsumePeripheralPower PeripheralId,

ActivationTimeConsumeTransceiverSendPower SendBytesConsumeTransceiverReceivePower Type,

ReceiverActivationTimeSetNodeState StateMarkActiveExecution CallerId, OperationCountGetRemainingEnergy Returns RemainingEnergy

the node by calling GetCurrentBatteryLevel

procedure.The Node simulation control implements a per-

node interface to the central simulation controland models the power consumption of node plat-form. In the initiation, the node simulation controlrelays node parameters in signal parameters to thenode control and to the different layers. During anactive simulation run, the node simulation controlgathers GUI related information from the nodeand passes it to the central simulation control.Remote procedures that implement the gatheringare presented in Table 5. UpdateNodeRole andUpdateNodeConnectivity must be called from proto-cols that possess the required information.

The node power consumption modeling is imple-mented in the node simulation control by a linearbattery model, in which the component power con-sumption is independent of the battery dischargerate. The remote procedures related to the powerconsumption are called only from the SDL pro-cesses that are part of the WISENES framework.The sensor interface process indicates a peripheralactivation by calling ConsumePeripheralPower pro-cedure. Procedures ConsumeTransceiverSendPower

and ConsumeTransceiverReceivePower are calledby the transceiver unit process when a transmitterand a receiver are activated, respectively. The nodecontrol marks the node state transitions by callingSetNodeState and indicates the execution by callingMarkActiveExecution. GetCurrentBatteryLevel pro-cedure in the node control calls GetRemainingEner-

gy to determine the battery level.The power consumption in a sensor node can be

divided into a very detailed level, as peripherals,protocols, and application tasks can be identifiedwhen they indicate their activation by calling a ded-icated remote procedure. The power consumptionby the transceiver unit can be split between thetransmission and reception, while CPU power con-sumption can be assigned to the different states,and to the application tasks, protocols, and devicedrivers.

The harvesting of energy from the surroundingsis modeled in the node simulation control, if sucha peripheral is available at the node platform. Thegenerated energy is randomized between 0 and theharvesting capacity limit specified in the inputparameters. When a sensor node runs out of energy,the node simulation control removes the node fromthe transmission medium and indicates this to thecentral simulation control.


4.7. Prototype mapping in WISENES

The accurate parameterization of sensor nodeplatforms in the XML configuration files and thedetailed capability modeling in the WISENESframework lead to the simulation results that corre-spond to those obtained from real node platforms.We refer the parameterization of hardware plat-forms and their modeling in the simulator to as pro-

totype mapping.The exact modeling of node and peripheral state

changes, and the detailed specification of the nodepower characteristics in the input parameters resultin realistic mapping of the power consumption. Fora fine-grained power consumption mapping of pro-tocol and application execution, the number of exe-cuted operations given as a parameter to Execute

procedure must be estimated during the initialdesign phase. For the further evaluation, bench-marking information from the prototype measure-ments is utilized.

The memory and processing capacities of thenode platforms are defined in the input parameters.The static instruction and data memory usage ofprotocols and applications is parameterized,whereas the dynamic data memory consumptiondepends on the data buffering and control con-structs stored within each protocol layer. The pro-cessing capacity is controlled by Execute

procedure in the node control.The delays in the data transmissions are modeled

in the transmission medium and in the transceiverunit. This approach considers the transfer delayand the internal processing delay of the transceiverunit, but omits the signal propagation delay in thetransmission medium.

4.8. Simulation of node code implementations in

WISENES

In addition to the simulation of node models thatare composed of protocols implemented in SDL,WISENES contains a prototype emulation environ-

ment, which allows the simulation of low-level Cimplementations that are directly applicable fornode prototypes. Similarly to sQualnet [15], the Ccode implementation is integrated above the datalink layer by a dedicated network layer SDL block.This block consists of a process that redirects theper-node signals received from the data link layerto the emulation environment and vice versa, andimplements the timer concept for the emulation.

When an SDL block in WISENES is created fora node, the prototype emulation environment cre-ates a simulator host OS thread for the node andassociates the thread to the node id. On the recep-tion of a signal from the data link layer, the SDLblock calls a signaling function from the prototypeemulation environment. The emulation environ-ment redirects the signal to the correct thread andconverts the signal parameters to a function callor to a message for the final C implementation.After the subsequent processing is completed, theSDL block calls a query function at the emulationenvironment. The query function gathers the eventscaused by the received signal and passes them backto the SDL block. The indications related to timersare handled similarly.

The current version of the prototype emulationenvironment in WISENES supports TUTWSN Ccode implementations. The required effort for port-ing the emulation environment core to supportother platforms is minimal. Only the interface pro-vided by the emulation environment for the C codeneeds to be adapted.

5. WISENES use-cases: TUTWSN and ZigBee

WISENES is used for the design and evaluationof two use-cases: proprietary TUTWSN and a stan-dard ZigBee network. In both, the design startsfrom scratch and ends up to extensive performancesimulations. Prototype platforms for both cases areparameterized using the XML configuration filesand the protocols are designed and implementedin SDL.

5.1. TUTWSN implementation

TUTWSN is a very energy efficient WSN tar-geted to low data rate applications, such as environ-mental and industrial monitoring [4]. TUTWSNconsists of a configurable full feature protocol stack,a family of physical node platforms, and severalGUIs for the network management andvisualization.

5.1.1. TUTWSN protocol stack

The TUTWSN protocol stack in WISENES con-sists of a middleware, a multi-hop routing protocolat the network layer, and a MAC protocol at thedata link layer. TUTWSN MAC is an energy effi-cient clustered protocol that minimizes the timespent in a receiving state per a node. Time Division

Fig. 8. TUTWSN Xemics prototype.


Multiple Access (TDMA) is used for the intra-clus-ter communication, whereas neighboring clustersoperate on different frequency channels. The controlsignaling, not the data transfers, for the inter-clustercommunication is performed on a dedicated net-work signaling channel.

At the beginning of each access cycle a clusterheadnode broadcasts an active network beacon tothe network signaling channel. Other headnodes uti-lize the beacon for the multi-hop routing, whereassubnodes listen the channel only when they aresearching for a cluster for the association. Neighbordiscovery times are shortened by idle network bea-cons that are sent during the inactive period of theaccess cycle. An idle network beacon indicates thetime of the next active network beacon.

The communication within a cluster is performedduring a superframe consisting of cluster beacons,aloha slots for contention, and reservation dataslots. The inter-cluster data transfers are made dur-ing the superframe of the recipient headnode. Clus-ter beacons start a superframe by informing theassociated nodes of the allocated reservation dataslots and access cycle timing. Subnodes listen thebeacons but sleep the rest of the access cycle, unlessthey have data to process. In the contention slots,subnodes and neighbor headnodes send occasionaldata and slot reservation requests to the clusterheadnode. The reservation data slots are allocatedfor periodical data transfers. Each slot consists ofan uplink for data sending to the headnode and ofa downlink for acknowledgements and data sendingto the associated node.

The TUTWSN MAC protocol in WISENESimplements a self-organizing cluster creation algo-rithm, and intra-cluster and inter-cluster communi-cation. For the inter-cluster communication, thecluster access cycle timing can be adapted accordingto the routing protocol needs. In order to minimizethe delay, the start time of the own access cycle isadjusted so that the superframe is completed rightbefore the start of the access cycle of the next hopcluster. The length of a slot is 20 ms, uplink anddownlink being both 10 ms. The access cycle length,and the number of contention and reservation dataslots are varied.

The flooding routing protocol is implemented forthe multi-hop path creation. Route requests arebroadcast to the network until a path to the destina-tion is found. In order to avoid unnecessary com-munication, the route requests are identified sothat duplicates can be discarded. Further, the neigh-

boring information from the MAC layer is utilized.If a node knows a valid route to the destination, itinitiates a response. Each node stores only theaddress of the next hop and the total hop countfor each destination.

The TUTWSN middleware layer controls theapplication task hosting in sensor nodes andabstracts the communication between tasks. Themiddleware keeps track of the neighbor nodes,which host tasks that are related those tasks hostedby the node itself. When a task sends data toanother task, the middleware redirects the data tothe correct node.

5.1.2. TUTWSN prototype platform

The TUTWSN prototype used in the simulationsis depicted in Fig. 8. The main component on theprototype is a 2 MIPS Xemics XE88LC02 [43]MicroController Unit (MCU) consisting of a Cool-Risc 816 processor core, a 16-bit ADC, 22 KB pro-gram memory, and 1 KB data memory. 2.4 GHzNordicVLSI nRF2401 transceiver unit [44] on theprototype supports 250 kbps and 1 Mbps data rateswith transmit power adjustable between �20 and0 dBm. A 16-bit CRC error detection is imple-mented in the transceiver unit. For the environmen-tal monitoring, the prototype has an integratedMAX6607 temperature sensor. A 0.22 F capacitoris used as the energy storage for the prototype.

The mapping between the TUTWSN prototypeand the WISENES sensor node model is depictedin Fig. 9. The TUTWSN protocol stack for the pro-totype is implemented in C and executed on XemicsMCU. In WISENES, it is implemented in SDL onthe sensor node model. Application tasks run ontop of the protocol stack. A lightweight OS that isimplemented in C controls the scheduling andpower management on the prototype. In WISE-NES, its functions are modeled by the node control.

The nRF2401 transceiver unit and its device dri-ver are implemented by the transceiver unit process

Sensor node model in SDL

Node control

Application

Middleware

Routing

MAC

Transceiverunit

TUTWSN prototype platform

Xemics XE88LC02

nRF2401Sensors

Middleware

Lightweight OSRouting

MACDevice driver

ADC controlDevice driver

Application

Powerunit

SensorInterface

Powermodel

WISENESPrototype implementation

Hardware parametrization C implementation

ADC

Mapping

Sensor node model in SDL

Node control

Application

Middleware

Routing

MAC

Transceiverunit

TUTWSN prototype platform

Xemics XE88LC02

nRF2401Sensors

Middleware

Lightweight OSRouting

MACDevice driver

ADC controlDevice driver

Application

Powerunit

SensorInterface

Powermodel

Hardware parametrization C implementation

ADC

Fig. 9. The prototype mapping between the WISENES sensor node model and TUTWSN prototype.


in WISENES. The sensor interface process modelsthe sensors, ADC, and their device drivers. Thepower model in the node simulation control simu-lates the power unit and the power consumptionof the hardware components.

Fig. 10 gives an example of the XML configura-tion parameters that specify the presentedTUTWSN prototype for WISENES. A dedicatedparameter set for a sensor node is assembled fromthe node type parameters (a), transceiver unitparameters (b), peripheral parameters (c), and nodeparameters (d). The transceiver unit dependent sig-nal attenuation curve constants for nRF2401 arefollowing: k = 0.2385, b = 2.7, v = 18.0, andL = 0.03. These are obtained by measuring PERfor different distances and deriving the values fromthe results.

5.2. ZigBee implementation

ZigBee [5] is a networking architecture targetedto low-cost and low-power monitoring and controlapplications. Although not directly designed forWSNs, many of its characteristics have encouragedits use also in WSN scenarios. The topology in aZigBee network can be either star or mesh. In thestar topology, a single ZigBee coordinator controlsthe whole network, whereas in the mesh topology,nodes communicate directly through peer-to-peerlinks. A special type of a mesh network is a clus-ter-tree topology, in which a coordinator starts thenetwork but other coordinators (referred also toas ZigBee routers) can extend the network. In the

following, we concentrate on the cluster-tree topol-ogy, because it is the only alternative for the low-power WSNs and the closest to the TUTWSNuse-case.

5.2.1. ZigBee protocol stack

The ZigBee protocol stack defined in the specifi-cation consists of a MAC protocol, network layer,and application layer. WISENES implements a fullfeatured version of the IEEE 802.15.4 Low-RateWireless Personal Area Network (LR-WPAN)MAC protocol [45] for ZigBee, and a simplified ver-sion of the ZigBee networking layer. The same mid-dleware layer as in TUTWSN is used on top of theZigBee protocols.

The ZigBee MAC in the cluster-tree topologynetworks uses a beacon-enabled channel access. AZigBee network is started and its parameters definedby a ZigBee coordinator. When joining to a net-work, a ZigBee router starts transmitting beaconson the same communication channel with theparameters advertised by its parent. The beacon isfollowed by a Contention Access Period (CAP) forCarrier Sense Multiple Access (CSMA) data trans-fers. Periodic data transfers between the ZigBeecoordinator and a child device can be made inguaranteed time slots during a Contention Free Per-iod (CFP) that follows CAP in the superframe ofthe ZigBee coordinator. The length of the accesscycle (beacon period) and the superframe (CAP per-iod) depends on the constants BeaconOrder andSuperframeOrder that are defined by ZigBeecoordinator.

<node_type id=“1”><name>TUTWSN Xemics Node</name><type>FFU</type><cpu_info>

<capacity>2000000</capacity><code_memory_inst>8000</code_memory_inst><data_memory_byte>1024</data_memory_byte>

</cpu_info><battery>

<voltage_V>3.0</voltage_V><capacity_mAh>0.57</capacity_mAh><efficiency>0.8</efficiency><harvest_uW>0</harvest_uW>

</battery><state_info>

<state name=“active” ms=“0” uW=“1350”/><state name=“node sleep” ms =“3” uW=“19”/>

</state_info><transceiver_unit id=“1”/><peripheral_info>

<peripheral id=“1” count=“1”/><peripheral id=“2” count=“2”/>

</peripheral_info></node_type>

<transceiver_unit id=“1”><name>nRF2401</name><throughput_bps>1000000</throughput_bps><rssi capability=“NO”/><data_load_info bps=“230400” uW=“1310”/><receiver_info transient_ms=“0.25” uW=“43600”/><transmitter_info>

<transient_ms>0.25</transient_ms><tx_power_levels>

<tx_power dBm=“-20” uW=“18700”/><tx_power dBm=“-10” uW=“23500”/><tx_power dBm=“-5” uW=“26400”/><tx_power dBm=“0” uW=“29300”/>

</tx_power_levels></transmitter_info><carrier_sense_info capability=“NO”/>

</transceiver_unit>

<peripheral id=“1” phenomenon=“NONE”><name>ADC</name><dependency id=“0”/><active_period ms=“0.5” uW=“15”/>

</peripheral><peripheral id=“2” phenomenon=“TEMPERATURE”>

<name>Temperature sensor</name><dependency id=“1”/><active_period ms=“0.1” uW=“10”/>

</peripheral>

<node_list count=“5”><node id="1“ type=“2”>

<coordinates x=“0.0” y=“0.0” z=“0.0”/></node><node id=“2“ type=“1”>


<coordinates x=“8.4” y=“-5.21” z=“1.03”/></node><node id=“4“ type=“1”>


<coordinates x=“22.4” y=“0.21” z=“0.93”/></node>

</node_list>

<node_type id=“1”><name>TUTWSN Xemics Node</name><type>FFU</type><cpu_info>



<voltage_V>3.0</voltage_V><capacity_mAh>0.57</capacity_mAh><efficiency>0.8</efficiency><harvest_uW>0</harvest_uW>






<transceiver_unit id=“1”><name>nRF2401</name><throughput_bps>1000000</throughput_bps><rssi capability=“NO”/><data_load_info bps=“230400” uW=“1310”/><receiver_info transient_ms=“0.25” uW=“43600”/><transmitter_info>



</tx_power_levels></transmitter_info><carrier_sense_info capability=“NO”/>

</transceiver_unit>

<peripheral id=“1” phenomenon=“NONE”><name>ADC</name><dependency id=“0”/><active_period ms=“0.5” uW=“15”/>

</peripheral><peripheral id=“2” phenomenon=“TEMPERATURE”>

<name>Temperature sensor</name><dependency id=“1”/><active_period ms=“0.1” uW=“10”/>

</peripheral>

<node_list count=“5”><node id="1“ type=“2”>





<coordinates x=“22.4” y=“0.21” z=“0.93”/></node>

</node_list>

a

b

c dFig. 10. TUTWSN prototype: (a) node type, (b) transceiver unit, (c) peripheral and (d) node parameters for WISENES.


Each child device communicates with its parentcoordinator during CAP. All transactions must becompleted before the end of CAP. Before a trans-mission, a random back-off period is waited. Afterthe back-off, the state of the transmission mediumis assessed. If the medium is busy, the back-off pro-cedure continues. If a coordinator has data pendingfor its child devices, it indicates the identifiers ofthese child devices in the beacon. When a devicereceives a beacon listing its address, it sends a datarequests to the coordinator, after which the trans-mission of data is made.

The ZigBee networking layer in WISENESimplements a mechanism for joining and leavingthe network, the algorithms for the cluster-treetopology formation, and data routing from devices

to the ZigBee coordinator. The routes are createdaccording to parent associations, i.e. each ZigBeerouter sends data targeted to the ZigBee coordina-tor to its parent. The continuous neighbor discoveryand the support for other network topologies arenot implemented. Further, the short address assign-ment and superframe scheduling algorithms benefitthe simulator addressing and timing information.

5.2.2. ZigBee prototype platform

The prototype platform used in WISENES for theZigBee evaluation is constructed from two separatecomponents. The MCU module of the prototype is2 MIPS PIC18LF4620 MCU [46] with 64 KB of pro-gram and 4 KB of data memory, an integrated 10-bitADC, and an interface to MAX6607 temperature

<node_type id=“1”><name>ZigBee PIC node</name><type>FFU</type><cpu_info>



<voltage_V>3.3</voltage_V><capacity_mAh>2100</capacity_mAh><efficiency>0.91</efficiency><harvest_uW>0</harvest_uW>






<transceiver_unit id=“2”><name>CC2420</name><throughput_bps>250000</throughput_bps><rssi capability=“YES”/><data_load_info bps=“460800” uW=“1310”/><receiver_info transient_ms=“0.22” uW=“54820”/><transmitter_info>



</tx_power_levels></transmitter_info><carrier_sense_info capability=“YES” uW=“54200”/>

</transceiver_unit>

a

<node_type id=“1”><name>ZigBee PIC node</name><type>FFU</type><cpu_info>



<voltage_V>3.3</voltage_V><capacity_mAh>2100</capacity_mAh><efficiency>0.91</efficiency><harvest_uW>0</harvest_uW>






<transceiver_unit id=“2”><name>CC2420</name><throughput_bps>250000</throughput_bps><rssi capability=“YES”/><data_load_info bps=“460800” uW=“1310”/><receiver_info transient_ms=“0.22” uW=“54820”/><transmitter_info>



</tx_power_levels></transmitter_info><carrier_sense_info capability=“YES” uW=“54200”/>

</transceiver_unit>

bFig. 11. ZigBee prototype: (a) node type and (b) transceiver unit parameters for WISENES.


sensor. The transceiver unit is 2.4 GHz ChipconCC2420 transceiver [47], which is IEEE 802.15.4standard compliant. The transceiver support250 kbps data rate and the transmit power is adjust-able between �24 dBm and 0 dBm. A CR123A lith-ium battery is used as an energy storage.

Although the prototype is assembled with twodistinct components, the resulting platform is realis-tic. MCU has enough resources for the ZigBeeimplementation. The power consumptions of thecomponents are measured separately, but they arecombined in WISENES. The transceiver unitparameters are measured using a Chipcon SmartRFCC2420DK Development Kit [47]. The constantsfor the transmission medium are: k = 0.08,b = 3.4, v = 6.0, and L = 0.05. The WISENESXML configuration parameters describing the pro-totype node type (a) and transceiver unit (b) aredepicted in Fig. 11.

6. WISENES evaluation

The design of a new protocol and the deploymentof a complete WSN protocol stack in WISENES arestraightforward for the designer due to the hierar-chical structure of SDL and the modularity of theWISENES framework. The graphical design based

on state machines is well-suited for the protocolmodeling. The modeled protocols are internallyindependent of WISENES, but an external interfacefor the adaptation of each layer to the WISENESframework is required. Interface templates are pro-vided for the designer.

For the usage evaluation, the full feature ZigBeeMAC protocol was implemented according to thespecification by a single designer within two work-ing weeks. The designer was familiar with theWISENES interfaces, but still the developmentcycle was faster than expected. The SDL descriptionattached to the IEEE 802.15.4 standard was tooincomplete to be used in WISENES.

The full implementation of the ZigBee MACprotocol in WISENES consists of three processeshaving totally 31 different states. In addition, 75SDL procedures are implemented in order to avoidredundant implementations and clarify the descrip-tion. The number of state transitions in the imple-mentation is 163. Among the transitions, there arein total 1817 divergent execution paths. The imple-mentation of TUTWSN MAC protocol in WISE-NES consists of two processes that have totally 21states and 32 procedures. The number of statetransitions is 112, but there are still 2642 divergentexecution paths.

1 2

2

1

Aggregated data

Subnode

Sensed data

Headnode

Sink node

1 2

2

1

Aggregated data

Subnode

Sensed data

Headnode

Sink node

Aggregated data

Subnode

Sensed data

Headnodee

Sink node

Fig. 13. Static topology for the prototype mapping test case.

0

50

100

150

200

250

10 100 1000

Sensor Node Count

Tim

e (s

)

Simulation, No GUI

Simulation, GUI

Logging

Fig. 12. Time required for the simulation of a single node inWISENES for a 24-h period with varying total number of nodes.


The simulation and evaluation capabilities ofWISENES are assessed by simulating TUTWSNand ZigBee networks. The application used in thesimulations is an environmental monitoring applica-tion. All nodes in WSN observe the temperature intheir vicinity. Sensed data are aggregated in clusterheadnodes (coordinator) and routed for a furtherprocessing to the sink node (ZigBee coordinator).The application is implemented by describing it asa task graph.

The evaluated aspects in WISENES are the per-formance of the simulator, applicability for thelarge scale simulations, and the accuracy of the pro-totype mapping. All simulations are executed on aworkstation with a 2.8 GHz Pentium4 processorwith 1 GB of memory and running Windows XPSP2. WISENES memory consumption is limited to150 MB, meaning that gathered log data are writtento files when the limit is exceeded.

6.1. WISENES performance

TUTWSN simulations are repeated five timeswith 10, 100, and 1000 of nodes. The node popula-tion is randomly generated for each simulation run.Monitored aspects are the correct functionality andperformance. The initial energy capacity of a TUT-WSN node is set twenty times larger than specifiedin Fig. 10 in order to obtain required lifetime. TheTUTWSN access cycle in simulations is 10 s, andeach node measures temperature once in an accesscycle and sends the result towards the sink node.Headnodes aggregate the subnode readings to a sin-gle data packet.

The presented WISENES performance is thetime elapsed for the simulation of a single nodefor a 24-h period. During that time, a node initiates8640 data packets. The resulting time is obtained bydividing the overall network simulation time by thenode count. The elapsed per-node simulation timeswith and without GUI are depicted in Fig. 12. Inaddition, the time consumed on writing the log datato files is presented separately.

The operations on a single node remain similarregardless of the node count. Hence, the simulationtime per a node should be at the same level in allcases. However, as depicted, the time per nodeincreases as the node count increases. This is causedby the increased time consumption in the processingof longer lists in both Telelogic TAU SDL Suitesimulation engine and WISENES framework com-ponents. The communication with GUI is time con-

suming but the penalty is independent of the nodecount. The increase in the simulation time is causedby the environment function polling and the largeamount of node information passed through thesocket interface.

As depicted in Fig. 12, the time consumed on logwriting with 1000 node simulations is ten timeslonger than in the other cases. A reason for this isnot accurately known, but it may be due to the frag-mentation of the storage disk, because the size of thelogged data in this case is over 12 GB.

6.2. Prototype mapping results

For the evaluation of the prototype mappingaccuracy, a similar configuration, illustrated inFig. 13, is constructed for both WISENES and pro-totypes. Subnodes S1 and S2 perform sensing andsend the data to headnode H1 once in every accesscycle. Headnode H1 aggregates data and sends themto the sink node through headnode H2. The numberof contention slots is four, reservation data slots arelimited to eight, and idle network beacons are sentevery 250 ms. The access cycle length is 1, 2, 5,and 10 s. Cluster scanning is avoided by using staticaccess cycle timings.

0

300

600

900

1200

1500

1 2 5 10

Access cycle length (s)

0

20

40

60

80

100

120

140

160

180

1 2 5 10

0

300

600

900

1200

1500

1 2 5 10


Pow

er (

μW)

Pow

er (

μW)

a

b

Transceiver

PeripheralsMCU, sleep

MCU, activePower unit

Transceiver



Fig. 15. The power consumptions of different components inTUTWSN: (a) headnode and (b) subnode in a thousand-nodenetwork.

0

100

200

300

400

500

600

700

800

900

1000

0 2 4 6 8 10


Pow

er (

μW)

H1, Prototype H1,WISENES H2, Prototype H2, WISENESS1, PrototypeS1,WISENES

Fig. 14. Modeled WISENES and measured TUTWSN prototypepower consumptions in the prototype mapping test case.


Fig. 14 presents the simulated power consump-tion from WISENES in contrasts to the measuredprototype power consumption. Generally, thepower consumption in subnodes is minimal com-pared to that of headnodes. The margin betweenthe two headnodes is not considerable, because theonly difference in their activity is one active reserva-tion data slot. When compared to the prototypemeasurements, the WISENES results are very accu-rate. The overall average difference is 6.73%. Theresults are more accurate for headnodes, averagedifference being 4.0% for H1 and 4.8% for H2.Due to the very low activity, the modeling in sub-nodes is more inaccurate, as the average differencein case of S1 is 11.34%. The main reason to this isthe differences in the timing models of WISENESand the prototypes.

Other aspects related to prototype mapping aredelay and throughput. As mentioned, WISENESmodels delays in the transmission medium andtransceiver units accurately. Only the delay of signalpropagation is omitted, but it is negligible in shortdistances when compared to the other delays intransmissions. Moreover, the main causes for thedelays on WSNs are higher layer protocol bufferingand channel access. Thus, the verification of thedelay mapping is omitted.

WSNs do not utilize the full bandwidth availableon their transceiver units but only a small fractionof it. The throughput depends on the channel accessmethod and PER. In WISENES, PER is derivedfrom the transceiver unit dependent measurementsand the implemented channel access methods areidentical. Hence, the further verification of thethroughput mapping is also omitted.

6.3. TUTWSN simulation results

A network of thousand nodes is simulated inorder to evaluate the applicability of TUTWSN inlarge scale. The number of contention slots is setto four, reservation data slots to eight, and idle net-work beacons are sent every 250 ms. The accesscycle length is 1, 2, 5, and 10 s. The environmentalmonitoring application is again activated once inan access cycle.

6.3.1. Power consumptionThe average power consumptions for five arbi-

trary selected headnodes and subnodes are depictedin Fig. 15a and b respectively. The scale in Fig. 15ais approximately eight times larger than in Fig. 15b.The power consumptions of the transceiver unit,peripherals, power unit, and MCU in sleep andactive states are presented separately.


As shown, the transceiver unit is the dominatingpower consumer in both headnodes and subnodes.With shorter access cycles, the share of the trans-ceiver unit in the power consumption is more dom-inant. The headnodes spend considerably more timewith CPU active, due to added processing andactive waiting while receiving data. The subnodesspend most of the time in the sleep states.

Compared to the power consumptions in the pro-totype mapping case, the presented results are aver-agely 28.7% larger for subnodes and 22.4% largerfor headnodes. This is mainly due to the scanningrequired for the network topology creation andmaintenance, which were omitted in the prototypemapping case. Further, headnodes have more activereservation data slots.

0

5

10

15

20

25

30

35

1 2 3 4 5 6 7 8 9 10

Hops from sink

Ave

rag

e d

ela

y (s

)

AC 10 sAC 5 sAC 2 sAC 1 s

AC 10 sAC 5 sAC 2 sAC 1 s

a

6.3.2. TUTWSN lifetime

The lifetimes of TUTWSNs with different accesscycle lengths are presented in Fig. 16. The lifetimesare shown for both a case where a node acts as aheadnode until it runs out of energy, and a casewhere a headnode deliberately releases its dutywhen its remaining energy level is first 50% and then10%. The network lifetime is considered as the timeuntil 50%r 20% of the nodes are left. In the firstcase, measurement data with reasonable accuracycan be obtained from WSN, while in the latter casethe accuracy suffers but the network is still capableof providing routes to sink node.

The changing of the cluster headnode balancesthe load between the nodes in the network. Thislengthens the time until the first node runs out ofenergy. Yet, the time between the first and the lastnode running out of energy is minimal. As shownin Fig. 16, the lifetime of the network until half of

0

5

10

15

20

25

1 2 3 4 5 6 7 8 9 10


Net

wor

k lif

etim

e (h

)

No change, 20%Change, 20 %Change, 50 %No change, 50%

Fig. 16. TUTWSN lifetimes in different conditions.

the nodes are remaining is considerably longer whenthe headnode duty is circulated. Instead, with life-time consideration of 20% of nodes remaining, thenetwork longevity is better if the headnode is notchanged.

If a node operates as a subnode continuously,lifetimes are 5.2, 9.9, 21.2, and 34.2 h for 1, 2, 5,and 10 s access cycles respectively. The reason forthe short lifetimes is the extremely limited capacityof the capacitor being the energy storage at thenodes. For comparison, with a 1 cm3 non-recharge-able lithium battery, the obtained lifetimes for asubnode are 96, 182, 391, and 631 days for 1, 2, 5,and 10 s access cycles respectively [48].

6.3.3. Delay and throughput

Fig. 17a depicts the communication delays fordifferent number of hops from a source to the sinknode. The delays are measured after the clusteraccess cycle timings have been adapted and stabi-lized. For one and two second access cycles, thedelays are acceptable. For an environmental moni-

0

250

500

750

1000

1250

1 2 3 4 5 6 7 8 9 10Access cycle length (s)

HIn

InSu

Th

rou

gh

pu

t (bp

s)

Headnode, receivedIntercluster link, 4 slotsIntercluster link, 3 slotsIntercluster link, 2 slotsSubnode, sent

b

Fig. 17. TUTWSN: (a) packet delays to sink and (b)throughputs.


toring application, the delays are adequate evenwith the longer access cycle lengths. A per hop delayis quite independent of the distance from the sinknode but the nodes in which several data flows con-verge cause congestion.

Throughputs for a subnode and a headnode, aswell as for the active inter-cluster links with differentnumber of reservation data slots are depicted inFig. 17b. A subnode has one active uplink for theheadnode. The headnode throughput is its incomingthroughput. The number of the reservation dataslots for an inter-cluster link is varied between twoand four, depending on the available slots. Obvi-ously, the throughput decreases as the access cyclelength increases. This is acceptable, as the accesscycle length is typically adapted according to theapplication requirements.

6.3.4. TUTWSN adaptability

The adaptability of TUTWSN is evaluated bysimulating unexpected error situations. An unrecov-erable error is simulated at the cluster headnode.The times elapsed until the network is reconfiguredare depicted in Fig. 18 for the different access cyclelengths. The subnodes do not start the self-organiz-ing cluster creation algorithm immediately, as acluster beacon may be lost due to a packet error.Thus, the reconfiguration time depends on the limitof the missed cluster beacon back-off counter. Acase, in which the cluster headnode is able to informabout its state, is given as a reference.

As can be seen, the reconfiguration time is almostdirectly proportional to the access cycle length. Thereconfiguration delay is not considerable with theshort access cycles, whereas the delay is over halfa minute for the longer access cycles.

0

5

10

15

20

25

30

35

40

45

1 2 3 4 5 6 7 8 9 10Access cycle length (s)

Rec

onfig

urat

ion

time

(s)

4 AC Back-off3 AC Back-off2 AC Back-offInformed

Fig. 18. The reconfiguration times of TUTWSN on an unex-pected error situation.

6.4. ZigBee simulation results

The applicability of ZigBee to WSN applicationsis evaluated by simulating the ZigBee protocols withthe defined environmental monitoring application.In the simulations, the beacon order of ZigBeeMAC protocol is varied from 6 to 10, which resultsto the access cycles of 0.98, 1.97, 3.93, 7.86, and15.73 s. We refer these to as 1, 2, 4, 8, 16 s accesscycles for clarity. The superframe order is set to 2,thus the length of the active period consisting ofthe beacon and CAP is 61.44 ms.

6.4.1. Small scale ZigBee network

The prototype for ZigBee is modeled from thecomponents, the characteristics of which are mea-sured individually. Therefore, we do not comparethe simulated results to physical deployment mea-surements. For a fair comparison, we use the samestatically defined network configuration for ZigBee,which is presented for TUTWSN in Section 6.2. Theapplication in the ZigBee simulation is identical tothat of TUTWSN simulations.

The power consumption results from the ZigBeesimulations are depicted in Fig. 19. The differencebetween ZigBee device and coordinator power con-sumptions is considerably bigger than the same dif-ference between the corresponding TUTWSNnodes. This is caused by the active listening of thecomplete CAP, which is also the reason for the iden-tical results of both coordinators. Compared toTUTWSN, the power consumption of a device isaveragely two times and that of a coordinator aver-agely 3.5 times larger than the power consumptionof the corresponding TUTWSN node.

0

500

1000

1500

2000

2500

3000

3500

4000

4500

0 2 4 6 8 10 12 14 16


Pow

er (

μW)

Coordinator 2

Coordinator 1

Device 1

Fig. 19. The power consumption in a small scale ZigBeenetwork.

0

50

100

150

200

250

1 2 3 4 5 6 7 8 9 10

Hops from sink

Del

ay (

s)

AC 16 s

AC 8 sAC 4 s

AC 2 sAC 1 s

Fig. 21. ZigBee packet delays to the ZigBee coordinator.


6.4.2. Large scale network

In the large scale ZigBee simulations, a networkthat consists of 100 nodes is simulated. The size ofthe simulated network is restricted by the usage ofthe same communication channel throughout thenetwork. In dense networks, the distribution ofcoordinator superframes so that they do not overlapis problematic. In the simulations, 35 coordinatorcapable devices and 65 reduced function devicesare distributed randomly to a 60 · 60 m area. Dueto the congestion, the parameters of the environ-mental monitoring application are changed so thateach coordinator stores the temperatures receivedfrom the devices over two access cycles. The resultsare then aggregated to a single data packet, which isrouted towards the ZigBee coordinator.

The power consumptions of the different compo-nents in coordinators and devices are depicted inFig. 20a and b respectively. The access cycle lengthis varied between 1 and 16 s and the results are aver-

0

500

1000

1500

2000

2500

3000

3500

4000

4500

1 2 4 8 16


Pow

er (

μW)

Transceiver



0

50

100

150

200

250

1 2 4 8 16


Transceiver



Transceiver



Pow

er (

μW)

Transceiver



a

b

Fig. 20. The power consumptions of different components inZigBee: (a) coordinator and (b) device in a hundred-nodenetwork.

aged over five arbitrarily selected coordinators anddevices. The scale in Fig. 20a is 18 times larger thanin Fig. 20b. Compared to results presented inFig. 19, the power consumption of a coordinatoris quite similar, whereas in the case devices thepower consumption depicted in Fig. 20b is consider-able larger for longer access cycles. This is caused bythe network scanning, which is required for topol-ogy creation and reformation in case of errors. Anode scans for a complete access cycle when search-ing for a network.

In comparison to TUTWSN, the differences aresimilar to those presented in Section 6.4.1, exceptfor the device vs. subnode power consumption withlonger access cycles. While in TUTWSN the scan-ning times and the energy required for networkmaintenance diminishes as the access cycle lengthincreases, the effect is opposite in ZigBee. Further,the proportional share of the transceiver unit onthe power consumption is significantly larger in Zig-Bee than in TUTWSN.

The delays in data routing towards the ZigBeecoordinator with the different access cycle lengthsare depicted in Fig. 21. As in the case of TUTWSN,with 1 and 2 s access cycles the delays are moderate,but with the longer access cycles the delay becomesunacceptable. TUTWSN outperforms ZigBee in thiscase. The reason for this is that in ZigBee the starttimes of the access cycles are not delay optimizedas in TUTWSN.

7. Conclusions

The large design space of WSNs cannot be man-aged without a complete tool for the WSN design,configuration, and evaluation. This paper presents


WISENES, which is the first tool that supports thegraphical design, simulation, final implementation,and evaluation of WSNs within a single framework.The WISENES framework enables a modulardesign of WSN protocols and applications. Differ-ent platforms and protocols are evaluated in orderto obtain an optimal configuration for a specificapplication. The back-annotation of the measuredperformance information from physical node plat-forms improves the accuracy of the simulationresults.

The implementation of TUTWSN and ZigBeenetworks shows that the design of protocols andtheir performance evaluation in WISENES is fast.The graphical state machine based notation is expli-cit and designer friendly. The TUTWSN and ZigBeenetwork simulations prove the applicability andperformance of WISENES for the simulations oflarge networks. Further, the simulated performanceresults correspond to those of real physicalplatforms.

Our main future work is projected on the devel-opment of a more accurate sensing channel modeland mobility support. At the moment, the WISE-NES framework is not publicly available, but weare planning to open it as an online web-basedWSN design service. We are also considering opensource SDL tools for the design.

References

[1] I.F. Akyildiz, W. Su, Y. Sankarasubramaniam, E. Cayirci, Asurvey on sensor networks, IEEE Communications Maga-zine 40 (8) (2002) 102–114.

[2] J.A. Stankovic, T.F. Abdelzaher, L. Chengyang, S. Lui, J.C.Hou, Real-time communication and coordination in embed-ded sensor networks, Proceedings of the IEEE 91 (2003)1002–1022.

[3] SDL Forum Society Homepage, http://www.sdl-forum.org/,visited in November 2005.

[4] M. Kohvakka, M. Hannikainen, T.D. Hamalainen, Ultra lowenergy wireless temperature sensor network implementation,in Proc. 16th annual IEEE Int. Symp. on Personal Indoor andMobile Radio Communications, 2005, pp. 187–200.

[5] ZigBee Specification, http://www.zigbee.org/, visited inOctober 2005.

[6] The Network Simulator – ns-2, http://www.isi.edu/nsnam/ns/, visited in November 2005.

[7] X. Zeng, R. Bagrodia, M. Gerla, GloMoSim: a library forparallel simulation of large-scale wireless networks, in: Proc.12th Workshop on Parallel and Distributed Simulations,1998, pp. 154–161.

[8] Qualnet Network Simulator, http://www.qualnet.com/, vis-ited in November 2005.

[9] OPNET Modeler,http://www.opnet.com/products/modeler/home.html, visited in November 2005.

[10] OMNeT++ Community Site, http://www.omnetpp.org/index.php, visited in November 2005.

[11] Scalable Simulation Framework, http://www.ssfnet.org/,visited in November 2005.

[12] J-Sim Homepage, http://www.j-sim.org/, visited in Novem-ber 2005.

[13] S. Park, A. Savvides, M.B. Srivastava, Simulating networksof wireless sensors, Proc. Winter Simulation Conference2001 (2001) 1330–1338.

[14] I. Downard, Simulating sensor networks in ns-2, http://pf.itd.nrl.navy.mil/nrlsensorsim/, visited in November 2005.

[15] sQualnet: A Scalable Simulation Framework for SensorNetworks website, http://nesl.ee.ucla.edu/projects/squalnet/,visited in November 2005.

[16] J. Liu, L.F. Perrone, D.M. Nicol, M. Liljenstam, Simulationmodeling of large-scale ad-hoc sensor networks, in: Proc.2001 Simulation Interoperability Workshop, (2001).

[17] C. Mallanda, A. Suri, V. Kunchakarra, S.S. Iyengar, R.Kannan, A. Durresi, S. Sastry, Simulating wireless sensornetworks with omnet++, http://csc.lsu.edu/sensor_web/sim-ulator.html, visited in November 2005.

[18] S. Dulman, P. Havinga, A simulation template for wirelesssensor networks, IEEE Int. Symp. on Autonomous Decen-tralized Systems, 2003, fast abstract.

[19] A. Sobeih, W.-P. Chen, J.C. Hou, L.-C. Kung, N. Li, H.Lim, H.-Y. Tyan, H. Zhang, J-Sim: A Simulation andEmulation Environment for Wireless Sensor Networks,http://www.j-sim.org/, visited in November 2005.

[20] P. Baldwin, S. Kohli, E.A. Lee, X. Liu, Y. Zhao Modeling ofsensor nets in ptolemy II, in: Proc. 3rd Int. Symp. onInformation Processing in Sensor Networks, 2004, pp. 359–368.

[21] Ptolemy II, http://ptolemy.eecs.berkeley.edu/ptolemyII/, vis-ited in November 2005.

[22] G. Simon, P. Volgyesi, M. Maroti, A. Ledeczi, Simulation-based optimization of communication protocols for large-scale wireless sensor networks, Proc. IEEE 2003 AerospaceConference 3 (2003) 1339–1346.

[23] B.C. Mochocki, G.R. Madey, H-MAS: a heterogeneous,mobile, ad-hoc sensor network simulation environment, in:Proc. 7th Annual Swarm Users/Researchers Conference,2003.

[24] G. Chen, J. Branch, M.J. Pflug, L. Zhu, B. Szymanski,SENSE: A sensor network simulator, http://www.cs.rpi.edu/~cheng3/sense/, visited in October 2005.

[25] A. Boulis, C.C. Han, M.B. Srivastava, Design and imple-mentation of a framework for efficient and programmablesensor networks, in: Proc. 1st Int. Conf. on Mobile Systems,Applications, and Services, 2003, pp. 801–805.

[26] Crossbow Technology, http://www.xbow.com/, visited inNovember 2005.

[27] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, K.Pister, System architecture directions for networked sen-sors, Proc. 9th ACM Int. Conf. on Architectural Supportfor Programming Languages and Operating Systems (2000)94–103.

[28] P. Levis, N. Lee, M. Welsh, D. Culler, TOSSIM: accurateand scalable simulation of entire TinyOS applications, Proc.1st ACM Conf. on Embedded Networked Sensor Systems(2003) 126–137.

[29] M. Karir, J. Polley, D. Blazakis, J. McGee, D. Rusk, J.S.Baras, ATEMU: a fine-grained sensor network simulator, in

http://www.sdl-forum.org/

http://www.zigbee.org/

http://www.isi.edu/nsnam/ns/

http://www.isi.edu/nsnam/ns/

http://www.qualnet.com/

http://www.opnet.com/products/modeler/home.html

http://www.opnet.com/products/modeler/home.html

http://www.omnetpp.org/index.php

http://www.omnetpp.org/index.php

http://www.ssfnet.org/

http://www.j-sim.org/

http://pf.itd.nrl.navy.mil/nrlsensorsim/

http://pf.itd.nrl.navy.mil/nrlsensorsim/

http://nesl.ee.ucla.edu/projects/squalnet/

http://csc.lsu.edu/sensor_web/simulator.html

http://csc.lsu.edu/sensor_web/simulator.html

http://www.j-sim.org/

http://ptolemy.eecs.berkeley.edu/ptolemyII/

http://www.cs.rpi.edu/~cheng3/sense/

http://www.cs.rpi.edu/~cheng3/sense/

http://www.xbow.com/

Marko Hannikainen (M.Sc.’98, Ph.D.’02,TUT) acted as a research scientist and aproject supervisor at the Institute ofDigital and Computer Systems at TUTin 1998–2007, and was nominated toprofessor in 2007. He co-directs theDACI research group, concentrating onwireless sensor networks, high abstrac-


Proc. 1st IEEE Int. Conf. on Sensor and Ad Hoc Commu-nication Networks, 2004.

[30] L.F. Perrone, D.M. Nicol, A scalable simulator for TinyOSapplications, Proc. Winter Simulation Conference 2002(2002) 679–687.

[31] S. Sundresh, K. Wooyoung, A. Gul, SENS: a sensor,environment and network simulator, in: Proc. 37th AnnualSimulation Symposium, 2004, pp. 221–228.

[32] L. Girod, J. Elson, A. Cerpa, T. Stathopoulos, N. Rama-nathan, D. Estrin, Em*: a software environment for devel-oping and deploying wireless sensor networks, CENSTechnical Report 0034, 2003. http://research.cens.ucla.edu/,visited in November 2005.

[33] C. Kelly IV, V. Ekanayake, R. Manohar, SNAP: a sensornetwork asynchronous processor, Proc. 9th Int. Symp. onAsynchronous Circuits and Systems (2003) 24–35.

[34] M. Kuorilehto, M. Kohvakka, M. Hannikainen, T.D.Hamalainen, High level design and implementation frame-work for wireless sensor networks, in: Proc. EmbeddedComputer Systems: Architectures, Modeling, and Simula-tion, 2005, pp. 384–393.

[35] Evaluation of J-Sim, http://www.j-sim.org/comparison.html,visited in November 2005.

[36] VisualSense Homepage, http://ptolemy.eecs.berkeley.edu/visualsense/, visited in November 2005.

[37] Getting Started with the EmStar Simulator, http://cvs.cen-s.ucla.edu/emstar/tut/emsim.html, visited in November2005.

[38] W. Stallings, Data and Computer Communications, sixthed., Prentice-Hall, 2001.

[39] The swing tutorial, http://java.sun.com/docs/books/tutorial/uiswing/, visited in August 2005.

[40] Telelogic Homepage, http://www.telelogic.com/corp/, vis-ited in September 2005.

[41] Telelogic TAU SDL Suite, http://www.telelogic.com/corp/products/tau/sdl/index.cfm, visited in September 2005.

[42] Specification and description language (SDL), ITU-T Rec-ommendation Z.100, http://www.itu.int/ITU-T/study-groups/com17/languages/, visited in June 2006.

[43] XE88LC02 Sensing Machine, Data Sheet, http://www.xemics.com/, visited in September 2005.

[44] Nordic VLSI nRF2401, Data Sheet, ver 1.0, http://www.nvlsi.no/, visited in September 2004.

[45] Wireless Medium Access Control (MAC) and Physical Layer(PHY) Specifications for Low-Rate Wireless Personal AreaNetworks (LR-WPANs), IEEE Standard 802.15.4, 2003.

[46] PIC18 Data Sheet, http://www.microchip.com/, visited inOctober 2005.

[47] Chipcon CC2420 Data Sheet, http://www.chipcon.com/,visited in October 2005.

[48] S. Roundy, P.K. Wright, J. Rabaey, A study of low levelvibrations as a power source for wireless sensor nodes,Elsevier Computer Communications 26 (11) (2003) 1131–1144.

Mauri Kuorilehto (M.Sc.’01, TUT)received the M.Sc. in Computer Sciencefrom Tampere University of Technology(TUT), Finland. He is currently pursuinghis Ph.D. in the Institute of Digital andComputer Systems at TUT. His researchinterests include network simulation,operating systems, and application dis-tribution in wireless sensor and ad hocnetworks.

tion design tools, and novel web

Timo D. Hamalainen (M.Sc. ’93,Ph.D.’97, TUT) acted as a seniorresearch scientist and project manager atTUT in 1997–2001. He was nominatedto full professor at TUT/Institute ofDigital and Computer Systems in 2001.He heads the DACI research group thatfocuses on three main lines: wireless localarea networking and wireless sensornetworks, high-performance DSP/HWbased video encoding, and interconnec-

tion networks with design flow tools for heterogeneous SoCplatforms.

applications.

http://research.cens.ucla.edu/

http://www.j-sim.org/comparison.html

http://ptolemy.eecs.berkeley.edu/visualsense/

http://ptolemy.eecs.berkeley.edu/visualsense/

http://cvs.cens.ucla.edu/emstar/tut/emsim.html

http://cvs.cens.ucla.edu/emstar/tut/emsim.html

http://java.sun.com/docs/books/tutorial/uiswing/

http://java.sun.com/docs/books/tutorial/uiswing/

http://www.telelogic.com/corp/

http://www.telelogic.com/corp/products/tau/sdl/index.cfm

http://www.telelogic.com/corp/products/tau/sdl/index.cfm

http://www.itu.int/ITU-T/studygroups/com17/languages/

http://www.itu.int/ITU-T/studygroups/com17/languages/

http://www.xemics.com/

http://www.xemics.com/

http://www.nvlsi.no/

http://www.nvlsi.no/

http://www.microchip.com/

http://www.chipcon.com/

rapid design and evaluation framework for wireless sensor networks · 2009. 7. 21. · tossim and...

Documents