For the next stage of my thesis instead of using the well known ns-2 simulator as originally planned, I have opted to instead use ns-3. I have chosen this particular environment because it seems to be designed from the ground up to be a wireless simulation tool while ns-2 was originally designed solely for wired network simulation. I have made some use of ns-2 however, so if you are looking for a guide to getting that working in Ubuntu see my post "[NS-2.33 on Ubuntu 8.04 Hardy Heron](https://www.jasonernst.com/posts/2008/06/11/ns-233-and-nam-on-ubuntu-804-hardy-heron)". In addition to this, ns-3 no longer uses the tcl scripting language. Instead the choice of pure c++ or a combination of c++ and python may be used to define the simulation parameters. I prefer this approach because I have no desire to learn tcl and find the c++ ns-3 ot be more intuitive than ns-2. Additionally, this guide will be used as a reference for myself while I learn the ns-3 environment. Check back for regular updates and useful infromation.
So back to the point of this article, a guide on how to install ns-3.2 on Ubuntu 8.04 Hardy Heron. Ns-3 installation is quite simple since an automatic build tool named `waf` is used to build the project. Enter the following in the terminal to download, untar and build ns-3.2.
```
wget http://www.nsnam.org/releases/ns-3.2.tar.bz2
tar -xvf ns-3.2.tar.bz2
./waf -d debug configure
```
**How to start working with NS-3**
So from here on out, all you have to do is use the waf tool for compiling and running your ns3 simulations. There are many example scenarios located in the /examples folder. You can run a simulation with any of the scenarios using the waf command. For example if you wanted to run a scenario file named first.cc you would enter the following command:
`./waf --run=first`
Notice that you do not need to include the .cc on the filename. If you do happen to misspell the file, ns3 will provide you with a list of all of the scenarios you are able to run. One other important note is that the /scratch folder automatically includes the .cc files as scenarios which you can run. This is likely where you will want to place your new scenarios when working on them. (If you try to put them in the examples folder you will need to edit the wscript file (see NS3 tutorial on how to do this). On other important thing to note is that ns3 supports improved logging / output compared with ns2 using the pcap file format which can be read using tcpdump or wireshark. These types of files were originally used for packet capturing in real working networks so it makes alot of sense to include this ability in simulation as well.
**How to display exactly what is going on to the screen (Logging)**
Sometimes when making changes and implementing something new, it is helpful to show everything that is happening on the screen. You can achieve this by entering the following at the linux command line:
`export 'NS_LOG=*=level_all|prefix_func|prefix_time'`
If you want to restrict the information to only certain parts of the simulation, for example the MAC layer of a wifi AP you could do something like this:
`export 'NS_LOG=NqapWifiMac=level_all|prefix_func|prefix_time'`
For more information on how to configure the logging to do exactly what you want, see the NS3 Tutorial section on logging.
If you have turned on logging, you have likely noticed that ns3 generates so much information that it scrolls by way to fast to be of any use. So you will probably want to output the results to a file. For example if you were running the first.cc file again and you have turned on logging you could do this:
`./waf --run=first >& first.txt`
which would send the logging output to the file first.txt where you could easily read it.
**Useful Functions**
So far I have found these functions make debugging scenarios easier:
```
static Vector
GetPosition (Ptr<Node> node)
{
Ptr<MobilityModel> mobility = node->GetObject<MobilityModel> ();
return mobility->GetPosition ();
}
static Ipv4Address
GetAddress (Ptr<Node> node, uint32_t interface)
{
Ptr<Ipv4> ipv4 = node->GetObject<Ipv4> ();
return ipv4->GetAddress(interface);
}
```
**Tips**
The following are a few important things I’ve discovered that may save you time when trying to work with ns3 on certain tasks:
* When simulating an ad-hoc or wireless mesh network using OLSR, make sure you set your mobility model before you install the OLSR routing on the nodes. If you do not do this, OLSR may generate link pairs for links which are actually too far away to communicate because before the mobility model is installed on the nodes they are all close enough to communicate.
* Also with OLSR, make sure you give OLSR enough time to determine the network topology before you allow the applications to start running on the network. I have read that about 100s of waiting time before starting is enough, however I imagine as the network size grows this may also grow (I have tested with a size of 4×4 and this is enough time – I will adjust this as I play with the numbers as well)
**Useful Links**
* [NS3 Doxygen Documentation](https://web.archive.org/web/20140122160300/http://www.nsnam.org/doxygen-release/index.html)
* [NS3 Tutorial](https://web.archive.org/web/20140122160300/http://www.nsnam.org/docs/tutorial.html)
* [NS3 Manual](https://web.archive.org/web/20140122160300/http://www.nsnam.org/docs/release/manual.html)
* [NS3 Wiki](https://web.archive.org/web/20140122160300/http://www.nsnam.org/wiki/index.php/Main_Page)