Design and Implementation of a WLAN Mesh Router Based on Multipath Routing

Jeong-Soo Kim, Sang-Hwa Chung, Yun-sung Lee, Chang-Woo Ahn, Won-suk Kim and Min-su Jung
Department of Computer Engineering Pusan National University Busan, Republic of Korea {mankindy, shchung, nzellys , changwooahn, skystars, jmanshu}@pusan.ac.kr
Abstract This paper focuses on the development of an IEEE 802.11s-based WLAN mesh router, which supports a multichannel with multi-interface. In this work, we implemented not only the single path routing based AODV defined in IEEE 802.11s HWMP, but also a multipath routing which extended the standard. The multipath routing was intended to reduce the recovery time and the control message overhead when the routing path was recovered from node or link failure. We also developed an outdoor test bed with 12 WLAN mesh routers. The bandwidth of the mesh router and a real-time video streaming service were verified using the test bed. The single path and multipath routing algorithms are also compared. The average TCP bandwidth was 23.77 Mbps and the latency was 2.4 ms in five hops. The test bed could service real-time streaming of MPEG4 VGA video with an average jitter of 0.547 ms in five hops. The mesh router that used the multipath routing path reduced the path recovery time by 12.73% on average. Keywords-Wireless Mesh Network; IEEE 802.11s; Multichannel Multi-interface; Multipath Routing

multipath routing algorithm was based on AOMDV (Ad hoc on-demand multipath distance vector routing) [15]. A multi-channel multi-interface technology that can transmit and receive simultaneously and lower bandwidth reduction caused by interferences than a single-channel singleinterface was implemented in our mesh router [3]. We verified the performance of the mesh router using an outdoor test bed with 12 WLAN mesh routers. The rest of this paper is structured as follows. Section II briefly explains the IEEE 802.11s standard, AODV, and the multipath routing protocols based on AODV, section III examines the design and implementation of the WLAN mesh router, section IV presents the results and analysis of experiments on the test bed, and section V concludes. II. RELATED WORK The IEEE 802.11s standard adopts mesh network technology to the IEEE 802.11 standard. IEEE 802.11s has defined that wireless nodes can automatically form a network in multihop network topology and can support broadcast, multicast, and unicast. A default wireless node is called a mesh point (MP), and it configures the mesh network and sets the path for data transfer using MAC layer routing protocols to communicate with other nodes. The mesh portal (MPP) connected to the wired network performs the task of a gateway node. It transmits data from the WLAN mesh network to the wired network. A mesh AP (MAP) is an MP with added AP (Access Point) functionality to connect clients to the WLAN mesh network. In the MIT Roofnet [17], each node consists of a small textbook-sized PC. All nodes in a Roofnet have a single radio and an omnidirectional antenna and are self configuring. Nodes constantly measure link conditions to nearby nodes in an effort to estimate link quality; the SRCR routing protocol, a variant of the Dynamic Source Routing (DSR) protocol, uses these estimates to choose a set of five optimal routes. In [18], Intel laptop PC and ARM-based embedded Linux development board were used to implement mesh routers. All nodes have a single radio and an omnidirectional antenna. Among tabledriven routing protocols, Optimized Link State Routing (OLSR) was used as a routing protocol. On the other hand, in industry, commercial products by companies such as Firetide, Motorola etc., have multi-channel multi-interface, but concrete methods to develop the mesh router was not reported.

I. INTRODUCTION WMN (Wireless Mesh Network) using multihop communication is attracting attention as a next-generation network technology by providing high scalability and economy. The IEEE 802.11s [2] task group is active and standardization work is under way to adopt mesh networking technology to IEEE 802.11 (WLAN) standard [11]. The biggest feature of the WLAN mesh network was that the functionality was built at the MAC (Media Access Control) layer to form a mesh network, i.e., peer link management to find neighboring nodes and make network links, mesh routing to generate paths for data communication, and self-healing to the recognition of link failure and to automatically recover the routing path. Because WMN supports these features, it provides efficient routing of the MAC layer and high scalability of multihop communication. This paper focused on the development of a WLAN mesh router that forms WMN [1]. The mesh router was implemented according to IEEE 802.11s standard. In IEEE 802.11s, proactive routing algorithm and on-demand routing algorithm were defined [5]. This paper focused on on-demand routing algorithm which was based on AODV (Ad hoc on-demand distance vector routing) [7]. In IEEE 802.11s, only a single path routing algorithm was defined. So, we implemented a multipath routing algorithm that intended to reduce the recovery time and the control message overhead when the routing path was recovered from node or link failure [12]. The

