Table of Contents Author Guidelines Submit a Manuscript
Mobile Information Systems
Volume 2015, Article ID 523294, 10 pages
http://dx.doi.org/10.1155/2015/523294
Research Article

Proposal and Performance Evaluation of a Multicast Routing Protocol for Wireless Mesh Networks Based on Network Load

1Department of Informatics, Graduate School of Science and Engineering, Yamagata University, 4-3-16 Jonan, Yonezawa, Yamagata 992-8510, Japan
2Department of Information and Communication Engineering, Fukuoka Institute of Technology, 3-30-1 Wajiro-Higashi, Higashi-Ku, Fukuoka 811-0295, Japan

Received 1 June 2013; Accepted 22 October 2013

Academic Editor: David Taniar

Copyright © 2015 Kiyotaka Oe et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

Abstract

Wireless Mesh Networks (WMNs) can provide wide range Wireless Local Area Networks (WLANs) area by connecting Access Points (APs) of WLANs with each other using radio communications. A routing protocol is very important to keep communication quality over radio multihop communications because radio waves are impacted much by surrounding environment. When we use multiuser shared applications like a video conference and an IP phone, it is predicted that large amount of traffic flows on network. Therefore, we should consider network loads to use these applications. In this paper, we propose a multicast routing protocol for WMNs which considers network loads and hop count. Furthermore, we evaluate performance by simulation. In the simulation results, we show that the proposed protocol has better performance than a conventional protocol (MAODV) at high loaded scenario.

1. Introduction

In recent years, the opportunity for using Wireless Local Area Networks (WLANs) is increasing rapidly due to popularization of Internet and mobile terminals (nodes). An Access Point (AP) cannot provide wide WLANs area because its radio wave range is about several ten meters to several hundred meters. Wireless Mesh Networks (WMNs) can solve this problem [17]. In WMNs, APs are connected with each other using radio communication and we can access the Internet through gateways (GWs) which can be accessed by AP multihop. WMNs have mainly two merits to be constructed: one is that cables are not needed and the other is that there are few location restrictions to install APs. So, WMNs can provide wide range WLAN area flexibly with low cost. Hence, we can access networks easily without restrictions of time and location. Due to this reason, WMNs are regarded as one of the techniques to realize ubiquitous society.

Recently, against a background of development of radio techniques, there is a growing need for using multiuser shared applications like a video conference and an IP phone with high quality over wireless networks. Generally, it is hard to keep communication quality over radio multihop communications because radio waves are impacted much by surrounding environment [8]. Thus, the routing protocol which determines data transmission route is very important to prevent deterioration of communication quality. It is predicted that large amount of data traffic flows into networks in point-to-multipoint and multipoint-to-multipoint communications. In highly loaded networks, it is possible that delays and congestions occur due to bandwidth compression. Therefore, the routing protocol which considers network loads is needed for communications of multiuser shared application. However, conventional routing protocols, for example, multicast ad hoc on-demand distance vector (MAODV) [9], usually determine data transmission route using hop count as routing metric. Consequently, these protocols cannot solve mentioned problems because they do not consider network loads.

In this paper, we propose a multicast routing protocol which considers network loads and hop count. Furthermore, we evaluate performance by simulation. In the evaluation results, we show that proposed protocol has better performance than MAODV.

The structure of this paper is as follows. In Section 2, we introduce a multicast technique. In Section 3, we explain MAODV protocol and other related protocols as related works. In Section 4, we present the proposed protocol. In Section 5, we discuss performance evaluation. Finally, some conclusions are given in Section 6.

2. Multicast over WMNs

In WMNs, mobile nodes communicate with other nodes through APs. Several mobile nodes (up to about 30) are connected with each AP. So, these nodes are significantly affected when network loads concentrate on their APs. In particular, more APs suffer high load if many nodes join a communication.

One of the techniques which solve this problem is multicast communication. In multicast communication, nodes use multicast IP address and communicate with all group members. In unicast communication, a source node duplicates the number of data packets equivalent to the destination nodes. On the other hand, in multicast communication, intermediate nodes duplicate the number of data packets equivalent to its downstream nodes (Figure 1). Therefore, the multicast communication is better than unicast communication regarding efficient use of bandwidth when a node sends same data to plural nodes [10].

Figure 1: Effectiveness of multicast communication.

