Mobile Netw Appl (2008) 13:117131 DOI 10.

1007/s11036-008-0038-4

A Hybrid Centralized Routing Protocol for 802.11s WMNs

Azman Osman Lim Xudong Wang Youiti Kado Bing Zhang

Published online: 1 April 2008 Springer Science + Business Media, LLC 2008

Abstract Wireless mesh networks (WMNs) are being widely accepted as a critical wireless access solution for various applications. Due to minimal mobility in mesh nodes, a backbone topology can be effectively maintained in WMN using a proactive routing protocol. In IEEE 802.11s standard, a tree-based routing (TBR) protocol is adopted as a viable proactive routing protocol for a WMN with user trafc owing to/from a wired network through a root (i.e., a mesh portal). However, the performance of the TBR protocol degrades rapidly as the user trafc becomes dominated by intra-mesh trafc. The reason is that the routing path through the root even for intra-mesh trafc unnecessarily overloads the root. Furthermore, the TBR performance becomes more severe when the network size of WMN is large, which could lead to the huge amount of intra-mesh trafc towards the root. To overcome these problems,

we propose a new routing mechanism, root driven routing (RDR) protocol, for the root to quickly determine the best-metric route for any source-destination pair of intra-mesh trafc. For inter-mesh trafc, the original TBR protocol is employed. Thus, the hybrid centralized routing protocol that combines TBR and RDR and is adaptive to all trafc scenarios. Our simulation results reveal that the proposed RDR protocol outperforms the TBR protocol with much lower average end-to-end delay and much higher packet delivery ratio for intra-mesh trafc. The simulation results also provide some insight into the right tradeoff between the TBR protocol and the RDR protocol to achieve the best performance of the hybrid centralized routing protocol for WMNs. Keywords wireless mesh network 802.11s hybrid centralized tree-based routing protocol intra-mesh trafc

A. O. Lim (B) National Institute of Information Communications Technology, 3-5 Hikaridai, Seika-cho, Soraku-gun, Kyoto 619-0289, Japan e-mail: aolim@nict.go.jp X. Wang Kiyon, Inc., 9381 Judicial Drive, Suite 160, San Diego, CA 92121, USA Y. Kado National Institute of Information Communications Technology, 3-5 Hikaridai, Seika-cho, Soraku-gun, Kyoto 619-0289, Japan B. Zhang National Institute of Information and Communications Technology, 3-5 Hikaridai, Seika-cho, Soraku-gun, Kyoto 619-0289, Japan

1 Introduction Wireless mesh network (WMN) has recently emerged as one of the tremendously promising technology for high-speed Internet access and state-of-the-art wireless networking in order to address a wide range of application scenarios. WMNs based on 802.11 wireless local area network (WLAN) rely on a multihop wireless backbone for delivering high-speed services to end-users without the need for deploying any xed infrastructure. WMNs supplant antiquated wired networks due to its advantages in terms of low-cost deployment, enhanced robustness, and exibility. WMNs are mainly targeted for residential, ofce, public safety,

118

Mobile Netw Appl (2008) 13:117131

military, campus, community, small to medium businesses, public access, emergency, municipality, and rural networks. Most of the above-mentioned networks needs to connect to the infrastructure networks. For example, an ambulance multihop network on an emergency call may connect to the hospital infrastructure as necessary for communicating with the doctor. In this kind of mesh topology, at least one root directly connects to the infrastructure networks. Moreover, nodes in this mesh network have minimal or no mobility. Thus, a proactive routing protocol is deemed more suitable for such a mesh network. The aforementioned features can be well captured by a tree-based routing (TBR) protocol [1, 2], which is attaining increased attention as a viable routing protocol for the WMNs. Based on the TBR protocol, the root (i.e., the mesh portal) constructs tree-type paths efciently and quickly in the WMN, whereby all the participating nodes are linked to it. In addition, the TBR protocol is proposed based on the premise that trafc are mostly directed to/from an infrastructure network through the root, in which it works effectively in handling the trafc communications towards the root. However, when the amount of trafc inside mesh network increases signicantly, the intra-mesh trafc around the root of the WMN becomes so heavy that the overall network performance can be degraded rapidly. Routing intra-mesh trafc through the root not only aggravate the said weak point of TBR protocol, but also waste efcient usage of network resources due to the physical characteristics of wireless constraints. Indeed all the forwarding of intra-mesh trafc through the root might ow over the routes without using the best-metric. To address these problems, in this paper we propose a new routing mechanism, namely a root driven routing (RDR) protocol that enables the root to provide the best-metric route for any source-destination pair rather than go through itself when an inevitability intramesh trafc volume occurs at the root. In other words, the RDR protocol extends and signicantly enhances the capability of the TBR protocol in regards to selftrafc-dispersing protocol and provides the best-metric route for all the source nodes. Furthermore, the RDR protocol advantageously improves the network performance without having any impact on the TBR protocol operation. It is a veritable idea that both TBR and RDR protocols fused into one stack protocol, called a hybrid centralized routing protocol. Thus, our main objective of the paper is to design an efcient and effective mechanism of RDR protocol that is simple enough for combining the TBR protocol to achieve the best performance for all trafc scenarios in the WMNs.

The remainder of this paper is organized as follows. The background of WMN and the related work are briey reviewed in Section 2. An overview of TBR protocol is given in Section 3 and the motivation of this paper is highlighted in Section 4. The details of the proposed RDR routing protocol are described in Section 5. Simulation setup and experimental results are presented in Section 6. This paper is concluded in Section 7.

2 Background and related work This section discusses the architecture of WMN and reviews the related work on tree-based approaches in disseminating control messages for the purpose of nding link status, collecting neighbor information, and requesting routing path. 2.1 WMN architecture In order to grasp the network architecture of WMN as specied in [3], we rst explain the original 802.11based WLAN [4]. Two types of WLAN are classied based on the combination of an access point and a station. The simplest WLAN type consists of a minimum of two stations, wherein each station operates with the same protocol. This is also known as a wireless ad hoc network. Another WLAN type consists of a minimum of one station and one access point (AP). It is represented as a wireless access network, in which the AP can act as a bridge or a gateway to other wired networks. To address the need of wireless mesh in WLANs, the AP links are unwired and their links are connected to each other via radio links resulting in a mesh of connectivity among the APs. Such an enhanced architecture is known as a WMN. An example of WMN architecture with legacy stations (STAs) as specied in the IEEE 802.11s [2] that is depicted in Fig. 1. In such a WMN architecture, different entities in the WMN

