Tag-Archive for » Babel «

HydroNet kommt in die Medien

Für diejenigen, die nicht wissen um was es sich beim EU-Projekt HydroNet handelt, hier eine kurze Erklärung:

Autonome Katamarane und Bojen, ausgestattet mit sensiblen Sensoren, ermöglichen die effiziente Überwachung der Wasserqualität in Seen, Lagunen und Flüssen. Eine optimierte drahtlose Kommunikationsinfrastruktur übermittelt die Messdaten zur Einsatzkontrolle.

Mit Freude gebe nun ich bekannt, dass HydroNet in den folgenden Medien erwähnt wird:

Durch die Medienpräsenz hoffen wir natürlich, dass potentielle künftige Partner auf das Projekt und die Resultate aufmerksam werden.
Nun sind es nur noch knapp drei Wochen, wo ich noch an der Hochschule Luzern arbeite bevor ich auf die lange Reise gehe.
Mit Hochdruck arbeite ich daran unser Forschungsprojekt abzuschliessen. Auch die UBICOMM 2011 Konferenz steht kurz bevor wofür ich noch meinen kurzen Talk vorbereiten darf.

HydroNet and the Babel Routing Protocol

This year I’ve had the task to develop a subset implementation of the Babel routing protocol for low-power wireless devices running the TinyOS operating system. This was done to satisfy the communication requirements (especially to overcome long distances over the air) for the HydroNet project. At the beginning of this article I will give you an overview of this amazing project. Afterwards I will explain you the functionality and advantages of Babel, which was primarily designed for wireless mesh networks.

HydroNet – The Guardians of Water

HydroNet is aimed at designing and developing an autonomous network of sensors to improve the monitoring of water quality in rivers, lakes and lagoons. This autonomous network consists of unmanned catamarans and buoys. Each catamaran or buoy (I will call them simply nodes) is equipped with optical, chemo- and bio-sensors to detect water pollutants like mercury, cadmium, oil and many others. The mission area is 10 x 3 km for open waters (sea, ocean) and 15 km for closed waters (creeks, rivers). Mission and measurement data is exchanged wirelessly between nodes and to the base station at the coast in real-time. Communication problems arise in the mission area due to the long distances, frequency regulations, reflections and obstacles (like ships, river bends). A communication infrastructure had to be built to overcome those challenges.

HydroNet is supported by the Seventh Framework Programme (FP7) from the European Commission and involves ten partners from six countries. Two competence centers at the Lucerne University of Applied Sciences and Arts were assigned to build the communication infrastructure. The CC Electronics center designed and developed the hardware and the D3S (where I work) center implemented the firmware including the routing protocol.

But first lets look at the video to get a better impression of the project:

[youtube width=”480″ height=”390″]http://www.youtube.com/watch?v=yr3WsrCf23M[/youtube]

The communication infrastructure consists mainly of the following components:

  • self-made antenna
  • TI MSP430 ultra-low-power micro-controller (10K RAM, 48K ROM, running @ 8MHz)
  • Semtech XE1205 radio transceiver operating in the 443MHz ISM band
  • An amplifier to boost the signals up to 2.5 Watt, with overload protection
  • TinyOS, an open-source operating system
  • the firmware (written in nesC), interacts with the node’s main computer, handling the radio communication and routing

The hardware components are designed for low-power usage. This is necessary to extend the battery lifetime of the nodes and increase the mission time without human intervention. Of course low-power is generally coupled to limited resources. Therefore you can’t add any extra sugar to your firmware and you need to develop very economically.
The amplifier and the antenna enable to overcome distances up to 3km above the sea (antenna 2m above sea level), but it’s still not enough to cover the whole mission area. Therefore a routing-protocol came into play to allow nodes to act as repeaters. Intermediate nodes on a path can forward data packets to the destination node which is out of range from the originator.

Babel, route me

As partly mentioned, several challenges needed to be achieved by the routing protocol to maintain a reliable communication within the participants:

  • minimal operational data, like routing tables, buffered messages (10K RAM)
  • small footprint (48K ROM)
  • low processing load (only 8MHz)
  • especially designed for wireless mesh networks
  • minimal and efficient bandwidth utilization (avoid collisions, routing-loops, routing overhead)
  • react fast to mobility changes (the catamarans are moving permanently)
  • low power consumption (the radio + amplifier are very hungry)
  • support research & development

Our evaluation of different routing protocols led us to Babel, because its features looked very promising to fulfill the project requirements. Juliusz Chroboczekhas specified Babel in the RFC 6126, which changed its state from draft to experimental in April 2011. He also has developed a stable daemon of Babel (babeld). More information, sources and binaries for Debian/Ubuntu and also for OpenWRT can be found on his official page. Also his slides from a talk about Babel explain well the protocol.

I will summarize some of the main, and in my opinion also very impressive, features of the protocol:

  • distance-vector routing protocol (less computational complexity, less overhead, saves memory)
    • babeld has only 8000 lines of code
  • proactive protocol, with reactive features
    • speeds up convergence by reactively requesting new routing information when a node suffers from route starvation
  • based on the ideas in DSDVAODV and Cisco’s EIGRP
  • designed to work in wired and wireless mesh network simultaneously
  • runs on IPv4 and IPv6 simultaneously
  • feasibility condition guarantees loop-freedom
  • senses link quality for computing route metrics using variant of the ETX algorithm (more adequate for wireless links)
  • also radio-frequency aware to avoid interference

The subset implementation

Of course, some of the features from Babel are not required or appropriate for the HydroNet project (like IPv6, operation in wired networks). Therefore I designed and have developed a subset implementation of the Babel routing protocol for the TinyOS operating system, to fit the needs for HydroNet.

I’ve described the considerations and optimizations in the Work in Progress paper Babel multi-hop routing for TinyOS low-power devices, which will be published at the UBICOMM 2011.

Category: nesC  Tags: , , , ,  Leave a Comment