Impact of Wireless Mesh Networks in Real-time Test-bed Setup

Abstract

Wireless mesh networks (WMNs) is a new emerging technology in wireless networks. WMNs are flexible, cost -effective and light infrastructure based wireless technology. The IEEE has set off the task group for 802.11s to reconcile about the WMNs development. The WMNS draft still far from its final version but major characteristic are defined and work is still in progress. Many researchers had done their wireless mesh network experiments through simulations. The simulation results and real world implementation results have big differences. In this paper, we have set up the testbed in our lab. We have used some different windows size for TCP and UDP transmission and analyze those throughput results.

Full text

Impact of Wireless Mesh Networks in Real-time Test-bed Setup
1Madhusudan Singh, 2Sang-Gon Lee, 3Whye Kit Tan, 4Jun Huy Lam
1, First Author Dept. of Ubiquitous IT, Division of Computer & Information Engineering,
Dongseo University, Busan, Korea, sonu.dsu@gmail.com
*2,Corresponding Author Division of Computer & Information Engineering, Dongseo University,
Busan, Korea, nok60@dsu.ac.kr
3Dept. of Ubiquitous IT, Division of Computer & Information Engineering, Dongseo
University, Busan, Korea, whyekit.tan@gmail.com
4Dept. of Ubiquitous IT, Division of Computer & Information Engineering, Dongseo
University, Busan, Korea, timljh@gmail.com
Abstract
Wireless mesh networks (WMNs) is a new emerging technology in wireless networks. WMNs are
flexible, cost –effective and light infrastructure based wireless technology. The IEEE has set off the
task group for 802.11s to reconcile about the WMNs development. The WMNS draft still far from its
final version but major characteristic are defined and work is still in progress. Many researchers had
done their wireless mesh network experiments through simulations. The simulation results and real
world implementation results have big differences. In this paper, we have set up the testbed in our lab.
We have used some different windows size for TCP and UDP transmission and analyze those
throughput results.
Keywords: IEEE802.11s, HWMP, Test-bed, Throughput Analysis.
1. Introduction
Researches had been conducted for wireless network field to provide a better service for its users. In
this field, wireless mesh network seems to be one of the favorite topics of discussion due to its ad-hoc
feature. WMNs have combined both mobile and ad-hoc characteristic (multi-hop dynamic routing and
dynamic self organization) to form a reliable Wireless Local Area Network (WLAN) [1]. WMNs nodes
can be divided into mesh portal (MP), mesh access points (MAP) and station based on their
functionality. Mesh portal acts as a portal to allow members of the WMN to access other network
(usually the wired LAN or internet) [2]. Mesh points are stations provided with the mesh functionality
and able to act as access points for the legacy stations to connect to the WMN.
Researchers had been using network simulator to evaluate the performance of WMN. However, we
believe that simulation results might not reflect the true performance of a WMN. Different results had
been observed between researches involving tests based on simulation and real implementation [3].
Therefore, a testbed had been set up according to the current IEEE 802.11s draft 4.0 to evaluate the
performance of the WMN protocol. This paper has organized as follows, in section 2 we discussed
about IEEE 802.11s Draft 4.0. In section 3 are defined the features of our test-bed. In section 4 we
mentioned performance analysis for TCP and UDP, and in section 5 we conclude our work.
2. Overview of IEEE802.11s draft 4.0
In this section, we discuss an overview of the IEEE 802.11s features. Our implementation is based
on the unofficial draft 4.0 for the IEEE802.11s [4], which is available during our implementation. The
general architecture of IEEE802.11s and major protocols are same as the previous draft. Though, some
names and features have been slightly changed in the draft 4.0.
Impact of Wireless Mesh Networks in Real-time Test-bed Setup
Madhusudan Singh, Sang-Gon Lee, Whye Kit Tan, Jun Huy Lam
Advances in information Sciences and Service Sciences(AISS)
Volume3, Number9, October 2011
doi : 10.4156/AISS.vol3.issue9.4
25

