978-1-4673-5828-6/13/$31.00 c©2013 IEEE

Experience from Testbeds and Managementplatforms towards Mesh Networking with

Heterogeneous Wireless AccessVangelis Angelakis1, Antonio Capone2, Alexandros Fragkiadakis3, Stefano Napoli2, Stefanos Papadakis3,

George Perantinos4, Vassilis Spitadakis4, Elias Tragos3, and Di Yuan11: Department of Science and Technology, Linkoping University.

2: MobiMESH Advanced Network Solutions & Products srl.3: Institute of Computer Science of the Foundation for Research and Technology-Hellas.

4: Forthnet S.A., Research and Development Department.Corresponding author: vangelis.angelakis@liu.se

Abstract—The MESH-WISE project is aiming to addresskey fundamental issues in wireless mesh networking that spanfrom fundamental performance characterization to prototypingheterogeneous-access mesh networking solutions for emergencyresponse scenarios. In this paper we present the infrastructuresthat will be leveraged in this project and the latest results thathave been acquired from the ones that are deployed. We furtherdiscuss the state of the art in academic and industrial resourceand network management platforms and discuss how we will useexisting know-how towards a centralized solution.

Index Terms—Mesh Network; Infrastructure; Testbed; Re-source management;

I. INTRODUCTION

In the past decade, significant research efforts have beendevoted to the establishment of the wireless mesh networkingparadigm. Wireless Mesh Networks (WMNs) present a low-cost solution to provide Internet access wirelessly in largegeographical areas. WMNs utilize multi-hop communications,to expand the coverage of classic one-hop systems suchas the Wi-Fi hotspots and the cellular systems up to 3G.The main advantages of WMNs are ease of deployment,relatively low capital and operational expenditure (CAPEXand OPEX), and scalability. However, a vast majority ofcurrent mesh solutions fall short on achieving efficient uti-lization of resources for several fundamental reasons. First,the achievable performance region of WMNs has not beenthoroughly investigated. from a global optimization perspec-tive. Second, WMN deployment solutions and configurationsare usually set for “typical” scenarios while the networkoperational environment is fluctuating unpredictably leadingstatic configurations to poor performance. Third, to date, thefundamental performance limits and resource managementmechanisms have largely been considered assuming that eachnetwork operates in isolation. This is not the case thoughfor the unlicensed ISM spectrum bands of IEEE 802.11,while for licensed bands the introduction of femtocell nodescreates similar issues. To address the above needs, the MESH-WISE EU-FP7 Marie Curie Industry Academia Partnerships

and Pathways project [1] targets to make WMNs capable ofsensing and predicting their operational conditions and allowtheir configuration to optimize the performance. The projectis founded on the previous experience of the partners, bothfrom the academia/research and the commercial sector. In thispaper we present the resources to be mobilized in this effortin terms of testbeds and management platforms. We link themthe state of art and present the latest results from deployedmesh infrastructures. Based on these we provide the outlookof the future research effort along these lines.

II. TESTBEDS & INFRASTRUCTURES IN THE MESH-WISECONSORTIUM

The MESH-WISE consortium has significant research ex-pertise in WMNs operating in real environments and condi-tions. This has been, in part, facilitated by the deploymentof large scale installations, the design and construction ofmesh nodes, and the extended experiments under controlledand dynamic conditions.

1) The FORTH metropolitan testbed: FORTH has deployeda multi-radio metropolitan WMN in the city of Heraklion(Figure 1). This network was initially designed and deployedwithin the project “Design, Management and Security ofWireless Networks with QoS Support” funded under the GreekSecretariat for Research and Technology (GSRT) and was laterupgraded and expanded within the EU-FP7 project EU-MESH(Enhanced Ubiquitous and Dependable Broadband Accessusing MESH Networks) [2]. In its current state, the WMNconsists of sixteen (16) nodes, among which six (6) nodes arethe core mesh nodes (K1-K6) and the other ten (M1-M10) areused for monitoring and management of the core network.