"This work was supported by the Grant of the Korean Ministry of Education, Science and Technology" (The Regional Core Research Program/Institute of Logistics Information Technology) & the Grant No. B0009720 from the Regional Technology Innovation Program of the Ministry of Knowledge Economy (MKE)

978-1-61284-663-7/11/$26.00 2011 IEEE

154

ICOIN 2011

In the existing literatures, WLAN mesh router was implemented using a single-channel single-interface. In WMN, communications using a single-channel single-interface reduce the throughput because mesh routers cannot send and receive data simultaneously and also suffer from inter-flow and intraflow interferences. Accordingly, to increase the throughput, a multi-channel multi-interface is needed. In this paper, we implement WLAN mesh router that can use multi-channel, multi-interface and multipath routing. To implement multipath routing, AOMDV was used in the mesh router. AODV was the routing protocol for an ad hoc network. When data were transmitted, AODV that is the on-demand routing protocol establishes the routing path. AODV uses messages to establish the routing path, such as RREQ (Route Request), RREP (Route Reply), and RERR (Route Error). When any routing path is disconnected, RERR is used to establish an alternative routing path. The original AODV operates on the IP (Internet Protocol) layer. However, in this paper, a single path routing protocol based on AODV operating on the MAC layer was implemented in the mesh router. Types of multipath routing protocols based on AODV are AODV-BR (Backup Route) [13], AODVM (Ad hoc Ondemand Distance Vector Multipath) [14], and AOMDV. AODV-BR is a modified RREP transmission process of AODV. If the destination node sends an RREP in response to RREQ, neighbor nodes of nodes in the main routing path overhear the RREP and make themselves the nodes of secondary path. If a main routing path node cannot transmit a data packet because of a broken link, the node broadcasts the data packet to all neighbor nodes. A node that receives the data packet sends it to the next hop using secondary path information produced by the overhearing RREP. Thus, AODVBR is not a true multipath routing algorithm because nodes have just one routing path to destination. AODVM is a modified RREQ and RREP transmission process of AODV. When RREQ is transmitted to a destination, intermediate nodes store the information of all received RREQ to the RREQ table in the mesh engine. If the destination node receives a RREQ with a different previous node, the node sends RREP to the source node. The RREP is forwarded to the source node of RREQ through a path that is the reverse of the RREQ path. At this time, neighbor nodes of nodes in the main routing path generated by the RREP overhear the RREP and remove the RREQ information that received from the nodes in the main routing path from the RREQ table. When the neighbor node receives another RREP, the node sends the RREP to another node that is not in the main routing path. If the RREQ source node receives the RREP, a multipath is established. Thus, AODVM has the disadvantage that it is a complex process of generating a routing path and has just a few routing paths. AOMDV is a link-disjoint multipath routing algorithm based on AODV. When intermediate nodes receive the RREQ from the source node, the AOMDV protocol stores all RREQs, unlike in the conventional AODV protocol where duplicates are discarded. So each node maintains a firsthop_list, where information from an additional field called firsthop in RREQs indicates the neighbor node of the source nodes. If the firsthop of a received RREQ is duplicated from its own firsthop_list, the RREQ is discarded. However, if the RREQ has different firsthop, then the node stores the new next-hop information to its routing table for multiple routing paths. At the destination, RREP packets are sent from each received RREQ packet. Multiple routes are constructed from RREP packets, which

