A Survey of Simulation in Sensor Networks

Transcription

1 A Survey of Simulation in Sensor Networks David Curren University of Binghamton Abstract Sensor networks face many problems that do not arise in other types of networks. Power constraints, limited hardware, decreased reliability, and a typically higher density and number of nodes than found in conventional networks are just a small portion of the problems that have to be considered when developing protocols for use in sensor networks. Simulation is often used to test new protocols that are being developed, as well as to compare old protocols. However, there is always a danger when using simulation in testing: the results are not necessarily going to be accurate or representative. To help overcome this, it is important to possess knowledge of the simulation tools available, along with their associated strengths and weaknesses. The goal of this paper is to aid developers in the selection of an appropriate simulation tool. 1. Introduction The goal for any simulator is to accurately model and predict the behavior of a real world environment. Developers are provided with information on feasibility and reflectivity crucial to the implementation of the system prior to investing significant time and money. This is especially true in sensor networks, where hardware may have to be purchased in large quantities and at high cost. Even with readily available sensor nodes, testing the network in the desired environment can be a timeconsuming and difficult task. Simulation-based testing can help to indicate whether or not these time and monetary investments are wise. Simulation is, therefore, the most common approach to developing and testing new protocol for a sensor networks. Many published papers contain results based only on experimental simulation. There are a number of advantages to this approach: lower cost, ease of implementation, and practicality of testing large-scale networks. In order to effectively develop any protocol with the help of simulation, it is important to know the different tools available and the benefits and drawbacks therein associated. Section 2 of this paper presents the problems inherent in the use of simulation for testing, specifically applied to sensor networks. Section 3 presents a number of sensor network simulators. Section 4 provides analysis, comparing the simulators in situation-specific circumstances and making recommendations to the developers of future sensor simulators. 2. Problem Formation With the growing popularity of the wireless world and the development of cheaper, smaller embedded processors, sensor networks have grown as an important field. Because of their importance, a simulation environment that accurately tests protocols would be very beneficial in terms of time and cost. Various network simulation environments exist in which sensor networks can be tested, including GloMoSim, OPNET, EmStar, SensorSim, ns-2, and many others. However, because of the unique aspects and limitations of sensor networks, the existing network models may not lead to a complete demonstration of all that is happening [1]. In fact, the developers in charge of ns-2 provide a warning at the top of their website indicating that their system is not perfect and that their research and development is always on-going [2]. Various problems found in different simulators include oversimplified models, lack of customization, difficulty in obtaining already existing relevant protocols, and financial cost [3]. Given the facts that simulation is not perfect and that there are a number of popular sensor simulators available, one can conclude that different simulators are appropriate and most effective in different situations. It is important for a developer to choose a simulator that fits their project, but without a working knowledge of the available simulators, this is a difficult task. Additionally, simulator developers would benefit by seeing the weaknesses of available simulators as well as the weaknesses of their own models when compared with these simulators, providing for an opportunity for improvement. For these reasons, it is beneficial to maintain a detailed description of a number of the more prominent simulators available.

