CHAPTER 4 SIMULATION MODEL AND PERFORMANCE METRICS

59 CHAPTER 4 SIMULATION MODEL AND PERFORMANCE METRICS 4.1 OVERVIEW OF SIMULATION MODEL The performance of a MANET routing protocol under varying network conditions is to be evaluated in order to understand the behaviour and assess the applicability of the protocol. Simulation is a tool which can be used to assess the performance of the protocol prior to implementing in a real-time environment. Network Simulator -2 (NS-2) version 2.30 (The Network Simulator - NS-2 Home page) was used in the present investigation. It records data regarding the traffic and saves in a trace file which can be used for detailed analysis. These trace files usually contains packet level information generated during packet transmission among nodes. The trace file format with two lines is shown below for reference. The relevant meaning for abbreviations is included in Table 4.1 and Table 4.2. LINE 1 S -T 0.500000000 -HS 9 -HD -2 -NI 9 -NX 300.00 -NY 350.00 -NZ 0.00 -NE 100.000000 -NL AGT -NW --- -MA 0 -MD 0 -MS 0 -MT 0 -IS 9.2 -ID 3.0 -IT CBR -IL 512 -IF 0 -II 0 -IV 32 -PN CBR -PI 0 -PF 0 -PO 0 LINE 2 R -T 0.500000000 -HS 9 -HD -2 -NI 9 -NX 300.00 -NY 350.00 -NZ 0.00 -NE 100.000000 -NL RTR -NW --- -MA 0 -MD 0 -MS 0 -MT 0 -IS 9.2 -ID 3.0 -IT CBR -IL 512 -IF 0 -II 0 -IV 32 -PN CBR -PI 0 -PF 0 -PO 0

60 Table 4.1 Wireless flags of trace file (Riswold 2003). Abbreviation Flag Type Value -t Double Time -Ni int Node ID -Nx double X coordinate of node -Ny double Y coordinate of node -Nz double Z coordinate of node -Ne double Node energy level s: Send r: Receive d: Drop f: Forward -Nl string Network trace level (AGT, RTR etc.) -Nw string Drop reason -Hs int Hop source node ID -Hd int Hop dest. node ID, -1, -2 -Ma hexadecimal Duration -Ms hexadecimal Source Ethernet address -Md hexadecimal Destination Ethernet address -Mt hexadecimal Ethernet type -P string Packet type -Pn string Packet type (cbr, tcp)

61 Table 4.2 IP and TCP flags for trace file (Riswold 2003). Event Flag Type Value -ls int Source address and port -ld int Destination address and port -lt string Packet type -ll int Packet size IP Trace -lf int Flow ID -li int Unique ID -lv int TTL Value -Ps int Sequence Number -Pa int Acknowledgement Number TCP Trace -Pf int No. of times packet forwarded -Po int Optimal forwards Compared to other competing simulators such as OPNET and GloMoSim, NS-2 offers the following unique characteristics (Lee Breslau et al (2000) and Sandeep Bajaj et al (1999)). NS is an event driven and object oriented simulator. NS uses a discrete event processor as its engine. NS performs sequential simulation NS uses a split programming model which includes C++ language for low level event processing and tcl language for high end processing such as configuration of protocol objects, nodes, routes and links.

In addition to that, NS offers the following additional features which made it a suitable choice for this present investigation: 62 Setting up of simulation scenarios: It is possible to create network topologies and define links between nodes. Apart from that it is possible to create traffic models with specific source and destination with workload. The node and link failures can also be monitored. Modifying existing protocols: In most of the cases, a common research objective might be modifying an existing protocol or proposing a new protocol and compare it with the existing protocol in NS. NS provides this possibility and an ideal choice for modification which is publicly available with a very good protocol library. 4.2 INSTALLATION AND CONFIGURATION The NS-2 was installed with Fedora Linux operating system. The 2.30 version of the NS-2 software was downloaded and installed based on instructions from http://www.isi.edu/nsnam/ns/. After installation, the./validate command was executed to ensure successful installation. After the validation process, the.bashrc file was modified to set the PATH correctly, LD_LIBRARY, and TCL_LIBRARY variables for the proper use of NS2. 4.3 SIMULATION SCENARIOS The simulation scenarios were established using Tcl programming. The traffic flows, movement patterns and other simulation environment variables were defined within the Tcl files. The 802.11 MAC protocol is defined to be the wireless channel and DSR is defined as the routing protocol. Each mobile node used a Two-

63 Ray Ground radio propagation model with an Omni antenna. The initial battery capacity of each node assumed to be 100%. The battery capacity of a mobile node was decremented in a predefined manner by the txpower and rxpower levels which remains constant throughout the simulation. In order to conform to the IEEE 802.11b specification, the datarate_ variable was set to 11 Mbps and the basicrate_ variable was set to 1 Mbps. These settings are important to change the default NS-2 setting of 2 Mbps. The CTS / RTS process used in IEEE 802.11b within NS2 normally generate huge volumes of data that made processing the trace files complicated. In order to restrict the processing of unnecessary data, the RTSThreshold_ variable was set to 3,000 bytes which restrict the processing of packets that have a size greater than 3,000 bytes. As per the definition, the simulation scenarios did not generate packets larger than 512 bytes which is well below the set RTSThreshold_ variable. In the present investigation, two different simulation scenarios, predefined scenario and random scenario were defined and detailed performance analysis was carried out. 4.3.1 Pre-defined Scenario In a pre-defined scenario, the topology, traffic flow and nodal movements are predetermined which is programmed in Tcl. These pre-defined setup of a network environment helps to verify and compare the functionality and performance of the modified DSR protocol with standard DSR protocol. Even though, in a real MANET environment, the changes in topology and node mobility are random and unpredictable in nature, an occurrence of congestion or failure of a node can easily be created in a pre-defined MANET situation which paves the way for more accurate and pointed analysis of the performance of the protocol. The pre-defined topology was created in a 1200 x 1200 meter grid with 17 nodes. The size of the topology was selected in such a way that it should provide adequate node spacing in order to minimize interference that cause dropping of

