Originally, we had imagined having a management interface for the Village Telco very similar to the Meraki and/or Open-Mesh network management “dashboards” which are  graphically-intuitive and easy for anyone to understand at a glance what is going on in the network.  However, Antoine introduced a new twist which opens up interesting possibilities.  He has designed the Afrimesh software so that it can run on any OpenWRT-based device.  It is written entirely in JavaScript. Actually Afrimesh will run on just about anything but, for me, the interesting new possibility is have a dashboard interface that runs on the mesh devices themselves.  I didn’t initially appreciate initially the potential that this opens up.

You can see at the left here what the management interface currently looks like.  As things currently stand, Afrimesh is designed to:

• monitor the health of the network and display connectivity information for each mesh node and connections between the nodes in a visually intuitive manner;
• provide an interface for the configuration of a B.A.T.M.A.N.-based mesh network; and,
• be an extensible GUI framework for interfacing with a mesh network.

From self organising data networks to self-organising phone networks

So here is where my minor epiphany came.  What is great about mesh networks is that you just plug them in and they work.  They self-organise in terms of upstream connectivitity, redundant routing, etc.  They are a very, very clever way of quickly establishing a pervasive, reliable IP-based network.

With the Mesh Potato, we are trying to leverage the power of mesh networks to set up a phone network.  Each Mesh Potato access point will have an RJ11 port, into which an everyday phone can be plugged.  However, to use the Mesh Potato, some configuration of the phone network detail is still required.  People need to have phone numbers to dial and a phone number themselves that people can call.  More than that, people have to have a way of finding out other people’s phone numbers.

I began to think of the Mesh Potato in different environments to that which we originally conceived.  For instance, would Mesh Potatoes work in an crisis environment where there was a need to set up a instant phone network?  Could they be designed to self-configure out of the box as a phone mesh?  Conversations with David Rowe and Antoine have encouraged me to think so.

Imagine you power up your Mesh Potato and an interactive voice response system says:

This is quite a reasonable scenario.  We could set up the Mesh Potatoes to do something like the above and the impact would be that you could unpack a box of 24 Mesh Potatoes, power them up (battery or solar), and within minutes have a working phone network.  This would work with or without upstream connectivity.  It would mean you could immediately start delivering value with a Village Telco even before you have a server, billing, and upstream connectivity set up.

The Afrimesh Potato

But it gets better.  With the Afrimesh software, you could conceivably combine data network information with phone network information.  Consider an enhanced version of the Afrimesh interface which not only provided network information but also voice call information.  The image at the right is my mock-up but it conveys the sense of how Afrimesh could show you who was on the phone network, what their extension is, whether they’re “available”, etc.

I think that having a plug-and-play Mesh Potato that will allow people to start talking with no initial technical configuration would substantially increase the take-up rate of the Mesh Potato.  I also think the Afrimesh interface offers opportunities for interesting voice/data/presence/twitter/jabber cross-over innovation on the MPs.  Love to hear thoughts from others on this.

P.S. For those waiting patiently to hold a Mesh Potato in your hand, David and Elektra are in the final stage of PCB design with Atcom.  I don’t have a date but we should have prototypes very shortly.

What FON and Meraki have in common is that they are both consumer-deployed infrastructure and both trade on the benefit of network effects.   The paper presents a useful analysis of both organisations but strains a bit in making an effective comparision between them because the models are so different.  FON is a distribution network of “Foneros” who share their Internet connections via WiFi in exchange for gaining low-cost access to other Fonero access points.  Thus FON access points can be anywhere there is an Internet connection.  Meraki on the other hand depends on nodes being connected to each other via a mesh network protocol.  You can see how it is hard then to make a head-to-head comparison.  I would be more interested in seeing a head-to-head comparison of Meraki and OpenMesh.

I still found the paper very useful, particularly in its analysis of FON.  It points out the critical failing that FON doesn’t achieve anything like ubiquity in distribution and particularly availability of access points and consequently turn out to be not so useful to people who might want to take advantage of roaming access.  The notion for driving around a city looking for a live FON access point can hardly be very appealing.  It would be more interesting if FON were able to link up with a service like IPASS so that you could leverage access where you want it most in cafes and airports (well, those are my priority spots .  However, it would probably be difficult to find a fit with IPASS’s purely commercial model.  Anyway, the take home for me about FON was the importance of ubiquity. The paper rates Meraki a little higher than FON because it achieves “local ubiquity” which in the context of Meraki is probably as good as is needed.

Middleton argues that Meraki’s model, while more successful than FON’s, still suffers from a reliability issue because the infrastructure is dependent on the community.  She highlights an incident with Meraki where a number of people turned off their routers in order to plug in Christmas trees causing the otherwise robust, redundant mesh network to fail.  It highlights the fact that a Meraki user can’t be a simple consumer, they need to be a participant in the community.  This may not be a bad thing. 

http://www.cwirp.ca/files/CWIRP_FON_Meraki_slides.pdf

However, Middleton’s final assessment is that both FON and Meraki are challenged when it comes to going to scale.  She argues that there is a need for cental coordination that is not easily achieved through the ad-hoc nature of community efforts.  This is something of a curious conclusion as the Internet itself is an ad-hoc network that succeeds very well.  It may be that FON and Meraki are doomed precisely because they attempt to have centralised control over their networks.  It may be that a federated model that links heterogenous community WiFi initiatives may be more successful; a situation in which an Île Sans Fil user in Montreal might have privileges on a FON or a Meraki network.

So what does this mean for the Village Telco?  I think the Village Telco is likely to address the key sustainability issues that Middleton raises about these networks.  I like the general criteria (pictured at left) that she comes up with to assess the networks.  I think they will be useful benchmarks to keep in mind as the Village Telco evolves.