Comments on: Dabba and Village Telco: Getting to Alpha http://manypossibilities.net/2008/04/village-telco-next-steps/ In the beginner's mind there are... Thu, 20 Nov 2008 15:22:42 +0000 http://wordpress.org/?v=2.6.3 By: Steve Song http://manypossibilities.net/2008/04/village-telco-next-steps/#comment-154 Steve Song Tue, 20 May 2008 13:19:13 +0000 http://manypossibilities.net/?p=61#comment-154 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? 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?

]]> By: Benoit Grégoire http://manypossibilities.net/2008/04/village-telco-next-steps/#comment-152 Benoit Grégoire Mon, 19 May 2008 21:04:57 +0000 http://manypossibilities.net/?p=61#comment-152 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. 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.

]]> By: Telecommunication « Helen King http://manypossibilities.net/2008/04/village-telco-next-steps/#comment-127 Telecommunication « Helen King Fri, 09 May 2008 05:54:50 +0000 http://manypossibilities.net/?p=61#comment-127 [...] Dabba and Village Telco – Getting to Alpha - Defining what is required to get to first base with the Open Source Village Telco project. [...] [...] Dabba and Village Telco – Getting to Alpha - Defining what is required to get to first base with the Open Source Village Telco project. [...]

]]> By: Steve Song http://manypossibilities.net/2008/04/village-telco-next-steps/#comment-117 Steve Song Fri, 02 May 2008 06:57:47 +0000 http://manypossibilities.net/?p=61#comment-117 Reposting a message from David Rowe to the Wireless Africa list in reaction to the above. On May 1, 11:33 pm, David Rowe <da ...@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</da> 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

]]>