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

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


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 intermesh 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.

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 defining multiple gateway nodes in a WMN. Tree-Based with Multi-Gateway Association (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 protocol 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 bottleneck 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 multimedia 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 extent, 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 priorities and dropping probability specified by the application layer for a specific traffic, the network layer chooses different routing metrics. A multiple metric routing protocol 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 metric, 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 parameters 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 differentiating the traffic into three different service classes.
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.

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.

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.  Fig. 1 illustrates this process. We distinguish four different states to describe a mesh node behavior at the routing trees construction 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 routing 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 corresponding 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.  The routing tree being constructed ; initialization tree =1 P Set of the stored paths in the cache of a node pi Path selected for the i th tree W The weight of a path Bw ; w1 Bandwidth ; its coefficient in the weight (W) calculating D ; w2 Delay ; its coefficient in the weight (W) calculating J ; w3 Jitter ; its coefficient in the weight (W) calculating Disj ; w4 Number of common nodes between paths ; its coefficient HC Number of hops in the path towards the root rank_D/A(X) Function that returns the rank of a path in a set of paths sorted in Descending/Ascending order according to the parameter X.
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.

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.
m_Path: the chosen Path by the intermediate node.
S_Path= the path sent in the PREQ.

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

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 realtime 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. 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.

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-toend delay and jitter for real-time application such as VoIP in a wireless mesh environment.
As ongoing work, we are conducting simulations to compare IMPR routing protocol to other proactive QoS based routing protocols for wireless mesh networks.