A Simulation Framework for Energy-Aware Wireless Sensor Network Protocols

Adrian F. Kacs o
University of Siegen 57068 Siegen, Germany Email: adrian.kacso@uni-siegen.de

Roland Wism uller

University of Siegen 57068 Siegen, Germany Email: roland.wismueller@uni-siegen.de

AbstractWe discuss a modular simulation framework to investigate the energy efciency of different routing protocols used in resource constrained wireless sensor networks. Our simulation framework provides a exible tool to build diverse protocols by combining existing building blocks at different layers and to analyse how several factors such as routing strategies, MAC protocols, link and node failures, energy on path, network topology changes, in-network processing, scheduling at MAC layer and other adjustable conguration parameters inuence the energy efciency of the protocol. The simulator extends the open source OMNeT++ and its Mobility Framework and provides a framework to rapidly develop, to experiment with and to evaluate efciently routing protocols; the quantitative effort to design new routing protocols and to integrate them into a complete protocol stack is considerably reduced. Moreover, we develop complete modules for MAC and network protocols; in order to study and evaluate the behavior and lifetime of the network we implement independent energy and statistics modules. We provide also new features such as add/delete, move, dis/reconnect nodes during simulation, which allow to analyse the impact of dynamic topology changes. Index Termsenergy-aware, simulation, WSN protocols

We rst need energy-aware routing protocols which should take into account new metrics based on a sensor nodes residual energy or other attributes to be able to take appropriate routing decisions in order to extend the lifetime of the WSN. Moreover, for a resource constrained sensor node it is very important that also the protocol stack operates efciently and all the layers making up the protocol stack are optimized toward the specic requirements of the application running on top of it. In particular, the energy consumption must be optimized at each layer and the cooperation between layers should be improved. In order to achieve this, we proposed in [1] a modular, energy-aware network stack architecture of a sensor node as a exible approach to design and plug-andplay various protocols at network and MAC layers, and to combine and analyse the impact of different strategies (inside the protocols) on performance and lifetime of the WSN. A. Motivation and objectives A WSN achieves the requirements of the application running on top of it (i.e. monitors the environment) as long as its constituent nodes are operating correctly. A node with depleted battery is not able to communicate and therefore it is useless for the network. Our main goal is to prolong the network lifetime by conserving the energy of the nodes as long as possible. The behavior of the nodes between source(s) and sink(s) depends on several factors such as the network topology and connectivity, the number of active requests in the network, the position of source(s) and sink(s), communication pattern, MAC protocol parameters (e.g. listen and sleep times), application parameters (e.g. interest refresh rate) and so on. The cumulated impact of such a large amount of parameters on the behavior of individual nodes is difcult to predict. What we need is a platform that allows us to rapidly develop, to experiment with and to evaluate routing protocols. It should reduce the quantitative effort to design new routing protocols and to integrate them into a complete protocol stack by providing exibility in conguration. Additionally, when the platform is used in a simulation environment, it should automatically visualize performance criteria to enable a fast evaluation and comparison of routing protocols. Our designed platform achieves these goals. To that aim we extend the public-source OMNeT++ 3.4b2 discrete event

I. I NTRODUCTION A wireless sensor network (WSN) consists of a large number of sensor nodes that are randomly and densely deployed in a geographical area. Each of the distributed nodes in the WSN is able to collect large amounts of information, analyse and/or preprocess them and communicate them to a base node (sink). The nodes operate unattended and are forced to selforganize themselves as a result of frequent topology changes and to adjust their behavior to current network conditions. Typically, a sensor node has restricted communication (radio range) and computation capabilities, limited energy and memory. A very challenging aspect in WSNs is to determine the way the query and data messages are forwarded between the sink and the locations where sensor nodes, called sources, may deliver the requested data. When the distance between source(s) and sink is large, intermediate nodes forward the messages from hop to hop until they reach the destination, leading to several possible multihop paths. Determining which set of nodes to select in order to create a path between the communicating sensor nodes is the main task of a routing algorithm. Routing in large WSNs is not trivial and must address multiple design requirements including scalability, reliability and energy efciency.

978-1-4244-4581-3/09/$25.00 2009 IEEE