2) The FORTHNET testbed: In the context of the EU-MESH project, FORTHNET deployed a metropolitan WMNfor research purposes (Figure 2) consisting of four long-distance mesh nodes placed throughout the city of Heraklionand one management node placed at FORTHNET’s premises.

For both WMNs off-the-shelf 802.11a devices have beenselected. The key reason for this was node cost efficiency;

Fig. 1. FORTH’s updated metropolitan mesh network

Fig. 2. Forthnet’s metropolitan mesh network

the use of commodity IEEE 802.11 interfaces, at the timeof deployment, led to significantly lower costs compared toother technologies, such as IEEE 802.16 for example. Eachmesh node is equipped with two to four 802.11 mini PCIinterfaces (NMP-8602 Atheros-based High Power dual band802.11a/b/g) and directional antennas, with each interfacehaving a static IP address. In the experiments, the 802.11ainterfaces were selected. More details regarding the deploy-ment of these metropolitan WMNs can be found in [3]–[7].

3) Rapid Emergency Deployment Communication infras-tructure - REDComm: Further than the typical metropolitanWMN the design and construction of a new, modern, moreversatile and multi-technology WMN in the framework ofthe European-funded project REDComm [8], will give thecutting edge advantage of unrestricted, multi-standard coex-isting radios. This new WMN will be the basis of a mobilerapid emergency deployment communication infrastructure.Each node is equipped with multiple Software Defined Radio(SDR) interfaces and common networking and communicationinterfaces including 802.11n Access Points, GSM Base Sta-tions, ISDN PRIs, two-way Satellite, VHF radio transceiversand gigabit ethernet switches. The use of open source soft-ware provides IP-based voice call routing through all theavailable systems and network connections, interconnecting

Fig. 3. REDComm mesh network

diverse technologies, i.e. GSM and VHF radio. The SDRs willprovide the backbone mesh connectivity taking advantage ofunderutilized parts of the spectrum, with dynamic selection ofthe operational frequency and bandwidth.

III. WIRELESS MESH NETWORKS MANAGEMENT

For typical commercial deployments of WMNs strong ad-ministration and centralized management mechanisms havebeen employed in order to efficiently supervise them, ratherthan relying only on deployed self-x mechanisms. The pri-mary goals of a WMN network management tool are theefficient, effortless and comprehensive planning, configuring,monitoring, reporting and alarm triggering, with the mini-mum required user interaction. Visualization of data is a keyelement mapping the information of the RF coverage andinterference, wireless performance and capacity, node, userand rogue device location, malfunction and security alertslocation. Further than the user interface the managementsystems provide several of the mechanisms that contribute tothe network’s reliability, resilience, security and performance.The former are achieved by assisting the network design dur-ing the deployment and the continuous real-time monitoringand statistics processing. The services-centric approach thatis being employed the last years provides an even betterperformance in the areas of mobility, voice, location, securityand resources allocation.The increased interest of the commercial, community andresearch sectors for WMNs has produced various managementtools based on the aforementioned principals. In the com-mercial sector key players are Motorola, Cisco, Open-Mesh,MeshDynamics, Meraki, MobiMESH, WILIBOX, Firetide,Ruckus, Aruba Networks and Proximetry. Usually each vendorprovides both the hardware and the management software asthere are closed-source customized protocols being employed.There are vendors that provide a special hardware controller,often called management appliance, which essentially is acustomized computer running their software on a typicaloperating system, i.e Cisco Wireless Control System Server[9], Juniper WLM1200 Wireless LAN Management Appli-ance [10] and Ruckus ZoneDirector [11]. Others provide thesoftware that can be installed in a standard PC with some