2 3. Simulators This paper will present thirteen different simulators. These simulators were selected based on a number of criteria including popularity, published results, and interesting characteristics and features. 3.1 ns-2 Ns-2 [2,4,5] is the most popular simulation tool for sensor networks. It began as ns (Network Simulator) in 1989 with the purpose of general network simulation. Ns-2 is an object-oriented discrete event simulator; its modular approach has effectively made it extensible. Simulations are based on a combination of C++ and OTcl. In general, C++ is used for implementing protocols and extending the ns-2 library. OTcl is used to create and control the simulation environment itself, including the selection of output data. Simulation is run at the packet level, allowing for detailed results. Ns-2 sensor simulation is a modification of their mobile ad hoc simulation tools, with a small number of add-ons. Support is included for many of the things that make sensor networks unique, including limited hardware and power. An extension developed in 2004 by [4] allows for external phenomena to trigger events. Ns-2 extensibility is perhaps what has made it so popular for sensor networks. In addition to the various extensions to the simulation model, the object-oriented design of ns-2 allows for straightforward creation and use of new protocols. The combination of easy in protocol development and popularity has ensured that a high number of different protocols are publicly available, despite not be included as part of the simulator's release. Its status as the most used sensor network simulator has also encouraged further popularity, as developers would prefer to compare their work to results from the same simulator. Ns-2 does not scale well for sensor networks. This is in part due to its object-oriented design. While this is beneficial in terms of extensibility and organization, it is a hindrance on performance in environments with large numbers of nodes. Every node is its own object and can interact with every other node in the simulation, creating a large number of dependencies to be checked at every simulation interval, leading to an n² relationship. Another drawback to ns-2 is the lack of customization available. Packet formats, energy models, MAC protocols, and the sensing hardware models all differ from those found in most sensors. One last drawback for ns-2 is the lack of an application model. In many network environments this is not a problem, but sensor networks often contain interactions between the application level and the network protocol level. 3.2 GloMoSim GloMoSim [6] was developed in 1998 for mobile wireless networks. It is written in Parsec, which is an extension of C for parallel programming. The ability to use GloMoSim in a parallel environment distinguishes it from most other sensor network simulators. Because of communication that must take place between simulated nodes on different machines, parallel network simulation is difficult. The use of a wireless model further complicates things; communication between simulated nodes is more complicated and computationally intensive than in a wired simulated network. Additionally, the use of broadcast communication protocols, common in mobile networks, leads to significantly more traffic between computers on the distributed network. Like ns-2, GloMoSim is designed to be extensible, with all protocols implemented as modules in the GloMoSim library. The GloMoSim architecture (Figure 1) is composed of a number of different layers. Each layer uses a different set of protocols and has an API defined to communicate with the surrounding layers. Like ns-2, GloMoSim uses an object-oriented approach. However, the designers realized that a purely object-oriented approach would not be scalable. Instead, GloMoSim partitions the nodes, and each object is responsible for running one layer in the protocol stack of every node for its given partition. This helps to ease the overhead of a large network. GloMoSim still contains a number of problems. Figure 1: GloMoSim Architecture from [6]

3 While effective for simulating IP networks, it is not capable of simulating any other type of network. This effectively ensures that many sensor networks can not be simulated accurately. Additionally, GloMoSim does not support phenomena occurring outside of the simulation environment, all events must be be generated from another node in the network. Finally, GloMoSim stopped releasing updates in Instead, it is now updated as a commercial product called QualNet. 3.3 OPNET OPNET [7,8] is another discrete event, objectoriented, general purpose network simulator. It uses a hierarchical model to define each aspect of the system. The top level consists of the network model, where topology is designed. The next level is the node level, where data flow models are defined. A third level is the process editor, which handles control flow models. Finally, a parameter editor is included to support the three higher levels. The results of the hierarchical models are an event queue for the discrete event simulation engine and a set of entities representing the nodes that will be handling the events. Each entity in the system consists of a finite state machine which processes the events during simulation. OPNET is capable of recording a large set of user defined results Unlike ns-2 and GloMoSim, OPNET supports the use of modeling different sensor-specific hardware, such as physical-link transceivers and antennas. OPNET can also be used to define custom packet formats. The simulator aids users in developing the various models through a graphical interface. The interface can also be used to model, graph, and animate the resulting output. OPNET suffers from the same object-oriented scalability problems as ns-2. It is not as popular as ns-2 or GloMoSim, at least in research being made publicly available, and thus does not have the high number of protocols available to those simulators. Additionally, OPNET is only available in commercial form. 3.4 SensorSim SensorSim [9] uses ns-2 as a base, and extends it in three important ways. First, it includes an advanced power model. The model takes into account each of the hardware components that would need battery power in order to operate. The developers researched the affects of each of these different components on energy consumption in order to create their power model. It is included as part of the sensor node model (Figure 2). Secondly, SensorSim includes a sensor channel This was a precursor to the phenomena introduced to ns-2 in Both function in approximately the same way. SensorSim's model is slightly more complicated and includes sensing through both a geophone and a microphone. However, the model is still simplistic, and the developers felt that another means of including more realistic events was needed. This led to the third extension to ns-2: an interaction mechanism with external applications. The main purpose is to interact with actual sensor node networks. This allows for real sensed events to trigger reactions within the simulated environment. In order to accomplish this, each real node is given a stack in the simulation environment. The real node is then connected to the simulator via a proxy, which provides the necessary mechanism for interaction. One further extension to ns-2 is the use of a piece of middleware called SensorWare. This middleware makes it possible to dynamically manage nodes in simulation. This provides the user with the ability to provide the network with small application scripts than can be dynamically moved throughout the network. This ensures that it is not necessary to preinstall all possible applications needed by each node, and provides a mechanism for distributed computation. Because of the battery model and sensor channel, improvements were made in the associated hardware models when compared with ns-2. However, especially in the case of the sensing hardware, the models are still very simple and do not accurately reflect what is found on most sensors. Like ns-2, SensorSim faces a scalability problem. Additionally, SensorSim is not being maintained and is not currently available to the public. Figure 2: Micro Sensor Node Model in SensorSim from [9]

