Hi Steve, Jeremy has already answered your questions well from a Serval perspective, but I offer my perspective as well. On Sun, Nov 27, 2011 at 8:22 PM, Song, Stephen <stephen.song@gmail.com> wrote:

On 27 November 2011 11:32, Jeremy Lakeman <jeremy@servalproject.org> wrote:

...

"Reason 1: Management is hard and expensive." That's why we want a network that auto-discovers topology. And provides easy to use debugging information to assist in placement of additional nodes.

I agree that there is lots of scope for improving this. B Computers used to be hard to use and Apple has succeeded in making them stupidly easy. B This can happen for mesh networks too.

Absolutely agree here. Indeed, Serval has worked from the outset to make mesh telephony insanely simple to use, and I think we have made significant advances on the state ease of use and management of mesh networks in the process, with more innovation in the pipeline.

...

"Reason 2: Omni-directional antennas suck. ... Reason 3: Your RF tricks wonbt help you here. ... Reason 4: Single-radio equipment doesnbt work; multi-radio equipment is very expensive." Fair enough. But we don't actually plan to build a wifi mesh network covering the globe. One un-censored connection to the internet is enough to join each little mesh network into the global internet. Store and forward; and wandering nodes may be enough to enable *some* communication in places where there isn't enough coverage yet for real-time traffic. Some communication is better than none.

The directional versus omnidirectional debate is a bit of a red-herring I think. B The author seems to be assuming that all connections would be distant or at the edge of WiFi capacity. B If mesh nodes are reasonably close you could actually consider turning the radio power down as opposed to up which would reduce interference. Also, there is no reason not to have a "directed" mesh where semi-directional devices like nsIIs or similar cover an arc of a community. B There are lots of creative things that can be done here such as mesh segmenting, supernodes, etc. B Perhaps that would disqualify them from being traditional mesh networks but who gives a stuff about that?

We agree heartily. Pure mesh networking fails in the way that a lot of other pure pursuits fail. But some judicious symmetry breaking can yield large dividends, and this is the approach we are already pursuing, e.g., by using the internet for backhaul when it is available.

...

"Reason 5: Unplanned mesh networks break routing" Well, partly. Sure you're going to use bandwidth in order to compute routing paths. But I think this is not insurmountable. Definitely needs to be more work in this area though to ensure you avoid routing loops and black holes. And this is something that we are already researching and plan to tackle further.

"unplanned wireless mesh networks never work at scale" Yep, there's an "event horizon" issue. If you spend too much bandwidth describing remote paths through the network, you'll have nothing left for actual data. So we absolutely need to limit the distribution of full topology information to ensure that local nodes can still communicate even if the greater mesh network is practically infinite. Beyond that limit you either interconnect via the internet, or we invent some other high level structure, address prefix / numbering scheme.

So, from a Serval perspective this seems to be a good question. B If the mesh protocol takes 1-2 minutes to "settle", how is it possible for a mesh network based on moving mobile phones to update routes fast enough to keep up. B Unless I miss something, the mesh routing is going to be constantly playing catch up unless everyone stays still.

We have some early work on very fast converging mesh networks in certain circumstances that we expect to map across at the right time. Basically, I have confidence that this can be substantially worked around. Also, the use of UHF/TVWS spectrum, low bit-rates and simple waveforms offers great potential to work around much of the problem in other creative ways, for example by switching voice calls to a very-long-range but very-low-bit-rate circuit, that would be capable of carrying a call over a single hop that would otherwise require perhaps half a dozen hops at higher bit-rate. Frequency hopping to make interference statistical is also a great help here. I am still writing up our initial plans in this space, and will make them public once we have a decent draft.

Have you guys done any testing of say 10 phones or more in a field environment?

As Jeremy has said, we have, and BATMAN has performed quite poorly. Part of this is really easy to fix, in that the link score calculation is slow to reflect lost links, and not fast enough to grab new good links. But we expect other interesting effects to emerge as we work on this.

...

There are 2 billion(-ish) people out there with no affordable access to communications. This is absolutely a problem we should be dedicating time to solve. Not just to "fight Internet censorship", but to allow these people to be heard.

Three unique problems:

