B.A.T.M.A.N.'s crucial point is the decentralization of knowledge about the best route through the network — no single node has all the data. This technique eliminates the need to spread information about network changes to every node in the network. The individual node only saves information about the "direction" it received data from and sends its data accordingly. The data gets passed from node to node, and packets get individual, dynamically created routes. A network of collective intelligence is created.
In early 2007, the B.A.T.M.A.N. developers started experimenting with the idea of routing on layer 2 (Ethernet layer) instead of layer 3. To differentiate from the layer 3 routing daemon, the suffix "adv" (for: advanced) was chosen. Instead of manipulating routing tables based on information exchanged via UDP/IP, it provides a virtual network interface and transparently transports Ethernet packets on its own.[2] The batman-adv kernel module has been part of the official Linux kernel since 2.6.38.[3]
Operation
B.A.T.M.A.N. has elements of classical routing protocols: It detects other B.A.T.M.A.N. nodes and finds the best way (route) to these. It also keeps track of new nodes and informs its neighbors about their existence.
In static networks, network administrators or technicians decide which computer is reached via which way or cable. As radio networks undergo constant changes and low participation-thresholds are a vital part of the "Freifunk"-networks' foundation, this task has to be automated as much as possible.
On a regular basis, every node sends out a broadcast, thereby informing all its neighbors about its existence. The neighbors then relay this message to their neighbors, and so on. This carries the information to every node in the network. In order to find the best route to a certain node, B.A.T.M.A.N. counts the originator-messages received and logs which neighbor the message came in through.
Like distance-vector protocols, B.A.T.M.A.N. does not try to determine the entire route, but by using the originator-messages, only the packet's first step in the right direction. The data is handed to the next neighbor in that direction, which in turn uses the same mechanism. This process is repeated until the data reaches its destination.
In addition to radio networks, B.A.T.M.A.N. can also be used with common wired cable connections, such as Ethernet.
History
The task was to create a protocol which was to be as easy, as small and as fast as possible. It seemed sensible to split the development in several phases and implement complex functions using an iterative process:
Version one
In the first phase, the routing algorithm was implemented and tested for its practicality and suitability for the task at hand. For the sending and receiving of originator-messages (information about existence), the UDP port 1966 was chosen.
Version two
The version one algorithm made a significant assumption: As soon as a node receives existence data from another node, it assumes it can also send data back. In radio networks however, it may very well be that only one-way communication is possible, i.e., asymmetric links.[4] A mechanism was incorporated into the protocol to allow for this and to solve the arising problems. The mechanism enables the node to determine whether a neighbouring node provides bidirectional communication. Only bidirectional nodes are being considered part of the network, and one-way nodes are no longer fully included.
Version three
The greatest innovation in this version is B.A.T.M.A.N.'s support of multiple network devices. A computer or router running B.A.T.M.A.N. can be deployed in a central location, such as a tall building, and have several wired or wireless network interfaces attached to it. When so deployed, B.A.T.M.A.N. can relay network data in more than one direction without any retransmission delay.
Certain unusual phenomena and special circumstances could appear during the determination of the best route through the network. These have been tackled and counteracted to prevent circular routing (which can prevent data reaching its destination).
A node can inform the network that it provides access to the Internet. Other nodes use this information to evaluate whether there is a connection to the Internet close to them and how much bandwidth is available. They can either use a specific gateway or allow B.A.T.M.A.N. to determine which gateway to use, based on criteria such as connection speed.
Announcing devices not running B.A.T.M.A.N. themselves was also included in this version. Usually, this method is used to connect home networks to mesh-networks. An antenna installation on the roof will connect to the wireless network through B.A.T.M.A.N. and the rest of the building will simply be announced, thus also be reachable.
This version of B.A.T.M.A.N. has been shown to exhibit high levels of stability but slightly slow convergence times in real-world conditions;[5] this is confirmed by theoretical analysis.[6]
BMX6
BatMan-eXperimental (BMX) aims to approximate the real exponent by also sending OGMs (originator messages) multiple times in independent broadcast datagrams.[7] It originated as an independent branch of BATMAN developed by Axel Neumann.[8] An extended version that incorporates securely-entrusted multi-topology routing (SEMTOR) is called BMX7.[9]
IV
This section needs expansion. You can help by adding to it. (September 2017)
Version four implements an algorithm to better detect quality of transmissions in abnormal link situations. Originator messages are updated to incorporate this data, enabling other nodes to better sense quality of asymmetric connections.
V
This section needs expansion. You can help by adding to it. (June 2016)
In 2017 B.A.T.M.A.N. was written on a whiteboard in the HBO series Silicon Valley (Season 4 Episode 2) where the show's lead character Richard Hendricks appears to include B.A.T.M.A.N. as a component of his "new Internet" concept (the text is visible on the top-right of the whiteboard).[12]
^On Supporting Link Asymmetry in Mobile Ad Hoc Networks - Kim, Toh, Choi, IEEE GLOBECOM 2001., vol. 5, November 2001, pp. 2798–2803 vol.5, doi:10.1109/GLOCOM.2001.965940, S2CID16396581