4 3.6 SENSE The SENSE [11] simulator is influenced by three other models. It attempts to implement the same functionality as ns-2. However, it breaks away from the object-oriented approach, using J-Sim's component based architecture. Like GloMoSim, SENSE also includes support for parallelization. Through its component-based model and support for parallelization, the developers attempt to address what they consider to be the three most critical factors in simulation: extensibility, reusability, and scalability. Figure 3: Top level of J-Sim's component based architecture from [10] 3.5 J-Sim J-Sim [10] is a general purpose Java-based simulator modeled after ns-2. Unlike ns-2, however, J-Sim uses the concept of components, replacing the notion that each node should be represented as an object. J-Sim uses three top level components (Figure 3): the target node (which produces stimuli), the sensor node (that reacts to the stimuli), and the sink node (the ultimate destination for stimuli reporting). Each component is broken into different parts and modeled differently within the simulator. The breakdown of each component makes it easy to use different protocols in different simulation runs. J-Sim features several improvements on ns-2 and other simulators. Most importantly, its component based architecture scales better than the object oriented model used by ns-2 and other simulators. Furthermore, J-Sim features an improved energy model and the ability to simulate the use of sensors for phenomena detection. Like SensorSim, applications may be simulated, and there is support for the connection of real hardware sensors to the simulator. SENSE was developed in C++, on top of COST, a general purpose discrete event simulator. It implements sensors as a collection of static components. Connections between each component are in the format of inports and outports (Figure 4). This allows for independence between components and enables straightforward extensibility and reusability. Traversing the ports are packets. Each packet is composed of different layers for each layer in the sensor. The designers try to improve scalability by having all sensors use the same packet in memory, assuming that the packet should not have to be modified. SENSE's packet sharing model is an improvement on ns-2 and other object-oriented models that can not do this, helping improve scalability by reducing memory use. However, the model is simplistic and places some communication limitations on the user. While SENSE implements the same basic functionality as ns-2, it can not match the extensions to the ns-2 model. Whether because it is a new simulator, or because it has not achieved the popularity of ns-2, there has not been research into adding a sensing model, eliminating physical phenomena and J-Sim is relatively complicated to use. While no more complicated than ns-2, the latter simulator is more popular and, thus, more people are willing to spend the time to learn how to use it. J-Sim, while more scalable than many other simulators, also faces its share of inefficiencies. Java, in general, is arguably less efficient than many other languages. There is also unnecessary overhead in the intercommunication model. The only MAC protocol that can be used in , a problem that seem to occur in most sensor simulators that are built on top of allpurpose simulators. Figure 4: SENSE's sensor node structure with ports from [11]