mesh portal point (MPP) mesh point (MP) mesh access point (MAP) legacy station (STA) mesh link legacy Link

Internet
A backbone of WMN

Figure 1 An architecture of WMN

Mobile Netw Appl (2008) 13:117131

119

play different roles according to the functionalities they provide. Basically, the WMN architecture consists of three entities; a mesh point (MP), a mesh portal point (MPP), and a mesh access point (MAP). The ad hoc link formation formed by the MPs, which provides the backbone for the WMN infrastructure, whereas the MPP works as a repeater or a gateway. The MP that supports the associated STAs is usually called as MAP. The MPs can be either stationary or mobile. However, the MPP and MAPs are mostly immobile. The STAs are usually regular devices that do not contribute to the WMN services, such as routing and forwarding for multi-hopping packets. Therefore, the STAs simply connect to one of the MAPs in order to access the network resources. Since we intend to focus on the routing protocol in the WMN backbone networks, STAs access to MAPs is not considered in this paper. We also use the terms of node and root to represent MP and MPP, respectively. 2.2 Related work Broadcasting protocols play an importance role in disseminating information to all network nodes in the wireless multihop networks [5]. For simple and reliable dissemination, a simply ooding or ooding-like approach is used. Despite its simplicity and reliability, ooding involves unnecessary communications, causing inefcient use of resources. To minimize the hefty communication overhead and reduce the number of collisions, the dissemination information is distributed over a tree path, instead of ooding it. In literature, the tree path broadcasting appears in two forms; a single root broadcast tree and multiple root broadcast trees. In the single root broadcast tree approach, Chlamtac and Kutten [6] have proposed two algorithms; distributed and centralized in order to increase the distribution efciency for maintaining the tree. In [6], both algorithms are based on a set of time-oriented channel allocation rules, which results in a collision free forwarding along the tree. In the distributed algorithm a message called TOKEN is generated at the root and routed through the network nodes. Upon TOKEN reception, a node becomes the focus of the tree construction activity and timeslot assignment. In the centralized algorithm however a nodes timeslot assignment is determined by the root only. In the multiple root broadcast trees, Ogier et al. [7] considered the idea behind reverse-path forwarding in [8] and proposed a new topology dissemination protocol called topology dissemination based on reversepath forwarding (TBRPF) protocol, in which broadcast trees are computed based on full topological informa-

tion received over the broadcast trees themselves. In TBRPF, every node executes Dijkstras algorithm to determine a reverse minimum-hop tree, and then exchanges some information with neighbors to determine its parent and children from the standpoints of other nodes. Once the topology is changed, TBRPF suffers from the overhead associated with computing the trees and communicating with neighbors. The idea of tree-based is also applied to the routing protocols for multicast (group-oriented) communication. An example of tree-based multicast protocols is multicast ad hoc on demand distance vector (MAODV) protocol [9]. The MAODV protocol maintains a shared tree for each multicast group, consisting of only receivers and relays. Sources wishing to send message to destinations in particular multicast group acquire on demand routes corresponding to the destinations in a way similar to the AODV protocol [10]. Each multicast group has a group leader. The group leader periodically transmits a HELLO packet to the receivers and relays. Upon HELLO packet reception, the receivers and relays reply with a special route request (RREQ) to the group leader in order to keep themselves as a member of shared tree. The primary drawback of MAODV is high delay and overhead in xing broken links under high network mobility and trafc load. It may be argued that its dependence on a unicast routing protocol makes it less exible. Besides the wireless networks, the idea of tree-based is used in the IEEE standardization like IEEE 802.1D Bridging LAN standard [11]. This tree-based algorithm congures a simply connected active tree topology from the bridge ports of a Bridged LAN. One of the bridges is known as the root bridge in the Bridged LAN. On the other hand, IEEE 802.11 working group conrmed a baseline draft for WMN, designated as IEEE 802.11s Wireless LAN medium access control (MAC) and physical layer (PHY) specications: Mesh Networking [2]. In the current draft, a hybrid wireless mesh protocol is a combination of on-demand and proactive routing protocols. On-demand routing protocol is adopted for nodes that experience a changing environment, while proactive TBR protocol is an efcient choice for nodes in a static WMN topology. The proactive TBR protocol is used to avoid unnecessary routing overhead for routing path discovery and recovery. Furthermore, the TBR protocol is deemed more suitable to cope with the most expected inter-mesh trafc that will occur between the nodes and the root (as gateway to further access the wired infrastructure). Although a plethora of research has been produced in relation to tree-based approaches for efcient and effective information distribution purposes, the TBR

120

Mobile Netw Appl (2008) 13:117131

protocol in the WMN deployment is still open issues among researchers today. To the best of our knowledge, there is no so much investigations on the performance optimization of TBR protocol under the static nature of WMNs.

3 The TBR protocol TBR protocol that is a kind of proactive routing protocols builds a tree-topology network when a root in the WMN is congured. The root is a portal or shared edge node with high computation, which acts like a server for other nodes. An example of root is a gateway of campus network topology. In this paper, we intend to focus our research work mainly dealing with only one root. Before a node could send its trafc to another node inside the mesh network, the topology tree is constructed in order to link all the participating nodes. This topology tree formation begins when the root starts to periodically broadcast a root announcement (RANN) message by increasing the sequence number in every announcement, which is set to default value of three seconds. The RANN message format is shown in Fig. 2a. A node receiving the RANN caches the originated node address of the corresponding RANN as a potential parent, and rebroadcasts the RANN with an updated cumulative metric. There are two fundamental approaches for a child node to select its parent node. First, after waiting for a pre-dened time of one second for other arriving RANNs from all possible parents, the child node selects a parent node with the best-metric

1 Type

1 TTL

4 Root Address

4 Root Sequence Number

Length Flag

Lifetime Metric

a
1 Type 1 1 1 4 4 4 Source Address 4 Source Sequence Number 4 Destination Address 4 Destination Sequence Number Length Flag TTL Lifetime Metric

b
28 4 4 4 4

