Sensor nerwork Simulator and Emulator

The Necessity of Network Simulation

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.

Why a New Simulator

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. 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.

Features of SENSE

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.

Currently Available Components and Simulation Engines (as of Oct 21, 2006)

• Battery Model:

  • Linear Battery

  • Discharge Rate Dependent and/or Relaxation Battery

• Application Layer:

  • Random Neighbor

  • Constant Bit Rate

• Network Layer:

  • Simple Flooding

  • A simplified version of ADOV without route repairing

  • A simplified version of DSR without route repairing

  • Self Selective Routing (SSR)

  • Self Healing Routing (SHR)

• MAC Layer:

  • NullMAC

  • IEEE 802.11 with DCF

• Physical Layer: Duplex Transceiver

• Wireless Channel:

  • Free Space

  • Adjacency Matrix

• Simulation Engine: CostSimEng (sequential)