5 environmental effects. SENSE also does not match the parallelization ability's of GloMoSim, leaving a significant portion of parallelizing to the user. It does, however, give the user the option to optimize for parallelization or for sequential operation. 3.7 OMNeT++ Another sensor network simulator was built upon the component-based discrete event simulator OMNeT++ [12]. OMNeT++ uses building blocks called modules to implement their simulator. Modules are connected in a hierarchical nested fashion, where each module can contain several other modules. Modules can be defined as being either simple or compound. Simple modules are used to define algorithms, and make up the bottom of the hierarchy. Compound modules are a collection of simple modules who interact with one another, using messages. In the sensor network model of OMNeT++, called SensorSim, modules are used to define a number of different objects (Figure 5). Within a sensor node itself, which is a complex module, there are three different types of modules: modules to represent each protocol layer, modules to reflect hardware, and a coordinator module. The coordinator module is responsible for communication between protocol layers and the hardware, forwarding the necessary messages from one to the other. Outside of the sensor node, there are modules that represent physical objects to be sensed, a sensor channel which communicates with the sensor node itself, and a wireless channel for network communication. SensorSim has a number of advantages over the other simulators. It uses a component based, efficient implementation which has been shown to be significantly faster than ns-2. SensorSim accurately models most hardware and includes the modeling of Figure 5: OMNeT++'s module implementation from [12] physical phenomena. All layers of the protocol stack can be modified. Despite its apparent advantages, SensorSim has remained relatively obscure. The simulator design is fairly different from most other designs, providing a steeper than average learning curve. Very little published work has been done using SensorSim. The original implementation does not offer a great variety of protocols, and very few have been implemented, leaving users with significant background work if they want to test their own protocol in different environments. 3.8 Sidh Sidh [13], developed specifically for wireless networks, is a recent component-based simulator written in Java. It is made up of a number of modules that interact with each other through events. Every module is defined by an interface that allows it to interact with other modules. As long as a module conforms to a specific interface, it can be used in the simulator, allowing for easy configuration. Sidh is composed of modules that fit into a number of different categories. These include Simulator, Events, Medium, Environment, Node, Transceivers, Protocols, and Applications. The Simulator module a discrete event simulator that is the base of Sidh. The Event module is responsible for communication between the other modules and includes a simulation time indicating when the even will occur. The Medium and Propagation models designate the properties of the wireless medium. They must keep information on the location and radio properties at each node. The Environment module is similar, except that is is modeling physical phenomena. The Node module represents a sensor node and contains all of the modules that make up a sensor, such as hardware, network protocols, and applications. Sidh attempts to allow the user to create as realistic of a sensor simulator as possible. In this, is succeeds. Of all simulators in this paper, it is possibly the easiest to replace and exchange modules at any level. However, Sidh seems to sacrifice efficiency in order to do this. There are several places in which different modules appear to store the same information. While this information is dynamically created during runtime and does not create independencies, it does use more memory than is needed, limiting the number of nodes that can be simulated and effectively slowing simulation. The developers of Sidh have not published any results yet, and the simulator is too new to be included in other comparisons. It also appears that the simulator can only be obtained by contacting the developers at this point. One further drawback is

