An Introduction to ns-3

It is a universal truth that life cannot be summarised in a single snapshot. The story of ns-3 is no different. This series of articles on ns-3 will definitely help researchers and students working in the area of computer networks. But before that, let’s briefly cover the fundamentals. ns-3 is a discrete event simulator with many features useful to the research community. The first problem I faced with ns-3 was regarding the abbreviation of the name—network simulator version 3. People often use NS3, NS-3 and ns-3 interchangeably. I am using ns-3 because that is the style used in the documents provided by the group overseeing the development of ns-3, which is the NS-3 Consortium.

Simulation and the need for simulation tools
The classical definition of simulation is “the imitation of the operation of a real-world process or system over time.” This definition gives a general description of simulation and it applies even to physical processes. For example, automobile simulators are used to train drivers. In computer simulation, the basic idea is to use a simplified model to study the behaviour of a real world system, which might otherwise not be feasible to model. For example, weather forecasting often involves simplified simulation models. Some of the tools used for computer based simulation are used in areas like computer networking, cloud computing, parallel computing, etc. The most important simulators are those used for simulating computer networks, and the question that should be answered is regarding the need for network simulation. Even though hardware has become cheaper, it is still a luxury for researchers in countries like ours where getting funds for research is a herculean task. So instead of relying on hardware in the initial stages of research we can use simulation tools for data, and if the results are promising, we can use the actual hardware based implementation for verification.
Computer simulators can be classified into continuous simulators and discrete event simulators. Continuous simulators continuously track the systems’ response based on a set of predefined conditions. Most of the time, continuous simulators work on a mathematical model developed by using differential equations. Commercial flight simulators use a continuous simulation model. Discrete event simulators model the working of a system as a discrete sequence of events in time. So the overall working of an event-driven system is based on an event/response model. A discrete event simulator changes its internal state by responding to some event happening in the simulation universe. One common assumption made by every discrete event simulator is that nothing happens between two events. Pseudo-random number generators typically make use of a discrete event simulation model.
Another point to be discussed is the difference between simulation and emulation. The latter is the process by which one system is made to behave like another system. This is different from the process of simulation. An emulator can be used to carry out real tasks as a substitute for the original device or system, whereas a simulator is used mainly as a model for analysis. For example, QEMU is a hosted virtual machine monitor. It emulates real CPUs and can be used to carry out arithmetic operations just like a normal CPU, whereas an automobile simulator is simply used for training and not for the actual purpose of transportation. I hope that example makes the difference between an emulator and a simulator clear.

An introduction to network simulation
Network simulation is the process by which a computer network is modelled by identifying, analysing and quantifying the interaction between various network devices and software. Mathematical modelling is used to study the behaviour of a computer network rather than using actual data. There are many advantages of doing this. Network behaviour under extreme conditions can be analysed very easily using a simulator. For example, consider a node (network simulation jargon to refer to a computer system) with mobility in a wireless network. We can very easily study the behaviour of a node having high velocity, using a simulator. In a physical network, achieving high velocity for mobile nodes is a very difficult task, and varying the velocity of mobile nodes for analysis purposes is time consuming and difficult.
Another situation where simulation becomes the natural choice is when the number of nodes in the network is very high. For example, if you want to study the working of a network with, say, a 1000 nodes, then simulation is the ideal choice, at least till you are sure about the results. Simulators are also suitable for network analysis if you have a limited budget, limited time, or you are not sure about the success of your proposed method or protocol.
While the previous paragraph lists out a few scenarios where network simulation is warranted, don’t assume that network simulation is an easy task. Simulating networks is difficult and developing a network simulator is an almost impossible task. Very often, I have lamented that it is far better to set up a network in hardware than use these simulators (at least, I used to in my younger days). To crown it all, sometimes the data obtained from the actual physical network may not corroborate the results obtained from the simulator. Having discussed all the many negative aspects of network simulators, I still believe they are excellent tools and all researchers should arm themselves with these potent tools.
Even though the ns class of simulators is the most widely used, there are other options in this field. There are QualNet, NetSim, OMNeT++, etc, which also are useful network simulators. If there are so many alternative network simulators, why is the ns class the most pervasive? QualNet and NetSim are proprietary tools and fail to address the important problem of reducing research costs, whereas the ns class of simulators is free and open source software that can be freely downloaded from the Internet. OMNeT++ is free software but it is not a complete simulator; rather, it is a simulation framework. So you have to develop your own modules before simulating the network, and this may not interest many potential users. So considering all these factors, I believe ns is the best tool available for a budding researcher in the area of computer networks.

