MAD Architecture

From OLPC

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.

[edit] 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.

[edit] 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.

[edit] Configuration Module

This modules reads a configuration file that has three parts:

[edit] Collectors section

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

[edit] 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.

[edit] 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.

[edit] Action Module

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

[edit] 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

[edit] 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.

[edit] Using MAD

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