Ns-2 is a packet-level simulator and essentially a centric discrete event scheduler to schedule the events such as packet and timer expiration. Centric event scheduler cannot accurately emulate “events handled at the same time” in real world, that is, events are handled one by one. However, this is not a serious problem in most network simulations, because the events here are often transitory. Beyond the event scheduler, ns-2 implements a variety of network components and protocols. Notably, the wireless extension, derived from CMU Monarch Project [2], has 2
Assumptions simplifying the physical world:
(1) Nodes do not move significantly over the length of time they transmit or receive a packet. This assumption holds only for mobile nodes of high-rate and low-speed. Consider a node with the sending rate of 10Kbps and moving speed of 10m/s, during its receiving a packet of 1500B, the node moves 12m. Thus, the surrounding can change significantly and cause reception failure.
(2) Node velocity is insignificant compared to the speed of light. In particular, none of the provided propagation models include Doppler effects, although they could.
Why two Languages?
NS-2 uses two languages because simulator has two different kinds of things it needs to do. On one hand, detailed simulation of protocols requires a systems programming language which can efficiently manipulate bytes, packet headers, and implement algorithms that run over large data sets. For these tasks run-time speed is important and turn-around time (run simulation, find bug, fix bug, recompile, re-run) is less important.
On the other hand, a large part of network research involves slightly varying parameters or configurations, or quickly exploring a number of scenarios. In these cases, iteration time (change the model and re-run) is more important. Since configuration runs once (at the beginning of the simulation), run-time of this part of the task is less important.
NS-2 meets both of these needs with two languages, C++ and OTcl. C++ is fast to run but slower to change, making it suitable for detailed protocol implementation. OTcl runs much slower but can be changed very quickly (and interactively), making it ideal for simulation configuration. NS-2 (via tclcl) provides glue to make objects and variables appear on both languages.
NS-2 Directory Structure:
As shown in Figure 1, the C++ classes of ns-2 network components or protocols are implemented in the subdirectory “ns-2”, and the TCL library (corresponding to configurations of these C++ instances) in the subdirectory of “tcl”.
Network Components:
Network components are Node, Link, Queue, etc. Some of them are simple components, that is, they are created from the corresponding C++ classes; The other are compound components, that is, they are composed multiple simple C++ classes, e.g. Link are composed of Delay (emulating propagation delay) and Queue. In general, in ns-2, all network components are created, plugged and configured from TCL.