2.1. Mesh architecture
In wireless mesh network, mesh stations are the members of the network. Mesh stations must be able
to play many roles in the network such as portal, access point, and simple mesh point. A Mesh Portal
(MP) is usually connected through wired connection to another network and thus, mesh stations
connected to this MP can access another network through it. Each network can have one or more MP
and the network will select its MP based on the member connectivity [5]. Legacy stations without
802.11s support can still connect to the WMN. In such situation, mesh stations will act as Mesh Access
Point (MAP) and so that the legacy stations can connect to the WMN just like connecting to a normal
access point. Legacy stations are not aware of the mesh features and the MAP will works as a proxy for
it [6]. The architecture of mesh software is shown in Figure 1.
User Interface
Mesh Software
Proc File Linux Bridge
AP
VAP Wds
VAP Wds
VAP Monitor
VAP Monitor
VAP Measures
User Space API API
Kernel Place
MADWifi
Driver
Client Access Mesh Backbone
(Data Frame) Mesh Management Frames
Ebtables
Figure 1. Architecture of mesh software
The draft 4.0 has many updates that deal with management of mesh services and algorithm. Some of
the updates mentioned about extended and modified frame format for the management and data frames
[4~6]. Both frames hold a Mesh Header, which can carry 4 or 16 bytes data field. In draft, the frame
format includes a set of fields that occur in fixed order in every frame. The first 3 frame fields (control,
duration/ID, and Address1) and the last fields comprise the minimal frame format and are present in
every frame, including reserved types and subtypes [7]. The fields’ address 2, address 3, sequence
control, address 4, QoS control, and frame body are present in certain frame types and subtypes. Frame
format has a very long description thus the detailed information can be obtained from the reference [4,
8].
2.2. Path selection: Hybrid Wireless Mesh Network (HWMP)
The HWMP is default path selection algorithm for wireless mesh network. HWMP is implemented
on every mesh stations that support IEEE802.11s [4~6]. The HWMP is a combination of reactive and
proactive routing protocol. The HWMP holds flexibility of on demand route discovery with option for
efficient proactive routing to a mesh portal. The On-demand service is based on Radio Metric (RM)
AODV without relying on the root; RM-AODV is used to discover direct end-to-end routes in the
network. Proactive routing on the other hand discovers routes between every nodes and the root. It
reduces unnecessary route discovery flooding [9, 10]. Normally, the mesh portal (MP) will be chosen as
the root. We have defined HWMP in below.
In the proactive mode, the MPs communicate with each other with the help of the root and the tree
topology will be built by using either the path request (PREQ) or root announcement (RANN)
mechanism. PREQ message will be broadcasted by the root MP or root mesh portal to create the paths
between the root MP and all the other MPs in the WMN while RANN message distributes the routing
Impact of Wireless Mesh Networks in Real-time Test-bed Setup
Madhusudan Singh, Sang-Gon Lee, Whye Kit Tan, Jun Huy Lam
26

information to reach the root MP. The tree will then be created and maintained for all the MPs in the
WMN to reach the root MP as it contains the information of the tree topology formed.
In the reactive mode, it allows the MPs to communicate with each other through the on-demand path
and no root configured or required. If there is no root MP available in the WMN, the WMN will be able
to operate on the reactive alone as well. The RREQ message will be broadcasted by the MP as the route
discovery process begins if it needs a path to its destination MP and the destination MP is not in its
routing table [10]. The received PREQ message will be used to create a path to the source or updates
the path if the RREQ consists of the same or greater sequence number with improved metric. The
destination MP or any intermediate node that is connected to the destination MP will respond to the
PREQ with a unicast path reply (PREP) message. However, there is an initial latency for the path
formation until the first data packet received by the MP that initiated the route discovery process.
A root portal is required in order for the system to operate in the hybrid mode. Since the root portal
has the information of all MPs in the WMN when the registration mode is used, it can fasten the route
discovery process by forwarding the data frames to the MP that wants to form a path with the other MP
that is in the same WMN. This information was sent to the requesting MP along with the signal that
these 2 MPs are in the same WMN and hence, a route discovery will be initiated and the optimal path
between these 2 MPs were formed. This hybrid mode improves the conventional reactive mode with the
information obtained from the proactive mode. The initial latency in the path settings is then eliminated.
In order to find the best path for the routes formation, the link cost for each link in the WMN had to
be computed. The link with the lowest metric value will be the chosen path for the transmission of the
data. This metric value can be found in the metric field of the PREQ, PREP and RANN messages, and
will be propagated to build or update the path. In IEEE 802.11s, the airtime link metric was defined as
the default link metric computation method for the path selection. This airtime link metric is a radio-
aware routing metric. By transmitting the frame over the particular wireless link, it is able to measure
the amount of channel resources consumed [4~6].
Root
12
3 D
S
Reactive Route
Proactive Route
4
Figure 3. HWMP routing
In Figure 3 root is a mesh portal. Root has path information for every node. Node S is source node
and node D is destination node. Node S send PREQ message to root and root provide the path for final
destination D with help of proactive routing. Once path has find between source to destination after that
destination send PREP with help of reactive routing. This is HWMP routing for wireless mesh network.
3. Test-bed implementation
In this section we defined the specification of our test-bed things. For our testbed experiment, we
have used Ubuntu Linux with kernel 2.6 based PCs and Multiband Atheros Driver for Wi-Fi
(MADWIFI) [11] diver for virtual access point (VAP) creation. The VAP has been created for the
operating system as different wireless interface. Moreover every VAP can be made for different mode.
The MADWIFI driver creates VAP interfaces for Linux Bridge. That bridge works same as hardware
bridge. The port of the bridge is communicated with each AP and wds, and those bridges forwards the
frames between interfaces according to the destination MAC address. The implementation specification
is described below.
Impact of Wireless Mesh Networks in Real-time Test-bed Setup
Madhusudan Singh, Sang-Gon Lee, Whye Kit Tan, Jun Huy Lam
27

 Hardware specifications
