The emergence of wireless sensor networks brought many open issues to network designers. Traditionally, the three main techniques for analyzing the performance of wired and wireless networks are analytical methods, computer simulation, and physical measurement. However, because of many constraints imposed on sensor networks, such as energy limitation, decentralized collaboration and fault tolerance, algorithms for sensor networks tend to be quite complex and usually defy analytical methods that have been proved to be fairly effective for traditional networks. Furthermore, few sensor networks have come into existence, for there are still many unsolved research problems, so measurement is virtually impossible. It appears that simulation is the only feasible approach to the quantitative analysis of sensor networks.
ns2, perhaps the most widely used network simulator, has been extended to include some basic facilities to simulate sensor networks. However, one of the problems of ns2 is its object-oriented design that introduces much unnecessary interdependency between modules by binding functionalities with types. For example in an OO design a physical layer module has always to be a sub-type of a physical layer abstract class. This constraint is unnecessary in the sense that when we building a new physical module we should not care about its type -- as long as it has a compatible interface (meaning matching input/output methods) with other modules it should be allowed to interact with others. Such interdependency sometimes makes the addition of new protocol models extremely difficult, only mastered by those who have intimate familiarity with the simulator. Being difficult to extend is not a major problem for simulators targeted at traditional networks, for there the set of popular protocols is relatively small. For example, Ethernet is widely used for wired LAN, IEEE 802.11 for wireless LAN, TCP for reliable transmission over unreliable media. For sensor networks, however, the situation is quite different. There are no such dominant protocols or algorithms and there will unlikely be any, because a sensor network is often tailored for a particular application with specific features, and it is unlikely that a single algorithm can always be the optimal one under various circumstances.
Many other publicly available network simulators, such as JavaSim, SSFNet, Glomosim and its descendant Qualnet, attempted to address problems that were left unsolved by ns2. Among them, JavaSim developers realized the drawback of object-oriented design and tried to attack this problem by building a component-oriented architecture. However, they chose Java as the simulation language, inevitably sacrificing the efficiency of the simulation. SSFNet and Glomosim designers were more concerned about parallel simulation, with the latter more focused on wireless networks. They are not superior to ns2 in terms of design and extensibility.
SENSE is designed to be an efficient and powerful sensor network simulator that is also easy of use. We identify the three most critical factors as:
Extensibility: The enabling force behind the fully extensibility network simulation architecture is our progress on component-based simulation. We introduced a component-port model that frees simulation models from interdependency usually found in an object-oriented architecture, and then proposed a simulation component classification that naturally solves the problem of handling simulated time. The component-port model makes simulation models extensible: a new component can replace an old one if they have compatible interfaces, and inheritance is not required. The simulation component classification makes simulation engines extensible: advanced users have the freedom to develop new simulation engines that meet their needs.
Reusability: The removal of interdependency between models also promotes reusability. A component developed for one simulation can be used in another if it satisfies the latter's requirements on the interface and semantics. There is another level of reusability made possible by the extensive use of C++ template: a component is usually declared as a template class so that it can handle different type of data.
Scalability: Unlike many parallel network simulators, especially SSFNet and Glomosim, parallelization is provided as an option to the users of SENSE. The reflects our belief that completely automated parallelization of sequential discrete event models, however tempting it may seem, is impossible, just as automated parallelization of sequential programs. Even if it possible, it is doomed to be inefficient. Therefore, parallelizable models require more effort than sequential models, but a good portion of users are not interested in parallel simulation at all. In SENSE, a parallel simulation engine can only execute components of compatible components. If a user is content with the default sequential simulation engine, then every component in the model repository can be reused.
G-Sense is an independently developed Guide User Interface for SENSE recomended for the first time users, see: Pedro M. P. Rosa, Paulo A. C. S. Neves, Binod Vaidya, and Joel J. P. C. Rodrigues, "G-Sense . A Graphical Interface for SENSE Simulator", The First International Conference on Advances in System Simulations (SIMUL 2009), Porto, Portugal, September 20-25, 2009. G-System is available at the link below:
Discharge Rate Dependent and/or Relaxation Battery
Constant Bit Rate
A simplified version of ADOV without route repairing
A simplified version of DSR without route repairing
Self Selective Routing (SSR)
Self Healing Routing (SHR)
IEEE 802.11 with DCF
Physical Layer: Duplex Transceiver
Simulation Engine: CostSimEng (sequential)
Chen, G., J. Branch, M. J. Pflug, L. Zhu and B. Szymanski (2004). SENSE: A Sensor Network Simulator. Advances in Pervasive Computing and Networking. B. Szymanski and B. Yener, Springer: 249-267.
B.K. Szymanski and G.G. Chen. Sensor Network Component Based Simulator. Handbook of Dynamic System Modeling, chapter 35, Paul Fishwick (edt.), CRC/Taylor and Francis Publ., 2007 pp. 35-1 -- 35-16.