MeshMon: a multi‐tiered framework for wireless mesh network monitoring

Abstract

Monitoring and troubleshooting a large wireless mesh network (WMN) presents several challenges. Diagnosis of problems related to wireless access in these networks requires a comprehensive set of metrics and network monitoring data. Collection and offloading of a large amount of data are infeasible in a bandwidth constrained mesh network. Additionally, the processing required to analyze data from the entire network restricts the scalability of the system and impacts the ability to perform real-time fault diagnosis. To this end, we propose MeshMon, a network monitoring framework that includes a multi-tiered method of data collection. MeshMon dynamically controls the granularity of data collection based on observed events in the network, thereby achieving significant bandwidth savings and enabling real-time automated management. Our evaluation of MeshMon on a real testbed shows that we can diagnose a majority (87%) of network faults with a 66% savings in bandwidth required for network monitoring.

Experience from testbeds and management platforms towards mesh networking with heterogeneous wireless access

“…KAUMesh [22] is a multiRadio, multiChannel mesh testbed that does combine the common monitoring tool Nagios with custom plugins and incorporates OpenFlow in order to exploit the mesh networking advantages. MeshMon [23] is a network monitoring framework that uses a multi-tiered method of data collection and employs dynamic control of the data collection granularity based on observed events in the network, achieving significant bandwidth conservation and enabling real-time automated management. Another open-source mesh deployment server called OrangeMesh [24] is compatible with Open-Mesh and mesh devices running RO.B.IN.…”

Distributed trigger counting algorithms for arbitrary network topology

“…More specifically, while receiving increase j .w j / for j ¤ i, p i first checks whether dynamic variable latest_received j i has been allocated; if not, p i knows that it has never received a message originating from p j , that is, it is the first time for p i to receive such a message. In this case, p i allocates memory space for latest_received j i to store the value of w j carried on this new message (lines [10][11][12]. Moreover, because we assume that the time for a message to diffuse throughout a considered network is much less than that between the receipt of two continuous triggers from external sources, it is not difficult to verify that the value of w j denotes the number of triggers that p j has received so far.…”

“…The distributed trigger counting (DTC) problem is a basic block for many distributed applications, such as monitoring [1][2][3][4][5][6][7][8][9][10][11][12][13][14][15], global snapshots [16][17][18][19][20][21], and synchronizers [20,21]. Among these applications, monitoring is the most important one.…”