Tagus Mesh Network - Application











Final Version

Web server: Tagus Mesh Network Application

Introduction

In order to give a simple and organized interface, a web application of the Tagus Mesh Network was created. This front-end is the first contact with the testbed, where a user can easily perform a set of experiments with different protocols and tools.

Until now, it is possible to use three different routing protocols which are:

  • HWMP from 802.11s
  • B.A.T.M.A.N Advanced
  • OLSR

Also, there are available 3 different bench-marking tools (ping, iperf) aiming the analysis of some important network characteristics like RTT, bandwidth, jitter and the datagram loss. In addition to these tools there is the TCPdump which tracks any experience made in the testbed.

Since a link path between two nodes is conditioned by the metrics and decisions of the routing protocol used which tends to choose the best path, it is useful to force different routes. This action allows the analysis of the protocol behavior under different circumstances. Thus, the TMN web application helps the user to easily create a different path between two nodes.

Routing Protocols

The way that the routers of a WMN communicate with each other is determined by routing protocols.

HWMP

Hybrid Wireless Mesh Protocol (HWMP) is a routing protocol defined in IEEE 802.11s. In order to add WMN as an amendment for IEEE 802.11 standard, IEEE published 802.11s which standardizes a new mesh architecture, defining a new type of network topology called Mesh Basic Service Set (MBSS). This protocol can operate in two modes: on-demand reactive mode and tree-based proactive mode. On-demand mode is appropriate to establish a path between Mesh STAs in a peer-to-peer basis, while in proactive mode, a tree-based topology is calculated once a Mesh STA announces itself as a root. The tree-based approach can improve path se- lection efficiency when there is a tendency for forwarding significant portions of network traffic to some specific nodes. In contrast, on-demand approach always provide the optimal path between two nodes but the efficiency of this approach is damaged by the initial latency required to find the that path.

OLSR

OLSR (RFC) is a link-state routing protocol. This requires each node to maintain the topology of the network in full. To ensure that the topology is available to all the nodes, link-state protocols generally perform topology flooding, in which certain nodes are responsible for transmitting the current state of the network to all other nodes. Each node is thereafter responsible for computing the best route for a packet to its destination. In OLSR the best route is considered as that with the least number of hops. This means that a route via a single very bad link is preferred to a route via two excellent links, although the latter is probably the better choice.

B.A.T.M.A.N

B.A.T.M.A.N (Wiki) use a simple and robust algorithm for establishing multi-hop routes in mobile ad-hoc networks. The approach of this algorithm is to divide the knowledge about the best end-to-end paths between nodes in the mesh to all participating nodes. In contrast to OLSR, each node perceives and maintains only the information about the best next hop, in terms of link quality, towards all other nodes. Thereby the need for a global knowledge about local topology changes becomes unnecessary. The importance of this fact is highlighted when a WMN comprises hundreds of nodes, where the time to recalculate the whole topology can be dramatic. The B.A.T.M.A.N implementation installed on the Tagus Mesh Network is the Advanced version which operates on the layer 2.

Tutorial

Download

User's Tests

Download

Screenshots

ss1.png: 1049x358, 65k (August 08, 2013, at 11:24 PM)
Layout Scheme
ss2.png: 1070x431, 72k (August 08, 2013, at 11:24 PM)
Reservation Scheme
ss3.png: 721x510, 131k (August 08, 2013, at 11:25 PM)
Network Map
ss4.png: 630x417, 27k (August 08, 2013, at 11:25 PM)
Configuration
ss5.png: 637x563, 84k (August 08, 2013, at 11:25 PM)
Protocol Settings
ss6.png: 289x234, 14k (August 08, 2013, at 11:25 PM)
Manual Routing
ss7.png: 811x261, 40k (August 08, 2013, at 11:25 PM)
Tests' Creation
ss8.png: 1035x395, 50k (August 09, 2013, at 12:14 AM)
Experiment's Results
ss9.png: 576x338, 37k (August 09, 2013, at 12:14 AM)
Graphic
* --nm1.png (User Site Map)