simulation package1 and its MF 2.0p3. B. Approach to structure a communication protocol The common approach to structure a communication protocol is layering; separate protocols are building the protocol stack where each protocol accesses functions of the lower layer protocol. Since for a resource constrained node strict layering is inappropriate [2], [3], we employ a partial crosslayer design (see also [4]) by allowing exchange of information mainly across application, routing and MAC layers in order to optimize them. For example, such optimization can improve the energy consumption during communication, extend the spectrum of routing decisions and adapt the communication to tolerate different kinds of failures or to avoid local congestion. Our architecture adds a cross layer to the OSI protocol stack model and is illustrated in Fig.1a. II. T HE PROTOCOL STACK The OMNeT++ (and MF) offers support to build a complete protocol stack to simulate a wireless sensor network. More precisely, it provides basic modules that can be inherited in order to implement own modules at each layer of the protocol stack, it models a wireless channel with dynamic connection management and attaches location information to each node. In our simulator (see Fig.1b) we provided full implementations for the application, network and MAC layer, we extended the mobility component and added a energy and statistics module.
Application Layer
(Transport Layer)

In our simulator everything below the network layer is part of the NIC module (see Fig.1.b) which contains three main components: the MAC module containing the MAC protocol, the PHY and the radio modules that model/simulate the hardware. Using this decomposition of modules at the NIC layer we have exibility in design and code reusability. One can embed on one side some own designed MAC protocols and on the other side already existent (popular) MAC protocols. To the best of our knowledge, so far there are no implementations for different MAC protocols (except a rst attempt of the IEEE 802.11 WLAN) which can be embedded in the OMNeT++ protocol stack. We provide complete NIC modules implementing S-MAC, Preamble Sampling, T-MAC, and the IEEE 802.11 WLAN standard that can be used below a network layer routing protocol. Moreover, we provide several working implementation of different routing protocols (including Directed Diffusion [5] and variants of it) using our network layer architecture (see [1]). The existence of the blackboard component (module) allows cross-layer interactions between the layers. The energy and statistics components are described in II-A3 and II-A4, respectively. A. Design and implementation Since we model energy-aware protocols we need to make a small detour in order to explain where the energy is consumed. Each sensor node has at startup a given energy reserve, which decreases according to the operations the node is involved into. The main consumer is the transceiver which works either as a receiver or as a transmitter and each sensor. Nowadays transceivers have at least four modes of operation: send, receive, idle and sleep. The idle mode means that the receiver is ready to receive, but the wireless channel is free. The energy consumptions varies according to the four modes. As a general rule, one can consider that transmission and reception costs are similar, idle cost is lower but often reaches the receptions cost and sleeping cost is almost neglected. To accommodate a low energy consumption, the main idea is to turn off the transceiver most of the time and to activate it only when necessary, meaning that the transceiver works at a low duty cycle. 1) Network layer: The network layer is the main component of our architecture and connects all other layers together; its architecture is illustrated in Fig.2. The network layer consists of three components: the in-out unit (IOU), the forwarding unit (FU) and several routing units (RUs). The main task of IOU is to guide the packet ow inside the protocol stack. The FU forwards the packets to the appropriate RU according to the packet type and the direction they are coming from. It also maintains and provides access to internal cache structures (Neighbor Table, Interest Table,etc). The RU is a dynamically exchangeable component implementing (part of) the routing protocol with the main task to forward packets by determining their next hops. The SU is an optional component inside the RU with the aim to modularly separate the policy

Cross Layer

Network Layer Data Link Layer MAC Layer Physical Layer

(Telos, MicaZ, Mica/Mica2, Dot)

(802.11,SMAC,TMAC,BMAC)

a)

b)

Fig. 1.

a) Node architecture and b) its components in our simulator.

The application layer provides the user a way to send his request to the network. In a data-centric approach, a request or interest is a sequence of attribute-value pairs such as type=temperature, interval=100ms, area=[(x,y),(u,v)] which is converted to an application packet. The application layer contains also the sensing unit of a sensor node and sends responses or data events. Upon receiving a request, the application layer checks if it is a source of the requested data; if yes, it starts the requested sensor to gather the data and packs it in a response message to be sent to the request initiator (the sink). In WSNs the network layer provides a (best-effort) connectionless multihop communication abstraction to the upper layers. Typically, its functionality has to include packet forwarding towards one or many destinations, creation and maintenance of routing structures, retransmissions and acknowledgments. The data link layer main component, the MAC layer, is responsible to control the access to the shared communication channel, while the remaining parts of the DLL are mainly responsible for synchronization, error control and ow control.
1 see

http://www.omnetpp.org/, http://mobility-fw.sourceforge.net

of determining the next hops for packets inside the routing protocol. See [1] for more details.
Application Layer
upperIn upperOut
ruIn ruOut

