Repository : ssh://git@open-mesh.org/doc
On branches: backup-redmine/2017-07-17,master
commit 8d12324fad349cf790392990013481ccc8ab4164 Author: Sven Eckelmann sven@narfation.org Date: Sun Jul 16 21:24:14 2017 +0000
doc: batman-adv/Bcast-hidden-node: Fix multiple page titles
8d12324fad349cf790392990013481ccc8ab4164 batman-adv/Bcast-hidden-node.textile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/batman-adv/Bcast-hidden-node.textile b/batman-adv/Bcast-hidden-node.textile index 8de21e6a..e3b4f84b 100644 --- a/batman-adv/Bcast-hidden-node.textile +++ b/batman-adv/Bcast-hidden-node.textile @@ -3,7 +3,7 @@ h1. Hidden Node Problem See "here":https://en.wikipedia.org/wiki/Hidden_node_problem for a general description of the problem.
-h1. Hidden Node Problem and NDP/OGMs +h2. Hidden Node Problem and NDP/OGMs
Especially in indoor scenarios like the one shown below where corners and thick walls are involved, hidden nodes can be a severe problem. Usually activating "RTS/CTS":https://en.wikipedia.org/wiki/IEEE_802.11_RTS/CTS is a common way of solving this problem at least to some degree. However, "RTS/CTS":https://en.wikipedia.org/wiki/IEEE_802.11_RTS/CTS can only be applied for unicast packets. Therefore a node C sending a lot of data packets to B, even with RTS/CTS those packets will interfere with BATMAN's broadcast packets (e.g. [[ndp|NDP]] packets or OGMs). The effect is, that with this stream, only the TQ from A -> B will decrease dramatically, the rest will stay relatively equal.
@@ -12,7 +12,7 @@ In the worst case, this can lead to route flapping to the shorter path, due to a !topology-scheme.png!
-h1. Solution Proposal +h2. Solution Proposal
In BATMAN-Adv. we have the possibility to control not only the routing protocols control packets (like NDP packets or OGMs), but also the data flow. Furthermore the period when a node is sending an NDP packet / OGM is relatively constant (+ some jitter), which allows finding a solution which does not need an active channel reserving like RTS/CTS. Roughly the following steps could be done to decrease the number of lost control packets in case of hidden nodes: * When sending an NDP packet, attach both the neighbor's NDP interval and the relative interval time offset. In other words, also add the amount of milliseconds when this node expects to receive the next NDP packet from this neighbor.