1) B provide affordable communication infrastructure for those for whom access is either unavailable or unaffordable, the so-called other 2-3billion 2) B provide resilient alternative communication infrastructure to ensure that communication is not restricted by centralised control 3) B provide easy-to-deploy infrastructure for use in crisis/disaster relief scenario

Mesh network infrastructure can potentially address all three of those issue but your technology development priorities will change depending on which one of the above is your mission. B Which one is Serval's mission?

I think I am inclined to agree with Jeremy that we see a common technology that is able to address all three fairly well. For example, (3) needs fool-proof deployment and management-free operation, but so does (1) and (2), but for different reasons. So we see the solution as requiring: - zero-configuration - tolerance of partitioning of the network - ability to scale, and maintain local operation when scaling beyond the bandwidth-limit event horizon. - security - use of existing phone numbers What differs for each use case is in some ways limited to how people use this platform, but fundamentally they all depend on the common ability of a phone to make/receive calls,sms,mms other data without recourse to infrastructure, and offering individuals the degree of privacy and security, and to some extent, the reliability, that people expect from a telephone network. Our Rhizome store-and-forward approach is a key element in all this, because it allows for almost insect-like persistence of retrying delivery, so that the instant a passage through the network becomes available it can be exploited. Also, Rhizome solves the nasty exponential bandwidth and arrival probability problem that otherwise hamstrings multi-hop wireless meshes. In fact, I would say that the fundamental reason why we think we (and this includes Village Telco) are able to make mesh networking work, is because we have focussed on a telephony-oriented model, where data volumes are lower, and where the user interface is simplified to telephone-level, which people understand, and which equally importantly, hides all of the mess underneath. It is also why we are not afraid of our planned overlay mesh network not being backward compatible for use by non-Serval-aware applications, as it will keep them from making inefficient and inconsiderate use of bandwidth, while allowing the use of the various innovations we have prototyped and have on the drawing board. On this note, we hope to be able to share a technology roadmap for the next 12 months in coming days. Paul.

Cheers... Steve

...

On Sun, Nov 27, 2011 at 7:17 PM, Alasdair Mclellan <alasdair@servalproject.org> wrote:

...

Hmm, There are a bunch of good points in this article, but none of them take into account the simple facts that; 1) An unplanned mesh is better than nothing (and 'nothing' is our primary use case), and 2) Everyone has a handset. Replacing the Internet with an unplanned mesh is, indeed, hard - especially when you need a dedicated node type to do so. Using people's existing handsets changes the game a bit (although exactly how much remains to be seen). Just my quick $0.02. Cheers, -- Alasdair.

On Sun, Nov 27, 2011 at 5:54 PM, Ben Hughes <ben@benrhughes.com> wrote:

...

http://sha.ddih.org/2011/11/26/why-wireless-mesh-networks-wont-save-us-from-...

Via hackernews. Would be interested in hearing what tguys think, seeing as you have lots of real-world experience.

Ben

-- You received this message because you are subscribed to the Google Groups "Serval Project Developers" group. To post to this group, send email to serval-project-developers@googlegroups.com. To unsubscribe from this group, send email to serval-project-developers+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/serval-project-developers?hl=en.

-- You received this message because you are subscribed to the Google Groups "Serval Project Developers" group. To post to this group, send email to serval-project-developers@googlegroups.com. To unsubscribe from this group, send email to serval-project-developers+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/serval-project-developers?hl=en.

-- You received this message because you are subscribed to the Google Groups "Serval Project Developers" group. To post to this group, send email to serval-project-developers@googlegroups.com. To unsubscribe from this group, send email to serval-project-developers+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/serval-project-developers?hl=en.

-- Steve Song http://manypossibilities.net http://villagetelco.org

-- You received this message because you are subscribed to the Google Groups "Serval Project Developers" group. To post to this group, send email to serval-project-developers@googlegroups.com. To unsubscribe from this group, send email to serval-project-developers+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/serval-project-developers?hl=en.

-- You received this message because you are subscribed to the Google Groups "Serval Project Developers" group. To post to this group, send email to serval-project-developers@googlegroups.com. To unsubscribe from this group, send email to serval-project-developers+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/serval-project-developers?hl=en. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE