The Performance Evaluation Metrics

Published Date: 02 Nov 2017

To simulate the modified routing algorithm (ETR-AODV) and compare its performance with existing AODV, we have used NS2 [30] version 2.34. The primary reason for choosing NS2 was its support of a multi-hop wireless environment. Secondly, as most of the studies cited in the literature there have used NS2 as their simulation environment.

5.1.1 NS2 (NETWORK SIMULATOR 2)

NS [30] is an event driven network simulator developed at UC Berkeley that simulates variety of IP networks. It implements network protocols such as TCP and UPD, traffic source behavior such as FTP, Telnet, Web, CBR and VBR, router queue management mechanism such as Drop Tail, RED and CBQ, routing algorithms such as Dijkstra, and more. NS also implements multicasting and some of the MAC layer protocols for LAN simulations. The NS project is now a part of the VINT project that develops tools for simulation results display, analysis and converters that convert network topologies generated by well-known generators to NS formats. Currently, NS2 (version 2) written in C++ and OTcl (Tcl script language with Object-oriented extensions developed at MIT) is available.

http://nile.wpi.edu/NS/Figure/fig1.gif

Figure 5.1 Simplified User's View of NS

As shown in Figure 5.1, in a simplified user's view, NS is Object-oriented Tcl (OTcl) script interpreter that has a simulation event scheduler and network component object libraries, and network setup (plumbing) module libraries (actually, plumbing modules are implemented as member functions of the base simulator object). In other words, to use NS, you program in OTcl script language. To setup and run a simulation network, a user should write an OTcl script that initiates an event scheduler, sets up the network topology using the network objects and the plumbing functions in the library, and tells traffic sources when to start and stop transmitting packets through the event scheduler. The term "plumbing" is used for a network setup, because setting up a network is plumbing possible data paths among network objects by setting the "neighbor" pointer of an object to the address of an appropriate object. When a user wants to make a new network object, he or she can easily make an object either by writing a new object or by making a compound object from the object library, and plumb the data path through the object. This may sound like complicated job, but the plumbing OTcl modules actually make the job very easy. The power of NS comes from this plumbing.

Another major component of NS beside network objects is the event scheduler. An event in NS is a packet ID that is unique for a packet with scheduled time and the pointer to an object that handles the event. In NS, an event scheduler keeps track of simulation time and fires all the events in the event queue scheduled for the current time by invoking appropriate network components, which usually are the ones who issued the events, and let them do the appropriate action associated with packet pointed by the event. Network components communicate with one another passing packets, however this does not consume actual simulation time. All the network components that need to spend some simulation time handling a packet (i.e. need a delay) use the event scheduler by issuing an event for the packet and waiting for the event to be fired to itself before doing further action handling the packet. For example, a network switch component that simulates a switch with 20 microseconds of switching delay issues an event for a packet to be switched to the scheduler as an event 20 microsecond later. The scheduler after 20 microsecond dequeues the event and fires it to the switch component, which then passes the packet to an appropriate output link component. Another use of an event scheduler is timer. For example, TCP needs a timer to keep track of a packet transmission time out for retransmission (transmission of a packet with the same TCP packet number but different NS packet ID). Timers use event schedulers in a similar manner that delay does. The only difference is that timer measures a time value associated with a packet and does an appropriate action related to that packet after a certain time goes by, and does not simulate a delay.

NS is written not only in OTcl but in C++ also. For efficiency reason, NS separates the data path implementation from control path implementations. In order to reduce packet and event processing time (not simulation time), the event scheduler and the basic network component objects in the data path are written and compiled using C++. These compiled objects are made available to the OTcl interpreter through an OTcl linkage that creates a matching OTcl object for each of the C++ objects and makes the control functions and the configurable variables specified by the C++ object act as member functions and member variables of the corresponding OTcl object. In this way, the controls of the C++ objects are given to OTcl. It is also possible to add member functions and variables to a C++ linked OTcl object. The objects in C++ that do not need to be controlled in a simulation or internally used by another object do not need to be linked to OTcl. Likewise, an object (not in the data path) can be entirely implemented in OTcl. Figure 5.2 shows an object hierarchy example in C++ and OTcl. One thing to note in the figure is that for C++ objects that have an OTcl linkage forming a hierarchy, there is a matching OTcl object hierarchy very similar to that of C++.

http://nile.wpi.edu/NS/Figure/fig2.gif

Figure 5.2 C++ and OTcl: The Duality

http://nile.wpi.edu/NS/Figure/fig3.gif

Figure 5.3 Architectural View of NS

