FB-ODMRP: A Feedback-based Scheme for Improving ODMRP Performance in Ad Hoc Networks

: This research aims at proposing an improvement to On Demand Multicast Routing Protocol (ODMRP) called as Feedback ODMRP (FB-ODMRP). ODMRP is a popular multicast routing protocol designed for ad hoc networks with mobile hosts. Its efficiency, simplicity and robustness to mobility render it one of the most widely used routing protocols in MANETs. In ODMRP, the robustness is achieved using periodic route refreshing wherein group membership and multicast mesh are established and updated by the source on fixed refresh intervals and thus such route refresh interval is of the utmost importance to ODMRP’s performance. However, robustness comes at the expense of high control overhead incurred to the network. If small route refresh interval values are used, fresh routes and membership information can be achieved at the expense of incurring more control packets and increasing probability of packet collisions and congestion whereas the large refresh values are used, the protocol cannot keep up with network varying dynamics resulting route breakages and packet failure. In this research, the proposed variation of ODMRP makes the route refresh interval variable adapted to feedback information achieved from receivers of the multicast group. Through extensive simulations, it is observed that FB-ODMRP performs well over the range of scenarios and incurs less control overhead compared to original ODMRP while maintaining packet delivery ratio comparable that of the original ODMRP.


INTRODUCTION
Motivated by increasing usage of laptop computers and communication over wireless devices, wireless communication between mobile users becoming increasingly on-demand.Hence, Mobile Ad Hoc Networks (MANETs) becoming useful and they are going to be an integral part of the future generation of mobile services.A MANET is an infrastructure-less, dynamically reconfigurable wireless network, wherein mobility of nodes results in rapid and unpredictable changes in the network topology.Ad hoc networks have numerous practical applications such as military applications, emergency operations and rapid construction of temporal wireless networks.Thus, MANETs are employed to support collaboration among a team of users.Multicasting support is critical and desirable feature of ad hoc networks.Multicasting plays a crucial role in ad hoc networks.There exist a wide range of survey studies in literature reviewing traditional and multicast routing protocols and generally routing in MANETs (Mohseni et al., 2010;Ismail and Hassan, 2011;Jetcheva and Johnson, 2004;Badarneh and Kadoch, 2009;Kant and Awasthi, 2010;De Morais et al., 2003;Junhai et al., 2009;Viswanath and Tsudik, 2006;Rai and Ashima, 2009;Masoudifar, 2009).Among multicast protocols proposed for ad hoc networks, ODMRP (Lee et al., 2002) has verified to outperform other protocols under different network scenarios (Jetcheva and Johnson, 2004).ODMRP is relied on network wide flooding of control packets in fixed periodic refresh intervals to refresh and rebuild the mesh structure.Such periodic control messages intend to provide robustness to ODMRP despite mobility and unreliable wireless links.To date, a wide range of research attempted to improve efficiency of this protocol from different prospective (Naderan-Tahan et al., 2009;Darehshoorzadeh et al., 2007a, b;Effatparvar et al., 2007b;Lee and Kim, 2001;Zhao et al., 2003;Oh et al., 2005).E-ODMRP proposed by Oh et al. (2005) is one of the ODMRP's variations focusing on variable refresh interval rather than the fix ones.
Authors attempted to adapt the refresh rate dynamically with respect to the environment varied from a prefixed minimum to maximum values.The refresh interval adaptation is carried out by receiver's report on link breakage.In addition, E-ODMRP is incorporated with a unified local recovery and receiver Join mechanism.The proposed E-ODMRP method results in lower control overhead while maintaining the packet delivery ratio comparable to original ODMRP.However, E-ODMRP introduces an additional control packet and utilizes additional processing at nodes which may not be available in low bandwidth and power mobile devices.Such an analytical idea to inject the control packets in variable refresh intervals rather than the fixed ones, proposed by Oh et al. (2005) resulting in less control overhead, has been specifically adapted in this by using of existing control packets in original ODMRP rather than introducing a new control packet.As the main contribution of this research, FB-ODMRP achieves less control overhead compared to the original ODMRP.Source node in FB-ODMRP is adapted to the information achieved from receivers of the multicast group in order to adjust their rate at which control packet are sent through the network.By exploiting the feedback information from receivers, the refresh interval is adjusted.The distinctive feature of FB-ODMRP can be found in its reduced overhead.

