The Qos Enabled Protocol Simulation

Published Date: 02 Nov 2017

The methodology Chapter discusses how AODV protocol was implemented and analyzed for the comparison. This includes the platform i.e. Fedora and the tools such as ns2 (Network Simulator version, NAM (Network Animator) and Gnuplot. Then the core implementation is discussed.

7.1 Core Implementation

7.1.1 Basic Protocol Simulation:

This Chapter discusses how the AODV protocol was simulated and implemented. First the platform i.e. Fedora 8 was set up in a virtual environment. Then NS-2 was set up on the platform on which the above said protocols were implemented. NS-2 requires a script file to be run on it. These script files are written in a language called TCL (Tool Command Language). I have made use of shell scripting & Gnuplot for plotting of graphs.

7.1.2 QoS-Enabled Protocol Simulation:

In this thesis, a quality of service (QoS) architecture for supporting real-time data transmission in mobile Ad hoc networks (MANETs) is explored. The QoS architecture includes a QoS transport layer, QoS routing, queue management and a priority MAC protocol. Through simulations, it is found that the QoS architecture reduces packet loss and greatly improves the resource utilization in MANETs.

Providing support for real-time data transmission is an important yet challenging goal for MANETs. Much research has been done in each network layer to support real-time data transmission. Various routing protocols have been proposed for routing a data from source to destination. But these protocols do not provide admission control or find a path with large enough bandwidth to support a given request. Data communication is the result of each network layer’s effort; thus, the cooperation of all network layers is needed to provide QoS support. However, these designs are not comprehensive enough to include all the networking layers. Therefore, the QoS architecture proposed in this Chapter supports real-time data transmission. It extends from the application layer to the MAC layer to. This QoS architecture is described in the following section.

7.2 Bandwidth Estimation

In this thesis, I tried to improve QoS with major focus on Bandwidth parameter. Figure 7.1 shows the RREQ message format used in AODV protocol. For enhancing performance of the basic protocol one more field named "Bandwidth Required" is added in the given RREQ format as shown in Figure 7.2. The RREQ message contains information about message type, source address, destination address, broadcast ID, hop count, source sequence number, destination sequence number & request time (timestamp).

Whenever the source node issues a new RREQ, the broadcast ID is incremented by one. Thus, the source and destination addresses, together with the broadcast ID, uniquely identify this RREQ packet. The source node broadcasts the RREQ to all nodes within its transmission range.

Type

UNDEFINED

Hop Count

ID of Broadcast

Destination Address

Sequence Number of Destination

Source Address

Sequence Number of Source

Request Time

Figure 7.1 RREQ Message Format before QoS-Enabling

Type

UNDEFINED

Hop Count

Bandwidth Required

ID of Broadcast

Destination Address

Sequence Number of Destination

Source Address

Sequence Number of Source

Request Time

Figure 7.2 RREQ Message Format after QoS-Enabling

These neighboring nodes will then pass on the RREQ to other nodes in the same manner. As the RREQ is broadcasted in the whole network, some nodes may receive several copies of the same RREQ. When an intermediate node receives a RREQ, the node checks whether it has earlier received a RREQ with similar broadcast id as well as source address. The node cashes broadcast id and source address for first time and drops redundant RREQ messages. When the destination node receives first route request message, it generates so called reverse request (R-RREQ) message and broadcasts it to neighbor nodes within transmission range like the RREQ of source node does.

This RREQ packet is used to store the information of bandwidth required field & then used to compare it with the current requirement. And, the packet is forwarded to the next intermediate node only when it does have sufficient amount of bandwidth otherwise it is dropped & then it is re-transmitted.

Each host periodically estimates its own bandwidth use with MAC layer bandwidth estimation, and this information is disseminated to the host’s two-hop neighbors through "Hello" packets. Each host’s available bandwidth is estimated based on the bandwidth used by itself as well as each of its one-hop and two-hop neighbors. Either an admission control scheme is used during route discovery, or adaptive feedback is embedded in the route reply packets. This procedure is an extension to AODV.

7.3 Test procedure (Building & Testing)

7.3.1 Performance Analysis:

The performance analysis has been done on Fedora 8 as the Operating System. NS 2.34 was installed on the platform for simulating the protocols along with necessary software such as GnuPlot. The GnuPlot is a software for plotting graphs from the trace files. ns-2 is characterized by it’s object oriented and event driven nature. Researchers of wirless network protocols like TCP and UDP use ns-2 for simulation based study. ns-2 also useful for study of multicasting as well as protocols of MAC layer for Local Area Networks( LAN).

7.3.2 Traffic Environment:

The tests were performed on CBR traffic with 50 nodes. Packet size was set to 500 and the time interval between transferring the packets was set to 0.005 ms. Bit rate was set to 1 Mbps with a Drop Tail of 10 ms. As it is not easy to create traffic simulations for such large number of nodes manually, therefore the simulations were generated with the help of CMU traffic generator and the scenario was generated with the help of setdest, which are the tools preinstalled with the ns-2. The field configuration was set to 1500 by 1500 m. The simulations were performed under two protocols i.e. UDP and TCP as the base protocols. The reason for using two different protocols for analysis is that different MANET protocols behave differently under different environments because TCP and UDP use different parameters for communication such as different packet sizes, flags, different header lengths etc. Table 7.1 shows simulation parameters used for simulation of ns-2.

Table 7.1 Simulation Parameters of NS2

Name of the Parameter

Name of the variable

Type

Channel Type

chan

Wireless Channel

Radio-Propagation Model

prop

Two-Ray Ground

Network Interface

netif

Wireless Physical

MAC Type

mac

802_11

Interface Queue Type

ifq

DropTail-PriQueue

Max Packet In Interface Queue

Ifqlen

50

Routing Protocol

rp

AODV

Topography

x

y

x=1500

y=1500

Time Of Simulation End

stop

1000

7.3.3 Performance Metrics used for Analysis:

The following metrics were used for the comparison of the protocols:

i) Throughput: This is the effective share of bandwidth that the application is getting from the network.

ii) Bandwidth: This signifies the portion of the available capacity of an end-to-end network path that is accessible to the application or data flow. Consequently, the number of bits that are injected into the network by the various flows of an application have to be adjusted accordingly.

iii) Average Packet Delay: Average packet delivery time from a source to a destination. First for each source-destination pair, an average delay for packet delivery is computed. Then the whole average delay is computed from each pair average delay. End-to-end delay includes the delay in the send buffer, the delay in the interface queue, the bandwidth contention delay at the MAC, and the propagation delay. Network delay corresponds to the time it takes for application data units to be carried by the network to the destination. Network delay is caused by the combination of network propagation delay, processing delays and variable queuing delays at the intermediate routers on the path to the destination host. A great deal of delay may cause data unavailability and unintelligible real-time interaction, with frustrating consequences for the application user.

iv) Packet Delivery Ratio: It is a ratio of number of data packets delivered to the destination and the number of data packets sent by the source or number of data packets delivered over number of data packets generated. Number of data packets delivered is the total number of received data packets by destinations and number of data packets generated is the total number of generated data packets by sources. This metric can measure the delivery reliability and the throughput of the protocol.

v) Network Overhead Load : It is the ratio of total amount of overhead caused due to control routing packets and the amount of wireless bandwidth wasted to transmit the packets that are dropped in other links. So we can estimate how many transmitted routing messages are used for one successful data packet delivery by this metric to determine the efficiency and scalability of the protocol.