Hi!
On 02:21 Tue 13 Apr , Korvin wrote:
> Hello again.
>
> Could someone tell me, whether is it possible to tune AP transmit power/range
> individually for each node? I know that modern wlan cards support this
> feature.
I am not sure whether modifying tranmit power is a good idea at all and one
global transmit power setting per node is very likely way too course. Reasons:
1) Some nodes with poor connectivity will loose their connection.
2) Reducing transmit power reduces throughput. This means more time spend
sending which may reduce the positive effect of reduced transmit power.
3) A node which does not reduce the transmit power may get more bandwidth
than it should, while possibly slowing down others.
How to do it right? My proposal:
1) The mac layer should provide the cost metric itself and upper layers should
read and honor it. This way, the mac layer will not have to transmit many
packets between nodes with poor connectivity. Whether you see them or not
becomes irrelevant (at least as long as the overhead for finding routes is
small).
2) If the connectivity is good, packet sizes and/or frame aggregating should
increase to reduce congestion avoidance overhead. The upper layer should
try to send packets as big as possible and avoid lots small packets, except
when sensing and reacting to poor connectivity.
3) The upper layer should try to be latency and loss tolerant and leave
congestion avoidance to the MAC layer. If your protocol operates as a
(linux) kernel layer 3 one, you can distinguish between drops by "radio
noise" and drops by "sending queue full". The "radio noise" should not
cause the slowdown of sending. Otherwise the available bandwidth will not
be fully used and frame aggregating will not be as efficient as possible.
4) Transmit power should be *entirely* independent of the number of visible
nodes. It may be reduced if done on the granularity of a "connection
between 2 neighbors" and only the mac layer itself without other layers
interfering. It may help when the connectivity is very good and packets are
too small for congestion avoidance to do its work well.
5) In case congestion is still too high, the MAC layer should enable RTS/CTS
and increase frame aggregating further without any command from upper
layers.
-Michi
--
programing a layer 3+4 network protocol for mesh networks
see http://michaelblizek.twilightparadox.com
_______________________________________________
Netsukuku mailing list
[email protected]
http://lists.dyne.org/mailman/listinfo/netsukuku
