Selection criteria for wireless sensor network simulators

This research involves the discrete-event simulations of the performance of ad hoc wireless sensor networks, including the use of energy which determines the life of the network. Therefore there is a need for selection criteria for the type of simulator that will be required. Different simulators, either open source or commercial have many modules

54

that are essential for our research e.g. the energy model, while others that don’t have the required models or are only available as purchasable modules. The simulator needs to be customisable as it may also be required to run the simulations with some of the trace options turned on while others trace options switched off e.g. if the packet delivery is only being monitored at the MAC layer, then there is no need for the traces of packet handling at network and transport layer. Also in another case we may only want to monitor the network energy consumption, then we will not be interested in the rest of the OSI reference model, and hence the trace support for them modules can be switched off (even though all those events would be taking place, but to reduce the size of the trace file, and to increase the speed of the simulation, they will not be recorded). Another key advantage is to have a simulator that can run on multiple platforms, e.g. Windows and Linux. Many simulators are written for Linux OS as they are open source and can easily be modified and also execute much faster in that environment as compared to when they are transported in Windows OS. Many network simulators come with some sort of topology creation tools that allow the researcher to create large network topologies using simple script or configuration languages. As the simulation networks become larger we will require the use of such tools to create large topologies, hence having such support in the simulator will enhance our work.

As the simulations will try to mimic real life sensor network deployment, the main requirement of the simulator is to have a real implementation of the OSI modules in all the layers. One of the key layers of interest will be the MAC layer where the sleep mode and synchronisation algorithms will be introduced. Node mobility is not required in the first instance; even though it is useful feature as in this research we are more interested in fixed node and multi-hop communication. At the application and session layer, a simple ftp module or CBR module can perform the required task. At transport layer we are only working on wireless sensor networks, it not a key requirement to have TCP transport protocol, a best effort UDP service is sufficient to carry out the task required. All the wirelesses sensor nodes are only required to send the data to the base station e.g. in case of a forest monitoring wireless sensor network, the base station would only be interested to know the temperature at certain locations in the forest.

The physical layer is also of importance as much of the research will be focused on the effect of transmission power on node energy and how the network could be as energy efficient as possible. There are many radio wave propagation models implemented within

55

simulators ranging from the simple Friss- space attenuation model which assume that the transmitter and receiver are in line of sight to the more complicated shadowing and Rayleigh fading models. However it is not only the number of models that are included, but the characteristics and quality of those models is far more important if accurate results are required. This research incorporates the Two Ray Ground Model that is the most accepted model used by the research community. The simulator should also have a set of good traffic generation modules that follow a specific target distribution e.g. Poisson or that can easily be configured as required by the user to model the traffic in the network. Monitoring support is of extreme importance as that will only allow studying the dynamics of the simulated model. The monitoring has to be based on per node as well as per flow model. It is of vital importance to record the energy consumption of the communications module while each node is either sleep/awake or transmitting/receiving and the energy consumed in the transition from sleep to wake including re-synchronisation energy. Also for network QoS analysis a flow model is essential. The monitoring module needs to be very flexible so that only the desired level of detail is recorded while other components can be turned off depending on the simulation, e.g. when trying to trace the energy consumption of each node we will not want to record the QoS parameters. Recording the QoS and energy parameters simultaneously will not only prolong the simulation run time, but also generate trace files in the size of gigabytes that use up all the system space memory. In that case the analysis of data will be automated.

Therefore to summarise, what is required, is a simulator architecture that is open, very flexible and modifiable. A simulator that allows the user to add new models and edit existing models. It also allows the user to select a desired level of detail so components can easily be switched on or off. A simulator that has the popular routing protocols, and allows scalability so that the number of nodes can be increased easily as required by the model application. The researcher needs to be familiar with the software design of the simulator and the programming languages and tools required to use the simulator. This will help in building prototype models much efficiently, confidently and effectively. It will also reduce time in testing and debugging the new modules and software. The documentation of the simulator should also be of good quality so that the user can easily learn how to use the software.

One of the most important factors to consider is the acceptability of the simulator by the research community. As mentioned earlier, results produced can be very specific to a

56

simulator and may not be nearly the same as results achieved from other simulators. Hence a simulator that produce results that can be compared easily with the present literature and that can easily be reproduced by other researchers is more likely to be accepted by the research community. Many of the public domain simulators are more convenient to use and modify and of course are free. However if commercial simulator provide some modules that are necessary and provide some clear advantage over the free simulator, then they need to be considered.