MAD Architecture

NOTE: The contents of this page are not set in stone, and are subject to change! This page is a draft in active flux ... Please leave suggestions on the talk page.

This page contains a proposed modular view for the Mesh Adaptation Daemon (MAD), which includes a description of itc configuration syntax.

Overview

From a functional point of view, MAD consists of the following modules:

• Collector Module - responsible for gathering all useful information (STATUS) upon which adaptation decisions will be performed
• Configuration Module - reads the STATUS CHARACTERIZATION and ADAPTATION RULES from a configuration file. The former characterizes an STATUS and the latter determines what ACTION should be performed for each given STATUS. STATUS are divided into AXISes (example: power, mobility, etc). At any given point in the time, an AXIS will have a LEVEL. For example, the Power Axis can assume the levels: ac powered; battery powered high, battery power medium, ..., battery powered critical. We would loosely refer to a status as a combination of LEVELs (where each level is implicitly related to an AXIS). An example of a status would be: AC-powered (Power), fixed (Mobility), dense (Denseness), congested (Congestion).
• Action Module - implement the ACTIONS i.e. change parameters on the mesh to adapt to the current status.

Collector Module

This module periodically (synchronously) polls data from many sources in order to determine the current mesh STATUS. Data sources include:

• ioctls
• pseudo file systems (procfs, sysfs, debugfs)
• other daemons (avahi, etc)

Irrespective of the mechanism used to detect it, each item probed will be a VARIABLE. One example, is the number of active neighbors that can be inferred from the forwarding route.

Configuration Module

This modules reads a configuration file that has three parts:

Collectors section

This section defines a list of VARIABLES and which collector (an external command) is responsible for determining the VALUES for this variable.

Characterization section

1. A list of axises with respective LEVELs. Example: The Power axis could have the following levels: AC powered, Battery powered 90+, battery powered 70+, and so on. These levels can be identified numerically or by a mnemonic (AC, FULL, MEDIUM, LOW, CRITICAL)

Possible parameters (each is an axis):

• Density: Determines the concentration of nodes within the interference (or carrier sensing, or transmission) range
• Congestion: Determines current (short termed) spectrum usage (airtime availability)
• Power: Determines if the node is AC powered or battery powered, and if the battery is FULL, LOW, etc.
• Mobility: Determines if the node is mobile and the general mobility of the mesh.

1. LEVEL characterization. What makes an axis assume a given level. For example: a battery less than 30% full characterizes the level CRITICAL, for the axis POWER. So, a LEVEL will be characterized for a group of VARIABLEs each with certain VALUES (ranges, where applicable).

1. STATUS characterization. Associates a STATUS with a (sub)set of axis that meet certain levels. STATUS may be very abstract (like IN-SCHOOL status) or more concrete (like CONGESTED) and may be formed by one or more axises.

Action Section

1. Directives that associate STATUS with ACTIONs. For example, in a congested network do not lower data rates and/or increase the contention window

1. Specification of the ACTIONs. Probably a command that will implement the desired adaptation.

Action Module

The action module is responsible for reading the status and act accordingly.

Configuration file syntax

A first idea for the configuration file syntax:

variable <VARIABLE_1_NAME> <COLLECTOR_1>
...
variable <VARIABLE_N_NAME> <COLLECTOR_N>
 
axis <AXIS_1_NAME> {
 <LEVEL_1_NAME>{<VARIABLE_1> <VALUE_X>; ... ;<VARIABLE_M> <VALUE_Y>}
 ...
 <LEVEL_2_NAME>{<VARIABLE_1> <VALUE_X>; ... ;<VARIABLE_M> <VALUE_Y>}
}

axis <AXIS_N_NAME> {
 <LEVEL_1_NAME>{<VARIABLE_1> <VALUE_X>; ... ;<VARIABLE_M> <VALUE_Y>}
 ...
 <LEVEL_2_NAME>{<VARIABLE_1> <VALUE_X>; ... ;<VARIABLE_M> <VALUE_Y>}
}

status <STATUS_1_NAME> <AXIS_X_NAME> <LEVEL_K> ... <AXIS_Y_NAME> <LEVEL_R>
...
STATUS <STATUS_TYPE> <STATUS_N_NAME> <AXIS_X_NAME> <LEVEL_K> ... <AXIS_Y_NAME> <LEVEL_R>

ACTION <ACTION_1_NAME> <COMMAND_1>
...
ACTION <ACTION_N_NAME> <COMMAND_N>

ADAPT <STATUS_NAME> <ACTION_1> ... <ACTION_N>

STATUS TYPE, can be "detected" or "user". So, users actions (like clicking on an icon) can characterize status. OR *** a user can inform a status, so it is not necessary to have the status_type

An example

variable act_neigh /usr/bin/active_neighbors.py
variable power /usr/bin/power.py

axis density {
 alone{act_neigh=[0]} 
 end(act_neigh=[1]}
 sparse{act_neigh=[2-3]} 
 low{act_neigh=[4-5]}
 medium{act_neigh=[6-8]}
 dense(act_neigh=[9+]}
}
axis power {
 ac{power=[0]}
 battery{power=[1+]}
 battery_full{power=[90-100]}
 battery_high{power=[70-89]}
 battery_medium{power=[50-69]}
 battery_low{power=[30-49]}
 battery_critical{power=[1-29]}
}

status fixed power[ac]; perrs[medium
status low_battery[battery_low or battery_critical]

action increase_metrics /usr/bin/metrics.py 800 1000 1900 3900
action decrease_metrics /usr/bin/metrics.py 700 900 1800 3800 

adapt low_battery increase_metrics
adapt fixed decrease_metrics

Here is the problem (a node can be fixed and low_battery.

Using MAD

MAD behavior will be determined by its configuration file mad.conf, but it is also possible to inform (force) a given status