o Mesh Portal & Mesh Access Points
 Wireless NIC: Atheros communications Inc. AR5413 802.11abg.
 Wired NIC: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI
Express Gigabit Ethernet.
 Wireless NIC: Atheros AR9285 Wireless Network Adapter (Mobile
Station).
 Software Specifications
o Mesh Portal and Mesh Access Points
 OS: Ubuntu version 10.04.2, kernel 2.6.32-31-generic.
 Driver: Madwifi, ath_pci.
 Measuring Tool: Jperf (Jperf is a graphical user interface using Iperf,
which allows us to calculate the throughput results) [12].
o Mobile Station
 OS: Fedora14.
 NIC driver: ath9k.
3.1. Network topology
Every the stations had been placed in the same room without any physical separation. Only the mesh
portal is connected to the wired LAN. We had made a simple test with 4 PCs having the mesh features
and two laptops act as the legacy stations without mesh features (Figure 4). One of the PCs was set as
the mesh portal (MP), three other PCs as mesh access point (MAP) and the laptops as mobile stations.
MAC 74:F0:6D:31:23:A6
IP 192.168.1.25
Mobile2 (Station)
MAC 00:24:73:1E:EB:3F
IP 192.168.1.16
MAP A (MESH 2)
MAC 00:24:73:1E:D7:6D
IP 192.168.1.5
MAP B (MESH 3)
MAC 00:24:73:1E:D7:BD
IP 192.168.1.1
Mesh Portal
(MESH1)
ETHERNET
MAC 00:24:73:1E:D6:4D
IP 192.168.1.10
MAP C (MESH 4)
WIRELESS
MESH
NETWORK
Router
MAC 74:F0:6D:32:1B:1F
IP 192.168.1.30
Mobile1 (Station)
Figure 4. Test bed wireless mesh network
3.2. Frame format
The front part of the frame is similar to normal IEEE 802.11 frame header format. The information is
injected to the last part of the frame. The information is structured with the task structure thus the data
contained in the frame is different according to the function of the frame. For more details information
about frame format, we can find in reference [4, 13]. The frame segment is shown in Table 1.
Table 1. Mesh frame format
802.11 Header
Category
Action
Task Information
When these dummy frames are detected, the mesh software will interpret the frame information and
move it into the action queue according to the task. The operation is shown by the help of flow chart in
Figure 5. Normal beacon frames from neighboring MAP will be used to list up available MAPs.
Impact of Wireless Mesh Networks in Real-time Test-bed Setup
Madhusudan Singh, Sang-Gon Lee, Whye Kit Tan, Jun Huy Lam
28