minimum requirements, for example Motorola’s MeshMan-ager [12], MeshDynamics Network Management System [13],MobiMESH Management System [14], WILIBOX RemoteConfiguration Management System [15], Firetide’s HotViewPro [16], Aruba MeshConfig [17] and Proximetry’s AirSync[18]. The most advanced ones, like the Open-Mesh’s Cloud-Trax [19], Meraki’s Cloud Networking [20], Xirrus XMSCloud [21], and the MobiMESH Management System provide“cloud” solutions moving the control and management awayfrom the actual deployment.On the other hand the community and research WMNs arebased on open-source tools, and almost exclusively run onLinux. One of the most common approaches is the use ofthe typical tools for monitoring and management of wirednetworks, like Nagios and Zabbix, plus one database visualiza-tion/mapping tool like WiND or even Google Maps. Furtherthan this simplistic approach that has minimum integrationand cannot be considered mesh-aware, there are few interest-ing efforts that provide the proper functionality. KAUMesh[22] is a multiRadio, multiChannel mesh testbed that doescombine the common monitoring tool Nagios with customplugins and incorporates OpenFlow in order to exploit themesh networking advantages. MeshMon [23] is a networkmonitoring framework that uses a multi-tiered method of datacollection and employs dynamic control of the data collectiongranularity based on observed events in the network, achievingsignificant bandwidth conservation and enabling real-time au-tomated management. Another open-source mesh deploymentserver called OrangeMesh [24] is compatible with Open-Meshand mesh devices running RO.B.IN. It provides a centralizednetwork configuration and network status visualization tools,and it is designed mainly for community wireless networks.The ReMesh project [25] has investigated, developed andintegrated open-source tools for the mesh nodes initializationand reconfiguration, the authentication and access control,the topology view and the performance measurements andstatistics. Afrimesh [26] is another effort to integrate manycommon open-source applications and research results undera user friendly, minimum complexity management dashboard.A freely available tool specifically designed for wireless meshmanagement and configuration of the Universidad Politecnicade Valencia is MAYA [27]. It extends the OpenWRT platformadapting it to the needs of the WMNs, and simplifies themanagement process by allowing to perform critical tasks, ina simple and efficient manner.

A. The MobiMESH Management System

The MobiMESH Management System (MMMS) per-forms configuration, provisioning, management and monitor-ing tasks, and communicates with the MobiMESH WirelessMesh Routers through a proprietary protocol. The MMMSprovides a configuration interface that allows the networkengineer to work on a central server instead of configuringeach single device; in fact the MMMS allows the config-uration of the general, network wide parameters (ESSIDs,access profiles, backbone settings, IP settings, etc.) and the

configuration of the more specific, per-device settings suchas channels, transmission powers, etc. Every device gets itsown configuration through a provisioning procedure: as soonas it is powered up, it performs a scanning loop in searchfor the MMMS (either directly or through multiple hops); assoon as it can communicate with it, the device performs astrong authentication procedure, after which it can retrieve itsconfiguration and it can apply it, entering the network. Thisprocedure also contains a watchdog mechanism that rebootsthe device, if it cannot be reached after the configuration hasbeen applied. Such situations are probably caused by a radiomisconfiguration, therefore the configuration shall be modifiedand provisioned again by the field device. Once the networkis set up and fully running, the MMMS can be used formanagement purposes. Therefore the configuration may needto be modified in real time, in order to deploy a new service orto adapt to a changing scenario (i.e. an interfering Access Pointis activated on the same frequency of a wireless access device;this should be detected, analyzed and the whole frequencyassignment shall be modified accordingly). The MMMS infact implements both push and pull mechanisms, so that it canapply configuration modifications on the field network and itcan receive alarms from the network itself, providing a strongmanagement platform. The MMMS also performs monitoringduties; in fact it keeps a real-time status of the network interms of nodes and links availability and quality, of networkoverall status and of general service parameters. Moreover,upon the verification of selected events, it can send alarmsand alerts for a human verification and action.

B. The MESH-WISE Centralized Management System