follow the reverse routes that have previously been set up over intermediate nodes. In comparison with AODV-BR and AODVM, AOMDV has some advantage. AODV-BR is not a real multipath routing algorithm. AODVM establishes multiple paths, but a path discovery process is complex. AOMDV finds more multiple paths through just single discovery. However, at present, research on AOMDV is only at the simulation level. In this paper, our multipath routing module is based on AOMDV, and actually implemented in the MAC layer of our mesh router. DESIGN AND IMPLEMENTATION OF THE MESH ROUTER In this section, the hardware and software for the implementation of the mesh router, multipath routing protocol, and multi-channel multi-interface are explained. A. Hardware and Software of the Mesh Router In this work, the mesh router was implemented using Gateworks Corporations GW2348-4 network development board [8], Embedded Linux, and the madwifi Linux device driver [9]. The GW2348-4 network development board is a high-performance embedded board mounted with the Intel XScale IXP425 533 MHz processor. The operating system was Embedded Linux (Linux 2.6 kernel). The WLAN mesh engine was implemented by modifying madwifi to support the Wi-Fi chip from Atheros Corporation for multihop communication between mesh routers. Nodes in the WLAN mesh network perform routing based on the MAC address, unlike the existing routing protocols that perform routing based on the IP address. Therefore, for implementation, we need to handle MAC frames directly. The MAC layer of the madwifi device driver was modified. The MAC frame of IEEE 802.11s was defined by extending the MAC frame of IEEE 802.11. Therefore, in this work, the device driver for the mesh router supporting IEEE 802.11s was implemented by modifying the IEEE 802.11 MAC frame of madwifi. The modified device driver manages its routing table and updates the address information of its MAC frame, when it communicates with others. III.

Figure 1. Block diagram of WLAN mesh router.

Fig. 1 is a block diagram of the WLAN mesh router, which consists of embedded Linux, the WLAN mesh engine, and other network interfaces. In addition, four wireless and two wired interfaces are mounted on the board. The WLAN mesh engine consists of a peer link management module, a selfhealing module, and a mesh routing module. The peer link management module gathers information from the surrounding nodes and forms a pair of nodes for data communication during the initial formation of the network. When the mesh router is booted, the peer link management module receives beacon frames from its neighbors and records the information to its neighbor table. The module performs peer link management with a corresponding node using the

155

neighbor information table. To establish links between each node, the module exchanges information to identify the links. The information consists of myMAC, peerMAC, local Link ID, and peer link ID; myMAC and peerMAC are both MAC addresses; local link ID and Peer Link ID are both selfgenerated random numbers. The module exchanges these pairs of information to establish links between each node. In the WLAN mesh network, the data transmission and reception path changes when a new node is added to the network, when an existing node moves to another location, and when the communication path via a particular node fails. In such situations, the self-healing module recognizes the change in the network and reestablishes the network to transmit and receive data. The self-healing module uses the HWMP. After the mesh routing module makes a routing path using RREQ and RREP to reach the destination, the next hop and the precursor node information were stored in routing table of each node. When a link is broken and a node recognize this situation, RERR is sent to the source node on the routing path using precursor node information by the node. At this time, selfhealing is triggered. The RERR packet includes information to notify that a link in the routing path was broken. A node knowing that the link was broken sends RERR to the previous node using precursor node information in routing table. The previous node that received the RERR propagates it to the source node using precursor node information. When the source node receives the RERR, the node requests a new routing path to the destination, when a secondary path doesnt exist. If the new routing path is made, self-healing is completed. In the mesh routing module, AODV of HWMP as defined in the IEEE 802.11s standard, and AOMDV which extended AODV to multipath routing were implemented. When the current routing path was broken, AODV must establish a new routing path. However, when the routing path was established, AOMDV generated multipath. Therefore, when the current routing path was broken, AOMDV replaced immediately the broken path to the pregenerated path. AOMDV has smaller routing overhead than other multipath routing algorithms and allows recovery of the routing path faster than AODV. When all pregenerated paths were broken, AOMDV established a new routing path. B. Implementation of the Multipath Routing Protocol

node and broadcasts the RREQ to the neighbor nodes. Node 6 transmits RREP responding for RREQ. RREP was transmitted on the reverse path for RREQ. Intermediate nodes that received the RREP store next-hop information to communicate with node 6 to the mesh the routing table. If node 1 receives the RREP, the routing path between node 1 and node 6 would be established.
RREQ is received. Its Dest is Me. Yes It is Not Duplicate. Yes Record Next-hop for its source. Send RREP to its source. No No I am neighbor node of its source Yes Pre-Node is Different. Yes Record new Nexthop for its source. Send new RREP to its source. Drop. Store my ID to its firsthop field. Record it to the RREQ table. Broadcast it to others. No Record its firsthop in my firsthop_list. Record it to the RREQ table. It is Duplicate. Yes Done. Drop. No Record Next-hop for its source. No There isnt its firsthop in my firsthop_list. Yes Record Next-hop for its source. No

Record it to the RREQ table.

Figure 3. Flowchart for handling RREQ of AOMDV.

