**3. Multi-radio ad hoc on-demand distance vector routing with channel reservation scheme**

The Multi-radio ad hoc on-demand distance vector routing with channel reservation scheme (AODV-MRCR) protocol is a multi-radio on demand distance vector routing protocol, which is proposed to establish high throughput paths for the gateway traffic in WMNs.

Our scheme uses on-demand reactive routing protocol to distribute the reserved channels list among all the nodes along the path from the source to the gateway. The source node that does not has fresh route to the gateway, it sends RREQ with flag set to one which means only the gateway can reply this message. Once the gateway receives a new RREQ\_I, it selects a reserved channel list and attaches to the RREP\_I message. The message is sent back to the source node. During the RREP\_I stage, each intermediate node selects its recommend channel based in the hop count index[20]. The intermediate node reserves at least two interfaces for the gateway path, one link for the forward path and other for reverse path.

We assume that *m* channels are available that can be used in a wireless area without interfering. In addition, *k* channels of available channel are statically assigned to *i* interfaces, half of *k* channels are used as "used channels", and the *m* − *k*/2 channels will be considered as "unused channels". The *i* available interfaces at each node can be classified as:


For example, if the mesh router has four interfaces, two channels of twelve (1, 2) will be considered as used channels. The reaming channels will be considered as unused channels. Moreover, the interfaces one and two will be considered as fixed interfaces while the interfaces three and four are switch- able interfaces. The scheme consists of two parts. The first part is carried out at the gateway, which is used to reserve a unique list of channels for each RREQ\_I received at the gateway. The second part is carried out when the intermediate nodes along the path back to the source receive the RREP\_I message. Following is a clarification of the procedures.

#### **3.1. Channel reservation scheme**

6 Will-be-set-by-IN-TECH

allocation strategies. The architecture is similar to Hyacinth architecture [25]; it classifies the interface to work as a fixed interface or a switchable interface. The protocol only considers one interface to work as a switchable interface. This interface has the ability to switch channels frequently, while the remaining interfaces are considered as fixed interfaces that work on fixed channels. The channel allocation of static interfaces aims at maximizing the network throughput from end-users to the gateway, while the dynamic interface is used to communicate with the neighbor node that has a different fixed channel on-demand fashion. Two dynamic interfaces that are within radio transmission range of each other are able to

In [23], the authors proposed a learning based approach for distributing channel assignments. It uses a learning based algorithm to determine the best channels to assign its own interfaces based on collecting information from the neighbor nodes. Hence, each mesh node periodically sends a "hello" message in order to discover its neighbors and the channel usage in its neighborhood. The algorithm achieves effective channel usage, and also adapts well to the change of network topology. [38] proposed a distributed channel assignment for uncoordinated WMNs to minimize the interference with adjacent access points. The algorithm assigns the least interference channel to the access point interference according to the gathered channel information from neighboring access points and associated clients. Both the protocols discussed earlier assign channels from node to node, and each node in the WMNs assigns a fixed channel, which makes it different from our approach. In our approach, channel assignment is based on data flow such that a channel is only assigned to a node if it has

The authors of [34] and [7] proposed algorithms to minimize network interference. The first one is interference-aware because it visits the links in decreasing order of the number of links falling in the interference range and it selects the least used channel in that range. Assuming the set of connection requests to be routed, both an optimal algorithm based on solving a Linear Programming (LP) and a simple heuristic are proposed to route such requests, given the link bandwidth availability as determined by the computed channel assignment. The algorithm considers minimum-interference channel assignments that preserve k-connectivity. The algorithm proposed in [7] uses a genetic approach to find the largest number that makes the whole network connected while minimizing network interference. However, such approaches only focus on minimizing the network interference that may decrease the network connectivity. In contrast to the above mentioned approaches, our approach is based on eliminating the interference for the common traffic on WMNs while maintaining network connectivity. Besides static channel assignment algorithms, which assign channels to interfaces without change for a long time, there have been several dynamic channel allocation

The authors of [29] proposed an on-demand channel allocation protocol in a wireless mesh network, where each node has two interfaces. In their framework, one interface of each node is devoted to controlling channel negotiation only while the other interface is used for data transmission. On the other hand, the frameworks proposed in [30] and [4] do not require a separate control interface, and the channel negotiation happens on the same interface for data

The Channel Assignment Ad hoc On-demand Distance Vector routing (CA-AODV) [12], has been proposed to assign channels within K hops in an ad hoc network, allowing for concurrent transmission on the neighboring links along the path and effectively reducing the intra-flow interference. Similar to CA-AODV, [33] proposed to join the channel assignment with the

algorithms proposed, which allow interfaces to switch channels frequently.

communicate by switching to the same channel when they have data to transmit.

data to send or forward to the gateway.

transmission.

Channel reservation scheme is carried out into two stages. First stage is carried out by the gateway, which is used to reserve a unique list of channel for each received RREQ\_I message,

8 Will-be-set-by-IN-TECH 234 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>9</sup>

