[Commotion-dev] Draft Roadmap

Ben West me at benwest.name
Tue Aug 9 08:37:24 UTC 2011


Hi All,

I am glad to read about progress for Commotion.

This was my proposal sent many moons ago to the OLSR listserv for a new
plugin to efficiently tweak TX power, and I am reposting here. Comments
encouraged ...

---

In follow up to the Commotion code sprint / conference that just occurred:
http://tech.chambana.net/projects/commotion
http://tech.chambana.net/projects/commotion/wiki/JUNE_2011_CODE_SPRINTSUMMIT
... we discussed a potential OLSR plugin that would gradually turn down a
node's TX poweruntil a minimum specified LQ was reached by one of that
node's 2-hop neighbors.

The primary use case for this plugin is to support a mesh of primarily low-
power / battery-power devices (smart phones, laptops, tablets) being used by
democratic activists as a secure and reliable communications platform that
is difficult to be controlled or cut off by authoritarian regimes.

In this use case, low TX power is ideal, as it prompts longer routes and
more hops through mesh, making the identification of a packet's source more
difficult.  Likewise, lower TXpower makes a node more difficult to detect /
eavesdrop.  I understand this use case does run counter to convention, in
particular sacrificing throughput and reliability for longer routes.

Although, I would expect this plugin could be generalized to also provide
some measure of tx power vs. interference optimization in more typical
meshes.

Below is a very rough, psuedo-code-ish spec for this plugin resulting from
discussion with conference attendees.  I am planning on doing a
proof-of-concept implementation of this plugin to try out in a small mesh,
and comments, suggestions, criticisms, and witticisms (especially funny
ones) are welcome.

*Functional spec:*
- Gradually turn down TX power until reachability of 2-hop neighbor degrades
below specified LQ
- Node beacons its config to 2-hop piers to tell neighbors not also turn
down their tx pwr at the same time
*
*
*Operational params:*
- minLQ (int): minimum LQ for 2-hop neighbors
- period (int): time period for TX power adjustments
- beaconCfg (bool): enable beaconing of config to neighbor nodes
- battery (bool): node running on battery?
- upCmd / downCmd (string): commands for raising / lowering TX power (a bit
hackish, but different radios may not all support iw and/or iwconfig)
- delta (int): delta for changing TX power, e.g. 1dB, 2dB
- oprhanTxPwr (int): Nominal TX power level for isolated nodes (may be 0?)
- neighborCheck (int): time period when an isolated node powers up tx to
check for new neighbors

*Edge case:*
- Battery-powered (or even wire-powered?) node with no visible neighbors
should eventually turn down (or turn off?) its transmitter.  Turn TX power down
to orphanTxPwr, and periodically power back up on interval neighborCheck to
check if a neighbor has appeared
--> collect these settings into config profiles for laptoppers to select
from desktop, e.g. lowest power, normal, max throughput


On Wed, Jul 27, 2011 at 8:07 AM, Josh King <joshking at newamerica.net> wrote:

> Hey everyone,
>
> I have published a draft roadmap for the project at:
>
> http://tech.chambana.net/projects/commotion/wiki/roadmap
>
> This is rough so far (and software focused, still working on adding in
> more documentation and outreach tasks), but I think serves to give an
> overall view of how the project is laid out and where it's heading.
> Recognizing that the project is made up of a large number of different
> pieces on different platforms, I've made a few structural decisions as
> far as the roadmap (and a coincident refactoring of the website):
>
> * The project has been re-structured into a number of subprojects, as it
> didn't make sense to me to put a large number of projects with
> substantially different codebases into one git repository. I realize
> that if we end up having a large shared codebase at the end then we may
> want to re-integrate, or create a shared repository drawn on by all
> sub-projects. Other people may have other takes on this. In any event,
> there are subprojects "Commotion-Openwrt", "Commotion-Android",
> "Commotion-Windows", etc. I hope that this will also help to clarify
> confusion between Commotion the overarching project and Commotion the
> OpenWRT embedded firmware (now Commotion-OpenWRT). All issues from
> subprojects are visible in the existing "Commotion" superproject.
>
> * The roadmap is structured into a number of 'releases.' The first one
> is a pre-release at the end of October, which will serve simply to pull
> together all of the disparate software elements in their current form,
> as well as give me some time to work on some features for the
> Commotion-OpenWRT firmware to bring it up to feature parity with some
> other firmwares out there in order to make it more useful to the
> community networks we're working with to deploy and test it. Past that,
> there are 4 "Developer Releases" which are split up in roughly 2-month
> increments through the year, with a "Finished Release" next summer. I
> structure it in this way to recognize that we need some general
> milestones to hit, but that each piece of component software has its own
> versioning and there's no need to try and change that, and the DR1-4
> naming scheme is not likely to strongly conflict with any other
> versioning scheme in use. Feedback around this is welcome, and the
> timeline is likely to change slightly as the release date as required by
> OTI's Internet Freedom grant award is predicated on when we actually get
> the check from the US State Department, which is not yet.
>
> I'm currently still putting items from the roadmap into the issue
> tracker as it makes sense, and adding users from the existing project
> into the subprojects (Redmine doesn't automatically migrate them).
> People should feel free to add to the roadmap for now, just ping the
> list when you do so to help me keep track of what's changed.
>
> --
> Josh King
> Technologist
> Open Technology Initiative
> New America Foundation
>
>
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> http://lists.chambana.net/mailman/listinfo/commotion-dev
>
>


-- 
Ben West
me at benwest.name
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20110809/1ceb93df/attachment-0002.html>


More information about the Commotion-dev mailing list