Routing Protocol (code)

fromLower fromUpper

Routing Unit
toUpper

Strategy Unit
getNext() getAllNext()
toLower

toUpper fromUpper inspectHeader localComputation manageNeighbor fwd to RU ackf mtype

Interface RUFU
register, manageTableEntries, get/setEntryFields, manageRUs ...

Cross Layer

fromLower

Interest Table
...

ACK

IO Unit
FUCR
Neighbor Table
nID avgRcvT

manageRetransmissions
sendACK resend

ResendList

...

energy

...

yes

lowerOut

toLower

updateHeader

ackf

Forwarding Unit
Network Layer
message flow cache updates function call

Link Layer

Fig. 2.

Interaction of the components at network layer.

Here we restrict ourselves to present two routing protocols that we implemented at the network layer. a) The rst one is an adaptive energy-aware routing protocol based on two phases: the interest propagation and the data event gathering. The goal of the protocol is to balance the load of forwarding the data packets on all the nodes by selecting different routing strategies. The rst strategy was to route the data packets on the shortest path between source and sink (hop count metrics). The second strategy combines the hop count metrics with the neighbor residual energy. The third metrics uses instead of residual energy E (of a node) the critical energy (cE ), i.e. the least residual energy on the path between the sink and source. Each node u computes cEu = min{Eu , max{cEv |v N eighbor(u)}}. Additionally, each node piggybacks its local residual energy to each packet sent by the node. Finally, each node forwards the data packet taking into account rst the hop count and then the critical energy (where the weight of each factor is adjustable). b) The second protocol illustrates an extension of the Directed Diffusion protocol [5] with GEAR [6]. The implementation is split in ve routing units (RUs), each of them implementing one phase of the protocol, namely: interest propagation, gradient setup, reinforcement, data event gathering and aggregation. The intention is to illustrate the impact on energy consumption resulted by exchanging different RUs. We exchanged, for example, for the rst phase the ooding RU with a geographic ooding RU and for the third phase the strategy used at reinforcement. Instead of reinforcing the fastest neighbor that delivered the data event we chose the neighbor with the most residual energy able to deliver it. 2) MAC layer: The most important component of the data link layer (the NIC in our simulator, see Fig.1b) is the Medium Access Control (MAC) which regulates the access of a set of sensor nodes to the shared communication medium in such a way that some application dependent performance requirements are satised. As we emphasized, the wireless radio communication is error prone, has limited range and consumes

a lot of energy. These characteristics force a cooperation between the sensor nodes to relay information, which heavily impacts on the lifetime of the unattended sensor network. Therefore, a MAC protocol must be rst of all energy efcient. This can be achieved by reducing potential energy wastes such as idle listening, collisions, overhearing, overemitting and protocol overhead [7], [8], [9], [10]. Avoiding idle listening can be achieved by using a periodic wakeup scheme or an active-sleep regime. Following a local managed schedule each node wakes up periodically and listen to see if some neighbor wants to communicate with it. The amount of energy savings depends on the ratio between the listen and frame period dened as the duty cycle. A low duty cycle improves the energy efciency on one side, but on the other side induces a latency per node, since a sender needs in average half of the sleep time before the receiver is ready. Usually MAC protocols achieve a tradeoff between energy efciency and latency. We describe here only one of our implemented MAC protocol, namely the T-MAC. We illustrate the protocol using state (transition) diagrams. Timeout-MAC (T-MAC) was proposed in [7] to enhance the limitation of S-MAC protocol [8] (its static listen-sleep regime) under variable trafc loads.
Frame Active Sleep TA TA Sleep TA

lowerIn

Fig. 3.

T-MAC adaptive duty cycle.

The active listening period has to be long enough to handle situations with highest communication demand but in other cases it wastes the time in idle listening. T-MAC introduces an adaptive duty cycle, which dynamically ends the active listen period. Similar to S-MAC, a node periodically wakes up to communicate with its neighbors, and then goes to sleep again until the next frame. As illustrated in the Fig. 3 the basic idea of T-MAC protocol is to transmit all messages in bursts of variable length at the beginning of a xed length frame. Since nodes can communicate only during the listen periods, T-MAC needs to coordinate the schedules of neighbor nodes such that their listen periods start at the same time. The coordination action is aimed to spread the schedules and to keep them synchronized. To synchronize the listen-sleep regime, each sensor node starts a random timer and all sensor are listening for a given time. During this time the node is in Startup state. The sensor node which timer expires rst (synchronizer) broadcasts a SYNC packet to all its neighbors. The SYNC packet describes its own schedule, i.e. when the node goes to sleep. Neighbors within the range of the synchronizer, without an own schedule, adopt the same schedule, adjust their timers correspondingly and broadcast the schedule in one of the neighbors next listen periods. A neighbor node following the schedule of a synchronizer (follower) keeps the schedule even if it later hears another synchronizer. Fig.4 illustrates the formation of two virtual schedule clusters under the assumption that two sensor nodes act as synchronizers. Nodes adopting the rst schedule are drawn as squares and form the virtual cluster A (consisting of the upper two circles). Nodes adopting the second schedule are

