Abar´e: A Deployment and Management Framework
for Wireless Mesh Network
Billy Pinheiro
Federal University of Par´aEmail: [email protected]
Vagner Nascimento
Federal University of Par´aEmail: [email protected]
Waldir Moreira
Institute for Systems and Computer Engineering of PortoEmail: [email protected]
Antˆonio Abel´em
Federal University of Par´aEmail: [email protected]
Abstract—The adoption of wireless mesh networks as a solution for access networks in indoor and outdoor environments is considered by the academic community and industry as a good alternative for Internet access due to their economic and technical feasibility. However, the existence of proprietary and open-source solutions that are not interoperable and the delay in the standardization makes the deployment of wide scale wireless mesh networks a time consuming task and it may come along with some security problems. In this paper, we propose Abar´e, a framework which defines a set of components and steps to aid in the deployment and administration of mesh networks since its inception.
I. INTRODUCTION
Wireless Mesh Networks (WMNs) emerge as a cheap alter-native with extended coverage, because through cooperation between the nodes, a link to the fixed network can be shared, allowing more efficient usage of bandwidth and avoiding the cost with cabling to the end users[1]. However, this type of network still suffers from the lack of standardization[2]. Several companies such as Motorola and Cisco have already developed pre-mesh solutions, but the high costs hamper their adoption on a large scale environment. Moreover, these solutions offer no guarantees of interoperability, making it almost impossible to use them together.
As an alternative to proprietary solutions, Wi-Fi (Wireless Fidelity) equipment can be used with modified firmware using a Linux distribution such as OpenWRT [3] or DD-WRT [4]. Such a solution is aimed for embedded devices, enabling the easy sharing of network resources and reducing considerably the total cost of deploying a WMN. This type of solution allows digital cities creation with an accessible cost, providing a range of services to users. Several projects have already shown that the use of this solution is viable, for example namely Vmesh[5].
The easiness offered by WMNs has stimulated its growth and this has caused needs for network maintenance and planning. In a small environment, only one person is able to manage it. However, given an environment that has dozens of distributed points, the maintenance becomes more difficult, demanding more time and resources. This happens because the deployment and management of such networks are still per-formed through a series of non-formalized steps and lacking standardization regarding the different software’s used.
Considering networks with a broader coverage, the man-agement task is inherently more complex and crucial, since it involves a large number of equipments and users depend-ing on their services. These services must be secured and maintained adequately, because users expect the same quality found in wired networks. Furthermore, with the great use and heterogeneity of networks, there has been a need for a scheme that offers solutions for managing consistent and structured networks, allowing equipment monitoring and control[6].
In the case of WMNs, management is a significantly more complex task because they are a type of hybrid network with characteristics of infrastructured and ad hoc networks. Therefore, they are not fully supported by existing tools that are usually developed based either on a set of requirements related to the infrastructured network or the ad hoc one[7].
Unlike wired networks, WMNs lack a standardization ef-fort to guarantee, for example, the interoperability between different WMNs. As a result, there are not many management tools focused on WMNs. The few tools found are usually developed by mesh solution suppliers related specifically to their solutions as motomesh[8]. An additional drawback is that they are not open source which would allow their extension to accommodate specific needs.
In order to address the limitations and aforementioned issues, we present Abar´e1, a framework with methods to assist
and facilitate the deployment, monitoring and management of WMNs based on information collected from routers and the network itself.
This paper is structured as follows. Section 2 presents the work related to WMN management. Open Mesh is described in Section 3. In Section 4 the proposed framework Abar´e is presented. Section 5 shows the application of the framework. Finally, Section 6 presents the conclusions and future work.
II. RELATEDWORK
This section covers not only work specifically related to mesh network management, but also work on ad hoc and wired networks frameworks, since both have a larger number of work that served as basis for the proposal presented in this paper.
Commonly, to perform network management, the Simple Network Management Protocol (SNMP) is used. It is the
standard protocol for monitoring and managing most of the networks due to its wide acceptance and usage in large software management[9]. With SNMP, each node keeps a database of local information that can be managed, known as Management Information Base (MIB), which is periodically accessed by a Network Management System (NMS). Mesh proprietary solutions use either SNMP or some other solution developed by the device manufacturer[8][10][11].
The Distributed Ad-hoc Network Monitoring (DAMON) is a system to monitor distributed and ad-hoc sensor networks, and it was proposed by[12]. There are agents used to collect information from the network and send data to repositories. It is worth emphasizing that this algorithm is dependent on the Ad-hoc On-Demand Distance Vector (AODV) routing protocol for its operation.
Jardosh[13] designed the SCUBA framework for interac-tive visualization to report on problems in large-scale mesh networks. In this framework, several metrics are gathered in a database through a gateway node. This information is used to generate an interactive view. The framework is tested in an initial implementation with 15 mesh nodes which shows the viability of the framework.
Riggio[14] proposed the JANUS framework for distributed management of WMNs.However, the actual proposal is re-stricted to the task of monitoring the network. The testbed used was a simple mesh network using microcomputers with MCL (Mesh Connectivity Layer) installed[15].
Mesh-Mon is a framework proposed and implemented by[16] that performs network monitoring to help the ad-ministrator with the task. Charles defined his management system as being scalable and distributed, and that attempts to automatically detect and recover from network failures. However, the framework is reduced to simply monitoring the network taking some actions automatically if the network behavior is different from a standard which was set statically by the author
MobiMESH is a WMN implementation that provides a comprehensive framework of analysis the behavior in real environments, including advanced routing support consider-ing multiple radios, channel allocation, as well as manag-ing, monitoring and security platforms[17]. Nevertheless this framework, as it happens for most of the frameworks, has no additional modules that could make them adaptable to the reality of WMNs over time.
Badonnel[18] mentions that the process of collecting information may cause overload in the network, and Cheikhrouhou[19] proposes a solution to this problem con-sidering that the management tools of a framework are imple-mented at application level. That is, the information would be accessed individually at each point of the network and, thus, the data would be collected in the desired way, but it would also be necessary to take proper precautions with the security of messages exchanged between applications.
Another important issue on the monitoring task that should be observed is the temporal property of information, this prop-erty is determined by the requirements of network
manage-ment. An example of such property is the task of visualizing the network topology in real time. This task requires that information be processed as quickly as possible; otherwise the representation is not precise enough. It may also be necessary to obtain the history of statistics of a given fixed point which has a very low time restriction. Therefore, the collection interval should be sufficient, but without interfering in the functioning of the network.
Thus, we can observe that the implementation, monitoring and administration tasks are very important to the network, and based on these aspects, we propose a framework that meets the needs or fills in the gaps left by other frameworks proposed in the literature and it is not just restricted to the monitoring task as done by most frameworks.
Next we define the scope where the proposed framework could be applied. Its focus is on networks that we call Open Mesh which can be implemented in indoor and outdoor environments.
III. OPENMESH
At the end of the twentieth century, we saw a movement in which the computers that were sold as a single box containing software and hardware started to be supplied by manufacturers only with the hardware. Therefore, efforts made in the development of operating systems for these products could be allocated for the improvement of hardware which consequently resulted in lower prices of equipment, making them more accessible. It is possible that this movement happen again, but having as target WiFi routers. These manufacturers would supply only the hardware that would be compatible with an operating system offered by third parties. This type of vision is shared by some companies already[20].
From the moment that there is an open firmware, i.e. an operating system with open source code, it is possible to develop an entire solution only with open source software to implement a mesh network[21]. We call the Open WMN a network that has the following components:
• Routers: Equipments that are independent of manufac-turer, brand, and model. They have the same physical and link layers transmission standards and allow changes in their firmware. It is recommended that the amount of RAM (Random Access Memory) and Flash are a minimum of 2MB and 8MB, respectively[22].
• GPL2 Firmware: This is the responsible for abstracting
the differences between different router manufacturers, brands and models, providing a homogeneous layer where it is possible to use the same tools and settings. Its development is supported by a community of users who create and use a series of software that are developed for the same platform.
• Routing Protocol: After the installation of the new firmware, it is possible the installation of any routing protocol that allows the routers to act as mesh routers. Different from Ad hoc networks, where the autonomy
of energy is limited, mesh routers in the networks have a constant power supply allowing that algorithms have higher computational demands.
A. Open Mesh Deployment and Management steps
The deployment and management of such a network con-sists of a series of steps. It is important to know these steps to understand the needs of a framework to assist in these tasks: 1) Once sure that the router is compatible with the chosen firmware, the process of firmware installation is done; 2) An initial connection is established with the router,
containing the modified firmware already, to set the system root password. This step can be done via telnet or http;
3) Then the network configuration should be done using a scheme based on identification (ID) of the router. It is also worth mentioning that the Extended Service Set ID (ESSID) set in the routers must be the same;
4) In order to have a mesh network, even without any type of authentication, Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS) and a dynamic routing algorithm, are required. Normally, the DHCP and DNS services are already installed, remaining only to conduct the installation of the dynamic routing algo-rithm that meets the needs of the network[1];
5) From this point on, the WMN should already be work-ing, leaving just the maintenance tasks that can be performed remotely, and a connection to each router must be established to perform the desired task; 6) The metrics collection must be done at each router.
Currently some captive portal tools already receive some information and store it in a database[23];
7) Any type of management, either security or QoS, will be done by logging in to each router and manually executing all the desired commands;
The completion of these steps in a network with few routers is a relatively straightforward task. However, in a network with tens of nodes, the complexity and the work spent on this task becomes impossible or at least very difficult to deploy this type of network.
As changes are made only on routers, this type of network is usually deployed as the infrastructure architecture. The network backbone is composed only of mesh routers that provide the basic infrastructure to non-mesh client access. Through this backbone, it is possible to interconnect different networks with different transmission technologies.Usually, this is the most widely used mesh architecture, because it requires changes only in the routers. Nevertheless, these networks accept the communication with other types of networks and their respective equipments [24]
IV. THEABARE´FRAMEWORK
The Abar´e framework is based on a series of practical observations which are used to assist in the deployment and management of WMNs. In other words, it is the formalization
of steps adopted. Thus, Abar´e aims to facilitate the deploy-ment and maintenance processes of large-scale WMNs. In this section we describe Abar´e, its features and components considering the diagram shown in Figure 1.
Fig. 1. Abar´e Framework.
The framework has 3 layers: the admin layer, which is responsible for interaction with the user; the core layer, which represents the core system where the logical part and storage of information are located; and the router layer, which allows access to the router for direct communication with the operating system of each network node. A description of each framework’s component is presented:
• Installer Agent - responsible for making the routers’ firmware change and performing their initial configura-tion. A more precise description about its operation is provided next:
– Make a request to Abar´e Core Application
Program-ming Interface (API) to obtain the suitable firmware available on the server according to the user’s choice and the information to correctly integrate the router to the current WMN;
– Connect to the router and transfer the firmware, re-booting it at the end of the transfer process; – The script generated by the Scripts Module
contain-ing the configuration information of a mesh node is transferred to the router and executed through the Commands Agent.
– The router is then rebooted and once it boots it is already part of the mesh network.
– The new mesh node has its addition to the network
confirmed to the Abar´e Core API and its settings are stored in the database.
• Manager Agent- Responsible for providing an interface
where, after proper authentication, the user can interact with the system and use the features offered by the
Abar´e Core. In other words, this is the interface for system management. Its implementation is independent of operating system and programming language.
• Abar´e Core API - The core system, responsible for obtaining and managing information of all the frame-work’s components. It must provide features, usually in webservice format, which can be used by the Manager and Installer Agents.
• Database Agent - Responsible for writing and reading
information in the database.
• Collection Agent - Requests information to the Routing Agent and sends it to the Abar´e Core API. These are some pieces of information that can be requested:
– Traffic information to identify possible network bot-tlenecks;
– Hardware information to prevent routers from
over-loading;
– Routing table information to monitor links and pos-sible routing problems;
• Commands Agent- Responsible for sending commands to the Router Agent. Normally, it is used for administra-tive tasks;
• Expander Agent - Enables the extension of the
frame-work through the addition of new modules, providing enough abstraction for allowing easy development of new features. These modules are the default modules of the framework:
– Control Module: Coordinates the routers’ IDs and performs the separation of networks and IPs used; – Scripts Module: Generates the script with
com-mands that are given to the Comcom-mands Agent, which in turn, forwards these commands to the routers to be executed. A set of templates is available, and according to the routers chosen as a target, the templates will have their variables changed according to the information of the routers, thus producing a customized script for each router.
– Firmware Module: Gets the firmwares inserted by the administrator and provides them according to the need of Installer Agent.
• Router Agent - Present in the router and is responsible
for replying to the requests of the Collection Agent, providing the information requested in the XML format. It must also accept the commands sent by the Command Agent and execute them in the routers. This agent can be divided into layers which are described below.
– Input and Output: Responsible for receiving re-quests and forwarding them to the correct layer depending on the type of data received. It is also responsible for sending the results on executed com-mands and the collected metrics;
– Exec Commands: Receives commands and executes each one of them sending a positive or negative response regarding the execution;
– XML Parser (eXtensible Markup Language):
Re-ceives XML information from the upper layer and triggers one of the collectors of the lower layer. In the opposite direction, it receives the collected information converting them into XML so that the upper layer can send them.
– Collectors: A set of small modules responsible for collecting information and sending it to the top layer. When a request reaches the XML Parser, it only has the name of the collection module to be triggered. Once the collection module is triggered, it must execute this request and respond with the requested information. Thus, it is easy the integration of new collection modules, being necessary only to insert the new module in the router and that the entity which needs to use the metrics provided by such module know its name.
For a better understanding of the activities covered by the framework, Figure 2 shows the use case diagram.
Fig. 2. Abar´e User Case
This diagram spans three external entities (Manager, Database and Router) in addition to the functionalities that are offered by the different components of the framework.
It is worth mentioning that Abar´e follows a centralized architecture, because it needs a Core to manage the network. This architecture brings advantages such as easy detection of problems and safety management, and allows a better infor-mation control[25]. Scalability problems are the disadvantages of this proposal. However, this can be solved with the use of load balancing solutions [26].
V. ABARE´ FRAMEWORKAPPLICATION
The usage of the Abar´e framework aims to make the network’s deployment and maintenance steps a systematic task and aided by software, that is, to create a roadmap that can be easily executed with the help of a software that meets the framework’s requirements framework. The application of the framework in a real environment, as in an open mesh network,
follows the structure presented in Figure 3. In this case, the Abar´e framework is applied in a WMN Infrastructured Architecture.
Fig. 3. Abar´e Framework Application.
Figure 3 shows the agents in the routers and in the comput-ers used for the deployment and management of the network. It is possible to see in the WMN backbone the presence of Router Agents that are embedded in each mesh router. The Abar´e Core is located outside the WMN backbone and connected to the gateway through the mesh router.
The Abar´e Core may be on the same machine hosting the database and the authentication server, but this is not mandatory. The only requirement is that they must be in the same subnet, preferably connected by wired means to avoid security and availability problems.
The support team in Figure 3 represents the users of the Installer and Manager agents which will be installed on computers, cell phones, palms, etc, since the Abar´e Core is envisioned as a Web Service providing, thus, platform and programming languages independence.
To evaluate the framework, we have developed a proto-typical implementation, containing all the functionalities of the Installer Agent. A prototype of the Core with firmware, control and scripts modules and a prototype of the Manager Agent with the interfaces to access the modules were also developed. The prototypical implementations employed in our experimental evaluation were developed using the Python language, with technology xmlrpc and ssl for secure exchange of messages, support for authentication and using GTK(GIMP toolkit) for the grafic user interface. Figure 4 presents the interface of the Agent Installer.
These are the deployment steps of a WMN using Abar´e: 1) The Installer Agent is used to select, from a list of
firmwares loaded in the Abar´e Core, the firmware compatible with the router. After the choice is made, the agent starts the recording process of the selected firmware in the router. Then, the Installer Agent be-gins the initial configuration of the router based on the information received from the Abar´e Core, such
Fig. 4. Installer Agente.
as IP address, network mask, ESSID, root password, etc. It also registers on the server database information regarding the newly added mesh node.
2) At this point, the node has been inserted into the network and it is operating normally with just a few pending maintenance tasks that can be done through the Manager Agent which uses the features offered by the Abar´e Core to manage the remote nodes. It is also possible to use scripts to automate repetitive tasks.
3) The collection agents begin a request to Router Agents where collectors perform the information collection re-quested and pass them to be stored by the DB Agent in a database previously specified.
There are a series of resources that can be aggregated by the framework, such as security and QoS management. However, these can be implemented through the Expander Module that allows an easy aggregation of characteristics initially not covered by the framework.
Through the conducted tests was possible verify that the framework can guarantee a solid basis for the deployment and administration phases and to allow that the framework answer the specifics needs of where the mesh network will be deployed.
To evaluate the solution’s scalability, have been performed load test in Abar´e Core. For that, we have been considered the worst case that occurs in the deployment step, when the Core needs to read the firmware from the database, to transform to base64 and to send via xml to Agent Installer. In testing the size of the firmware was 2.6 MB and the server was a Pentium 4, 3.0 Ghz with 1 GB of memory.
Tests were performed considering the number of 1, 5, 10, 20 and 40 requests. Figure 5 presents the values of the load of processing peak period of each set of requests.
The results shows that the server endured the 40 simulta-neous requests, generating a percentage of cpu load, equal to 52.4%. It is worth emphasizing that this is the worst case because of the great part of the xmlrpc requests to be exchanged by Abar´e shall not exceed 1 KB.
Figure 6 , on the other hand, presents the response time of the Core to requests made by customers, given the same sce-nario described above. It is possible to observe a curve almost linear, since all requests are performed without decreasing the system performance.
VI. CONCLUSIONS ANDFUTUREWORKS
The implementation, monitoring and management tasks are important to the network. Despite their importance, only the
Fig. 5. Abar´e Cpu Load
Fig. 6. Abar´e Request Time
monitoring and a few management tasks have been performed by the existing frameworks. In this paper we present Abar´e, the first framework for WMNs that takes into consideration these three aspects simultaneously.
This framework should encourage the development of man-agement tools since it provides the required theoretical basis for their creation, given that one of the biggest obstacles to large-scale deployment of Open Mesh Networks is the lack of tools that could assist in this process.
Abar´e makes possible the deployment and management of Open Mesh with a few number of steps, as discussed throughout the paper. These steps, besides being a small number, are simpler as they are conducted with the support of software which gathers and reuses a variety of information about the network.
The tests proved the feasibility of the framework to ac-commodate a high number of requests without producing an overload in the core. Thus facilitating the deployment and management of large-scale mesh networks.
As future work, we intend to implement a tool that includes all Abar´e’s features and to expand the modules already pro-posed including other modules such as user management tasks,
QoS, mobilite and security management. REFERENCES
[1] M. E. M. Campista and at All, “Routing metrics and protocols for wireless mesh networks,”Network, IEEE, vol. 22, no. 1, pp. 6–12, 2008. [Online]. Available: http://dx.doi.org/10.1109/MNET.2008.4435897 [2] I. of Eletrical and E. Engennering, “Ieee draft p802.11s d3.0.” IEEE
Unapproved Draft Std P802.11s/D3.0, Mar 2009, pp. –, 2009. [3] “Openwrt wireless fredom,” last accessed, June 2009. [Online].
Available: http://openwrt.org/
[4] “Dd-wrt,” last accessed, June 2009. [Online]. Available: http://www.dd-wrt.com
[5] “Vmesh - wireless network testbed,” last accessed, June 2009. [Online]. Available: http://vmesh.inf.uth.gr/
[6] J. F. Kurose and K. W. Ross, Computer Networking: A Top-Down Approach (4th Edition). Addison Wesley, 2007.
[7] E. Hossain and K. K. Leung,Wireless Mesh Networks: Architectures and Protocols, illustrated edition ed. Springer, December 2007. [8] Motorola, “Motomesh,” last accessed, June 2009. [Online]. Available:
http://www.motorola.com/statichtml/MOTOMESH Quattro.html [9] D. Harrington, R. Presuhn, and B. Wijnen, “An architecture for
de-scribing simple network management protocol (snmp) management frameworks,” United States, 2002.
[10] Cisco, “Cisco mesh products,” last accessed, June 2009. [Online]. Available: http://www.cisco.com/en/US/products/ps8368/index.html [11] O. O. Networks, “Order one networks mesh networking
products,” last accessed, June 2009. [Online]. Available: http://www.orderonenetworks.com
[12] K. Ramachandran, E. Belding-Royer, and K. AImeroth, “Damon: a distributed architecture for monitoring multi-hop mobile networks,” Oct. 2004, pp. 601–609.
[13] A. P. Jardosh, P. Suwannatat, T. H¨ollerer, E. M. Belding, and K. C. Almeroth, “Scuba: Focus and context for real-time mesh network health diagnosis.” in PAM, ser. Lecture Notes in Computer Science, M. Claypool and S. Uhlig, Eds., vol. 4979. Springer, 2008, pp. 162–171. [Online]. Available: http://dblp.uni-trier.de/db/conf/pam/pam2008.htmlJardoshSHBA08
[14] R. Riggio, N. Scalabrino, D. Miorandi, and I. Chlamtac, “Janus: A framework for distributed management of wireless mesh networks,” TridentCom 2007. 3rd International Conference on, 2007.
[15] Microsoft, “Mcl,” last accessed, June 2009. [Online]. Available: http://research.microsoft.com/mesh/
[16] S. Nanda and D. Kotz, “Mesh-mon: A multi-radio mesh monitoring and management system,”Comput. Commun., vol. 31, no. 8, pp. 1588–1601, 2008.
[17] A. Capone, M. Cesana, S. Napoli, and A. Pollastro, “Mobimesh: a complete solution for wireless mesh networking,” IEEE International Conference on Mobile Adhoc and Sensor Systems Conference, vol. 0, pp. 1–3, 2007.
[18] R. Badonnel, R. State, and O. Festor, “Management of mobile ad hoc networks: information model and probe-based architecture,”Int. J. Netw. Manag., vol. 15, no. 5, pp. 335–347, 2005.
[19] O. Cheikhrouhou and M. L. Maknavicius, “Security architecture in a multi-hop mesh network,” June 2006.
[20] “Openrouter,” last accessed, June 2009. [Online]. Available: http://www.myopenrouter.com
[21] N. Tsarmpopoulos, I. Kalavros, and S. Lalis, “A low-cost and simple-to-deploy peer-to-peer wireless network based on open source linux routers,” pp. 92–97, 2005.
[22] “Openwrtdocs – openwrt documentation,” last accessed, June 2009. [Online]. Available: http://wiki.openwrt.org
[23] M. Lenczner, “Wireless portals with wifidog,”Linux J., vol. 2005, no. 140, p. 8, 2005.
[24] I. F. Akyildiz, X. Wang, and W. Wang, “Wireless mesh networks: a survey,”Comput. Netw. ISDN Syst., vol. 47, no. 4, pp. 445–487, 2005. [25] J. Dollimore, T. Kindberg, and G. Coulouris, Distributed Systems: Concepts and Design (4th Edition) (International Computer Science Series). Addison Wesley, May 2005. [Online]. Available: http://www.amazon.ca/exec/obidos/redirect?tag=citeulike09-20&path=ASIN/0321263545
[26] V. Cardellini, M. Colajanni, and P. S. Yu, “Dynamic load balancing on web-server systems,”IEEE Internet Computing, vol. 3, no. 3, pp. 28–39, 1999.