A centralized management platform for a mesh multi-accesstechnology system should be able to perform several tasks,which include the communication with all the components ofthe WMN for configuration, provisioning, management andmonitoring functions. Since the devices that constitute theWMN may belong to different families, and may communicatethrough various wireless and wired technologies and protocols,the Management Platform must provide a higher level view ofthe network topology, capabilities and routing, so that eachservice can be optimized with respect to such information.Therefore the centralized management architecture will com-prise two sets of components: a) one set for identifying thetype and capabilities of the network devices, and establishinga specialized communication with each device or device type,and b) one for providing configuration, provisioning, manage-ment and monitoring functions. This architecture well matchessome of the current components of the MMMS, described inthe preceeding section, which can be used as a starting pointto develop the MESH-WISE Management Platform.

The MESH-WISE Management System will be designedstarting from the MMMS platform and extending it in severaldirections, but first of all by adding the possibility of commu-nicating with devices of different technologies, such as sensorsand actuators. The communication with such devices in manycases cannot be direct and thus requires the intermediation

of a technology gateway that acts as a supervisor and as anabstraction layer for the sensor network. The MESH-WISEManagement Platform will therefore be equipped with a com-ponent that will detect the Management-device communicationmechanism implemented by the different network devices, andthat will activate the device-specific connector that will allowthe communication of the Management with each specific kindof device. This will be a more general approach that willopen the possibility of applying the routing, management andmonitoring approaches to a wide range of network devices,going even beyond the scope of the MESH-WISE project, toa wide range of further applications. Moreover the MESH-WISE Management Platform will extend the configuration andprovisioning capabilities; in fact a more general and abstractview of the network will be provided in order to consider thenetwork as a general topology with specific characteristics,thus going beyond the distinction between the specific devices’technologies. This will grant the possibility of implementingadvanced services on top of the network by just consideringcapabilities and not the single technologies. Overall, the net-work management functions will be improved, creating thepossibility of a high level, service-dependent reconfigurationof the network, that will trigger lower level and technologyspecific configuration modifications. Finally, monitoring willbe further developed, by adding more service-oriented moni-toring functions that will cover different technologies, in orderto provide a higher level view of the network as a whole.Through these enhancements the MESH-WISE platform willevolve from being a WMN management system to a moregeneral, service-oriented WMN management platform.

IV. EVALUATION OF DEPLOYED INFRASTRUCTURES

A. FORTH’s metropolitan testbed

This metropolitan WMN has been upgraded and extendedin order to assess its performance regarding supporting high-quality end-to-end applications. The extension involves theintegration of two gateways that connect the network to theglobal Internet. The goal was to exploit the two differentgateways in order to perform multi-path and multi-gatewayexperiments. As seen in Figure 1, the two gateways are K1and K4. K1 is connected to the global internet through thenode M1 located at FORTH’s premises, while K4 is connectedthrough the University of Crete and the GRNET network thatconnects the universities and research centres of Greece.

1) Performance results: In [4], [6], [7] several hop-by-hopexperiments in FORTH’s WMN were presented, showing howthe one-hop links of the network were impacted by the intra-network interference. In multi-hop WMNs, the hop-by-hopmeasurements do not represent efficiently the overall end-to-end network performance. Especially when the server islocated outside the WMN, end-to-end (e2e) performance mea-surements are mandatory, since some hops/links (especiallythose adjacent to the gateways) normally become congested.In [28] some initial e2e measurements in the extended and up-graded metropolitan WMN were presented. This work presents

more results regarding the e2e performance of such a WMN,which affects the quality of experience of the users.

For evaluating the e2e performance of the metropolitannetwork, we set up one server at FORTH’s premises, whichis outside the area of the metropolitan network and can beconsidered as an “Internet server”. The experiments includedtwo scenarios: (i) raw UDP traffic, and (ii) http browsing.In the server, we have installed the Darwin Server [29] forstreaming video and the Lampp http server [30]. On the clientside at the metropolitan mesh nodes we use the GNU wget tool[31] for the HTTP browsing. We also used the iperf tool [32]that serves both as a server and a client for sending raw UDPdata traffic between the server and a client. For all experiments,extra background traffic of 1 Mbps is generated using iperf atthe links for creating low intra-network interference.