Frame Detected
Parsed with data
structure
Destination MAC ?
Type ?
Flush buffer
Read Task
Information
Insert Task
Neighbors
Detect all MAP
in range
MAC=! My MAC
MAC=! Broadcast
Extended Beacon
Figure 5. Flow chart of frame format processing
3.3. Routing process
Once the mesh software is started, mesh portal will start to form the tree for the mesh network. The
tree is formed based on the metric value or the radio quality of each link. Since the mobile station is not
part of the mesh network, it was identified as a proxy station connected to the mesh access point. The
mesh portal gains information about the path metric by broadcasting the path request frames to every
mesh access points within the mesh network. Every the MAPs will then reply to the request and paths
between the stations and the portal are formed.
The reactive routing is triggered by the mesh software after the proactive tree is formed, so that the
path formation can be observed. The formation of reactive paths for this test is very similar to the
formation of proactive paths. Path request frames will be unicast to every MAP that it can detect and the
MAPs will reply to the request.
4. Performance analysis
In this part, we discussed an example of our experiment. In our experiment, we used 4 PCs with
mesh features as MP and 2 laptops (non mesh) as station. Each system has been assigned a unique name,
and IP address. Every system has its own MAC address. Testbed layout is shown in Figure 4.
We have used a mesh portal (Mesh1), three mesh points (Mesh2, Mesh3 & Mesh4), and two mobile
stations (Mobile1 and Mobile2) during experiment. The root (Mesh1) create tree which have path to
mesh nodes (Mesh1- Mesh2- Mobile1, Mesh1-Mesh4-Mobile2 and Mesh1-Mesh3). Mesh nodes need
to know MAC address of Mobile1 and Mobile2 to setup a path between them. The Mesh2 broadcasts
PREQ, which received by Mesh4. Mesh4 unicasts PREQ to final destination via MP. The Mobile1 has
sent message frame to Mesh2 which forwards to Mesh1. Mesh1 has information about every mesh
nodes of the network and replies to destination MAC address. This path information is stored in every
intermediate node which is involved in the path. Now source node has path information for destination,
it can be start the communication with defined path. We can see the nodes IP address and MAC address
in Table 2.
Table 2. Computer information (ID, IP Address, MAC Address)
Name
IP Address
MAC Address
Mesh 1 (MP)
192.168.1.1
00:24:73:1E:D7:BD
Mesh 2 (MAP A)
192.168.1.16
00:24:73:1E:EB:3F
Mesh 3 (MAP B)
192.168.1.5
00:24:73:1E:D6:6D
Mesh 4 (MAP C)
192.168.1.10
00:24:73:1E:D7:4D
Mobile 1 (Station)
192.168.1.30
74:F0:6D:32:1B:1F
Mobile 2 (Station)
192.168.1.25
74:F0:6D:31:23:A6
Impact of Wireless Mesh Networks in Real-time Test-bed Setup
Madhusudan Singh, Sang-Gon Lee, Whye Kit Tan, Jun Huy Lam
29

4.1. TCP throughput analysis
The experiment has been done according to the experimental scenario described below. First, we
have made settings and parameters for TCP test. The experiment has been initialized with a simple TCP
test. We have done 5 trials for TCP protocol transmission. The information of the test is shown in Table
3. Table 3. Parameters for TCP experiment
Transport Protocol
TCP
Number of Trails
6
Buffer Length
2Mbytes
Max segment Size
1 kbytes
Total transmission time
100 sec.
Interval
10 sec.
Transport Protocol
TCP
Number of Trails
6
We have done 5 trials of TCP transmission with different window size. We have set 2 Mbytes for the
buffer length in experiment. Length of buffer is set for the bandwidth read and write. By default it used
8 KB for TCP. We can also set the window size for TCP experiment. The window size is socket buffer
size to the specified value in TCP transmission. We have used different window size for every
experiment. For window size, we used 5 different values such as 16 kbytes, 32 kbytes, 128 kbytes, 128
kbytes, and 256 kbytes. We have reported TCP maximum segment size (MSS) and the observed sizes
which often correlate with the MSS. The MSS is usually the maximum transmission unit (MTU)
including 40 bytes for the TCP/IP header. This option is not implemented on many OS, but sizes may
still indicate the MSS. We have set the MSS 1 kbytes in our experiment. Above described information,
we had used for the Jperf [12] during our experiment.
We have run our transmission 100 second of each trial and set 10 second interval time between
periodic bandwidth.
Table 4. Throughput results of TCP transmission
Window size
(kbytes)
Bandwidth
(kbits/sec)
Data transfer (Kbytes)
16
2319
28352
32
3224
39368
64
3819
46616
128
5677
69312
256
3620
44272
In table 4 we can see the average throughput results of the every 5 different window sizes. We can
see the easily variation of throughput between different window size. In Figure 7 we can see that, the
window size 128 kbytes throughput is better than that of other window sizes. In Figure 8 we can see the
amount of the data transfer at the window size of 128 kbytes is larger than that of other window sizes.
Impact of Wireless Mesh Networks in Real-time Test-bed Setup
Madhusudan Singh, Sang-Gon Lee, Whye Kit Tan, Jun Huy Lam
30