There are two ways to realize multipoint-to-multipoint communications in multicast communication. The one is that each source node constructs a transmission tree whose root is itself. The other is that group members (all nodes which belong to a multicast group) construct a shared transmission tree. In this work, we adopt latter case considering network load.

3. Related Works

In WMNs, multicast routing protocols which are proposed for mobile ad hoc networks (MANETs) are often used. They are, for example, MAODV [9], ODMRP [11], AMRoute [12], CAMP [13], and so on. ODMRP and CAMP create mesh topology for reliable communications in MANETs where topology frequently changes due to node’s mobility. Unlike MANETs, nodes in WMNs have no/little mobility; therefore, reliable communications are expected over tree topology. In addition, mesh topology tends to involve more intermediate nodes [14], which leads to performance degradation in loaded scenarios. From this aspect, MAODV and AMRoute are better suited for WMNs because they create tree topology. However, AMRoute requires any unicast protocol to work it. For all of these reasons, we decided that MAODV is best protocol for WMNs in all MANET routing protocols. In the rest of this section, we describe detailed MAODV behavior.

MAODV is a multicast routing protocol. This is expanded AODV [15] which is a unicast routing protocol to multicast. In MAODV, all nodes which are involved in routing have routing tables for unicast and multicast. The transmission topology is a shared tree and a group leader manages a transmission route. The transmission route is constructed by Route REQuest (RREQ), Route REPly (RREP), and Multicast ACTivation (MACT) packets. Rough steps to construct a shared tree are as follows. Also, explanations of terms are shown in Table 1.(1)A node which wants to join a multicast group broadcasts a RREQ packet to get route information to the group nodes and waits for RREP packets.(2)When tree member nodes receive the RREQ packets, they send a RREP packet which includes route information to the RREQ source node.(3)If the RREQ source node did not receive any RREP packets in a certain time, it resends a RREQ packet. If it has already resent a RREQ packet till a certain number of times, it guesses that there is no group member, and it becomes a group leader.(4)When the RREQ source node receives the RREP packets, it sends a MACT packet to the shortest route to the group leader. The nodes which receive the MACT packet activate the route which RREQ packet traveled.

Table 1: Explanation of terms.
3.1. An Example of MAODV Behavior

The more detailed algorithm is shown as follows. This consisted of three phases. They are RREQ phase, RREP phase, and MACT phase. The transmission of RREQ and RREP packets is shown in Figure 9. The transmission of MACT packets is shown in Figure 12.

3.1.1. RREQ Phase

(1)The node F which wants to join a certain multicast group broadcasts a RREQ packet which includes the group’s IP address. Part of RREQ packet format is shown in Figure 2.(2)Nodes which received a RREQ packet do the duplicate check by using RREQ source IP address and broadcast ID. If the received packet is duplicate packet, the node discards it.(3)Otherwise, the node records the route information into unicast and multicast tables. Main fields of unicast and multicast table are shown in Figures 3 and 4, respectively. The node E’s unicast and multicast tables after receiving a RREQ packet from node F are shown in Figures 5 and 6, respectively. Here the destination IP address (group IP address) is M.(4)If the received node is a multicast tree member (i.e., node B or C), move to RREP phase.(5)Otherwise, (i.e., node E), the node broadcasts the received RREQ packet.(6)Steps from (2) to (5) are repeated until a multicast tree member receives RREQ packet.

Figure 2: Part of RREQ packet format.
Figure 3: Main fields of unicast table.
Figure 4: Main fields of multicast table.
Figure 5: Unicast table entry of node E.
Figure 6: Multicast table entry of node E.
3.1.2. RREP Phase

(1)Tree member nodes which received the RREQ packet (i.e., nodes B, C) generate and send a RREP packet to the RREQ source node (node F). The RREP packet travels the reverse route, corresponding to the RREQ packet traveled. Part of the RREP packet format is shown in Figure 7.(2)The RREQ relay nodes which received the RREP packet (node E) update their multicast tables. Node E’s multicast table after receiving the RREP packet from node B is shown in Figure 8.(3)If a node receives more than one RREP packet for same RREQ packets, the node compares group sequence number of the RREP packets with group sequence number of its multicast table. If the information of the RREP packet is older than the information of the multicast table, the RREP packet is discarded.(4)If the information of the RREP packet is newest or it has shorter route to group leader, the node updates its multicast table. In Figure 9, we suppose that nodes B and C have same group sequence number. We also suppose that node E receives the RREP packet from node B earlier than the RREP packet from other nodes. The node E discards the RREP packet from node C because it does not have shorter route to group leader than one from node B.(5)The relay node (node E) of the RREP packet relays the RREP packet referring to own unicast table which was updated at the RREQ phase.(6)Steps from (2) to (5) are repeated until the RREQ source node (node F) receives the RREP packets. The RREQ source node moves to the MACT phase after RREP waiting time.