For each scenario several sets of experiments were per-formed, for both a random Channel Assignment (CA) and theCA algorithm presented in [5] that takes into account bothintra-network interference from the network’s links, as wellas external interference from other sources. The goal was toinvestigate the performance of a metropolitan network whenthere is significant interference in the network and how this canaffect the multi-path and the single-path flows. Static routing isused in all the experiments and the multi-hop scenario includes2 hops. The metrics that were measured were: (i) one-waye2e delay, (ii) e2e throughput, (iii) e2e packet loss, and (iv)http latency. For measuring the e2e delay the Precision TimeProtocol (PTP) [33] was selected for synchronization.

a) raw traffic: In Figure 4 the results of three sets ofmeasurements for iperf UDP traffic of 14Mbps in the multi-path scenario are presented. Iperf sends raw data traffic viaUDP packets, without any control of the throughput or any re-transmissions. Figure 4a presents the throughput results (boththe actual measurements and the mean value) for the CA caseand the interference case. It can be easily seen that the receivedCA throughput is quite stable, equal to the sending rate ofiperf (no loss of throughput) and approximately 16% higherthan in the case when no proper CA has been applied at thelinks (which is approximately 2.5Mbps lower than the sendingrate). In Figure 4b the mean e2e packet delay for both cases forthe multi-path scenario is presented. It is quite clear that thereis a huge difference in the delay measurements, since the CAachieves very low e2e packet delay (approximately 0.007s),while, when there is interference, the delay is significantlyhigher (around 0.21s). In Figure 4c the average percentageof lost packets are depicted for five different runs of theexperiment. On average, with proper CA only 0.27% of thepackets are lost, while in the interference case approximatelyone out of four packets are lost. This can be explained due tothe fact that 14Mbps traffic nearly congests the links causinghigh interference, collisions, backoffs and retransmissions;thus it increases the delay and packet loss rate and lowersthroughput.

b) http traffic: Another set of measurements was per-formed with http traffic. Usual http web pages have very smallsize and this would not allow us to get some useful results,

packet id packet id number of runs

a) throughput b) delay c) packet loss

Fig. 4. iperf measurements for multi-path

thus we used a file of 50MB, which was downloaded throughhttp with the use of the wget tool. Table I presents the resultsfor mean latency (time required to download the file) of severalruns of the experiment for the two single-path scenarios andthe multi-path scenario. The third row shows the percentage ofthe latency increase due to additional interference at the linksand it varies from 37.46% for the K1-K3 single-path scenarioup to 126.47% for the K4-K2-K3 single-path scenario. Thehuge difference between the results of the two single-pathscenarios can be explained easily due to the adjacent linksK4-K2 and K2-K3 in the K4-K2-K3 single-path scenario.If no proper CA is performed for the multiple interfacesof node K2, the adjacent links can be affected by adjacentchannel interference [34], [35], [36], which severely degradesthe performance of the link. On the other hand, link K3-K1 isonly affected by the external interference, which surprisinglyalso has significant impact on the link’s performance.

Similarly, Table II presents the results for the receivedthroughput in all three scenarios. It is obvious that the through-put degradation is quite huge (more than 45%) in the multi-path and single-path K4-K2-K3 scenarios, while in the K1-K3single-path scenario, the difference is slightly lower (25%) butstill quite high. Figure 5 presents the actual and the mean httpthroughput for the multi-path scenario for one run.

TABLE IHTTP - MEAN LATENCY

HTTP mean latency (s)Algorithm Single K1-K3 Single K4-K2-K3 Multi-pathCA 37.127 37.666 23.249Interference 51.034 85.301 39.263Latency increase 37.46% 126.47% 68.88%

TABLE IIHTTP - MEAN THROUGHPUT

HTTP - mean throughput (Mbps)Algorithm Single K1-K3 Single K4-K2-K3 Multi-pathCA 11.144 10.752 17.592Interference 8.304 5.208 9.656Degradation 25.48% 51.56% 45.11%

packet id

Fig. 5. http throughput for multi-path scenario

B. Forthnet testbed

