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 [1–7]. 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].
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.
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.
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.
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.
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 [18–20]. 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.
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.
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.
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.
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.
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.
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.
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.