Repository : ssh://git@open-mesh.org/doc

On branches: backup-redmine/2017-07-17,master

commit e7605c8e1ea4b9cf380f0d51efef9415b2836b42 Author: Sven Eckelmann sven@narfation.org Date: Sun Jul 16 21:39:31 2017 +0000

doc: batman-adv/Bcast-hidden-node: Change NDP to new name ELP

e7605c8e1ea4b9cf380f0d51efef9415b2836b42 batman-adv/Bcast-hidden-node.textile | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/batman-adv/Bcast-hidden-node.textile b/batman-adv/Bcast-hidden-node.textile index e3b4f84b..d33478a8 100644 --- a/batman-adv/Bcast-hidden-node.textile +++ b/batman-adv/Bcast-hidden-node.textile @@ -3,19 +3,19 @@ h1. Hidden Node Problem See "here":https://en.wikipedia.org/wiki/Hidden_node_problem for a general description of the problem.

-h2. Hidden Node Problem and NDP/OGMs +h2. Hidden Node Problem and ELP/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. +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. [[elp|ELP]] 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.

-In the worst case, this can lead to route flapping to the shorter path, due to all these lost packets, A will switch its route towards C to the direct one if occasionally some NDP/OGMs had been received over this link, which might however not be usable for i.e. TCP traffic due to a too high packet loss. +In the worst case, this can lead to route flapping to the shorter path, due to all these lost packets, A will switch its route towards C to the direct one if occasionally some ELP/OGMs had been received over this link, which might however not be usable for i.e. TCP traffic due to a too high packet loss.

!topology-scheme.png!

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. -* Any neighbor receiving an NDP packet with this new information then knows at which times sending data packets could result in collisions (due to e.g. hidden nodes). +In BATMAN-Adv. we have the possibility to control not only the routing protocols control packets (like ELP packets or OGMs), but also the data flow. Furthermore the period when a node is sending an ELP 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 ELP packet, attach both the neighbor's ELP interval and the relative interval time offset. In other words, also add the amount of milliseconds when this node expects to receive the next ELP packet from this neighbor. +* Any neighbor receiving an ELP packet with this new information then knows at which times sending data packets could result in collisions (due to e.g. hidden nodes). * A node then halts its unicast packet transmissions at these times. The benefit of this also is, that even if there was no hidden node problem in such a scenario, still a congested links (e.g. saturated bc. of many UDP packet transfers) could lead to switching to the unusable, direct link A - C. This solution also eliminates the influence of congestion on BATMAN's control packets. \ No newline at end of file