[Battlemesh] Collaborate on TDMA development

Paul Gardner-Stephen paul at servalproject.org
Mon Oct 22 20:55:21 UTC 2012


Hello,

This sounds pretty interesting.

A related project we have been looking at prototyping for Serval for a
while now is to make an
interesting frequency-hopping (and thus TDMA) system for using some of
the ISM bands for
mesh communications.

Probably easiest explained with a little diagram and example.

Imagine a band with 4 available channels, A,B,C & D, (in reality it
would probably be more like 100, e.g., for the ISM915MHz band here in
Australia or in the USA, but it could also be done over 2.4GHz).

Regulation or otherwise requires frequent frequency hopping, but with
the loop-hole that a transmitter can TX on a single channel for a
relatively long time (longer than the typical frequency hopping time
slice), but only occasionally.

We generate an appropriate frequency hopping pattern (for now we will
just use A,B,C then D for simplicity).  The tricky part is getting
multiple nodes synchronised onto it.

We want to reduce idle power consumption, so each station offers only
to listen on a certain duty cycle. So Nodes 1 & 3 might only listen on
A & C time slots, while Node 2 & 4 might only listen on B & D time
slots.

Now if Node 1 wants to send to Node 2, it waits until channel B or D
is the next channel in the hopping sequence, then begins to transmit
its packet.  Let's assume that channel B comes up next.

Here is the fun part, the packet may take longer than the time slot
allocated to channel B -- it just keeps transmitting on channel B, and
Node 2 keeps listening.

But Node 4 who would also have been listening on channel B, stops
listening as soon as it hears that the packet is not addressed to
itself.

Now Node 4 decides it wants to talk to Node 3.  It can do that when
channel C comes up in the hopping pattern.  Now node 4 is TXing to
node 3 on channel C, and continues to do so, possibly for more than
one time slot.

At this point, both node 1 and node 4 are TXing at the same time at
full-rate, and without interfering.  We effectively have created
"hyper-threaded radio".

There are some obvious limitations, but it has some quite nice properties:
1. each channel is relatively low bit rate, so listen power will be
lower, and link margin will be better at a given TX power;
2. many devices can be transmitting on the channel at the same time
without interfering;
3. can probably be done with a very simple modulation like GFSK.

This is in contrast to WiFi where each channel uses multiple carriers
and tricky encoding to get high overall bandwidth, but optimised for
the two-station case, and then decaying, and eating energy like crazy.

We know that ad-hoc WiFi on modern phones takes about 0.35W, excluding the CPU.
In contrast, something like this using a HopeRF RFM22B or similar, and
assuming a TX duty-cycle of 10% and RX/listen duty cycle of, say, 25%
would give a power budget of:

TX = 10% x 85mA x 3.3v =  0.028VA ~= 0.028W
RX = 25% x 18.5mA x 3.3v = 0.016VA ~= 0.016W
total = ~0.045W, almost 10x less than WiFi

And for the ISM 915MHz band at least, there is about +5-6db gain
compared to WiFi just due to propagation characteristics. Then if we
use 100kbit/channel instead of 1Mbit we get another +10db for about
+15db.  If we used 1W instead of 100mW (this is possible for ISM915
band), then it becomes +25db versus WiFi.  All up the range can thus
be much greater than WiFi, possibly >16x @ 1W/915MHz, or about 2-3x @
100mW/2.4GHz.

Paul.

On Tue, Oct 23, 2012 at 6:38 AM, Gui Iribarren <gui at altermundi.net> wrote:
> Hello people,
> in several chats with NicoEchaniz, we end up concluding it would be
> wonderful to have a libre TDMA implementation for mac80211, so that
> ath9k and other current drivers can partially overcome the awful
> performance issues of a shared medium.
>
> AirOS does a wonderful job when handling several hidden stations, but
> it's unfortunately a propietary software solution. Flashing OpenWRT
> opens the box of possibilities in terms of software but severely
> impacts radio performance.
>
> We think solving this would greatly benefit the wireless community
> networks worldwide, and several attempts / achievements have been made
> in the past. Sadly, the solutions are now outdated, or were absorbed
> by private companies at some point in the development cycle.
> A key problem in the past was the lack of a uniform stack like
> mac80211 provides, so the implementations were tied to one particular
> driver (madwifi for example) and had to be reinvented / ported when
> that driver was abandoned / deprecated.
>
> So, what do you think about coding a TDMA solution for mac80211 stack?
> Are there any current projects that are already on this track, that we
> haven't come accross?
> If a team is formed, we could propose the idea for an NLNET /
> shuttleworth / etc grant.
>
> Background / Past efforts linkdump:
>
> projects: jazzymac, srawan, JaldiMAC, wildmac, fractel, 2P. LiT,
> WiLDnet,karlNet TurboCell, wiccp, frottle, nstreme, oswave
>
> http://patraswireless.net/software.html
> http://wafreenet.org/Frottle
> http://www.netequalizer.com/Hidden_Node_White_Paper.php
> https://github.com/shaddi/jaldimac
> http://tier.cs.berkeley.edu/drupal/node/128 (wildnet)
> http://tier.cs.berkeley.edu/drupal/wireless
>
> frottle ipkg (old)?
> http://www.ipkg.be/repositories/26
>
> a possible design on frottle for meshes
> http://www.melbournewireless.org.au/wiki/?MWRPAdhocFrottleDev
>
> tdma on freebsd by sam leffler
>
> AirJaldi
> http://drupal.airjaldi.com/blog/
> http://drupal.airjaldi.com/
>
> nice summary of experiences
> http://wiki.airjaldi.org/tiki-index.php
>
> AirJaldi Bandwidth Maximizer (BwM)
> http://drupal.airjaldi.com/node/264
> http://drupal.airjaldi.com/node/265
> _______________________________________________
> Battlemesh mailing list
> Battlemesh at ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/battlemesh


More information about the Battlemesh mailing list