Figure 7. TCP throughput result of bandwidth on different window size
4.2. UDP throughput analysis
The UDP bandwidth has been defined to 200 kbits/sec at the client side. Thus the client will
constantly send out data frames at the stated speed. For experiment we have used 10 datagram sizes
(100 bytes, 200 bytes, 300 bytes, 400 bytes, 500 bytes, 1000 bytes, 1500 bytes, 2000 bytes, 2500 bytes
and 3000 bytes). We have defined the common buffer size for experiment is 41 kbytes. The buffer size
is the just buffer which packets are received in, and limits the maximum receivable data packets size.
We have fixed 10 common transmission times for every trails. We did every packet size test to 3 times
trails. In table 5 is shown average throughput result of different packet size after experiment. UDP test
parameter settings are shown in Table 5.
Table 5. Parameters for UDP transmission
Transport Protocol
UDP
UDP Bandwidth
200 kbps
Buffer size
41 kbytes
Number of data transmission for each trail
10
Number of trails
3
In our experiment, we have fixed the bandwidth up to 200 kbits/s. We used two different data
packets for experiment. In the 1st data packets, we have used 100 bytes to 500 bytes datagram. Where
each datagram has 100 bytes differences between 100 byte to 500 bytes such as 100 bytes, 200 bytes,
300 bytes, 400 bytes, and 500 bytes datagram packets. In the 2nd datagram packets, we have used 500
bytes to 3000 bytes datagram. Where each datagram differences is 500 bytes such as 500 bytes, 1000
bytes, 1500 bytes, 2000 bytes, 2500 bytes and 3000 bytes. In the result 100 to 400 bytes datagram
packets used nearly at fixed bandwidth (200 Kbits/s) but 500~3000 bytes datagram has many
differences that of. In our experiment results shows that, 100 bytes to 500 bytes datagram have large
data transmission and data loss ratio is less but 500 bytes to 3000 bytes data packets have less data
transmission and large amount of data loss.
In Table 6 is shown data loss ratio of the each transmission. In the 100~500 bytes datagram packets
have number of frames 25001, 12051, 8335, 6251, 500 and 500~3000 bytes datagram packets have
numbers are frames 2501, 1668, 1251, 1001, 835. Those are less than 100~500 bytes datagram packets.
There we found, 100~500 bytes datagram packets data loss ratio is less than 500~3000 bytes datagram
packets. In the 100~500 bytes datagram packets has less than 5.45% data loss and in the 500~3000
bytes data loss ratio is more than that of. It has inconsistence data loss ratio. So we can say that, the
performance of the network depends on the frame size.
In Figure 9 is shown average throughput of different datagram packets of UDP. In table 6 is shown
the throughput of UDP transmission.
Impact of Wireless Mesh Networks in Real-time Test-bed Setup
Madhusudan Singh, Sang-Gon Lee, Whye Kit Tan, Jun Huy Lam
31

Table 6. Throughput results of UDP transmission
Datagram size
(bytes)
Bandwidth
(Kbits/sec)
Jitters
(ms)
Data Loss Rate
(Loss/Total)
100
196
0.805
492/25001 (1.96%)
200
198
1.158
125/12501(0.99%)
300
196
0.338
168/8335 (2.01%)
400
193
0.906
224/6251 (3.58%)
500
187
15.659
273/5001 (5.45%)
1000
172
25.525
327/2501 (13.07%)
1500
185
9.365
122/1668 (7.31%)
2000
163
37.998
228/ 1251 (18.22%)
2500
183
21.084
83/1001 (8.29%)
3000
192
7.702
34/835 (4.07%)
Figure 9. Average throughput of different data grams of UDP
The result shows that jitters and datagram loss ratio increases with increasing datagram size. The
jitters or packet delay variation increased sharply when the datagram size exceeds the allowable
maximum size (1500 bytes). Since the size is larger than 1500 bytes, the data packets had been
fragmented and were sent separately. This causes the high latency as shown by the jitters.
When datagram differences are less then packet transmission delay is also less. For example, the
100~500 bytes datagram packets has very less data packet delay time compare than 500~3000 bytes
datagram packets. In Figure 10 is shown average jitter value of each datagram packets of UDP. Our
experiment basis we can suggest 1500 bytes datagram packets is good for data transmission.
Figure 10. Average jitter of each datagram packtes of UDP
5. Conclusion
This paper presented an experimental performance analysis of different window size for TCP and
UDP transmission. Most of researcher did the wireless mesh network performance analysis through the
simulation. The simulation analysis is easier to be used but the result is often less reliable compared to
Impact of Wireless Mesh Networks in Real-time Test-bed Setup
Madhusudan Singh, Sang-Gon Lee, Whye Kit Tan, Jun Huy Lam
32

