**4. Simulation environment**

10 Will-be-set-by-IN-TECH

3: update *RC* of the forward path that belong to the *RREP*\_*I* source node with the

13: update *RC* of the reversed routing entry that belong to the *RREQ*\_*I* source node with

The proposed protocol is an across layer protocol that integrated the channel assignment and routing protocol with the MAC layer. The routing protocol is used to select the reserved channel list for each received RREQ\_I at the gateway and distribute them among the nodes along the path from the source to the destination. Moreover, the four handshake, rts-cts-data-ack, MAC messages are used by the proposed protocol in order to coordinate the channel switching between pair of nodes and ensure that both nodes have been switched to

Fig. 3 describes the channel switching and negotiation, when the intermediate node receives the RREP\_I message, it sends the message to the MAC layer using the reverse route entry interface field. Then the MAC layer sends a RTS message including the channel information to the neighboring nodes. The neighboring nodes, which work on the same channel as the sender, will receive the RTS message; upon receiving the RTS message, the receiver sends back a CTS message. Once the source node receives the CTS message, it starts sending the RREP\_I packet. If the node receives ACK or the transmission time has expired, it switches the interface to the new channel. At the receiver side, the receiver replies with an ACK and waits for the transmission time to expire when it receives data. After that, it switches the interface

the selected channel (recommended channel) same as proposed in [8, 29].

**Algorithm 2** Channel selection at an intermediate node

*hops*: Hop count field in RREQ\_I message

*RC*: Recommended Channel

*RCL*: Reserved Channel List

4: *sw*\_*inter f ace* ← *sw*\_*inter f ace* + 1

10: *index* ← (*RREP*\_*I*.*hops* mod *max*\_*channel*)

**3.2. Channel switching and negotiation**

1: BEGIN

5: **end if**

9: **else**

14: **end if** 15: send *RREP*\_*I*

16: *END*

to the new channel.

7: *RC* ← 0

*RREP*\_*I*.*RC*

8: *RREP*\_*I*.*RC* ← 0

12: *RREP*\_*I*.*RC* ← *RC*

11: *RC* ← *RREP*\_*I*.*RCL*(*index*)

the new *RC* value.

**Require:** *RREQ*\_*I*: Routing Request message with an "I" flag *RREP*\_*I*: Routing Reply message with an "I" flag

*max*\_*channel*: Maximum number of channels in each list

*sw*\_*inter f ace*: Number of interfaces that has been switching

2: **if** ((*RREP*\_*I*.*RC* �= 0) **and** (*sw*\_*inter f ace* ≤ *no*\_*i f ace*/2)) **then**

6: **if** ((*RREP*\_*I*.*RCL* �= 0) **or** (*sw*\_*inter f ace* > *no*\_*i f ace*/2)) **then**

*no*\_*i f ace*: Number of interfaces per mesh router

Since our protocol is multi-radio mutli-channel routing protocol that take into consideration the availability of multi-radio per mesh router as well as the multi-channel, We evaluate the performance of AODV-MRCR compared to AODV-MR [24] and MCR [17] using ns-2 [22]. The former AODV-MR is developed to enhance the reactive routing protocol to support the multi-radio and take into account the advantage of multi-links between mesh routers. The protocol uses ICA channel assignment where each mesh router has multi-radio interfaces, which statically dedicated to non-overlapping channel. The latter MCR routing protocol is developed to utilize the multi-channel where each node randomly selects a channel from the none-overlapping channels. The selected channel is assigned to an interface. This interface is considered as fixed interface for communication between neighbors and the remaining interfaces are considered as switchable interfaces. The switching mechanism is used to exchange the message between neighbors. When a mesh router has a data to send, it switches one of its switchable interfaces to the distentionŠs fixed channel. AODV-MR and MCR protocols distribute the channels based on unknown knowledge profile similar to our protocol. Moreover, they are based on the reactive routing discovery process in order to discover the path. When the node has data to send, it sends RREQ message and waits for receiving RREP message. Every intermediate node receives RREQ, it creates a reverse path and forwards the message to all interfaces. Once the destination receives the RREQ message, it replies with RREP message back to the RREQŠs source node.