see algorithm 1. The second stage is carried out when the intermediate nodes along the path back to the RREQ\_I source node receive RREP\_I message, which is aims to distributed the channel along the active nodes, see algorithm 2.

**Algorithm 1** The selection of the reserved channel list at the gateway

**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

1: *RCL*(*i*) ← 0, ∀*i* ∈ {0, .., 4} {4 means the maximum number of channel in *RCL*}

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

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

In this figure, the gateway selects the channel at location zero. This is because the hop count at the gateway is zero. Once the message receives at the next hop, the hop count will be one and the result of modular operation point to the location one in the reserve channel list, and so. When the hop count exceeds the maximum number of channel in the reserve channel list, such as node six, the recommended channel will be selected based on the modular operation which will point to location zero. However, In case the above constraints are not satisfied, the node sets the RREP's recommended channel to zero and forward the message to next hop, see

9: **if** (*gateway has been assign channel to theRREQ*\_*I source node*) **then**

10: *RCL*[] ← *LookupchannelTable*(*RREQ*\_*I*.*source*\_*address*)

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

*RC*: Recommended Channel

A: Unused channels *RCL*: Reserved Channel List

{ initialize variable }

5: *max*\_*channel* ← 4

14: *RC* ← *rand*(A)

17: *RCL*(*i*) ← *RC* 18: *i* ← *i* + 1 19: **end if** 20: **end while** 21: **end if**

22: *RC* ← *RCL*(0)

26: send *RREP*\_*I*

24: *RREP*\_*I*.*RC* ← *RC* 25: *RREP*\_*I*.*RCL* ← *RCL*

value.

27: END

algorithm 2.

4: **if** (*RREQ*\_*I*.*hops* > 3) **then**

7: *max*\_*channel* ← *RREQ*\_*I*.*hops*

13: **while** (*i* < *max*\_*channel*) **do**

15: check *RCL* for *RC* duplicate value. 16: **if** (*duplicate not f ound*) **then**

2: *RC* ← 0 3: BEGIN

6: **else**

8: **end if**

11: **else** 12: *i* ← 0

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

Once the gateway receives a new RREQ\_I message, it checks the channel reservation table for the RREQ\_I source address entry. Each table entry contains the source node address and reserved channel list for each received RREQ\_I.

**Figure 2.** Example of channel reservation scheme.

When the intermediate node receives the RREP\_I message, it creates/updates the forward route entry with the recommended channel as indicated in RREP\_I's recommended channel. Then, it selects a channel from the RREP\_I's list based on the hop count. The intermediate node selects the channel only if it satisfied the following constrains.


If the intermediate nodes along the forward path are satisfied the above constraints, a recommended channel will be selected based on the hop count modular the number of channel in the reserve channel list as shown in Fig. 2.

In case it matches, the corresponding entry is attached to the RREP\_I and send back along the reverse path to the RREQ\_I source node. However, if no entry found, then the gateway randomly select a new reserved channel list from the unused channel list, update the channel reservation table and attach the list to the unicast RREP\_I.

2 explains the channel selection at the gateway. Two RREQ\_I messages from source node (*S*) received at the gateway through different paths. The path with minimum hop count will be selected as the best path toward the source node (*S*). The gateway (*G*) checks the channel reservation table for the source node address (*S*). If a match is found, the corresponding entry is attached to the RREP\_I message. If not found, a new reserve channel list will be selected and attached to the RREP\_I message. The maximum number of the channel in the reserve channel list is four channels [20]. The reserve channel list along with recommend channel is attached to the RREP\_I message and is sent back to the RREQ\_I's source node.


8 Will-be-set-by-IN-TECH

see algorithm 1. The second stage is carried out when the intermediate nodes along the path back to the RREQ\_I source node receive RREP\_I message, which is aims to distributed the

Once the gateway receives a new RREQ\_I message, it checks the channel reservation table for the RREQ\_I source address entry. Each table entry contains the source node address and

RREP's reserved channel list RREQ Message RREP Message

**3 4**

**9 6 5 8 9 658 9 658 9 658**

When the intermediate node receives the RREP\_I message, it creates/updates the forward route entry with the recommended channel as indicated in RREP\_I's recommended channel. Then, it selects a channel from the RREP\_I's list based on the hop count. The intermediate

If the intermediate nodes along the forward path are satisfied the above constraints, a recommended channel will be selected based on the hop count modular the number of

In case it matches, the corresponding entry is attached to the RREP\_I and send back along the reverse path to the RREQ\_I source node. However, if no entry found, then the gateway randomly select a new reserved channel list from the unused channel list, update the channel

2 explains the channel selection at the gateway. Two RREQ\_I messages from source node (*S*) received at the gateway through different paths. The path with minimum hop count will be selected as the best path toward the source node (*S*). The gateway (*G*) checks the channel reservation table for the source node address (*S*). If a match is found, the corresponding entry is attached to the RREP\_I message. If not found, a new reserve channel list will be selected and attached to the RREP\_I message. The maximum number of the channel in the reserve channel list is four channels [20]. The reserve channel list along with recommend channel is

**8**

**7**

**Hop=4; Index=hop%4 Hop=3; Index=hop%4 Hop=2; Index=hop%4**

