Saturday, March 3, 2012

KiwiEx 2012: Installing and Updating Software In A Simulated Disaster

(Please take a look at our crowd-funding campaign at

KiwiEx 2012 has just finished, and I am sitting in Wellington Airport with a few spare minutes to write down some thoughts about the experience.

First, it has been amazing to spend a week with the exceptionally bright and dedicated volunteers of the New Zealand Red Cross IT&T Emergency Response Unit (ERU).  These people are all volunteers giving up their valuable time for training, and also for potential overseas deployment to help provide communications support for Red Cross activities anywhere in the world.  This IT&T ERU is one of only five in the world, and the only one outside of Europe and the USA, which shows the calibre of the group.

To provide some context, the ERU is the team that deploys HF and VHF radio systems and satellite-backed internet access for other Red Cross teams.  Thus, they are frequently working in areas with no available terrestrial communications infrastructure.
Setting up the HF and VHF Radio Mast For the Emergency Operations Centre (EOC)

The primary function of KiwiEx was to provide a simulated deployment exercise to aid team readiness for potential deployment.

Along side this, the secondary goal of the exercise was to test various new technologies to see if they would be helpful for the ERU, and possibly for other users within the New Zealand Red Cross and other Red Cross national societies.

The Serval Mesh was one of these new technologies being test-run at KiwiEx, with a focus on Serval Rhizome store-and-forward and the Serval MeshMS infrastructure-independent short message service, which is similar to SMS on cellular networks.

Charging Phones Ready For Roll-Out
Rhizome allows the sharing of files between mesh-enabled phones, even if they are not all in range of one another at the same time.  MeshMS allows text messaging between phones -- all without relying on any infrastructure.  The Serval software was also combined with software from Kestrel and hardware from de Lorme that allows the entering of free-form or structured information into an electronic form on an Android phone that is then relayed via the de Lorme inReach (which uses the Iridium satellite constellation) back to an internet-enabled portal that can display the entered information in real time.  The Serval Mesh software was also complemented with the ability to deliver MeshMS between teams using the inReach satellite link as the back-haul.

This combination can also provide real-time tracking of people on the ground via the GPS receiver in the inReach unit.  Keeping track of their personnel is very important for the Red Cross, not only to maximise their effectiveness, but also to keep their people safe.

Pre-Exercise Briefing
Following Serval's approach of assume zero infrastructure (including no satellite internet, and possibly even no GPS), we also provided a mesh-based mapping application that uses Rhizome to share location and point-of-interest (POI) information among phones on the mesh.  This allows the Emergency Operations Centre (EOC) in the field to get this useful information, even when outside communications are not possible.  If internet access is available, the information can be pushed to the internet and visualised there.

The intention was to test if these various technologies (and combinations of them) were actually practical. In this regard, the tests were very successful: about 50 succinct data reports and a number of Serval MeshMS messages were pushed via inReach back to Kestrel's internet portal; more than 11,000 tracking points were obtained from more than a dozen phones allowing the reconstruction of team movements during the week; and more than 86MB of data was pushed around the mesh using Rhizome.

The ERU Team Familarise Themselves With The Serval Mesh Phones
Rhizome proved it's value several times over during the exercise, enabling bulk data transfer without any supporting infrastructure, and without requiring that all phones be on the mesh at the same time.

The KiwiEx Amenities Block
Indeed, Rhizome worked so seamlessly that it wasn't until I had pushed several software updates and a local map to the phones on the mesh that the significance of what we had done really dawned on me:  we had been transferring data at broad-band speeds, delivering software updates and critical operational data and telemetry over a network that contained no infrastructure.  Phones delivered data to other phones as required.  By the time I had pushed an update to the mesh and told the team leaders about it, it was available on their handsets.  It just worked.  It was amazing.

Serval Mesh Phone and inReach on Dash-Board Relaying Data via Iridium Satellite and Serval Rhizome
Sending a Message via Satellite In The Field
The fact that phones were moving around an area of several hundred square kilometres, and being turned on and off at various times was unable to overcome Rhizome's termite-like relentlessness in steadily nibbling away at transferring data whenever it could.  Where as many other protocols try a few times to complete a transaction, Rhizome's design allows it to keep trying for as long as it takes. Also, where as many other mesh protocols suffer from exponential bandwidth decay as the hop count increases, Rhizome is able to transfer large amounts of data easily because it only ever moves files one hop at a time, and thus does not need any routing information.
Boiling the billy, Kiwi style, in a Thermette.

Similarly, when at the end of the exercise I wanted to collect all the photographs that various people had taken during the exercise and shared to the mesh, all I had to do was find any mesh phone, and copy the pictures, because they all had a copy of all of the photographs.

The early feedback from the ERU team has been very encouraging, and they have made many valuable suggestions to enable us to improve our software.  Above all, their enthusiasm for what Serval will be able to do for them in the near future was a wonderful vindication of our approach of assuming no infrastructure, but using whatever infrastructure is available.


  1. This comment has been removed by a blog administrator.

  2. Very helpful article thanks for sharing some points are related to emergency mass notification software

  3. Rhizome and MeshMS sound amazing, and I'd love to know more about their work strategies. Is there any kind-of-"white paper"?

    For example, some points I am curious about are: what happens in a longer-term deployment? Won't the storage get exhausted? Imagine that a whole town is using a Serval mesh in a sudden crisis (not only humanitarian workers), so lots of messages are going around; what would happen?

    Also, IIRC the Serval mesh had implemented some kind of "delete-message" to tell the network to delete a stored message that had been successfully delivered. But, is that the only mechanism? And how effective is it? Delete-messages themselves also have to use up space and bookkeeping time, no?
    And, what happens when a node with little storage keeps contacting nodes with larger storage?

    What about use cases where a node expects to work on a rather well-connected network vs a node that could be dedicated to relay messages between two otherwise disconnected networks (kind-of-automated-sneakernet)? I read about the message-from-Africa experiment, but does Serval distinguish the use cases?

    I am currently taking part in Techfugees, a series of hackathons to try to help the refugee situation in Europe. I was dismayed to see that mesh networking is still in its infancy - somehow I had assumed it was rather robust already! Alas, for mobile phones only toy examples seem to be available. So glad to see that the Serval Project exists and still works on the subject! I hope to be able to contribute at some moment...

    1. You raise a lot of relevant points here, that we might better address and discuss on the Serval Project Developers Google Group, if you are willing to post there.