d353d8d4d9
Network coding exploits the 802.11 shared medium to allow multiple
packets to be sent in a single transmission. In brief, a relay can XOR
two packets, and send the coded packet to two destinations. The
receivers can decode one of the original packets by XOR'ing the coded
packet with the other original packet. This will lead to increased
throughput in topologies where two packets cross one relay.
In a simple topology with three nodes, it takes four transmissions
without network coding to get one packet from Node A to Node B and one
from Node B to Node A:
1. Node A ---- p1 ---> Node R Node B
2. Node A Node R <--- p2 ---- Node B
3. Node A <--- p2 ---- Node R Node B
4. Node A Node R ---- p1 ---> Node B
With network coding, the relay only needs one transmission, which saves
us one slot of valuable airtime:
1. Node A ---- p1 ---> Node R Node B
2. Node A Node R <--- p2 ---- Node B
3. Node A <- p1 x p2 - Node R - p1 x p2 -> Node B
The same principle holds for a topology including five nodes. Here the
packets from Node A and Node B are overheard by Node C and Node D,
respectively. This allows Node R to send a network coded packet to save
one transmission:
Node A Node B
| \ / |
| p1 p2 |
| \ / |
p1 > Node R < p2
| |
| / \ |
| p1 x p2 p1 x p2 |
v / \ v
/ \
Node C < > Node D
More information is available on the open-mesh.org wiki[1].
This patch adds the initial code to support network coding in
batman-adv. It sets up a worker thread to do house keeping and adds a
sysfs file to enable/disable network coding. The feature is disabled by
default, as it requires a wifi-driver with working promiscuous mode, and
also because it adds a small delay at each hop.
[1] http://www.open-mesh.org/projects/batman-adv/wiki/Catwoman
Signed-off-by: Martin Hundebøll <martin@hundeboll.net>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
Signed-off-by: Antonio Quartulli <ordex@autistici.org>
102 lines
4.2 KiB
Plaintext
102 lines
4.2 KiB
Plaintext
|
|
What: /sys/class/net/<mesh_iface>/mesh/aggregated_ogms
|
|
Date: May 2010
|
|
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
|
Description:
|
|
Indicates whether the batman protocol messages of the
|
|
mesh <mesh_iface> shall be aggregated or not.
|
|
|
|
What: /sys/class/net/<mesh_iface>/mesh/ap_isolation
|
|
Date: May 2011
|
|
Contact: Antonio Quartulli <ordex@autistici.org>
|
|
Description:
|
|
Indicates whether the data traffic going from a
|
|
wireless client to another wireless client will be
|
|
silently dropped.
|
|
|
|
What: /sys/class/net/<mesh_iface>/mesh/bonding
|
|
Date: June 2010
|
|
Contact: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
|
|
Description:
|
|
Indicates whether the data traffic going through the
|
|
mesh will be sent using multiple interfaces at the
|
|
same time (if available).
|
|
|
|
What: /sys/class/net/<mesh_iface>/mesh/bridge_loop_avoidance
|
|
Date: November 2011
|
|
Contact: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
|
|
Description:
|
|
Indicates whether the bridge loop avoidance feature
|
|
is enabled. This feature detects and avoids loops
|
|
between the mesh and devices bridged with the soft
|
|
interface <mesh_iface>.
|
|
|
|
What: /sys/class/net/<mesh_iface>/mesh/fragmentation
|
|
Date: October 2010
|
|
Contact: Andreas Langer <an.langer@gmx.de>
|
|
Description:
|
|
Indicates whether the data traffic going through the
|
|
mesh will be fragmented or silently discarded if the
|
|
packet size exceeds the outgoing interface MTU.
|
|
|
|
What: /sys/class/net/<mesh_iface>/mesh/gw_bandwidth
|
|
Date: October 2010
|
|
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
|
Description:
|
|
Defines the bandwidth which is propagated by this
|
|
node if gw_mode was set to 'server'.
|
|
|
|
What: /sys/class/net/<mesh_iface>/mesh/gw_mode
|
|
Date: October 2010
|
|
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
|
Description:
|
|
Defines the state of the gateway features. Can be
|
|
either 'off', 'client' or 'server'.
|
|
|
|
What: /sys/class/net/<mesh_iface>/mesh/gw_sel_class
|
|
Date: October 2010
|
|
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
|
Description:
|
|
Defines the selection criteria this node will use
|
|
to choose a gateway if gw_mode was set to 'client'.
|
|
|
|
What: /sys/class/net/<mesh_iface>/mesh/hop_penalty
|
|
Date: Oct 2010
|
|
Contact: Linus Lüssing <linus.luessing@web.de>
|
|
Description:
|
|
Defines the penalty which will be applied to an
|
|
originator message's tq-field on every hop.
|
|
|
|
What: /sys/class/net/<mesh_iface>/mesh/network_coding
|
|
Date: Nov 2012
|
|
Contact: Martin Hundeboll <martin@hundeboll.net>
|
|
Description:
|
|
Controls whether Network Coding (using some magic
|
|
to send fewer wifi packets but still the same
|
|
content) is enabled or not.
|
|
|
|
What: /sys/class/net/<mesh_iface>/mesh/orig_interval
|
|
Date: May 2010
|
|
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
|
Description:
|
|
Defines the interval in milliseconds in which batman
|
|
sends its protocol messages.
|
|
|
|
What: /sys/class/net/<mesh_iface>/mesh/routing_algo
|
|
Date: Dec 2011
|
|
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
|
Description:
|
|
Defines the routing procotol this mesh instance
|
|
uses to find the optimal paths through the mesh.
|
|
|
|
What: /sys/class/net/<mesh_iface>/mesh/vis_mode
|
|
Date: May 2010
|
|
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
|
Description:
|
|
Each batman node only maintains information about its
|
|
own local neighborhood, therefore generating graphs
|
|
showing the topology of the entire mesh is not easily
|
|
feasible without having a central instance to collect
|
|
the local topologies from all nodes. This file allows
|
|
to activate the collecting (server) mode.
|