real implementation. Therefore, a real implementation test is assumed to be able to provide a more
reliable result.
Our testbed is constructed based on the IEEE802.11s draft 4.0. The network formed consisted of
four PCs and two laptops. In our experiment, the best path selection is done by using the modified air
time metric which is claimed to be able to reduce the PREQ and RREQ frames flooding. In our
experiment, the non-mesh stations information are stored through the proxy mechanisms in HWMP tree
table whenever HWMP tree is available in the network.
Acknowledgement
This work is supported by the 2011 National Research Foundation of Korea.
6. References
[1] I.F. Akyildiz, X. Wang, and W. Wang, “Wireless mesh networks: a survey”, Elsevier Computer
Networks Journal, vol. 47, no. 4, pp. 445-487, 2005.
[2] X. Wang, and A. O. Lim, “IEEE802.11s wireless mesh networks: Framework and challenges”,
Journal Ad Hoc Networks, vol. 6, no. 6, pp. 970-984, 2008.
[3] Y. Yan, H. Cai, and S.W. Seo, “Performance Analysis of IEEE802.11 Wireless Mesh Networks”,
IEEE International Conference on Communications 2008 (ICC'08), Beijing, China, pp.2547-2551,
2008.
[4] IEEE P802.11s task Group IEEE Unapproved draft standard P802.11s/D4.0, Dec. 2010.
[5] R. G. Garroppo, S. Giordano, D. Lacono, and L. Tavanti, “on the development of a IEE 802.11s
Mesh Point prototype”, ACM Tridentcom 2008, Innsbruck, Austria, pp.969- 978, 2008.
[6] R.G. Garroppo, S.Giordano, and L. Tavanti, “ Implementation frameworks for IEEE 802.11s
systems”, In Proceedings of Computer Communications, Elsevier Journal, vol. 33, pp. 336-349,
2010.
[7] H.Song, B.C.Kim, J.Y. Lee, and H.S. Lee, “IEEE 802.11-based Wireless Mesh Network Testbed”,
proceedings of 16th IST Mobile and Wireless Communication Summit, Budapest, Hungry, pp.1-5,
2007.
[8] Nori Mohammed AL-Kharasani, Zuriati Ahmad Zukarnain, “Performance Evaluation of Routing
with Load-Balancing in Multi-Radio Wireless Mesh Networks”, JDCTA: International Journal of
Digital Content Technology and its Applications, Vol. 5, No. 2, pp. 64 ~ 71, 2011.
[9] Kai Yang, M. Jianfeng, “A Hierarchical Hybrid Routing Protocol for Wireless Mesh Network”,
JCIT: Journal of Convergence Information Technology, Vol. 5, No. 8, pp. 146 ~ 156, 2010.
[10] Madhusudan Singh, Sang-Gon Lee, “Decentralized Hybrid Wireless Mesh Protocol”, ICCIT 2009,
Seoul, ACM 978-1, pp.824-829, 2009.
[11] “Madwifi: multiband atheros driver for wifi” ,[Online] Available: http://madwifi-project.org
[12] http://code.google.com/p/xjperf/
[13] F. Granelli, R. Riggio, T. Rasheed, and D. Miorandi, “WING/WORLD: An Open Experimental
Toolkit for the Design and Deployment of IEEE 802.11-Based Wireless Mesh Networks Test
beds”, EURASIP Journal on Wireless Communications and Networking, vol. 2010, PP. 1-18, 2010.
Impact of Wireless Mesh Networks in Real-time Test-bed Setup
Madhusudan Singh, Sang-Gon Lee, Whye Kit Tan, Jun Huy Lam
33