A mesh network on an area of 1000 <sup>×</sup> 1000 meter<sup>2</sup> a 2-dimensional open area, without any building or mountain, was established using a random distribution mesh routers. Hence, a simple two-ray-ground propagation model [28] is used. all nodes are randomly distributed and each node is equipped with multiple wireless interfaces that statically turned to non-overlapping channels using the same channel allocation scheme. At the MAC layer, IEEE 802.11 DCF with RTS/CTS collision avoidance is used since we used the four hand check to distribute the channel between pair nodes along the path from source to destination. The channel switching latency is set to 80*μ*s [12]. The common parameters for all the simulations are listed in Table 1.

12 Will-be-set-by-IN-TECH 238 Wireless Mesh Networks – Effi cient Link Scheduling, Channel Assignment and Network Planning Strategies High Throughput Path Establishment for Common Traffic in Wireless Mesh Networks <sup>13</sup>


*5.1.1. Scenario 1: Varying number of the flow*

0 0.5 1 1.5 2 2.5

Packet Delivery Ratio (%)

packet delivery ratio.

**105 ×**

Packet Loss (packet)

10 20 30 40 50

TXͲRate AODVͲMR AODVͲMRCR

Number of Flows (a)

10 20 30 40 50

**Figure 4.** Simulation 1: results for scenario 1 (Varying the number of flows).

Number of Flows (c)

AODVͲMR AODVͲMRCR

many collision domains as the number of flows increase.

diversity along the path.

In this scenario, we investigate the impact of traffic load in the network. The number of generated flows varied from 10 to 50 flows with increments of 10. The packet size for each connection was fixed to 512 bytes with a 20 packet per second data rate. Fig. 4 (a-d) shows the packet loss, aggregated goodput, PDR and end-to-end delay performance. As observed from Fig 4, performance of the AODV-MRCR is comparable to that of the AODV-MR at a lower traffic load, such as 10 or 20. This is because AODV-MR can utilize the four channels to minimize the number of links on the same channel within the path as well as create channel

> 0 0.5 1 1.5 2 2.5 3

0 0.2 0.4 0.6 0.8 1 1.2

EndͲtoͲEnd Delay (seconds)

However, when the flow increases, the network becomes saturated. Thus, the AODV-MR end-to-end delay and packet loss increase as shown in Fig. 4(a, d) while the PDR and aggregated goodput decrease (Fig. 4(b, c). This is because AODV-MR is unable to avoid the congestion area as it does not have an intelligent way to route the packet through a less congested area. Moreover, minimum channel diversity cannot achieve due to using the hop count as a metric. In contrast, 4 shows an improvement in the performance of the AODV-MRCR under increasing traffic load relative to the AODV-MR. In addition, it shows that the lower packet losses incurred by our protocol enables it to achieve a significantly higher

This is because the protocol assigns a unique list of channels to every RREQ\_I received at the gateway during the route-establishing stage. Hence, the single collision domain divided to

Fig. 4(d) As the number of the flows increase, our protocol achieves better average end-to-end delay than the AODV-MR. This is because our reservation scheme allows the AODV-MRCR protocol to assign different non-overlapping channels for each node for the gateway traffic. Resulting in, reduces the contention time at the MAC layer as well as allowing the node to receive and send simultaneously. Moreover, It is interesting to note that at high traffic load

**106 ×**

Aggregate Goodput (bps)

10 20 30 40 50

10 20 30 40 50

Number of Flows (d)

Number of Flows (b)

AODVͲMR AODVͲMRCR

TXͲRate AODVͲMR AODVͲMRCR

High Throughput Path Establishment for Common Traffi c in Wireless Mesh Networks 239

**Table 1.** Simulation parameters

#### **4.1. Performance metrics**

The simulation provides the following five performance metrics:

