The Serval Project attended Linux.conf.au 2013 in Canberra from 28 January to 2 February 2013, with the following aims:

• make four presentations in the MobileFOSS miniconf and one in the main conference;
• explore options for collaborating on the Serval Mesh Extender hardware (which was still at concept stage);
• perform a field trial of Commotion OpenBTS integration by testing the VoMP channel driver for Asterisk;
• test the recently released Serval Mesh Version 0.90 “Shiny” app for Android;
• maintain the project's profile within the Australian FOSS community;
• meet with potential new collaborators and stakeholders.

The New America Foundation - Second Contractor Agreement “NAF2” funded travel from Adelaide to Canberra and accommodation for a founder and two senior engineers for the week-long conference.

The MobileFOSS miniconf was covered by Linux Weekly News.

• Creating the Friendly Borgtel (video not available) presented by Paul Gardner-Stephen
• Serval Maps presented by Andrew Bettison
• Field Trialling the Serval Project with New Zealand Red Cross presented by Paul Gardner-Stephen
• Serval Project Technology Stack presented by Andrew Bettison
• Making Mobile Communications Secure presented by Paul Gardner-Stephen

Here are the slides produced for Linux.conf.au 2013.

• One Dell PC running Ubuntu 12.10, set up using the serval-setup-lca2013.sh script as follows:
  • Asterisk 1.8 downloaded, compiled and installed
  • Serval DNA downloaded, compiled and installed
  • VoMP channel driver for Asterisk downloaded, compiled and installed
  • VoMP channel driver basic sample configuration applied
• A dozen Huawei IDEOS X1 u8180 Android phones set up as follows:
  • rooted
  • Serval Mesh Version 0.90 “Shiny” installed
  • pre-configured to use the Dell PC as a directory service
• One Wi-Fi Access Point router with a 3G dongle for Internet access (the “Brian” router from the Serval Batcave)
• Several personal laptops used as development workstations

At the conference, the server was set up as a Serval Infrastructure node connected to the campus network via Ethernet cable. Several of the IDEOS X1 phones were lent to attendees for the duration of the conference. Many attendees installed the Serval Mesh app on their own phones from a URL and QR code displayed during presentations.

The Wi-Fi coverage in many of the seminar rooms was uneven, and Wi-Fi quickly became congested during sessions. The conference attendees were no doubt heavy Wi-Fi users, but the Serval Mesh phones probably contributed a lot:

• There was a large volume of Rhizome traffic between activated Serval Mesh phones. Some phones contained very large bundles, such as updated APK files created to perform Auto Upgrade during the conference, and there were several shared photos. As soon as a newly installed phone joined the Mesh network, it would commence fetching all available Rhizome bundles from nearby phones.

• The Broadcast MeshMS feature produced a large number of ACK messages in response to every broadcast message, and the Serval Mesh UI made it trivially easy (tempting, even) for attendees to send broadcast messages. This increased the volume of Rhizome traffic even more.

• The Mesh Datagram Protocol (MDP) implementation at the time used broadcast UDP frames instead of unicast UDP frames, even when connected in Client mode to an Access Point. It was known that Wi-Fi Ad Hoc mode does not acknowledge broadcast packets, but a Wi-Fi Access Points and/or Clients might acknowledge broadcast packets, in which case all the DNA Lookup requests sent by all the Serval Mesh phones would have been causing a Wi-Fi ACK storm.

Conclusion: Rhizome fetches must either be done using Mesh Datagram Protocol (MDP), which is throttled to avoid congestion, or the existing HTTP over TCP/IP transfers must be throttled.

Conclusion: A new Rhizome sync protocol is needed, to efficiently sync only new content between up-to-date devices, and also incrementally sync the entire content in order of importance to newly-arrived (out-of-date) devices.

Conclusion: Broadcast MeshMS should be deprecated, and in the short term the implementation fixed to suppress Acknowledgements of received broadcast messages.

Conclusion: The Overlay network implementation in Serval DNA should use unicast UDP frames by default, and only use broadcast frames on interfaces configured to do so (eg, when the Batphone app detects that Ad Hoc mode is in use). This would require improvements to the Overlay network and Mesh routing logic to perform MDP broadcasts over many UDP unicast links.

Conclusion: DNA Lookup and Reverse Lookup queries should be sent completely asynchronously to the display of the Peer List activity in the Serval Mesh app, so that they can be rate throttled by Serval DNA.

The Rhizome file distribution system worked well during the conference, despite the Wi-Fi congestion. Most MeshMS text messages, most shared photos, and all Auto Upgrade APK updates reached all phones eventually.

Voice calls between phones in Ad Hoc mode worked, although audio quality was dreadful.

However, Wi-Fi congestion prevented any Voice over Mesh Protocol (VoMP) calls to conventional telephone numbers during sessions, because the Dell PC server could not be reliably contacted (although it appeared in the Peer List, so it was responding to DNA requests).

A few VoMP calls were successfully made from the dormitory room when the “Brian” Wi-Fi router was set up connected to the Dell PC server, although audio quality was poor, echo was a problem, and delay tended to build up.

Conclusion: Mesh Datagram Protocol (MDP) clearly did not cope well in a congested environment, since most VoMP messages were lost. Adding per-hop retransmissions to Mesh Datagram Protocol (MDP) would significantly improve this situation.

Conclusion: Voice over Mesh Protocol (VoMP) used a very inefficient audio codec (µ-Law or A-Law, 8kHz sample rate, 8 bit resolution) which generates 160 bytes per 20 ms packet, or 8kB per second. Changing to use CODEC2 would dramatically reduce the data rate over the air per call.