drawn as circles and form the second virtual cluster B. The process of announcing both schedules spreads like a wave into all directions. It ends either if the listen period has expired or if the packet reaches a node that has adopted a schedule propagated by another synchronizer. Nodes that have already adopted a schedule, referred as border nodes, do not distribute another schedule further; they would bridge the communication between neighbor clusters.
Synchronizer 1 communication Border node A schedule

Cluster A

Border node B schedule

Cluster B
Synchronizer 2

Fig. 4.

Distributing synchronized schedules.

In order to ensure the communication outside the cluster we proceed as follows: nodes that received the rst SYNC packet will stay awake (state Active Startup in Fig.5) for a further frame time to be able to receive further possible SYNC packets. Each new incoming schedule will be adopted as a foreign schedule. At the end of the Active Startup state the node is synchronized and switches into Active-Sleep regime as shown in Fig.5.a.
Synchronisation Phase

We increase the efciency of broadcasting by restricting the transmission of broadcast frames. The idea: if a node already detected activity on the channel (either sent or received a frame) during its rst listen timeout it can conclude that all its neighbors have extended their active period and thus they are still reachable for a next listen period. Therefore, in this case, sending a broadcast frame is safe. A node that didnt sent any message during a listen period and continues to stay awake is not allowed to broadcast any messages of itself, since it cannot be guaranteed that all his neighbors are also awake. This improves the reliability for broadcasted frames. We give priority at send by establishing an adaptive maximal contention time. Recall that before each transmission a node rst listen the shared medium for a given time, referred as contention time, to detect ongoing transmissions. Nodes having their queues more that half full should listen the medium for a shorter time and thus would get a half long contention time. The T-MAC header is kept small and illustrated below

Startup
<entry>

Active Foreign
<entry>

Own Timeout

Listen Timeout

Idle
RTS not for me <entry> | FRTS

has DATA to send

Send RTS
<exit>

lose contention

setSyncTimeout()
<exit>

setRadioListen() kickFrameActive() Foreign Timeout Listen Timeout

Nodes not involved in the communication set their Network Allocation Vector (NAV), defer own transmissions and switch off their radio for that time. The T-MAC uses the blackboard component to exchange information with the radio and the physical layer in order to get/set the state of the radio and to detect when the medium is free. Moreover, it is informed by the energy module when the residual energy of the node reaches some threshold precongured at simulator startup. All our implemented MAC protocols are embedded in complete nic modules in order to be easily incorporated in the protocol stack. 3) The Energy component: Since we model energy-aware protocols we need a way to model the energy consumption on a sensor node. The energy component models the energy consumed by a given radio and the energy consumed by the controller to process the packet. We assume that each node has at startup a given congurable (known) energy reserve, which decreases according to the operations the node is involved into. The energy module simulates the real energy consumption of each sensor node and exposes other components an interface focused on energy computation and notication methods. Nowadays there exist several models for the energy consumption per bit with different accuracy and level of detail [13], [14], etc. For the following description let us assume that the energy consumption during transmission and reception is modeled as in [14] (pp.40). The energy consumed at transmission depends on the ampliers power, PAmp , and on the power consumed by the electronic components (VCO, lters, etc.), PT xElec . The power of the amplier depends on the hardware, but for most of them it depends on the desired transmission power, PT x . A realistic model assumes that PAmp can be computed as the

setRadioListen()
RTS for me Lose contention

Wait
<exit> setIdle()

win contention:

sendRTS()
win contention

SyncTimeout: sendSync() adoptOwnSchedule() Sync received: adoptSchedule() SyncTimeout | Sync received

CTS and has DATA

Timeout

Wait for CTS

<entry> setRadioListen()

receive other

Sleep
<entry>

Send FRTS
<exit> sendFRTS()

