Here is a short note on where things stand with Dabba and the Village Telco. The Shuttleworth Foundation is planning to fund the hacking/adaptation/development, to at least alpha version, of an Open Source “Village Telco” integrated suite of applications. This will be developed based on the business model established by Dabba in Orange Farm and aimed at facilitating the replication of that model.
A lot of the detail written below came out of a half-day brainstorming session that I participated in earlier this month. Rael hosted myself and a three very cool business development / technical / entrepreneur folk from Internet Solutions. Internet Solutions have informally supported Dabba in exploring low-cost telephony and data business models from the very early days. They have an interest since businesses like Dabba are a potentially natural complement to Internet Solutions. I hope in my meeting with them that I also convinced them that there was a useful and important place for an Open Source VillageTelco project which could speed the replication of Dabba-clients and Dabba-like enterprises.
So, as currently planned, the first iteration of the Village Telco will include:
- mesh network provisioning and management
- pay-as-you-go billing and management
- wireless access / captive portal setup and management
- SIP/VOIP server and client management
- least cost routing solutions
subsequent iterations will include:
- an integrated web-based management interface to the Village Telco
- content server
- customer relationship management (CRM)
- caching proxy for web content
- multicast streaming video
So here is a little more detail on what is required to get each of those components off the ground.
Mesh Network Provisioning & Management
Open-mesh.com and Meraki have the slickest mesh network provisioning and management interfaces going. Both are based on the deployment of Meraki wireless routers which run a version of the B.A.T.M.A.N. mesh protocol called RO.B.IN (ROuting Batman INside). Both Open-Mesh and Meraki have very similar interfaces which is not surprising as Open-Mesh was developed as a reaction to Meraki’s decision to close the change to their End User Licence Agreement to preclude anyone from changing any of the software that they install on their units. So now you can buy a Meraki mini router, flash it with Open-Mesh’s more open firmware and connect up your mesh without being locked into Meraki. Pretty cool although you still have to use the OpenMesh site for network management. It would be much better for a Village Telco to have its own network management software that was as cool as Open-Mesh. Happily a group of students at UNC Chapel Hill are developing an Open Source mesh deployment server called OrangeMesh that is compatible with Open-Mesh. This would be a great place to start developing a provisioning interface for a Village Telco, one that would ideally handle both OpenWRT/LinksysWRT54Gx routers running B.A.T.M.A.N. and Meraki Mini or similar devices running RO.B.IN.
Pay-as-you-go Billing and Management
A2Billing appear to have the most robust Open Source voice billing solution for Asterisk that supports pay-as-you-go billing. The goal here would be to create a customised A2Billing configuration particularly geared to the Village Telco environment.
Wireless Access / Captive Portal Setup and Management
There are a few great Open Source captive portal applications. Coova, ChilliSpot, and WiFiDog are probably the best known although Chillispot ceased development some time in 2007 and has morphed into CoovaChilli and there are other hybrids such as CoovaAAAwithWiFiDog. WiFiDog has a great captive portal and customised/localised content for users but relies on a standard password file for authentication which probably means that it will not scale well. Both Coova and WiFiDog have versions of their captive portal software that are designed to run on wireless access points (APs) such as the Linksys WRT54G series. While the Village Telco will use Linksys APs, because the APs will be meshed together, there is no need to run authentication on the local AP. It can be handled at the server. Something like CoovaChilli makes more sense because it authenticates with Radius but it would be nice to also have some of WiFiDog’s captive portal features as well. It sounds like CoovaAAAwithWifiDog should do that but CoovaAAA is a service not a software provided by Coova. For anyone who read my earlier post, you will note that authenticating from the server versus the AP represents a change of strategy.
SIP/VOIP server and client management
The two big applications for SIP authenticating and managing VoIP traffic are OpenSER and Asterisk. In my earlier post, I wrote about running OpenSER on a Linksys AP. Once again, in a mesh environment, it seems that this is not necessary either. OpenSER’s chief advantage over Asterisk in this domain is that it is comparatively very efficient and would be able to route calls within the AP’s coverage area without leaving the AP to authenticate at the server. There are even some very cool OpenSER distributions designed for the Linksys AP such as Milkfish. However, the downside of this is that those calls would not get tracked or would at least be much more work to track. Having a central authentication for calls makes sense as tracking usage patterns will be quite important to managing service delivery and growth. In the end, it probably makes more sense to have a single Asterisk implementation that handles authentication. Once again, because the network is meshed, this should be relatively seamless across APs.
Least Cost Routing Solutions
Least Cost Routing (LCR) refers to the set of tables, software, appliances that ensure that a call is made for the least possible cost. So, for a Village Telco, you would first want to make sure that calls within the WiFi mesh were routed directly to another user within the mesh. Next, if the call were leaving the VillageTelco coverage area, then you would want to have direct connections to all the major networks in order to avoid paying additional interconnect charges. This means having the SIM cards and hardware to route calls to the GSM networks and having the facility to interconnect with the Publicly Switched Telephone Network (PSTN) e.g. Telkom. There is a host of hardware and software for achieving this and part of the challenge will be choosing the right technology. Equally if not more important will be deciding where in the connectivity chain to break out to other networks. In some cases, an isolated Village Telco would have to solve all of these problems by themselves. However in the case of Dabba in South Africa, Dabba can solve many of these problems for local Village Telcos by offering LCR services (among other services) to Village Telco operators. This is particularly important in a place like South Africa where Telkom insists on having carrier-grade interconnection equipment which is typically very expensive.
Customer Relationship Management
The above covers most of the basics of the Village Telco but thinking further forward, it would be great for the Village Telco operator to have the tools to manage relationships with his/her customers. Customer Relationship Management (CRM) tools like Vtiger could offer marketing and support functions to a Village Telco operator that would help them expand their range of services, provide better support, and generally understand their customers better. However, one step at a time and much will depend on how easy it is to integrate something like Vtiger with the other elements of the Village Telco.
That’s a start. Obviously much more to come. Please feel free to post comments, observations, suggestions on the above as this is definitely a work in progress. Also, I’m learning in this space as well so if I have misrepresented issues, forgotten issues, or left out an amazing piece of Open Source software, let me know!
For more software and hardware possibilities, check out the list compiled by Sebastian Beuttrich for the CSIR’s Wireless Africa initiative.
Related posts:
- Dabba: Open Source Components - Access Node
- Theory of Change: The Village Telco
- Village Telco Workshop
- Yabba Dabba Do
- Looking for Possible Village Telco Entrepreneurs in Khayalitsha
Related posts brought to you by Yet Another Related Posts Plugin.
Reposting a message from David Rowe to the Wireless Africa list in reaction to the above.
On May 1, 11:33 pm, David Rowe…@rowetel.com> wrote:
> Hi Steve,
>
> >http://manypossibilities.net/2008/04/village-telco-next-steps/
>
> It is wonderful to see the design work moving along.
Yes, although not half as fast as I would like. However, I think things will speed up over the next couple of moths.
> Not sure if I should comment on the blog site or here, figured here
>
> would have a wider audience. So here goes
> A few comments/questions:
>
> 1/ I notice a few parts of the architecture (authentication, Asterisk)
> moving from the AP to a central server. Do you think this will have an
> impact of reliability, say if a few nodes (or the server) go down?
Very good question. The shift to server authentication means you lose the ability to route calls locally on an access point but for all other calls (i.e. to other mesh nodes, mobile networks, PSTN) you would still need to route through a server. Thinking about it, if it were possible, it would be nice to have a fallover condition where a simple local splash page for the AP (indicating the lack of upstream connectivity) and the possibility to route calls locally. But I have no sense at the moment of how much work that would be. Doesn’t sound too hard
> 2/ With the type of software required it seems like the main server will
> be an x86 class machine (rather than embedded). Will this affect
> rolling out a small system (say a 2-3 node system) to a remote location
> will no electricity? I guess I am pondering on the “granularity” of the
> architecture, can it scale up and down.
I would very much like to see how far one could go with an IP0x box as the hub, however, at this point Dabba have a business model where the break-even for a VT entrepreneur is at about a 1000 users. This is based on setting up in a competitive environment where mobile connectivity and public pay phones are available. I imagine that number would be much smaller in a rural environment where there is less access.
We’ll have to see what kind of load an active server requires. At this point Dabba have established that a WRT54GL access point can handle somewhere between 10 and 20 concurrent calls. I don’t know if they have stats yet for server capacity. One of the first things that the foundation will fund is the setting up of a lab to start testing for the weak points in the communication chain.
> 3/ Any ideas on the user interface and level of skill required to drive
> the system? For example will it be possible for a bright but
> semi-literate person to become a village telco owner/operator?
My goal is to make the Village Telco as easy to set up as setting up a small business on QuickBooks. It would be nice to be able to order self-configuring, Village Telco mesh APs as easily as you can order the Meraki (ROBIN-based) APs. The VT APs would be a Landrover to Meraki’s Volkswagen Beetle. Not that you don’t need VW Beetles but for outdoor use in Africa, something much more rugged is called for. Having said that, it would be ideal if the Meraki devices could also be included in the design but more as indoor devices.
> 4/ What cost/per node (or cost/system amortising the server) are we
> estimating?
At the moment, the cost price of a mesh node such as is being developed by Dabba is in the neighbourhood of USD800. That includes two linksys routers (one for mesh, one for access) and the antenna housing. That is a bit high and I think the price will come down but it is the upper limit. Plus USD700 for solar per node. The server is still an unknown for me in terms of computing requirements. Backhaul connectivity is also a factor. Each of the antenna housings can take three radios (two omnis and one panel directional). So any node can also be configured for backhaul. The mesh design requires that you need backhaul to the server for roughly every 5 nodes.
BTW…. we are thinking of putting together a VT week-long development sprint in the 3rd week of June (in SA). If anyone is interested in attending such an event, please contact me directly.
Regards… Steve
Wifidog has several authentication methods (Internal with and without signup, RADIUS, LDAP), but standard password file isn’t one of them. As for scaling, at least one wifidog server has over 100 000 user accounts.
Many thanks for the correction Benoit. I will edit the post accordingly and look more closely at the WiFidog documentation. Am I correct in assuming you are involved in the Wifidog project? Do you know of any instance where Wifidog has been combined with voice service provision via asterisk?