Abstract
With the development of wireless technology, two basic wireless network models that are commonly used, known as infrastructure and wireless ad hoc networks (WANETs), have been developed. In the literature, it has been observed that channel contention is one of the main reasons for packet drop in WANETs. To handle this problem, this paper presents a routing protocol named CCBR (Channel Contention Based Routing). CCBR tries to determine a least contended path between the endpoints to increase packet delivery ratio and to reduce packet delay and normalized routing overhead. Moreover, throughout the active data section, each intermediate node computes its channel contention value. If an intermediate node detects an increase in channel contention, it notifies the source node. Then the source node determines another least contended route for transmission. The advantages of CCBR are verified in our NS2-based performance study, and the results show that CCBR outperforms ad hoc on-demand distance vector (AODV) in terms of packet delivery ratio, end-to-end delay, and routing overhead by 4% to 9%.
1. Introduction
Wireless networks based on the IEEE 802.11 standard are one of the best ways to provide network availability to users ubiquitously. With the development of wireless technology, two basic wireless network models called infrastructure and wireless ad hoc networks (WANETs) have been developed. In an infrastructure network, all wireless nodes are communicating to a wired network through a wired access point; on the other hand, a WANET is a temporary infrastructure less network that consists of wireless nodes, where communication takes place among the nodes through wireless links. There is no restriction on a node to join or leave the network; as a result, WANET has a very dynamic topology. Each node in WANET has two roles: to work as a host and as a router; therefore, each node allows establishing a multihop path in the network [1, 2].
There are a number of scenarios where an infrastructure network is not an appropriate one. For example, if the goal is only Internet access or an application communicating in local area network with a number of movable nodes, it may not be possible for an access point to communicate with all movable wireless nodes due to limitations such as transmission range. Communication is possible in these scenarios if routing is performed in the wireless domain. Thus, a WANET is an appropriate one for such scenarios. It is a good choice for those scenarios, where quick reinstatement of communication is essential, such as rescue operation performed during flooding and earthquakes, and more suitable for a battlefield environment [3].
To get full benefits of the WANETs, one of the technological problems that should be resolved is the design of an efficient routing protocol, where multihop routing is challenged by dynamic network topology, congestion, channel contention, and limited wireless bandwidth, to name just a few [1]. Then, there are a number of routing protocols that were designed to address these problems:(i)The adaptive backup routing (AODV-ABR) [4] protocol handles the problem of route failure, where the routing protocol presented in [5] is designed to know the location of other nodes and selects the potential relay node.(ii)The objective of the protocols presented in [6, 7] is to utilize the bandwidth efficiently, while the protocol presented in [8] is designed to reduce the power consumption.(iii)Some protocols worked on other challenges such as Quality of Service (QoS), where Trustworthiness-based Quality of Service (TQoS) routing [9] is an example of such routing protocol and to establish secure routing is considered in [10].
There are a number of protocols, such as those in [11–15], which were designed to handle the problem of congestion. Congestion is the situation when the load on the network is greater than its capacity, resulting in queuing delay and packet loss due to the buffer overflow. On the other hand, nodes are facing channel contention due to share medium in WANETs. If a packet drop occurs due to channel contention, then the MAC (Medium Access Control) layer sends a wrong notification to the network layer that the path is unavailable; as a result, the network layers start route recovery procedure without any need [16]. However, if the buffer size at the MAC layer is of appropriate size, then packets drop rate due to congestion will be very low and drops ratio due to channel contention will dominate [17].
To handle the problem of channel contention, we present an adaptive routing protocol named CCBR (Channel Contention Based Routing) protocol in this paper. CCBR tries to determine a least contended path between the endpoints to reduce packet delay and normalized routing overhead and increases packet delivery ratio. Moreover, throughout the active data section, each intermediate node computes its channel contention. In case of an increase in channel contention detected by an intermediate node, it notifies the source node. Then the source node determines another least contended route for transmission. The advantages of CCBR are verified in our NS2-based performance study.
The rest of the paper is organized as follows. The second section presents the related work. Section 3 introduces the medium access mechanism of IEEE 802.11 standard. The proposed mechanism is presented in Section 4 and simulation results are presented in Section 5. Finally, the paper is concluded in Section 6.
2. Related Work
Dynamic Load-Aware Routing (DLAR) [18] is designed to handle the congestion in WANET and the number of packets buffered by the intermediate nodes is used as the main metric to select the least congested path. In DLAR, the destination node monitors the congestion level of the route throughout the active data session; if congestion is detected, then the destination node activates the new route selection process.
Tran and Raghavendra proposed Congestion Adaptive Routing (CRP) [11], where the ratio is computed periodically between the buffer size and the number of packets in the buffer to identify congestion level. If a node is near to be congested, it notifies its previous node. On receipt of this notification, the previous node tries to find out the bypass route and avoids the congested node. Moreover, a congested node must drop the RREQ packet to be excluded from path selection.
In [19], the DCDR (Dynamic Congestion Detection and Control Routing) protocol was introduced to detect congestion level using the average queue length at each node. If and , then the node is in the safe zone. If , then the node is expected to be congested and substitute route selection process is activated. In the meantime, if due to incoming traffic, then the status of substitute route selection becomes false. So the MaxThreshold will be adjusted so that the substitute route selection process becomes true. When a node enters congestion status, it sends a warning notification to its neighbours. As a result, the neighbour nodes attempt to find out an alternative congestion-free path towards the destination.
Congestion-Aware Routing Protocol (CARP) [20] measures the congestion level through a combined weight metric, based on the data rate, queuing delay, link quality, and MAC overhead. If more than one RREQ packet arrives at the destination, then the route with minimum combined weight value will be selected for transmission, that is, the sum of the combined weights of all nodes on the path.
In [21], Chen et al. proposed Congestion-Aware Routing Protocol for mobile ad hoc networks (CARM) and the Weighted Channel Delay (WCD) is the metric for congestion detection. The parameters used to compute WCD are buffer delay, data rate, and MAC overhead. In addition, the Effective Link Data Rate Category (ELDC) scheme is used to handle the Mismatched Data Rate Problem (MDRP) in multirate WANETs. The data rate of the link directly attached to the source is taken as ELDC and incorporated in the RREQ packet. The nodes in the network forward a route RREQ on those links which have ELDC value greater than or equal to the one included in the RREQ packet.
Raval et al. proposed the Ant-CAMP (Ant-Based Congestion Adaptive Multipath Routing Protocol) [22], which uses the average queue size as a metric to discover a congestion-free shortest path between the end nodes. When the average queue size at any node reaches a predefined threshold, it notifies the sender that the path is congested. On receipt of the congestion notification, the sender starts transmission on the next optimal path, if available; otherwise, a new route selection process is initiated.
The above-mentioned protocols use a single path for data transmission, but there are some protocols that use multipath. One of such protocols is MNDP (Multiple Node-Disjoint Paths Protocol) [23], designed to handle congestion in the network. After detecting multipath, the source sorts these paths based on the number of the hop count. If there are two routes, the shortest one has a priority of two and the next one has a priority of one. Thus, 66.67% and 33.33% of packets will be transmitted on routes, having priority of two and one, respectively.
The Fibonacci Multipath Load Balancing (FMLB) [24] is another multipath protocol proposed by Tashtoush et al. In FMLB, if a source detects K routes, then arrange them in the increasing order based on the number of hop count. Then the FMLB protocol will assign the following weights for these routes:
The number of packets to be forwarded on each route depends on their weight. Similarly, Congestion-Aware FMLB [25] protocol is also a multiple path routing protocol like FMLB. The difference between these two protocols is that FMLB uses hope count, while Congestion-Aware FMLB uses round-trip time to assign weights to each route.
Multipath Load Balancing Technique for Congestion Control (MLBCC) [26] is designed to balance the load in order to control congestion in MANET. In MLBCC, the packet arrival and outgoing rate in a specific interval of time are used to detect the congestion level. Moreover, to select the gateway node, the link cost and the path cost are used. When traffic on the selected path is over the selected threshold value, the traffic is transmitted via the gateway node.
In [14], Ali et al. proposed a mechanism to enhance DSR and make it more power- and load-aware; it discovers multiple paths from source to destination and then selects the optimal one. The power- and load-aware combined metrics are used for route selection. A node cannot participate in the route selection process if its energy is below a specific threshold. The path will be less loaded or less congested if it has a minimum cost value. The protocols presented in [27–30] are also worked on congestion control.
3. Medium Access Mechanism in 802.11 Based Network
The fundamental medium access method in IEEE 802.11 MAC [31] protocol is DCF (distributed coordination function) that allows through the use of carrier sense multiple access with collision avoidance (CSMA/CA) to share medium between the compatible physical layers.
If a node is ready to transmit data (using the CSMA/CA mechanism), it senses the medium first and defers its transmission if it was found that the medium is busy; otherwise, if the medium is free for a short time interval named DIFS (Distributed Interframe Space), then the node can transmit data. The receiver should provide an acknowledgement (ACK) to confirm the packet reception without any collision. If the sender receives no ACK, then the packet is retransmitted until it gets an acknowledgement. After a free defined number of unsuccessful retransmission tries, drop the packet. Meanwhile in case of successful transmission, the node should follow a backoff time before another transmission.
The DCF uses the RTS (request to send)/CTS (clear to send) control packets to reserve the medium for data sending and avoid collision among packets. This mechanism works as follows.
Before data transmission, a node should transmit an RTS packet that includes the source and destination IDs and the time required for the packet transmission and its respective ACK. The destination will respond with CTS packet, which will also include the same time required for data transmission. On the receipt of CTS, the source node transmits data after a SIFS (Short Interframe Space) and waits for the ACK. All other nodes update their NAV (Network Allocation Vector) on receipt of RTS/CTS. The NAV tells the node that the medium is busy for the specified time. This process is depicted in Figure 1.
The absence of CTS packet as a response of RTS packet means the medium as busy or collision occurred; on the other hand, if ACK is not received as a response of data packet, it represents fail transmission. In both cases, retransmission is initiated after a backoff time and transmission retry counter will be incremented.
4. Proposed Channel Contention-Based Routing Protocol
We describe our proposed mechanism in this section. For clarity purpose, the discussion is divided into subsections.
4.1. Estimation of Channel Contention
In IEEE 802.11 based wireless networks, each node makes a specific number of attempts for data transmission and discards the packet in case of failure. If the number of attempts for a packet transmission increases, it means a node potentially identified an increase in the channel contention and vice versa. It actually identifies how busy the medium is in the neighbour of a node. However, this measurement or number of attempts for a packet transmission can radically change over the time and especially in mobile ad hoc networks. Therefore, to get a normalized value for the number of attempts, each node computes a weighted moving average of the number of attempts made for packet transmission according to the following equation:where is the current weighted moving average which reflects the channel contention of a wireless link or how busy the medium is in the neighbour of a node. represents the previous weighted moving average and represents the most recent number of attempts of the node for packet transmission and α is a constant. During simulation, value used for α is 0.55, but one can select an appropriate value in the range of .
4.2. Route Selection Process
When a route towards the destination is required, a Route Request (RREQ) is initiated for route discovery. On receipt of the RREQ, the intermediate nodes make a routing entry for the source and next hop towards the source. The next hop information is required later on to forward the RREP towards the source. If there is no RREP on this path, the entry will be discarded from the routing table after a timeout. The intermediate nodes will drop the duplicate RREQ packet.
In the route selection process, each intermediate node compares its estimated channel contention with the channel contention value received in RREQ packet. Suppose that the value of channel contention received in RREQ packet is ; then the three following cases can happen:(i)Case 1: just forward the RREQ packet.(ii)Case 2: replace the value of CC (channel contention) field in RREQ packet with the value of channel contention estimated by the current node which is and set the value of NC (node count) field in RREQ packet to one; after that, forward the RREQ packet.(iii)Case 3: it means that more than one node has a larger value for channel contention. In such a case, the proposed algorithm counts the number of nodes with a larger value of channel contention. So, increment the value of the NC field by one and forward the packet. This count is used to resolve a tie if more than one RREQ packet arrives with same channel contention value.
Finally, RREQ arrives at the destination node with the larger value of channel contention obtained along the route. Moreover, to learn about all possible routes, acceptance of multiple RREQ packets is allowed at the destination node. Then the destination node selects the least contended route and returns a RREP to the source through this route, which is to be used for data transmission.
To explain the route selection process with an example considers a scenario of wireless ad hoc network shown in Figure 2.(1)Before sending data to node D, node S initiates a route selection process by flooding the RREQ packet into the network as shown with Label-A in Figure 2. Suppose that nodes A and B receive the RREQ.(2)After updating the value of CC and NC field, nodes A and B broadcast the RREQ packet to their neighbour (as shown with Label-B in Figure 2).(3)Let the RREQ packets be broadcasted by A and B, received at nodes X and Y, respectively.(4)Nodes X and Y compare their estimated channel contention values with the value received by each one in the RREQ packet. After updating the NC and CC field in RREQ packet, it is broadcasted by each one to its neighbour (as shown with Label-C in Figure 2).(5)Repeat step 4 at each intermediate node until the RREQ packet arrives at destination D.(6)Finally, two RREQ packets with channel contention values of 2 and 3 arrive at node D.(7)Node D will send RREP through route (S—B—Y—D) which is the least contended route in this example, that is, the route with channel contention value of two.
Consider another scenario given in Figure 3. In this scenario, destination D receives two route request packets through the paths (S—A—C—X—D) and (S—B—E—Y—D), each with channel contention of 3 and node count of 1 and 2, respectively. Here the highest channel contention value for both routes is the same, that is, three, but the number of node count with the highest channel contention value (the value of NC field) is one for the route (S—A—C—X—D), so this route will be selected for transmission. If still there is a tie, then consider the route request that is received first.
4.2.1. Modification of RREQ Packet
The RREQ packet of the proposed routing protocol includes all the fields present in the RREQ packet of AODV with the addition of two other fields named CC (channel contention) and NC (node count). The CC field carries the value of the highest channel contention estimated along the route, while the NC field carries the total number of nodes with the highest channel contention value on the path.
4.2.2. Modifications in Routing Table (RT) and Adaptive Mechanism
In the routing table, the proposed algorithm incorporates all the fields included in the routing table of AODV with the addition of rt_CC (route channel contention) field. The rt_CC field holds a value of the highest channel contention estimated along the route. When the destination node returns a RREP packet, it also includes a value of the highest channel contention estimated along the selected path. For example, in the network scenario depicted in Figure 3, the route (S—A—C—X—D) is selected for transmission. The highest value of channel contention received by the destination node in the RREQ packet along this path is three and it is returned in the RREP packet. Each intermediate node receiving this RREP packet updates the value of the rt_CC field in the routing table for the selected path in the backward and forward directions.
Each intermediate node periodically compares its current value of channel contention with the value of the rt_CC field, if it is greater than the value of rt_CC by ; that is,
It means that the value of the rt_CC field is too far from the channel contention and is not reflecting the actual status of the contention. If, at any intermediate node, equation (3) becomes true, then inform the source that the path has contended. As a result of the source adopting a least contended path for transmission, it starts the discovery of a new least contended path.
In AODV routing protocols, an intermediate node can send RREP packet if it has path information towards the destination. However, in the proposed algorithm, only the destination node is allowed to generate RREP in order to select the path on the basis of most up-to-date channel contention information.
4.2.3. Modification of Route RREP and RERR Packets
The destination node is allowed to accept more than one RREQ packet in order to select the least contended path for transmission. The highest channel contention value along the selected path is returned in the RREP packet, where a field RC (route contention) is added to the RREP packet for this purpose. During the active data session, if a node observes an increase in the channel contention (as described in the previous section), it is communicated in the RERR packet by raising a flag. There are some reserved bits in the RERR packet, where the first reserve bit is used as a flag for communicating increase in channel contention (Pseudocode 1).
|
5. Performance Evaluation
We implemented the proposed algorithm in Network Simulator NS 2.34 and compared its performance to that of AODV. The simulation modelling and results are presented in Sections 5.1 and 5.2, respectively.
However, initially a mobile scenario of 100 nodes was considered to select a best value for α. These 100 nodes randomly distributed over 1000 m × 1000 m area. The network traffic generated at 4, 8, 12, 16, 20, and 24 packets per second. The other parameters for this scenario are summarized in Table 1. The best value chosen for α is 0.55 and it is selected on the basis of packet delivery ratio. The packet delivery ratio achieved with each value of α is depicted in Figure 4.
5.1. Simulation Modelling
According to the number of nodes, we considered two scenarios with 200 and 400 nodes, and these nodes randomly distributed over a 2000 m × 2000 m area and a 3000 m × 3000 m area, respectively. The simulation scenarios generated with setdest utility available with NS2. The simulation was carried out in static as well as in mobile scenarios. In a mobile scenario, each node selects a random destination, when a node reaches the destination; then it waits for the pause interval and, after that, it chooses a new destination. The simulation time for each scenario was 300 seconds. The results presented in each scenario represent the average of 10 runs. The channel capacity was set to 2 Mbps and the transmission range of each node was 250 m. The MAC layer was based on 802.11 distributed coordination function.
The sources were generating a constant bit rate (CBR) traffic, where the packet size was 512 bytes. The network traffic generated at 4, 8, 12, 16, 20, 24, 28, 32, 36, and 40 packets per second. The queue size at the MAC layer has a length of 50 packets. The simulation modelling parameters are summarized in Table 2.
The protocols were evaluated with the following performance metrics:(i)Packet delivery ratio: the ratio of the number of data packets successfully received at the destinations to the number of data packets generated by the sources.(ii)Normalized routing control overhead: the ratio of the number of control packets (RREQ and RREP are examples of control packets) to the number of packets delivered to destinations.(iii)Average end-to-end delay: the average time taken by a packet to reach destination from source.
5.2. Simulation Results
Two hundred nodes were placed in the 2000 m × 2000 m area. In one case, all the nodes are moving continuously. In such a scenario, the packets drop occurs not only due to channel contention but also due to the mobility of the nodes. In the second case, all 200 nodes are static to avoid mobility losses or losses due to route failure in order to see the performance of CCBR and AODV in the presence of losses due to channel contention. Since CCBR tries to find out the least contended path dynamically and switch the transmission to the least contended path, the simulation results show that our hypothesis is true. Figures 5 and 6 illustrate the packet delivery ratio of CCBR and AODV in mobile and static scenarios, respectively, with increasing packets rate. It can be seen that CCBR outperforms AODV in both scenarios. In a static scenario, CCBR achieved 6% to 9% increase in packet delivery ratio, while in the mobile scenario it outperforms AODV by 4 to 8%.
The results for end-to-end delay are illustrated in Figures 7 and 8 for mobile and static scenarios, respectively. It is clear from Figure 8 that when the load on the network was low, the end-to-end delays of CCBR and AODV are almost the same. But, with an increase of network load, the CCBR outperforms AODV in terms of end-to-end delay. In a mobile scenario, when the load on the network was low, the difference in the end-to-end delay is small, recorded in the presence of CCBR and AODV. However, with the increase of network load, there is a tendency towards the decrease in end-to-end delay in the presence of CCBR. But, in the presence of AODV, there is a tendency towards the increase in the end-to-end delay.
In mobile and static environments, the routing overhead of CCBR is low compared to that of AODV. The results for the routing overhead are illustrated in Figures 9 and 10. It is also observed that when network traffic is generated at a high rate, the routing overhead decreases. The reason is that there is high channel contention on the transmission path, which causes packets to drop and a small number of nodes participating to find out the path to the destination and, therefore, not generating too many control packets.
Moreover, to see how the proposed mechanism works in dense scenario, the simulation was also carried out with 400 nodes, where the nodes were randomly placed in a 3000 m × 3000 m area; the results achieved in this scenario for packet delivery ratio, average end-to-end delay, and normalized routing overhead are illustrated in Figures 11–13, which show that CCBR outperformed AODV in dense scenario.
6. Conclusion
To handle the problem of channel contention, we proposed an adaptive routing protocol named CCBR in this paper. CCBR tries to determine a least contended path between the source and destination to increase packet delivery ratio and reduce packet delay and normalized routing overhead. Moreover, in the case of an increase in channel contention detected by an intermediate node, it notifies the source node. Then the source node determines another least contended route for transmission.
Using NS2 simulator, static and mobile scenarios were considered to compare the performance of CCBR against the AODV based on packet delivery ratio, average end-to-end delay, and routing overhead. In case of packet delivery ratio, CCBR outperformed AODV in both static and mobile scenarios, where the number of nodes was 200, and achieved 6% to 9% and 4 to 8% increase in packet delivery ratio, respectively. There is a small difference between the end-to-end delays of CCBR and AODV when the load on the network is low. But, with the increase of network load, the CCBR outperforms AODV in terms of end-to-end delay. Similarly, CCBR has lower overhead compared to AODV. Moreover, a dense scenario of 400 nodes was also considered and the results revealed that the performance of the network in the presence of CCBR is better compared to that in the presence of AODV.
Data Availability
Data are available upon request.
Conflicts of Interest
The authors declare that there are no conflicts of interest regarding the publication of this paper.
Acknowledgments
This project was funded by the Deanship of Scientific Research (DSR), King Abdulaziz University, Jeddah, under Grant no. DF-460-156-1441. The authors, therefore, gratefully acknowledge DSR technical and financial support.