RREP Message

Neighbor Node Neighbor Node Address #1 Link Metric #1

...

Neighbor Node Neighbor Node Address #m Link Metric #m

c
1 Type 1 1 4

m denotes number of neighbor nodes

Unreachable Unreachable Destination Length Flag Destination Address Sequence Number

Note: all the figures denote in Octets

Figure 2 RANN, RREP without and with neighbor information, and RERR message formats. a RANN message format. b RREP message format. c RREP message format with neighbor information. d RERR message format

for its path to the root from all the possible parents. Alternatively, the second approach is that the child node does not wait for the pre-dened time for other arriving RANNs from all possible parents, whereas the child node immediately selects the corresponding parent node that sent the rst received RANN message. After selecting the parent node, the child node updates its route table in which, for instance, the latest message sequence number. Then, the child node that has the known path to the root also registers itself by sending a route reply (RREP) message with the root as the destination address in the RREP message eld. Figure 2b shows the RREP message format. Each intermediate node that received the RREP forwards the RREP to its selected parent and updates the node it was received from as the next-hop child to reach the source node in its route table. After receiving all the RREPs, the root learns all participating nodes and builds a tree topology to reach any node in the mesh network. If a node does not hear the RANN for a pre-dened period, the node does not participate in tree-building until hearing a valid RANN again. Each node in the tree-topology network maintains its own route table, which has entries for recent route towards the destination node. In the route table of each node, the contents are destination (DST), next hop (NH), link metric (LM), sequence number (SN), time stamp (TS), and node ag (NF). The eld of link metric represents that the metric that is associated with the hop count, airtime cost, etc. For the sake of simplicity, the metric of hop count is hereinafter used for the TBR protocol as well as our proposed protocol in the simulation studies of this paper. The eld of sequence number represents the most recent information of an entry. The eld of time stamp represents that the time for an entry is stored and it is used to monitor the expiration of an entry. Each time the tree route is used, its associated time stamp is updated. If the route is not used within the specied time, route table timeout must be at least the maximum of three times of RAN N announcement interv al , it is deleted. The eld of node ag represents that the destination of entry is either a root (R) or a node (N). Figure 3 shows a root and all the participating nodes form a tree-topology network using the TBR protocol. With the tree-topology and table-driven routing, any node can participate and communicate with each other in the network. For instance, when a node wants to send trafc to another node, and if it has no route to its destination node, it sends the trafc to the root. Upon receiving the trafc from the source node, the root checks if the source trafc is intended for a node within the mesh or outside. The root forwards the source

Mobile Netw Appl (2008) 13:117131

Wired Network Wired Network

121

R A C F D

Root

R A E C F D G I
one-hop link TBR route
TS
1.0345 1.1355 1.3740 1.6241 1.5585 1.7925 1.8252 1.8511 1.9236

B E H

G I

Example: Rs Route Table

DST NH LM
A B C D E F G H I A B A A B A A B A 1 1 2 2 2 3 3 3 4

but also waste of network resources due to non-uniform spatial usage of shared wireless bandwidth. As a result, TBR protocol faces many problems like the increased end-to-end packet loss, the decreased network lifetime, root of the tree is unique point of failure, and poor load balancing whereby nodes near the root carry more trafc, which lead to trafc congestion around the root. To solve the aforementioned problems, we propose a RDR protocol that is a novelty protocol for handling the increment of intra-mesh trafc despite the intermesh trafc when nodes has a minimal mobility in WMNs.

SN
655 655 655 655 655 655 655 655 655

NF
N N N N N N N N N

Node As Route Table

DST NH LM
R D C F G I R D C C D D 1 1 1 2 2 3

SN
655 655 655 655 655 655

TS
1.0125 1.1075 1.2930 1.5430 1.4893 1.7632

NF
R N N N N N

5 RDR protocol In this section, we introduce a new RDR protocol, which incorporates with the TBR routing so that it forms a hybrid centralized routing protocol for the handling the increment of intra-mesh trafc despite the inter-mesh trafc in the WMNs. We rst present how to build the whole network topology at the root beside having the tree topology and then present the proposed protocol description and procedure. We discuss the computation and algorithm of choosing the optimum route for any source-destination pair. We also discuss how to improve the proposed protocol and its protocol procedures when dealing with link breaks.

Figure 3 A root and all participating nodes form a tree-topology network using the TBR protocol. The examples of route table for the root and node A are also provided

trafc to the destination node if it nds an entry in the route table, otherwise it sends to the destination node of the wired networks.

4 Problem description There are three types of trafc requiring routing via a mesh gateway, which is usually congured as a root in the WMN; upstream from inside mesh, downstream from outside mesh, and intra-mesh between nodes within mesh. For both downstream and upstream trafc, the root can provide the available proactive TBR protocol itself. For the trafc of intra-mesh between nodes within mesh, when a source node wants to send trafc to a destination node, which is inside the mesh network, the source node forwards the trafc toward the root if no active path exists and the destination node receives the trafc forwarded by the root. There is one serious drawback in the TBR protocol when other participating nodes always forward their intramesh trafc ow without using the best-metric route through the root. The root is noticeably overloaded with forwarding trafc as shown in Fig. 4. Moreover, when the network size grows and becomes signicantly huge, the intra-mesh trafc around the root becomes so heavy that the overall network performance can be degraded sharply and the entire network can slow down or even stall. Routing the intra-mesh trafc through the root not only worsen the performance of TBR protocol,

Wired Network

R A
C to B

B D
E to F G to E

C
F to H

E
H to D

F
I to B

G I

TBR route

Intra-mesh traffic

Figure 4 The inefciency of the TBR protocol when dealing with intra-mesh trafc in the mesh network

122

Mobile Netw Appl (2008) 13:117131

Wired Network