Send CTS
<exit>

CTS

setRadioSleep()
<exit>

win contention:

sendCTS()
win contention

Send DS
<exit>

setNextSchedule() Listen Timeout Own Timeout Own Timeout

lose contention

win contention:

Active Startup
<entry>

NAV Sleep
<entry> setRadioSleep()

Timeout

Wait for DATA

<entry> setRadioListen()

sendDS() Timeout
win contention

setNextSchedule()
<do>

Active Own
<entry>

Send DATA
<exit>

Sync received: adoptForeignSchedule()

<exit>

setRadioListen() kickFrameActive() ActiveSleep Regime

receive DATA

sendDATA()

Send ACK
<entry>

setNextSchedule()

Timeout

Wait for ACK

<entry> setRadioListen()

win contention:

Receiver

sendACK()

Sender

Fig. 5.

T-MAC: a) Main states. b) State diagram for Active Own

In the state Active Own the node has its own schedule during which it can receive and transmit. The protocol states for a unicast communication are illustrated in Fig.5.b. The above states are almost self-explanatory and are common to RTS/CTS handshake mechanism (see [11], [12]). The reason to send data packets using the Request-To-Send (RTS) and Clear-To-Send (CTS) control packets is to reduce collisions when two (or more) nodes transmit near the same time (hidden-station problem). This handshake mechanism is useful when the data packets are long since if the packets collide, they are discarded, the energy is wasted and a later retransmission requires additional energy consumption both at sender and receiver. Broadcast packets are never sent using the RTS/CTS handshake and are not acknowledged (using ACK packets). In case of Active Foreign the node is in active state of a foreign schedule, where it can only receive. Therefore, the state transitions are the same as in the left side of Fig.5.b. The Future-Request-To-Send (FRTS) packet is an extension to avoid the early sleeping problem described in [7]. We conclude this section with some adjustments and improvements made in our implementation of the original TMAC protocol.

sum of a certain constant power independent of the radiated power and a proportional offset as PAmp = amp + amp PT x where amp and amp are constants depending on the amplier hardware (see [14]). The required PT x depends on several factors such as the energy per bit to noise ratio (Eb /N0 ), the target distance, the path loss coefcient, bandwidth efciency, etc. We can assume that the transmission power PT x is known. Generally speaking, the energy consumed by the transceiver in an operation is computed as E = P t, where P is the power and t the time spent in that operation. Thus, the energy ET x to transmit a packet of n bits long with a bit rate, R, is computed as n ET x = tst Pst + (PT xElec + amp + amp PT x ) (1) R where an initial startup energy tst Pst is required (to allow the VCO and phase-locked loops to settle) if the radio has to be turned on. The energy consumption during reception can be modeled in a similar way. During the time of the reception the receiver circuitry has to be powered up requiring a power of PRxElec and an initial startup energy if the receiver had been turned off. The energy to receive a packet of n bits long is given by equation n (2) ERx = tst Pst + PRxElec R Using equations (1) and (2) the energy module is able to compute the energy consumption for both sending and receiving. Note that the energy consumption is computed according to the state of the radio, the amount of bytes communicated and n in equations (1) and (2) the bit rate. Observe that the factor R is exactly the time spent in the corresponding operation, Top . If the energy module is notied at each radio state transition, the energy component is able to determine automatically the energy consumption during an operation without using n and R. To achieve the necessary information exchange we use again the publish-subscribe concept implemented by the blackboard component of the simulator. In this way, the energy module is informed at each state change (including switch states) of the radio, it computes automatically the energy consumed during the last operation and informs subscriber components when the energy of the node reaches some threshold values precongured at simulator startup. Computation of Top : Assume that a node follows the sequence of operations as illustrated in Fig.6. Each time the radio changes its state it transits into a switch state. The switch times are considered not null except the switch time from idle-receive to receive state and viceversa.
SW_RXR time SW_S Top = Tend Tst SW_R Idle Rcv Receive Send Sleep SW_SL SW_R SW_RXR SW_S SW_SL Switch Switch Switch Switch to to to to RECV (Idle) RECV SEND SLEEP