6 that there seem to be very few protocols implemented. 3.9 SENS The last of the component-based simulators to be discussed in this paper is SENS [14]. It is composed of four main components: application, network, and physical, and environment. The former three components make up the sensor node. The application component simulates the software of the sensor node. It communicates with the network layer to handle incoming and outgoing packets, and communicates with the physical component to read sensed information. To simulate the software in the application level, code intended for a real sensor may be used. The compiler links to a library to port the code to the simulator. The network component is responsible for sending and receiving packets to the other sensor nodes making up the network. There are three network models that can be used. The first successfully forwards packets to all neighbors, the second delivers with chance of loss based on a fixed probability, and the third considers the chance of collision at each node. The physical component represents the non-network hardware for the sensor. This includes the power, sensors, and actuators. This is the component that interacts with the environment component. The environment component models the environment of the sensor nodes. This includes the physical phenomena and the layout. The layout model is fairly complex and includes different types of surfaces, each affecting radio and sound propagation in a different way. Each of the components has its own simulated time. This allows for any component to send a message to any other component with a given delay. SENS is less customizable than many other simulators, providing no opportunity to change the MAC protocol, along with other low level network protocols. SENS does appear to use one of the most sophisticated environmental models and implements the use of sensors well. However, the only phenomenon detectable is sound. It can be argued as to whether or not it is better for a simulator to support several phenomena well, or to support one phenomenon very well TOSSIM TOSSIM [15], along with the rest of the simulators still to be discussed in this paper, are actually emulators. Emulators are different from simulators in that they run actual application code. The benefits and drawbacks of emulation will be included in Section 4 of this paper. Figure 6: TOSSIM architecture from [15] TOSSIM is designed specifically for TinyOS applications to be run on MICA Motes. The developers had four key concepts in mind when creating TOSSIM: scalability (the system should be able to handle thousands of nodes with different network configurations), completeness (as many system interactions as possible must be covered in order to accurately capture behavior), fidelity (subtle interactions must be captured if testing is to be accurate), and bridging (validating the implementation of algorithms). In order to achieve its goal of scalability, each node in the simulator is connected in a directed graph where each edge has a probabilistic bit error. For perfect transmission, the bit error is 0, and can be changed for different situations. Also in the name of efficiency, every node in TOSSIM runs the same application code; all nodes are identical. The goal of scalability is successfully achieved, results show it be able to handle larger networks than almost any other simulator or emulator. The TOSSIM architecture is made up of a number of different components (Figure 6): support for compiling a network topology graph, a discrete event queue, simulated hardware, and a communication infrastructure that allows the simulator to communicate with external programs. Most application code is run unchanged. The only differences are in some places where the application interacts with hardware. TOSSIM's probabilistic bit error model leads to inaccuracies, and reduces the simulator's effectiveness in analyzing low level protocols. Accuracy loss also occurs during compilation, when fine grained timing and interrupt properties are lost, affecting interactions with other nodes in the network. Additionally,

7 network. Additionally, despite the fact that the sensor's data gathering hardware is simulated, the phenomena that trigger reactions are not ATEMU ATEMU [16] picks up where TOSSIM left off. Like TOSSIM, ATEMU code is binarily compatible with the MICA2 platform. However, emulation is more fine-grained than in TOSSIM; ATEMU uses a cycleby-cycle strategy to run application code. This is done through emulation of the AVR CPU used by MICA. ATEMU (Figure 7) uses an XML configuration file in order to configure the network. This enables the entire network to be defined in a hierarchical manner, with the characteristics of the network defined at the top level, and the characteristics of each node defined at lower levels. ATEMU also provides a graphical user interface called XATDB. It can be used to debug and observe the execution of the code, allowing for breakpoints, step-by-step execution, and other debugging functions. ATEMU offers an accurate emulation model in which each MICA mote can run different application code. While more accurate than TOSSIM, ATEMU sacrifices speed and scalability to do this; the simulator only runs accurately with up to 120 nodes. Aside from the overhead involved in decoding instruction-by-instruction, ATEMU also suffers the same overhead as object oriented models. One radio transmission can affect every other node in the network, creating an n² algorithm. Despite the scalability problems, ATEMU is one of the most accurate sensor simulators available Arvora Avrora [17] is a new emulator that attempts to find a middle ground between TOSSIM and ATEMU. Avrora is implemented in Java, unlike the other two emulators, which are written in C. Similar to many of the object-oriented simulators, Avrora implements each node as its own thread. However, it still runs actual Mica code and is an emulator. Like ATEMU, Avrora runs code in an instruction-by-instruction fashion. However, the simulator attempts to achieve better scalability and speed by not synchronizing all nodes after every instruction. Arvora can use two different strategies for synchronization. The first approach uses a synchronization interval to define how often synchronization occurs. The higher the number, the longer between synchronization. A synchronization interval of 1 would be roughly analogous to ATEMU. The user must be careful not to make the number too high, or a node could run past the time at which it would be affected by an event from another node. The second strategy Arvora can use waits for neighbors to reach a certain simulation time before synchronizing. A global data structure is kept with the local time of each simulator. The algorithm allows each node to be further ahead in simulation time than other nodes until synchronization is required. By reducing synchronization, Avrora effectively reduces the overheard inherent in the n² communication algorithm. The developer's results back their claim of improved efficiency over ATEMU, with results much closer to TOSSIM. However, no tests were reported that indicated the accuracy of the results. Until a further look is taken at simulator accuracy in the face of both synchronization algorithms, and with different parameters, it is difficult to judge the effectiveness of Avrora EmStar EmStar [18] is a Linux-based framework that offers both a range of runtime environments, from pure simulation to actual deployment. EmStar uses the same code and configuration files to run at each of these levels, allowing for ease in continuing through the development cycle. Like SensorSim, amongst other simulators, EmStar provides an option to interface with actual hardware while running simulation. Figure 7: ATEMU architecture from [16] The EmStar simulation model (Figure 8) is component-based and uses a discrete event model. In fact, it is similar to many of the other simulators discussed in this paper, but with limitations. EmStar

