Abstract
Due to its simplicity, efficiency, and robustness to mobility, the On-Demand Multicast Routing Protocol (ODMRP) becomes a standout amongst the most broadly utilized multicast routing protocols in mobile ad hoc networks (MANETs). However, the robustness of ODMRP comes at the expense of incurring a high control overhead to the network. The Enhanced ODMRP (EODMRP) proposed a dynamic refresh interval for the multicast mesh based on the network feedback on real disconnections experienced by the multicast network members. Veritably, EODMRP decreased the network control overhead at the cost of obtaining a low packet delivery ratio especially in high mobility conditions of the network. In this paper, two protocols, as improvements to both ODMRP and EODMRP, are proposed where the refresh interval is basically adapted based on the source moving speed and the number of disconnections reported by multicast members. Furthermore, we proposed an impressive local recovery to be employed in both protocols, which includes new setup and failure mechanisms that contribute effectively to boosting the performance of our proposed protocols. Since the majority of nodes in MANET rely on batteries, the main contribution of this research is to limit the amount of control information that is passed between nodes (i.e., reducing the control overhead over that in ODMRP) while maintaining a better packet delivery ratio than EODMRP.
1. Introduction
Roused by expanding the utilization of laptop computers and communication over wireless appliances, the wireless communication among mobile users is getting to be progressively of a great interest [1–5]. Currently, there are two varieties of mobile wireless networks [6–9]. The first one is known as the infrastructured networks where there are fixed and central access points or base stations [7, 10, 11]. In these networks, any mobile node can communicate with the access point or base station that falls within its communications range [12–14]. The second type belongs to the infrastructureless mobile networks which are commonly known as the mobile ad hoc networks (MANETs) [15–17]. Nowadays, in the majority of network scenarios, there is no communication infrastructure such as base stations or mobile switching centers or those legacy equipment become expensive and inconvenient to use [18–20]. Therefore, MANETs become useful and are going to be an integral part of the future generation of mobile services [21, 22]. A MANET is a vigorously reconfigurable wireless network wherein the mobility of nodes results in speedy and eccentric changes in the network topology [23, 24]. Each node functions not only as a network host for transmitting and receiving data but also as a network router for routing packets to other nodes [25, 26]. Undeviatingly, ad hoc networks have numerous practical applications such as military applications, emergency operations, and rapid construction of temporal wireless networks [26, 27].
For typical applications, MANETs are employed to support collaborations among teams of users. It is worth mentioning that multicasting is a technique of distributing datagrams from one or more sources to a set of desired multicast receivers [28, 29]. Thus, multicasting support is a critical and desirable feature of ad hoc networks. The rapidly growing technology and popularity of Internet led to many new and challenging applications such as video conferencing, interactive gaming, distributed computing, real-time multimedia playing, and distributed database applications [30]. Interestingly, the common feature of all of these applications is the interactions among multiple users that require constructing a group [31]. However, multicast routing algorithms are considered one of the most important research fields in wireless ad hoc networks as for being able to efficiently deliver data to a set of nodes [32, 33]. As the nodes move randomly and make frequent topology changes in MANETs, power resources, bandwidth, and processing abilities become critical [34]. To cope with the frequent changes in topology, multicast algorithms are always in need of improvements [32, 34, 35].
There are several methods to categorize the multicast routing protocols in MANETs [36, 37]. One of the most popular methods is based on how distribution paths are constructed among group members (i.e., network topology) [38]. In this method, the multicast routing protocols are classified into tree-, mesh-, hybrid-, and stateless-based approaches [38]. Mesh-based algorithms build a mesh as a delivery structure. When the network topology changes frequently, mesh-based protocols have proven to be more efficient than tree-based due to providing redundant routes in the mesh topology [39].
Related Work. One of the most important mesh-based routing protocols is the On-Demand Multicast Routing Protocol (ODMRP) [40, 41]. In this protocol, group membership and multicast routes are established and updated by the source on demand. When a multicast source has packets to send, but no route to the multicast group is available, it broadcasts a JoinQuery control packet to the entire network. In point of fact, this JoinQuery control packet is periodically broadcasted (i.e., every 3 seconds) to refresh the membership information and update routes. When an intermediate node receives the JoinQuery control packet, it stores the upstream node ID and rebroadcasts that packet. When the JoinQuery packet reaches a multicast receiver, it creates and broadcasts a JoinReply control packet to its neighbors. When a node receives a JoinReply, it checks if it is situated on the path to the source and thus it is a part of the forwarding mesh and broadcasts its JoinReply packet. In this way, every JoinReply control packet is relayed back to the source using the reverse path traversed by the JoinQuery control packet. To make the whole process clearer, the authors would like to provide the following details: the main attributes of JoinQuery control packets are multicast group address, sequence number, source IP address, and previous hop IP address. Every multicast receiver has a member table that contains the entries that correspond to JoinQuery control packets received from the source where the JoinReply control packets are prepared to be then broadcasted based on this table. On the other hand, every intermediate node has a message cache and routing table. Every received JoinQuery control packet is checked first for being a duplicate or not. In other words, the received packet is compared with all entries found in the message cache (through utilizing the sequence number and source IP address). If there is a match, it means that it is a duplicate packet. Hence, the node simply ignores it. If there is no match, then it is an original and consequently a new entry is created in the message cache. Thereafter, the routing table is updated accordingly through inserting a new entry or updating an existing one.
It is interesting to mention that the major attributes of JoinReply control packets are multicast group address, previous hop IP address, sequence number, sender (multicast receiver) IP address, and next hop IP address. Upon receiving a JoinReply control packet, the node examines the next hop IP address attribute. If the value of this attribute does not coincide with its IP address, then it simply does nothing. Otherwise (i.e., it matches its IP address), this node is a route member and accordingly builds up its own JoinReply packet. Specifically, it searches all entries available in its routing table to find the one that has a multicast group address and sequence number which comply with those found in the received JoinReply control packet. Upon finding that entry, the node creates a new JoinReply control packet through replacing the next hop IP address (found in the received JoinReply packet) with the previous hop IP address extracted from the entry found. Additionally, it replaces the previous hop IP address (found in the received JoinReply packet) with its IP address. After that, it broadcasts this prepared JoinReply control packet to its neighbor nodes.
It is worthwhile mentioning that there are a lot of antecedently proposed protocols that rely on ODMRP [42–52]. In addition to the original ODMRP, the most pertinent and comparable protocol, to our proposed protocols, is called the Enhanced On-Demand Multicast Routing Protocol (EODMRP) [49, 50]. Intrinsically, it is considered as an enhanced version of ODMRP with adaptive refresh interval of JoinQuery control packet flooding. This adaptation is driven by the multicast receivers' reports on link breakages. The adaptive refreshing mechanism is integrated with a local recovery procedure. The multicast source informs its mesh nodes about the interarrival packet time by storing it as a field inside the broadcasted JoinQuery packet. If a multicast receiver or forwarder does not receive any data packet during five times the announced interarrival packet time, it is considered to be detached from the multicast network. Upon detection of a broken route, a detached node performs a local recovery instead of flooding to attach itself to the forwarding mesh again. If local recovery fails, the detached node requests a global route refresh from the source via a wide flooding of special control packets called RefreshRequest packets which contain the route lifetime that is stored by the disconnected node. When an intermediate node receives a multiple of RefreshRequests within a short time, it relays only the first received one and drops the others despite being generated by different nodes. Once the source node receives a RefreshRequest packet, it adapts its refresh interval time based on the route lifetime extracted from the RefreshRequest packet.
Deficiencies and Challenges. Notwithstanding the simplicity, efficiency, and robustness of ODMRP to mobility, it has some impediments. The static Join Query Refresh Interval Time (JQRIT) introduced in this protocol has a crucial role in its robustness via retaining redundant routes. Thus, the JQRIT is of a most extreme imperativeness to the performance of ODMRP. Such refresh interval cannot be chosen arbitrarily since it has a terrible impact on the network performance. In ODMRP, the preferred value of this parameter is 3 seconds. This is justified by the need of achieving the highest possible packet delivery ratio. Unfortunately, one important dimension has been neglected which is the control overhead incurred to the network. In fact, the robustness is achieved at the cost of increasing the control overhead.
The adaptation of JQRIT proposed by EODMRP for the forwarding mesh is driven by the received RefreshRequest control packet flooding and route lifetime stored in each packet. This means that the mesh nodes have to experience real disconnections and data packet losses in order to make the source aware of the declining condition of the network. This mechanism of feedback has a cost on the network performance in terms of packet delivery ratio. Besides, EODMRP RefreshRequest control packets suppression mechanism consumes node's battery in generating a RefreshRequest broadcast packet which might be dropped later. Additionally, choosing the first received RefreshRequest packet, while waiting for a certain specific time, without paying attention for the route lifetime stored in each received one has severe consequences on the network performance since the source has to involve the route lifetime of that selected RefreshRequest packet (or the average route lifetime of all received ones) in scheduling the new JoinQuery flooding where it may be the longest route lifetime among all received and dropped ones, contributing to packet delivery ratio reduction. Furthermore, the receiving nodes' resources are at risk of waste as for handling, processing, and relaying such packets. Moreover, a multiple of RefreshRequest wide flooding may cause a congestion that may result in having more retransmissions and accordingly high end-to-end delay. In a nutshell, EODMRP JQRIT adaptation mechanism and RefreshRequest packets suppression mechanism are extremely unrepresentative of network dynamics, specially when the network encounters high mobility conditions.
Our Contributions. In this paper, we propose two protocols, Improved ODMRP with Fuzzy Logic Join Query Refreshment (IODMRP-FLJQR) and Improved ODMRP with Slow Start Join Query Refreshment (IODMRP-SSJQR). These protocols follow the same forwarding mesh construction procedure employed in both ODMRP and EODMRP. In addition, they use the same procedure considered in EODMRP for detecting the links breakage but they proposed a new shared mechanism for local recovery and two algorithms for dynamic refreshments as the name implies. However, in local recovery failure routine, we aimed at reducing the RefreshRequests flooding by considering the fact that adjacent nodes have a higher probability to be detached simultaneously from the network within a short time. Therefore, we employ a flooding aggregation technique and create a special type of RefreshRequest control packet named as DelegateRefreshRequest control packet.
In ODMRP and EODMRP, the source node plays a key role in the multicast network because it is the generator of the data packets and is responsible for maintaining the forwarding mesh. Interestingly, any change of the source node speed indicates a change in the level of node mobility and makes the most important node in the multicast network more susceptible to leave its forwarding mesh. Accordingly, our proposed protocols involve the Source Moving Speed (SMS), which can be measured using accelerometer or global positioning system, as a prior indicator of what may cause a weak forwarding mesh and adapt the JQRIT based on not only SMS, but also number of DelegateRefreshRequests (NoDRRs). As a matter of fact, considering these two parameters in finding the appropriate JQRIT is a very challenging task. Hence, two algorithms have been proposed for that purpose, namely, FLJQR and SSJQR. Substantial details for these algorithms are presented in Section 2. However, we consider three performance metrics to evaluate the performance of our proposed protocols which include packet delivery ratio, number of control packets, and average end-to-end delay. Besides, their impacts on the node mobility speed and multicast group size have been extensively studied and professionally discussed. Many simulation experiments have been conducted using QualNet 7.1. Our experiments show that our proposed protocols enact a remarkable control overhead reduction over that in ODMRP and a superior packet delivery ratio under high mobility conditions compared to EODMRP with maintaining a comparable and acceptable number of control regardless of the multicast group size.
Outline. The rest of the paper is organized as follows. Section 2 introduces the research methodology and demonstrates our proposed protocols and amendments over ODMRP and EODMRP. In Section 3, the simulation environment is illustrated. The performance of our proposed protocols is evaluated, discussed, well justified, and professionally verified with relevant protocols in Section 4. Section 5 concludes our paper.
2. Proposed Work
2.1. Overview
In this subsection, we present and demonstrate our proposed protocols as improvements to ODMRP and EODMRP. The proposed work intends mainly to enhance the data delivery ratio, obtained by EODMRP, while preserving low and comparable control packets overhead. Multicast routing can basically be divided into four main procedures which include forwarding mesh creation, links breakage detection, local recovery, and join query refreshment. Those four components will be explained in the following sections in sequence. In this work, we propose two protocols for adapting the JQRIT named as IODMRP-FLJQR and IODMRP-SSJQR. Additionally, we propose an interesting and common approach for local recovery which includes new setup and failure methods. However, in the proposed protocols, the forwarding mesh creation and links breakage detection procedures used are the same as those employed in ODMRP and EODMRP.
2.2. Forwarding Mesh Creation
As considered in EODMRP, the multicast network has mainly four types of nodes: source, forwarder, listener, and multicast receiver. The source node is the data packets originator, the forwarder node is responsible for relaying data packets from source to multicast receivers, the listener is the node surrounding the forwarding mesh or multicast receivers, and the multicast receiver is the recipient of the data packets. As stated earlier, in our proposed protocols, we followed the same forwarding mesh creation procedure employed in ODMRP and EODMRP being cognizant of the fact that listener node is ventilated only in EODMRP, for the sake of using it by the detached nodes to rejoin the multicast network, and is not available in ODMRP.
In a multicast network, the source node is responsible for forwarding mesh creation and maintenance [41, 50]. The purpose of the created forwarding mesh is data delivery for network multicast destinations. Once the source has data to send, it proactively starts mesh creation by flooding the entire network with a type of special control packet called JoinQuery control packet. Source node keeps broadcasting JoinQuery packets frequently as long as it has a certain data, thereby maintaining the constructed forwarding mesh. The frequency of broadcasting the JoinQuery packets depends on a time called join query refresh interval time. Upon receiving a JoinQuery packet, the intermediate nodes verify their originality by exploiting their message caches and accordingly update these caches and their routing tables taking into account that the main fields of JoinQuery packets are multicast group address, sequence number, source IP address, and previous hop IP address. After that, they rebroadcast the JoinQuery packet until it reaches a multicast receiver. Utilizing their member tables, the multicast receivers respond to the JoinQuery packet with a JoinReply control packet and broadcast it through the network towards the source node. As a matter of fact, every JoinReply packet is relayed back to the source using the reverse path crossed over by the JoinQuery packet being mindful that its primary fields are multicast group address, previous hop IP address, sequence number, originator IP address, and next hop IP address. In different words, when a node receives a JoinReply packet, it checks first if it is located on the path to the source (i.e., through making sure that the next hop IP address found in the received JoinReply packet coincides with its IP address) and thus broadcasts the JoinReply packet and accordingly sets its type to be a forwarder that is responsible for relaying data packets from the source to that multicast receiver.
In ODMRP, the forwarders have a lifetime state (or a timeout) which is set to three times of JQRIT. If a forwarder lifetime expires, then it gets discharged from the forwarding mesh [41]. On the contrary, the forwarders in EODMRP do not have a declared lifetime state. Accurately, they keep relaying data (staying in the forwarding state) as long as there are downstream nodes (receivers) receiving data packets. As soon as no receivers exist, forwarders get pruned [50]. Similar to EODMRP, the forwarders, in our protocols, have no defined lifetime state. However, the node type listener is defined typically according to data packets overhearing [50]. In other words, a normal node, which does not belong to any multicast group, turns into a listener upon hearing a data packet relayed by any member of the forwarding mesh group. In detail, if a normal node receives a data packet, it sets its ListenerFlag to “True” for a specific period defined as ListenerFlagTimeout (i.e., one second which is the time to receive four data packets and will be discussed further shortly) [50]. The new listener stores some necessary information extracted from the overheared data packets such as the multicast group address, multicast source IP address, and last time a data packet is overheard (LastDataTimeStamp) where we propose the last field to serve our local recovery that will be illustrated in a little while. When the ListenerFlagTimeout expires, the listener resets its flag and returns back to a normal node. Otherwise, it holds the ListenerFlag set for another ListenerFlagTimeout.
2.3. Links Breakage Detection and Local Recovery
Forwarders and multicast receivers are susceptible to be detached from the mesh due to mobility. In unicast transmission, route breakage can be detected by the acknowledgment absence. Multicast networks need another detection scheme since broadcast has no acknowledgments. We assume the network traffic to be frequent enough to work as an indicator of route breakage. As employed in EODMRP, the multicast source informs its mesh nodes with the interarrival packet time (i.e., 0.25 seconds) by storing it as a field inside the broadcasted JoinQuery control packet. If a multicast receiver or forwarder does not receive any data packet during five times the announced interarrival packet time, the node considers itself to be detached from the multicast network.
As considered in EODMRP, the loss of five data packets triggers the node to start a local recovery by performing a local search to rejoin the existing mesh again. Our local recovery setup begins with broadcasting a special control packet called RejoinRequest packet with a limited Time-To-Live (TTL = 1) to rejoin the multicast network very fast and then waiting for the amount of five times of interarrival packet time (i.e., RejoinResponseTimeout) for any response from the surrounding listeners. The selection of the RejoinResponseTimeout was determined through simulations to maximize the network performance by making sure not losing more data packets and giving all perimeter listeners enough time to respond back. Each listener that receives a RejoinRequest packet sets itself as a temporary forwarder and replies to the disconnected node with a special control packet called RejoinReply packet. The RejoinReply packet role is to inform the detached node with the existence of a surrounding listener and provide it with the LastDataTimeStamp related to it. As previously explained, LastDataTimeStamp is a timestamp of the last time the listener was capable of hearing data packets from any member of the forwarding mesh or any multicast receiver.
Temporary forwarders immediately proceed to forward data packets to the detached node for a specific time (i.e., minimum join query refresh interval time, which is 3 seconds) until one of them is chosen by the detached node to become a permanent forwarder. EODMRP selects its permanent forwarder depending on the first listener that responds disregarding how fresh the listener in overhearing data packet. This mechanism may become deficient since it may choose a listener that is about to timeout and convert back to a normal node (which is the node that is not participating in the multicast network, that is, not a forwarder, multicast receiver, listener, or source) at the moment of selection. Accordingly, in our local recovery setup mechanism, the preference of selecting the best temporary forwarder to be a permanent one, after RejoinResponseTimeout expires, is based on the LastDataTimeStamp recorded in the RejoinReply packet to guarantee that the disconnected node will successfully rejoin the multicast network again before the listener timeout. By way of explanation, the temporary forwarder that has the most recent LastDataTimeStamp is selected, by the detached node, to turn into a permanent forwarder via a special unicast control packet called RejoinTempSelection. Those temporary forwarders that are not chosen clear the temporary status and get back to be listeners.
Figure 1 shows an example of our local recovery setup phase. In Figure 1(a), disconnected node A wants to rejoin the forwarding mesh again. Hence, it broadcasts RejoinRequest packet with a limited TTL = 1. In Figure 1(b), listeners B and C become temporary forwarders, reply with RejoinReply packets, and relay several data packets towards the disconnected node. In Figure 1(c), node A chooses B as a parent node since it has the recent LastDataTimeStamp value and node C gets back as a listener node.
Local recovery setup phase.
In ODMRP and due to having frequent route refreshments (or JoinQuery refresh intervals), there is no local route recovery scheme presented. In other words, no explicit control packets are defined to rejoin or leave the network (multicast group). In fact, any new node which wants to join the multicast group (as a receiver) or receiver which gets disconnected from the forwarding mesh (by cause of mobility) has to wait for the next JoinQuery flooding. It is worth stating that the impact of employing local recovery procedures will be at the cost of not keeping the shortest path from the source to receivers, thereby increasing the latency and decreasing the efficiency. However, in EODMRP, when a local recovery fails (i.e., no responses are received from listeners), the disconnected node floods a RefreshRequest control packet towards the source after inserting a new field called route lifetime which will be detailed in the next subsection. However, when an intermediate node receives multiple RefreshRequest packets within a short time (i.e., a minimum join query refresh interval time, which is 3 seconds), it relays only the first received and drops the others even though they are generated from different nodes, neglecting the route lifetime field in selecting the most important one to relay (i.e., the shortest route lifetime is the best to select). The main drawbacks of EODMRP RefreshRequest control packets suppression mechanism, beside consuming and wasting a part of node power in generating a broadcast packet which might be dropped later, are reducing the packet delivery ratio and increasing the congestion that may occur as a result of flooding multiple RefreshRequest packets that lead to having more undesired retransmissions and consequently high end-to-end delay.
Unlike EODMRP, in our work, we aimed at reducing the refresh requests flooding by taking advantage of the fact that adjacent nodes have a higher probability to be detached simultaneously from the network within a short time taking into consideration that we would never reach the RefreshRequest phase if there is a connected node around. We employ a flooding aggregation technique and create a special type of RefreshRequest control packet named as DelegateRefreshRequest packet. We added a new field inside DelegateRefreshRequest control packet called HopCount. Any node that receives the DelegateRefreshRequest packet creates an entry inside a local maintained table called RefreshRequestTable and stores the HopCount for a specific period (i.e., a minimum join query refresh interval time, 3 seconds). Thereafter, the node increases the HopCount field by one and rebroadcasts an updated DelegateRefreshRequest packet. When a node fails in local recovery and intends to generate DelegateRefreshRequest packet, it uses the RefreshRequestTable to detect if any neighboring node (HopCount is up to two) does generate a DelegateRefreshRequest packet recently. If a neighboring node does, the disconnected node refrains from sending a new DelegateRefreshRequest packet. Using this technique makes the suppression more efficient and representative for a group of disconnected neighboring nodes from the forwarding mesh, which will save the network recourses and enhance the overall network performance. Figure 2 demonstrates our local recovery procedure which includes the setup and failure phases.
Local recovery procedure (setup and failure).
2.4. Join Query Refreshment Mechanism
It is quite interesting to mention that the join query refresh interval time may be chosen to be either static as used in ODMRP, which results in increasing the control overhead that undoubtedly degrades the network performance and lifetime, or dynamic as utilized in EODMRP. In EODMRP, the regularity of flooding the JoinQuery packets (or choosing JQRIT) relies on the route lifetime, found in the received RefreshRequest packets, which is mainly estimated by finding the absolute difference between the time of receiving the first JoinReply packet by the source (route establishment) and the time of detecting the route breakage (node disconnection). The route lifetime describes how long the forwarding mesh is operational for all available receivers. Upon receiving any RefreshRequest packet, the source extracts the route lifetime and accordingly adjusts the JoinQuery flooding rate. In other words, when flooding the next JoinQuery packet and trying to schedule a new one, it will be proportionally affected by all extracted route lifetimes bearing in mind that the average route lifetime (ARL) will be considered if there are more than a received RefreshRequest packet. Pointedly, the JoinQuery flooding rate will be the inverse of ARL decreased by a very small constant (i.e., c), which is required to avoid having any further disconnections (i.e.,
It is noteworthy to state that the dynamic adaptation of JoinQuery refresh interval becomes fruitful if the right tradeoff and feedback based on network dynamics and conditions are considered. To the best of our knowledge, there is no prior work that considered the mobility concern in the investigation of JQRIT. Therefore, ignoring the source node speed from the dynamic refresh interval investigations has a severe effect on the network performance as any change of source node speed indicates a change in the level of node mobility and makes the most important node in the multicast network more frequently liable to leave its forwarding mesh. Consequently, our proposed protocols embed the source node speed as a prior indicator of what may cause a weak forwarding mesh beside the DelegateRefreshRequests mechanism as an indicator of the worst-case scenario the multicast network may experience. Our new algorithms that will be explained shortly find the convenient JQRIT based on not only SMS but also NoDRRs. In few words, the source starts JoinQuery flooding with a minimum JQRIT (i.e., 3 seconds). Hence, after 3 seconds passed from the simulation time, it not only sends a JoinQuery packet but also schedules the next JQRIT based on our proposed parameters (i.e., SMS and NoDRRs). This process will be operative till the end of simulation time.
2.4.1. First Algorithm: Fuzzy Logic Join Query Refreshment
The forwarding mesh is vulnerable to suboptimal chosen values of JQRIT. In a low mobility source node scenario, a longer JQRIT can reduce the number of JoinQuery control packets while still providing sufficiently robust forwarding mesh. By contrast, when the source node moves at a higher speed, a longer JQRIT makes the possibility of the source node to leave its forwarding mesh higher. Therefore, a shorter JQRIT is desirable in high mobility conditions. Similarly, the source node may receive DelegateRefreshRequest packets sent by the forwarding mesh members as a feedback of their conditions. Thereupon, they should also have an influence on the frequency of JoinQuery packets. In different words, if the source node receives larger NoDRRs, then the source node should broadcast more JoinQuery packets in order to reconstruct its forwarding mesh that is collapsed. In this case, a shorter JQRIT is desirable. Analogously, if a source node receives smaller NoDRRs, then the source node should rarely broadcast JoinQuery since smaller NoDRRs indicate more stabilized forwarding mesh. In this case, a longer JQRIT is fair enough to maintain forwarding mesh stability. Based on the above, choosing the appropriate JQRIT that satisfies aforementioned constraints is very challenging. Hence, we propose in the Fuzzy Logic Join Query Refreshment (FLJQR) algorithm a Fuzzy Logic Controller (FLC) mechanism to derive the best JQRIT based on SMS and NoDRRs. Figure 3 shows the architecture of the FLJQR algorithm, which is illustrated as follows.
Architecture of the FLJQR algorithm.
(1) Fuzzifying the Inputs (SMS and NoDRRs) and JQRIT Output Parameters. Genuinely, the fuzzifier maps crisp data values to fuzzy sets and assigns degrees of membership for each fuzzy set. As suggested in [53, 54], we proposed five fuzzy sets for each input and output parameter. To obtain an efficient and effective FLC, the adjacent sets are overlapped by 25–50% [53, 54]. Further details are provided as follows.
(i) Fuzzifying the SMS Input Parameter. The fuzzy sets of the SMS input parameter have the following linguistic names: very low (vl), low (l), medium (m), high (h), and very high (vh). Table 1 shows the assignment of ranges, fuzzy sets, and membership functions of this parameter. As the maximum node speed, reported in EODMRP, is 50 m/s, the SMS is fuzzified between SMS-min = zero and SMS-max = 50 m/s. It is noteworthy to mention that the membership functions do not usually change at runtime. Therefore, we use the membership functions shown in Figure 4. These membership functions are known as Z-shaped, triangular, and S-shaped [55]. They were mainly chosen because of their smoothness, computational speed, and efficiency. Additionally, they can be defined by using a minimal amount of information. Data related to the corner points of a function is sufficient in defining these functions. The Z-shaped, triangular, and S-shaped membership functions are specified according to the following formulas [56]:
Fuzzy set of the SMS input parameter.
Membership functions of the SMS input parameter: Z-shaped, triangular, and S-shaped.
(ii) Fuzzifying the NoDRRs Input Parameter. The fuzzy sets of the NoDRRs input variable have the following names: very small (vs), small (s), medium (m), large (l), and very large (vl). Table 2 shows the assignment of ranges and corresponding fuzzy sets and membership functions. It deserves mentioning that the maximum number of DelegateRefreshRequests observed during our simulation experiments is 24. Therefore, the NoDRRs are fuzzified between NoDRRs-min = 0 and NoDRRs-max = 24. Descriptions of the membership functions used are shown in Figure 5 where the chosen values of a, b, c, d, e, f, and g are 5, 11, 17, 0.5, 1, 16, and 20, respectively.
Fuzzy set of the NoDRRs input parameter.
Membership functions of the NoDRRs input parameter: Z-shaped, triangular, and S-shaped.
(iii) Fuzzifying the JQRIT Output Parameter. The proposed fuzzy sets of the JQRIT output parameter have the following linguistic names: very short (vs), short (s), medium (m), long (l), and very long (vl). Table 3 describes each range of JQRIT along with its corresponding fuzzy set and membership function. Detailed picture is shown in Figure 6 where the values of a, b, and c chosen are 7, 13, and 19, respectively. In EODMRP, the maximum JQRIT chosen is 30 seconds. Hence, JQRIT is fuzzified, in our algorithm, between JQRIT-min = zero and JQRIT-max = 30 s. It is good to stress on the point that the membership functions shown in Figures 4–6 are chosen to maximize the performance of our proposed protocol, IODMRP-FLJQR.
Fuzzy set of the JQRIT output parameter.
Membership functions of the JQRIT output parameter: triangular.
(2) Fuzzy Rules and Fuzzy Inference. Table 4 summarizes the proposed fuzzy rules, which can be used by fuzzy inference to map fuzzy SMS and NoDRRs input sets described in Tables 1 and 2 into fuzzy JQRIT output sets shown in Table 3. The rules generated in Table 4 were designed based on long experiments and tuning using fuzzy logic toolbox in Matlab R2013a to achieve a perfect balance between the SMS and NoDRRs input sets and JQRIT output sets. For example, in Table 4, we can observe that the output “short” is a dominant set in JQRIT output sets. This output is chosen to ensure that the source will broadcast JoinQuery control packet at a convenient rate for a solid forwarding mesh. In rule 25, when the SMS is “very high” and NoDRRs is “very large,” the proposed JQRIT is “very short” which is quite expected. Accordingly, all proposed rules can contribute efficiently to improving the performance of FLJQR algorithm.
Fuzzy logic rules.
2.4.2. Second Algorithm: Slow Start Join Query Refreshment
In our Slow Start Join Query Refreshment (SSJQR) proposed algorithm, we divided the source node moving speed into two ranges: low mobility speed (i.e., 1–30 mps) and high mobility speed (i.e., 31–50 mps). This division of the source node moving ranges was constructed based on the number of disconnections obtained through our simulation experiments while implementing the EODMRP. As illustrated in Figure 7, when the source node moves in a low mobility speed, the source node starts broadcasting JoinQuery control packet with a minimum refresh interval time (MinJQRIT, 3 secs) and exponentially increases the refresh interval time until two-thirds of the maximum refresh interval time (MaxJQRIT, 30 secs) unless no DelegateRefreshRequests are received. If a refreshment time exceeds the two-thirds of the maximum refresh interval with DelegateRefreshRequests absence, the increase of the JQRIT becomes linearly increasing by one-third of the previous JQRIT. The selection of the refreshment time behavior before and after two-thirds of the maximum refresh interval was designed based on experiments to make the refresh interval properly increase with time. However, under high source mobility conditions, the JQRIT decreases proportionately to the difference between the previous and current source node speeds. Whenever the source node receives a DelegateRefreshRequest control packet, it decreases the JQRIT to half of the current defined one (i.e., flight size). Figure 8 explains the whole adaptation of SSJQR algorithm.
SSJQR algorithm under low source node speed.
Flow diagram of SSJQR algorithm.
3. Simulation Environment
3.1. Simulation Assumptions and Model
In our simulation experiments, we assume that the network consists of 100 wireless nodes which were randomly distributed over a 1200 m × 800 m area. Additionally, there is one multicast group, one source, and 20 multicast receivers unless otherwise specified. As employed in [41, 50], no packet or channel error model is considered in our simulations. The mobility model used is our simulations is Random Waypoint model where nodes in the simulation area select a certain destination and move towards it at a random speed that is uniformly chosen between the specified minimum speed (i.e., 1 mps) and selected maximum speed (i.e., 50 mps). Moving directions of each node were also chosen randomly and when nodes reached the simulation terrain boundary, they bounced back and continued to move.
To demonstrate the effectiveness of our proposed protocols, we simulated them using The QualNet communications simulation platform (QualNet 7.1) on a PC with an Intel Core (TM) i7 CPU working at 2.4 GHz with a 2 MB cache and 8 GB RAM. Data points presented in the simulation results were calculated by taking the average of 20 simulation runs to eliminate the effect of any anomalous individual result. To this end, we implemented the EODMRP and used the existing ODMRP provided by QualNet 7.1. As defined in EODMRP, we set the minimum and maximum JQRIT to 3 and 30 seconds, respectively. Additionally, the initial value of JQRIT in EODMRP is set to 30 seconds. On the other hand, as elucidated in ODMRP, the JQRIT is set to 3 seconds and forwarders' lifetime is set to three times the refresh interval time (i.e., 9 seconds). In ODMRP, EODMRP, and our proposed protocols, the source is assumed to remain alive through the whole simulation time.
3.2. Simulation Parameters
Our simulations have been conducted considering different numbers of multicast receivers and node moving speeds keeping in mind that all simulation parameters listed in Table 5 are constants, unless otherwise stated. In our simulations, the source and destination nodes were randomly selected from the nodes available in the network.
Simulation parameters.
3.3. Performance Metrics
The performance metrics used in our experiments are as follows:
Packet delivery ratio, which represents the ratio of the total number of data packets received at the destinations to the total number of data packets sent from the source; the number of control packets, which counts the total number of control packets which were generated by the multicast network; end-to-end delay, which identifies the average end-to-end delay experienced by each data packet on its way from the source node to the destination node.
4. Results and Discussions
To show how efficient our proposed protocols are, we introduce the results for the performance metrics, just specified, considering two dimensions, namely, mobility speed and multicast group size. They are discussed as follows.
4.1. Mobility Speed
Figure 9 illustrates the packet delivery ratio versus different node speeds considering ODMRP, EODMRP, IODMRP-FLJQR, and IODMRP-SSJQR protocols. To easily and numerically trace the results, Table 6 is provided. As for employing a static and short JQRIT (i.e., 3 seconds), ODMRP shows a remarkable and almost constant delivery ratio even in highly dynamic situations. Compared to ODMRP and as the mobility increases, the EODMRP, IODMRP-FLJQR, and IODMRP-SSJQR achieve less packet delivery ratio. In fact, this is a result of using a dynamic JQRIT to reduce the network wide flooding as formerly explained. In a low mobility condition (i.e., nodes' speed less than 30 mps), the EODMRP, IODMRP-FLJQR, and IODMRP-SSJQR show consistent behavior in terms of packet delivery ratio. This is due to the low probability of disconnections that the nodes may experience and high probability of having a successful local recovery. Over EODMRP, our proposed protocols, IODMRP-FLJQR and IODMRP-SSJQR, show improvements of packet deleivery ratio which reach about 5% and 4.6%, respectively, with, of course, a comparable cost in terms of control packets count as will be highlighted shortly. The enhanced performance of our proposed protocols achieved in this figure is due their approaches of keeping a more coherent forwarding mesh.
Packet delivery ratio with various node speeds.
Packet delivery ratio with various node speeds.
In a high mobility condition and considering the low probability of having an efficacious local recovery in EODMRP and our proposed protocols, the ODMRP is still showing steady and better performance compared to EODMRP and our proposed protocols since, as stated earlier, it keeps refreshing the forwarding mesh based on a short and static JQRIT. The divergence of EODMRP performance, compared to our proposed protocols which have somehow consistent and steady behavior, proved how poor the EODMRP is in reacting to high mobility conditions of the network. As far as the packet delivery ratio is concerned, our proposed protocols impressively outperform the EODMRP of about 75% as the node speed increases to 50 m/s. This superior behavior of IODMRP-FLJQR and IODMRP-SSJQR, beside the relative better performance in low mobility conditions, is due to their common method of involving the source node moving speed as a prior indicator of possible coming crackles in multicast routes before they actually happened and reported. Furthermore, our DelegateRefreshRequest procedure affirmed its effectiveness rather than the normal RefreshRequest procedure used in EODMRP in reporting link breakages in the network without causing network congestion. The discussions related to the differences of our proposed protocols will be provided shortly.
Figure 10 shows the number of control packets generated by ODMRP, EODMRP, IODMRP-FLJQR, and IODMRP-SSJQR against different node speeds. It is clearly noticed that the outstanding performance of ODMRP in terms of packet delivery ratio, shown in Figure 9, is at the expense of control packets overhead. In other words, Figure 10 illustrates that the ODMRP induces nearly 35000 control packets, more than the two-time dose of the other protocols, to achieve a packet delivery ratio close to 92%, as shown in Figure 9. This can be justified as the ODMRP induces significantly more JoinQuery wide flooding packets regardless of the mobility condition to maintain a robust forwarding mesh structure and exhibit better reliability. It is good to point out that this huge number of control packets, generated by ODMRP, has a severe impact on the network in terms of bandwidth and node battery. However, for efficient results interpretations, Table 7 is included. For a dynamic JQRIT, it is more reasonable to have an increasing number of control packets as the mobility increases in order to adapt more properly to network changes. Unfortunately, the steady behavior of EODMRP as the mobility increases, as shown in Figure 10, indicates that the RefreshRequest flooding mechanism and suppression are wasting of network resources and inefficient in reporting the network breakdowns. This also distinctly explains the degradation of EODMRP performance as the mobility increases, in terms of packet delivery ratio (as shown in Figure 9), while maintaining approximately the same level of control packet injection to the network. In light of prior discussions related to EODMRP behavior, we conclude that the fact of using the JQRIT properly has failed, as the multicast network dynamics have not been taken into consideration.
The number of control packets with different node speeds.
The number of control packets with different node speeds.
As shown in Table 7, the IODMRP-FLJQR and IODMRP-SSJQR cause an increase in the number of control packets as the network mobility speed increases, which is more logical and convincing. In fact, this is in view of involving the source node speed factor in their adaptations. Compared to EODMRP, this surplus number of control packets, induced by IODMRP-FLJQR and IODMRP-SSJQR, contributes to building a more coherent forwarding mesh than EODMRP, leading to a better packet delivery ratio, as shown in Figure 9.
Figure 11 illustrates the end-to-end delay against different node speeds where numeric values are provided in Table 8. It is good to stress on the point that the more robust the forwarding mesh built by the source, the better the packet delivery ratio and the lower the average end-to-end delay obtained. Since ODMRP has the most robust forwarding mesh, it achieves the lowest end-to-end delay. The EODMRP brings about the highest end-to-end delay compared to other protocols, especially in high mobility conditions, because as the mobility speed increases, its decrepitude of constructing a robust forwarding mesh increases. In comparison with EODMRP, the IODMRP-FLJQR and IODMRP-SSJQR achieve a lower end-to-end delay since they maintain a more solid forwarding mesh.
End-to-end delay with omnifarious node speeds.
End-to-end delay with various node speeds.
Scrutinizing the behaviors of IODMRP-FLJQR and IODMRP-SSJQR, shown in Figures 9, 10, and 11, we can recognize the marginally improved performance of IODMRP-SSJQR over IODMRP-FLJQR under different mobility speeds in terms of packet delivery ratio. This difference results from the modest robustness of forwarding mesh that the IODMRP-SSJQR could build. As expected, this robustness comes at the cost of having higher control overhead. Particularly, the IODMRP-FLJQR sustains on average a lower number of control packets that may reach up to 841 packets relative to IODMRP-SSJQR when the maximum node speed is raised up to 40 and 50 mps. In detail and under low mobility conditions, the IODMRP-SSJQR operates a slow start mechanism regardless of the source node speed and effectively responses a bit exaggeratedly to any abrupt change that may occur under high mobility conditions which in turn induce a relative increase in the control packets over IODMRP-FLJQR that is characterized by affording a wide dynamic range of JQRITs.
4.2. Multicast Group Size
To investigate the scalability of our proposed protocols, we introduce our results considering different number of multicast members along with several mobility conditions.
4.2.1. Multicast Group Size under Low Mobility
Under low mobility conditions, we set up the network to have a source, mobility speed of 20 m/s, and different multicast receivers (i.e., 10, 20, 30, and 40). However, Figure 12 depicts the packet delivery ratio of ODMRP, EODMRP, IODMRP-FLJQR, and IODMRP-SSJQR versus different multicast receivers. As shown in this figure, the packet delivery ratios of just mentioned protocols increase gradually as the number of multicast receivers increases. This increase is a consequence of having a larger number of redundant routes that are created as the multicast group size grows more. It is worth mentioning that these protocols are mesh based. Hence, as the number of multicast receivers increases, the mesh structure becomes more massive. When the multicast network becomes denser, the data packets are routed through multiple paths and get more chances to be delivered to destinations even when the primary routes are unavailable.
Packet delivery ratio with a mobility speed of 20 m/s and varying multicast group sizes.
It is plainly shown in Figure 12 that among all protocols and as the number of multicast receivers increases more and more, the ODMRP keeps performing the best. This is due to the sturdy forwarding mesh that turns to having the largest number of available routes as a result of having the shortest JQRIT. As the routes are refreshed less frequently in EODMRP, IODMRP-FLJQR, and IODMRP-SSJQR, fewer redundant routes are available. Over EODMRP, our proposed protocols attain an improvement in the packet delivery ratio of about 7% in scalable multicast network since they have an efficient mechanism in refreshing the forwarding mesh structure.
Figure 13 demonstrates the performance of ODMRP, EODMRP, IODMRP-FLJQR, and IODMRP-SSJQR with respect to the number control packets in opposition to different multicast group sizes. It is clearly seen, in all protocols, that the number of control packets increases as the number of multicast receivers increases. As a matter of fact, increasing the number of multicast reciviers means having more JoinReply control packets spread over the network as a response to wide flooding JoinQuery control packets. However, the ODMRP acquires the largest number of control packet generated which exceeds about 41000 packets. Interestingly, the IODMRP-FLJQR and IODMRP-SSJQR accomplish a number of control packets which is basically 75% less than that in ODMRP. Moreover, they require a slight increase in the control packets, over EODMRP, which was lucrative in improving the packet delivery ratio.
The number of control packets with a mobility speed of 20 m/s and varying multicast group sizes.
Figure 14 describes the average end-to-end delay each data packet takes to reach the group multicast receivers in contrast to various multicast group sizes. As the multicast group size gets larger and larger, the ODMRP exploits more and more redundant routes (for data delivery) that lead to having a higher and higher number of forwarding nodes to relay data packets which result in increasing the control packets overhead and consequently having more contention and collision that turn to prolonging the end-to-end delay. The augmentation (raise) in the end-to-end delay for EODMRP, IODMRP-FLJQR, and IODMRP-SSJQR as the multicast group size increases though they have less control pacekts overhead than that in ODMRP is truely questionable. Actually, the dynamic refreshment and longer JQRIT (as for considering low mobility conditions) make the possibility of having link breakages higher. As the multicast network becomes denser, the local recovery procedures employed in EODMRP, IODMRP-FLJQR, and IODMRP-SSJQR come to be more successful. In other words, the disconnected nodes get more chance of having surrounding listeners for a longer time to rejoin the network. It is good to mention that the local recovery procedures, employed in these protocols, do not guarantee choosing the shortest path. For example, in our protocols, the disconnected nodes select their parent forwarders based on how recent they are in overhearing data packet, not based on the shortest path. This contributes to increasing the end-to-end delay. It cannot be missed to be mentioned that the EODMRP consummates the highest end-to-end delay, regardless of the number of multicast receivers, and more seemingly noticeable in denser multicast network. Apparently, this is due to having the weakest forwarding mesh which leads to having the largest occurrences of link breakage and consequently excessive calling to local recovery procedures. It is undeniable that IODMRP-FLJQR and IODMRP-SSJQR outperform EODMRP as for being more affluent in maintaining a coherent forwarding mesh.
End-to-end delay with a mobility speed of 20 m/s and different multicast group sizes.
4.2.2. Multicast Group Size under High Mobility
Under high mobility conditions, we set up the network to have a source, mobility speed of 45 m/s, and different number of multicast receivers (i.e., 10, 20, 30, and 40). However, Figures 15, 16, and 17 illustrate the packet delivery ratio, number of control packets, and end-to-end delay, respectively, versus several multicast receivers considering ODMRP, EODMRP, IODMRP-FLJQR, and IODMRP-SSJQR protocols. Obviously, it is seen in all figures that all protocols have a consistent behavior over those shown in prior relevant Figures 12, 13, and 14 taking into consideration the significant contributions of our proposed protocols as for increasing the mobility speed of the network. With reference to the packet delivery ratio, our proposed protocols outperform the EODMRP of about 92% when the multicast group size is set to 10 while keeping a low and comparable number of control packets. As far as the end-to-end delay is concerned and regardless of multicast group size, the IODMRP-FLJQR and IODMRP-SSJQR greatly surpass the EODMRP.
Packet delivery ratio with a mobility speed of 45 m/s and different multicast group sizes.
The number of control packets with a mobility speed of 45 m/s and various multicast group sizes.
End-to-end delay with a mobility speed of 45 m/s and various multicast group sizes.
In light of what we have explained when studying the influence of having different multicast receivers and mobility speeds on our proposed protocols and formerly proposed ones, we can state full of proudness that our proposed protocols attested to be extremely efficient in scalable networks and various mobility conditions. Through our experiments, the IODMRP-FLJQR and IODMRP-SSJQR have nearly the same packet delivery ratio under different network variables but with a slight difference in the number of control packets. In different words, the IODMRP-SSJQR gives rise to relatively having more number of control packets throughout the network which may degrade the network performance, especially at the dimension of power consumption. Nevertheless, in connection with complexity, the IODMRP-FLJQR requires more difficult implementations as for necessitating more lines of code (LOC) and floating point operations which trigger increasing the amount of computations that severely affect the power consumption. Thus, as a tradeoff, both of proposed protocols are interesting and worth exhibiting.
5. Conclusion
In this paper, two new On-Demand Multicast Routing Protocols have been proposed as improvements to ODMRP and EODMRP in mobile ad hoc networks that are IODMRP-FLJQR and IODMRP-SSJQR. The performance of these proposed protocols has been examined thoroughly utilizing three metrics which include packet delivery ratio, number of control packets, and average end-to-end delay. Moreover, their reactions (responses) to employing different node speeds and multicast receivers have been extensively studied and sophisticatedly discussed. However, many simulation experiments have been conducted using QualNet 7.1 and eventually concluded that our proposed protocols have a splendid packet delivery ratio compared to EODMRP under high mobility conditions while maintaining a comparable and acceptable number of control packets regardless of multicast group size. Furthermore, our proposed protocols have an improved end-to-end delay, with rapprochement to EODMRP, irrespective of mobility speed and multicast group size since they are more efficacious in building and refreshing the multicast forwarding mesh. In addition, they achieve extraordinary improvements over ODMRP with respect to control overhead. It is noteworthy to mention that IODMRP-FLJQR and IODMRP-SSJQR achieve almost a close packet delivery ratio (i.e., the latter is a bit higher) under different mobility speeds and multicast group sizes but with a little difference in the number of control packets. Specifically, results show that IODMRP-SSJQR generates marginally more number of control packets over IODMRP-FLJQR. As far as the complexity dimension is concerned, both refreshment algorithms run in a constant complexity
Footnotes
Conflict of Interests
The authors declare that there is no conflict of interests regarding the publication of this paper.