Improving Performance of MANET under DSR Protocol using Swarm Optimization to avoid redundancy
CHAPTER 5
Implementation and Testing
The implementation phase of any project development is the most important phase as it yields the final solution, which solves the problem at hand. The implementation phase involves actual materialization of the ideas, which are expressed in the analysis document and developed in design phase. Implementation of any software is always preceded by important decisions regarding selection of the platform, the language used, etc. These decisions are often influenced by several factors such as the real environment in which the system work, the speed that is required, the security concerns, other implementation specific details etc. Implementation should be perfect matching with the design document in order to achieve the necessary final product. For implementation of our system we use Network Simulator (NS) tool for simulation of the network and programming languages like Tool Command Language (TCL) and AWK are used for coding.
5.1 General Implementation
Implementation and simulation under NS-2 consists of 3 steps:
- Simulation Design
The first step in simulating a network is to design the simulation. In this step, the users should determine the simulation purposes, network configuration and assumptions, the performance measures, and the type of expected results
- Configuring and Running Simulation
This step implements the design described in the first step. It consists of two phases:
- Network configuration phase: In this phase network components (e.g., node, mobile sink, base station TCP and UDP) are created and configured according to the simulation design. Also, the events such as data transfer are scheduled to start at a certain time.
- Simulation Phase: This phase starts the simulation which was configured in the Network
- Configuration Phase. It maintains the simulation clock and executes events chronologically. An algorithm is a procedure or formula for solving a problem. A computer program can be viewed as an elaborate algorithm. In mathematics and computer science, an algorithm usually means a small procedure that solves a recurrent problem. The algorithms used in the project to solve the problem.
- Evaluation of Fitness Function
The fitness function F(x) is defined as follows:
F(x) = PDR/k – k*[NO + AD + PD]
Where, NO = Normalized Overhead
AD = Average End to End Delay
PD = Number of Packet drop
PDR = Packet Delivery Ratio
k = Proportionality constant used for the optimization of fitness function. Value of k lies between 0 & 1 i.e. O 1) Genetic Algorithm
Step 1. Simulate the network using the DSR protocol.
Step 2. After the simulation, analyze the Trace file. This gives the number of different paths for the same source and destination pair.
Step 3. Choose two paths PI & P2 for the same source and destination pair with the equal number of nodes ‘n’.
Step 4. Calculate the Routing Load (RL) MAC Load (ML),Packet Delivery Ratio ( PDR), End-to-End Delay (D), and number of packets dropped, for the selected path.
Step 5. Apply fitness function on the path chosen in step 3.
Step 6. Apply crossover on the path chosen in step 3 at random site.
Step 7. Apply mutation after crossover on the path chosen in step 3 on the randomly chosen site.
Step 8. Step 6 gives two new paths P’1 & P’2 with one new node as compared to the old path. Let the new node in path P’I be n’l and in P’2 be n’2.
Step 9. If n’ 1 belongs to network topology then apply the fitness function on the respective path otherwise discard the path.
Step 10. Do the same for node n’2 as in Step 9.
Step 11. Consider the path with the highest fitness function value and:- {
Respective path will be the optimal path for the given source and destination pair. The node replaced from the previous path is the misbehaving node.
}
2) Ant Colony Optimization
Step 1: Calculate the probability of selection of newly generated path that are obtain by applying genetic algorithm for the given source-destination pair. The path will be selected with the higher probability.
P
ðœ‚ij=
pheromone on the link.
ðœ‚ij visibility factor of the link.
B
k k is a constant used for optimization
and lies between 0 and 1
ð›¼, B are the constant aco optimization constant
Step 2: The backward ant accumulates the pheromone and also the evaporation of pheromone take place, now we calculate the updated pheromone after the evaporation,
ðœij=
(i,j) accumulated pheromone on the link.
FF Fitness Function
k proposnality
ðœnew=ρ*ðœold+ðœ
Step 3: The path with the higher path preference probability will be considered as the best path and the data transmission can be started along that path.
Network Simulator (Version 2), extensively recognized as NS2, is basically an event driven simulation tool that has established helpful in learning the dynamic environment of communication networks. Simulation of agitated as well as wireless network purposes and protocols for example, routing algorithms, TCP, and UDP can be completed using NS-2. In all-purpose, and then the NS-2 make available for the users by means of a way of identifying such network protocols and simulating their corresponding activities.
NS-2 is written in C++, with an OTcl1 interpreter as a command and configuration interface. The C++ part, which is fast to run but slower to change, is used for detailed protocol implementation.
The OTcl part, on the other hand, which runs much slower but can be changed very fast quickly, is used for simulation configuration.
One of the advantages of this split language program approach is that it allows for fast generation of large scenarios.
To simply use the simulator, it is sufficient to know OTcl. On the other hand, one disadvantage is that modifying and extending the simulator requires programming and debugging in both languages. NS-2 can simulate the following:
5.2.1 Basic Architecture of NS2
The basic architecture of NS2 is shown in the figure 5.1 below. NS2 provides users with executable command ns which take one input quarrel, the name of a Tcl simulation scripting file. Users are providing for the name of a Tcl simulation script as an input argument of anNS2 executable command that is ns.
In the majority suitcases, a simulation trace file is shaped, and is second-hand to plot graph and/or to construct animation. NS-2 consists of two key languages: C++ and Object-oriented Tool Command Language (OTcl). While the C++ characterizes the internal apparatus of the simulation objects, the OTcl sets up simulation by pull together and configuring the substance as well as preparation discrete events. The C++ and the OTcl are linked collectively by means of TclCL. Mapped to a C++ object; variables in the OTcl sphere of influence are occasionally referred to as switches. Theoretically, a handle for example, n as a Node handle is just a string in the Otcl sphere of influence, and does not surround any functionality. Instead, the functionality for example, receiving a packet is distinct in the mapped C++ object examples are, of class Connector. In the OTcl province, a handle take steps as a frontend which interrelated with consumers and other Otcl objects. After simulation, NS-2 outputs moreover text-based or animation-based simulation consequences.
Figure 5.1: Basic Architecture of NS2
To interpret these results graphically and interactively, tools such as NAM (Network Animator) and Xgraph are used. To investigate an exacting behavior of the network, clients can extract a relevant subset of text-based data and make over it to a more conceivable presentation
Tcl (Tool Command Language) is used by millions of people in the world. It is a language with a very simple syntax and it allows a very easy integration with other languages. The characteristics of these languages are as follows:
Some of the basics of Tcl and Otcl programming are listed below.
This module performs processing of output result set to compute the various performance metrics required to analyze the performance of flow slice based routing. This module includes following
The Fig 4.11 gives Flow chart for working of performance analysis module, Understanding the trace file format is essential for modeling performance metric computation. Manually interpretation of NS2 trace files for wireless simulation as follows
ACTION:[s|r|D]: s — sent, r — received, D — dropped
WHEN:the time when the action happened
WHERE:the node where the action happened
LAYER:AGT – application,
RTR – routing,
LL – link layer (ARP is done here),
IFQ – outgoing packet queue (between link and mac layer),
MAC – Mac,
PHY – physical
SEQNO:the sequence number of the packet
TYPE:The packet type
cbr – CBR data stream packet
ftp – FTP data stream packet
DSR – DSR routing packet (control packet generated by routing)
RTS – RTS packet generated by MAC 802.11
ARP – link layer ARP packet
SIZE:the size of packet at current layer, when packet goes down, size increases, goes up size decreases
[a b c d]:a – The packet duration in Mac layer header
b – The mac address of destination
c – The mac address of source
d – The mac type of the packet body
Figure 5.2: Flow chart for working of performance analysis module
An ns simulation starts with the command
set ns [new Simulator]
The first line in the tcl script. This declares a new variable NS using the set command. The code [new Simulator] is the instantiation of the class Simulator using the reserved word new.In order to have output files with data in the simulation (trace files) or files for visualization (nam files); we need to create the files using the “open” command as follows:
#Open the Trace file
set tracefile1 [open out.tr w]
$ns trace-all $namfile
#Open the NAM trace file
Set namfile [open out.nam w]
$ns namtrace-all $namfile
The above procedures create a data trace file called “out.tr” and a nam visualization trace file called “out.nam”. The second lines open the file “out.tr” to be used for writing, declared with the letter “w”. The third line uses a simulator method called trace-all that have name of file as parameter where the traces will go.
The termination of the program is done using a “finish” procedure.
#Define a ‘finish’ procedure
proc finish {} {
global ns tracefile1 namfile
$ns flush–trace
close $tracefile1
close $namfile
execnamout.nam&
exit 0
}
Xgraph is a plotting utility that is provided by ns. It allows to create postscript, Tgif files, and others, by clicking on the button “Hdcpy”. It can be invoked within the tcl command which results in an immediate display after the end of the simulation. The xgraph command expects one or more ASCII files as input containing each x-y data point pair perl line. Some of the options in xgraph are:
Title: use –t “title”.
Size: geometry xsize z ysize.
Title for axis: -x “xtitle” (for the title of the x axis) and –y “ytitle” (for the
title of the y axis)
Color of text and grid: with the flag –v
Command for the above options would be shown below
Xgraph ov.xg in terms of load units for the” overhead”,Xgraph dl.xg in terms of microsec “delay”,Xgraph pdr.xg percentage of delivered data for” packet deliver ratio”.
5.3 Network Animator (NAM)
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 script.
The data can be used for simulation analysis or as an input to a graphical simulation display tool called NAM. NAM has a nice graphical user interface.
It can graphically present information such as throughput and number of packet drops at each link NAM is started with the command ‘nam
Figure 5.3: A Simple NAM Window
5.4 Test Setup
The aim of testing stage is to discover defects/errors by testing individual program components. These components may be functions and the objects or modules. During system testing then these components are integrated to form the complete system. At this stage, of testing should focus on establishing that the system meets its functional requirements and does not behave in unexpected ways.
Test data are inputs which have been devised to test the system whereas test cases are inputs to test the system and the outputs are predicted from these inputs if the system operates according to its specification the result of this is used to examine the behavior in a cohesive system.
The test cases are selected to ensure that the system behavior can be examined in all possible combinations of conditions. Detecting all the different failure modes for software is generally infeasible. Software testing is used in association with verification and validation:
Testing is an integral part of software development. Testing process, in a way certifies, whether the product, that is developed, complies with the standards, that it was designed for Testing process involves building of test cases, against which, the product has to be tested.
In some cases, test cases are done based on the system requirements specified for the product/software, which is to be developed.
These following objectives imply a dramatic change in view port the testing cannot show absence of defects, it can only show that software errors are present.
5.4.1 Test Environment
The software was tested on the following platform.
5.4.2 System testing
Here the entire software system is tested and the reference document for this process is the requirements document the main goal is to see if the system meets its requirements.
Each module and component of project was thoroughly tested to remove bugs through a system testing strategy. Test cases were generated for all possible input sequences and the output was verified for its correctness. Test cases for system testing are mentioned below.
Software testing is the process used to help identify the correctness and completeness of developed system. Testing is a process of technical investigation that is intended to reveal if the system works in a way it is intended to operate. Testing furnishes a comparison that compares the state and behavior of the product against a specification. Software testing also provides an objective and the independent view of the software to allow the business to appreciate and understand the risks of software implementation.
5.4.3 Testing Artifacts
Software testing development shown with many artifacts and they are:
A test specification is normally known as test plan and the investigators are well conscious about what test plans determination is implemented and this information is made obtainable to administration and the developers.
The manager or the foremost supervisory plan is to put together them more careful when increasing the code or construction additional revolutionizes.
A traceability matrix is counters that draw a parallel necessity or propose for the documents to test documents and it is used to substantiate that the results are acceptable.
The test case in general consists of a exclusive identifier and obligation references from a design specification then the preconditions along with the events a series of steps known as actions to follow the input output and expected result including the actual result.
All these phases can be accumulated in a word central processing unit document, with the spreadsheet, and also the database, or other common repository.
The good number of frequent phrase for a collected works of test cases is a test suite.
The test suite frequently also contains more comprehensive instructions or goals for each collected works of test cases.
Numerous positions of standards or data are used to test the identical functionality of an exacting characteristic.
It is also helpful to manufacture this data to the client and with the creation of or a project.
The software apparatus, illustration of information input and output, and arrangements are all referred to cooperatively as a test harness.
The testing methods describe the approach that is used to test the working of the project.
These approaches tests whether the functionality of the project address with the existing requirements. Overall functionality of the project is also tested.
Types of test carried out are:
A unit test is a piece of code that invokes a unit of work and checks one specific end result of that unit of work.
If the assumptions on the end result turn out to be wrong, the unit test has failed. In unit testing and black-box testing then the white-box testing are done to check the correctness of the existing functionality.
Normal Manual testing has been done to check the correctness of the functionality of the project. Then the further results of each testing are depicted in the table the test case approach has been chosen out of the testing artifacts.
Integration testing is any type of software testing that seeks to verify the interfaces between the components against a software design.
Integration test may be performed all at once the top-down and bottom-up then significant piece first, some time integrating functional subsystems first and then integrating the subsystems in separate phases using any of the basic strategies.
Usually larger the project, the more important the integration strategy will be to the project.
Functional testing is the generation of test cases from specifications is a valuable and flexible approach to software testing application from very early system specification right through module specification Functional testing deriving test cases from program specifications.
Functional said to set of information used in test cases design not to what is tested also known as Specification based testing (from specifications) black-box testing (no view of the code)and the Functional and the specification description of intended program behavior either formal or informal.
Cite This Work
To export a reference to this article please select a referencing style below: