# QoS Multi-tree Based Routing Protocol for Inter-mesh Infrastructure Communications

Hajer Bargaoui, Nader Mbarek, Olivier Togni, Mounir Frikha

► To cite this version:

Hajer Bargaoui, Nader Mbarek, Olivier Togni, Mounir Frikha. QoS Multi-tree Based Routing Protocol for Inter-mesh Infrastructure Communications. 14th International Conference on Wired/Wireless Internet Communication (WWIC), May 2016, Thessaloniki, Greece. pp.199-211, 10.1007/978-3-319-33936-8_16. hal-01434852

HAL Id: hal-01434852

https://inria.hal.science/hal-01434852

Submitted on 13 Jan 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# QoS Multi-Tree Based Routing Protocol for Inter-Mesh Infrastructure Communications

Hajer Bargaoui, Nader Mbarek, Olivier Togni

LE2I Laboratory, University of Burgundy
Dijon, France

E-mails: {Hajer.Bargaoui, Nader.Mbarek, Olivier.Togni}@u-bourgogne.fr

Mounir Frikha

MEDIATRON Laboratory, High School of Communication of Tunis (SUP'COM)
Tunis, Tunisia

E-mail: m.frikha@supcom.rnu.tn

**Abstract.** Quality of service (QoS) in wireless mesh networks (WMN) is an active area of research, which is driven by the increasing demand for real-time and multimedia applications, such as VoIP (Voice over IP) and VoD (Video on Demand). In this paper, we propose a QoS multi-tree based routing protocol for wireless mesh environments, named Inter-Mesh Infrastructure Proactive Routing (IMPR). It is a proactive multi-tree routing protocol enabling QoS guarantee for communications from/towards the Internet network through the Mesh Gateway (MG) of the mesh infrastructure. We describe and analyze the simulation results of different scenarios conducted on the network simulator ns-3 to demonstrate the effectiveness of our IMPR routing protocol in forwarding real-time applications with QoS guarantee.

**Keywords:** Wireless Mesh Network; QoS routing, multi-tree routing, IMPR, Performance Evaluation.

## 1 Introduction

Popularity of WMNs in Internet access layer has been growing in the recent years. They are self-organizing and self-configuring multi-hop wireless networks, which are similar to ad hoc networks [1], [2]. However, a wireless ad hoc network is generally considered as a decentralized network that does not have any infrastructure. A main difference is that WMNs can support the multi-hop communications, but also be connected to the infrastructure networks through portal mesh points.

Forwarding real-time and streaming applications, such as VoIP and VoD, is a major challenge for wireless mesh networks due to radio channels limitations. Different routing protocols were proposed to ensure the discovery of a route with satisfying QoS parameters. However, forwarding different kinds of flows using a single route
may cause the perturbation of multimedia flows by non-QoS constrained ones. Thus, the challenging issue we address in this paper is how to forward flows depending on their requested service level (QoS) towards/from the Internet gateway in a WMN.

As a solution, we propose a QoS multi-tree based routing protocol (IMPR) for inter-mesh infrastructure communications, jointly with an adapted clustering algorithm to reduce efficiently the network's load within a wireless mesh infrastructure. IMPR is a proactive multi-tree routing protocol that provides QoS guarantee for communications from/towards the Internet network through the Mesh Gateway of the infrastructure. The proposed protocol defines three different service classes depending on the applications' QoS requirements. A different routing tree would forward each service class. In the other hand, in order to ensure QoS for communications within the wireless mesh infrastructure, the IMPR protocol operates jointly with a second QoS based routing sub-protocol. It is a reactive routing protocol proposed to ensure QoS guarantee for intra-infrastructure communications. Moreover, in order to reduce the overhead and the routing table size at each node, we proposed a one-hop clustering algorithm, which divides the topology of the infrastructure into a set of groups called clusters. A node named Cluster-Head (CH) coordinates each cluster. The inter-clusters communications are maintained thanks to Cluster-Gateway nodes (C-Gw), used to ensure connectivity between two Cluster-Heads in direct vision and the Distributed-Gateway nodes (D-Gw), used to ensure communications between two disjoint clusters. More details about the reactive QoS based routing protocol and the clustering algorithm have been published in [3].

In this paper, we aim to present the design details of our proposed IMPR routing protocol as well as the discussions of the different simulation results. The remainder of this paper is organized as follows. In Section 2, we present some related works. Then, we define in Section 3, the novel proactive QoS multi-tree based routing protocol IMPR and we introduce in Section 4 the performance evaluation and the results analysis. Finally, Section 5 concludes the paper.

## 2 Related Work

Given the particular topology of WMNs, characterized by the existence of a gateway node to ensure communications with the external networks, a tree based routing protocol was considered as a solution to handle this type of communication. The default routing protocol of the IEEE 802.11s standard, i.e. Hybrid Wireless Mesh Protocol (HWMP), defines a tree based path selection algorithm for inter-infrastructure communications [4], using the portal mesh gateway as a root. It is a proactive distance vector routing protocol, using a radio aware metric. HWMP is based on a periodic broadcast of proactive control messages to announce the existence of the root. Each node records and updates the metric to the root and forwards the received control message. Then, it chooses the best parent node and replies with a route reply message to the root. However, this approach does not consider the applications' QoS requirements in the tree construction process. In the research work [5], the authors propose a solution to reduce the number of routing packets sent to build the tree based topology. They define a new address space based on the link state and propose an initial route establishment method with greedy forwarding by using addresses as positional infor-
mation. Other research works address the bottleneck problem at the root node by de-
fining multiple gateway nodes in a WMN. Tree-Based with Multi-Gateway Associa-
tion (TBMGA) routing protocol [6] efficiently balance the load among the different
Internet gateways in the wireless mesh network, by creating a tree from each gateway.
In the same manner, Optimized Tree based routing (OTR) [7] lightens the load on the
root node by changing it in order to join another routing tree when its corresponding
gateway node gets congested. Madhusudan et al. [8] propose also a new routing pro-
tocol as a solution to bottleneck issues at the root node. Their proposed protocol,
named Decentralized Hybrid Wireless Mesh Protocol (DHWMP), is an enhancement
of the HWMP routing protocol in order to provide a different root for each different
transmission between a source and a destination node.

The previous mentioned tree based routing algorithms mainly focused on the bottle-
neck issues at the root node whereas the routes establishment for QoS-constrained
applications was not fully investigated by those works. In this context, some reactive
routing protocols were proposed to ensure QoS guarantee for real-time and multime-
dia traffic within a wireless mesh infrastructure. Wireless Mesh Routing (WMR) [9]
is a QoS based routing solution for wireless mesh LAN networks. It provides QoS
guarantees in terms of minimum bandwidth and maximum end-to-end delay. Kon et
al. [10] improve the WMR protocol by proposing a novel end-to-end packet delay
estimation mechanism thanks to a stability-aware routing policy. The delay estimation
is based on packets named DUMMY-RREP, which have the same size, priority and
data rate as real data traffic. However, these proposed approaches do not take into
account traffic heterogeneity within a WMN. Enabling QoS verification while using a
single path for different traffic types may create congestion or overloading in this
path. The research conducted in [11] attempts to address this limitation to some ex-
tent, in order to enhance the video quality over IEEE 802.11e WMN, by proposing a
cross-layer approach combined with the use of ETX metric. Depending on the priori-
ties and dropping probability specified by the application layer for a specific traffic,
the network layer chooses different routing metrics. A multiple metric routing proto-
col has been proposed in [12], by using an active network architecture to provide QoS
within WMNs. Their proposed routing protocol, named active AODV, adapts the
AODV routing protocol to use five routing metrics, namely the hop count, ETX met-
ric, ETT metric, Available Bandwidth metric and Expected Interference (EI) metric.
Most of the research works that we have presented, do not consider QoS requirements
of traffic belonging to different service classes. Thus, to guarantee various QoS pa-
rameters for heterogeneous traffic types, it is important to use multiple good quality
paths with appropriate routing metrics. In this context, we propose the IMPR routing
protocol, which provides mesh nodes with QoS based routing capability enabling a
service level guarantee for communications toward external networks, by differentiat-
ing the traffic into three different service classes.

3 IMPR: Inter-Mesh infrastructure Proactive Routing

Inter-infrastructure Mesh Proactive Routing (IMPR) is a proactive multi-tree based routing protocol, designed to ensure communications towards external networks, especially Internet network, for WMNs. IMPR deploys a multi-path routing concept
over each mesh node to ensure the construction of three partially node-disjoint routing trees; with a common root (i.e. Mesh Gateway), over a WMN. The routing trees construction process is based on the exchange of three different control messages, namely the Root Announcement (RANN) message, the Path Request (PREQ) message and the Path Relay (PREP) message. Thus, to reduce the overhead of the network, IMPR is used only over the different cluster-head and cluster gateways nodes. The cluster members would not participate to the trees construction process.

In fact, this multi-tree construction process of IMPR routing protocol is defined to provide QoS guarantees for real-time and multimedia applications, in a wireless mesh network. Each routing tree is set to forward a specific type of traffic. Therefore, we differentiate three service classes, namely interactive real-time applications class, Streaming applications class and Best Effort class. The first class is more sensitive to delay and jitter variations. The Streaming applications class is more sensitive to jitter variation while the third one is a non QoS-constrained traffic class. In brief, IMPR routing protocol allows the construction of three QoS partially node-disjoint trees with a common root: the Real Time tree, the Streaming tree, and the Best Effort tree.

In the following, we detail the operation of our IMPR routing protocol. Indeed, it is mainly executed according to two phases: the routes caching phase and the routing trees construction phase.

## 3.1 Routes Caching Phase

During this phase, each mesh node participating to the trees construction process, stores as much as possible routes towards the root node, by receiving a Root Announcement (RANN) message. In fact, the root node broadcasts periodically a RANN message (Table 1) to its neighboring mesh nodes to announce its presence. Only the CH and the Gw nodes consider this message. So, all the CM nodes reject it. Then, in order to keep an overall QoS value of the path, the RANN message introduces a QoS Metric field. It includes three QoS parameters, namely the bandwidth, the delay and the jitter.

When receiving a RANN message, each intermediate node stores the Path parameter in its route cache and updates it by adding its address. Furthermore, it modifies the QoS Metric and forwards the updated RANN message to its multicast group formed by the CHs, the Gws, and the root. In order to keep as many routes as possible, duplicated RANN messages are not rejected. Instead, to avoid an infinite loop of a message, each node verifies first if its address already exists in the Path field or not. Besides, each node keeps the entire path received through the RANN message in its route cache in order to be able to verify later the disjunction of two paths.

<table><caption>Table 1. RANN Message</caption><tr><td>Root IP address</td><td>Path</td><td>QoS Metric</td></tr></table>

## 3.2 Routing trees construction Phase

Each node waits for a certain time Ts, enabling a maximum of paths local storage, before starting the routing trees construction phase. Once the timer expires, each node
starts the selection of a potential Real Time Tree path from its route cache, according
to our proposed routes selection algorithm (Section 3.2.1). Then, this route is validated
as one of the tree branches by an exchange of PREQ and PREP messages with the root
node. In fact, this exchange of control messages between the mesh node and the root is
used to ensure that each intermediate node of a path is using the same path toward the
root, so that each node has no more than a single branch toward the root for a specific
routing tree. Once a PREP message is received from the root, the node validates the
path for the actual under construction routing tree, removes it from its route cache and
starts the construction process of the next routing tree in the same way.

<figure><img src="image_2.png" /><figcaption>Fig. 1. FSM diagram of IMPR routing trees construction phase</figcaption></figure>

A Finite State Machine (FSM) diagram in Fig. 1 illustrates this process. We distin-
guish four different states to describe a mesh node behavior at the routing trees con-
struction phase:

* "State 0": it is the initial state where a node has already in cache the maximum of paths towards the root node.

* State “Tree 1”: the node is participating in the construction of the first tree, i.e. the Real Time Tree. By executing the routes selection algorithm of IMPR (Algorithm 1), the node selects a path and sends a PREQ message to the root. In the same time, it forwards or reject the other control messages received from the other node, depending on the corresponding condition (Flowchart in Fig. 2).

* State “Tree 2”: by receiving a PREP message from the root for the first routing tree, the node validates the first tree path and changes to state “Tree 2” to start the construction of the second routing tree, i.e Streaming Tree.

* State “Tree 3”: similarly, once the mesh node validates a path for the second rout-
ing tree, it changes its state to start the selection of a path to the third routing tree,
i.e. Best Effort Tree.

In the following, we present the proposed algorithm for routes selection correspond-
ing to different QoS routing trees. Then, we define the Path request and the Path reply
process designed to validate each chosen path for each routing tree.
**Routes Selection Algorithm.** The routes selection algorithm (Algorithm 1) is proposed to provide each mesh node with the capability of selecting a potential path for each QoS routing tree, satisfying the requirements of three specified service classes. For the first path corresponding to the Real Time Tree, we select the best in terms of delay and jitter while optimizing the bandwidth parameter. For the Streaming Tree, we choose not only a partially disjoint path from the selected first tree path to reduce congestion issues, but also a path with low values of jitter. Lastly, from the remaining paths, we choose for the Best Effort Tree, the best in terms of disjunction over the other paths.

In case none of the stored paths satisfies the required QoS parameters, we introduce a weight parameter (W) for each path. It combines the different required QoS parameters with the disjunction parameter in order to allow the selection of the best path in terms of QoS guarantee while optimizing disjunction.

We specify in Algorithm 1 these concepts enabling the selection of routes for the different QoS routing trees. Besides, we present in Table 2 the notations used in the IMPR routes selection algorithm.

<caption>**Algorithm 1 : IMPR Routes Selection Algorithm**</caption>

1: **If tree = 1 then**
2:   A = {P}(D<Max and J<Max)
3:   **If A ≠ Ø then**
4:     p₁ = min<sub>HC</sub> {max<sub>BW</sub> (A)}
5:     **Else**
6:     B = {P}(D<Max)
7:     **If B ≠ Ø then**
8:       //Calculate W for each path in B
9:       W = w₁*rank_D (Bw) + w₃*rank_A (J)
10:      p₁ = min<sub>W</sub> (B)
11:      **Else**
12:      //Calculate W for each path in P
13:      W = w₁*rank_D(Bw) + w₂*rank_A(D) + w₃*rank_A(J)
14:      p₁ = min<sub>W</sub> (P)
15:      **End If**
16:      **End If**
17:      **End If**
18:      // Once the origin node receives a PREP from the root -> tree = tree+1
19:      **If tree = 2 then**
20:        P = P\{p₁}
21:        A = {P}(J<Max)
22:        **If A ≠ Ø then**
23:          //Calculate W for each path in A
24:          W = w₁*rank_D(Bw) + w₄*rank_A(Disj)
25:          p₂ = min<sub>W</sub> (A)
26:          **Else**
27:          //Calculate W for each path in P
28:          W = w₁*rank_D (Bw) + w₃*rank_A (J) + w₄*rank_A (Disj)
29:          p₂ = min<sub>W</sub> (P)
30:        **End If**
31:      **End If**
32:      // Once the origin node receives a PREP from the root -> tree = tree+1
33:      **If tree = 3 then**
34:        P = P\{p₂}
35:        p₃ = min<sub>HC</sub> {min<sub>Disj</sub> (P)}
36:      **End If**
<table><caption>**Table 2.** Notations used in the Algorithm 1</caption><thead><tr><td>Notation</td><td>Description</td></tr></thead><tbody><tr><td><b>tree</b></td><td>The routing tree being constructed; initialization tree =1</td></tr><tr><td><b>P</b></td><td>Set of the stored paths in the cache of a node</td></tr><tr><td><b>p<sub>1</sub></b></td><td>Path selected for the <i>i</i>th tree</td></tr><tr><td><b>W</b></td><td>The weight of a path</td></tr><tr><td><b>Bw</b> ; <b>w<sub>1</sub></b></td><td>Bandwidth ; its coefficient in the weight (W) calculating</td></tr><tr><td><b>D</b> ; <b>w<sub>2</sub></b></td><td>Delay ; its coefficient in the weight (W) calculating</td></tr><tr><td><b>J</b> ; <b>w<sub>3</sub></b></td><td>Jitter ; its coefficient in the weight (W) calculating</td></tr><tr><td><b>Disj</b> ; <b>w<sub>4</sub></b></td><td>Number of common nodes between paths ; its coefficient</td></tr><tr><td><b>HC</b></td><td>Number of hops in the path towards the root</td></tr><tr><td><b>rank_D/A(X)</b></td><td>Function that returns the rank of a path in a set of paths sorted in Descending/Ascending order according to the parameter X.</td></tr></tbody></table>

**Path Request Process.** By executing the route selection algorithm, a node selects a path for its ith routing tree and sends a PREQ message (Table 3), to the root node for validation. Each intermediate node compares its chosen path for its ith routing tree to the path carried by the PREQ message. If the intermediate node is already the origin of the PREQ message, it modifies its chosen path in order to eliminate the corresponding loop and sends a new PREQ message with the modified path. Otherwise, if the next hop in the two paths is different, the node either modifies its entire path or updates the path in the PREQ message, depending on the corresponding conditions. The Flowchart in Fig. 2 presents the different cases that an intermediate node may encounter, mainly based on the use of the level parameter, which represents the level of a node in the first routing tree, namely the Real Time Tree.

**Path Reply Process.** For each received PREQ message, the root node replies to the origin mesh node with a PREP message (Table 5), after updating its routing table. When an intermediate node receives a PREP message, it updates the Path field by adding its IP address and forwards it to next hop towards the destination. By receiving the PREP message, the destination node updates its routing table (Table 4) and its chosen path for the routing tree if it is different from the Path field in the PREP message. Then, it removes it from its route cache before starting the construction of the next routing tree.

<table><caption>**Table 3.** PREQ Message</caption><tr><td>Src IP address</td><td>Dest IP address</td><td>Path</td><td>ID-Path</td><td>Level<sup>a</sup></td></tr></table>

<table><caption>**Table 4.** IMPR Routing Table</caption><tr><td>Dest IP address</td><td>Next Hop</td><td>ID-Path</td></tr></table>

<footnote>a Level : the level of the source node in the Real Time Tree</footnote>
<table><caption>Table 5. PREP Message</caption><thead><tr><td>Dest IP address</td><td>Path</td><td>ID-Path</td></tr></thead></table>

<figure><img src="image_3.png" /><figcaption>Fig. 2. Flowchart of PREQ process</figcaption></figure>

# 4 Performance Evaluation and Results

## 4.1 Simulation Environment

To evaluate the performance of our IMPR routing protocol, we have developed our source code using the network simulator ns-3 environment [13]. Then, we have conducted some simulation scenarios to evaluate its performance and to compare it to the IEEE 802.11s default routing protocol HWMP, in a wireless mesh environment. In fact, HWMP routing algorithm defines also a tree-based sub-protocol for inter-mesh infrastructure communications [4].

The simulation environment consists of up to 30 stationary mesh nodes arranged in a grid topology. Simulation time is 200 seconds. Two different traffic models are used according to the elaborated scenarios. The first one is a generic Constant Bit Rate (CBR) traffic used in scenario 1 to evaluate our routing protocol performance in terms of overhead and convergence (section 4.2). The second one simulates a VoIP traffic used in scenario 2 (section 4.3) to evaluate real time traffic performance in terms of delay and jitter when using our protocol compared to HWMP. Each scenario is simulated ten times and an average value is considered for the performance analysis. Table 5 shows the used simulation parameters.
<table><caption>**Table 6.** Simulation Parameters</caption><thead><tr><td>Simulation parameters</td><td>Value</td></tr></thead><tbody><tr><td>Routing Protocols</td><td>IMPR & HWMP</td></tr><tr><td>Simulation Time</td><td>200s</td></tr><tr><td>Nodes 'Number</td><td>6 to 30 nodes</td></tr><tr><td>Mobility Model</td><td>GridPosition Allocator / static</td></tr><tr><td>Traffic Model</td><td>CBR (UDP) / VoIP (UDP)</td></tr><tr><td>Packet Size</td><td>512 bytes / 160 bytes</td></tr><tr><td>Data Rate</td><td>512kbps / 64 kbps</td></tr></tbody></table>

## 4.2 Scenario 1: routing protocol performance evaluation

We evaluate our routing protocol performance in terms of routing overhead and tree(s) construction convergence. To this end, we perform different simulations, by varying the number of nodes within a wireless mesh infrastructure, while considering a CBR traffic. This traffic is modeled with 512-byte data packets and a data rate of 512kbps.

Fig. 3.a shows the global routing overhead of IMPR and HWMP routing protocols. We observe a close variation of the routing overhead between the two protocols. In fact, to ensure the routing tree construction, HWMP protocol is based on the exchange of PREQ and PREP messages. The root broadcasts a PREQ message to announce its existence and each mesh node replies with a PREP message. However, IMPR routing protocol uses three different control messages, i.e. RANN, PREQ and PREP messages, to enable the construction of three partially node-disjoint trees with a common root. Despite the different control messages and the construction of three trees (unlike HWMP with only one tree), IMPR routing overhead remains acceptable, thanks to the adapted clustering algorithm, since the broadcast is limited to the multicast group formed by the CH and the cluster gateway nodes.

<figure><img src="image_4.png" /><figcaption>**Fig. 3.** IMPR vs HWMP (a) Overhead (b) Tree(s) Construction Convergence</figcaption></figure>
Fig. 3.b illustrates the variation of the routing Tree(s) Construction Time (TCT) according to the size of the mesh topology. For both protocols, the TCT parameter increases with the number of nodes since more delay is needed to reach all the nodes in the mesh infrastructure. HWMP protocol presents better TCT variation than our IMPR protocol. This is explained by the fact that HWMP protocol is based only on one routing tree, when IMPR offers three different QoS based routing trees at the end of the trees construction phase, to offer better QoS guarantee for real-time and streaming applications.

## 4.3 Scenario 2: Traffic performance evaluation

To demonstrate the effectiveness of our routing protocol in forwarding real-time applications with QoS guarantee, we evaluate the corresponding QoS parameters by generating a VoIP traffic towards an external network. We evaluate the VoIP real-time application in terms of average end-to-end delay and average jitter parameters, since such application is very sensitive to these QoS parameters.

To simulate a voice conversation, we used a traffic pattern corresponding to the G711 encoder, which produces 50 packets per second with 160 bytes of payload each. Then, we have introduced a noise over some links to simulate network perturbation. Besides, different source nodes are installed in the network, to simulate a more realistic scenario. The simulations are conducted to compare the IMPR routing protocol and the HWMP protocol usage by varying the mesh infrastructure size.

<figure><img src="image_5.png" /><figcaption>Fig. 4. VoIP Traffic (a) Delay Evaluation (b) Jitter Evaluation</figcaption></figure>

The obtained results concerning the end-to-end delay and jitter QoS parameters for a VoIP application are shown in Fig. 4. We observe a considerable difference concerning the variation of the delay and jitter parameters for the VoIP traffic while using HWMP and IMPR protocols. The corresponding values while using HWMP are almost twice the QoS values while using IMPR protocol. Thus, our IMPR protocol offers better guarantee in terms of QoS than HWMP protocol for real-time applications.

Actually, HWMP protocol offers a single tree for different service classes. Forwarding a real-time traffic may be perturbed by a Best Effort traffic generated by another node. On the other hand, IMPR protocol offers three partially disjoint QoS based
routing trees to be used depending on the type of the application to forward in order to
satisfy the requested QoS parameters.

Thus, to demonstrate the effectiveness of the IMPR QoS multi-tree approach, we conduct a different simulation scenario, enabling three different service classes’ flows generation between the root node and a mesh node. In this scenario, we simulate a 5x5 grid network topology consisting of 24 mesh nodes and a root node, in order to evaluate the performance of IMPR and HWMP protocols.

In the considered simulation scenario, the first flow (i.e Flow 1) starts at Time=10 seconds. Flow 1 has a rate of 64 kbps and a payload of 160 bytes, corresponding to a VoIP traffic (first service class). At Time=50 seconds, the source node starts generating a CBR UDP flow (Flow 2) with a rate of 512 kbps and a payload of 1000 bytes, simulating a streaming type traffic. As a Best Effort traffic, a third flow (Flow 3) begins at Time=80 seconds with a rate of 1Mbps and a payload of 1460 bytes.

We present in Fig. 5, the delay evaluation for each traffic flow while using, respectively, HWMP and IMPR as routing protocols in a WMN. We observe that the delay while using the HWMP protocol increases for Flow 1 (Time=50s) and Flow 2 (Time=80s) when the source node generates an additional flow. Indeed, we notice that the delay of the first flow get larger with the start of the second traffic flow, which could result in a QoS degradation for the VoIP real-time application simulated by Flow 1.

Nevertheless, we note a stable and a better delay, comparing to HWMP, while considering the different types of flows in the simulation scenario using the IMPR protocol. Actually, the HWMP protocol uses a single route to forward the three different flows, whereas the IMPR protocol uses a specific QoS routing tree for each traffic flow, reducing the inter-flows perturbation.

<figure><img src="image_6.png" /><figcaption>Fig. 5. Delay evaluation for different flows (a) using HWMP (b) using IMPR</figcaption></figure>

# 5 Conclusion

In this paper, we presented our QoS multi-tree based routing protocol jointly with a clustering algorithm, to ensure better performance for inter-mesh infrastructure communications, regarding the amount of traffic oriented to the Internet network. We compared the performance of our IMPR routing protocol to the HWMP protocol in terms of routing overhead and tree establishment convergence and showed that we
obtain better results while using our routing protocol to guarantee the average end-to-
end delay and jitter for real-time application such as VoIP in a wireless mesh envi-
ronment.

As ongoing work, we are conducting simulations to compare IMPR routing protocol
to other proactive QoS based routing protocols for wireless mesh networks.

**Acknowledgment.** This work has been funded by the regional Council of Burgundy, France.

References

1. I. F. Akyildiz, X. Wang, and W. Wang, "Wireless mesh networks: a survey," *Comput. Netw.*, vol. 47, no. 4, pp. 445-487, Mar. 2005.

2. I. F. Akyildiz and X. Wang, "A survey on wireless mesh networks," *IEEE Commun. Mag.*, vol. 43, no. 9, pp. S23-S30, 2005.

3. H. Bargaoui, N. Mbarek, O. Togni, and M. Frikha, "Hybrid QoS Based Routing for IEEE 802.16j Mesh Infrastructure," presented at the AICT 2014, The Tenth Advanced International Conference on Telecommunications, 2014, pp. 110-118.

4. "IEEE Standard for Information Technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 10: Mesh Networking," pp. 1–372, 2011.

5. K. Ueda and K. -i. Baba, "Proposal of an Initial Route Establishment Method in Wireless Mesh Networks," in *Ninth Annual International Symposium on Applications and the Internet*, 2009. SAINT '09, 2009, pp. 173–176.

6. S. Maurina, R. Riggio, T. Rasheed, and F. Granelli, "On tree-based routing in multi-gateway association based Wireless Mesh Networks," in *2009 IEEE 20th International Symposium on Personal, Indoor and Mobile Radio Communications*, 2009, pp. 1542–1546.

7. *Ji Wenjiang, M. Jianfeng, M. Zhuo, and T. Youliang, "Tree-Based Proactive Routing Protocol for Wireless Mesh Network," *China Commun.*, vol. 9, no. 1, pp. 25-33, Jan. 2012.

8. S. Madhusudan, Song-Gon, Lee, and HoonJae, Lee, "Non-root-based Hybrid Wireless Mesh Protocol for Wireless Mesh Networks," *Int. J. Smart Home*, vol. 7, no. 2, pp. 71–84, Mar. 2013.

9. Q. Xue and A. Ganz, "QoS Routing for Mesh-Based Wireless LANs," *Int. J. Wirel. Inf. Netw.*, vol. 9, no. 3, pp. 179–190, Jul. 2002.

10. V. Kone, S. Das, B. Y. Zhao, and H. Zheng, "QUORUM: quality of service in wireless mesh networks," *Mob Netw Appl*, vol. 12, no. 5, pp. 358–369, Dec. 2007.

11. M. A. Malgi and G. N. Gaikwad, "A study on QoS enhancement of MPEG-4 video transmission over Wireless Mesh Network," in *2015 International Conference on Pervasive Computing (ICPC)*, 2015, pp. 1–5.

12. J. Yun, J. Han, G. Seong, W. Cho, J. Seo, M. Khan, B. Kim, G. Park, and K. Han, "Self-organized multi-metric routing for QoS in wireless mesh networks," in *2014 International Conference on Information Networking (ICOIN)*, 2014, pp. 160–163.

13. "ns-3." [Online]. Available: http://www.nsnam.org/. [Accessed: 22-Feb-2015].