[ mobility | traffic pattern | Back to Network Simulator 2 for Wireless ]
1.Node Movement and Topology Generation
Instead of specifying and control each nodes' position and movement pattern, we use a CMU tool "setdest" to generate large number of nodes and there movements. The tool use a random waypoint model.
Setdest tool is used to generate the positions of nodes and their moving
speed and moving directions.
The syntax is:
setdest -v 1 -n $numnodes -p $pt -M $maxspeed -t $simtime -x $maxx -y $maxy
for example: setdest -v 1 -n 50 -p 0 -M 20 -t 900 -x 1500 -y 300
will generate a 1500*300 topology with 50 nodes random distributed labeled by a XY(Z) coordinates. ( Note that, there is a bug in the README file, which gives a wrong option for specifying the speed, we should use "-M" instead of "-s" ).
After the initial position information, the nodes are specified with their movement destination and speed.
After that, the initial distance (hop counts) information are counted by a GOD. Currently, the god object is used only to store an array of the shortest number of hops required to reach from one node to an other. The god object does not calculate this on the fly during simulation runs, since it can be quite time consuming. The information is loaded into the god object from the movement pattern file (this file)..
Then, the nodes are going to move during this 900-second simulation scenario. During this, the distance (hop-counts) information is going to change, thus, the following lines are going to show this recent change. Note that the distance is calculated based on a nominal radio change as "250" meters. The god information should not be available to any of the node. Thus, for a routing protocol, it has to discover the distance by itself with some mechanism.
It's possible that a node reaches its destination before the simulation timer ends. Thus, it needs to re-specify a new direction and speed for it. Also, the average pause time is a parameter to allow a node stop to move in a destination before moving again.
Finally, there are some statistics about this movement file? During the simulation, some nodes get isolated from all other nodes which results one count of "destination unreachable". Also, all route changes and link changes are calculated.
$ns_ at 0.000000000000 "$node_(0) setdest 298.258250355189 34.553480936942 5.763540789209"
$god_ set-dist 0 1 6
$ns_ at 0.141920608238 "$god_ set-dist 17 24 2"
$ns_ at 12.602131706040 "$god_ set-dist 16 36 2"
$ns_ at 899.907548331028 "$god_ set-dist 32 40 1"
for generate scenarios in a patch, we could use following shell scripts.
2. Traffic Pattern Generation
Random traffic connections of TCP and CBR can be setup between mobilenodes using a traffic-scenario generator script. This traffic generator script is available under ~ns/indep-utils/cmu-scen-gen and is called cbrgen.tcl. It can be used to create CBR and TCP traffics connections between wireless mobilenodes. In order to create a traffic-connection file, we need to define the type of traffic connection (CBR or TCP), the number of nodes and maximum number of connections to be setup between them, a random seed and incase of CBR connections, a rate whose inverse value is used to compute the interval time between the CBR pkts. So the command line looks like the following:
ns cbrgen.tcl [-type cbr|tcp] [-nn nodes] [-seed seed] [-mc connections][-rate rate] >output.tclThe start times for the TCP/CBR connections are randomly generated with a maximum value set at 180.0s, thus the simulation time is at least 180 seconds. And the number of nodes has no relationship to the maximum number of connections (mc), we can have 10 nodes, also 10 connections as one node could have multiple simultaneous connections to other nodes. The parameter "rate" means how many packets per second, thus, for CBR traffic, the packet intervel is the reversal of this parameter. And for TCP traffic, we don't have to specify rate, ftp connections are going to be used. the default packet size is 512B. Actully, we can change all this in the "output.tcl" file.
Note that there is no guarantee that the number of connections are created and the actual nodes involved as source and sink. A typical generated CBR traffic file looks like:
The last lines shows how many actual connections are created and how many nodes are used for the source.