In this paper, we implemented a multipath algorithm based on AOMDV. As shown in Fig. 3, if a node receives RREQ, the node checks whether the destination of the RREQ is the current node or not. If the destination is the current node, it checks whether the RREQ is a duplicate or not. If it is a non-duplicate packet, the node records the next-hop information in the routing table and send RREP packet to the source node of RREQ. If it is a duplicate, the node checks the precursor node of the RREQ. If the RREQ has another precursor node, the node records new next-hop information for its source and then sends new RREP to the source of the RREQ. Otherwise, the node discards the RREQ. On the other hand, if the current node is not the destination and there is the firsthop of the RREQ in its firsthop_list, the RREQ is discarded. Each node maintains a firsthop_list that is generated from an additional field called firsthop in RREQs; the firsthop indicates the neighbor node of the source node. However, if the RREQ has new firsthop, then the node stores new next-hop information to its routing table for multiple routing paths and stores new firsthop to its firsthop_list. And then the node checks whether the RREQ is a duplicate or not. If it is a duplicate packet, the node discards the RREQ. Otherwise, the node broadcasts the RREQ to other nodes. In this way, the nodes can generate multiple paths for the source node of RREQ.
RREP is received. Its Dest is Not Me. Yes It is first RREP . Yes Record Next-hop for its source. Forward to Next-hop for its Dest. No There is another Next-hop for its Dest. Yes Record another Nexthop for its source. Forward to another Next-hop for its Dest. Drop. No No Record all Nexthop for its source.

Figure 2. Process to establish a routing path of AODV.

In a mesh network using AODV, a node establishes a routing path to communicate with other nodes using RREQ and RREP. As shown in Fig. 2, node 1 sends RREQ to node 6 to establish a routing path between nodes 1 and 6. At this time, RREQ is broadcasted. Intermediate nodes that receive the RREQ store the next-hop information to communicate with node 1 in the mesh routing table; AODV does not store information for the entire routing path, it just stores the nexthop information for communication with the corresponding

Done.

Figure 4. Flowchart for handling RREP of AOMDV.

156

As shown in Fig. 4, if a node receives RREP, the node checks whether the destination of the RREP is the current node or not. If the current node is not the destination, it checks whether the received packet is a duplicate or not. If it is a first RREP, the node records the next-hop information in the routing table and forwards RREP to its destination node. If it is a duplicate, the node checks whether there is other next-hop information in its routing table or not. If yes, the node records new next-hop information for source of the RREP and then forwards the RREP to the other next-hop for its destination node. Otherwise, the node discards the packet. On the other hand, if the destination is the current node, it stores the nexthop information to its routing table. In this way, the nodes can generate multiple paths for the source node of RREP. In summary, when a node deals with a RREQ, AOMDV stores next-hop information for sources of RREQs that have different previous node or firsthop information, unlike in the AODV where duplicates are discarded. When a node handles a RREP, AOMDV sends multiple RREPs for RREQs that have different previous node, unlike in the AODV protocol where just one RREP are sent for RREQs. So, AOMDV has multiple routing paths through just one path discovery process. C. Implementation of the Multi-channel Multi-interface Structure

coming from the NAT (Network Address Translation) module. If any of the mesh interfaces has the corresponding routing information for the packet, the latter is passed to the mesh interface (F.6-1). Otherwise, the mesh bonding module sends a command to all mesh interfaces to create a route for the packet. After creating the route, the packet is passed to that interface (F.6-2). Besides, the mesh bonding module can pass packets coming from the mesh interfaces to the NAT module (F.6-3).
If( From_NAT) Then If(Search_R_table(dest_MAC)) Then Interface = Find(dest_MAC) Send_To(Interface, packet) Else For (All_mesh_engine) Send_CMD_for_Find_Route(dest_MAC) End For Interface = Find(dest_MAC) Send_To(Interface, packet) End If Else Send_To(NAT, packet) End If F.6-1

F.6-2

F.6-3

Figure 6. Operating algorithm of the mesh bonding module.

Figure 5. Software configuration of a multi-interface mesh router.