A brief history of ns

The story of ns begins with a simulator called REAL, which was developed in 1989. This simulator has heavily influenced the first version of ns (called ns-1), which was developed in 1995. ns-1 was mostly a derivative work of the REAL simulator. The creation of ns-1 was initiated by the Lawrence Berkeley National Laboratory (LBNL), and later received large scale contributions from Sun Microsystems and Carnegie Mellon University. The core of the system was developed in C++ and simulation scripts were written using Tcl, a scripting language. Tcl is used as a binding language for generating simulation scripts, and saves a lot of time by avoiding unnecessary recompilation of the C++ core code every time a minor modification is made in the simulation scenario. This bi-language system was really beneficial in the earlier days when processing power was very low, but this approach is not necessary nowadays with processors measuring their speeds in gigaFLOPS and teraFLOPS.
The second version, ns-2, was initially made available for researchers in 1997. It was not very different from ns-1. The core of ns-2 was also developed in C++ with many of the features directly taken from ns-1. One major difference was that in ns-2, the binding language was OTcl rather than Tcl. OTcl is an object oriented dialect of Tcl developed by MIT. ns-2 was instantly adopted by many research communities all over the world, even though there were problems like a steep learning curve and a large number of bugs.
The third version of the network simulator, ns-3, was first released in 2008. The US National Science Foundation (NSF) funded the development of ns-3 by Tom Henderson and team. ns-3 is a free and open source discrete event simulator licensed under the GNU GPLv2 license. The latest version of ns-3 is ns-3.22, which was released in February 2015. Unlike ns-2, developers make sure that there are frequent and regular releases of ns-3. The close relationship between ns-1 and ns-2 has led to the misconception that ns-3 is also not very different from them. The decision to name the simulator ns-3 seems to be an ill-advised one, because a different name would have generated a larger fan base for this elegant software.

The relevance of ns-3
I believe people will let go of ns-2 only if the case for ns-3 is strong and convincing. That is my sole aim now. The importance of ns-3 is based on the fact that roughly one-third of all the projects done by computer science postgraduate students in India involve ns-2. This clearly tells us that ns-2 is quite popular with the academic community in our country. If ns-2 is so heavily used within academia, then why switch to ns-3? Well, papers with results depending on data obtained from the ns-2 simulator are no longer accepted by many prestigious journals for publication. Please refer to the Wikipedia article on network simulator (ns) to confirm this fact, at http://en.wikipedia.org/wiki/Ns_(simulator)#ns-3.
In spite of this, Indian students and researchers are still dependent on ns-2 for their data and results. And what is the condition of research publications in India? A quick search on the Internet tells us that the USA produces roughly 10 times more research papers than India. China’s output in research papers is roughly four times that of India. This tells us that the use of tools like ns-2, in fact, hampers the growth of research and research publication in India. Research publication is one of the indicators of a country’s development. So it is high time to migrate to advanced tools like ns-3 to increase our research output.
Another reason for the low adoption rate of ns-3 is that the research community often fails to understand that ns-3 is not backward-compatible with ns-2. ns-3 is an altogether new simulator, which is in no way related to ns-2. To my horror, even those claiming to be well versed in ns-2 have suggested that ns-1, ns-2, ns-3, and even ns-4 are no different at all. Frankly, there is no ns-4, and ns-1 and ns-2 are as different from ns-3 as chalk and cheese. This series on ns-3 aims to correct this fallacy once and for all.