Figure 5.3 shows the general architecture of NS. In this figure a general user (not an NS developer) can be thought of standing at the left bottom corner, designing and running simulations in Tcl using the simulator objects in the OTcl library. The event schedulers and most of the network components are implemented in C++ and available to OTcl through an OTcl linkage that is implemented using tclcl. The whole thing together makes NS, which is a OO extended Tcl interpreter with network simulator libraries.

This section briefly examined the general structure and architecture of NS. At this point, one might be wondering about how to obtain NS simulation results. As shown in Figure 1, when a simulation is finished, NS produces one or more text-based output files that contain detailed simulation data, if specified to do so in the input Tcl (or more specifically, OTcl) script. The data can be used for simulation analysis (two simulation result analysis examples are presented in later sections) or as an input to a graphical simulation display tool called Network Animator (NAM) that is developed as a part of VINT project. NAM has a nice graphical user interface similar to that of a CD player (play, fast forward, rewind, pause and so on), and also has a display speed controller. Furthermore, it can graphically present information such as throughput and number of packet drops at each link, although the graphical information cannot be used for accurate simulation analysis.

This section talks about the NS components, mostly compound network components. Figure 6 shows a partial OTcl class hierarchy of NS, which will help understanding the basic network components.

http://nile.wpi.edu/NS/Figure/fig6.gif

Figure 5.4 Class Hierarchy (Partial)

The root of the hierarchy is the TclObject class that is the superclass of all OTcl library objects (scheduler, network components, timers and the other objects including NAM related ones). As an ancestor class of TclObject, NsObject class is the superclass of all basic network component objects that handle packets, which may compose compound network objects such as nodes and links. The basic network components are further divided into two subclasses, Connector and Classifier, based on the number of the possible output data paths. The basic network objects that have only one output data path are under the Connector class, and switching objects that have possible multiple output data paths are under the Classifier class.

Organize the source code for Ns2 in the following directories:

ï‚·TCL: (Tool Command Language) An open source scripting language. It is used to program Ns2.

ï‚·TK: (Tool Kit) A GUI extension for TCL.

ï‚·OTCL: An extension to Tcl/Tk for object-oriented programming.

ï‚·TCLCL: Tcl/C++ interface

ï‚·NS2: Network Simulator Version 2

  http://www.geocities.ws/kaustubhnjoshi/project/software_files/image003.gif

Fig 5.4 NS Organization

5.1.2 Network Animator

Network Animator (nam) is a Tcl/TK based animation tool for viewing network simulation traces and real world packet trace data. The first step to use NAM is to produce the trace file. The trace file should contain topology information, e.g., nodes, links, as well as packet traces. Usually, the trace file is generated by ns. During an ns simulation, user can produce topology configurations, layout information, and packet traces using tracing events in ns. When the trace file is generated, it is ready to be animated by NAM. Upon startup, NAM will read the trace file, create topology, pop up a window, do layout if necessary, and then pause at the time of the first packet in the trace file. Through its user interface, NAM provides control over many aspects of animation.

In the NAM graphical interface, additional properties can be specified color, shapes, label, text, and marks. The Network Animator window and various tools available in it shown in Fig 5.5

D:\Sumit's Dissertation Stuffs\fwrtup\nam.jpg

Fig 5.5 Window of NAM

5.2 Performance evaluation metrics:

The Performance of ETR-AODV protocol was evaluated based upon packet delivery ratio, end-to-end delay, total average energy consumption and normalized routing load. These performances metric are defined as follows:

5.2.1 End-to-End Delay:

End-to-end delay is a measurement of the network delay on a packet and measured by the time interval between when a message is queued for transmission at the physical layer until the last bit is received at the receiving node. NS-2 measures this period as the average elapsed time between source transmission and sink reception. The end-to-end delay was measured in millisecond.

5.2.2 Packet Delivery Ratio:

This is the ratio of total number of packets successfully received by the destination nodes to the number of packets sent by the source nodes. Packet delivery fraction is an important metric as it describes the loss rate. Thus packet delivery fraction in turn reflects the maximum throughput that the network can support.

5.2.3 Normalized Routing Load:

Normalized routing load is used to determine the routing overhead caused by ETR-AODV packets in the network. Normalized routing load is the ratio of the number of control packets propagated by every node in the network and the number of data packets received by the destination nodes.

5.2.4 Energy Consumed:

The total average energy consumed by our algorithm is much not as much of AODV. Energy consumed is measured in Joule.

5.2.5 Simulation Factors:

Parameters which are varied during an experiment or simulation to study their effect on the system performance are called factors. Factors that are varied in the simulation include the MAC protocol, the number of nodes in a network, network aggregate packet rate in order to study the network lifetime, energy consumed/node, throughput, network delay, average energy consumed.