For evaluating the performance of FORTHNET’s networkseveral measurements were taken for two scenarios: (i) theselected CA algorithm (the same as in the measurements inFORTH’s network) and (ii) random CA. It must be noted herethat the CA is centralized and runs at the management node.For all experiments, background traffic of 1 Mbps is generatedusing iperf at the links for creating intra-network interference.

We provide measurements regarding the average http la-tency for downloading a file of 6 MBytes in size, the averagepacket loss and average throughput using iperf and the averageround trip delay using ping generating ICMP requests. Allthese measurements are e2e measurements from MANAS toKOUROU node. It can be seen in the topology figure thatthe path from MANAS to KOUROU includes two routes:(i) LinkA and LinkD, or (ii) LinkA, LinkB and LinkC.

c) Results: The first set of experiments was performedusing http traffic. Table III shows the mean http latency forboth CA scenarios. It is obvious that when no proper CAalgorithm is used and the links are interfering with each otherthe mean latency is increased by almost 35%.

The second set of experiments were performed using rawiperf UDP traffic of 1Mbps. Table IV shows the UDP results

TABLE IIIHTTP - MEAN LATENCY

Algorithm HTTP mean latency (s)CA 67.07Interference 90.30Latency increase 34.64%

for throughput and mean packet loss. It is quite obvious thatin both cases the performance degradation due to interferenceis very significant. This is especially shown by the packet lossresults. Using proper CA there are almost no packets lost, butwith the random CA there are on average approximately 15packets lost. It must be noticed here that the 1Mbps traffic thatis generated is quite low, which means that with higher trafficthe results would be much worse.

TABLE IVUDP RESULTS

Algorithm mean throughput (Kbps) Mean packet loss (%)Full algorithm 463 0.42Random 415 14.92Degradation 10.36% 3452.38%

The last set of experiments was performed using ICMPtraffic for measuring the round trip e2e delay. For generatingICMP traffic, the command line tool ping was used. It canbe noticed by the table that interference at the links resultsto approximately 27% higher round trip delay. The averageround trip delay depends on external and internal interferenceas well as on contention. Interference can cause collisions orcan delay the transmission of data at the sender because of theCCA mechanism of the IEEE 802.11 protocol. Contention dueto the presence of external sources using the same channels fortransmission can cause extensive transmission delays becauseof the back-off mechanism.

TABLE VMEAN ROUND TRIP DELAY

Algorithm Mean round trip delay (s)Full algorithm 0.00626Random 0.00797Delay increase 27.32%

V. CONCLUSION

We have presented deployed metropolitan-scale meshtestbeds, along with the REDComm mesh network, that willbe leveraged in the MESH-WISE project. We provided thelatest, unpublished results that have been acquired from themetro-scale testbeds, where we illustrated that the role of intra-network interference is significant in performance degradation.This brings into focus the role of the discussed resource andnetwork management systems, and the platform we proposeto develop within the MESH-WISE project.

ACKNOWLEDGMENT

The authors would like to thank prof. Vasilis Siris andprof. Apostolos Traganitis for their contributions to the work

presented in this paper. This work has been supported in partby the EC Marie Curie Actions project MESH-WISE (FP7-PEOPLE-2012-IAPP: 324515).

REFERENCES

[1] http://www.mesh-wise.eu[2] EU FP7 ICT project no 215320: Enhanced Ubiquitous and Dependable

Broadband Access using MESH Networks (EU-MESH)[3] V. Angelakis, et. al, “Heraklion MESH: An Experimental Metropolitan

Multi-Radio Mesh Network”. In Proc. of 2nd ACM WiNTECH’07,Montreal, Sep. 2007.

[4] M.Delakis, et. al, “Experiences and Investigations with Heraklion MESH:An experimental Metropolitan Multi-Radio Mesh Network”. In Proc. of4th TRIDENTCOM 2008, Innsbruck, Mar. 2008.

[5] M. Delakis and V. A. Siris, “Channel Assignment in a MetropolitanWireless Multi-Radio Mesh Network”. In Proc. of 5th Broadnets 2008,London, September 2008.