FB-ODMRP mechanism:
In following sections, it is discussed how feedback from the receivers can be used to adjust the control packet refresh interval in FB-ODMRP, thus reducing the control overhead which may result in higher data delivery ratio.If the source is informed regarding the poor data delivery rate, it takes an action to refresh the forwarding mesh and routes more frequently (i.e., decreases the refresh interval).The rationale is that scarce data delivery is mainly due to route breakage and failure, so protocol should refresh the forwarding mesh before the route fails or breaks.On the other hand, high data delivery identifies that the routes in the forwarding mesh are refreshed in reasonable intervals and the frequent refreshing is not necessary.

Forwarding mesh creation in FB-ODMRP:
In FB-ODMRP, the multicast tree creation and maintenance process follows original ODMRP.Similarly, the source initiates a forwarding mesh structure between source and receivers.When a node has data packets to send, it floods the entire network by a Join Query packet.In ODMRP, Join Query packets are propagated periodically in fixed refresh intervals in order to refresh the membership information and multicast routes whereas source originates Join Query packets in variable refresh intervals in FB-ODMRP.
In the proposed FB-ODMRP, the forwarder node timeout is based on the information stored in membership table while propagating the Join Query packets.Such Join Query packet contains an additional field, "Membership Time"; each source appends the Membership Time to its Join Query packet and floods it through the network.An intermediate node receiving a non-duplicate Join Query packet stores the Membership Time in its membership table and rebroadcasts the packet.In FB-ODMRP, the forwarder node timeout is defined as network's current time in addition to the Membership Time.Hence, each forwarding group maintains variable refresh intervals rather than fixed ones implemented in original ODMRP.
A table maintained in multicast receivers of FB-ODMRP called as "NodeList Table " including information about the number of data packets received by this receiver of the multicast group from source during the last data transmissions (denoted by 0 and n in Fig. 1) and multicast group IP address (denoted by M1 in Fig. 1).When the Join Query packet reaches a multicast receiver, the receiver appends the information in its Nodelist to Join Reply packet and broadcasts the packet to its neighbors.With the aim of feeding back the information to the source, some information are attached to the Join Reply packets and periodically sent back to the source.Thus, Join Reply packet is modified in order to carry feedback information.When an intermediate node receives a Join Reply packet, it checks if the next node address of one of the entries matches its own address, it if does, the node realizes that it is one the path to the source and thus is a member of the multicast group.It sets its Forwarding Group Flag (FG-FLAG) and rebroadcasts the packet.Another table, "TempNodeList", is created and maintained at each intermediate node in FB-ODMRP.Each forwarder node receiving the Join Reply packet creates a new entry in its TempNodeList table according to the information provided by the reply packet.This table stores the feedback information attached to the Join Reply packet including the destination (i.e., receiver which has originated such Join Reply packet), multicast group IP address and the number of successfully delivered multicast packets to this receiver (denoted by n in TempNodeList, Fig. 1).
This table provides information for the forwarder nodes to originate their own Join Reply packet.Also, this table provides information when calculating the average number of received packets by each receiver of the group.In Fig. 1, variable refresh intervals (denoted by T 'in Fig. 1) are maintained in FB-ODMRP while such intervals in original ODMRP are fixed (denoted by T in Fig. 1).Considering the diagram shown in Fig. 2, forwarding mesh creation in FB-ODMRP encompasses five different phases.Briefly, phase 1 and 5 are completed in the source node, phase 2 and 4 in forwarder nodes and phase 3 in receivers of the multicast group:    In FB-ODMRP, we propose to assign an array of probabilities in order to take appropriate actions under different feedback information.These actions are defined in an array labeled as actionProb (0) (i.e., increase action), actionProb (1) (i.e., decrease action) and actionProb (2) (i.e., reset action) which are initialized by 0.4, 0.4 and 0.2, respectively.The refresh interval is varied using adjustment of actionProbs upon receiving the feedback information.If probability of actionProb ( 0) is the highest probability among three actionProbs, the refresh interval is increased.
Otherwise, if actionProb ( 1) is the highest probability, the refresh interval is decreased.ActionProb (2) resets the refresh interval to its predefined value (i.e., 4 second).To be exact, there is 80% probability of decreasing or increasing the refresh interval while 20% probability of resetting the value to its predefined value in original ODMRP.The array of actionProbs and functionality of each cell is depicted in Fig. 4. Upon receiving the Join Reply packet by the source of the group which contains the feedback information, source decides to take an action.To sum up, following actions shall be taken: • actionProb (0) = 0.4, this cell of the array stands for the probability of increasing the refresh interval.When an acceptable number of transmitted packets are successfully delivered to the receivers of the multicast group, the source is notified about the satisfying success ratio of data delivery and takes an action to adjust the refresh interval.At this point, an increase in refresh interval may not result in loss of packets.So, the value of actionProb (0) is increased and if it is the highest probability in array, an increase in refresh interval rate occurs.In this situation, control packets are flooded in the network less frequently than before.• actionProb (1) = 0.4, this cell of array stands for probability of decreasing the refresh interval.If the source is not satisfied with the average number of received packets by the receiver, this probability is increased and if this field of array maintains the highest probability resulting in a decrease in refresh interval.In this situation, Join Query packets are propagated more frequently to refresh the routes and forwarding group.• actionProb (2) = 0.2, this cells of array stands for resetting the refresh interval to its value in original ODMRP.
Control algorithm in FB-ODMRP: Control actions are taken by the source of the multicast group at discrete points in time.The aim of the control action is to adjust minimum number of control packets incurred to the network by the source using a control algorithm.
The control algorithm in FB-ODMRP is as follows.If an average number of half of the originated packets successfully reach their destinations, it is assumed as a satisfactory data delivery ratio and we can increase the refresh interval and inject less control packets in the network.On the other hand, if an average number of less than half of the originated packets are received by the receivers of the multicast group, it is assumed that link breakages happened and forwarding mesh requires being refreshed more frequently, hence, the refresh time is decreased.Upon receiving the Join Reply packet, a timer is set by the source to collect all Join Reply packets from different branches of the multicast group; when this timer expires, the mechanism of adjusting the route refresh interval is carried out at which information achieved from Join Reply packets play the main role.The source calculates the average number of received packets by each receiver of the multicast group and accordingly adjusts probabilities of increasing or decreasing the refresh interval.Finally, an action is taken to increase, decrease or reset the refresh interval.
Figure 5 represents the pseudo code of the control algorithm with respect to three roles of nodes in the network which are sender, receiver and intermediate node.S is the total number of data packets originally sent by the source, x is total number of multicast packets received by the receivers of a multicast group; c is the number of receivers.Hence, R is the average number of received packets by each receiver of the multicast group; StepProb is set to 0.05 and α to 0.5, since we assume half of the originated packets should successfully reach their receivers.
The source compares half of the originated data packets with the average number of received packet by each receiver of the group.Result of this comparison is denoted by ∆.Afterwards, source decides whether to increase or decreases the refresh interval.Equation (1) shows how ∆ is computed: In Eq. ( 1), S is the total number of data packets originally sent by the source, R is the average number of received data packets by each receiver of the multicast group and α is set to 0.5 because we assume the delivery ratio satisfactory if half of the originated packets successfully reach their destinations.At this stage, two possible situations may occur: • If ∆>0, that is an average number of equal to or less than half of the originated packets are delivered to the receivers, it is concluded that a short interval could improve the network performance by refreshing the routes and forwarding mesh more frequently.Hence, it is required to increase actionProb (1) in order to decrease the refresh time and at the same time the probability of increasing the refresh interval (i.e., actionProb (0)) is decreased.Having done so, the frequent route refreshes attempts to keep high packet delivery ratios by providing redundant forwarding routes.• If ∆<0, that is more than half of the data packets successfully reached their destinations.In this situation, a short interval seems unnecessary; wastes channel bandwidth and degrade network performance.Hence, the control algorithm increases the actionProb (0) which is the probability of increasing the refresh interval and at the same time decreases the actionProb (1), the probability of decreasing the refresh interval.Hence, the refresh interval is increased in order to inject less control packets to the network when they seem unnecessary and just waste the network resources.
The source slowly increases or decreases the refresh interval to a constant value.Essentially, it is a slow increase to avoid rapid and unexpected increases in refresh interval, where source of the group attempts to reduce the overhead by slowing down the refresh intervals.In the same way, sudden and quick decrease results in short refresh intervals when the packet delivery is low.Also, unnecessary short intervals corrupt network performance.

TEST RESULTS AND DISCUSSION
The simulation code and scenario of this research was implemented within GloMoSim library (Bajaj et al., 1999) FB-ODMRP is the enhanced scheme to the original ODMRP as proposed in this research.To investigate efficiency of the proposed enhancement compared to original ODMRP, we have simulated the following three schemes: • FB-ODMRP: The feedback integrated scheme for ODMRP proposed in this research that uses the feedback information to adjust the refresh interval time • ODMRP: The original ODMRP routing protocol modeled and evaluated in this research is the latest version which already exists in version 2.03 of GloMoSim (Lee et al., 2002) • QoS-ODMRP: The recently proposed quality of service extension for ODMRP proposed in Darehshoorzadeh et al. (2007b) The performance metrics used in this research are presented in the following section.
Average end-to-end delay, Packet Delivery Ratio (PDR) and normalized control overhead: An alternative of using a measure of pure control overhead, a ratio of number of control packets transmitted per data packet delivered is used to investigate the efficiency of utilizing control packets in delivering real data packets.Multicast efficiency: the ratio of the total number of multicast packets delivered to all receivers versus the total number of multicast packets transmitted (Ozaki et al., 2001).Simulation settings of this research and protocols specification are as presented in Table 1 and 2, respectively.Scenario: varying mobility speed: Figure 6a to d compare FB-ODMRP's, ODMRP's and QoS-ODMRP's performance in different mobility conditions, i.e., varying maximum node speed.As expected, QoS-ODMRP gives by far higher end-to-end delay than ODMRP and FB-ODMRP (Fig. 6a), since QoS-ODMRP incurs more control overhead to the network.Also, as the mobility speed increases, the endto-end delay of QoS-ODMRP escalates moderately.From Fig. 6a and b, we can see that both ODMRP and FB-ODMRP can tolerate mobility changes well.However, in majority of cases, FB-ODMRP slightly outperforms ODMRP in terms of end-to-end delay.This is because ODMRP floods the Join Query packets in constant refresh intervals resulting in more control overhead and contention of the radio channel.However, in FB-ODMRP, the control packets are sent in variable refresh intervals based on the feedback on data delivery provided by the receiver of the multicast group, hence, the control overhead is reduced, contention is less likely to occur and end-to-end delay stands in better position compared to ODMRP.Generally, end-to-end delays of ODMRP and FB-ODMRP protocols show the same pattern.This is attributed to the same mesh-structure maintained in both protocols.The packet delivery ratio as a function of mobility speed is shown in Fig. 6b.We can observe that the results for FB-ODMRP and ODMRP are approximately the same at starting point of the simulation (i.e., max mobility speed 5 m/sec) while incurring 75% less control overhead by FB-ODMRP compared to ODMRP at the same speed (Fig. 6c).As the mobility speed increases, FB-ODMRP achieves just about the same delivery ratio as ODMRP with minimal difference.
In contrast, QoS-ODMRP's packet delivery ratio diverges the other two investigated protocols as the mobility speed increases, 52% higher than the other two at the start point of the simulation (i.e., maximum node speed 5 m/sec).Although QoS-ODMRP's PDR decreases slightly as the mobility speed increases, still this ratio is significantly high over 70% regardless of speed.The reasoning behind such rewarding PDR is the traffic admission ratio policies used in this protocol and just establishing the sessions that could satisfy QoS requirements of the application.In QoS-ODMRP, sources only send data when the established routes have enough bandwidth available, thus the packet delivery ratio is by far higher than the other two studied protocols.On the other hand, the performance of ODMRP stays relatively constant even in highly dynamic environments.
As mentioned earlier, ODMRP provides redundant routes using the mesh topology; hence, the packet delivery does not change considerably when the speed increases even if primarily routes are unavailable (because redundant routes are available).Moreover, PDR in FB-ODMRP decreases to some extent as the mobility speed increases.
Figure 6c shows the total number of control packets transmitted normalized by the number of data packet delivered to their destinations as a function of mobility speed.It is observed that FB-ODMRP induces significantly less control packets compared to QoS-ODMRP and ODMRP by 92 and 64% at maximum   et al., 2006).