A comparison of ns-2 and ns-3
ns-2 is network simulator version 2 and ns-3 is network simulator version 3. This wordplay somehow suggests that ns-3 is merely the next version of ns-2, a very common misconception held by many. There is nothing in common between ns-2 and ns-3 except that both are network simulators. ns-2 can act only as a simulator, whereas ns-3 has the ability to act as a simulator as well as an emulator. One tough decision made by the ns-3 development team was not to make ns-3 backward compatible with ns-2. If ns-3 was backward compatible with ns-2, it might have become more popular. But then the main advantage of ns-3 is that with freshly written code it has been possible to create a new core architecture capable of supporting long term development. So I believe the decision to scrap backward compatibility with ns-2 will benefit ns-3 in the long run.
Even though the cores of both ns-2 and ns-3 are in C++, the ns-2 source code didn’t have much impact on the development of the ns-3 source code. Another implementation level difference between ns-2 and ns-3 is regarding the binding language. The binding language (scripting language) associated with ns-2 is OTcl, whereas for ns-3, it is Python. With today’s faster computers, it is not mandatory to have a separate scripting language to save compilation time. So in ns-3, the use of Python scripting is limited or can be avoided altogether. The dependence on a bi-language platform is another difficulty while learning ns-2, because half your time is spent on understanding the binding between the compiled hierarchy (C++ code) and the interpreted hierarchy (OTcl code). This is no longer a problem with ns-3 because C++ alone is sufficient to simulate different networking scenarios.
Other than the implementation level differences, ns-2 and ns-3 also differ in terms of the network services provided, network devices supported, network protocols and networking scenarios that can be simulated, etc. Some of the models supported by ns-2 are not supported by ns-3 and vice versa. This is one area where ns-2 outperforms ns-3. The code base of ns-2 is still larger when compared with that of ns-3. For example, the wireless sensor networks supported by ns-2 are not yet implemented in ns-3. This drawback (the smaller code base of ns-3) is getting rectified as the source code of ns-3 increases in size, day by day. Another area where ns-2 has an advantage is regarding the large chunk of contributed code provided by third party developers. ns-3 is yet to gain such massive support from third party developers.
Another area where ns-2 and ns-3 differ is in data analysis, which is done with the help of a trace file. The trace file formats are different for ns-2 and ns-3. To view the topology of the simulated network, both ns-2 and ns-3 use animators. Animators show the node alignment as well as packet movement. ns-2 uses its own animator called Network Animator (Nam), which is a Tcl/TK based animation tool and supports topology layout and packet level animation. Figure 1 shows the Nam window for an ns-2 simulation with six nodes. Packet movement through the network is also shown in Nam. Circles in the figure are nodes, and packets are shown in red colour. ns-3 does not have its own animator to display network topology and packet movement; instead, it uses an animator called NetAnim, a standalone application, and it uses the custom trace files (for animation) generated by ns-3 to graphically display the simulation scenario. NetAnim is based on the Qt4 GUI toolkit. The animation trace file format generated by ns-3 for NetAnim will be discussed in detail in subsequent issues.

Another major difference between ns-2 and ns-3 is the way they have reached their present states, over a period of time. The difference is that ns-2 is software that has evolved, whereas ns-3 is planned software. Let me explain. REAL simulator was initially a single person’s venture and later on, more code was added to it to create ns-1. Then ns-1 was remodelled and modified to ns-2. In the beginning, nobody had any idea about the eventual fate of ns-2. Source code was added, bugs were fixed, patches were released and, eventually, the present day ns-2 evolved. But with ns-3, this process was altogether different. ns-3 was developed with clear goals and deadlines in mind. Consider the fact that any planned software worth its salt ought to have a mascot or an emblem, but you can’t find one for ns-2. Figure 2 shows the emblem for ns-3. So the moral of the story is, ‘Eventually planned software is going to be far more useful than software evolved over time.’ Yes, you have to trust me on this one—ns-3 is much better than ns-2. Moreover, nowadays ns-2 is only lightly maintained whereas ns-3 is maintained very fervently. To confirm this fact, please check the mailing list of network simulator (ns); topics related to ns-2 are mostly ignored whereas ns-3 topics often lead to heated debates.

Prerequisites for learning ns-3

Skills in certain programming languages and tools might be beneficial if you are planning to work with ns-3. A middle level understanding of C++ is the only essential requirement. A basic knowledge of socket programming with C++ is necessary for understanding ns-3, which I will cover in this series. Python based scripting is also supported in ns-3, so knowing the basics of Python will be a bonus. But remember, Python scripting is not essential in ns-3, so the lack of Python skills is not a barrier to learning ns-3. Two other tools used in conjunction with ns-3 are Doxygen and Waf. The former is a documentation generator tool. Knowing the basics of this tool will help you decode the ns-3 source files more easily. Waf is the build automation tool used by ns-3. A basic understanding of Waf is required for compiling ns-3 modules. I will discuss both these tools in the next issue. So, essentially, you can start this journey through ns-3 with me if you have middle level C++ skills, and a lot of patience.