5.1 Protocol description and procedure The core idea of our proposed protocol is to inaugurate a RDR protocol for handling the intra-mesh trafc within the mesh network. First, to enable a root to provide the best-metric route for any intra-mesh trafc, it needs to build a whole network topology in addition to the tree topology. To do so, upon receiving the RANN message, each node piggybacks the neighbor information that consist of neighbor addresses and the corresponding metric into the RREP message (see Fig. 2c). Second, we need two additional messages; route set (RSET) and route notication (RNTF) in order to notify nodes within the network for their intra-mesh trafc. These two message formats are shown in Fig. 5b and c. Basically, the proposed protocol is very simple and efcient to provide an on-demand routes for any source to its corresponding destination in the mesh network. Simply to say, when a source node wants to send trafc to a destination node, the root can recommend the optimum on-demand route by notifying the route information using a RSET message via unicasting to the destination node or to the source node. Then, the destination node (or the source node) noties the intermediate nodes along the recommended optimum route with a RNTF message via unicasting. For the sake of consistency in term of protocol implementation, we only specify the case where the root sends the RSET message to the destination node rather than to the source node. Figure 6 illustrates an example of how the root uses a RDR protocol to provide a pair of sourcedestination to deliver its intra-mesh trafc. When a source node ( F ) wants to send trafc to a destination node ( H ), F has no route to its H , it sends a RREQ message to the root and followed by sending the DATA messages to the root. Upon receiving the RREQ mes-

source F
DATA 1 DATA 2 DATA 3

destination R H

R A C
DATA

Root

B D E G I H

DATA 4 DATA N time

source

destination

a
Wired Network

F
(2)

R G

H
(3)

R A C
(1) RREQ (2) DATA

(3) RSET

B D
(4) RNTF

DATA 1 DATA 2 DATA 3 DATA 4

(1)

(4)

E G I H

(5)

F
(5) DATA

DATA N

time

b
Wired Network Wired Network

R A C
DATA RSET

R B E G I H C
RREQ DATA

RSET

B E

D F

D F G I H

c
Figure 6 a The TBR protocol operation for intra-mesh trafc. b The proposed RDR protocol operation for intra-mesh trafc. c The function of RREQ in the proposed protocol

1 Type

4 Source Address

4 Source Sequence Number

4 Destination Address

4 Destination Sequence Number

Length Flag

TTL Lifetime

a
1 1 1 4 4 4 Node Address #1 (Source) 4 Source Type = RSET Length Flag Lifetime Sequence Number

...

Node Address #n (Destination)

b
1 1 1 4 4 Source Type = RNTF Length Flag Lifetime Sequence Number

n denotes number of notifying nodes

4 Node Address #1 (Source)

sage, the root refers to the topology information of the whole network, and then it selects the optimum route from F to H . To notify the selected route, the root generates a RSET message via unicasting to H , whereby the RSET message contains the complete path information from F to H . Meanwhile, the root also forwards the DATA messages to H . Upon receiving the RSET message, H generates a RNTF message, which contains the path information from F to H , and then forwards it to F via G according to the path information. When F receives the RNTF message, F switches and unicasts its DATA messages destined to H along the recommended optimum route by the root. 5.2 RREQ function According to the example of network topology in Fig. 6c, when a source node ( F ) wants to send trafc

...

Node Address #n (Destination)

Note: all the figures denote in Octets

Figure 5 RREQ, RSET, and RNTF message formats used in the proposed protocol. a RREQ message format. b RSET message format. c RNTF message format

Mobile Netw Appl (2008) 13:117131

123
Rs Neighbor List Cache Table
node
A B C D E F G H I R

to a destination node, e.g., G, F sends the trafc to the root if F has no route to G. Upon receiving the trafc with the destination address eld is set to G from F , node A realize that it has to forward the source trafc to G via node D. This is because A checked its route table and found out that there is an entry of destination G with two-hop away through D. Thus, A rationally sends all the source trafc to D rather to the root. In order to avoid the RREQ message is being forwarded by A to D, the destination address eld in the RREQ message is set to root address. By doing that, the RREQ message is directly to the root. Upon receiving the RREQ message, the root generates a RSET message. In other words, the function of RREQ message is to trigger the generation of RSET message when the proposed protocol is applied. Before the RSET message is generated, the root computes the optimum route for the source node that sent the RREQ message and the information of the optimum route put into the node address elds of RSET message as shown in Fig. 5b.

1-hop neighbors
R, B, C, D R, A, D, E A, D, F A, B, C, F, G B, D, G, H C, D, G, I D, E, F, H, I E, G, I F, G, H A, B

Rs Route Table
DST NH LM
A B C D E F G H I A B A A B A A B A 1 1 2 2 1 3 3 3 4

SN
655 655 655 655 655 655 655 655 655

TS
1.0345 1.1355 1.3740 1.6241 1.5585 1.7925 1.8252 1.8511 1.9236

NF RF
N N N N N N N N N PA PA PA PA PA PA PA PA PA

Dijkstras Algorithm
Recommended route Metric
F G H 2 hops

TBR route
Tree route
F C A R (3 hops) R B E H (3 hops)

Metric
6 hops

Algorithm to choose a route for any SRC-DST pair:

Begin myRoute = TBR_route if (myRoute > Recommended_route) myRoute = Recommended_route else if (myRoute == Recommended_route) myRoute = random(Recommended_route, TBR_route) end if End

The optimum route

5.3 Optimum route computation In the proposed protocol, the root builds a whole network topology upon receiving the RREP message that contains the neighbor information of the nodes. According to the topology information of the entire network, the root computes the optimum route for all source-destination pairs using the Dijkstras algorithm. Upon receiving the RREQ message, the root rst selects all the possible valid paths for a source-destination pair. Then, the root chooses the best-metric route among the possible valid paths. After the Dijkstras algorithm is carried out, the root compare the computation results with the existing TBR route information in its route table in order to make sure that the recommended route is an optimum route. Figure 7 shows a computation and algorithm of choosing the optimum route for a source-destination pair in the mesh network when the proposed protocol is applied. In other words, the root can adapt to the network demands by necessarily recommending the optimum route for a source-destination pair besides the tree-type route. If the computation result of best-metric route has the same metric with the TBR route, the algorithm chooses either one randomly as an optimum route. In order to avoid high computation in the root, the computation is conducted one based on the latest piggybacked neighbor information of participating nodes when a RREQ message is received. It is intuitively clear that the computation process is relatively simple and consumes less computation power for the root.

Figure 7 Computation and algorithm of choosing the optimum route for any source-destination pair in the mesh network

