This version of the OBAMP protocol, implemented as an OLSR plugin, is a simplified one for Wireless Community Networks, where we assume the nodes to be in fixed positions on the roof of the houses. Protocol features regarding mobility have not been implemented (yet).
To explain how the plugin works consider the scenario in the following figure:
There are 7 routers, where only 5 have the OBAMP plugin working. Router 1 2 and 6 also have an attached HNA network with some hosts.
OBAMP nodes generate OLSR OBAMP_ALIVE messages, these OLSR messages are forwarded in the whole network (also by the nodes that do not understand OBAMP thanks to the OLSR design). Because of the flooding mechanism every OBAMP node has a complete list of all the other OBAMP nodes in the mesh network. Every OBAMP node listens on the UDP port 6226 for OBAMP signalling.
When a OBAMP nodes starts it has 5 timers to periodically start operations:
OBAMP_alive_timer: every obamp node sends alive messages to
advertise its presence to the other obamp nodes in the network. In the
alive message every nodes states its IP address, and if it has already
a tree link or not (we will see later this information is important for
the outer tree create procedure).
The OBAMP network must have a member called “Core”, that starts the TREE_CREATE procedure. The core is the node with the smallest IP address. When the list of known OBAMP nodes changes, the Core Election procedure is eventually called.
mesh_create_timer: every obamp node every OBAMP_MESH_CREATE_IVAL evaluates how far the other obamp nodes are and selects a subset of nodes to keep mesh links with. Note that to reduce signalling and to increase scalability, the overylay mesh links are setup only with a subset of the nearest OBAMP nodes. To select the overlay neighbor the OBAMP nodes first calculates the ETX distance of the nearest OBAMP nodes, and the creates overlay mesh links to every node that are far in the range (minETX,minETX+1)
tree_create_timer: the core of the network every OBAMP_TREE_CREATE_IVAL sends a message called TREE_CREATE on its mesh links. The creation of the spanning tree is very similar to the spanning tree protocol. When a TREE_CREATE message is received a OBAMP node enables a tree link with its parent and forwards the TREE_CREATE on the other mesh links. TREE_CREATE messages are generated only by the core and are numbered, so TREE_CREATE received over loops can be discarded.
outer_tree_create_timer: The mesh_create algorithm may create cluster of OBAMP nodes within the network that are disconnected between each other. This happens if there are groups OBAMP nodes that are far from each other. If this happens only the cluster where the Core is present will receive the TREE_CREATE and will receive traffic from the distribution tree. To overcome this problem if in a cluster there are not TREE_CREATE every OBAMP_TREE_CREATE_IVAL the node with the smallest IP in the cluster will make a long mesh link with the nearest node that has at least a tree link. All the necessary information to perform this procedure is diffused in the OBAMP_ALIVE messages.
purge_nodes_timer: checks expire time of various variables, and deletes nodes or tree links in a soft state fashion
The OBAMP nodes will capture the multicast udp traffic from the non-OLSR interfaces, and will forward this traffic encapsulated in the UDP tunnels of the distribution tree. The other OBAMP nodes will forward the traffic in the tree and will decapsulate it on their non-OLSR interfaces. To avoid duplicated packets the data is carried into OBAMP_DATA messages, that are identified by a sequence number, and the OBAMP source node where the traffic has been encapsulated.
In the figure black links represent real radio links, and red links represent overlay mesh links (udp tunnels). Router 1 2 3 and will create a OBAMP cluster, with two mesh links. Router 6 and 7 will create a mesh link between them. Because the mesh_create algorithm does not create a mesh link between the two clusters, the router 6 (supposing it has the smallest IP address in the mesh) will create an outer tree link with Router 3.
So please download the code and use it . If you find bugs please report them to Saverio and in the Sourceforge tracker here:
Thanks for this great result of the summer. Special thanks also to Nino from ninux.org who was the mentor for this projet.
The OpenWrt team (Cph) has announced a new version of its Linux distribution for embedded wireless devices named "OpenWrt Kamikaze 808 Release". I talked to Felix Fietkau already at the WCW. Unfortunately we did not have the time to do an interview at the end. But Cyrus from freifunk Halle gave a short showcase of his interface (in German). The OpenWrt team was also impressed by it and they now announce the enclosure of the Luci interface officially. Congratulations Cyrus!
It has been quite a while since OpenWrt had a new Kamikaze release. The developer team has decided that it is time to get things straight and focus on a new release. This release have the official name: OpenWrt Kamikaze 808 Release.
The schedule will look like this:
*Last day in July - final release candidate: 808 RC-1 808 RC-1 will be a feature freeze, and all changes after this point will be bug fixes.
*Last day in August - final release: OpenWrt Kamikaze 808 Release.
OpenWrt Kamikaze 808 Release will focus on bringing the following:
- Firewall rewrite
- Broadcom 47xx running reliably with the new Kernel, not including wifi
- IMQ and Traffic shaping tested with newer kernels, especially 2.6.25
- Sysupgrade for more platforms (x86 is tested again)
- The new web interface (LuCI, Lua Configuration Interface)
- Attention towards the integration of security updates
- Package maintaining and updates between releases
- Testing, testing and lots of testing...
The 808 Release will also include support for several new platforms/targets. (http://forum.openwrt.org/viewtopic.php?pid=69873 )
A couple of weeks ago I was talking with Alex about meshlium. I found out more about the project now. Last week I did an interview with Jose Luis Marina from Peopleware at a workshop of FOSS Bridge in Hanoi. Peopleware develops Osmius a very advanced monitoring tool to monitor all kinds of devices. He told me about their idea of using the open Squidbee hardware for their sensor networks. They want to be able to transfer data from sensor networks in an easy and affordable way. A scenario I see here is to use mesh networks for the transmission.
SquidBee is a project that uses an open hardware design as well as open-source software as a platform for remote control and sensing: "SquidBee is an Open Hardware and Source wireless sensor device. The goal of SquidBee is getting an "open mote" to create Sensor Networks." SquidBee uses the ZigBee self-organizing low power wireless mesh network protocol. ZigBee operates in the unlicensed 2.4 GHz, 915 MHz and 868 MHz ISM bands with data rates from 20-250 kbit/second, per channel. ZigBee is optimized for super low power operation so that the devices can be operated from battery power for long amounts of time. For long-running outdoor applications, powering the devices from photovoltaic panels would be an obvious technology choice. Using the 1mW XBee power level, the XBee maximum device-to-device range is 100 meters. At the 100mW XBee pro power level, the range is extended to 1KM. Each additional node can extend the range of the mesh network, since data passes through the nodes. (Download, June 16, 2008, http://lwn.net/Articles/260223/)
Behind the project is Libelium Comunicaciones Distribuidas, a SpinOff company of the University of Zaragoza (Spain) which has develop the ZigBee communication module. The Libelium team is formed by Marcos Yarza, Alicia Asín and David Gascón. The board has been developed by the Arduino team by David Cuartielles, Massimo Banzi, David A.Mellis and Tom Igoe. They come from different institutions in Spain, Sweden, Italy and New York (compare: http://www.libelium.com/squidbee/index.php?title=Who_is_behind%3F).
Some more info from the Squidbee wiki:
The main concepts behind SquidBee are:
* Wireless Comunications
Repeat with me: "Ubiquity, Ubiquity, Ubiquity..."
How does SquidBee work?
- Acquires values from environment parameters: temperature, humidity, lightness, presence, pressure or (almost!) whatever you can sense.
- Operates with these values, when required.
- Transmits these values using a low power comsumption wireless technology (ZigBee).
- Sleeps until next timeout and repeats from the first stept.
Second step is not always necessary, depending of the calculations needed it may be better to make them in receiver computer to save nodes energy.
An open mote? What does it really mean? It means every part of the mote is accessible and can be studied, changed, personalized, ... From the schematic circuit to the source code of the programs that are running inside the mote.
Who is interested in SquidBee? Anybody who is researching in the environment monitoring field. This is also an educational project so that universities can offer to the students a multi-learning device. With SquidBee people can learn at the same time electronic, programation, communications... and everything in just one device.
Who is supporting SquiBee? The board inside SquidBee has been developed by the Arduino team. The communications module wich lets the node transmit through a ZigBee module has been developed by Libelium. Both components are open hardware and they have a really strong community support. A specialized wiki related to SquidBee and the Sensor Networks will be created soon. There, all the Arduino and Libelium tutorials and examples will be shared and other research teams will be able to exchange their knowledge with the community.
What can I do with SquidBee? The main concept is: "sense what you want where you want and transmit it".
Two configurations of SquidBee? What is it exactly? Using the same board and communications module we have created 2 kinds of SquidBee: the sensor mote and the gateway. The first one is the self-powered sensor mote and the second is the computer USB connected receiver.
Can I integrate SquidBee into a wireless 802.11 Mesh network? Yes! We have also developed an outdoor Mesh Router: MeshLium which you can use to collect the information using the ZigBee protocol and transmit it to the mesh network using the Wifi technology (802.11). (Version, May 15, 2008, 15.22, http://www.libelium.com/squidbee/)
Unter dem Namen Motomesh Duo hat Motorola auf der Hannover Messe verschiedene Geräte für ein City-WLAN-Netz präsentiert. Außer der englischen Website http://www.motorola.com/mesh/ habe ich über Motorolas "Meshaktivitäten" bisher nicht viel gefunden. Dort gibt es verschiedene Geräte und einen MeshManager zu sehen.
Motorola's MeshManager element management system (EMS) provides a complete solution for configuration, fault, performance and security management for all Motorola mesh networks. Consisting of a Java based graphical user interface (GUI) and a series of software servers, the MeshManager suite gives you streamlined, point-and-click access to tools needed for complete network configuration and control. (Motorola MeshManager Website)
In dem Beitrag auf heise.de kann man Motomesh und Motorola einfach durch Freifunk ersetzen, dann hat man das, was Freifunker schon seit Jahren machen.
Eine City-WLAN-Lösung auf der Basis von Motomesh Duo soll nicht nur die WLAN-Endgeräte der Bürger umfassen, sondern ebenso Verkehrsinformationssysteme, Location Based Services, innerstädtische Videoüberwachung und eGovernment-Funktionen integrieren. Wie derzeit üblich, wird auch der Energiespareffekt beworben: "Zudem können City-WiFi-Netze dabei helfen, Energie zu sparen, indem sie strombedürftige Anlagen steuern. So können Stadtwerke mittels City-WiFi Straßenlaternen selektiv steuern und je nach Bedarf ein- oder ausschalten", heißt es in der Motorola-Mitteilung. Zur Komplettierung der städtischen Vernetzung will Motorola Sensoren, optische Schranken und Perimeter-Radarsysteme liefern. Ein mit Motomesh Duo aufgebautes Kommunikationsnetz kann nach Angabe von Motorola Flächen bis 150 Quadratkilometer abdecken. Auch weiter entfernte Punkte im ländlichen Bereich können mit der Punkt-zu-Punkt-Technik von Canopy erreicht werden. Nach eigenen Angaben hat Motorola für Internet Provider in Deutschland bisher 20.000 solcher DSL-Ersatzanbindungen installiert. Die Provider sind es auch, die Motorola mit seinem Motomesh-Angebot ansprechen will: "Ein flächendeckendes WiFi-Netz macht die Stadt zum Hotspot", erklärte Alexander Burghardt, Europa-Vizepräsident der Abteilung professionelle Funktechnik gegenüber heise online. (22.04.2008 13:23, Detlef Borchers, http://www.heise.de/newsticker/City-WLAN-von-Motorola--/meldung/106846)
"150 Quadratkilometer" deckt ein Motomesh-Netzwerk ab. Aha. Wie viele geben denn Freifunk-Netze so derzeit her?
Aus dem von elektra verfassten Buch "Mesh", welches Anfang August bei opensourcepress.de erschienen ist, gibt es jetzt das Kapitel über B.A.T.M.A.N als pdf-Download: https://www.opensourcepress.de/fileadmin/osp/pdf/mesh_leseprobe.pdf
Ausserdem beim EDV-Buchversand das Vorwort als Teaser...!
Im Chaosradio 16 zum Thema Wireless Meshworking gibt es ein Interview mit Elektra. Originalposting hier: http://chaosradio.ccc.de/cre016.html
Teilnehmer: Tim Pritlove (Moderation), Elektra Wagenrad
Ausgabe Nummer 16 von Chaosradio Express widmet sich dem Wireless Mesh Networking, dem Aufbau von billigen, offenen Netzwerken in netzwerktechnisch unterversorgten Gegenden in Stadt und Land. In einem recht geekigen Interview erläutert Elektra die Technik, existierende Projekte und die Geschichte des Wireless Mesh Networking der letzten fünf Jahren.