Abstract
A mobile ad hoc network (MANET) consists of a self-configured set of portable mobile nodes without any central infrastructure to regulate traffic in the network. These networks present problems such as lack of congestion control, reliability, and energy consumption. In this paper, we present a new model for MANET multicasting called Reliable and Energy Efficient Protocol Depending on Distance and Remaining Energy (REEDDRE). Our proposal is based on a tone system to provide more efficiency and better performance, and it combines solutions over the Medium Access Control (MAC) layer. The protocol consists of a new construction method for mobile nodes using a clustering approach that depends on distance and remaining energy to provide more stability and to reduce energy consumption. In addition, we propose an adjustment to the typical multicast flow by adding unicast links between clusters. We further present in our model a technique to provide more reliability based on a busy tone system (RMBTM) to reduce excessive control overhead caused by control packets in error recovery. We simulate our proposal using OPNET, and the results show enhancement in terms of reliability, packet delivery ratio (PDR), energy consumption, and throughput.
1. Introduction
Nowadays, most organizations and companies make their services available on the Internet so that they may be reached by many different users. In contrast, if multiple users ask for a service, it is better to use multicast transmission in order to save time and effort. By using the broadcast nature of wireless transmission, a multicast can be used to improve the efficiency of a network by sending a number of copies instead of sending one copy individually; this may reduce the communications cost of applications that use multicast instead of unicast.
A great number of current applications require a reliable multicast scheme, meaning that one sender must ensure data delivery to multiple receivers; this may sometimes be hard to do, especially in a wireless environment. Wireless environments may suffer from packet loss more frequently than wired environments, but such losses still happen in both environments. By using multicast transmission, we can reduce the consumption of links’ bandwidth and reduce the time for using these links.
A mobile ad hoc network is a combination of moving mobile nodes that form a temporary network without support from any centralized admission or infrastructure such as access points or base stations. The term ad hoc is of Latin origin and means “for this purpose,” which in this case signifies that the network exists for special circumstances and is dismantled easily (on-the-spot) [1].
In MANETs, all moving nodes coordinate among themselves to enable communication and to manage routing and resources; this is done in a distributed manner. This means that each node in the MANET must be more intelligent, so that it can operate as a sender for transmitting messages, can receive data from another master sender that received the original message, and can work as a router for forwarding packets to other nodes [2].
MANETs work in a highly dynamic and distributed nature, and nodes are mostly battery powered and have a limited power source; thus, energy consumption is a key issue in MANETs, sometimes causing failures in a node that can affect the whole network. If one node runs out of power, the probability of network separation will increase; therefore, to prolong the lifetime of the MANET, we need to consider energy efficient ways to reduce the consumption of network energy, such as announcing the remaining energy of a node, which will avoid depletion of energy and reduce the probability of network separation [1].
This paper is organized as follows. Section 2 discusses MANET multicasting issues and challenges. In Section 3, we build a tree-based clustering approach for construction of a network depending on distance and remaining energy (REEDDRE) to reduce energy consumption. In Section 4, we present a model called RMBTM for providing reliability in a MANET and we report its architecture and description. In Section 5, we list the simulation results. Finally, we present the conclusion in Section 6.
2. MANET Multicasting: Challenges and Issues
Issues and challenges presented by MANET multicasting include the following [2–10].
2.1. Resource Management
Mobile nodes in MANETs are limited in resources such as power and memory, so a multicast protocol minimizes the consumption of these resources and utilizes them in such a manner as to ensure competent handling of information with efficient resource consumption, such as by minimizing the use of state information packets.
2.2. Link Failure
Because of the random mobility of the nodes and the wireless nature of links, link stability is hard to preserve in mobile ad hoc networks.
2.3. Control Overhead
In multicast transmission, we need to keep track of the members involved in the multicast transmission; thus, we need control packets to be exchanged between them. Since only limited bandwidth is provided in MANETs, this may result in significant overhead requirements, so the design of MANET should take into consideration the need to keep the control packet size to a minimum.
2.4. Efficiency
In MANETs, errors and failure are more likely to happen than in ordinary networks due to their mobility and limited bandwidth. Therefore, in the multicast protocol design, efficiency is very important. Efficiency as used here is the ratio of received data to the total number of transmitted packets in the network.
2.5. Reliability
Reliability is the key issue in multicast transmissions in MANETs, and this can be difficult to deliver due to the differentiation in the members involved and the fact that any member can disconnect from the network at any time, in consideration of its environmental conditions.
2.6. Wireless Nature
The wireless nature of a MANET makes it vulnerable to the numerous types of attacks that are common to wireless links such as snooping, interference, and eavesdropping, which may also affect the network resources. Attackers can use these methods to prevent the normal communication scenario among nodes or to capture valuable information.
2.7. No Defined Physical Boundary
Due to mobility, we cannot define exactly the boundaries of our network, and the nodes can join or leave the network because of radio coverage. The scalability of MANETs is changing, so the security mechanism must be able to handle large networks as well as smaller networks, which makes for a difficult task.
2.8. Absence of Centralized Management
Detection of possible attacks is difficult due to the absence of centralized management such as an access point or base station that can monitor the traffic in a MANET, especially if the network is deployed over a large scale, which may delay the trust between involved nodes.
2.9. Infrastructure
Mobile ad hoc networks are infrastructureless, and there is no central administration that can regulate the communication between involved nodes. This means that every node can communicate with other nodes, which makes it difficult to detect faults happening in the network, and because of the highly dynamic topology of MANET, frequent network separation and route changing can result in the loss of packets.
2.10. Limitation in Power
The nodes in mobile ad hoc networks are battery powered; this restriction may cause problems such as the loss of packets, or the nodes may work in a selfish manner, meaning that they do not forward messages received.
2.11. Trust
The lack of central administration and the highly dynamic topology of MANETs may result in a lack of trust between involved nodes due to the absence of verification and the fact that some nodes may participate in a transmission even if they are not part of the network, which may result in security breaches in the network or leaks of valued information.
2.12. Security
Attacks may happen in MANETs due to their wireless nature and the lack of centralized admission of mobile ad hoc networks, which make these networks vulnerable to attacks such as eavesdropping and wormhole or black hole attacks. As such, it is essential for the multicast protocol to ensure security.
2.13. Quality of Service
The applications that currently rely on MANETs vary greatly, and these include military applications. Quality of service is an important issue in such applications, but ensuring quality of service by multicast can be difficult for reasons including throughput, delay, and reliability. The design of a multicast protocol should take into consideration the need to provide these parameters.
3. Reliable and Energy Efficient Protocol Depending on Distance and Remaining Energy (REEDDRE)
We propose herein a hierarchical tree-based design with a specified type of predefined clustering approach for MANET multicasting. From the literature on routing protocols, we found that most routing protocols do not depend on power preservation of nodes, which is critical to provide the reliable multicast which is our goal. We propose a new reactive technique that depends on the distance and the remaining energy of nodes in the mobile ad hoc network, which we call the Reliable and Energy Efficient protocol Depending on Distance and Remaining Energy (REEDDRE).
The proposal comprises the following stages. In its first stage, we define the route request and route replay mechanism. In the second stage, we build a multicast tree with clustering approach from the master sender (MS), which is the node that sends the original message to the involved members, by dividing these nodes into three clusters according to two calculated thresholds of distance: cluster 1, the nodes nearest to the MS; cluster 2, the nodes at a medium distance according to threshold 1; and cluster 3, the farthest nodes from the MS according to threshold 2. In the third stage, we propose an efficient way of saving resources in all nodes in all clusters in our tree construction by calculating the remaining energy. In the final stage, we propose an adjustment to the flow of the multicast such that, according to our construction, each cluster will receive the message in a consecutive order.
3.1. Route Discovery in REEDDRE Protocol
In REEDDRE, routes are established based on on-demand techniques. Route discovery in our protocol and other reactive protocols is based on the request route (RREQ) packet and route reply (RREP) packet has been used for traditional AODV protocol. In our protocol, we propose a modification to this request-reply packet procedures. In our model, we apply tones to these request and reply packets that will be sent before the RREQ and RREP packets to make our model more efficient in terms of saving the network resources. Since our model is supporting using tones of short pluses, we will add predefined tones for the request and reply mechanism.
For RREQ, the relative tones are called route request tones (RRQT) and for RREP the relative tones are called route reply tone (RRPT). Using these tones will enable the system to avoid control overhead and collision of packets and can reduce the effect of black hole attacks happening in such reactive protocols. For establishing routes in our protocol, all route requests will be sent and from the node that has the original message, which is called the master sender (MS) and collected from other mobile nodes toward this node.
The MS in our protocol will send two route request tones (RRQT) having a predefined duration (i.e., 20 microseconds each) prior to the request packet in order to search for a destination. If the destination is reached, it will respond with two route reply tones (RRPT) also of a predefined duration (i.e., 25 microseconds each) prior to the reply packets. Request and reply packets will be sent only if the tones are received successfully. This will introduce some kind of reliability and will prevent reply packets from colliding.
To utilize using tones for our protocol, the duration and the spacing between tones should be unified and predefined. Fortunately, there are many standards that offer spacing frames that have been offered in IEEE 802.11 WLAN that can offer collision avoidance mechanism. We will use them in our model but with minor modification to be adopted for MANET. In our model, we will use a standard frame space and a backoff algorithm with a distributed coordination function (DCF) using interframe space (DIFS) that contain short interframe space (SIFS) which will be mainly used in our model.
The procedures of route discovery in our model will be as follows: first for RREQ method, RREQ consists of two spaced RRQT sent before the RREQ packet and each RRQT is bounded by two SIFS. Second for RREP method, if the destination is reached and also the RRQT is received, it will reply with appropriate two spaced RRPT also bounded by two SIFS and then RREP packet as depicted in Figure 1. We shall use different durations for the route request tone and the route reply tone to distinguish between them and to avoid malfunctioning of the system.
(a) Successful request-reply packet exchange
(b) Failed request-reply packet exchange
The MS will save the routes to this destination as well as the intermediate nodes that make the route to this destination valid in the routing table. This process will be repeated if there is need to establish new routes. This will introduce some delay in the process but only successful received tones will make the destination respond with a packet and this will reduce the waste of the network by using short tones which involve short pulses and will not cost the network.
In MANET, the nodes are moving freely without any constraints to this mobility. In order to keep track of all mobile nodes, mobile nodes should send an updating message when they change their location broadcasted in the network. If the number of update messages is large, a new routing discovery procedure should be established to update the routing tables for the new locations and the intermediate nodes.
If no update message is received, we assume that all routes remain in the same position and other messages with different master senders should take the same discovered routes. This will reduce the overhead required in using route discovery techniques.
3.2. Distance Distribution and Clusters Construction
In our REEDDRE protocol, we build three hierarchical clusters between the MS and the receiving node, depending on distance. In our approach, we assume that all nodes are equipped with devices that calculate the position of involved nodes (e.g., GPS). The geographical locations of all nodes are thus measured periodically by a GPS device, and these nodes will broadcast their locations. Update messages will be sent only if the nodes move to another location to reduce the overhead delivered from these update messages.
From the information delivered by the GPS device, we can determine the two farthest nodes reached in the whole network. From there, we can define two distance thresholds to divide our network for clustering purposes. We divide our network into three levels according to the two distance thresholds calculated based on the transmission of a message from the MS to the two farthest nodes in the network.
We list the following formulas for calculating the distance thresholds:In level 1, the first cluster will be formed depending on the threshold distance . The nodes that are located before this threshold are members of cluster 1, and these nodes are considered to be the nearest nodes to one of the farthest nodes that define . In level 2, the second cluster will be formed depending on threshold distance and threshold distance . The nodes that are located between distance thresholds and are members of cluster 2. In level 3, cluster 3 is formed containing all the remaining nodes, of which locations are greater than the threshold .
In Figure 2, we assume that the MS is in the first cluster and is the farthest node from the north and that node 14 is the farthest node from the south. This information is delivered from the GPS devices in all nodes. First, we calculate as the difference between N14 and the MS. Second, we calculate the distance threshold , which equals (), to form cluster 1, and finally, we calculate the distance threshold , which equals () to form cluster 2.
As a result, nodes MS, N1, N2, N3, N4, and N5 will form cluster 1. After that, we calculate the distance threshold , which is equal to (). Then, the nodes which are located between and will form cluster 2; in this case, N6, N7, N8, N9, N10, and N11 are the members of cluster 2. Finally, all remaining nodes, which are greater than , will form cluster 3. N11, N12, N13, N14, N15, and N16 are the members of cluster 3, and these members are considered the nearest nodes to the farthest node from the south, N14.
Once the distance thresholds are defined and the members of each cluster are known. Mobile nodes should send membership message to the MS or to the relative cluster head to inform these nodes with their locations and to be a part of a multicast tree happening in each cluster.
The cluster which includes the node which has the MS is called the home region cluster, because it will start multicasting the message. Each cluster member can be classified into the master sender, which has the original message; gateway nodes, which will forward the message to other clusters; and relay nodes, which will remulticast the message into their own clusters. This will be discussed in more detail in the next section.
By dividing the nodes into two distance thresholds, we can ensure that all clusters will have at least one member and that nonoverlapping clusters will form, but we cannot ensure that the distribution in all clusters will be even.
3.3. Calculating the Remaining Energy of Nodes
In mobile ad hoc networks, the stability is important. To increase the stability in MANETs, every node in the network should be power aware, meaning that each node must calculate its remaining energy and announce it periodically, which is done with the assistance of the physical layer in all nodes in the network. To announce the remaining energy of nodes, all mobile nodes should follow these equations as follows.
In transmission, the consumed power is calculated aswhere is the needed energy for transmission and is the time needed for this transmission.
In reception, the consumed power is calculated aswhere is the needed energy for reception and is the time needed for reception operation.
Thus, from (2) and (3) the remaining energy of a node can be easily calculated as [1] After calculating the remaining energy, all nodes should announce the remaining energy by broadcasting these values in the network to help the MS to create general idea about the energy level in network for further actions.
After all nodes have announced their remaining energy and locations, classification of the nodes role is applied. Thus, in the home region cluster, the MS node will be defined, after which we sort nodes depending on their distance from the distance thresholds. We pick the nearest node to the distance threshold to serve as a gateway node, which will forward the message from one cluster to other clusters.
In the other clusters which are not the home region cluster, we also sort the nodes depending on their remaining energy and we pick the nodes with the maximum remaining energy to be the cluster heads and the relay nodes for further retransmission in their cluster.
To preserve the energy in the network, the nodes in the network may operate in different modes; that is, along with the transmission mode and the reception mode, we add the listen and sleep modes, which provide improvements to the stability of the network. Transmission mode means that the node is either the MS or a node that transmits to other nodes by unicast. Reception mode means that the node is a recipient of either our multicast member or a unicast transmission. Listen mode means that the node is ready to receive, which means that it has enough energy to do so, but it is not included in the multicast message and other nodes want to transmit to it. Sleep mode means that the node has a lack of energy; it thus turns on sleep mode until its battery is charged. In some cases, nodes in sleep mode may be involved in the multicast message; in this case, after charging the battery this node may ask the nearest node to unicast the message to it. In our tree-based design, we need to know which node has the maximum remaining energy in all clusters.
In the example shown in Figure 3, N3 (which is in cluster 1) and N8 (which is in cluster 2) will be gateway nodes and will forward the message from cluster 1 (the home region) to cluster 2 and from cluster 2 to cluster 3. Furthermore, after sorting the nodes depending on the remaining energy, N6 (which is in cluster 2) and N13 (which is cluster 3) will be relay nodes in their clusters (cluster head) because they have the maximum remaining energy in their cluster. In addition, we can see that N5 and N12 are in sleep mode because they have less energy than the threshold of energy permitted to be involved in communication where N11 and N15 are listen mode which means they have enough power to be a part of the multicast transmission.
After routes have been discovered, the network has been divided into clusters, and all nodes have announced their remaining energy, all nodes will be assigned with hybrid addresses containing a node ID, which may be a MAC address, and a cluster ID. If there is no transmission, joining or leaving cluster is permitted; however, if there is transmission, joining or leaving clusters is not allowed; this is to avoid misbehavior of the addressing technique. If the node enters a new cluster, which means that it passes one of the two distance thresholds, it will send an update message to inform the cluster head that it has become a member of the cluster. The update message will contain the new node address and its location.
3.4. Multicast Traffic Flow Adjustment in Our REERRDE Protocol
In this phase, we will adjust the typical flow of the multicast network to adopt MANET properties and clustering properties. In our REEDDRE protocol, once the MS picks up nodes of multicast tree, all nodes should be able to send an acceptance tone with a predefined duration (i.e., 35 microseconds) to inform the sender that it is a part of the multicast group. We assume that all nodes should be able to buffer the message for further retransmission if needed.
After we divide the network into three clusters according to distance, the MS will pick up all wanted nodes, and routes will be discovered in all three clusters by sending to the nodes a send synchronization packet (SSP) and expecting an acknowledgment acceptance tone (AT) from the nodes with enough energy.
The MS will multicast the message to nodes in cluster 1 (the home region cluster) to preserve as much energy as possible, and this will be multicast group 1. We assume that only the master sender and the gateway node will save the message in their buffers for further retransmission if needed and that all other nodes are not required to save the message. This will minimize the capacity overhead, leading to better results in the congestion status of these nodes.
After that, in cluster 2 we find which node has the maximum remaining energy, and this node announces itself as the cluster head in cluster 2. The closest node from cluster 1 (gateway node of the home region cluster) will retransmit the message by unicasting the message to the node which has the maximum remaining energy in cluster 2; then this node (the relay node or the cluster head node) will remulticast the message of the MS in cluster 2. This will be the multicast group 2, and again only the relay node and gateway node of this cluster will save the message in their buffers.
In cluster 3 the node which has the maximum remaining energy will announce itself as the cluster head, and the closest node from cluster 2 (the gateway node of cluster 2) will retransmit the message by unicasting the message of the MS to this node. Again, this node which has the maximum remaining energy in cluster 3 (relay node or the cluster head node) will remulticast the message in cluster 3, which will be considered as multicast group 3. Since in this cluster no gateway node is needed, only the relay node will save the message of the master sender in its buffer. By doing this we preserve the energy of the MS and try to optimize the consumed energy in the whole network.
Unicast links between the gateway nodes and the relay nodes must contain a high level of reliability and error detection and correction mechanisms, because this is an essential procedure that moves our message from one partition to another.
Our system may result in some delay at the beginning of initialization but overall it provides an efficient way of handling the consumption of energy. Nodes whose energy has run out will not cause a message to remain in one cluster and not move to the next partition because we use some kind of acknowledgment of reception which is needed in a reliable scheme of multicast transmissions, and this causes an endless loop in our network.
After this adjustment, we conclude the cluster formation of the multicast batch. There are only one master sender, which is located in home region cluster; two gateways nodes, located in the home region and in cluster 2; and two relay nodes or cluster head nodes, which will remulticast the original message and are located in cluster 2 and cluster 3. This structure will reduce the formation overhead because only a few roles of nodes are required to perform multicast in the network and to reduce the cluster construction complexity.
Figure 4 shows the traffic modification procedures. In home region cluster the MS multicast the message within its cluster boundaries, N3 is the gateway node of this cluster which will save the message and forward it by unicasting the message to cluster 2.
In cluster 2, N6 is the cluster head and N8 is the gateway node of this group. The cluster head will remulticast the message within the boundaries of cluster 2 and N8 will save and forward the message to cluster 3 by means of unicast transmissions.
In cluster 3, N14 is the cluster head of this group, which will remulticast the message after receiving it from N8. At this stage all multicast group receives the original message coming from the MS.
4. Reliable Multicast Based on Busy Tones in MANETs (RMBTM)
This is a similar system to the system proposed in IEEE 802.11 [3], but we modify it to be convenient for MANETs. When we have several receivers, multicast transmission is very useful compared to unicast transmission to each receiver. It can save time, reduce the redundancy of retransmission, and preserve the bandwidth of the network. Unfortunately, multicast transmission does not support reliability in the exchange of a packet, as there are no control packets that may support reliability, such as the three-way handshake send, receive, and acknowledgment, which are used in unicast transmissions.
Several protocols have been proposed to provide reliable multicast transmissions. However, they are not efficient for MANETs because of the nature of the MANET network or due to excessive use of control packets in error recovery, which may cause an unacceptable overhead. We propose a simple and effective scheme, called reliable multicast based on busy tone for MANET (RMBTM), which can be used in our model. The novel idea behind this model is that we combine two well-known methods for error detection or error recovery over the MAC layer, the ARQ (Automatic Repeat Request), and FEC (Forward Error Correction), with tone-based acknowledgments to reduce the retransmission number and to provide data reliability in the multicast environment.
The RMBTM may support multimedia transmission because it can support block transmission, which means the data stream into a number of blocks. In our RMBTM model, all mobile nodes are equipped with a tone-based system that uses short pulses of energy replacing the control packets; this increases the efficiency in MANETs by reducing the excessive usage of control packets.
These tones are categorized by different time durations to ensure good performance in the model. Tones are used as a replacement for acknowledgment in the handshake process. The first type of tone that we will use in our model is called the feedback request tone (FRT), which is sent from the MS to all involved multicast nodes to check whether the received data are correct or not; the duration of feedback request tones is fixed. The other types of tones used in our RMBTM model are packet request tones (PRTs) from the receiver to the MS, and the tone number of packet request is determined by how many packets must be recovered.
4.1. RMBTM Architecture
Figure 5 shows the proposed system architecture for providing reliable multicast transmissions in the MANET. In the architecture, MS sends data packets to all multicast receivers, and these MS alternates between different receivers due to different scenarios in multicast transmissions and different messages.
All mobile nodes of the proposed RMBTM model are equipped with ARQ and FEC in their MAC layer to provide the error discovery and error recovery mechanisms. At receiver nodes, the FEC tries to recover any errors that occurred in the packet. If it is unable to do so, the receiver will ask the MS or cluster head to retransmit via ARQ. The function of the FEC is, after receiving a number of packets of one block, to produce a parity check of packets for use in error recovery. The ARQ function is to retransmit the original message if the FEC fails to recover data.
First, the MS or the cluster head divides the original message into a number of blocks with the same size; then the MS or the cluster head sends each block individually, which contains a certain number of packets. After transmitting a number of packets of a block, the MS or the cluster head will send a feedback request tone (FRT) with a predefined duration (i.e., 45 microseconds) to all receivers involved. Second, at the receiving side, while the MS or cluster head sends its message, the receiving node generates a parity check packet from its own FEC to try to recover any errors that occurred in the transmission. If the parity check is not enough, then after receiving the feedback request tone (FRT), the receiving node will send a packet request tone (PRT) with a predefined duration (i.e., 50 microseconds) followed by the packet header of the lost packet. Third, when the MS or cluster head receives a PRT or a number of PRTs, its own ARQ will retransmit the needed number of packets. Fourth, this process of trying to recover errors by FEC and feedback and packet request and retransmission is repeated until the original block is recovered.
After that, the MS or cluster head continues sending other blocks with the same technique. The feedback request transmission is defined before the transmission based on the network congestion status; if the network status is excellent, it can be postponed to the end of the message to reduce the time needed for error recovery, while if the status of the network is not good, it is better to send a feedback request after a number of blocks have been transmitted [3]. This may cause extra time overhead compared to the original transmission of multicast without any method of providing reliability, but our proposal ensures a better level of reliability with an appropriate control overhead.
4.2. RMBTM Description
To describe RMBTM we need a minor modification to three standard aspects, the packet header format, space frame, and handshake. Because our system is supporting block transmission and to allow our system to distinguish correctly where an error happened, we need to modify the standard packet header format of IEEE 802.11 as shown in Figure 6. We will add eight bytes of information (four-byte block number; four-byte packet index) in optional field of the standard packet header format; these modifications provide a way to identify precisely the error that happened in the packet in order to take an action. The packet size will not change, so as to prevent malfunction of our model and to avoid conflict with other systems. So our modification will not affect the packet header format since we use the optional field details.
In our RMBTM model, we will use the same standard spacing frame that we will use in the routing discovery method which is SIFS to utilize using tones and avoid the collisions of these tones [3].
To provide reliability, the standard format of the three-way handshake is as follows: send, receive, and acknowledge (ACK); however, we will modify this format to be convenient to our tone-based system. We use a four-way handshake to ensure that all members of the multicast group are ready; this consists of the send synchronization packet (SSP), acceptance tone (AT) with a predetermined duration (i.e., 35 microseconds), and data feedback request tone (FRT), and finally we replace the ACK with FRT, which may result in a better performance because it is just a tone with no harm if it collides.
The acceptance tone (AT) could be considered as a replacement for the Clear to Send (CTS) packet, but it is just a busy tone, so it will not cause traffic overhead. It is sent in two situations; first, when the node wants to be a part of the multicast group and second, when the master want to send data to all multicast members. Moreover, FRT could be sent more than one time depending on the receiver’s status; if the receiver asks for packets by sending a packet request tone (PRT), the FRT will be transmitted until all receivers get the original message correctly.
Transmitting a block which consists of a number of packets involves transmitting a number of different spacing frames and different packets. First, the node will wait for one standard frame space (i.e., the short interframe space, SIFS); after that, it uses the standard backoff algorithm used in DFC; then again it will wait for the SIFS. Next, it will send the synchronization packet (SSP) to all involved receivers, after which it will wait for one SIFS. After that, the sender will expect from all involved receivers an acceptance tone (AT) to inform the master sender that all multicast members are ready to receive and have enough power.
After the master sender receives the ATs, it will wait for one SIFS before sending the packets of the original block. Once it finishes, it will wait again for one SIFS; then it will send a feedback request tone (FRT) as depicted in Figure 7(a).
(a) Successful handshake
(b) Failed or collide in handshake
If the master sender does not receive the ATs, it will not send the packets but will instead try to send the synchronization packet again as shown in Figure 7(b). This may happen if the acceptance tones coming from multiple receivers collide, but it does not matter since it is just a tone and will not affect the network links.
From the ATs the master sender knows the involved nodes in the multicast transmission which is ready to receive from the MS.
After the master sender sends the original data it will wait for one space frame (SIFS); then it will send a feedback request tone to all involved receivers in the multicast transmission. If there is an error during the transmission that the FEC is not able to recover, the receiver will send back to the master sender a packet request tone (PRT) determined by the number of errors that occurred or send an AT telling the MS that the original message is received correctly.
This spacing frame procedure makes our multicast transmission operate like unicast because the master sender or relay node will wait and listen to ensure that the channel is free before sending the synchronization packet to all receivers. If the channel is not free, then the backoff algorithm counter is zero, and the MS or cluster head will wait for a time defined by the backoff algorithm before trying again. The counter of the backoff algorithm is decreased by the MS when the channel is idling. This process is repeated until the master sender sends the SSP packet.
Block transmission by the master sender involves dividing the stream of data into a number of blocks of equal size; each block is composed of one standard space frame, backoff, send synchronization packet, acceptance tone, and data, which consists of a number of packets as shown in Figure 8.
The decision of the time to send the feedback request tone (FRT) is made based on network status; if the network connection is considered excellent, then the master sender will send FRT only after a number of blocks have been transmitted, to avoid delay and waste of network resources. Otherwise, it will consider making FRT more frequently during the transmission.
After the master sender sends its data, it will wait for one space frame (SIFS), and then it will send two-time slot feedback request tone (FRT) without any interframe spacing. After that, if the receiver decides that it could not recover all data by using FEC and want additional data from the master sender in order to recover the message, the receiver will wait for one space frame (SIFS) and then send a packet request tone (PRT) to the master sender based on the number of packets it wants followed by the packet header of these lost packets. For example, if a receiver has three errors and this receiver could not recover these errors via its FEC, it will send a three-time slot PRT without any interframe spacing to the master sender followed by the packet header of these three lost packets to make the MS or cluster head send precisely these lost packets via its ARQ.
The master sender will make its own ARQ and will retransmit the needed additional data to this receiver, and then the master sender will send the two (FRT) again to this receiver to check whether this receiver has received the original message correctly. If not, again the receiver will send a number of PRTs to the master sender depending on the received data that could not be recovered also followed by the packet headers. This process is repeated until the receiver retrieves the original data. If the receiver node receives the data correctly, after the master sender sends two FRT, the receiver will send AT and wait for the next block to be transmitted. Upon transmission of the next block, the above process will repeat again.
Figure 8 gives an example of the procedures described above. The MS transmits data packets. Receivers 1 receive two erroneous data packets (packet 1 and packet 2), receiver 2 receives one erroneous data packet (packet 2), and receiver 3 does not receive any error, all identified through our modification to packet header format. R3 will send an AT and will not do anything in whole correction procedure because it does not have any error.
To correct errors happening in the transmission, after receiving an FRT from the MS, R1 and R2 will transmit PRTs back to the MS followed by the packet header format of these erroneous packets, R1 will transmit PRT with two-time slot of duration, and R2 will transmit RPTs with one slot of duration due to the number of errors occurring in the transmission followed by packet header. From the PRTs and the packet headers, the MS knows the largest number of needed packets that could not be retrieved from the first attempt.
The master sender will retransmit these packets again to all nodes of interest and send again FRT. The involved receiver will receive the retransmitted packet again on the second attempt and do error correction by its own FEC. So after receiving the second FRT the R2 will send AT because it could retrieve the original data and R1 still suffer and still need one additional packet, so it will send one PRT to the MS with the packet header of this erroneous packet.
After receiving the second RPT, the MS will send this packet again to this receiver and it will perform error check. At this point all receivers recover all missing data and R3 will send an AT to tell the MS of the current status of these lost packets, so after the third FRT they do nothing and the MS will continue sending other blocks with the same procedures.
In our model, we use five different tones RRQT, RRPT, FRT, PRT, and AT. The duration of these tones should be different to avoid malfunction on the network. We assume that, for example, RRQT is 20 microseconds, RRPT 25 microseconds, FRT 45 microseconds, PRT 50 microseconds, and AT 35 microseconds to enable the system to distinguish between them. Also we assume the sender should send two FRT because it is essential part in our model and to enable the receiver in worst cases to receive at least one of these tones.
5. Simulation and Results
In this section, we will describe the procedure for the simulation of our proposal, for which we will use the OPNET simulator. Our proposal is simulated in various scenarios to evaluate its performance and efficiency. The simulation procedure of our proposal will follow these parameters:(1)Consider a MANET = .(2)The distance is measured by the GPS device for each node and the threshold value is defined.(3)Create the partitions cluster 1, cluster 2, and cluster 3 and the involved nodes for cluster 1 = , cluster 2 = , and cluster 3 = , where and are the distance thresholds (as shown in Figure 2).(4)All nodes in the network announce their remaining energy (as shown in Figure 3).(5)The master sender defines the wanted nodes by using our handshake mechanism, that is, by sending a synchronization packet (SSP) and expecting from all nodes an acceptance tone (AT), excluding all nodes which are in sleep mode until they charge their batteries (as shown in Figure 7).(6)Use our proposed scheme for route request and route reply (as described in Figure 1).(7)Use our multicast modification (as shown in Figure 4).(8)The master sender multicasts the message to cluster 1 and uses our RMBTM to provide more reliability.(9)The closest node to cluster 2 will unicast the message to the node which has the maximum remaining energy in cluster 2 (cluster head), which will act as relay node 1.(10)The cluster head in cluster 2 will remulticast the message to the nodes of interest in cluster 2 and will also use our RMBTM to provide more reliability.(11)The closest node to cluster 3 will unicast the message to the node which has the maximum remaining energy in cluster 3 (cluster head), which will act as relay node 2.(12)The cluster head in cluster 3 will remulticast the message to the nodes of interest in cluster 3 and will also use our RMBTM to provide more reliability.(13)For more reliability, the master sender will ask the farthest node in our MANET to resend the message to it to ensure that the message has been received correctly through the whole network.
We will base our performance analysis on comparison with other protocols; this means that in our simulation we will build the same MANET network under the same conditions with different routing protocols. We compare our proposal with other well-known protocols supported by OPNET, such as AODV, DSR, and OLSR. This will allow us to show our enhancements in terms of delay, reliability, energy consumption, and throughput.
We conduct our simulation for all routing protocol in wireless environment using the network size of 10 × 10 km with 30 highly dynamic mobile nodes in a random deployment running for one hour. For our model, we build three trajectories to construct three clusters that depend on distance and remaining energy.
In routing discovery time, we compare our proposed model with the reactive routing protocol AODV as shown in Figure 9. Our proposal shows more stable growth with acceptable delay, whereas the AODV route discovery time shows unpredicted growth. In the beginning of the simulation our model shows more delay caused by the initializing of RRQT and RRPT in routing discovery mechanism, but as time progresses our system produces better results since only successful interchanged tones will generate routing discovery packets, while in AODV protocol, the routing discovery packets could collide at the source causing more delay to retransmit these packets again.
In Figure 10, we show comparison results of our model against AODV, DSR, and OLSR in terms of delay factor happening in the entire network. Our model is the best performer in this comparison due to our proposed requirement of initializing tones and adjusting the multicast flow; however, as time continues our model shows steady improvement with an overall acceptable delay.
The reliability factor results are shown in Figure 11; REEDDRE shows a great enhancement in received packets over dropped packets due to using our proposed handshake mechanism as described in Section 4.2. the corrugated shape of our model is caused by FRT and PRTs used to ensure the reliability in our model.
Figure 11 shows a comparison of retransmission attempts of all routing protocol used in the simulation; our model is the best performer in this comparison since it produces the lowest number of retransmission attempts, which means that REEDDRE is more reliable than others with less delay caused by these attempts.
As shown in Figures 11 and 12, the results support our proposed techniques to offer reliable scheme for multicast transmission in MANET. This is because we utilize the network resource with the assistance of short pluses of tones replacing the traditional routing protocols control packets.
Figure 13 shows the energy consumption results. Our model shows great enhancement in terms of preservation of the network energy. This enhancement is done with idea of our proposal to divide the network into three clusters based on distance and remaining energy and also with idea of role-based assignment such as gateway nodes.
We compare the network throughput among REEDDRE, AODV, DSR, and OLSR as shown in Figure 14. At the beginning, OLSR shows better throughput because of the MRP technique used in OLSR, but as the time advances, our REEDDRE demonstrates the highest throughput because of its reliability mechanism and clustering approach while OLSR will produce more overhead because of update MRP neighboring list.
Finally, the overall comparison showed that our REEDDRE offers better results in every parameter, but it is important to note that REEDDRE does not demonstrate the best results at the beginning of the simulation. This is because of the model’s initial requirements for initializing the tone system and modification, but as time progresses our system produces the best results.
6. Conclusion
In this paper, we propose the tone-based REEDDRE model as a means of overcoming the disadvantages of the huge consumption of energy relating to distance and to provide congestion control and reliability in multicast transmissions over mobile ad hoc networks (MANETs). Our model consists of a tree-based design where all nodes are divided into three partitions. Our proposal mandates that only the node with the maximum remaining energy will multicast because of the consumption of energy resulting from such a multicast. In addition, we propose for our REEDDRE model a reliable multicast transmission over the MAC layer. The proposed model uses RMBPM in combination with ARQ and FEC, using a tone-based system to provide data reliability and efficiency. We provide a short summary of the routing protocol in MANETs, the requirements for a reliable multicast over different topologies, and different approaches to provide congestion control. Our simulation results showed that the REEDDRE model produces better results in terms of delay, reliability, energy consumption, and throughput compared with well-known protocols such as AODV, OLSR, and DSR. These results support our proposed ideas regarding the use of tones and a clustering approach. These proposed techniques can all be implemented in one MANET without conflicting with others and will provide a level of service quality which is essential for services which depend on such networks.
Competing Interests
The authors declare that they have no competing interests regarding the publication of this paper.
Acknowledgments
The authors would like to extend their sincere appreciation to the Deanship of Scientific Research at King Saud University for funding this research group (no. RGP-1437-35).