8 Figure 8: The EmStar pure simulation mode from [18] uses a very simple environmental model and network medium. As the purpose is to migrate the code to a real sensor environment, simple environment and network medium abstractions sufficed for the developers. Secondly, the simulator will only run code for the types of nodes that it is designed to work with. EmStar was designed to be compatible with two different types of nodes. Like the other emulators, it can be used to develop software for Mica2 motes. It also offers support for developing software for ipaq based microservers. The development cycle is the same for either hardware platform. In the development cycle, the next step forward from simulation uses data replay. In this model, which has not been completed by the developers, EmStar uses data collected from actual sensors in order to run its simulation. From there, EmStar uses the halfsimulation/half-emulation approach similar to SensorSim's, where software is running on a host machine and interfacing with the actual sensor. This allows for use of the actual communication channel and sensors. The final step is deployment. EmStar brings together a number of the stronger features of other simulators and emulators. While not as efficient and fast as other frameworks like TOSSIM, EmStar's use of the component-based model allows for fair scalability. Through the use of their development cycle, each aspect of the network can be fine-tuned in a logical manner. Because code is designed to work with already existent hardware, many protocols are already available. Only the configuration file has to be designed. However, the configuration file is a potential drawback. If a user is attempting to model a system by progressing through the development cycle, he must either ensure that the hardware configuration being used matches the configuration file, or he must bear in mind that there will be differences and compensate appropriately, if necessary. 4. Analysis This paper by no means presents an exhaustive list of sensor simulators. Other simulators include TOSSF, SensorSimII, Monarch, VisualSense, and Prowler, just to name a few. However, I believe that most of the issues facing the developers of sensor networks can be seen in this paper. Of course, many decisions must be made for specific situations rather than following all encompassing guidelines. At the topmost level, developers must decided whether they want a simulator or an emulator. Each has advantages and disadvantages, and each is appropriate in different situations. Generally, a simulator is more useful when looking at things from a high view. The effect of routing protocols, topology, and data aggregation can be see best at a top level and would be more appropriate for simulation. Emulation is more useful for fine-tuning and looking at low-level results. Emulators are effective for timing interactions between nodes and for fine tuning network level and sensor algorithms. If the developers decide to build a simulator, another design level decision that must be made is whether to build their simulator on top of an existing general simulator or to create their own model. If development time is limited or there is one very specific feature that the developers would like to use that is not available, then it may be best to build on top of an existing simulator. However, if there is available development time and the developers feel that they have a design that would be more effective in terms of scalability, execution speed, features, or another idea, then building a simulator from the base to the top would be most effective. In building a simulator from the bottom up, many choices need to be made. Developers must consider the pros and cons of different programming languages, the means in which simulation is driven (event vs. time based), component-based or objectoriented architecture, the level of complexity of the simulator, features to include and not include, use of parallel execution, ability to interact with real nodes, and other design choices. While design language choices are outside of the scope of this paper, there are some guidelines that appear upon looking at a number of already existing simulators. Most simulators use a discrete event engine for efficiency. Component-based architectures scale significantly better than object-oriented architectures, but may be more difficult to implement in a modularized way. Defining each sensor as its own object ensures independence amongst the nodes. The ease of swapping in new algorithms for different protocols