64 packets. Considering the size of the topology and node spacing, the speed of nodes is set at 10 meters per second. Each node had a maximum queue size of 50 packets. The five destination nodes were placed close to the border of the topology in a circular manner and the two source nodes located at the center as shown in Figure 4.1. The destinations were placed away from each other so that transmission interference and signal overlap could be avoided. The destination nodes were stdatic throughout the simulation and the source nodes moved in a clock-wise manner. The data transmission from the source defined to be transmitted during pause times through a pre-defined path and by using a hop of another stationary node. During transmission, few other intermediate nodes are moved inside the transmission range to provide alternate path to destination. In addition to that, the workload was intentionally increased in certain instance to cause congestion in the primary path. An example of a Tcl file used in a random scenario is given in Appendix 2. Figure 4.1 Initial Node position in a pre-defined topology.

65 Six different simulation iterations were carried out in sets of three. In the first set, the pause time was varied at 4, 10 and 20 seconds, by keeping the workload and data rate constant at 5 CBR and 200 PPS, respectively. This will create high, medium and low mobility scenarios. In the second set, the workload was varied at 10, 15 and 20 CBR traffic flows by keeping the pause time and data rate constant at 4 seconds and 200 PPS, respectively. This will result in low, medium and high workload scenarios. For example, in a 10 CBR workload scenario, one source node transmit two CBR traffic to three destinations and the another source node transmit two CBR traffic to other two destinations. In case of 15 and 20 CBR workload, the number of traffic flows from the source node proportionally increased to 3 and 4 CBR, respectively. 4.3.2 Random Scenario In realistic situations, MANETs consists of mobile nodes that move and generate traffic randomly. In order to validate the functionality of the modified DSR in diverse and unpredictable random environment, a random scenario was created with NS-2. In the random scenario, the topologies, CBR multimedia traffic flows and movement patterns were created randomly. The random topology consisted of 800 x 800 meter grid with 20 nodes. This smaller topology was used to create a densely populated network that did not consider spatial boundaries or interference as considered in pre-defined scenario. The packet sizes of CBR multimedia streams were fixed at 512 bytes with each node had a maximum queue size of 50 packets. The simulation time was set to be 400 seconds and the speed of the node is 10 m/s. The scenarios were similar to the pre-defined scenario with varying mobility and workload environment. An example of a Tcl file used in a random scenario is given in Appendix 3.

66 During the random scenario simulation, the traffic flows and movement patterns were randomly created using the cbrgen.tcl and setdest.exe utilities of NS- 2. The pattern for CBR is as follows: ns cbrgen.tcl [-type cbr tcp][-nn nodes][-seed seed][-mc connections][-rate rate] These utilities create text files for repeatable use and testing. Within these text files, the random traffic flow and movement patterns were defined. The generated text files were referenced and called from within the Tcl files which allowed both the standard and modified DSR protocols to be tested using the same movement and traffic flow pattern. 4.4 PERFORMANCE METRICS In streaming multimedia applications, throughput alone cannot be considered as performance indicator and that mobility may have a deceive effect on other parameters. Reide and Seide (2003) insisted on measuring packet loss, endto-end delay and jitter to further validate the network performance. (Durkin 2003) stated that packet loss and delay are the most important measures for CBR traffic. In the present investigation, the performance metrics such as throughput, average jitter, average end-to-end delay, packet delivery fraction (PDF) and percentage packet loss were calculated and evaluated for both normal DSR and modified DSR. The above mentioned performance metrics were calculated as follows: 4.4.1 Throughput Number of bytesreceived 8 Throughtpu t kbps (4.1) Time 1000

67 The instant throughput can be computed if the time been considered as instant time. Similarly, the average throughput can be computed using the same relationship by considering the time as total simulation time. 4.4.2 Average Jitter Jitter is a measure of variation in delay across multiple packets associated with a given traffic flow. In streaming multimedia applications, only a small and limited amount of jitter is tolerable. 4.4.3 Average End-to-End Delay The average end-to-end delay is a measure of average time taken to transmit each packet of data from the source to the destination. Network congestion is indicated by higher end-to-end delays. 4.4.4 Packet Delivery Fraction (PDF) PDF is the ratio of successfully received packets to the number of sent packets. A higher PDF value indicates a good network performance with lower packet loss. 4.4.5 Percentage Packet Loss Number of packetssent - Number of packets received % Packet loss 100 (4.2) Number of packetssent In pre-defined scenarios, the performance metrics were calculated using the generated trace files. The $tracefd variable of the Tcl file can establish the

68 parameter and specify the trace file for a particular simulation scenario. The data stored in the trace file can be imported as an external data and then it can be graphed for further comparison. Within the Tcl files, the performance metrics concerning traffic to a particular destination were also calculated using the record procedure. The data can be collected by repeating this procedure every five seconds. In random scenarios, it is very difficult to capture the traffic details of individual nodes since there is no predefined source or destination nodes. The nodes assume their role as either source or destination during the start of the simulation and communicate via intermediate nodes available at that instance. Hence, different awk programs were used to extract the performance metrics from the generated trace files. For example, the average throughput can be calculated by giving the following command: > awk -f throughput.awk dsr-highmobility.tr > throughput.out The throughput.awk is the program which calculate the throughput by using the data generated in the trace file dsr-highmobility.tr and give the output in throughput.out file. Similarly, the other performance metrics can be calculated using the same procedure with the help of corresponding awk programs. A sample awk program is given in Appendix 4.