Figure 7: Part of RREP packet format.
Figure 8: Multicast table entry of node E.
Figure 9: Transmission of RREQ and RREP packets.
3.1.3. MACT Phase

(1)The RREQ source node (node F) sends a MACT packet along shortest route to group leader (i.e., ). At this time the node sets activated flag of next upstream node in its multicast table. Part of MACT packet format is shown in Figure 10. Additionally, the multicast table of the node F after unicasting a MACT packet is shown in Figure 11.(2)The nodes which receive the MACT packet (nodes E and B) set activated flag of next downstream node in their multicast tables.(3)If received node is not the tree member (node E), it sets activate flag of next upstream node in its multicast table and sends the MACT packet to the upstream node (node B).(4)Steps from (2) to (3) are repeated until the tree member node (node B) receives the MACT packet.

Figure 10: Part of MACT packet format.
Figure 11: Multicast table entry of node F.
Figure 12: Transmission of MACT packet.
3.1.4. Problem of MAODV

The problem of MAODV is that routing metric is only hop count. Generally, the route of the shorter hop count has the lower error rate and delay. However, a communication quality deteriorates if the route quality is low [16, 17]. For example, the route has high load and the link signal strength is weak and so on [1820]. In particular, in multipoint-to-multipoint communications, the communication failure such as the congestion happens with a high probability because these communications tend to put large load on networks. From this reason, we need to consider network load.

4. Proposed Protocol

4.1. Load Evaluation Value

In multipoint-to-multipoint communications, amount of packets which are sent to networks tend to be heavy. In this work, we select MAODV as a base protocol in consideration of this point because MAODV tends to have fewer relay nodes which are involved in communications.

In the proposed protocol, we introduce a Load Evaluation Value (LEV) [21, 22]. The LEV is calculated from (1) with queue length (ql) of relay nodes and hop count (hop):

In (1), we calculate square sum of queue length divided by 5 in order to assign large weight to nodes whose queue length is more than 5. This is because we found from our simulation experiences that the nodes whose queue length is more than 5 become overload with high probability with time advances. In addition, we introduce hop count to routing metric to prevent selecting of extremely long route [23].

In particular, when there are any routes that square sum of queue length equals zero, we add 1 to the square sum of queue length in order to consider hop count. We show the proposed algorithm to construct routes as follows. The transmission of RREQ and RREP packets is shown in Figure 20, and the transmission of MACT packets is shown in Figure 21.

4.2. Behavior of Proposed Protocol [21, 22]
4.2.1. RREQ Phase

(1)The node (node F) which wants to join a multicast group broadcasts a RREQ packet which includes the group’s IP address. Part of a RREQ packet format in proposed protocol is shown in Figure 13. At this time the square sum of queue length is initialized to zero.(2)The node (node E) which received RREQ packet performs sequence check. If route information of the RREQ packet is older than the information in the unicast table, it is discarded.(3)Otherwise, the node calculates LEV from RREQ source node to its own node by using (1).(4)If the LEV is bigger than the value in the unicast table, the node discards the RREQ packet. Main fields of unicast table in proposed protocol are shown in Figure 14.(5)Otherwise, the node updates its own unicast and multicast table. Main fields of multicast table in proposed protocol are shown in Figure 15. Additionally, unicast and multicast tables of node E after receiving RREQ packet from node F are shown in Figures 16 and 17, respectively. Here the group IP address is M.(6)If the received node is group leader (node L), move to RREP phase.(7)If not, the node adds to square sum of queue length in RREQ packet and rebroadcasts it.(8)Steps from (2) to (7) are repeated until group leader receives RREQ packet.

Figure 13: Part of RREQ packet format in proposed protocol.
Figure 14: Main fields of unicast table in proposed protocol.
Figure 15: Main fields of multicast table in proposed protocol.
Figure 16: Unicast table entry of node E in proposed protocol.
Figure 17: Multicast table entry of node E in proposed protocol.
4.2.2. RREP Phase

