International Journal of Scientific & Engineering Research, Volume 5, Issue 6, June-2014 145

ISSN 2229-5518

High packet delivery ratio with low end to end delay using ICCBCC_AODV for multimedia

applications

Poonam N Gholap Computer department, VIT,Mumbai University Poonamgholap04@gmail.com
Rinku Shah Computer department, VIT,Mumbai University Rinku.shah@vit.edu.in

ABSTRACT- Meeting bandwidth demand successfully is one of the important issue for multimedia application. In this paper I have proposed a protocol of AODV routing protocol named as ICBCC–AODV (Integration of current bandwidth capacity calculation) protocol which calculates current bandwidth compares with required bandwidth and then forwards data to destination which is compared with QOS_AODV [11] for getting high pdr and low end to end delay.

Keywords

Mobile Ad-hoc Network, QoS, AODV, Bandwidth Estimation, Routing Protocol.

I.
II. INTRODUCTION
Many routing protocols have been proposed in ad hoc networks, and these can be classified into two categories: table- driven (proactive) protocols and on-demand (reactive) protocols.Reactive protocols: create and maintain routes only when they are desired, and differ on how they discover and maintain routes between sources and destinations.Proactive protocols: require each node to maintain one or more tables to store routing information from each node to all other nodes in the network, regardless of whether they are actually used or not. In this article we are interested by Ad hoc On-demand Distance Vector (AODV) Routing protocol [2]. AODV is a distance vector routing protocol. AODV is an pure on demand routing protocol, so that a route is only discovered when required by a source node. A node does not need to keep routing or reserve bandwidth that does not need. AODV eliminates periodic routing updates and propagate if nodes bandwidth capacity is satisfied by the nodes required bandwidth to be send to the destination. A majority of ad hoc applications involve voice communications while some may require video transmissions. Thus Quality of Service (QoS) is desired to provide the required service differentiation to the demanding connections. However providing QoS assurance in MANETs is a very complex problem due to the characteristics of the network,such as the mobile nature of the nodes resulting in an unpredictable topology, scarce wireless bandwidth which varies with the changing environmental conditions, limited mobile device power and the requirement of node cooperation to relay packets through the network. In this paper we propose and implement an enhanced version of AODV, using the Network Simulator 2 (NS2) The main objectives of this work is to propose a QoS aware AODV routing protocol based on the draft “Quality of Service for Ad hoc On-Demand Distance Vector Routing” [1], to implement (using C++ programming
language) this by amending the source code of the existing AODV routing protocol employed within NS2 and analyse (using TCL(Tool Command Language), AWK (Aho Weinberger Kaho)) the effects of these changes and, comparing the ICBCC_AODV network performance measures (i.e traffic delay, bandwidth) with the unchanged AODV protocol. In the section II, we present some QoS works in the ad hoc networks. Section III describes the problem definition and the network model. In section IV, the ICBCC_AODV route establishment is explained in section V, in section VI Simulation & results and a comparative study lastly in section VII, conclusion of paper is done.
II .LITERATURE
In the literature, the research on QoS support in MANETs spans over all the layers in the network [4]:
1.QoS models specify an architecture in which some kinds of services could be provided.
2. QoS Adaptation hides all environment-related features from awareness of the multimedia-application above and provides an interface for applications to interact with QoS control.
3.QoS routing is part of the network layer and searches for a path with enough resources but does not reserve resources.
4. QoS MAC protocols are essential components in QoS for MANETs. QoS supporting components at upper layers, such as QoS signaling or QoS routing assume the existence of a MAC protocol, which solves the problems of medium contention, supports reliable communication, and provides resource reservation.
A . Existing approach

IJSER © 2014 http://www.ijser.org

International Journal of Scientific & Engineering Research, Volume 5, Issue 6, June-2014 146

ISSN 2229-5518

QOS_AODV: QOS_AODV ROUTE ESTABLISHMENT
To describe how the QoS_AODV works, consider a scenario in which a node , S wishes to communicate with another node, D. if node S has no valid path(s) to D in its routing table, then a route request is initiated. Nodes broadcasts the extended AODV RREQ packet to its neighbours. Upon receiving these RREQ packets, the intermediate nodes (n1,n2,…,nj) compare the RREQ_QoS_BANDWITH field value, within the RREQ packet, say, x kbps with their Current Bandwidth Capacity, CBC kbps. If these intermediate nodes are already engaged in other traffic sessions then their total available bandwidth capacity will vary.The nodes which cannot accommodate the user-specified minimum bandwidth, x kbps, the ‘busy’ nodes, will discard the QoS_AODV_RREQ and not unicast further. The nodes which do satisfy the bandwidth requirement, broadcast the QoS_AODV_RREQ to their neighbours. A reverse route entry is added in the routing table of the QoS_valid node thatunicasts the QoS_AODV_RREQ packet. This process continues until a node receives the QoS_AODV_RREQ and has a fresh enough route to the destination node, D in its routing table, or itself is the destination node. The intermediate nodes (n1,n2,…,nj) are QoS_valid if the following condition is satisfied :
Where CBCbn kbps is the available bandwidth capacity of the bottleneck node [11].
III.PROPOSED AODV ROUTING PROTOCOL NAMED AS ICBCC–AODV (INTEGRATION OF CURRENT BANDWIDTH CAPACITY CALCULATION) [12]
The QOS_ADOV protocol does not speaks on packet delivery ratio also in case if route is not found when bandwidth constrained not satisfied it discards the RREQ packet which causes delay in route discovery till next route discovery process generated in the ICBCC_AODV protocol route establishment the above problem is considered and designed so that delay becomes low.
The decision of whether to accept or reject a flow is done by admission control procedure based on resource availability basis. In reactive routing protocol AODV, when a node wants to communicate to another node and does not know a route to the destination, it sends out a route request (RREQ) message I extend this RREQ message to include the quality of the wanted route to destination in terms of ICBCC parameters like maximum end-to-end delay, minimum bandwidth (MB).
I denote:

