Description of the ns-2 modifications

Description of the ns-2 modifications

Jump to the files

This page describes some modifications I did in ns-2 that could be included in the main version. While changing the simulator to have multiple wireless interfaces listening on different channels on a single node I found several parts of the basic ns-2 structures quite annoying. They were unreadable, almost impossible to understand, etc...For example, in the class Node there was a method called nextchannel(). One could expect to get the "next" channel by calling this function but actually you proceed to the next node connected to some channel. To which channel? You cannot know this, because the channel controls the pointers of this... Which directly leads to one of the most annoying flaws in the design: if you have two channels on the same node both will use the same pointers to create a linked list. This can lead to lists with loops in it.

There are some more problems very similar to that. If you want to add an interface to a node, you would have to call "interface->insertnode(&ifhead_);" on the node... For me it looks like adding a node to the interface and not the other way round.

Annother annoying thing are all the different *Node classes (ParentNode, NixNode, ...). For example Node is dereive from ParentNode but both have address_ and nodeid_. This can result in problems. I changed the address function of the Node to be const. Then all the time the ParentNode was used to call address() a different value was returned. The problem could easily be solved by simply deleting the duplicated entries from the Node class.

What I did

I did some code cleanup with all those lists mysteriously created by ns-2. First of all I used std::list datastructures wherever possible. In addition, in the wireless channel class I changed the logic of the list based improvement: instead of keeping an own list of nodes, the already existing list of interfaces is used. Instead of getting all affected nodes all affected interfaces are searched, which is much more straight forward.

Update: I changed the data structure for the nodes to b a vector. That way I can do a binary search for get_node_by_address. For large scenarios this can be considerably faster.

Why it should be included in the ns-2

The code is now clearer, easier to read, and it is now easier to use multiple wireless interfaces on a single node (although, to make it comfortable more code is needed and I haven't yet tested it thoroughly enough).

I ran the validation tests on the modified version and the results were the same as on the unmodified version. Actually, i also found a bug in a validation test (using dsr as routing protocol instead of DSR).

Adding multiple wireless interfaces

To add more than one wireless interface to a node this code might be an example

set chan_1 [new $val(chan)]


set chan_2 [new $val(chan)]




$ns_ node-config -adhocRouting $val(rp) \


             -llType $val(ll) \


             -macType $val(mac) \


             -ifqType $val(ifq) \


             -ifqLen $val(ifqlen) \


             -antType $val(ant) \


             -propType $val(prop) \


             -phyType $val(netif) \


             -channel $chan_1 \


             -topoInstance $topo \


             -agentTrace ON \


             -routerTrace ON \


             -macTrace ON \


             -movementTrace OFF




set node1 [$ns_ node]


$ns_ node-config  -channel $chan_2


set node2 [$ns_ node]

Now you have two nodes with one interface each. They are on different channels and cannot hear each other. The folowing is a conveniance function, i simply add this to my simulation scripts.

proc addInterface { node channel } {


    puts "Adding channel [$channel get-channel-id] to node [$node node-addr]"


    global ns_ val


    set propInstance [$ns_ set propInstance_]


    set topoInstance [$ns_ set topoInstance_]


    set inerrProc_ ""


    set outerrProc_ ""


    set FECProc_ ""


    if { [$ns_ info vars inerrProc_] ne "" } {


        set inerrProc_ [$ns_ set inerrProc_]


    }


    if { [$ns_ info vars outerrProc_] ne "" } {


        set outerrProc_ [$ns_ set outerrProc_]


    }


    if { [$ns_ info vars FECProc_] ne "" } {


        set FECProc_ [$ns_ set FECProc_]


    }


    $node add-interface $channel $propInstance $val(ll) $val(mac) \


        $val(ifq) $val(ifqlen) $val(netif) $val(ant) $topoInstance \


        $inerrProc_ $outerrProc_ $FECProc_


    puts "Node [$node node-addr] has now [expr $nifs+1] interfaces"


}

Now I add a second interface to the two nodes.

add-interface $node1 $chan_2


add-interface $node2 $chan_1

As result I now have two nodes with two wireless interfaces: one listening on channel1 and the other one listening on channel2.

Keep in mind that the routing has to select the proper interface for communication. As far as i know, the included routing protocols only use a single interface (the first one created).

Communication on channel1 does not affect communication on channel2

Files

Here you can get the patch against the cvs version of ns-2

patch for the cvs version (0.2)

patch for the cvs version

Here you can download a modified version of the ns-2 source code modified ns-2 source code

Open Issues

Quite a lot actually...

• most important for me is the improved support for multiple interfaces on a single node. This also includes channel switching, dynamic creation and configuration of interfaces, etc...
  
• more code cleanup could be done in the (Mobile)Node and the interfaces code
• can't we get rid of the GridKeeper? It does not seem to be in use...
• It seems that TORA cannot be used anymore, shouldn't all malfunctioning modules be removed? They could be moved to some kind of attic in which they wait for someone to fix them (If nobody cares about the modules they will be forgotten)
• (I will not repeat everything that has been said over and over again: packet format, evil otcl, ... )

from : http://www-i4.informatik.rwth-aachen.de/mcg/projects/NS-2%20Modifications