This year I was not expecting to beheading to Linux Conference Australia (LCA), as two of the ServalProject team were expecting to be there, and I am already looking atthe likelihood of somewhere north of six bouts of internationaltravel this year, on top of a very full itinerary for myself in oursoftware development program, especially in the first half of theyear.
However, circumstances changed justbefore LCA2012 with one of our team unable to travel due to health, andanother being overseas at an IEEE 802.11 meeting as part of oureffort to get the ad-hoc WiFi standard improved. So I found myselfflying in for just over 24 hours to present one of the talks.
The two Serval Project talks this yearwere covering Serval Rhizome, our store-and-forward message and filedistribution system, and the Serval Mapping Service, aninfrastructure-free map and crowd-sourced information gathering andvisualisation platform that is something like a cross between GoogleMaps, Ushahidi and Twitter.
Update: Here are the videos of the talks. The authorships are wrong way around, however:
The talks were well attended and manypeople asked a wide variety of questions. Several themes thatemerged in the question time were that we should think about how wemight interface our work with that of the ham radio community, and ageneral discussion of the Open Street Maps project that we use tosupply the cacheable maps for the Serval Mapping Service. Questionswere also asked about whether we were looking to branch out fromAndroid to other platforms, including low-cost “feature phones”,which are common in the developing world. We have been targeting theSymbian/Belle S60 platform for a long time now. We also explainedhow we intend to seek the manufacture of custom feature and smartphones that contain a pluggable extra radio for mesh communications.
This goal received a substantial boostwhen we discovered that Andrew Tridgell (of SAMBA fame) has alreadywritten frequency-hopping firmware for HopeRF radio modules similar to the ones we are intending to use. This will likely save us months of effort,and also enabled us to learn from Andrew’s experience about what therealistic capabilities of the modules are. The firmware and adapterboards that Andrew has created will also make it much easier for usto quantify the transmission range that we can achieve with thesedevices in practise, rather than relying on fairly simplisticlink-budget calculations.
Also from talking with Andrew we havebegun to look more seriously about using small model drone aircraftto loft mesh repeaters (possibly just mesh-enabled Android phones)and have them loiter over an area to provide significant coveragewhere it would otherwise be possible.
The combination of the longer-rangeradios and an established ability to loft mesh devices each have thepotential to greatly increase the utility of our technology in avariety of settings, including disaster response and in both built-upareas and open country where either obstacles or low populationdensity make WiFi meshing difficult.
It was also great to hear about DavidRowe’s continuing progress on his open-source codec, called Codec2,which while still alpha, already is able to demonstrate veryacceptable performance at 2500bps and 1400bps, i.e., as low as 175bytes per second for speech of a quality that is more than acceptablefor a phone call, and is substantially better than the now ratheraged GSM codec that requires almost 10x the bandwidth. The challengeis how to make effective use of such a low bit-rate coded, since asDavid pointed out during his talk, the IP, UDP and RTP headers in atypical VoIP application would consume probably 5x more bandwidththan the voice stream itself.
This is a welcome problem we have beenanticipating for some time now, and have some thoughts on how wemight address it. First, once we get our new overlay mesh operating,we will use packet aggregation to defray some of the headers. Second, we will setup pseudo virtual circuits between nodes that willallow the voice to be directed using one-byte channel identifiersthat are local to each node-pair. Third, we can build more efficienttransport structures once we branch out to custom radio interfaces,such as in the ISM915 band building on the work that Andrew Tridgelldescribed earlier in this post.
For example, we could use a one-bytepacket type identifier plus the one-byte channel identifier describedto provide an overall header size of just two bytes. Add to this perhaps 2 more bytes of synchronisation data for the cryptographylayer, and the total overhead is 4 bytes per 40ms, for a total of 100bytes of overhead, and a total data requirement in each direction of275 bytes per second, or just under 2400bps. Allowing for guardbands and the like on the radio interface, we should be able toeasily accommodate a full duplex voice call over a 5kbs – 10kbsradio channel, and multi-hop voice calls over perhaps 20kbs –30kbs*. Such a low bit rate, as I have explained previously, offersthe potential of very long range compared with WiFi, probablyhundreds of metres per hop in built-up urban areas, and perhaps a fewkilo-metres in open country, and even better with an elevatedtransmitter. We do hope to quantify these range figures in somerealistic situations over coming months.
(* Each channel into and out of eachnode requires about 2400bps. In a multi-hop network, we do not wantany two adjacent, two-hop or three-hop neighbours transmitting at thesame, as they will cause interference to each others (theinterference range is typically about double the effectivetransmission range, so one node talking can be heard by its immediateneighbours, and cause interference to it’s two-hop neighbours). Also, we have two voice streams, one each way, so we need to schedulethis in an appropriate manner. Let us explore how this might work ifwe have four nodes, A, B, C and D, involved as successive hops in amulti-hop call.
At time 0 transmits to B (A → B), soB must be listening, and C cannot talk, else it would interfere withB’s reception of A’s transmission. In fact, even D cannot talk, forfear of interfering with B’s reception of A’s transmission, as B maybe in the interference range of D. Thus in this entire system of fournodes to maximise range we need to have only one of the four nodestalking at any time. As it takes three hops to carry the audio ineach direction, we need six time slices. Some savings can, however,be gained by having B talk to A and C at the same time with adouble-length frame, and similarly C talk to B and D with a doublelength frame, thus saving two guard bands. Thus we need two 2400bpschannels and two 4800bps channels (a total of 14400bps), plus fourguard bands. At 20kps this would leave approximately 25% of air timeavailable, including for use guard bands, or to allow for theoccasional carriage of additional data.
At 30kps fully half of air time wouldbe available, which would also allow for some forward errorcorrection, and a more realistic allowance for additional data,especially if some creative time slicing and signalling is employed.For calls with more than four hops, additional bandwidth is notrequired, as nodes more than three hops from one another havereasonable prognosis (though no guarantee) of not interfering withone another.)
Meanwhile, also at LCA, we have beendemonstrating the ability of the Serval software to share itself viabluetooth and WiFi to other phones, thus simulating deployment in adisaster zone or rural/remote context where internet access is notavailable. While there have been some issues, it has been tremendousto see many people install and try our software. It seems thatpractically everyone at LCA this year is aware of Serval and what weare trying to do.
As part of my talking about the ServalMapping Service, Jeremy and I setup a “scavenger hunt” using theServal Mapping Service to place geotagged pins on the map and ServalRhizome to distribute photographs of the location of each small 2.5cmsquare cardboard token that we hid around the sprawling BallaratUniversity Campus. Similar to geocaching, the tokens were placed soas to be near impossible to find without knowing their location. LCAattendees can use the Mapping and Rhizome software to locate thetokens and return them to Jeremy. Each token is redeemable for twofree coffee vouchers to help encourage participation. Apart from abit of fun, we hope that this will provide us with some real-lifeexperience and feedback on the use of these technologies.
Jeremy also succeeded in setting up anconfiguration-free gateway between Serval Mesh phones and a free SIPto PSTN service that is running at the conference, and left somevoice mail on my cell phone to prove it.
We also had some interesting contactwith several businesses that may be able to make use of ourtechnology.
Much credit must go to Jeremy forgetting the software together, and engaging in many of theconversations that have enabled us to have such a successful time atLCA so far. Also Rob Thomas has been a tireless advocate of Servalat LCA and elsewhere, and together with Jeremy have helped manypeople to install our software on their phones at the conference thisyear.
Thus, while I was not expecting toattend LCA this year, I am very glad that I managed to get there.