As part of the proof-of-concept work around the Mesh Potato, David and Elektra have more or less settled on the Atheros AR2317 chip as a likely candidate for the Mesh Potato.  This is partly because it is a very affordable chip yet still has all the features needed for the Mesh Potato but also because it is a chip that Atcom have indicate they have ready access to.

In order to confirm that the AR2317 would perform adequately, Elektra purchased a D-Link DIR-300 which is based on the AR2317.  Elektra points out that the DIR-300:

is less then half the price of a Linksys WRT54GL and about a third the price of a Ubiquiti NS-2. It features 4MB flash and 16MB RAM, 4 port switch, 1 WAN port, a 180MHz Mips (Big Endian) CPU, Redboot Open-Source bootloader, a switched mode onboard DC/DC converter, one R-SMA antenna socket, on-board serial port and JTAG port. The device is much smaller than the Linksys WRT54GL, so outdoor boxes can be much cheaper and easier to mount than outdoor boxes for the Linksys.

As an added bonus, Elektra has posted instructions on how to set up OpenWRT a DIR-300 on the Village Telco wiki.

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.

Wireless AP and ATA

So what does this mean for the Mesh Potato? Our challenge at the moment is to create a prototype of the Mesh Potato on which both functional and performance aspects of the Mesh Potato concept can be tested. In oversimplified terms, this consists of wiring a Wifi access point and an analogue to telephony adapator (ATA) together to functionally if not physically imitate the operation of the Mesh Potato. This will constitute a basic platform on which the Mesh Potato software can be developed and tested.

In the Village Telco workshop, we took the decision to develop the Mesh Potato using a similar chipset to the one used in the Ubiquiti Nanostation 2 and indeed in the OpenMesh Accton mini-APs. Both of these devices use an Atheros chipset which is gaining popularity in the wireless networking world as a being affordable, powerful, and developer friendly. So the Mesh Potato prototype will consist of a Nanostation 2 physically wired up to an ATA of some description.

The code referenced above is a version of OpenWRT adapted to run on the Nanostation 2. Next steps will including installing the speech compression/decompression software and the interface to the ATA. Then the actually performance testing can begin.

Assuming all of that goes well, the next phase begin to address the actual hardware design of the Mesh Potato.

The Mesh Potato

I’m very happy to say that the Shuttleworth Foundation has completed agreements with David Rowe and Elektra and that they are now hard at work on the production of a Mesh Potato proof-of-concept.  David has just posted a fairly detailed kick-off post on his blog.  A rough time-frame for the Mesh Potato is to produce a proof-of-concept by November, hand-made prototypes by early 2009 and hopefully production Mesh Potatos by mid-2009.  All software developed for the Mesh Potato will be stored in an SVN repository on Sourceforge.

Simplified Billing

The Foundation has also now provided support to Dabba to work on a simplified interface to A2Billing aimed at Village Telco operation.  Early results of this work should be available on the Village Telco website by the end of October.

Mesh Deployment and Management Software

This work is currently being carried out by the CSIR.  Stand by for an update on that.

You can see the full list of participants here or click here to put a face to all the names but topping out the geek factor at the workshop were David Rowe, Open Hardware pioneer and developer of the Free Telephony Project; Elektra, author of the B.A.T.M.A.N. mesh networking protocol; Jeff Wishnie, Chief Technology Officer for Inveneo; and, Alberto Escudero-Pascual of IT46.

The intent of the workshop was to bring together the right people to be able to prototype a Village Telco, with the intention of getting some configurations and code up on to the website so that interested parties would have something to hack on. As you can see from the picture at left, we had no shortage of wireless hardware to experiment with and four servers lined up to start assembling Village Telco software on. Well, as they say in the U.S. Army, “no plan ever survives contact with the enemy”. We never did build a prototype but we did something better, we brainstormed a new, low-cost startup model for a Village Telco.

Low-cost wireless networking a powerful concept with a thousand potential applications. Unfortunatley, this strength is also its weakness in helping people get started with low-cost WiFi and VoIP. Because you can do just about anything, the endless configurability is an intimidating prospect for even the above-average geek. Our challenge was to create something simple enough to use that an entrepreneur with only modest technical skills could see how to implement and scale up a village telco.

In order to keep the discussion honest, we agreed to use Dabba as the use case against which we would design a solution. Right now Dabba is operating in South African townships which are typically low-income, high-density and most of which have existing, but arguably expensive or inconvenient, telecoms services from the mobile operators and the incumbent, Telkom. But even this was not enough to ground the discussion. We needed to constrain the discussion to something as specific as possible. At first we talked about what would be required to cover a fixed area, say nine square kilometres, but after some time that seemed too ambitious for a bootstrapping startup. In the end, we decided to ask the question, “What could be achieved with USD 5000?” and given that investment “Could you break even within six months?”

One early leap forward in the workshop was to recognise the superiority of the Ubiquiti Nanostation as an external access point. While there is no question that the Linksys WRT54Gx series of wireless routers have played a seminal role in the Open Source movement around wireless networking, there is no getting around the fact that they are designed for indoors and there is a significant cost increase associated with ruggedizing them for outdoors. The Nanostations cost the same as the WRT54GLs but come pre-built in a ruggedized outdoor housing with mounting brackets. The Nanostation is also more powerful than the Linksys routers.

