(IJCSIS) International Journal of Computer Science and Information Security,Vol. 9, No. 7, 2011
Decreasing control overhead of ODMRP by using passive data acknowledgement
Robabeh Ghafouri
Department of computer Shahr-e-Qods branch, Islamic Azad UniversityTehran, Iran
autcomp@yahoo.com
Abstract
—
On Demand Multicast Routing Protocol (ODMRP) isa multicast routing protocol for mobile ad hoc networks.Although its simplicity and robustness to mobility, render it oneof the most widely used MANET multicast protocols, it suffersfrom excessive control overhead and redundant datatransmissions as the network size and the number of sourcesincrease. This event wastes valuable resources - such as channelbandwidth- and increases the packets collision. In this paper, wepresent a new method for reducing control overhead of ODMRPand called the new protocol LFPA_ODMRP (Limited Floodingby Passive data Acknowledgements). LFPA_ODMRP restrictssome nodes to flood Join-Query packets by using passive dataacknowledgments. Consequently it limits the scope of Join-Query packets flooding and reduces the control overhead.Simulation results showed that the proposed method reduces thecontrol overhead, end to end delay and at some conditionsimproves the data packet delivery ratio.Keywords-Ad hoc networks; multicast routing; ODMRP; passiveacknowledgement; GLOMOSIM
I.
I
NTRODUCTION
An ad hoc network is a multi-hop wireless network formed by a collection of mobile nodes without the intervention of fixed infrastructure. Because an ad hoc network isinfrastructure-less and self-organized, it is used to provideimpromptu communication facilities in inhospitableenvironments. Typical application areas include battlefields,emergency search and rescue sites, and data acquisition inremote areas. An ad hoc network is also useful in classroomsand conventions where participants share informationdynamically through their mobile computing devices.Each mobile node in an ad hoc network functions as arouter to establish end-to-end connections between any twonodes. Although a packet reaches all neighbors withintransmission range, a mobile node has limited transmissionranges and its signals may not reach all hosts. To providecommunications throughout the network, a sequence of neighbor nodes from a source to a destination form a path andintermediate mobile hosts relay packets in a store-and-forwardmode.Unique characteristics of an ad hoc network raise severalrequirements for the routing protocol design: ad hoc network routing must be simple, robust and minimize control messageexchanges. Ad hoc routing must be simple because routing is performed by generic mobile hosts which have limited CPUand memory capacities and are powered by batteries.Bandwidth is a scarce resource in wireless networks. Routingalgorithms which consume excessive bandwidth for routingcontrol message exchanges may not be appropriate for wirelessnetworks. The topology of an ad hoc network is inherentlyvolatile and routing algorithms must be robust against frequenttopology changes caused by host movements.Many routing schemes have been presented to provideadequate performance of ad hoc networks, for example DBF[1], DSDV [2], WRP [3], TORA [4], DSR [5], AODV [6],ABR [7], RDMAR [8] . In addition to unicast routing protocols, several multicast routing protocols for ad hocnetworks have been proposed in more recent years
[
9–13].Multicast consists of concurrently sending the same messagefrom one source to multiple destinations. Unicast is a specialform of multicast. Some proposed multicast routing protocolssupport both unicast and multicast routing [9, 10]. Multicasting plays a very crucial role in the application of Ad hoc networks.It plays an important role in video-conferencing, distanceeducation, co-operative work, video on demand, replicateddatabase updating and querying, online gaming, chat roomsetc...The proposed multicast protocols for ad hoc network can beclassified into two categories: tree-based protocols and mesh- based protocols. In the tree-based schemes, a single shortest path between a source and a destination is selected out for datadelivery. MAODV [9], AMRIS [12] and AMRoute [13] aretypical tree-based schemes. In the mesh-based schemes,multiple paths are selected for data delivery. ODMRP [9, 16,17], CAMP [11], FGMP [14], NSMP [15] are typical mesh- based schemes. Tree-based protocols are generally moreefficient than mesh-based protocols, but they are not as robustagainst topology changes as mesh-based schemes because thereis no alternative path between a source and a destination.Recent study [18] shows that the mesh-based schemesgenerally outperform the tree-based schemes. It also concludesthat ODMRP outperforms other mesh-based protocols.
34http://sites.google.com/site/ijcsis/ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 9, No. 7, 2011
Although ODMRP is simple and robust to mobility, it relieson frequent network-wide flooding to maintain its forwardingmesh. This event creates lots of control packets, and the largeamounts of control packets occupy most of limited wireless bandwidth. Thereby, data packets cannot acquire enough bandwidth for their transmissions.Some protocols were proposed to improve the ODMRPflooding scheme. The local recovery approach was introducedto limit the scope of flooding. According to that, most link failure recoveries can be localized to a small region along previous route [8]. NSMP [15], PatchODMRP [19],PoolODMRP [20, 21] and PDAODMRP [22] are proposed tosave their control overhead by their local route maintenancesystem. DCMP [23] reduced the control overhead bydynamically classifying the sources into Active and Passivecategories. The key concept in DCMP is to make some sourcesPassive, which then forward data packets through their corenodes.In this paper, in order to reducing the control overhead of ODMRP, we used passive data acknowledgements to limit thescope of join query packets flooding. By using the passiveACK scheme and limiting some nodes to flood Join-Request packets, the control overhead reduced. We called the new protocol LFPA_ODMRP. Simulation results showed that the proposed method reduces the control overhead, end to enddelay and at some conditions improves the data packet deliveryratio.The rest of the paper is organized as follows. Section II,contains an overview of ODMRP. In Section III, we providethe motivation for our work. In Section IV, we describe our multicast routing protocol. We present numerical results fromthe simulation studies of our multicast routing protocol inSection V. Finally, we make some concluding remarks inSection VI.II.
O
N
-
D
EMAND
M
ULTICAST
R
OUTING
P
ROTOCOL
(ODMRP)ODMRP is an on-demand multicast routing protocoldesigned for ad-hoc networks. This protocol was proposed in1999 by lee. It is a mesh based protocol that provides richconnectivity among multicast members. By building a meshand supplying multiple routes, multicast packets can bedelivered to destination in the face of node movement andtopology changed. To establish a mesh for each multicastgroup, ODMRP uses the concept of forwarding group .theforwarding group is a set of nodes responsible for forwardingmulticast data between any member pair .
A.
Multicast route and mesh creation
In ODMRP, group membership and multicast routes areestablished and updated by the source on demand. Similar to ondemand unicast routing protocols, a request phase and reply phase comprise the protocol. While a multicast source has packets to send, it periodically broadcasts to the entire network,a member advertising packet, called JOIN _Query. When anode receives a non-duplicate JOIN _Query, it stores theupstream node ID (i.e., backward learning) and rebroadcaststhe packet. When the JOIN _Query packet reaches a multicastreceiver, it broadcasts join replies to the neighbors. When anode receives a Join reply, it checks if the next node ID of oneof the entries matches its own ID. If it dose, the node realizethat it is on the path to the source and thus is part of theforwarding group. It then sets the FG-flag and broadcasts itsown join reply built upon matched entries. The join reply isthus propagated by each forwarding group member until itreaches the multicast source. This process constructs the routesfrom sources to receivers and builds a mesh of nodes, theforwarding group.
B.
Data forwarding
After the group establishment and route construction process, a multicast source can transmit packets to receivers viaselected routes and forwarding groups. When receivingmulticast data packets, a node forwards it only if it is not aduplicate and the setting of the FG-flag for the multicast grouphas not expired
.
III.
MOTIVATION
As mention in II-A, ODMRP relies on frequent network wide flooding to maintain its forwarding mesh. This wideflooding creates lots of control packets, and the large amountsof control packets occupy most of limited wireless bandwidth.The excessive control overhead degrades the scalability of theODMRP protocol especially when there are too many sourcesin a multicast group. In this paper, we propose a method calledLFPA (Limit Flooding by Passive Acknowledgements) whichuse the passive data acknowledgement scheme and limit somenodes to flood Join-Request packets. There fore it reducescontrol messages and control overhead of ODMRP .We callednew protocol LFPA_ODMRP
.
IV.
PROPOSED PROTOCOL DESCRIPTION
A.
An overview of proposed protocol
In proposed protocol we utilized a limited flooding schemeto reducing control overhead in ODMRP. We used the PassiveData acknowledgements and called the new protocolLFPA_ODMRP (Limited Flooding by using the Passive ACK).LFPA_ODMRP forbids some nodes to broadcastingJOIN_Query Packets, by using the passive dataacknowledgements.When node B transmits a packet to node C after receiving a packet from node A, node A can hear the transmission of nodeB if it is within B's radio propagation range. Hence, the packettransmission by node B to node C is used as a passiveacknowledgment to node A. A node may not hear the passiveacknowledgments of its downstream neighbor because of conflicts due to the hidden terminal problem. It will also nothear the passive acknowledgment if the downstream neighbor has moved away.We can utilize these passive acknowledgments to verify thedelivery of data packets. In LFPA_ODMRP the number of data packets which a FG node has forwarded but it has not received passive acknowledgement for them, are counted. We called this
35http://sites.google.com/site/ijcsis/ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 9, No. 7, 2011
value NDD (Not Delivered Data packet) and we set a thresholdvalue
τ
. According to NDD value and threshold value, wedecide whether FG node forwards the J-Query packet and joinsto the forwarding group or not, in the next rout refresh interval.If NDD value of the node is greater than threshold value,that node is forbidden from forwarding Join-Query packets inthe next rout refresh interval. The higher threshold value makesthe LFPA_ODMRP similar to ODMRP. The lower thresholdvalue saves more control messages, but at low threshold valueand high load of network traffic, some multicast sessions haveno routes to receivers because intermediate nodes save toomany control massages. We determined optimized thresholdvalue by simulation results. Simulation results show thatoptimized threshold value must be double of PacketTransmission Rate or network traffic load.
B.
The data structure of LFPA_ODMRP
In addition to data structures used in ODMRP, two other data structures used in LFPA_ODMRP are as follow:Data Passive ACK Table: In LFPA_ODMRP this datastructure is created to every FG node. “Fig. 1”,
shows the fieldsof an entry in a Data Passive ACK Table. Each entry in thistable includes source address, group address, sequence number of data packet, a flag bit to indicate whether this node hasreceived passive acknowledgement for this data packet or notand time stamp field indicates recording time of this record.When a forwarding node receives an unduplicated data packet,it inserts a record to its own “Data
Passive ACK Table”
.
Figure 1. Format of Data Passive ACK Table
Next Node Table: Another data structure that every FGnode maintains is “Next Node
Table”. “Fig. 2”, shows thefields of an entry in a Next Node Table. In this table, multicastaddress field is the address of a multicast group; source addressfield is the address of a node, which initiates the data packet;next node address field presents which node deals with the packet last. When a node receives join reply packet and becomes a forwarding node of a group, it records the address of a node which deals the reply packet last as next node address inits “Next Node Table”. Therefore, each forwarding node knowswhich nodes are its next nodes on path to receivers. If the nodewhich its address is written in “next node address” field is puremember of group, “It is a member” field is set “true” becausethe members don’t forward data packets.
Figure 2. Format of Next Node Table
C.
The forwarding mesh setup in LFPA_ODMRP
LFPA_ODMRP is a mesh-based on-demand multicast protocol which is based on ODMRP. The setup andmaintenance of routes are roughly the same as ODMRP withsmall difference. LFPA_ODMRP builds a mesh for multicastdata delivery and is composed of a request phase and a reply phase similar to ODMRP.
Request phase:
When a source has data packets to sendwithout knowing routes, it floods a Join Query packet toacquire membership information and routes to entire network,when a node receives a non-duplicate Join Query, it checks its“Passive ACK Table” to decide whether it drops the JoinQuery packet or rebroadcast it. The decision principles are asfollows.
•
We set a threshold value
τ
that it is double of PacketTransmission Rate. NDD is number of Passive ACK table entries which their delivery field is false. NDDvalue indicates number of data packets which a FGnode has forwarded but it has not received passiveACK for them.
•
For every FG node if NDD value exceeds thresholdvalue, it drops the Join Query packet; otherwise itrebroadcasts the Join Query packet.
Reply phase
: After receiving Join Query packets, amember answers its received Join Query packets with a JoinReply packet same as ODMRP. When a node receives a JoinReply packet, it checks whether it is a downstream nodedefined in the downstream list of the Join Reply packet. If thenode is a downstream node, then the node marks itself as aforwarding node. The new forwarding node records the addressof a node dealing the reply packet last (the address of the nodewhich has been received reply packet from it) as next addressin its “Next Node Table”, and broadcasts a new Join Reply packet. Therefore, the nodes on the paths are marked asforwarding nodes, and each forwarding node knows whichnodes are its next nodes on path to receivers.
D.
Data packet forwarding in LFPA_ODMRP
A source begins to broadcast its data packets, after itsforwarding mesh founded. When a FG node receives a dataPacket, it deals with the data packet as follows:
•
When a forwarding node receives an unduplicated data packet, it relays the data packet then it records itssource address, multicast group address and sequencenumber in “Passive ACK table”, if next node of thisnode is not pure receiver or member of multicastgroup.
•
When the FG node receives a data packet from its nextnode on path to a receiver (data passive ACK), it refersto its “Data Passive ACK Table” and sets true todelivery field in related record.V.
S
IMULATION
E
NVIRONMENT
We evaluated the performance of our proposed scheme bycarrying out various simulation studies. The simulation modelwas built around GLOMOSIM [24] developed at theUniversity of California, Los Angeles using PARSEC. TheIEEE 802.11 DCF is used as the MAC protocol. The free-space propagation model is used at the radio layer. In the radiomodel, we assumed that the radio type was radio-capture.
Mcast.Addr Scr.Addr Seq.Num Time.stamp DeliveryMcast.Addr Scr.Addr Next nodeAddr Time.stampIt is amember
36http://sites.google.com/site/ijcsis/ISSN 1947-5500
Search History:
Result 00 of 00
00 results for result for
p.
Decreasing Control Overhead of ODMRP by Using Passive Data Acknowledgement
On Demand Multicast Routing Protocol (ODMRP) is a multicast routing protocol for mobile ad hoc networks. Although its simplicity and robustness to mobility, render it one of the most widely used MANET multicast protocols, it suffers…
(More)
221
Reads
2
Readcasts
0
Embed Views
Get Scribd Mobile
To get Scribd mobile enter your number and we'll send you a link to the Scribd app for iPhone & Android.We've sent a link to the Scribd app. If you didn't receive it, try again.
We'll never share your phone number.
More From This User
Notes
Load more
