At LCA 2012 (Linux Conf AU)

This year I was not expecting to be heading to Linux Conference Australia (LCA), as two of the Serval Project team were expecting to be there, and I am already looking at the likelihood of somewhere north of six bouts of international travel this year, on top of a very full itinerary for myself in our software development program, especially in the first half of the year.

However, circumstances changed just before LCA2012 with one of our team unable to travel due to health, and another being overseas at an IEEE 802.11 meeting as part of our effort to get the ad-hoc WiFi standard improved. So I found myself flying in for just over 24 hours to present one of the talks.

The two Serval Project talks this year were covering Serval Rhizome, our store-and-forward message and file distribution system, and the Serval Mapping Service, an infrastructure-free map and crowd-sourced information gathering and visualisation 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 many people asked a wide variety of questions. Several themes that emerged in the question time were that we should think about how we might interface our work with that of the ham radio community, and a general discussion of the Open Street Maps project that we use to supply the cacheable maps for the Serval Mapping Service. Questions were also asked about whether we were looking to branch out from Android to other platforms, including low-cost “feature phones”, which are common in the developing world. We have been targeting the Symbian/Belle S60 platform for a long time now. We also explained how we intend to seek the manufacture of custom feature and smart phones that contain a pluggable extra radio for mesh communications.

This goal received a substantial boost when we discovered that Andrew Tridgell (of SAMBA fame) has already written 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 the realistic capabilities of the modules are. The firmware and adapter boards that Andrew has created will also make it much easier for us to quantify the transmission range that we can achieve with these devices in practise, rather than relying on fairly simplistic link-budget calculations.

Also from talking with Andrew we have begun to look more seriously about using small model drone aircraft to loft mesh repeaters (possibly just mesh-enabled Android phones) and have them loiter over an area to provide significant coverage where it would otherwise be possible.

The combination of the longer-range radios and an established ability to loft mesh devices each have the potential to greatly increase the utility of our technology in a variety of settings, including disaster response and in both built-up areas and open country where either obstacles or low population density make WiFi meshing difficult.

It was also great to hear about David Rowe'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 175 bytes per second for speech of a quality that is more than acceptable for a phone call, and is substantially better than the now rather aged GSM codec that requires almost 10x the bandwidth. The challenge is how to make effective use of such a low bit-rate coded, since as David pointed out during his talk, the IP, UDP and RTP headers in a typical VoIP application would consume probably 5x more bandwidth than the voice stream itself.

This is a welcome problem we have been anticipating for some time now, and have some thoughts on how we might 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 will allow the voice to be directed using one-byte channel identifiers that are local to each node-pair. Third, we can build more efficient transport structures once we branch out to custom radio interfaces, such as in the ISM915 band building on the work that Andrew Tridgell described earlier in this post.

For example, we could use a one-byte packet type identifier plus the one-byte channel identifier described to provide an overall header size of just two bytes. Add to this perhaps 2 more bytes of synchronisation data for the cryptography layer, and the total overhead is 4 bytes per 40ms, for a total of 100 bytes of overhead, and a total data requirement in each direction of 275 bytes per second, or just under 2400bps. Allowing for guard bands and the like on the radio interface, we should be able to easily accommodate a full duplex voice call over a 5kbs – 10kbs radio channel, and multi-hop voice calls over perhaps 20kbs – 30kbs*. Such a low bit rate, as I have explained previously, offers the potential of very long range compared with WiFi, probably hundreds of metres per hop in built-up urban areas, and perhaps a few kilo-metres in open country, and even better with an elevated transmitter. We do hope to quantify these range figures in some realistic situations over coming months.