In a multihop environment, communications using a single-interface reduce throughput because mesh routers cannot send and receive data simultaneously and also suffer from interflow and intraflow interferences. Accordingly, to increase throughput, a multi-channel multi-interface is needed. Fig. 5 depicts the software configuration of the multi-interface mesh router. In Fig. 5, the Linux DHCP (dynamic host configuration protocol) operating on embedded Linux can automatically assign an IP address to the client node connected to the AP interface. The client node can communicate with another node using a private IP address assigned by the Linux DHCP software. The AP interface uses the AP software implemented in madwifi. It has an access control function for clients to connect to MAP and an authentication control to permit access only to authorized clients. The mesh bonding module on the Linux kernel allows representing mesh interfaces by one IP address, if there is more than one network interface. It enables data communication between the AP and the mesh interfaces, and it allows communication between clients connected with different mesh routers. Fig. 6 presents the algorithm of the mesh bonding module. This module decides the destination of a packet

If( From_AP(packet)) Then If(Here_is_Dest(dest_IP)) Then Send_To(TCP_IP, packet) Else Save_Info_To_NAT_table(packet) Send_To(Bonding, packet) End If Else If(From_Bonding(packet)) Then Dest_Info = Search_NAT_table(packet) If(Dest_Info == this_node) Then Send_To(TCP_IP, packet) Else Change_Dest_IP(packet, Dest_Info) Send_To(AP, packet) End If Else If(Dest_IP_is_Private_IP(packet)) Then Send_To(AP, packet) Else Send_To(Bonding, packet) End If End If
Figure 7. NAT Module operating algorithm

F.7-1 F.7-2

F.7-3

F.7-4

The NAT module implemented in the Linux kernel has the ability to provide communication between the mesh bonding module and the AP interface. Fig. 7 shows algorithm of the NAT module. This module decides the destination of a packet coming from the AP interface. If the current router is the destination, the packet is passed to the TCP/IP stack (F.7-1). Otherwise, the module stores to the NAT table the source IP address and connecting information between the external node and a client node of the AP interface contained in the packet, and then passes the packet to the mesh bonding module (F.7-2). In addition, the NAT module decides the destination of a

157

packet coming from the mesh bonding module using the information in the NAT table. If the current router is the destination, then the packet is passed to the TCP/IP stack. In contrast, if the destination is the AP interface, the module changes the destination IP address using the information in the NAT table and passes the packet to the AP interface (F.7-3). Furthermore, the NAT module can decide the destination module of a packet coming from the TCP/IP stack and send the packet to the proper destination module (F.7-4). Furthermore, if the mesh interface receives a data packet, it checks its MAC address, and if it is the MAC address of the mesh bonding module of this mesh router, the mesh interface passes the packet to the mesh bonding module. Otherwise, the mesh interface passes the packet to other mesh interfaces using the information in the MAC routing table in the mesh router. Using these modules, the mesh router supports multichannel multi-interface communication. Port forwarding is used for communication between clients connected with the mesh routers. The basic port forwarding module of the Linux kernel is used for this purpose, but it should be set up for all mesh routers connected with clients. We solved this problem by using Global DHCP to make a single subnet. IV. TEST BED USING MESH ROUTER All of our experiments were conducted in the sports complex of Pusan National University Campus. We used mesh routers in our test bed for making a wireless Internet environment that supports a real-time streaming service using an IP camera. A. Test Bed A total of 12 mesh routers were used in the test bed, each with four wireless interfaces with a data rate of 54 Mbps and a frequency band of 5 GHz. All mesh routers communicated with each other using directional antennas. All data packets for Internet service were sent out with a data rate of 100 Mbps through the wired interface of the gateway node, which was installed in the research center in our university. The maximum distance between routers using the directional antenna was approximately 140 m. B. Bandwidth and Latency Bandwidths from one to five hops were measured via the AP interface. We used Iperf [10], a network-testing tool, to measure bandwidth. For performance measurements, notebook computers were used as server and client. Table 1 shows the measured bandwidth and latency of our test bed from one to five hops. We used TCP to measure bandwidth and ICMP (Internet Control Message Protocol) to measure latency. To communicate between the mesh routers, IEEE 802.11a was used in the mesh network. The maximum bandwidth of the IEEE 802.11a physical layer is 54 Mbps. However, generally, when a network-testing tool such as Iperf is used to measure performance, the maximum bandwidth is actually in the range of 2730 Mbps.
TABLE I. TCP Bandwidth (Mbps) Latency (ms) TCP BANDWIDTH AND LATENCY IN TEST BED
1-Hop 2-Hop 3-Hop 4-Hop 5-Hop