(1)Group leader (node L) generates and sends a RREP packet to the RREQ source node (node F). This RREP packet travels reverse route. The RREP packet has LEV from RREQ source node to group leader. Part of a RREP packet format is shown in Figure 18.(2)RREQ relay nodes which received a RREP packet update their multicast tables.(3)If nodes receive more than one RREP packet for same RREQ packets, the node compares group sequence number of the RREP packets with group sequence number of the multicast tables. If the information of the RREP packet is older than the information of the multicast table, the RREP packet is discarded.(4)If the RREP packet has newest route information or lower LEV, the node updates the multicast table. In Figure 19, we suppose that node E receives the RREP packet (LEV = 113.52) from node B before the RREP packet (LEV = 31.1) from node C. Node E updates its multicast table (Figure 19) after receiving RREP packet from node C because the RREP packet has lower LEV.(5)The relay nodes of the RREQ packet relay the RREP packets referring to their unicast tables which were updated at RREQ phase.(6)Steps from (2) to (5) are repeated until the RREQ source node (node F) receives the RREP packet. The RREQ source node moves to MACT phase after RREP waiting time.

Figure 18: Part of RREP packet format in proposed protocol.
Figure 19: Multicast table entry of node E in proposed protocol.
Figure 20: Transmission of RREQ and RREP packets in proposed protocol.
Figure 21: Transmission of MACT packets in proposed protocol.
4.2.3. MACT Phase

The MACT phase of the proposed protocol is same as MAODV. However, note that routing metrics in proposed protocol are queue length of relay nodes and hop count.

5. Performance Evaluation

5.1. Simulation Conditions

In this work, we carried out the simulation to evaluate the performance of proposed protocol by using Network Simulator version 2 (NS-2) [24]. We compared the proposed protocol with the MAODV protocol. The parameters in this simulation are shown in Table 2. The network topology is a grid which consisted of  APs (Figure 22). We generated three multicast groups which consist of three or four randomly selected nodes. Two of them generate background traffics (BGTs) which aim to give load to network. During the first twenty-five seconds of simulation time, only BGTs flow to give some loads to the network. Then, the other starts data transmission.

Table 2: Simulation parameters.
Figure 22: Network topology in simulation.
5.2. Simulation Results and Consideration

We observed change of delivery ratio, delay, and throughput at different traffic load (5, 10, 15, 20, 25, 30 packets/s) under two scenarios. In this paper, traffic load is defined as the number of data packets where each source node of three multicast groups sends per second.

First, we show simulation results (delivery ratio, delay, and throughput) from Figure 23 to Figure 25. In this case, the number of source nodes of three multicast groups is one (scenario 1). From Figure 23, we found that the delivery ratio of proposed protocol is higher than MAODV at all traffic loads. Nodes have big queue length which mean that packets concentrate on them. The proposed protocol avoids these nodes when a shared tree is constructed. Therefore, packet collisions and queue drops are decreased and delivery ratio is improved. Additionally, there is a tendency that difference between proposed protocol and MAODV becomes small with the increase of traffic load. This is because the proposed protocol constructs longer routes than MAODV. When the network load increases, each queue length increases (the congestion occurs). So the delivery ratio of proposed protocol is close to MAODV in high load.

Figure 23: Delivery ratio under scenario 1.

From Figure 24, we found that the throughput of proposed protocol is also higher than the MAODV at all traffic loads. A throughput is amount of received data packets per second in all nodes except BGTs. Therefore, the throughput of proposed protocol increases with difference of the packet delivery ratio between proposed protocol and MAODV.

Figure 24: Throughput under scenario 1.
Figure 25: Transmission delay under scenario 1.

From Figure 25, we can observe change of delay characteristics. The delay of proposed protocol is lower than MAODV when traffic load is low (5, 10 packets/s). At middle traffic load (15, 20 packets/s), the proposed protocol and MAODV have almost same characteristics. However, the proposed protocol deteriorates at high traffic load (25, 30 packets/s). This is because the queue length of transmission route reaches certain value at high traffic load. As mentioned above, the degree of delay increase of proposed protocol is bigger than MAODV because the proposed protocol tends to select longer route than MAODV. So, the delay of the proposed protocol becomes bigger than MAODV when traffic load is more than certain value. From this result, we should modify coefficients of (1) so that they change according to network load.