[6] V. Angelakis, et. al, “Investigation of Timescales for Channel, Rate,and Power Control in a Metropolitan Wireless Mesh Testbed”, ICT-MobileSummit 2009, Santander, Spain, 10-12 June 2009.

[7] Vassilios Siris, Elias Tragos, Nikolaos Petroulakis, “Experiences with aMetropolitan Multi-Radio Wireless Mesh Network: Design, Performance,and Application”, accepted to be published in IEEE CommnicationsMagazine, Series on Ad Hoc and Sensor Networks.

[8] http://www.redcomm-project.eu[9] http://www.cisco.com/en/US/prod/collateral/wireless/ps5755/ps6301/

ps6305/product data sheet0900aecd802570d0.html[10] http://www.juniper.net/us/en/local/pdf/datasheets/1000366-en.pdf[11] http://www.ruckuswireless.com/products/controllers[12] http://www.motorola.com/Business/XP-EN/Business+Product+and+

Services/Wireless+Broadband+Networks/Mesh+Networks/Mesh+Tools/[13] http://www.meshdynamics.com/mesh-network-manager.html[14] http://www.mobimesh.eu/index.php?option=com content&task=

view&id=200&Itemid=226[15] http://www.wilibox.com/products/rcms-remote-management[16] http://www.firetide.com/innercontent.aspx?taxid=8&id=76[17] http://www.arubanetworks.com/products/mesh-routers/

aruba-meshconfig[18] http://www.proximetry.com/airsync-features-and-benefits.php[19] http://www.open-mesh.com/index.php/solutions/cloud-controller.html[20] http://www.meraki.com/products/architecture[21] http://www.xirrus.com/Products/Network-Management/Cloud[22] Dely, P.; Kassler, A.; Bayer, N.;, “OpenFlow for Wireless Mesh Net-

works,” Computer Communications and Networks ICCCN 2011, Pro-ceedings of 20th International Conference on, 2011

[23] R. Raghavendra, et. al, “MeshMon: a multi-tiered framework for wire-less mesh network monitoring”, In Proc. of MobiHoc S3 ’09, 2009

[24] http://orangemesh.sourceforge.net[25] J.L. Duarte, et. al, “Management Issues on Wireless Mesh Networks,”

Network Operations and Management Symposium, 2007. LANOMS2007. Latin American , vol., no., pp.8,19, 10-12 Sept. 2007

[26] http://code.google.com/p/afrimesh[27] D. Manzano, et. al, “MAYA: A Tool For Wireless Mesh Networks

Management,” In Proc. of IEEE MASS vol. 1, no. 6, pp.8-11 Oct. 2007[28] E. Z. Tragos, A. G. Fragkiadakis, I. Askoxylakis, V. A. Siris, “The

impact of interference on the performance of a multi-rate multi-pathmetropolitan wireless mesh network”, Proc. Of IEEE ISCC, July 2011,Corfu, Greece.

[29] Open Source Darwin Streaming Server http://dss.macosforge.org/[30] Linux XAMPP http://www.apachefriends.org/en/xampp-linux.html[31] GNU wget tool http://www.gnu.org/software/wget/[32] http://sourceforge.net/projects/iperf/[33] IEEE 1588-2002, “Standard for A Precision Clock Synchronization

Protocol for Networked Measurement and Control Systems”,[34] V. Angelakis, et. al, “Adjacent Channel Interference in 802.11a: Model-

ing and Testbed validation” IEEE Radio and Wireless Symposium (RWS2008), Orlando, FL, USA, Jan. 2008.

[35] V. Angelakis, et. al, “The Effect of Using Directional Antennas onAdjacent Channel Interference in 802.11a: Modeling and Experience Withan Outdoors Testbed” 4th WiNMee 2008, Berlin, Mar. 2008.

[36] V. Angelakis, et. al,“Adjacent channel interference in 802.11a is harmful:Testbed validation of a simple quantification model,” CommunicationsMagazine, IEEE , vol.49, no.3, pp.160-166, March 2011