Having established a preference, discussion revolved around how open the Ubiquiti Nanostation is. The Nanostations can run OpenWRT and Inveneo had already had some success compiling the quagga routing protocol to run on it. Unfortunately, some of the tunable antenna functionality is lost with the OpenWRT software but this is not really a significant factor in the context of the Village Telco. The amazing thing about having Jeff and Elektra there was that they were able to test on the spot whether B.A.T.M.A.N. could be compiled for OpenWRT on the Nanostation. A couple of hours of quiet conspiring later and presto, the mesh protocol was running on the Nanostation!

While the idea of a mesh network is to have each node extend the mesh, a good first step for a Village Telco would be to start with a “Super Node” which would help the Village Telco Entrepreneur (VTE). A Super Node might be three Ubiquiti Nanostations mounted on a single pole above the premises of the VTE. This would offer a 2 kilometre radius of coverage to the Village Telco.

However, the Super Node reaching 2 kilometres is not the same as a VoIP handset reaching back that same distance. We had been thinking of typical wireless VoIP handsets such as the one by UT Starcom pictured at right. While this kind of device offers signficant advantages such as mobility and a built-in battery, it is also true that the range of such a phone is only about a 100 metres. Using this kind of phone would mean a dramatic increase in the number of wireless access points required to give service to a particular area. We either needed to think of a way of driving down the cost of an access point or increasing the power of the customer’s equipment.

As an aside, the two key cost factors that emerged in the scale-up of the Village Telco concept were a) the cost of the customer’s phone or Customer Premises Equipment (CPE) as I believe it is called in the trade; and, b) the cost of power supply to the wireless mesh access points. We made the assumption that it was critical for the network to have guaranteed power but that it was a nice-to-have rather than a must-have for the CPE.

As we brainstormed how to drive down the cost of the CPE, we discussed the potential of small mini-APs such as the Accton Mini-router sold by OpenMesh. These tiny APs are capable of running an adapted version of B.A.T.M.A.N. called, yes you guessed it, Robin. The combination of an OpenMesh router and a SIP phone would provide the CPE needed for a Village Telco. However, SIP phones are still not that cheap. We decided that what would be ideal would be a combination of a simple Analogue Telephony Adaptor (ATA) combined with something like an Open Mesh mini-router. There is something to be said for having equipment right in front of you because the idea of actually gaffer-taping an ATA to an Open Mesh router actually struck a chord with the workshop.

With a less amazing group, the conversation might have stopped there but as it turned out we brainstormed the existence of a device which we decided to call a Mesh Potato which would combine the functionality of an ATA and a mesh AP, and would be low-power, Open Source, Open Hardware, pre-ruggedized for outdoors and be easy-to-install and manage. Target cost of such a device would be sub USD 60 per device. In quantity, should we pull this off, the cost should be much lower.

So, with that we came to our 5000 dollar recipe for a Village Telco startup. USD 5000 should get you a server and printer (for pay-as-you-go coupons) running Asterisk and A2billing (modified into simple management framework), an Ubiquiti Nanostation-based Super Node and about 40 Mesh Potatoes or in other words something like this:

In my next post, I’ll talk more about scope of work involved in bringing these ideas to fruition. In the mean time, you can read the raw outputs of the workshop at http://wiki.villagetelco.org. If you are interested in getting involved as a developer, please sign up to the Village Telco development list at http://groups.google.com/group/village-telco-dev.

Handsets prove to be a particular challenge for a couple of reasons. An initial assumption for the Village Telco was that low-cost VOIP handsets would probably be the most viable, convenient way of delivering telephones to customers. While the cost of VOIP phones appear to be steadily descreasing and the convenience of a handheld, battery powered device is very attractive, the small antenna is a signficant problem for a Village Telco. Even when you have access points that cover up to a two kilometre radius, wireless VOIP phones would need to be no more than 100 metres away for a reliable connection. This significantly drives up the number of wireless access points that would be required to cover a given area, signficantly driving up the overall startup cost.

In order to keep the number of access points down, the antenna for each user’s phone would have to be stronger. Another possibility would be to use a small mesh device like the Open Mesh AP and connect a SIP phone to the AP. This would solve the antenna problem and also increase the coverage area as each phone would also be a mesh node. Unfortunately this is still a comparatively expensive option.

As we were debating the options, someone grabbed an ATA (Analog Telephone Adaptor) and an OpenMesh AP and held them together and said, what we need is these two devices in one. And thus the idea for a Mesh Potato was born. The name Mesh Potato came from combining Mesh with POTS (Plain Old Telephone Service) and ATA. Patata is Spanish for potato and Alberto Escudero-Pascual made the link…. The Mesh Potato…. a Mesh enabled WiFi device with an RJ11 port to connect an inexpensive regular phone and an RJ45 to connect any IP device.

The device would be based on the Aetheros chipset used by Meraki and OpenMesh and would run OpenWRT and BATMAN. Asterisk would deliver the telephony function. Designed with a weatherproof housing, this device could be attached to the outside of a house or would even work inside if need be. Pre-configured, it would be plug and play for a new Village Telco client.

Now, had Open Hardware maverick, David Rowe, not been at the workshop, this might have been idle speculation on a “love-to-see” technology. As it turned out, David said “I could do that….”. I don’t think we all took him completely seriously at first but as the conversation ensued, it appears that bringing together the right designers, developers, and manufacturers was eminently possible. The more we discussed it, the more excited we all became that we might be able to drive our own hardware design in stead of depending on the luck of the market to come up with technology that could be appropriated for developing countries.

So, we are going to try it. The Shuttleworth Foundation is going to backstop the initial development of the hardware design and firmware development. Standby…. prototype by December 2008.

An empty shell at the moment.  Please post a message if you would like to get involved.