My Wiki!

Table of Contents

NS3 Tutorial: Getting Started

Installation

1. Bake vs release vs waf

1.1 Bake

Bake can be configured to download and build ns3: 

  ns-3.26: the module corresponding to the release; it will download components similar to the release tarball.
  ns-3-dev: a similar module but using the development code tree
  ns-allinone-3.26: the module that includes other optional features such as click routing, openflow for ns-3, and the Network Simulation Cradle
  ns-3-allinone: similar to the released version of the allinone module, but for development code.

The sources are downloaded to a folder and bake compile everything there. 

$ export BAKE_HOME=`pwd`
$ export PATH=$PATH:$BAKE_HOME:$BAKE_HOME/build/bin
$ export PYTHONPATH=$PYTHONPATH:$BAKE_HOME:$BAKE_HOME/build/lib

This will put the bake.py program into the shell’s path, and will allow other programs to find executables and libraries created by bake. Although several bake use cases do not require setting PATH and PYTHONPATH as above, full builds of ns-3-allinone (with the optional packages) typically do.

Configure. Step into the workspace directory and type the following into your shell: 

  $ ./bake.py configure -e ns-3.26

Download: 

  bake.py check
  bake.py download

Build: 

  bake.py build

1.2 NS3 release

Download and build only ns3 tarball. If you downloaded using a tarball you should have a directory called something like ns-allinone-3.26 under your ~/workspace directory. Type the following: 

./build.py --enable-examples --enable-tests

1.3 Waf

Up to this point, we have used either the build.py script, or the bake tool, to get started with building ns-3. These tools are useful for building ns-3 and supporting libraries, and they call into the ns-3 directory to call the Waf build tool to do the actual building. Most users quickly transition to using Waf directly to configure and build ns-3. So, to proceed, please change your working directory to the ns-3 directory that you have initially built.

$ ./waf clean $ ./waf configure –build-profile=optimized –enable-examples –enable-tests

Run Simulation

1. Source dir

Source dir under ns-3.xx/scratch 

[dang@dai142 scratch]$ tree
.
├── mytut
│   └── myfirst.cc
├── scratch-simulator.cc
├── subdir
│   └── scratch-simulator-subdir.cc
└── waff.source

All *.cc in a folder will be linked to a single executable with the name is folder name. The same name is used when run experiment. TBD details on using multiple *.cc or modules files.

2. Compile, Run

Because execution is always from waf-dir, this makes all output files are put here instead.

Change working dir to scratch as follow. Source script make it more convenient. 

cat waff.source 
#!/bin/bash

function waff {
    CWD="$PWD"
    #cd $NS3DIR >/dev/null
    #./waf --cwd="$CWD" $*
		cd $(hg root) && ./waf --cwd="$CWD" $* 
    cd - >/dev/null
  }

source waff.source

Build all project with updated configuration and simulation sources: 

  waff build

Run in scratch 

  waff --run scratch-simulator

Run myfirst.cc in subdir mytut 

  waff --run mytut

Creating Simulation

1. Concepts

2. Topology Construction

2.1 The Helper/Container API

We want to:

  • Make it easy to build topologies with repeating patterns
  • Make the topology description more high-level (and less

verbose) to make it easier to read and understand

The idea is simple:

  • Sets of objects are stored in Containers. Example containers: NodeContainer, NetDeviceContainer, Ipv4AddressContainer
  • One operation is encoded in a Helper object and applies on a Container. Example helper classes: InternetStackHelper, WifiHelper, MobilityHelper, OlsrHelper, etc. Each model provides a helper class

Helper operations:

  • Are not generic: different helpers provide different operations
  • Do not try to allow code reuse: just try to minimize the amount of

code written

  • Provide syntactical sugar: make the code easier to read

2.2 Sample project

3. Create Module

4. More resources

  • OpenFlow13 module (Brazil): really good work, virtual machine available

OpenFlow to LTE: some issues toward Software-Defined Mobile Networks”. In: 7th IFIP International Conference on New Technologies, Mobility and Security (NTMS), 2015.


Trace: • java_rest • pro_django • android_native • python_begin • 0_java_begin • embedded_programming_resources • graph_api_jscript • git_svn_workflow • 0_getting_start

Navigation