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.