time (Tend ) and the last and actual state of the radio. At each transition from the last state to the current state, the energy module updates the Tend to the current time and substracts Tst to get the Top which is used to compute the energy consumed during the last nished operation. For example, in case of the send operation illustrated in Fig.6, the available residual energy, avE , of the node is updated by subtracting the transmission energy (according to equation (1)) and an internal energy (proportional to the packet size) needed by the Controller to process the sending packet. So far, PSIntern , representing the power to preprocess the packet before sending it effectively, was considered a (constant) conguration parameter. Of course, this parameter can be chosen such as to model more thoroughly the energy behavior of the Controller. In a similar way the residual energy of the node is adjusted at each transition of the radio assuming that the power in the idle mode, PRxIdle , and the power in sleep mode, PSleep , are known; and the power to change the state is bounded by PRxIdle . The energy component noties other components (for example, the network layer) when the energy of the node reaches some threshold values, and updates the Tst time for the next operation. If the battery of the node is depleted, the dischargedTime is recorded and the node appearance in the GUI is changed (for example, the nodes icon is changed and/or the node is disconnected from its neighbors or it is deleted from the network see III). Since the energy computation is hardware dependent a lot of parameters (transmission power, electronic power, startup times, currents, switch times etc.) are completely congurable at startup using an initialization le. 4) The Statistics component: Moreover, to be able to automatically analyse the performance criteria of the implemented routing protocols we need an additional component able to collect important statistical information (statistical data), such as residual energy of nodes and their depleting time, (average) number of collisions per node, min/max latency in a node and between source and sink, etc. The statistics component provides the functionality to record statistical data at each layer of the protocol stack in the precongured (scalar and vector) les. In order to parse huge data les, to lter some nodes (especially for large sensor networks) and to plot these performance statistics a script le was written. The script le calls the gnuplot program and create a pdf le with the selected statistical data. III. N EW F EATURES IN SIMULATOR In order to create a simulation network it is necessary to dene in the conguration le the node coordinates either by assigning a xed position or by leaving the simulator to place it automatically (random position). One starts to place some nodes at desired places and allows the remaining of nodes to be placed automatically. In this way one has a minimal guarantee that the network is connected. Even then, the randomly placed nodes of the resulted network may be not uniformly distributed, i.e., some parts of the network are

T st last state

T end actual state

. P avE = avE E T Tx op SIntern

Fig. 6.

Computation of the available energy using Top .

The energy component has to record four variables, two times and two states: the operation start time (Tst ) and end

more densely deployed than other. If the achieved network connectivity is not appropriate, one needs to move some nodes from a dense part or to add new nodes into the network. For such cases, a drag-and-drop facility in the simulation window saves a lot of time to position the nodes in the eld. In the sequel we discuss a possibility to implement this useful feature. Additionally, following the same mechanism new features such as node creation, deletion and disconnection/reconnection can be implemented. In all these features the user interaction with the GUI of the simulator generates an event that is caught by the OMNeT++ code inside the Tcl/Tk graphical interface. The OMNeT++ code redirects the events parameters (the node new coordinates) to the Mobility Framework since the corresponding action (the movement of the node and the topology redrawing) is implemented in the MF code. The challenge is to create no (additional) dependency from OMNeT++ code to MF code. In other words, the OMNeT++ code cannot directly call MF code, since than it will create an unwanted dependency to MF. This interaction between OMNeT++ code to MF code must be implemented. First we dene some special keys, buttons and submenus. In order to move a node we dene a special key combination to trigger the movement of the node. To create a new node we add a button and to delete, to dis/re-connect a node we dene a pop-up submenu when a given node is selected. Moreover, it turned out to be quite useful to integrate a further facility; the userFunction which can be mapped to any utility function related to a node. For example, during runtime one can call the function to display the actual contents of the internal tables (see II-A1) of a certain node. To implement the features we need to embed our code inside TCL/TK functions gathering the user input in the GUI simulator. Each control has a corresponding TCL/TK procedure that will be executed when the control is selected. Every such procedure has a corresponding C-function in the OMNeT++ code, that must be implemented to call a function in the MF code. Since we dont want to create a dependency from OMNeT++ to the mobility code, a convenient solution is to use an observer pattern, which allows the OMNeT++ code to register several observers interested in our GUI events. Thus, we dene an Observer interface which declares the virtual action method2 as follows:
class Observer { public: virtual void action( oppObservers *opp, ActionPar param)=0; };

The OMNeT++ code part contains in its oppObs object a list of observers3 (obsList) and provides three methods to attach, detach and notify observers. Now the C-function to move a node (which correspond to the TCL/TK opp movehost method) is implemented by
int movehost_cmd( ..., int argc, const char **argv) {s cModule *mod=dynamic_cast<cModule *> strToPtr(argv[1]); xpos = atoi( argv[2]); ypos = atoi( argv[3]); ActionPar aPar={ "move", mod, xpos, ypos}; oppObs.notify( aPar); ... }