9 also appears to be easier in object-oriented designs. However, with careful programming, component based architectures perform better and are more effective. Generally, the level of complexity built into the simulator has a lot to do with the goals of the developers and the time constraints imposed. Using a simple MAC protocol may suffice in most instances, and only providing one saves significant amounts of time. Other design choices are dependent on intended situation, programmer ability, and available design time. The authors of the ATEMU paper propose an idea for a common configuration file to be used in sensor simulation. They present a hierarchical XML description to create the network. Using XML to define the network is logical because of the ability to extend the given set of tags, allowing for different simulators to offer unique features while conforming to the standard. However, achieving conformity seeming unlikely, with established general network simulators like ns-2 unlikely to change there model. The use of a standard configuration file may be limiting in many situations to. 5. Conclusion The goals of this paper were to provide background on a number of different sensor network simulators and present the best and worst features of each. The purpose was two-fold. First, knowing the strengths and weaknesses of a number of different simulators is valuable because it allows users to select the one most appropriate for their testing. Second, the developers of new simulators are well served knowing what has worked in previous simulators and what has not. To these ends, I believe I have succeeded. 6. Acknowledgments I would like to thank K.D. Kang, Nael Abu-Ghazaleh, and the entire Sensor Networks class at Binghamton University for providing the background necessary for this study. I would also like to thank Ke Liu for his help in exposing me to some sensor network routing code for use in both simulation and real implementation. 7. References [1] S. Park, A. Savvides and M. B. Srivastava. Simulating Networks of Wireless Sensors. Proceedings of the 2001 Winter Simulation Conference, [2] The Network Simulator ns-2. [3] Vlado Handziski, Andreas Köpke, Holger Karl, and Adam Wolisz. A Common Wireless Sensor Network Architecture?. Sentzornetze, July [4] Ian Downard. Simulating Sensor Networks in ns-2. NRL Formal Report 5522, April, [5] Valeri Naoumov and Thomas Gross. Simulation of Large Ad Hoc Networks. ACM MSWiM, [6] Xiang Zeng, Rajive Bagrodia, Mario Gerla. GloMoSim: A Library for Parallel Simulation of Large-scale Wireless Networks. Workshop on Parallel and Distributed Simulation, [7] Xinjie Chang. Network Simulations with OPNET. [8] Yi Pan. Introduction to OPNET Simulator. [9] Sung Park, Andreas Savvides, and Mani B. Srivastava. SensorSim: A Simulation Framework for Sensor Networks. ACM MSWiM, August, [10]Ahmed Sobeih and Jennifer C. Hou. A Simulation Framework for Sensor Networks in J- Sim. Technical Report UIUCDCS-R , November [11] Gilbert Chen, Joel Branch, Michael Pflug, Lijuan Zhu, and Boleslaw Szymanski. SENSE: A Sensor Network Simulator. Advances in Pervasive Computing and Networking, [12]C. Mallanda, A. Suri, V. Kunchakarra, S.S. Iyengar, R. Kannan, and A. Durresi. Simulating Wireless Sensor Networks with OMNeT++. [13]Thomas W. Carley. Sidh: A Wireless Sensor Network Simulator. ISR Technical Reports, [14]Sameer Sundresh, Wooyoung Kim, and Gul Agha. SENS: A Sensor, Environment, and Network Simulator. Proceedings of 37th Annual Simulation Symposium, 2004 [15] Philip Levis, Nelson Lee, Matt Welsh, and David Culler. TOSSIM: Accurate and Scalable Simulation of Entire TinyOS Applications. Proceedings of SenSys 03, First ACM Conference on Embedded Networked Sensor Systems, [16]Jonathan Pollet, et al. ATEMU: A Fine-Grained Sensor Network Simulator. Proceedings of SECON 04, First IEEE Communications Society Conference on Sensor and Ad Hoc Communications and Networks, [17]Ben L. Titzer, Daniel K. Lee, Jens Palsberg. Avrora: Scalable Sensor Network Simulation With Precise Timing. Proceedings of IPSN'05, Fourth International Conference on Information Processing in Sensor Networks, [18] J. Elson, et a. EmStar: An Environment for Developing Wireless Embedded Systems Software. Proceedings of the USENIX Technical Conference, 2004.