Next, we show simulation results from Figures 26 to 28. In this case, each multicast group has two source nodes (scenario 2). So, scenario 2 is more loaded than scenario 1.

Figure 26: Delivery ratio under scenario 2.

As shown in Figures 26 and 27, MAODV almost cannot communicate at high traffic load. On the other hand, in the proposed protocol, the delivery ratio and the throughput are significantly higher than MAODV because the proposed protocol avoids high loaded route.

Figure 27: Throughput under scenario 2.
Figure 28: Transmission delay under scenario 2.

From Figure 28, we can observe the delay characteristics which are different from scenario 1. In scenario 1, the delay characteristic of the proposed protocol becomes bigger than MAODV when traffic load reaches certain value. However, the delay of the proposed protocol is lower than MAODV at all traffic loads in scenario 2. From this, we found that in case there are any extremely high loaded nodes, the delay performance does not deteriorate even if longer route is selected to avoid these nodes.

6. Conclusions

In this work, we proposed the multicast routing protocol for multiuser communication over WMNs. The proposed protocol is based on MAODV which is a routing protocol for ad hoc networks. The proposed protocol calculates LEV of all candidate routes using their queue length and hop count. After that it selects one route which has the lowest LEV as a transmission route. From the simulation results, we showed that the delivery ratio, the throughput, and the delay characteristics are more improved than MAODV.

In this simulation, we evaluated network performance over uniform distribution. Next, we will simulate the network performance at non-uniform distribution. Under this scenario, there are high density area and low density area. In high density area, it is expected that there are varieties of routes; thus, the proposed protocol selects one which differs from MAODV, which improves network performances in loaded networks. However, the route could be more inferior than MAODV as is the case with scenario 1 if network is not congested. On the other hand, the proposed protocol chooses same route with MAODV with high probability in low density area because it is assumed that there are few candidate routes.

In the future, we would like to improve the proposed protocol to be able to adapt to change of network environments. However, we should mind that network performance is dropped if a network environment frequently changes and routes have to reconstruct frequently [25]. Furthermore, we would like to apply proposed protocol and metric to real WMNs and evaluate the performance.

Conflict of Interests

The authors declare that there is no conflict of interests regarding the publication of this paper.