(* Each channel into and out of each node requires about 2400bps. In a multi-hop network, we do not want any two adjacent, two-hop or three-hop neighbours transmitting at the same, as they will cause interference to each others (the interference range is typically about double the effective transmission range, so one node talking can be heard by its immediate neighbours, and cause interference to it's two-hop neighbours). Also, we have two voice streams, one each way, so we need to schedule this in an appropriate manner. Let us explore how this might work if we have four nodes, A, B, C and D, involved as successive hops in a multi-hop call.

At time 0 transmits to B (A → B), so B must be listening, and C cannot talk, else it would interfere with B's reception of A's transmission. In fact, even D cannot talk, for fear of interfering with B's reception of A's transmission, as B may be in the interference range of D. Thus in this entire system of four nodes to maximise range we need to have only one of the four nodes talking at any time. As it takes three hops to carry the audio in each 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 a double-length frame, and similarly C talk to B and D with a double length frame, thus saving two guard bands. Thus we need two 2400bps channels and two 4800bps channels (a total of 14400bps), plus four guard bands. At 20kps this would leave approximately 25% of air time available, including for use guard bands, or to allow for the occasional carriage of additional data.

At 30kps fully half of air time would be available, which would also allow for some forward error correction, 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 not required, as nodes more than three hops from one another have reasonable prognosis (though no guarantee) of not interfering with one another.)

Meanwhile, also at LCA, we have been demonstrating the ability of the Serval software to share itself via bluetooth and WiFi to other phones, thus simulating deployment in a disaster zone or rural/remote context where internet access is not available. While there have been some issues, it has been tremendous to see many people install and try our software. It seems that practically everyone at LCA this year is aware of Serval and what we are trying to do.

As part of my talking about the Serval Mapping Service, Jeremy and I setup a “scavenger hunt” using the Serval Mapping Service to place geotagged pins on the map and Serval Rhizome to distribute photographs of the location of each small 2.5cm square cardboard token that we hid around the sprawling Ballarat University Campus. Similar to geocaching, the tokens were placed so as to be near impossible to find without knowing their location. LCA attendees can use the Mapping and Rhizome software to locate the tokens and return them to Jeremy. Each token is redeemable for two free coffee vouchers to help encourage participation. Apart from a bit of fun, we hope that this will provide us with some real-life experience and feedback on the use of these technologies.

Jeremy also succeeded in setting up an configuration-free gateway between Serval Mesh phones and a free SIP to PSTN service that is running at the conference, and left some voice mail on my cell phone to prove it.

We also had some interesting contact with several businesses that may be able to make use of our technology.

Much credit must go to Jeremy for getting the software together, and engaging in many of the conversations that have enabled us to have such a successful time at LCA so far. Also Rob Thomas has been a tireless advocate of Serval at LCA and elsewhere, and together with Jeremy have helped many people to install our software on their phones at the conference this year.

Thus, while I was not expecting to attend LCA this year, I am very glad that I managed to get there.

A Simple Illustration of A Multi-Hop Telephone Call

From time to time I get asked to provide a simple explanation of what the Serval Project actually does.

It allows you to make multi-hop phone calls using only phones, with the signal bouncing from phone to phone 

What does a multi-hop mobile mesh telephone call look like?  

Well, it can look a bit like this:

Of course this photo is a bit staged, and in reality the people in the middle of the call don't have to have their phones out, or do anything -- the mesh routing software automatically works out how to get the call between the parties.  

The only limitation is that their be a path between the calling parties.

Also, the phones can be quite a bit further apart than shown here, around 100 - 200m with line of sight at present, and potentially kilometres apart once we get the ISM915 band meshing happening in the future.

In a future post I will explain how we can enable SMS type services, even when there isn't a reliable path.

Serval is going to Atlanta

Well, Romana (co-founder of Serval Project) is.  And that is because she will be representing the Serval Project's interests at the IEEE 802 plenary meeting there in just a couple of weeks (November 2011).

Romana will be putting forward use cases that reveal deficiencies in the current 802.11 family of WiFi standards for mesh and ad-hoc communications.

If all goes well, we may have the opportunity to input into a process of looking to address these issues, which is tremendously exciting for us.

It could mean much longer range mesh hops using ordinary mobile phones, by using the cellular radio to implement some kind of WiFi in the ISM 915MHz band.

It could also spell the end of frustrating incompatibilities in the 802.11 ad-hoc WiFi standard, including the bizarre lack of specification of ad-hoc in 802.11n, preventing standards conforming devices from using the higher speeds and other benefits that 802.11n brings.

Either or both of these have the potential to make citizen generated infrastructure-free communications systems mainstream, thus our excitement.

So Atlanta will be the official first turning of clod in a process that could extend up to four years, and represents a huge personal investment on the part of Romana, as well as a substantial financial investment on the part of the Serval Project, and thus the Shuttleworth Foundation whose support makes this possible.

We would invite any other open efforts that have concerns with aspects or omissions of the IEEE 802.11 WiFi standards to get in touch with us, so that we can do our best to represent the needs of more than just ourselves.

More than we expected at the IEEE

If you have been reading this blog you will know that we sent Romana over to Okinawa to present our desire to see ad-hoc mode wifi improved, and also to consider how to use the baseband radio in mobile phones to support wifi on very low cost phones, and also to provide much longer range meshing using the ISM915/868 bands that offer very useful link budget advantages over the 2.4GHz band used by regular WiFi.

Well, we have been absolutely gobsmacked by the interest and positive response that Romana experienced at the meeting, and have the opportunity of taking up the baton to champion proposing these enhancements through the formal IEEE 802 standards process.

This is a great privilege, and also an opportunity that cannot be accepted without serious and solemn consideration, because it will basically require someone's effort, full time, for perhaps three years or more.

We are convinced that we want to, and that we should engage with this standards process, but just need to work out whether we have the resources to do it, without drawing all of our available resources away from progressing the development of the Serval mesh telephony software.

More news as we have it.

Day 1 of Shuttleworth Foundation Fellowship

So today I have commenced a telecommunications fellowship with the Shuttleworth Foundation, which will be undertaken here at Flinders University where with the University's generous support we have based the Serval Project.

This is an amazing support for our work on the Serval Project, as not only does it free up my salary so that we can employ a project manager, but it also provides access to a very helpful operational budget, and a great team of dedicated open-technologists working on a variety of projects.  Check out their list of past and current fellows to get a feel for what they are supporting.

This support builds on that already provided by The Awesome Foundation, Flinders University and NLnet, as well as that of many students, volunteers and my family, which has enabled us to reach this point.

The particular mandate of my work under the fellowship is to:

0. 
   

- Build on existing trials, which include remote, in-motion, underground and
indoor tests by linking with partner organisations to deploy the
technology in an escalating series of situations;– Increasing the breadth of applications for the technology, and the usability
of the technology in disaster, by governments, and in remote locations;
and– Improving the maximum range between handsets beyond what is
possible using WiFi, but without altering the hardware in existing mobile telephones (the “Focus Area Objectives”). 


What this means is that we will be pursuing a simultaneous software improvement and testing program that will, hopefully, get us to the point of a quality public release within a year.


The greatest challenge comes from the range extension, which we know is possible using the baseband radio in mobile phones. However, it is extremely difficult to get the programming information to enable modification of the firmware loaded into the radio's baseband processor. 


We will be exploring multiple angles to achieve this, ranging from engaging with the IEEE 802.11 standardisation process, to seeking to open channels with cell phone chipset manufacturers, through to, building custom cell phones that contain friendlier baseband or other radio chipsets that we can more easily reprogram, and where legal and appropriate, reverse-engineering the information we require.


The potential gains over using WiFi to build the mesh (perhaps 300m between phones indoors and 10km or more between phones outdoors in open country) are so great that we must engage with this process, regardless of the difficulty.