Mesh Potato Features and Specifications
Steve Song
David, Elektra, Edwin, and I have been brainstorming a Features and
Specifications sheet for the Mesh Potato. You can see it at
http://wiki.villagetelco.org/index.php?title=Mesh_Potato_Features_/_Specs
We'd be very interested to have your feedback, particularly on the
Features and Benefits section. Are they expressed in a way that
expresses the value of the Mesh Potato as you see it? Is there
anything you would add? or modify? or delete?
Feel free to comment here or edit the wiki directly.
Regards... Steve
Paul Gardner-Stephen
On Jul 26, 10:09 pm, Steve Song
> Hi all,
>
> David, Elektra, Edwin, and I have been brainstorming a Features and
> Specifications sheet for the Mesh Potato. You can see it at
>
> We'd be very interested to have your feedback, particularly on the
> Features and Benefits section. Are they expressed in a way that
> expresses the value of the Mesh Potato as you see it? Is there
> anything you would add? or modify? or delete?
>
> Feel free to comment here or edit the wiki directly.
be to add a uses section. The features/benefits deals with individual
aspects of the unit, but a uses section would cover a few simple but
compelling use cases to make it clear that this is a revolutionary
device, and to help widen peoples perspective. Whether that can still
fit on a single page, I am not sure.
PS: I am happy to start looking at more formal integration of DNA onto
the Mesh Potato anytime now.
Paul.
Paul Wolstenholme
Looks good to me, except that I think you are very bold to claim:
"Protection: ..., nearby lightning, ..."
Perhaps replacing the word "lightning" with "surges" would more fairly
represent reality - unless you have information on failures (daughter
boards in particular) that supports your claim.
Paul W
Steve Song
A "Uses" section is a great idea. Thanks Paul!
> PS: I am happy to start looking at more formal integration of DNA onto
> the Mesh Potato anytime now.
Perhaps we could attempt to demo DNA on the MPs at the Community
Wireless Summit in Vienna?
BTW... is anyone else on the list going to be at
http://wirelesssummit.org/ ? Would be very happy to meet up if so.
Cheers... Steve
Steve Song
A reasonable point. I think it is fair to stick with surges until we
have more evidence on how the MPs behave in the wild.'
Cheers... Steve
elektra
> BTW... is anyone else on the list going to be at
> http://wirelesssummit.org/ ? Would be very happy to meet up if so.
c u there.
Elektra
Paul Gardner-Stephen
I'll be there too, it will be great to meet both yourself and Steve as
well as anyone else who is coming.
Paul.
On Jul 28, 8:02 am, elektra <onelek...@gmx.net> wrote:
> Hello Steve -
>
> > BTW... is anyone else on the list going to be at
>
> c u there.
>
> Elektra
David Rowe
The Dili Village Telco is working well after a few months, and will soon
be expanded for 10 to 100 nodes across 3 sites in Timor Leste.
In East Timor, the killer app for Village Telco is local calls. So no
server and no GSM/PSTN or even VOIP upstream connectivity. Until now we
have always assumed that some "Guy in the Village" will be making money
from off-mesh calls and using that income to maintain his Village Telco.
So, how do we provide an income to sustain a local call only Village
Telco network?
Open to ideas....
Cheers,
David
David Carman
> So, how do we provide an income to sustain a local call only Village
> Telco network?
1. Purchases and installations
The VT entrepreneur can mark up on the MP cost and charge an install fee.
2. Rentals
The MPs can be rented to users. I prefer self-owned because the
liability due to failed equipment is offloaded onto the owner, and
people tend to take better care of what is theirs.
2. Tech support
If the MPs are self-owned, there is no need for the VT entrepreneur to
spend time or money on the network, and therefore shouldn't get a free
lunch. However, there will be plenty of tech support requests,
especially to do with signal strength. Users are given the option of
educating themselves or paying someone to do the job for them.
David
Rael Lissoos
this is brilliant, the bus model is something that we have been testing
hopefully i will be able to post some ideas soon
the ideas below are also good on the free call model
rael
David
--
You received this message because you are subscribed to the Google Groups "village-telco-dev" group.
To post to this group, send email to village-...@googlegroups.com.
To unsubscribe from this group, send email to village-telco-...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/village-telco-dev?hl=en.
Vickram Crishna
David
--
You received this message because you are subscribed to the Google Groups "village-telco-dev" group.
To post to this group, send email to village-...@googlegroups.com.
To unsubscribe from this group, send email to village-telco-...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/village-telco-dev?hl=en.
Don Onwunumah
I will be there too, at the least I should be able to learn something crucial from you 'masters'. Let me know if you guys require any assistance, I will be willing to help.
Regards,
Don
David Rowe
me that the Scarborough mesh business model might be applicable to a
local VT.
Rather than individual node maintenance I think there is a need for a
network-wide "phone wallah" (to use an Indian term). Mesh networks are
really different from point-multipoint (like a cell phone network). If
your MP stops making calls it might be because the guy next door
accidentally unplugged his. You rely on each other to relay calls. So
there is more to it than just maintaining your node - a community wide
approach is required.
David C, I have a concern about (3) - the tech support model might have
a problem. I have visited a country where the phone lines are
maintained just well enough so that the phone guy will get called out
every 4 weeks! It would be better to have a model that makes
reliability an incentive.
One idea I had was a loosely based "license" scheme. This is similar to
the rent idea. The community appoints a phone wallah. Then everyone who
has a MP and gets use out of it pays $1/month, or some amount trivial
compared to a cell phone. If their MP doesn't work, then no pay. This
incentivises (is that a word?):
i) keeping all nodes working
ii) building the network larger, e.g. 500 nodes = $500/month
This could also be implemented by local government (at the village
scale), i.e. taxation to support ongoing telephony. The phone wallah
could then be employed by the local council (or equivalent).
Cheers,
David
> To unsubscribe from this group, send email to village-telco-dev
> +unsub...@googlegroups.com.
David Rowe
converted to cash or goods for the "phone wallah" who does the
maintenance?
I totally agree that phone calls should not be limited in any way. I
guess there is an option of installing a billing system and charging say
1/cent per call. But the idea of all that regulation and "locking up" a
Village Telco rubs me the wrong way. A phone call should be free - to
me communication should be a human right.
With Village Telco technology we have the ability to give everyone free
local phone calls - therefore we should.
I have a feeling the local call focus of the Dili VT is not unique. It
has just exposed an assumption we blindly made that the value in VOIP is
long distance of GSM connectivity. This is why real-world deployments
of the village Telco are so important right now - they expose a bunch of
business and technical issues we hadn't dreamed of.
Re local calls it appears that the frustration and expense of GSM is so
great that people will go to huge lengths (like leaving the GSM network
entirely). Also as 1st world people, we often forget the magic and
economic power of a simple local call over a few km.
Lemi phrased it very elegantly. When I told him he could have low cost
long distance or overseas calls he said "Who are we going to call?"
Thanks,
David
On Wed, 2010-07-28 at 13:45 +0530, Vickram Crishna wrote:
> To unsubscribe from this group, send email to village-telco-dev
> +unsub...@googlegroups.com.
Antoine van Gelder
On 28 Jul 2010, at 22:50 , David Rowe wrote:
> With Village Telco technology we have the ability to give everyone free
> local phone calls - therefore we should.
+1
- antoine
Joy Tang
The focus is not how much profit the sell-and-buy of the ICT devices (VT in this case) would make.
The focus is to experience how much more viable and profitable the users of the ICT devices could have in relation to their life. This would create much more space for good design I feel as this is a natural way to engage in 'human centered design.'
Joy
http://blog.onevillage.tv/
http://twitter.com/unitydrum
http://www.flickr.com/photos/1village
David Carman
On Wed, Jul 28, 2010 at 10:40 PM, David Rowe <da...@rowetel.com> wrote:
> David C, I have a concern about (3) - the tech support model might have
> a problem. I have visited a country where the phone lines are
> maintained just well enough so that the phone guy will get called out
> every 4 weeks! It would be better to have a model that makes
> reliability an incentive.
True. The irony in Scarborough is that when the mesh is not working
well (a gateway or an important relay node goes down), the gateway
bank balance rockets and the tech kids get lots of callouts . When
people get poor service, they naturally want to pay more for better,
and dodgy dealers can create problems in order to solve them. The same
happens in other industries.
> One idea I had was a loosely based "license" scheme. This is similar to
> the rent idea. The community appoints a phone wallah. Then everyone who
> has a MP and gets use out of it pays $1/month, or some amount trivial
> compared to a cell phone. If their MP doesn't work, then no pay. This
> incentivises (is that a word?):
>
> i) keeping all nodes working
> ii) building the network larger, e.g. 500 nodes = $500/month
Spot on - perhaps called a service fee - "license" is a yucky word :)
David C
Mario Marais
In the South African context we have pervasive cellphone (mobile phone) coverage and I've always assumed that we could ask people how much they pay currently for local calls per month ( mobile at 1 SA Rand per minute?) and fixed line to fixed line calls and charge them a % of that cost for use of VOIP. Maybe one should sign people up in pairs - who do you call most? Another way is to look at local "frequent call" formal networks - e.g. schools to educational circuit offices, where principals are making expensive cellphone calls to their local management structure. There must be value to these parties in connecting them via VOIP.
In our context pre-paid works best for individuals on a strict budget.
Just a few thoughts!
rgds
Mario
--
You received this message because you are subscribed to the Google Groups "village-telco-dev" group.
To post to this group, send email to village-...@googlegroups.com.
To unsubscribe from this group, send email to village-telco-...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/village-telco-dev?hl=en.
--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their support.
Antoine van Gelder
> In the South African context we have pervasive cellphone (mobile phone) coverage and I've always assumed that we could ask people how much they pay currently for local calls per month ( mobile at 1 SA Rand per minute?) and fixed line to fixed line calls and charge them a % of that cost for use of VOIP. Maybe one should sign people up in pairs - who do you call most? Another way is to look at local "frequent call" formal networks - e.g. schools to educational circuit offices, where principals are making expensive cellphone calls to their local management structure. There must be value to these parties in connecting them via VOIP.
+1
- antoine
starlinknetwork starlinknetwork
--
You received this message because you are subscribed to the Google Groups "village-telco-dev" group.
To post to this group, send email to village-...@googlegroups.com.
To unsubscribe from this group, send email to village-telco-...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/village-telco-dev?hl=en.
--
Marshall MbekAnako
Phoenix Arizona
(623)570-8306
David Rowe
change the Wifi protocols so that the packet size over the air is much
shorter?
I am thinking about reliable VT operation in high interference or high
load scenarios where longer packets get wiped out but shorter packets
can get through. It could also lead to higher capacity without
aggregation of payload packets.
Compatibility with other Wifi could be maintained as long as we keep the
arbitration mechanism so we don't transmit when some one else is
transmitting.
Shorter packets would also let us apply forward error correction across
packets, e.g. a code that allows packet n to be reconstructed from
information in packets n-1 and n+1.
However I am not sure how much of the Wifi protocol we have access to,
for example most of it may be implemented in hardware or binary blobs
rather than open source drivers.
- David
Paul Gardner-Stephen
On Jul 30, 3:20 am, starlinknetwork starlinknetwork
> My question is where is the internet or how can i secure internet because we
> do not have any yet or we do not have an affrdable one.
> Please can someone give me information on where to get internet ?
developing locations, or how can we connect a VT telephone network to
the internet?
Paul.
> On Tue, Jul 27, 2010 at 11:52 PM, David Rowe <da...@rowetel.com> wrote:
> > Hello List,
>
> > The Dili Village Telco is working well after a few months, and will soon
> > be expanded for 10 to 100 nodes across 3 sites in Timor Leste.
>
> > In East Timor, the killer app for Village Telco is local calls. So no
> > server and no GSM/PSTN or even VOIP upstream connectivity. Until now we
> > have always assumed that some "Guy in the Village" will be making money
> > from off-mesh calls and using that income to maintain his Village Telco.
>
> > So, how do we provide an income to sustain a local call only Village
> > Telco network?
>
> > Open to ideas....
>
> > Cheers,
>
> > David
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "village-telco-dev" group.
> > To post to this group, send email to village-...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > .
elektra
> This is a question (probably for you Elektra). Is it possible for us to
> change the Wifi protocols so that the packet size over the air is much
> shorter?
I'm not sure whether it is worth going that way, given that we are probably
not saving much overhead if we would stick with CSMA/CD.
Cheers,
Elektra
Paul Gardner-Stephen
This is why getting ad-hoc mode to interoperate is a pain at times,
even though it should be easy to do, at least for our purposes where
we just want to put packets on the air and take them off again.
Having said this, I think that we can perhaps decompose your question
into two sub-questions to explore in parallel:
1. Assuming that we have to use the wifi air-interface, how can we at
layer 2 or 3 add error correction and other techniques to mitigate
interference and packet loss?
2. If we can dive deeper and get into the drivers, what can we do to
achieve (1) better at the physical-layer?
This also raises questions like:
- Can we get a wifi driver to pass up packets that contain errors, so
that we can apply our own error correction, and so recover as much of
the payload as possible?
- Can we switch to a layer 2 protocol for carrying VoIP, and so bypass
the extra packet length (and transmission delay, and increased error
probability)?
It strikes me that this could halve our packet length, with all sorts
of lovely advantages.
Also, there is almost certainly no question as to IF, but how much
effort is required.
It might necessitate using BATMAN-advanced to drop to that layer, but
I think it could be done without that using some networking
skullduggery.
Here is what I am thinking:
a. We make a tun device that acts as the IP route to the destination
point (DNA could easily re-map the SIP destination to it to keep
things simple).
b. The tun device takes the IP packets passed to it, strips them of
their UDP and IP headers if they are VoIP data packets, adds some
error correction and redundancy codes so that we can reconstruct any
one lost packet, and forwards them to the MAC of the next BATMAN-
informed hop to the destination. These ethernet frames would then be
marked with a special protocol number, and tagged with the IP of the
eventual destination.
c. Each node listens to the air interface for such frames, checks the
BATMAN routing table and forwards the frames as required to next hop,
or if it is the destination, reconstructs the IP & UDP headers and
causes the packet to emerge from the tun device on that node.
d. If packets have been missed (or are just out of order etc), but can
be reconstructed, then those packets are reconstructed.
The advantages of this approach are:
1. We don't need the WiFi drivers to send raw ethernet frames.
2. tun interfaces are available in most Linux kernels.
3. We can fairly easily merge this kind of functionality into the
existing services that we run on an MP or BatPhone
4. Some WiFi cards will let you choose to accept packets with bad
checksums. With some care, we could use error correction to recover
those packets. But on interfaces that do not allow this, we still
have a good fall-back of reconstructing packets.
5. If the remote end doesn't support it, it is easy to fall back to
ordinary IP over WiFi
6. We can keep using asterisk/SIP etc, instead of having to invent and
implement our own protocol.
Basically in return for a bit of effort we swap IP and UDP overhead
for error correction of the kind you desire.
I have done this kind of network gruel before.
Gotta run now, but let me know what you think,
Paul.
David Rowe
> 1. Assuming that we have to use the wifi air-interface, how can we at
> layer 2 or 3 add error correction and other techniques to mitigate
> interference and packet loss?
Actually what I am proposing is thoroughly breaking the current Wifi
protocol for our own selfish purposes. In particular, the current
timers in CSMA/CD that make us sitting around doing nothing for 90% of
the time with short packets.
Our protocol would then look like an interferer to regular Wifi in the
vicinity. As we would be using small gaps it might not matter much, we
could slip through the cracks. It's unlicensed spectrum, so I figure we
are free to do whatever we want.
Then (after we have an efficient physical layer) start forward error
coding across packets.
Thanks for you other ideas - all very valid and useful.
If any one on the list is in, or entering academia, this sort of work
would make a great thesis topic.
Cheers,
David
Donald Gordon
On Fri, Jul 30, 2010 at 11:14 AM, Paul Gardner-Stephen
<paul.gardn...@gmail.com> wrote:
> - Can we switch to a layer 2 protocol for carrying VoIP, and so bypass
> the extra packet length (and transmission delay, and increased error
> probability)?
> It strikes me that this could halve our packet length, with all sorts
> of lovely advantages.
> Also, there is almost certainly no question as to IF, but how much
> effort is required.
> It might necessitate using BATMAN-advanced to drop to that layer, but
> I think it could be done without that using some networking
> skullduggery.
> Here is what I am thinking:
>
> a. We make a tun device that acts as the IP route to the destination
> point (DNA could easily re-map the SIP destination to it to keep
> things simple).
> b. The tun device takes the IP packets passed to it, strips them of
> their UDP and IP headers if they are VoIP data packets, adds some
> error correction and redundancy codes so that we can reconstruct any
> one lost packet, and forwards them to the MAC of the next BATMAN-
> informed hop to the destination. These ethernet frames would then be
> marked with a special protocol number, and tagged with the IP of the
> eventual destination.
This all seems very complicated compared to e.g. using
Batman-advanced, which runs at layer 2 and has support for
concatenating small ethernet frames together, reducing the
packets-per-second over the wifi interface. And you could shoehorn
some RTP header compression code into that layer, maybe?
In my experience passing packets through userspace via tun incurs
quite a high CPU usage overhead; I don't know how much headroom there
is on the potatoes CPU wise but I wasn't under the impression it was a
lot.
donald
Paul Gardner-Stephen
On this note, is the wifi driver for the mesh potato completely open,
or does it have a binary blob?
Paul.
David Rowe
IIRC there is a binary blob from our good friends at Atheros called "the
HAL". Shades of 2001. On top of this sits MadWifi, which is open.
Cheers,
David
Steve Song
What about a VT / Serval dinner on the evening of the 13th? The
schedule indicates it is an open evening.
@Elektra, I will be bringing Antoine's latest and greatest version of
Afrimesh. Perhaps we can take some time to hack it into your most
recent VTE server ISO?
Cheers... Steve
--
Steve Song
Telecommunications Fellow, Shuttleworth Foundation
email: steve...@shuttleworthfoundation.org
work: +27 21 970 1220
mobile: +27 83 482 2088
skype: steve_l_song
blog: http://manypossibilities.net
twitter: stevesong
elektra
> What about a VT / Serval dinner on the evening of the 13th? The
> schedule indicates it is an open evening.
with pleasure!
>
> @Elektra, I will be bringing Antoine's latest and greatest version of
> Afrimesh. Perhaps we can take some time to hack it into your most
> recent VTE server ISO?
Naturally!
Looking forward to meet you all soon!
Cheers,
Elektra
Rudolf Meijering
This could potentially become a very interesting research topic. It would certainly be possible and the (completely oss) ath9k drivers and 802.11n cards would provide more oppertunities. (There was an advertisement on the mailing list for someone looking for a developer to change the driver to enable greater experimenting with mac protocol variables).
A good starting point would be the Wildnet, here is an excerpt from one of the papers:
"...networks yield very poor end-to-end performance due to two reasons. First, the current 802.11 MAC protocol has fundamental shortcomings when used over long-distances. Second, WiLD networks can exhibit high and variable loss characteristics, thereby severely limiting end-to-end throughput. This paper describes the design, implementation and evaluation of WiLDNet, a system that overcomes these two problems and provides enhanced end-to-end performance in WiLD networks. To address the protocol shortcomings, WiLDNet makes several essential changes to the 802.11 MAC protocol, but continues to rely on standard WiFi network cards. To better handle losses and improve link utilization, WiLDNet uses an adaptive loss-recovery mechanism using FEC and bulk acknowledgements. Based on a real-world deployment, WiLDNet provides a 2–5 fold improvement in TCP/UDP throughput (along with significantly reduced loss-rates) in comparison to the best throughput achievable by conventional 802.11 MAC. WiLDNet can also be configured to adapt to a range of end-toend performance requirements (bandwidth, delay, loss, jitter)"
--
You received this message because you are subscribed to the Google Groups "village-telco-dev" group.
To post to this group, send email to village-...@googlegroups.com.
To unsubscribe from this group, send email to village-telco-...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/village-telco-dev?hl=en.
--
Rudolf Meijering
Paul Gardner-Stephen
Paul.
On Jul 30, 9:57 pm, Steve Song <steve.s...@shuttleworthfoundation.org>
wrote:
>
> What about a VT / Serval dinner on the evening of the 13th? The
> schedule indicates it is an open evening.
>
> @Elektra, I will be bringing Antoine's latest and greatest version of
> Afrimesh. Perhaps we can take some time to hack it into your most
> recent VTE server ISO?
>
> Cheers... Steve
>
Paul Gardner-Stephen
On Jul 31, 5:27 am, Rudolf Meijering <skaap...@gmail.com> wrote:
> Hi Paul,
>
> This could potentially become a very interesting research topic. It would
> certainly be possible and the (completely oss) ath9k drivers and 802.11n
> cards would provide more oppertunities. (There was an advertisement on the
> mailing list for someone looking for a developer to change the driver to
> enable greater experimenting with mac protocol variables).
> A good starting point would be the Wildnet, here is an excerpt from one of
> the papers:
>
> "...networks yield very poor end-to-end performance due to two reasons.
> First, the current 802.11 MAC protocol has fundamental shortcomings when
> used over long-distances. Second, WiLD networks can exhibit high and
> variable loss characteristics, thereby severely limiting end-to-end
> throughput. This paper describes the design, implementation and evaluation
> of WiLDNet, a system that overcomes these two problems and provides enhanced
> end-to-end performance in WiLD networks. To address the protocol
> shortcomings, WiLDNet makes several essential changes to the 802.11 MAC
> protocol, but continues to rely on standard WiFi network cards. To better
> handle losses and improve link utilization, WiLDNet uses an adaptive
> loss-recovery mechanism using FEC and bulk acknowledgements. Based on a
> real-world deployment, WiLDNet provides a 2–5 fold improvement in TCP/UDP
> throughput (along with significantly reduced loss-rates) in comparison to
> the best throughput achievable by conventional 802.11 MAC. WiLDNet can also
> be configured to adapt to a range of end-toend performance requirements
> (bandwidth, delay, loss, jitter)"
about their work, but have had to be so narrow with my critical path
due to lack of time that I have not had opportunity to explore it
further. But it is on Serval's technology road-map to explore this,
along with a number of other things.
Paul.
> > .
Paul Gardner-Stephen
I am also anxious to retain interoperability with mobile phones.
Paul.
Paul Gardner-Stephen
On Jul 30, 8:58 am, Donald Gordon <d...@dis.org.nz> wrote:
> Hi
>
> On Fri, Jul 30, 2010 at 11:14 AM, Paul Gardner-Stephen
>
>
>
>
> <paul.gardner.step...@gmail.com> wrote:
> > - Can we switch to a layer 2 protocol for carrying VoIP, and so bypass
> > the extra packet length (and transmission delay, and increased error
> > probability)?
> > It strikes me that this could halve our packet length, with all sorts
> > of lovely advantages.
> > Also, there is almost certainly no question as to IF, but how much
> > effort is required.
> > It might necessitate using BATMAN-advanced to drop to that layer, but
> > I think it could be done without that using some networking
> > skullduggery.
> > Here is what I am thinking:
>
> > a. We make a tun device that acts as the IP route to the destination
> > point (DNA could easily re-map the SIP destination to it to keep
> > things simple).
> > b. The tun device takes the IP packets passed to it, strips them of
> > their UDP and IP headers if they are VoIP data packets, adds some
> > error correction and redundancy codes so that we can reconstruct any
> > one lost packet, and forwards them to the MAC of the next BATMAN-
> > informed hop to the destination. These ethernet frames would then be
> > marked with a special protocol number, and tagged with the IP of the
> > eventual destination.
>
> Batman-advanced, which runs at layer 2 and has support for
> concatenating small ethernet frames together, reducing the
> packets-per-second over the wifi interface. And you could shoehorn
> some RTP header compression code into that layer, maybe?
out, the CSMA/CD regime on WiFi introduces some inordinate
inefficiencies.
Also, adding batman advanced makes mobile telephone support all the
more difficult.
Of course, so does messing with the WiFi air interface. However, it
is probably possible to do this in a way that most normal wifi cards
can still accept the frames, e.g., if we transmit eariler than we
would normally be allowed.
However, the real advantage I see to messing with the wifi air
interface is that we can introduce something resemble circuit-
switching to minimise jitter and other undesirable things that happen
with WiFi. This is something that I have been plotting about in the
back of my brain for a while, but have not had time to put any real
effort into. But I think that it is something that would have some
value in exploring.
In fact, really all that VT needs is a WiFi card that can be driven
like an old coax ethernet card: we just want to be able to send and
receive frames, and deal with all the mess at higher layers, including
detecting and dealing with any errors that might occur.
Depending how low the HAL for the ath9k chipset is, this might be
entirely possible.
> In my experience passing packets through userspace via tun incurs
> quite a high CPU usage overhead; I don't know how much headroom there
> is on the potatoes CPU wise but I wasn't under the impression it was a
> lot.
additional burden, it is not as bad as many people claim, especially
for relatively low packet rates, and even more so for small packets
where the copy time is near zero, and the routing time remains
constant. I still think it would be worth trying and measuring.
Paul.
> donald
starlinknetwork starlinknetwork
To unsubscribe from this group, send email to village-telco-...@googlegroups.com.
Steve Song
VSAT solution. One of our partners used it Kafanchan, Nigeria. At
the time, I wasn't aware of how it was going for them. I have since
learned that it didn't really work out for them as it turned out to be
quite expensive in the end.
Perhaps you are aware that the GLO1 cable will go live in Nigeria
before the end of August. The MainOne cable is has also just gone
live. If you are in southern Nigeria, I would imagine that finding a
connection to GLO1 or MainOne is going to be your best bet, whether
directly or through an intermediary. There are more cables coming to
Nigeria. WACS will land there next year and the ACE cable the year
after that. Nigeria should have the cheapest bandwidth in West Africa
very soon.
Regards... Steve
On 31 July 2010 15:14, starlinknetwork starlinknetwork
--
Steve Song
Telecommunications Fellow, Shuttleworth Foundation
email: steve...@shuttleworthfoundation.org
Paul Gardner-Stephen
I believe they have near global coverage now, and seem to be the
service of choice here in Australia instead of VSAT.
I think it backhauled via one of the inmarsats.
Paul.
On Aug 1, 2:47 am, Steve Song <steve.s...@shuttleworthfoundation.org>
wrote:
Paul Wolstenholme
If we are looking at ways of passing more telephony data over limited
bandwidth then consider this:
If node A has a call in progress via node B with node C, then A and C
each send a segment of voice that only B receives. Let's say a is the
segment sent by A and c is the segment sent by C and that they are the
same size.
Conventional wisdom says that node B re-transmits segment a for C to
receive and retransmits segment c for A to receive. That is 2
messages.
But in our system, B uses the same hardware for both transmissions and
both A and C receive these transmissions. Instead of sending 2
messages, B could actually send one message containing both segments a
and c. This halves the number of messages sent by node B.
To make this even better, the message sent by B actually only needs to
contain the exclusive OR combination of a and c, resulting in a
message of the same size as either a or c which we shall call b. Node
A can decode this by evaluating the exclusive OR of a and b (the
result of which is c). Similarly node C evaluates the exclusive OR of
c and b (the result of which is a).
This is a known technique that I saw in a publication this year
although it had nothing to do with the IP protocol. What I haven't
looked into is what headers node B would use on its message so that
both nodes A and C would know to use it. This is no longer a point to
point message but a multi-cast (or bi-cast if there is such a term)
message.
The payoff for this technique, over many-hop links, approaches twice
the calls handled in the same bandwidth.
The techniques already mentioned in this thread to improve performance
in the presence of errors are also needed.
How does this fit with the constraints of our platform?
Cheers,
Paul W.
Paul Gardner-Stephen
On Aug 1, 8:14 pm, Paul Wolstenholme <paulwolstenholme2...@gmail.com>
wrote:
as if either is lost, then it must fall back to "regular"
transmission, but this is no great problem.
The real issue is how to correctly address the packet to two hosts.
Multicast is the usual way to deal with this on IP, but is not always
the simplest solution.
More generally, the advantage I see with using multicast is that it
allows you to stuff the two payloads a and c into a single WiFi frame,
with only double the payload overhead, which is a small percentage of
the air-time taken by either frame.
But then I was trying to figure out when we have multi-hop calls in
progress. Don't we normally have point-to-point calls. I guess you
are talking about when intermediate nodes are relaying calls. In that
case, we would have to move to a tun style regime (or some kernel
hacking) to introduce such creative packet handling.
Also, it would introduce additional latency as each intermediate node
would be performing a synchronous action. This, I suspect, is the
real difficulty that would need to be modelled and solved.
On the up side, given our short payloads, there would be some merit in
a scheme like this to offer a circuit-switched like behaviour.
We could keep an active eye on voice frames going past, and request re-
TX of any in the sequence we lose from the first node that fails to
receive it. This would allow better handling in the face of bit
errors, as it would avoid the end-to-end re-TX latency that makes it
impractical to do so now. The topology information that BATMAN
provides us could be used to support this. This is heading back into
territory that I have been thinking about. It could be trialled in
user-land with a tun, and if it works well, we could then invest the
effort in moving it into a kernel module to gain the performance
advantage. However, given the real-world limits to WiFi performance,
I think that an MP would be able to handle the traffic in most
situations, as the ultimate maximum data rate using small packets will
only be a (possibly very) small fraction of the link speed.
> The techniques already mentioned in this thread to improve performance
> in the presence of errors are also needed.
>
> How does this fit with the constraints of our platform?
advantages for us in moving to such a scheme. The trade-off is the
work required, and the risk regarding the degree of actual benefit
gained. Again, this would be something great to get a research
student working on. I have enough MPs here if I can find a good
student who is interested in the project. I am teaching networks this
term, so maybe I can encourage one of them to go on to further
study :)
Paul.
> Cheers,
> Paul W.
David Rowe
One the problems we discovered with the Dili Village Telco is that we
need many Nanostation 2's to roll out a real world network. I am also
seeing many examples of NS2s or directional antennas in other mesh
network deployments. This is OK in the 1st world, but presents several
problems for the Village Telco.
NS2s are expensive - it costs us USD$170/per NS2 delivered to Dili.
Shipping is the killer to 3rd world locations. Unlike the Mesh Potato
NS2s are closed hardware so we are exposed to the whims of the
manufacturer.
In Dili the ratio of MPS:NS2s is currently 1:2, although I expect this
to drop as we add more nodes and the network fills out. The NS2s are
required as their directional antennas allow us to punch through links
with interference. As NS2s don't do telephony it means many nodes have
a NS plus a MP. This triples the cost per node.
There is also a procurement issue - if a NS2 is suddenly required it may
take 4 weeks to get it. As they are expensive items a budding VT
entrepreneur is unlikely to keep stock (nor should he).
We currently have no rules or diagnostics that tell some one when a
directional link and hence a NS2 is required. It takes considerable
Wifi skills to understand when such a link is required. It took weeks
of work to get just 10 stable nodes up in Dili. So we still have some
work to do to make the "ease of set up" vision of the Village Telco
become reality.
What would be great is a low cost directional antenna option for the MP
(e.g. an add-on reflector, not an expensive 1st world antenna), and some
training and diagnostics that tells "the guy in the village" when a
directional antenna is needed to get a good link.
Cheers,
David
starlinknetwork starlinknetwork
David Carman
On Mon, Aug 2, 2010 at 2:35 AM, David Rowe <da...@rowetel.com> wrote:
> What would be great is a low cost directional antenna option for the MP
> (e.g. an add-on reflector, not an expensive 1st world antenna), and some
> training and diagnostics that tells "the guy in the village" when a
> directional antenna is needed to get a good link.
Is the outside casing of the production MP exactly 8mm away from the
etched antenna? If so, glue and a piece of foil could double
directional gain.
The size and weatherproofing of the production MP also lends itself to
Marcelo's idea of using ubiquitous old TV satellite dishes.
I look forward to playing.
David C
Steve Song
that a Mesh Potato can handle (about 20 in our tests so far) and the
maximum of hops that a Mesh Potato can sustain (no more than 4-5) but
both of these issues can be worked around through network design. So,
in theory there is no limit to the size of a Village Telco but we have
yet to build a large Village Telco network so all of what I have said
needs to be tested. We will have some larger test sites to report on
by the end of October.
Cheers... Steve
On 2 August 2010 02:35, starlinknetwork starlinknetwork