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.
Here are the slides produced for Linux.conf.au 2013.
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:
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.