2. At least there is one interface work on fixed channel to support the local traffic.

attached to the RREP\_I message and is sent back to the RREQ\_I's source node.

**Gateway**

**G**

**9 65 8**

**Hop=0; Index=hop%4**

**Hop=1; Index=hop%4**

**9**

**5**

channel along the active nodes, see algorithm 2.

reserved channel list for each received RREQ\_I.

**9 6 5 8**

**S**

**Source node**

**Figure 2.** Example of channel reservation scheme.

1. The RREP's reserve channel list is not empty

channel in the reserve channel list as shown in Fig. 2.

reservation table and attach the list to the unicast RREP\_I.

**1**

**2**

**6**

node selects the channel only if it satisfied the following constrains.

**Require:** *RREQ*\_*I*: Routing Request message with an "I" flag *RREP*\_*I*: Routing Reply message with an "I" flag *RC*: Recommended Channel *hops*: Hop count field in RREQ\_I message A: Unused channels *RCL*: Reserved Channel List *max*\_*channel*: Maximum number of channels in each list *no*\_*i f ace*: Number of interfaces per mesh router { initialize variable } 1: *RCL*(*i*) ← 0, ∀*i* ∈ {0, .., 4} {4 means the maximum number of channel in *RCL*} 2: *RC* ← 0 3: BEGIN 4: **if** (*RREQ*\_*I*.*hops* > 3) **then** 5: *max*\_*channel* ← 4 6: **else** 7: *max*\_*channel* ← *RREQ*\_*I*.*hops* 8: **end if** 9: **if** (*gateway has been assign channel to theRREQ*\_*I source node*) **then** 10: *RCL*[] ← *LookupchannelTable*(*RREQ*\_*I*.*source*\_*address*) 11: **else** 12: *i* ← 0 13: **while** (*i* < *max*\_*channel*) **do** 14: *RC* ← *rand*(A) 15: check *RCL* for *RC* duplicate value. 16: **if** (*duplicate not f ound*) **then** 17: *RCL*(*i*) ← *RC* 18: *i* ← *i* + 1 19: **end if** 20: **end while** 21: **end if** 22: *RC* ← *RCL*(0) 23: update *RC* of the reversed routing entry that belong to the *RREQ*\_*I* source node with *RC* value. 24: *RREP*\_*I*.*RC* ← *RC* 25: *RREP*\_*I*.*RCL* ← *RCL* 26: send *RREP*\_*I* 27: END

In this figure, the gateway selects the channel at location zero. This is because the hop count at the gateway is zero. Once the message receives at the next hop, the hop count will be one and the result of modular operation point to the location one in the reserve channel list, and so. When the hop count exceeds the maximum number of channel in the reserve channel list, such as node six, the recommended channel will be selected based on the modular operation which will point to location zero. However, In case the above constraints are not satisfied, the node sets the RREP's recommended channel to zero and forward the message to next hop, see algorithm 2.

**NodeA**

**DIFS Back off RTS SIFS DATA**

**SIFS CTS SIFS ACK**

**NAV(RTS) NAV(DATA) DIFS**

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

**Defer Access**

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,

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

**Node B**

**Other nodes that used samechannel with A**

it replies with RREP message back to the RREQŠs source node.

**Figure 3.** Channel switching and negotiation.

**4. Simulation environment**

are listed in Table 1.

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

**Require:** *RREQ*\_*I*: Routing Request message with an "I" flag *RREP*\_*I*: Routing Reply message with an "I" flag *RC*: Recommended Channel *hops*: Hop count field in RREQ\_I message *RCL*: Reserved Channel List *max*\_*channel*: Maximum number of channels in each list *no*\_*i f ace*: Number of interfaces per mesh router *sw*\_*inter f ace*: Number of interfaces that has been switching 1: BEGIN 2: **if** ((*RREP*\_*I*.*RC* �= 0) **and** (*sw*\_*inter f ace* ≤ *no*\_*i f ace*/2)) **then** 3: update *RC* of the forward path that belong to the *RREP*\_*I* source node with the *RREP*\_*I*.*RC* 4: *sw*\_*inter f ace* ← *sw*\_*inter f ace* + 1 5: **end if** 6: **if** ((*RREP*\_*I*.*RCL* �= 0) **or** (*sw*\_*inter f ace* > *no*\_*i f ace*/2)) **then** 7: *RC* ← 0 8: *RREP*\_*I*.*RC* ← 0 9: **else** 10: *index* ← (*RREP*\_*I*.*hops* mod *max*\_*channel*) 11: *RC* ← *RREP*\_*I*.*RCL*(*index*) 12: *RREP*\_*I*.*RC* ← *RC* 13: update *RC* of the reversed routing entry that belong to the *RREQ*\_*I* source node with the new *RC* value. 14: **end if** 15: send *RREP*\_*I* 16: *END*

#### **3.2. Channel switching and negotiation**

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 the selected channel (recommended channel) same as proposed in [8, 29].

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 to the new channel.

**Figure 3.** Channel switching and negotiation.