5.4 On-demand active route In this section, we explain how to implement and maintain the on-demand active route for any sourcedestination pair when the proposed protocol is applied. Upon receiving the RSET message, a destination node generates a RNTF message with an information of ondemand (optimum) route that is recommended by root. An intermediate node that received the RNTF message has to update its route table with the on-demand entries and forwards it toward the source node after processing the RNTF message. To ensure the entries for ondemand and proactive can share in one common route table, new column of route ag (RF) eld is added into the route table. The eld of RF represents that the destination of entry is handled either by the proactive (PA) mode or for the on-demand (OD) mode. Figure 8 illustrates an example of how to implement both proactive and on-demand entries in one common route table when the proposed protocol is applied. Upon receiving the RNTF message, the source node switches its trafc transmission to the corresponding destination node via the recommended optimum route by the root. In the proposed protocol, the route between each source and destination pair is expected to be symmetric. Thus, the forward path to destination and the reverse path back to source are constructed when one RNTF message is

124
Node Fs Route Table
DST NH LM
R C H C C G 3 1 1

Mobile Netw Appl (2008) 13:117131

Node Hs Route Table
NF RF
R PA N PA N OD

SN
655 655 325

TS
1.0032 1.0775 0.4625

DST NH LM
R E E E G 3 1 1

SN
655 655 325

TS
1.0074 1.0289 0.2905

NF RF
R PA N PA N OD

R
Root

A C
source Node Gs Route Table
DST NH LM
R D I H F D D I H F 3 1 1 1 1

B D E G
RNTF

F
DATA

destination An on-demand route is recommended by Root

SN
655 655 655 325 325

TS
1.1274 1.1375 1.4875 0.3125 0.3125

NF RF
R N N N N PA PA PA OD OD

neighbor information, we recommend that upon receiving each consecutive broadcasted RANN message from the root, every node replies the RREP message without piggybacking the neighbor information when the topology is unchanged. We restrict piggybacking the neighbor information in the RREP message only when the changes of the metric between a node and its neighbor nodes occurs. A part of the route optimization and maintenance for the proposed protocol is quite similar to the TBR protocol. 5.6 Link breaks A link between two nodes is not stable due to node movement and other restrictions. Since the network topology is dynamically changed with respect to time, the root needs to maintain its topology table by sending the RANN with every maintenance interval. For the TBR protocol, it can provide good reliability and low latency through frequent dissemination of routing information, but it entails high control overhead and scales poorly with the increasing number of nodes. If the parent node is lost, the child node checks its cached route table and selects a new parent node (if any) by unicasting a RREP destined to the root via the selected parent node. Figure 9a shows the link of

On-demand entries is recorded through the received RNTF

Figure 8 On-demand route construction for an intra-mesh trafc transmission using one common route table

received. As a result, it indirectly can reduce the overall control overhead of proposed protocol despite using the second RNTF message to build the reverse path back to source. In summary, one RNTF message is used to build a bidirectional path of source-destination pair when the route is assumed to be symmetric. Each time an on-demand route is used to forward a data packet, the source, the destination, and the intermediate nodes along the route are updated their time stamp eld of route table to be no less than the current time plus activ e route timeout. Since the on-demand route is assumed to be symmetric, the time stamp eld of route table along the reverse path back to the source, is also updated to be no less than the current time plus activ e route timeout. Since the mesh network is nearly a static network, the activ e route timeout is set to default value of three seconds. In other words, on-demand routes if not used for three seconds will be invalidated. After three seconds, the source, the destination, and the intermediate nodes along the on-demand route will be deleted their corresponding entry of the route table. For simplicity, a RERR message is generated to trigger the on-demand route in the proposed protocol. 5.5 Optimization and maintenance In the proposed protocol, the root can provide the optimum route information for all source-destination pairs, but it requires additional control overhead to piggyback the neighbor information of the nodes. Moreover, the root periodically needed to update the neighbor information that was piggybacked by the nodes in order to cope with the dynamic network changes. To reduce the control overhead, after the rst piggybacked

Wired Network

Wired Network

Root

R B
RERR Recovery Mechanism

R A C F
RREP

A C
destination

link break

B
new link

D F
DATA

E H

G I

source

G I

A new proactive link is built using RREP

Wired Network

Wired Network

R A C F D
RERR source DATA

R B
link break

A E C
RREQ DATA

B D E G I H

G I

H
destination

F initiates new RREQ and sends it to ROOT

proactive link

on-demand link

Figure 9 a Repair of a broken tree link. b Heal of a broken ondemand link

Mobile Netw Appl (2008) 13:117131

125

a child node ( D) and a parent node ( A) broken and a new link is built. For the proposed protocol, there is no additional mechanism is needed to re-establish the optimum route for an ongoing trafc transmission of a source-destination pair when an active link of the optimum route is broken. Once the intermediate node detected an active link is broken for the next hop of an on-demand active route in its route table while transmitting data, it sends a RERR message to the source node along the optimum route. For any intermediate node that receiving the RERR message, it deletes the corresponding entry of the on-demand route in its own route table. However, the source node stop sending its trafc transmission along the optimum route and generates new RREQ for hoping to look for another recommended route information from the root. Figure 9a and b show a repair of a broken tree link and a heal of a broken on-demand link, respectively.

where B denotes that the RANN is a broadcast message. Upon receiving the RANN message, each node replies a RREP message when the TBR protocol is applied. Thus, the size of RREP message can be expressed as SU RREP = 28 (2)

where U denotes that the RREP is an unicast message. On the other hand, each node replies a RREP message with neighbor information when the RDR protocol is performed. Therefore, the size of RREP message that used for the RDR protocol can be expressed as SU RRN I = 28 + 8n (3)

6 Evaluation studies We investigate the performance of the proposed protocol over the TBR protocol by using analysis and simulation. Both results are explained accordingly in the subsection. 6.1 Overhead analysis In this section, we analyze the overhead of the proposed RDR protocol over the TBR protocol. First, we dene a group of notations for the overhead analysis as listed in Table 1. The TBR and RDR protocols periodically broadcast a RANN message, in which the size of RANN message can be expressed as SB RAN N = 20
Table 1 Notations that used for overhead analysis

where n is the number of neighbor MPs that excluding parent MP and child MPs. In RDR protocol, a source node that wants to communicate with a destination node needs an additional RREQ message to trigger the root to recommend an optimum route. The size of RREQ message is given by SU RREQ = 24 (4)

