Context Navigation

Project Documentation Roadmap

This page provides (at the end) a structured view of a subset of the project documentation in the repository. This subset is probably the best to read, in the indicated sequence, if you are trying to get familiar with the project, moving on to gain a detailed understanding of each module. . To provide the context for the documents, we first provide below a brief overview of CentMesh? software architecture.

CentMesh? Software Architecture

The CentMesh? testbed is a centralized control system where one of the mesh node is assigned the role of the controller. Though the underlying CentMesh? software remains the same on every node, different services are started depending on whether a node is a controller node or a mesh node. Different from other current state-of-art testbeds, we do not deploy any wired backhaul using Ethernet to connect and control the nodes. Instead control messages flow between nodes using one of the radios (fixed but not dedicated) operating on a fixed channel. Researchers can write their own modules, create testing scripts and distribute them to mesh nodes. At the end of the experiments, similar automated services are provided to gather the experiment output and analyze the results. CentMesh? testbed design modularizes and clearly separates functionality in data, control and management planes. The modules are divided into system modules, core modules and extension modules. System modules provide basic functionality like transport of control messages, broadcast services, topology management etc. Also, researchers are provided with a modular programming library which they can use to write their own modules (core modules such as routing, channel assignment, power control etc.) and plug them in and out of the network stack. Apart from the large set of system modules, CentMesh? software suite also provides following OAM modules which are necessary for Operations, Administrations and Maintenance.

System Modules

These modules are implemented as a part of the system software and are provided to the experimenters. They are an indispensable part of the CentMesh? software that is always present and running on mesh nodes irrespective of type of experiments.

Communicator: All control and signaling traffic between mesh nodes is channeled through the communicator module. It provides reliable communication (using TCP connections) between various core modules and enables distributed design in a loosely coupled manner. Fig. 1 shows how the communicator works as an entry/exit point between various processes running on different mesh nodes.

Fig.1 CentMesh? software architecture

Reporter and Disseminator: Build on top of communicator, reporter provides a unicast reporting functionality which can be used by mesh nodes to report various data to the controller. Similarly, disseminator acts as a flooding agent which can be used by a mesh node (typically controller) to broadcast information to other mesh nodes. Researchers can create their own messages with necessary information and can report/disseminate them easily using reporter and disseminator. This way, these two modules provide routing of messages for the control plane.

Neighbor Discovery: One of the most common requirements of any protocol design is correct detection of physical layer topology. The neighbor discovery process on a mesh node periodically probes its neighbors and gathers the local neighborhood information. All nodes report the neighbor information to the controller, which then realizes the entire network topology.

Bootstrap Routing: Based on the current network topology, controller node computes a simple and robust set of routing paths which are then distributed to the mesh nodes for actuation. Such a routing is necessary for example when experimenter’s core module does not deal with routing at all and relies on system modules to establish and maintain the routes.

Data Repository: The controller node maintains a database which contains virtually every information regarding the network (link states, node status etc.). The information is periodically refreshed by various system modules. Information in the database is made available as input to the management algorithms of core modules. This way, the data repository acts as decoupling intermediary between various data collections and dissemination procedures.

System Crash and Recovery: It is possible that the modules developed by researchers can create software failures or traps which requires a systematic method of recovery. To address this, every CentMesh? node contains three separate Linux installations in three different disk partitions. CentMesh? uses Fedora 9 Linux distribution (together with all development and server packages) as the operating system in all 3 partitions.

The first partition (referred as fail-safe) contains a minimal set of functionality which allows users to remotely access the node and recover it. The second and the third partitions are in general open to the researchers to perform their experiments. In case of system crash during the experiments, researcher can use the fail-safe mode to make changes to any other partition and resume their experiments. The access to the fail-safe mode by researchers is limited for the purpose of recovery and the fail-safe mode in general is maintained by the CentMesh? administrator. The routing is statically configured for fail-safe partition which allows remote access to a crashed node (recall that there is not Ethernet backbone in CentMesh?).

In the second and third partitions, experimenters are free to perform their development and tests. It is highly likely that core module(s) developed by a user are part of user space (and not the kernel space) in which case no modification to provided Linux kernels are necessary. Examples of such modules are given below. If the experiment requires modification of kernel image (e.g. to add a kernel module), user can create their own kernel images and replace the existing ones provided by CentMesh?. Since the resources are shared by many experimenters, it is advisable for users to make fewer changes to actual root file system of any partition.

