Simulators are forming an increasingly large role in many fields. In Biology, simulators are used for protein folding [160] in attempts to cure cancers. The defence industry have used simulators for battlefield tactics [161] and the modelling of entire socio-political countries [162]. There are several types of simulators. This section discusses discrete event, Monte Carlo and continuous event simulation.
The Monte Carlo [163] technique, coined by Ulam, involves randomness. A range of random inputs are generated; these are analysed using a deterministic model and the output recorded. The statistical
44
analysis of the output provides the approximate answer. As the number of inputs increase, so does the accuracy of the output. This method is useful whenever the possible range of inputs is too large to be performed systematically. This technique saw great use with nuclear experimentation but is also now used in financial and telecommunication systems evaluation as well as physical sciences.
A continuous event simulation is used for biological and social systems that can be described using differential equations [164]. The equations are estimated and then periodically solved to produce a feedback loop that can then affect the state of the simulation.
Discrete event simulation performs a series of events at specified intervals. This technique of simulation maintains a monotonic clock and events occur at a discrete time. A list is maintained of pending events to be simulated. Each event in the simulation may affect the finite state machine, causing a range of other events to occur. For example, a Request To Send packet in ns-2 will generate a Clear To Send packet; these events occur at discrete time values and affect each node’s finite state machine. The output is a trace of all events that have occurred during the simulation and the system time at which they occurred. Examples of this type of simulator are ns-2 [5] and Avrora [165].
4.1.1
ns-2 the Network Simulator
The Network Simulator 2 (ns-2) [5] is a discrete event network simulator which is heavily used in research for modelling and evaluating protocols. A Linux environment is required for ns-2 as well as the Tool Command Language (TCL) [166] and Tk framework [167]. Creating new simulations requires programming knowledge of OTcl [22]. ns-2 itself is open source and has many contributors to its source code including Defence Advanced Research Projects Agency [168], Palo Alto Research Center [169] and University of California Berkeley [170]. Contributed code includes many areas such as routing, wireless, satellite, topology, transport and application. The contributed code for wireless simulations allows improved Medium Access Control (MAC) and physical layer modelling. There is a large amount of open source activity relating to the wireless code and this reflects the amount of interest and the importance in teaching this wireless technology. Contributions provide source code for new standards (e.g. IEEE 802.15.4 [171]), revisions of existing ones and patches for the system. ns-2 is developed using the language C++ [172] due to its speed. A disadvantage is that changes made to any C++ file require a recompilation of the whole project. This disadvantage is countered by using OTcl. OTcl allows interactions between objects created in C++ and OTcl. This gives ns-2 the flexibility to allow scripting of complex scenarios in OTcl without having to recompile for every new scenario. Drawbacks to this approach are the requirement to either run predefined scenarios or having to learn OTcl, and the requirement of a Linux environment. Using the official API to program the OTcl code has proven to be difficult and often cryptic. Several methods that are specified in the API do not exist in the OTcl space. Other OTcl scripts compile without error but then cause an irrecoverable termination of the simulation. Tracking down such bugs is both time consuming and difficult. Network Animator (NAM) is provided with the ns-2 release. NAM requires X-Windows
45
libraries to run and is written in TCL/TK. It is used to animate trace files generated from an ns-2 simulation. The performance of NAM is limited as it has a variety of bugs and can only support a limited range of animations.
An ns-2 simulation has an initialisation [173] step which creates the packet format, a scheduler and an agent. The scheduler selects and executes the next time ordered event. The simulator is single threaded only. A topology needs to be created in ns-2 and this is done using the primitive ns. The node is a standalone OTcl class and consists of two Tcl Objects, an address and a port classifier. All nodes contain an id, (which is monotonically increased from 0) a list of neighbours, agents, a node type and a routing module.
Nodes can be configured using the node-config setting in OTcl. An example of how the node is configured is shown in Figure 15. In this example the type of MAC protocol, queue type, antenna type, routing protocols and components that should be traced for review are configured.
$ns node-config -adhocRouting DSR \ -llType LL \ -macType Mac/802_11 \ -ifqType CMUPriQueue \ -ifqLen 32768 \ -antType Antenna/OmniAntenna \ -propType Propagation/Shadowing \ -phyType Phy/WirelessPhy \ -channelType Channel/WirelessChannel \ -topoInstance $topo \ -agentTrace ON \ -routerTrace ON \ -macTrace ON \
Figure 15: OTcl code fragment that defines a range of node properties
When a node receives a packet, the packet’s fields are examined and then the values are mapped to an outgoing interface, which is another object. This analysis is done using the classifier object and a table lookup to calculate where to send the packet. The packet is examined and forwarded onto the appropriate agents or outgoing links. Routing modules can also be developed and inserted into ns-2. A routing module can consist of three parts:
• Routing agent – Exchanges a routing packet with neighbours
• Route logic – Uses information gathered by routing agents to perform route computation • Classifier – Located at the actual node and uses the computed routing table for packet
forwarding
Agents are a core concept of ns-2 and are the source of network packets construction and consumption and are created in the OTcl segment. The agents know the source and destination addresses, size and type of packets. There are several Protocol Agents in ns-2 including: TCP, TCP/Reno, TCP/Vegas, UDP, RTP and RTCP. An example of how to define an OTcl agent is shown in Figure 16. In this example a TCP connection is made between two nodes and then an FTP [174] transfer takes place. In this example, the communication starts at time 0 and continues for 0.5 seconds.
46 set protocolDescriptor4 [new Agent/TCP] $protocolDescriptor4 set class_ 2 set sinkDescriptor6 [new Agent/TCPSink]
$ns attach-agent $node_(1) $protocolDescriptor4 $ns attach-agent $node_(0) $sinkDescriptor6 $ns connect $protocolDescriptor4 $sinkDescriptor6 set applicationDescriptor5 [new Application/FTP]
$applicationDescriptor5 attach-agent $protocolDescriptor4 $ns at 0.0 "$applicationDescriptor5 start"
$ns at 0.5 "$applicationDescriptor5 stop"
Figure 16: OTcl code fragment for defining a TCP Agent
Figure 16 demonstrates that OTcl is quite cryptic and presents a barrier to using ns-2 as a learning tool. This is not a criticism of ns-2, which has not been designed as an educational tool.