Upon receiving the RREQ message, the root uses a RSET message to notify a destination node. Upon receiving the RSET message, the destination node uses a RNTF message to notify the intermediate nodes in order to establish the optimum route for the corresponding source node. The size of RSET and RNTF messages is given by
U SU RSET = S RNT F = 11 + 4m

(5)

(1)

where m is the number of notifying MPs. In this analysis, the mobility of MPs is not taken into account in order to simplify our calculation. Thus, we can assume that the RERR message will not be generated in both protocols.

Notation SB RAN N SU RREP SU RRN I SU RREQ SU RSET SU RNT F H MP, MPP H MP, MP NB NF N MP T RAN N

Description [unit] RANN size [byte] RREP size [byte] RREP size with neighbor information [byte] RREQ size [byte] RSET size [byte] RNTF size [byte] Average number of hops between MPP and MP [no unit] Average number of hops between MPs [no unit] Number of broadcasted transmissions [no unit] Number of trafc ows [no unit] Number of MPs [no unit] RANN broadcast interval [second]

126
0.06 0.05

Mobile Netw Appl (2008) 13:117131

Routing overhead (%)

TBR
0.04 0.03

at the rate of 50 packets per second. We plot the routing overhead as a function of the number of trafc ows. The routing overhead is obtained as below: RoutingOv erhead = CinBytes CinBytes + DinBytes (8)

RDR

0.02 0.01

0.00 2 4 6 8 10 12 14 16

Number of traffic flows Figure 10 Routing overhead as a function of number of trafc ows

where CinBytes is the total number of control bytes transmitted and DinBytes is the total number of data bytes received. Figure 10 shows the routing overhead as a function of number of trafc ows. It is seen that as the number of trafc ows increases, the routing overhead of both protocols decreases rapidly. When the number of trafc ows is 2, the routing overhead of TBR protocol and proposed protocol is about 0.030% and 0.057%, respectively. The difference becomes less when the number of trafc ows becomes larger. For example, the percentage difference of 16 trafc ows between two protocols is 0.015%. 6.2 Numerical simulations In this section, we investigate the performance of the RDR protocol over the TBR protocol with the OPNET 11.5 simulator [12] assuming in the WMN environment. In our simulation, all the nodes that included one root are conned to a 100 100 m2 area. The root is located in the top-left corner of the simulation area whereas other nodes are placed randomly and distributedly. Other parameters are summarized in Table 2. We model our trafc based on voice over internet protocol (VoIP). In the simulations a bidirectional VoIP trafc is sent, one ow from source node to destination

Next, we consider that the number of trafc ows as N F . Let H MP, MPP and H MP, MP be the average number of hops between MPP and MP, and the average number of hops between MPs, respectively. In this paper, these value are derived by averaging a few hundred topologies with MPs are placed randomly and uniformly. Under these assumptions, the total control overhead for both protocols can be derived as follow: The total control message of TBR protocol is given by CT BR = SB RAN N T RAN N NB + SU RREP T RAN N

N MP H MP, MPP (6)

However, the total control message of RDR protocol is given by C RDR = SB RAN N T RAN N NB + SU RRN I T RAN N N MP H MP, MPP

Table 2 Simulation parameters Parameter Network simulator Physical characteristic MAC protocol Network coverage area Simulation time Transmission range Transmission bit rate RANN broadcast interval RREP pre-dened time Mobility model Pause time Queue size Codec scheme for VoIP Voice offered rate Voice frame size Value OPNET 11.5 IEEE 802.11a OFDM CSMA/CA 100 100 m 100 s 50 m 54 Mbps 3s 1s Random waypoint 0s 50 packets G.711 64 kbps (50 pkts/s) 160 bytes

U + SU RREQ H MP, MPP + S RSET H MP, MPP

+ SU RNT F H MP, MP N F

(7)

In our numerical analysis, we assume that N MP is 32 and T RAN N is ve seconds. We obtain the H MP, MPP and H MP, MP by averaging 1000 topologies with 32 MPs are placed randomly and uniformly. The round-off value of H MP, MPP and H MP, MP is 5 and 3, respectively. To observe the intra-mesh trafc effect on the routing overhead, we vary the number of trafc ows. Each trafc ow consists of 160-byte frame size, which sends

Mobile Netw Appl (2008) 13:117131

127
100

node and another ow vice versa. All source nodes are pre-selected and all corresponding destination nodes are chosen randomly in the network. The VoIP trafc consists of 160-byte frame size, which sends at the rate of 50 packets per second. A G.711 encoder/decoder is applied to the VoIP ows. When the mobility is taken into account in the network, only the root is static and the entire node is moving based on random waypoint model, where the nodes direction is random, and the node speed is similar to human walking speed (1 m/s) with the pause time is zero seconds. For comparison purposes, the simulation time is 120 seconds and ten scenarios with different tree-path are averaged. Our simulation can be divided into two simulations. In the rst simulation, we investigate the impact of increasing trafc ow on protocol performance. The number of nodes is xed at 50. The number of trafc ows is varied from 10 ows to 50 ows in steps of 10 ows. In the second simulation, we focus on the inuence of the number of nodes on the performance of both routing protocols. The number of trafc ows is xed at 40 ows. The number of nodes is varied from 20100 in increment of 20. 6.3 Comparison of packet delivery ratio Figures 11 and 12 show how packet delivery ratio varies with number of trafc ows and the number of nodes, respectively. Packet delivery ratio is the ratio of total number of packets received at the destinations over the total number of packets transmitted by the sources. As both number of trafc ows and number of nodes increase, the superiority of the RDR protocol over the

Packet delivery ratio (%)

80

60

40

20

TBR (0 m/s) TBR (1 m/s) RDR (0 m/s) RDR (1 m/s)

20 40 60 80 100

Number of nodes
Figure 12 Packet delivery ratio as a function of number of nodes (40 ows with 50 packets/second)

TBR protocol becomes very obvious. This is shown that trafc around the root of the tree-topology becomes signicantly less when the proposed protocol is used. This leads to the fact that the number of packet drops due to packet collision and buffer overow reduces largely as well as a decrement of packet processing and forwarding at the root. In the static network, only the RDR protocol always manages to deliver the packets with a reliability greater than 98%. When nodes are moving, both protocols experienced the packet delivery drops below 55%. The reason is that a large number of packet drops due to many broken links occurred in the network. 6.4 Comparison of average end-to-end delay