The last argument of the function (argv), contains the string representation of the module pointer and the two new coordinates of the node. This parameters are converted and given as argument to the observers notify method. Similar functions exist for the remaining features. To complete the picture, we need in Mobility code a class that implements the Observer interface. The candidate is an own MyChCo class which inherits both the original ChannelControl class and the new Observer interface.
class MyChCo: public ChannelControl, Observer { public: virtual void initialize(); virtual void action( oppObservers *opp, ActionPar param); // functions for all actions: new, move, delete ... void newHostModule(); mymove( newx, newy); ... }

The derived class must register its observer at initialization and it provides an implementation for the action method for move, create, delete, disconnect, reconnect module and user function as illustrated in the pseudocode
void MyChCo::action(oppObservers *ob, ActionPar aPar) { cModule* module = aPar.modPtr; int newx = aPar.xpos; int newy = aPar.ypos; #get pointers to MyMobility (myMPtr) and MyChCo (myCCPtr) switch ( aPar.todo) { case "move": myMPtr->mymove( newx, newy); myCCPtr->updateDisconnectedHosts( NULL, true); break; // corresponding code for new, delete, ... } }

IV. S IMULATION RESULTS Simulation results for the rst routing protocol given in II-A using a 48 nodes WSN are given in Tab.I.
48 nodes network Energy consumed Max [mJ] Max-Min [mJ] Std. dev.[mJ] Total [mJ] Strategy1 hc(hop count) 5.631 3.712 1.154 147.76 Strategy2 hc+E(energy) 5.107 3.200 985 152.164 Strategy3 hc+cE(critical energy) 4.523 2.605 843 153.517

TABLE I I MPACT OF STRATEGIES ON THE ENERGY CONSUMPTION .

Inside the OMNeT++ code part we must keep track of all observers attached to it. Therefore, we dene the class
class oppObservers { list<Observer *> obsList; public: void attach( Observer *o){ obsList.push_back( o);} void detach( Observer *o) { obsList.remove( o);} void notify( ActionPar aParam) { for( list<Observer *>::iterator i=obsList.begin(); i!=obsList.end(); i++) (*i)->action( this, aParam);} }; extern oppObservers oppObs;
2 To allow callback functions we provide as argument a pointer to the OMNeT++ code

As can be seen, an energy-aware approach leads to a better overall behavior of the network. The results show that the best metrics is the combination of hop count with critical energy; the overall energy consumption is larger but the consumption is better balanced, which extends the network lifetime. When using only the hop count metrics we notice a very unbalanced energy consumption of the nodes (see standard deviation, the difference MaxMin); nodes on minimal hop count paths will soon be depleted while nodes with enough energy on comparable paths are not employed at all).
3 In order to allow the registration of more observers

Moreover, one can also combine the designed network protocol with different MAC layer protocols. Fig.7 illustrates the sorted energy consumption of all nodes using S-MAC and T-MAC protocols with two strategies. The energy is sorted in order to better visualize the distribution of the energy consumption on the nodes. The application requirements assume that the data interval generation is set to 200ms and the request is refreshed at a 5s interval. We use the following abbreviation, for example Smac 60 600 employs S-MAC with an active time and frame time of 60ms and 600ms respectively and the hop count as default routing strategy, while Tmac 15 600ce uses an active time and frame time of 15ms and 600ms respectively and a routing strategy based on the combination of hop count with critical energy.

Fig. 7. Energy consumption using different protocol stacks (different strategies and different MAC protocols).

strategy inuence the energy consumption. Of course, there are a lot more possible scenarios whose impacts can be analyzed; due to the lack of space we refrain from presenting them here. Besides comparing energy consumption in nodes our framework allows also an analysis of many other statistic measurements, such as: (average) number of collisions per node, min/max latency in a node and between source and sink, residual energy of nodes and their depleting time, number of broadcasted, unicasted, forwarded, lost and aggregated packets, etc. V. C ONCLUSIONS We used and extended OMNeT++ and its Mobility Framework mainly by: a) providing full implementation of MAC protocols (S-MAC, T-MAC, Preamble Sampling, etc.) including support for collision detection, b) adding two components, namely an energy module and a statistics module (with visualization support), c) extending the GUI with new features allowing an easy reconguration of the network topology at runtime. Our extensions are modularly designed, support code reusability and can be easily used and further developed. Together with the network layer architecture implementation they allow us to rapidly develop, to experiment with and to evaluate efciently routing protocols for WSNs and their impact on the energy behavior of sensor nodes and the lifetime of the WSN. R EFERENCES
[1] A. Kacso and R. Wism uller, A framework architecture to simulate energy-aware routing protocols in wsns, in Proc. of the IASTED Int. Conf. on Sensor Networks. Crete, Greece, September 2008, pp. 7782. [2] J. Polastre et al., A unifying link abstraction for wireless sensor networks, in Proc. Int. Conf. 3rd ACM SenSys, 2005, pp. 7689. [3] C. Ee, R. Fonseca, S. Kim, D. Moon, A. Tavakoli, D. Culler, S. Shenker, and I. Stoica, A modular network layer for sensornets, in Proc. 7th Symp. OSDI. Seattle, WA, USA, 2006, pp. 249262. [4] I. Akyildiz, M. Vuran, and O.Aka, A cross-layer protocol for wireless sensor networks, in Proc. Conference on Information Science and Systems (CISS 06). Princeton, NJ, March 2006. [5] C. Intanagonwiwat, R. Govindan, and D. Estrin, Directed diffusion a scalable and robust communication paradigm for sensor networks, in Proc. of ACM MobiCom. Boston, 2000, pp. 5667. [6] Y. Yu, R. Govindan, and D. Estrin, Geographical and energy aware routing: a recursive data dissemination protocol for wsns, in UCLA/CSDTR-01-0023s. LA, California, USA, May 2001. [7] T. Dam and K.Langendoen, An adaptive energy-efcient mac protocol for wireless sensor networks, in Proc. 1st Int. Conf. on Embedded Networked SenSys. California, USA, November 2003, pp. 171180. [8] W. Ye, J. Heidemann, and D. Estrin, Medium access control with coordinated, adaptive sleeping for wireless sensor networks, IEEE/ACM Trans. on Netw., vol. 12, no. 3, pp. 493506, 2004. [9] J. Polastre, J. Hill, and D. Culler, Versatile low power media access for wireless sensor networks, in Proc. 2nd ACM Int. Conf. on Embedded Networked SenSys. NY, USA, November 2004, pp. 95107. [10] G. Halkes, T. Dam, and K. Langendoen, Comparing energy-saving mac protocols for wireless sensor networks, Mob. Netw. Appl., vol. 10, no. 5, pp. 783791, 2005. [11] P. Karn, Maca - a new channel access method for packet radio, in ARRL/CRRL Amateur Radio 9th Computer Networking Conf., 1990, pp. 134140. [12] V. Bharghavan, A. Demers, S.Shenker, and L. Zhang, Macaw: A media access protocol for wireless lans, in Proc. of SIGCOMM Conf. London, UK, 1994, pp. 212225. [13] R. Min and A. Chandrakasan, A framework for energy-scalable communication in high-density wireless networks, in Proc. Int. Conf. ISLPED02. ACM Press, Calif.,USA, August 2002, pp. 3641. [14] H. Karl and A. Willig, Protocols and Architectures for Wireless Sensor Networks. John Wiley & Sons Inc., 2005.