hops. The bandwidth for one hop is not different from that in a typical WLAN connection. A video of 30 fps using VGA of 640 480 size, and compressed by MPEG-4 typically requires a bandwidth of about 4 Mbps. The test bed could service video streaming of VGA size in five hops. Despite the five hops, the delay was 2.4 ms, which is very small. Therefore, it can be applied to an application requiring faster response time. Table 2 shows the UDP bandwidth in the test bed. As shown in the Table, the average UDP bandwidth was 28.6 Mbps for communications via multihop. The loss rate of the UDP data packet increased with the hop count, because the number of links that the data packets go through increased. However, the bandwidth was stable regardless of the hop count because UDP is based on the send-and-forget approach.
TABLE II. UDP Bandwidth (Mbps) Loss Rate (%) UDP BANDWIDTH AND PACKET LOSS RATE IN TEST BED
1-Hop 2-Hop 3-Hop 4-Hop 5-Hop

28.7 0.0006

28.5 0.0006

28.2 0.0047

28.8 0.0061

28.6 0.033

Table 3 shows the measured average jitter when the data transmission rate changes from 1 to 8 Mbps. Iperf was used in this experiment. As shown in Table 3, despite the five hops the average jitter value was small, 0.547 ms, when the data bandwidth was 1~8 Mbps. Therefore, this test bed supports any application for real-time stream services.
TABLE III. Bandwidth Jitter (ms) THE AVERAGE JITTER VALUE IN 5 HOPS
1Mbps 2Mbps 4Mbps 8Mbps

0.466

0.524

0.651

0.643

C. Multipath routing experiments The network topology of the test bed was reformed for multipath routing performance tests (Fig. 8).
Destination Mesh Router

Primar y Path Secondar y Path

Source

Figure 8. Network topology of the test bed used for the multipath routing algorithm experiment.

27.7 1.2

27.1 1.5

25.2 1.8

24.7 2.2

23.8 2.4

As shown in Table 1, the average TCP bandwidth was 27.7 Mbps for communications via one hop and 23.8 Mbps in five

Performances of the single path and multipath routing algorithms were compared by message overhead for establishing the routing path after path recovery and by the delay for path recovery. For the single path routing algorithm, when any link was broken, nodes that recognized link failure sent and received messages that were used to construct a new routing path. However, with the multipath routing algorithm, when the routing path was at first established, a multipath was

158

generated. Thus, if some path was broken, the path was immediately replaced by the preconstructed alternative path. Therefore, there was a gap between message overheads of single path and multipath routing algorithms. Fig. 9 shows the differences between message overheads of single path and multipath routing algorithms for constructing a new routing path when one was broken. The message overhead to establish a new routing path was accumulated from constructing routing paths at first to three times of link failures.
60 m e s s a g e s 50 40 30 20 10 0 After making route After firsterror Afterseconderror Single pathrouting Multipath routing

