MAD
The Mesh Adaptation Daemon (MAD) is a simple daemon that collects mesh statistics from the driver and responds to the changes in the radio environment by adjusting the operating parameters according to some predefined recipes.
Contents
Overview
From a functional point of view, it 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, congested, not congested; battery powered, ac powered; low powered, etc...). An example of a status in current terms would be: AC-powered, fixed, dense, congested.
- 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 current mesh STATUS. Data sources include:
- ioctls
- pseudo file systems (procfs, sysfs, debugfs)
- other daemons
Irrespective of the mechanism used to detect it, each item probed will be a VARIABLE. One example, is the number of active neighbors as inferred from the forwarding route.
Configuration Module
This modules reads a configuration file that has three parts:
Collectors parts
This section defines a list of VARIABLES and which collector (an external command) is responsible for determining the VALUES for this variable.
Characterization section
- A list of AXISes with respective LEVELs. Example: The Power axis could have the following levels: AC powered, Battery powered 90+ full, battery powered 70+ full, and so on. These levels can be identified numerically or by a mnemonic (AC, FULL, MEDIUM, LOW, CRITICAL)
Possible axises:
- Denseness: 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.
- 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).
- 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 totally concrete (like CONGESTED) and may be formed by one or many axises.
Action Section
- Directives that associate STATUS with ACTIONs. For example, in a congested
- 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> ... AXIS <AXIS_N_NAME> AXIS_LEVEL <AXIS_1_NAME> <LEVEL_1> <VARIABLE_1> <VALUE_X> ... <VARIABLE_M> <VALUE_Y> ... AXIS_LEVEL <AXIS_1_NAME> <LEVEL_N> <VARIABLE_1> <VALUE_P> ... <VARIABLE_M> <VALUE_Q> ... ... AXIS_LEVEL <AXIS_N_NAME> <LEVEL_1> <VARIABLE_1> <VALUE_X> ... <VARIABLE_M> <VALUE_Y> ... AXIS_LEVEL <AXIS_N_NAME> <LEVEL_N> <VARIABLE_1> <VALUE_P> ... <VARIABLE_M> <VALUE_Q>
STATUS <STATUS_TYPE> <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.