CONCLUSION
This research study focuses on multicast routing in mobile ad hoc networks and mainly mesh-based protocol, ODMRP.In this research, we have presented an improved version of ODMRP with adaptive refresh, namely FB-ODMRP.It presents the periodic refresh interval dynamically adapted to receiver's feedback on packet delivery.Efficiency and scalability of FB-ODMRP is evaluated in contrast to original ODMRP and QoS-ODMRP under several simulation scenarios and network conditions.Simulation results show that our new method improves the basic ODMRP's performance significantly wherein less control packets incurred through all simulation scenarios, the Feedback-based ODMRP was scalable and efficient in successfully delivering the data packets to receivers of the multicast groups using small number of data transmissions.Although the proposed approach achieves the goal of the research by reducing control overhead to some degree, there are some other important aspects in ODMRP which need to be further investigated in conjunction with adaptive refresh interval.One future study of this research is to mathematically study and formulate this value based on network dynamics.

Fig. 3 :
Fig.3: An example of join reply packet propagation in FB-ODMRP

Fig. 5 :
Fig. 5: Pseudo code of the control algorithm in FB-ODMRP Fig. 6: (a) End-to-end delay, (b) packet delivery ration, (c) normalized control overhead, (d) multicast efficiency as a function of mobility speed mobility speed 30 m/sec, respectively.This enhancement is attributed to its dynamic refresh interval at which the network wide flooding is restricted.It is interesting to see that ODMRP and FB-ODMRP's number of control packets stays nearly constant while mobility speed increases from 5 to 35 m/sec.As mentioned earlier, this is due to the mesh structure maintained in both schemes which results in robustness to mobility.On the other hand, the number of control packets in QoS-ODMRP remains relatively constant till 15 m/sec, since then this value increases dramatically.In QoS-ODMRP, Hello messages are transmitted periodically through the network; such extra control packets induce a large amount of overhead to the network.Although QoS-ODMRP prevents propagation of Join Queries and Join Replies where there are not enough resources available, still this QoS function could not compensate the extra control packets introduced by Hello messages to the network (Darehshoozareh et al., 2006).

Table 1
Hello messages are transmitted periodically through the network; such extra control packets induce a large amount of overhead to the network.Although QoS-ODMRP prevents propagation of Join Queries and Join Replies where there are not enough resources available, still this QoS function could not compensate the extra control packets introduced by Hello messages to the network (Darehshoozareh