All the above mentioned system modules are made available to the researchers as part of the CentMesh? software suite. Using these modules and the development API, researchers can easily write their own core modules.

Core Modules

We use publish/subscribe relationship to allow various core module processes on different mesh nodes to send and receive messages to each other based on the topic names. Current publish/subscribe mechanism is implemented on the top of communicator which maintains a directory of known topics and respective subscriptions. Such topic-based message filtering in publish/subscribe model creates logical channels in the network-wide control path which provides greater flexibility and scalability compared to a typical client-server model. The management modules (or core modules) are implemented as paired managers and agents. The manager component of a core module resides typically on the controller node while the agent component is functional on mesh nodes. The manager of a core module contains the central intelligence/algorithm of the protocol. The agents on the other hand are light-weight which gather necessary information for input to the manager algorithm and perform actuating tasks based on manager’s decisions. As an example, a newly written core module (see Fig. 1) for routing contains a routing manager (residing as a process in the controller) and a routing agent (in mesh nodes). The routing manager calculated the set of routing paths based on any specific strategy and distributes the routing paths to different nodes. The routing agents on different nodes which have subscribed to the particular topic of routing receive the route decisions and set the routes on the mesh nodes accordingly. Again, the actual transport of control messages such as routing messages from manager to agents is performed using preexisting system modules.

Hence, a core module is a module developed by the researcher to perform experiment. Following core modules are also developed as sample core modules for the purpose of reuse and demonstration. They may be replaced by experimenters by their own modules, but some routing module, some channel assignment, etc. must always be present. As an example, an experimenter who is not dealing with routing can reuse readily available routing module for the experiments.

Routing: The routing considers ETT (Expected Transmission Time) of links as the metric for route calculations. It is well-known that ETT based routes achieve significantly better throughput than simple hop-count based routing paths. The routing agent on each node gathers ETT values of links and reports back to controller node. The controller node collects the data and puts it into the database. The routing manager operating on controller node retrieves the data and runs the routing algorithm to determine feasible set of paths. The routes are then distributed to all nodes and the entire process is repeated periodically.

Channel Assignment: Similar to routing module, the channel manager uses greedy edge coloring algorithm on the network topology graph and determines the channel for each radio. The current channel assignment mechanism is static and runs only once at the start of experiments.

OAM Modules

Apart from the large set of system modules, CentMesh? software suite also provides following OAM modules which are necessary for Operations, Administrations and Maintenance.

Network Monitoring: A separate network monitoring module (design similar to core modules) run constantly in background which collects large set of network status information and reports it to the controller. The purpose of designing such a monitoring module is to facilitate exhaustive information about every possible network event/state to the researchers while they are performing the experiments. The monitoring module is completely customizable which allows researchers to control what information they want to be reported and at what intervals. In its simplest form, researchers can specify a set of commands (e.g. iwlist, iwconfig etc.) to the monitoring manager which then periodically runs them on different mesh nodes using monitoring agents.

Visualization: Apart from user customizable information collection, monitoring module contains a fixed set of basic routines which are run periodically to gather network state information. These include node status information, link interference information, topology information and current routing paths. A separate visualization program (Fig. 1) is provided which runs on the controller. The visualization program extracts the information provided by monitoring manager and converts it into KML format. The KML files are then used to visualize the network status information on geographic maps using Google Earth. Such visualization helps the researchers to quickly understand and interpret the monitoring information from a remote client.

Testing Module: Once the users have developed their own core module and configuration, a set of common testing utilities can be used to perform the evaluation. Basic set of utilities like traffic generator, synchronization, logging etc. are provided to experimenters to assist them with the testing. Also, the researchers can customize the testing module to run any tests between mesh nodes as per the interest and can control/monitor them from the controller node.

Above mentioned description provides high level overview of the software architecture. The more detailed view of the various software modules can be found in Fig. 2.

Now, with general understanding of different modules and how they interact, more detailed documentation of each individual module can be explored. The following provides a roadmap of studying these documents - starting from downloading the centmesh software to performing various experiments on network.