100

80

60

40

20

TBR (0 m/s) TBR (1 m/s) RDR (0 m/s) RDR (1 m/s)

10 20 30 40 50

Number of traffic flows

Figure 11 Packet delivery ratio as a function of number of trafc ows (50 nodes)

Average end-to-end delay is the average elapsed time to deliver a packet from the source to the destination, and it includes all possible delays before data packets arrive at their destinations. Figures 13 and 14 show how average end-to-end varies with number of trafc ows and the number of nodes, respectively. As both number of trafc ows and number of nodes increase, the average end-to-end delay of the RDR protocol is about three to four times smaller than the TBR protocol when nodes are static. This is because the RDR protocol yields smaller delays in routing the data messages with the best-metric route that recommended by the root, resulting in the decrement packet contention and number of transmissions, which leads to low endto-end delay. When nodes are moving, both protocols experienced the average end-to-end delay more than 400 ms.

Packet delivery ratio (%)

128
1

Mobile Netw Appl (2008) 13:117131

18

Average end-to-end delay (s)

0.8

Routing overhead (%)

TBR (0 m/s) TBR (1 m/s) RDR (0 m/s) RDR (1 m/s)

TBR (0 m/s) TBR (1 m/s) RDR (0 m/s) RDR (1 m/s)

12

0.6

0.4

0.2

0 10 20 30 40 50

10

20

30

40

50

Number of traffic flows

Figure 13 Average end-to-end delay as a function of number of trafc ows (50 nodes)

Number of traffic flows

Figure 15 Routing overhead as a function of number of trafc ows (50 nodes)

6.5 Comparison of routing overhead The routing overhead describes how many routing messages for route discovery and route maintenance need to be sent in order to propagate the data messages. In this paper, the routing overhead is obtained from Eq. 8. In the RDR protocol, the additional of control bytes accounts for RSET and RNTF messages as well as the piggybacked neighbor information of the nodes in the RREP message. However, the routing overhead remains fair when the number of trafc ows increases, because the number of control bytes transmitted is almost constant without change with the increasing trafc ow. We can see from Figs. 15 and 16 that the routing overheads of TBR protocol and RDR protocol become

very close with each others as the number of trafc ows becomes large or as the number of nodes becomes less. However, simulation results show that when nodes are moving, the routing overhead for both protocols is about twice as large as that of the routing overhead when the network is static. 6.6 Discussion on voice quality of VoIP In the previous section, we adopt the VoIP trafc model and evaluate the average end-to-end delay and the packet delivery ratio of the WMN environment by using the TBR protocol and the RDR protocol. In order to justify the transmission quality of the VoIP trafc in our simulations, we use the requirements that

18

Average end-to-end delay (s)

0.8

Routing overhead (%)

TBR (0 m/s) TBR (1 m/s) RDR (0 m/s) RDR (1 m/s)

TBR (0 m/s) TBR (1 m/s) RDR (0 m/s) RDR (1 m/s)

12

0.6

0.4

0.2

20

40

60

80

100

20

40

60

80

100

Number of nodes
Figure 14 Average end-to-end delay as a function of number of nodes (40 ows with 50 packets/second)

Number of nodes
Figure 16 Routing overhead as a function of number of nodes (40 ows with 50 packets/second)

Mobile Netw Appl (2008) 13:117131

129

is proposed by [13]. In [13], they determine that class A requires less than 100 ms of average end-to-end delay and more than 97% of packet delivery ratio, dening the speech quality for the xed phone services. However, class B requires less than 150 ms of average end-to-end delay and more than 94% of packet delivery ratio, dening the speech quality for mobile phones services. Based on the Figs. 11 and 13, we conclude that when all nodes are static the TBR protocol can support only 22 ows, and 24 ows when the number of nodes is 50 for class A and class B voice quality, respectively. On the other hand, under the same conditions the RDR protocol can support more than 50 ows for both class A and class B voice quality. The RDR protocol, therefore, is efcient and effective for practical voice applications such as VoIP service. 6.7 The effect of intra-mesh trafc ratio inside the WMN In our previous results, all the trafc between nodes in the WMN are assumed to be the intra-mesh trafc. Besides the intra-mesh trafc, the trafc between a node in the WMN and a node on the wired networks is mainly originated within the mesh network. For fair evaluation, we further examine the performance of the RDR protocol over the TBR protocol when the intramesh trafc ratio is increased from 0% to 100%. The intra-mesh trafc ratio is calculated as the number of intra-mesh trafc ows over the total number of user trafc ows. For example, the intra-mesh trafc ratio is 20%. This means that the percentage of intra-mesh trafc is 20% and the rest of the percentage, i.e., 80% is the inter-mesh trafc. We run the simulations with the rest of the parameters is the same except the number

of nodes is 50 and 10 simulation scenarios with different random seeds are averaged. Figure 17 shows the throughput as a function of intra-mesh trafc ratio. The throughput is the average total number of data bytes received at the destinations over the total simulation time. Our evaluation reveals that when the intra-mesh trafc ratio is below 20%, the RDR protocol obtains approximately the same throughput compared to the TBR protocol. We can see that the RDR protocol outperforms the TBR protocol when the intra-mesh trafc ratio is more than 20%. We conclude that in order to assure the best network performance, the TBR protocol can be used for inter-mesh trafc whereas the RDR protocol can be used for intra-mesh trafc.

7 Concluding remarks In this paper, we proposed the RDR protocol to solve the trafc concentration around the root when the TBR protocol is used for the intra-mesh trafc in the WMNs. The RDR protocol provides the optimum route by the root for any source-destination pair of intra-mesh trafc. The RDR protocol advantageously improves the network performance without incurring any severe impact on the operation of TBR protocol. In order to accomplish the best network performance, the TBR protocol can be used for inter-mesh trafc whereas the RDR protocol can be used for intra-mesh trafc. These two protocols are potentially fused into one stack protocol, called a hybrid centralized routing protocol that adaptively handles all trafc scenarios in the WMNs. Numerical simulations reveal that the RDR protocol is very benecial and outperforms the TBR protocol with much lower average end-to-end delay and much higher packet delivery ratio for the intra-mesh trafc. Furthermore, our simulation results show that when all nodes are static the TBR protocol can support only 22 trafc ows when the number of nodes is 50 for class A voice quality, whereas the RDR protocol attains more than 50 trafc ows. Our simulation results are very encouraging and we currently focus on examining the multiple root broadcast trees issue for the WMNs.