References

  1. K. Mase and S. Sakata, Ad Hoc Mesh Networks, Corona Publisher, Tokyo, Japan, 2007, (Japanese).
  2. X. Wang and A. O. Lim, “IEEE 802.11s wireless mesh networks: framework and challenges,” Ad Hoc Networks, vol. 6, no. 6, pp. 970–984, 2008. View at Publisher · View at Google Scholar · View at Scopus
  3. J. D. Camp and E. W. Knightly, “The IEEE 802.11s extended service set mesh networking standard,” IEEE Communications Magazine, vol. 46, no. 8, pp. 120–126, 2008. View at Publisher · View at Google Scholar · View at Scopus
  4. I. F. Akyildiz and X. Wang, “A survey on wireless networks,” IEEE Radio Communications, vol. 43, no. 9, pp. S23–S30, 2005. View at Google Scholar
  5. M. Seyedzadegan, M. Othman, B. M. Ali, and S. Subramaniam, “Wireless mesh networks: WMN overview, WMN architecture,” in Proceedings of the International Conference on Communication Engineering and Networks, vol. 19, pp. 12–18, IPCSIT, 2011.
  6. S. Sakata, H. Aoki, and K. Mase, “Mobile ad hoc networks and wireless LAN mesh networks,” IEICE Transactions, vol. J89-B, no. 6, pp. 811–823, 2006 (Japanese). View at Google Scholar
  7. S. D. Odabasi and A. H. Zaim, “A survey on wireless mesh networks, routing metrics and protocols,” International Journal of Electronics, Mechanical and Mechatronics Engineering, vol. 2, no. 1, pp. 92–104, 2010. View at Google Scholar
  8. T. Farag, N. Funabiki, and T. Nakanishi, “An access point allocation algorithm for indoor environments in wireless mesh networks,” IEICE Transactions on Communications, vol. E92-B, no. 3, pp. 784–793, 2009. View at Publisher · View at Google Scholar · View at Scopus
  9. Draft-ietf-manet-aodv-00—Multicast Ad hoc On-Demand Distance Vector (MAODV) Routing, http://tools.ietf.org/html/draft-ietf-manet-maodv-00.
  10. M. Nomata, A. Koyama, and L. Barolli, “A multicast routing protocol for reduction of relay nodes in MANETs,” in Proceedings of the 13th International Conference on Network-Based Information Systems (NBiS '10), pp. 224–231, Takayama, Japan, September 2010. View at Publisher · View at Google Scholar · View at Scopus
  11. S.-J. Lee, W. Su, and M. Gerla, “On-demand multicast routing protocol in multihop wireless mobile networks,” Mobile Networks and Applications, vol. 7, no. 6, pp. 441–453, 2002. View at Publisher · View at Google Scholar · View at Scopus
  12. J. Xie, R. R. Talpade, A. McAuley, and M. Liu, “AMRoute: Ad Hoc multicast routing protocol,” Mobile Networks and Applications, vol. 7, no. 6, pp. 429–439, 2002. View at Publisher · View at Google Scholar · View at Scopus
  13. J. J. Garcia-Luna-Aceves and E. L. Madruga, “The core-assisted mesh protocol,” Selected Areas in Communications, vol. 17, no. 8, pp. 1380–1394, 2006. View at Google Scholar
  14. U. T. Nguyen, “On multicast routing in wireless mesh networks,” Computer Communications, vol. 31, no. 7, pp. 1385–1399, 2008. View at Publisher · View at Google Scholar · View at Scopus
  15. Draft-ietf-manet-aodv-05—Ad hoc On-Demand Distance Vector (AODV) Routing, http://tools.ietf.org/html/draft-ietf-manet-aodv-05.
  16. A. Bicket, D. Aguayo, S. Biswas, and R. Morris, “Architecture and evaluation of an unplanned 802.11b mesh network,” in Proceedings of the 11th Eleventh Annual International Conference on Mobile Computing and Networking (MobiCom '05), pp. 31–42, September 2005. View at Publisher · View at Google Scholar · View at Scopus
  17. B. Shin, S. Y. Han, and D. Lee, “Dynamic link quality aware routing protocol for multi-radio wireless mesh networks,” in Proceedings of the 26th IEEE International Conference on Advanced Information Networking and Applications (AINA '12), pp. 44–50, March 2012. View at Publisher · View at Google Scholar · View at Scopus
  18. S. Kim, O. Lee, S. Choi, and S.-J. Lee, “Comparative analysis of link quality metrics and routing protocols for optimal route construction in wireless mesh networks,” Ad Hoc Networks, vol. 9, no. 7, pp. 1343–1358, 2011. View at Publisher · View at Google Scholar · View at Scopus
  19. S. Roy, D. Koutsonikolas, S. Das, and Y. C. Hu, “High-throughput multicast routing metrics in wireless mesh networks,” Ad Hoc Networks, vol. 6, no. 6, pp. 878–899, 2008. View at Publisher · View at Google Scholar · View at Scopus
  20. D. S. J. de Couto, D. Aguayo, J. C. Bicket, and R. Morris, “A high-throughput path metric for multi-hop wireless routing,” in Proceedings of the 9th Annual International Conference on Mobile Computing and Networking (MobiCom '03), pp. 134–146, ACM, San Diego, Calif, USA, September 2003. View at Publisher · View at Google Scholar · View at Scopus
  21. K. Oe and A. Koyama, “A multicast routing protocol for wireless mesh networks considering network load,” in Proceedings of the 15th International Conference on Network-Based Information Systems, pp. 597–602, September 2012. View at Publisher · View at Google Scholar · View at Scopus
  22. K. Oe, A. Koyama, and L. Barolli, “Performance evaluation of a multicast routing protocol for Wireless Mesh Networks considering network load,” in Proceedings of the 27th IEEE International Conference on Advanced Information Networking and Applications (AINA '13), pp. 591–597, Barcelona, Spain, March 2013. View at Publisher · View at Google Scholar · View at Scopus
  23. A. Pal and A. Nasipuri, “A quality based routing protocol for wireless mesh networks,” Pervasive and Mobile Computing, vol. 7, no. 5, pp. 611–626, 2011. View at Publisher · View at Google Scholar · View at Scopus
  24. The network simulator-ns2, http://www.isi.edu/nsnam/ns/.
  25. J. Jun and M. L. Sichitiu, “MRP: wireless mesh networks routing protocol,” Computer Communications, vol. 31, no. 7, pp. 1413–1435, 2008. View at Publisher · View at Google Scholar · View at Scopus