QoS_AODV_RREQ = RREQ U {D,MB} QoS_AODV_RREP = RREP U {MB}

Where D is the required maximum end-to-end delay,MB is the minimum bandwidth that the application will require, RREQ is the RREQ packet of original AODV, RREP is the RREP packet of original AODV. So the route to the destination must have available bandwidth greater than or equal to MB. In our protocol the source node’s network layer gets a request in the format of ICBCC_AODV_RREQ (fig.1), from its application. It removes D from ICBCC_AODV_RREQ, stores D locally, starts a timer with value 2*D, and sends out the route request RREQ with the remaining parameters. When an intermediate node gets this ICBCC_AODV_RREQ, it uses MB to determine
whether to forward the route request or drop it. An intermediate node compares the requested minimum bandwidth (MB) with its current bandwidth capacity (CBC). If the node’s CBC is higher, the node rebroadcasts the route request to its neighbors. If the CBC is less than MB, the node drops the route request. By this way if the ICBCC_AODV_RREQ reaches the destination by satisfying the bandwidth constraint then the destination records the MB contained in the ICBCC_AODV_RREQ and replies with a ICBCC_AODV_RREP To include the user defined quality of service parameters (minimum bandwidth (MB) the AODV RREQ packet is modified. The RESERVED field within the normal AODV RREQ packet is used to carry the information during the route establishing process. This extended version of the AODV RREQ will be referred as ICBCC_AODV RREQ (fig.1). The RESERVED field has total length of 16 bits, the maximum value that can be passed in a ICBCC_AODV RREQ packet is 65536 (216).
IV. ICBCC_AODV ROUTE ESTABLISHMENT
To describe how the ICBCC_AODV works, consider a scenario in which a node , S wishes to communicate with another node, D. if node S has no valid path(s) to D in its routing table, then a route request is initiated. Node S broadcasts the extended AODV RREQ packet to its neighbours. Upon receiving these RREQ packets, the intermediate nodes (n1,n2,…,nj) compare the RREQ_ICBCC_BANDWITH field value, within the RREQ packet, say, x kbps with their Current Bandwidth Capacity,CBC kbps. If these intermediate nodes are already engaged in other traffic sessions then their total available bandwidth capacity will vary. The nodes which cannot accommodate the user-specified minimum bandwidth, x kbps, the ‘busy’ nodes, will not discard the ICBCC_AODV_RREQ initially it will forward ICBCC_AODV_RREQ to the successor if not satisfied there it forward to predessor if not satidfied then it will be discarded. The nodes which do satisfy the bandwidth requirement, broadcast the ICBCC_AODV_RREQ to their neighbours. A reverse route entry is added in the routing table of the ICBCC_valid node that unicasts the ICBCC_AODV_RREQ packet. This process continues until a node receives the ICBCC_AODV_RREQ and has a fresh enough route to the destination node, D in its routing table, or itself is the destination node [12].
V .DYNAMIC CURRENT BANDWIDTH CAPACITY (CBC) CALCULATION
Below we propose a mechanism to calculate the CBC for a given node which will be implemented and incorporated within the AODV routing protocol in NS2.The proposed method to monitor and update a nodes traffic status in based upon session flows. This will include keeping track of the various flow statistics over a period of time.The instance at which a traffic flow session is started at any given node, the start-time for every unique flow session is stored. As the data packets arrive and are processed by the nodes, other information necessary for the CBC calculation is extracted from the IP data packets such as: packet size, flow id,source node, destination node, etc. For each individual session flowing through a node, the total number of bytes (calculated from the data packet size for each different flow) sent/forwarded by the node is monitored .The

IJSER © 2014 http://www.ijser.org

International Journal of Scientific & Engineering Research, Volume 5, Issue 6, June-2014 147

ISSN 2229-5518

start-time for each flow is used to work out the interval between packets which are part of the same flow. The CBC is calculated and updated constantly and is a new addition to the
nodes routing table [11].
Formula used to calculate bandwidth is : CBC[j]=8*sum[j]/((end_time-start_time)/1000) Where:
j: flow number
sum[j] : sum of all flow j packet size in byte. CBC[j]: current bandwidth capacity of flow j.

1.2

1

0.8

0.6

0.4

0.2

0

10 20 30 40 50 60 70

ICBCC_AODV_PD R

BASIC AODV_PDR

PAPER_PDR

Fig 1. Pdr graph
V. SIMULATION

Parameter

Value

Topology Size

900x450

Simulation time

150s

Number of Nodes

10 20 30 40 50 60 70

Different traffic flow

sources

4

Table 1: Simulation Parameters.
The Minimum bandwidth (MB) ,delay is assumed here according to the readings of normal AODV.
VI. RESULTS

Table 3 : End to end delay readings

0.2

0.15

0.1

0.05

ICBCC_AODV_ E2E

BASIC AODV_E2E

PAPER_E2E

0

10 20 30 40 50 60 70

Table 2.Pdr readings
Fig 2.end to end delay graph
From the graph we came to conclusion that ICBCC_AODV pdr is better in few cases than QOS_AODV_PDR and BASIC_AODV_PDR also end to end delay is low in ICBCC_AODV_E2E than QOS_AODV_E2E and BASIC_AODV_E2E.

IJSER © 2014 http://www.ijser.org

International Journal of Scientific & Engineering Research, Volume 5, Issue 6, June-2014 148

ISSN 2229-5518

VII .CONCLUSION.
In this paper, an enhanced version of AODV routing protocol was proposed. We have implemented our admission control mechanism using the Network Simulator 2 (NS2) Where the source node checks the end-to-end delay and all the intermediate nodes perform bandwidth check. Our a algorithm is based on the modification of the AODV RREQ and AODV RREP packets, to include the user defined quality of service parameters (minimum bandwidth (BP) and maximum delay(D)); it also compute the Current Bandwidth Capacity (CBC) for a given node which will be implemented and incorporated within the AODV in NS2. We have developed some components of the network Simulator NS 2 to adapt our algorithm. It is seen from the simulation results that our proposal ICBCC_AODV gives a very good packet delivery ratio and low end to end delay in the shown scenario which secures packet from getting dropped thus enhances the node bandwidth processing performance. In future work, we envisage to improve our current ICBCC_AODV proposal by making it compared with others routing protocols like DSR,DSDV etc.
Moussa,FERAOUN M.Kamel,DOUMI Noureddine,KHATER Maamar,978-1-4673-1166-3/12/$31.00 ©2012 IEEE.
[12] Modified AODV with Current Bandwidth Calculation for Mobile ADHOC Networks" , Poonam N Gholap & Rinku Shah,,International Journal of Applied Engineering Research and Development ", ISSN(Online): 2250-1584, ISSN(Print):
2278-9383,Edition:APR2014
REFERENCES
[1] C. Perkins and E. Belding-Royer: Quality of Service for Ad hoc On-Demand Distance Vector Routing (work in progress), Oct 2003, draft-perkinsmanet-aodvqos-02.txt.
[2] C. Perkins, E. Belding-Royer, S. Das: Ad hoc On-Demand
Distance Vector (AODV) Routing, Network Working Group, July 2003 available on:ftp://ftp.nordu.net/rfc/rfc3561.txt.
[3] The ns Manual (formerly ns Notes and Documentation)1, The VINT Project, A Collaboration between researchers at UC Berkeley, LBL, USC/ISI, and Xerox PARC. Kevin Fall.
[4] Yihai Zhang : Quality of Service for Ad-hoc On-demand Distance VectorRouting, Master of Applied Science thesis, department of Electrical and computer Engineering, university of Victoria, 2004.
[5] Gahng-Seop Ahn, Andrew T. Campbell, Andreas Veres and Li-HsiangSun. SWAN: Service Differentiation in Wireless Ad Hoc Networks. In IEEE INFOCOM, 2002
[6] Steven Blake, David Black, Mark Carlson, Elwyn Davies, Zheng Wang, and Walter Weiss: An Architecture for Differentiated Services. Internet Request for Comments RFC
2475, Internet Engineering Task Force, Décembre 1998.
[7] Robert Braden, Lixia Zhang, Steven Berson, Shai Herzog, and Sigih Jamin: Resource ReSerVation Protocol (RSVP) – Version 1 Functional Specification. Internet Request For Comments RFC 2205, Internet Engineering Task Force, Septembre 1997.
[8] Cheikh Sarr, Sofiane Khalfallah and Isabelle Guérin Lassous: Gestion dynamique de la bande passante dans les réseaux ad hoc multi-sauts.In JDIR'09: 10èmes Journées Doctorales en Informatique et Réseaux, 2009.
[9] L Junhai, X Liu, and Y Danxia : Research on Multicast Routing Protocols for Mobile Ad-Hoc Networks Computer Networks – Elsevier, 2008.
[10] Cheikh Sarr, Claude Chaudet, Guillaume Chelius, and
Isabelle Guérin Lassous: Bandwidth Estimation for IEEE
802.11-Based Ad Hoc Networks.
IEEE transaction on mobile computing, vol. 7, No. 10, october
2008, pp 1228-1241.
[11]Integration of dynamic current bandwidth capacity calculation for existing AODV ,ALI CHERIF

IJSER © 2014 http://www.ijser.org