Throughput (Mbps)

References
TBR RDR

20

40

60

80

100

Intra-mesh traffic ratio (%)

Figure 17 Throughput as a function of intra-mesh trafc ratio

1. Raniwala A, Chiueh TC (2005) Architecture and algorithms for an IEEE 802.11-based multi-channel wireless mesh network. In: Proc. IEEE INFOCOM conf. IEEE, Piscataway, pp 22232234 2. IEEE (2007) Amendment: Mesh networking. IEEE P802.11s/D1.06. IEEE, Piscataway

130 3. Akyildiz IF, Wang X, Wang W (2005) Wireless mesh network: a survey. Comput Netw 47(4):445487 4. IEEE (1999) Part II: Wireless LAN medium access control (MAC) and physical layer (PHY) specications, ANSI/IEEE Standard 802.11-1999. IEEE, Piscataway 5. Juttner A, Magi A (2005) Tree based broadcast in ad hoc networks. Mob Netw Appl 10(5):753762 6. Chlamtac I, Kutten S (1987) Tree-based broadcasting in multihop radio networks. IEEE Trans Comput C-36(10): 12091223 7. Ogier R, Templin F, Lewis M (2004) Topology dissemination based on reverse-path forwarding (TBRPF). RFC 3684. IETF, Fremont 8. Dalal YK, Metcalfe RM (1978) Reverse path forwarding of broadcast packets. Commun ACM 21:10401048 9. Royer E, Perkins C (1999) Multicast operation of the ad hoc on-demand distance vector routing protocol. In: Proc. mobicom conf., Seattle, 19 August 1999 10. Perkins C, Royer E, Das S (2003) Ad hoc on-demand distance vector (AODV) routing. RFC 3561. IETF, Fremont 11. IEEE (2004) Medium access control (MAC) bridges, IEEE Standard 802.1D-2004. IEEE, Piscataway 12. OPNET (2008) OPNET Simulator. http://www.opnet.com/ 13. Szigeti T, Hattingh C (2005) End-to-end QoS network design: quality of service in LANs, WANs, and VPNs. Cisco, Indianapolis

Mobile Netw Appl (2008) 13:117131 he joined NICT in 2005. Since 2005, he is actively joining the standardization activities of IEEE 802.11s Mesh Networking. Since 2006, he is also joining the standardization activities of nextgeneration home networks from Telecommunication Technology Committee (TTC), Japan. In April 2007, he obtained a Grantin-Aid for Scientic Research from the Ministry of Education, Culture, Sports, Science and Technology (MEXT) for three years. His research interests include the congestion control and management of ATM networks, multihop wireless networks, wireless mesh networks, wireless sensor networks, heterogeneous wireless networks, two-dimensional communication system, game theory, and capacity theory. He is a member of IEEE and IEICE.

Azman Osman Lim received the B.Eng. (Hons) and M.Inf. Technology degrees from Universiti Malaysia Sarawak (UNIMAS), Malaysia in 1998 and 2000, respectively. He received the Ph.D. degree in communications and computer engineering from Kyoto University in 2005. Currently, he is an expert researcher at National Institute of Information and Communications Technology (NICT), Japan, where he is one of the researchers involving energetically in new era of communication, called two-dimensional communication system. He was a visiting researcher at Fudan University in China for two months before

Xudong Wang received his B.E. degree in Electric Engineering and his Ph.D. degree in Automatic Control in 1992 and 1997, respectively, from Shanghai Jiao Tong University, Shanghai, P. R. China. In August 2003, he also received a Ph.D. degree in Electrical and Computer Engineering from Georgia Institute of Technology. Currently, he is the R&D manager at Kiyon, Inc., where he leads research and development of wireless mesh networking technologies. He was a senior network architect and researcher in the same company. He is the creator of Kiyons pioneering single-channel and multi-channel TDMA technologies for wireless mesh networks. His research interests also include cognitive/software radios, cross-layer design, and communication protocols for cellular networks, mobile ad hoc networks, sensor networks, and ultra-wideband networks. He holds a number of patents on wireless networking technologies and most of his inventions have been successfully transferred to products. Dr. Wang is an editor for Elsevier Ad Hoc Networks and was also a guest editor for several journals. He was the demo cochair of the ACM International Symposium on Mobile Ad Hoc Networking and Computing (ACM MOBIHOC 2006). Currently he is a technical program co-chair of Wireless Internet Conference (WICON) 2007. He has been a technical committee member

Mobile Netw Appl (2008) 13:117131 of many international conferences and a technical reviewer for numerous international journals and conferences. Dr. Wang is a member of IEEE, ACM, and ACM SIGMOBILE and a voting member of IEEE 802.11 and 802.15 Standard Committees.

131

Youiti Kado received the B.Litt. degree from Kyoto University in 1992. He received the M.Eng. degree from Nara Advanced Institute of Science and Technology in 1995. He was an employee at Oki Electric Industry Co., Ltd., Japan for eleven years before he joined Knowledge Creating Communication Research Center, NICT, Japan in 2005. His research interests include the wireless mesh and sensor networks, ATM networks, and knowledge processing.

Bing Zhang received her B.S. degree in 1983 from Peking Aeronautics and Astronautics University, China, and M.S. in 1987 and Ph.D. degrees in 1990 from Hiroshima University, Japan. From 1991 she has been working at the Communication Research Laboratory of Japan Ministry of Posts and Telecommunications (presently, National Institute of Information and Communications Technology), as a senior researcher. During 1995-1996, she was a post-doctoral research associate in the University of Tennessee. From 2000 to 2004, she was with ATR Adaptive Communications Research Laboratories as a senior researcher. She is an editor for IEICE, and was a TPC member for VTC2007 (IEEE 66th Vehicular Technology Conference). Her current research interests include wireless mesh networks, sensor networks, ubiquitous computing systems and two-dimensional communication system. She is a member of IEEE and IEICE.