standard. Because the mesh router used the multipath routing algorithm, it had a 12.73% shorter path recovery time and the smaller control message overhead than using the single path routing algorithm when the routing path was recovered from node or link failure, in outdoor test bed. The average TCP bandwidth of the mesh router was 27.7 Mbps for communications via one hop and 23.8 Mbps via five hops. The end-to-end delay was 2.4 ms. The average UDP bandwidth of the mesh router was 28.6 Mbps constantly, but the packet loss rate for UDP increased slightly by increasing the hop count. The mesh router jitter was 0.547 ms on average when the transmission data rate was from 1 to 8 Mbps. The mesh router could provide a VGA-size real-time video streaming service with five hops. REFERENCES
[1] [2] [3] I.F. Akyildiz, X. Wang and W. Wang, Wireless mesh networks: a survey, Computer Networks and ISDN Systems, Volume 47, Issue 4, Page(s): 445487, Mar. 2005. IEEE, Draft amendment for mesh networking, IEEE 802.11s Draft 1.06, Jul. 2007. Torregoza, J.P.M. and Won-Joo Hwang, Multi-channel MultiTransceiver Routing Protocol for Wireless Mesh Network, Advanced Communication Technology, The 9th International Conference, Volume 1, 1214 Feb. 2007 Page(s): 488. Shrestha, D.M. and Young-Bae Ko, Enhanced Topology Formation Protocol for IEEE 802.11 WLAN based Mesh Networks, Communication Systems Software and Middleware, COMSWARE 2007. 2nd International Conference, 712 Jan. 2007 Page(s): 15. Won-Ju Yoon, Sang-Hwa Chung, Seong-Joon Lee and Yun-Sung Lee, An Efficient Cooperation of On-demand and Proactive Modes in Hybrid Wireless Mesh Protocol, The 33rd IEEE Conference on Local Computer Networks, pp. 5257, Montreal, Canada, Oct. 2008. Faccin, S.M., Wijting, C., Kenckt, J. and Damle, A., Mesh WLAN networks: concept and system design, Wireless Communications, IEEE Volume 13, Issue 2, April 2006 Page(s): 1017. C.E. Perkins, E.M. Belding-Royer and S. Das, Ad hoc on demand distance vector (AODV) routing, IETF RFC 3561, July 2003. Gateworks GW2348-4 [Online] Available: http://www.gateworks.com/products/avila/gw2348-4.php Madwifi [Online] Available: http://www.madwifi.org/ Iperf [Online] Available: http://sourceforge.net/projects/iperf IEEE, IEEE Standard for Information technology-Telecommunications and information exchange between systems-Local and metropolitan area networks-Specific requirements, IEEE 802.11-2007 S. Mueller, R. P. Tsang and D. Ghosal, Multipath Routing in Mobile Ad Hoc Networks: Issues and Challenges, In Performance Tools and Applications to Networked Systems, Vol. 2965 of LNCS, 2004 S. J. Lee and M. Gerla, AODV-BR: Backup Routing in Ad hoc Networks, IEEE Wireless Communications and Networking Conference, September 2000 Z. Ye, S. V. Krishnamurthy and S. K. Tripathi, A Framework for Reliable Routing in Mobile Ad Hoc Networks, INFOCOM 2003. Twenty-Second Annual Joint Conference of the IEEE Computer and Communications Societies. IEEE, vol. 1, 2003, pp. 270-280 M. K. Marina, S. R. Das, "On-demand Multipath Distance Vector Routing in Ad Hoc Networks, Proceedings of the 9th International Conference on Network Protocols, pp 14-23, November 2001 S. Adibi and S. Erfani, A Multipath Routing Survey for Mobile AdHoc Networks, Consumer Communications and Networking Conference, 2006 MIT Roofnet [Online] http://pdos.csail.mit.edu/roofnet/doku.php Heecheol Song, Bong Chan Kim, Jae Young Lee and Hwang Soo Lee, IEEE 802.11-based Wireless Mesh Network Testbed, IST Mobile and Wireless Communications Summit, 2007

Figure 9. Message overhead comparison for multipath and single path routing algorithm.

The single path routing algorithm transmits a message to establish a new routing path when a routing path is broken. Thus, as shown in Fig. 9, messages to establish a new routing path increased consistently. However, the multipath routing algorithm does not transmit a message to establish a new routing path when a routing path is broken. Therefore, until a first link failure occurs, messages to establish a new routing path have not changed. This way, using a multipath routing algorithm allows decrease of message overheads for constructing a routing path. However, with the multipath routing algorithm, if a second link failure occurs, the node transmits routing messages. The reason is as follows. As shown in Fig. 9, AOMDV can generate just two routing paths. Therefore, if links fail two times, AOMDV transmits routing messages to establish new routing paths. The multipath routing algorithm initially has more routing messages, because it sends more RREPs to establish a multi-routing path than for a single path routing algorithm. The difference in recovery time is as follows. The time delay that recognized a link failure was 237 ms on average when the beacon interval of the mesh router was 100 ms. When a link failed, the average time delay to establish a new routing path using a single path routing algorithm was 30.3 ms. With a multipath routing algorithm, when a link was broken the node immediately used an alternative routing path. Therefore, the difference in time delay between the single path and multipath routing algorithms was 30.3 ms. The time delay of path recovery sums up the time delays of recognizing link failure and constructing an alternative routing path. Thus, the multipath routing algorithm has a shorter path recovery time by 12.73% than a single path routing algorithm. V. CONCLUSION This paper focuses on the development of an IEEE 802.11s-based WLAN mesh router, which can support a multichannel multi-interface. In this work, we implemented not only the single path routing based AODV defined in IEEE 802.11s HWMP, but also a multipath routing which extended the

[4]

[5]

[6] [7] [8] [9] [10] [11] [12] [13] [14]

[15] [16] [17] [18]

159