It can be observed that: In case of Smac 60 600 and Smac 60 600ce the inuence of the strategy on the energy consumption is minimal. This can be explained by the fact that the data trafc is relatively small and all the nodes are most of the time in idle listening and therefore consuming almost the same amount of energy. When comparing Smac 60 600 and Tmac 15 600, the energy consumption of the majority of nodes decreases considerably, excepting the nodes on the path (right part of the curve). The combination of hop count with critical energy is a good routing metrics that balances the overall energy on more nodes. This can be observed by the comparison of Tmac 30 600 with Tmac 30 600ce and Tmac 15 600 with Tmac 15 600ce, respectively. In both cases the second curve is smoother than the rst one, with no more than 4% overall energy increase (see Tab.I). For the assumed application requirements the best energy consumption is achieved by using Tmac 15 600ce, since in this case the strategy balances the energy consumption (compared to Tmac 15 600) and the active time of 15ms is enough to sustain the expected data interval generation. Of course, we can also decrease the active time for the S-MAC in order to reduce the duty cycle of a node and correspondingly its energy consumption. Experimental results reveal that S-MAC fails to deliver all packets to the sink and collapses sooner than T-MAC when the data interval generation increases above a threshold. It can be seen that both the choice of the MAC protocol, its parameters (i.e. active time) and the routing