<div dir="ltr">Thank you for the pointer to JaldiMAC! Looks it is/was indeed a rough equivalent of AirMAX for 802.11n Atheros radios.<br><br>Unfortunately, I think the JaldiMAC trail goes cold here. No updates to this repo I found since 3 years:<br>
<a href="https://github.com/shaddi/jaldimac/commits/master">https://github.com/shaddi/jaldimac/commits/master</a><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 18, 2014 at 11:10 AM, fboehm <span dir="ltr"><<a href="mailto:fboehm@aon.at" target="_blank">fboehm@aon.at</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 18.02.14 17:40, schrieb Mitar:<div><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi!<br>
<br>
I think using TDMA would help here. Each client would reserve its time<br>
slot and it would not matter how strong they transmit in their time slot.<br>
<br>
Sadly open source drivers do not (yet) support TDMA. But Ubiquiti ones do.<br>
<br>
<br>
Mitar<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm curious if list members have found clever approaches for operating mesh<br>
nodes that must talk simultaneously to near/strong clients and far/weak<br>
clients. I've found that, at least with atheros / ath5k-based nodes<br>
running OpenWRT AA r39154, which do single-radio meshing via multiple VIFs,<br>
connecting a particular strong client to the AP VIF of one node can disrupt<br>
that node's communication with a distant node on the adhoc VIF. Admitted,<br>
the ath5k driver is pretty suboptimal, but its weakness does at least<br>
demonstrate the nature of the problem easily.<br>
<br>
This problem is less pronounced with ar71xx-based nodes, e.g. UBNT Airmax<br>
gear, and I do understand it is going to fundamental to single-radio<br>
meshing applications anyway (i.e. hidden node problem). Likewise, one<br>
can't always control clients' TX strength, besides mounting nodes at<br>
locations such that a client can never be physically too close, e.g. on a<br>
rooftop or high on an exterior wall.<br>
<br>
Acknowledging the limits of the radios, I'm curious if anyone has had<br>
reasonable success in these situations with things the following:<br>
<br>
- RF-Armor style shielding on the back of the mesh node, i.e. to reduce the<br>
influence of stray noise or reflections<br>
- Setting an RTS value<br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
Battlemesh mailing list<br>
<a href="mailto:Battlemesh@ml.ninux.org" target="_blank">Battlemesh@ml.ninux.org</a><br>
<a href="http://ml.ninux.org/mailman/listinfo/battlemesh" target="_blank">http://ml.ninux.org/mailman/<u></u>listinfo/battlemesh</a><br>
<br>
</blockquote>
<br>
</blockquote></div></div>
It's quite a while since I read it but you might want to have a look at "JaldiMAC". It's kind of a 802.11 based polling protocol.<br>
<br>
<a href="http://matthias.vallentin.net/papers/nsdr10.pdf" target="_blank">http://matthias.vallentin.net/<u></u>papers/nsdr10.pdf</a><br>
<br>
By the way. As far as I know AirMAX protocol from Ubiquiti Networks is also based on polling the clients. Although it seems to be a quite advanced and mature polling protocol.<br>
<br>
Franz<div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
Battlemesh mailing list<br>
<a href="mailto:Battlemesh@ml.ninux.org" target="_blank">Battlemesh@ml.ninux.org</a><br>
<a href="http://ml.ninux.org/mailman/listinfo/battlemesh" target="_blank">http://ml.ninux.org/mailman/<u></u>listinfo/battlemesh</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Ben West<div><a href="http://gowasabi.net" target="_blank">http://gowasabi.net</a><br><a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a><br>
314-246-9434<br></div>
</div>