public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
From: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
To: The list for a Better Approach To Mobile Ad-hoc Networking
	<b.a.t.m.a.n@open-mesh.net>
Subject: Re: [B.A.T.M.A.N.] Suitability of B.A.T.M.A.N. protocol to my disaster relief network project
Date: Mon, 14 Apr 2008 16:52:07 +0200	[thread overview]
Message-ID: <20080414145207.GA7687@hrz.tu-chemnitz.de> (raw)
In-Reply-To: <4801C1DF.5080600@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 6885 bytes --]

On Sun, Apr 13, 2008 at 03:18:39AM -0500, Tim LePes wrote:
> Greetings!
> 
> If this list is the wrong place to be asking about this, please let me
> apologize up front.  :)

This is exactly the right place to ask questions about B.A.T.M.A.N.,
don't hesitate ... ;)

 
> I am thinking of putting WiMAX radios in the mesh nodes, for the
> purported range.  There are several things that I am unsure of, so any
> suggestions or comments on any points are more than welcome.  Forgive me
> if I just ramble out some of my thoughts/questions here...
> 
> Is WiMAX a good choice for this?  I have not really seen a lot of WiMAX
> hardware.  The SoC board will be running Linux and is a PowerPC
> architecture, so drivers will of course be important with whatever
> radios go in the device.

Personally i have no experience with WiMAX. As far as i could read,
there seems to be a "mesh mode" in WiMAX, but i have no idea on which routing
protocol it is based. Another interesting thing would be if it is
already implemented ....
A fairly new site is: http://linuxwimax.org/ which provides intel
wifi/wimax link 5050 support. 
If i had the choice, i'd personally stick to WiFi as it's well tested,
and keep the option to integrate WiMAX later, if it proves to be usable.
:)

> 
> Would it be best to have two radios in the mesh nodes?  If only one is
> needed, then perhaps I can put one WiMAX for the backhaul and one
> regular WiFi 802.11a/b/g and provide a WAP for the downlink sites.  Or
> simply save on the BoM by only using single radios.  Or maybe single
> radios would work for the nodes comfortably "meshed" with others, but
> dual-radios could be used in a directional repeater node specifically
> made to extend the mesh connectivity over distances?  Or do I have that
> backwards?  Maybe multiple radios would be better for the chatty
> meshed-up nodes versus the far-flung nodes making a chain back to the
> internet connectivity points at the periphery of a disaster area.  I am
> certainly open to any suggestions on other technologies to consider, too.

Multiple radios are always a good idea, e.g. having a backhaul in
802.11a (5ghz band) and AP in 802.11bg (2.4 Ghz). Minimizing
interferences is always a good idea, and you could replace one radio
later with a WiMAX radio, if you want to.

> 
> How well do BATMAN or other meshes scale?  What is the ideal density for
> nodes in the mesh, and how much better does it get with more node
> density before you have a diminishing return?

Depends very much on your setup. If you use many nodes in one area in
the same band, you'll probably have lot of interferences and packet loss. 
If you have lots of "direct connections", you have less flexibility but
probably less interferences, and better link quality. B.A.T.M.A.N. and
OLSR would scale up at least into a few hundreds participants afaik, so 
it's not a problem of the routing daemon.

> 
> How bad is the latency?  Is VoIP do-able?  Is it do-able for a few hops
> (like between field sites) but simply not do-able for longer trips out
> to the periphery of the mesh, where the internet connectivity is likely
> to be?

This also depends very much one the link quality. With lots of
interences, VoIP won't be fun with even in only 1 or 2 hops. In a
"clean" enviroment, this should work quite well.
As you probably know, WiFi retransmits packets on errors, so if you have
much noise, the latency will rise, and VoIP will probably become
unusuable. 

> 
> Is this even the right approach to this sort of connectivity problem?  I
> can see a mesh being useful for field-sites communicating with each
> other.  But often I have seen that the ideal with a mesh is to have the
> internet-connected nodes be in the center of the mesh whereas in this
> scenario, typically, the internet connection is only to be had at the
> periphery.  Would it be better to have a split role system where
> long-range internet connectivity is brought out over distance using some
> long-range repeater set-up, and the mesh spawned off from the end-point
> of this line? (Or multiple such lines)?

Mhm, you could build such long range extra lines, and having them on
another channel would be better for interference reasons. These long-range
lines could go into the middle of the mesh, and B.A.T.M.A.N. could take
control of both radios (the adhoc one the and the long-range one). Still,
all the Nodes would be B.A.T.M.A.N. nodes. The seperation would be just a 
physical, not a logical one.
> 
> How much does the actual routing of traffic tax the processor in a mesh
> node?  These boxes have 128Mb and can have a hard drive or SSD in them.
> They run a fairly complete Linux on them.  I am already imagining they
> can be managed via http with a web interface fairly easily.  But I am
> curious to find out how much more room I have to run other softwares.  I
> have thought of them having the ability to boot found/donated PCs over
> PXE and bootstrapping Linux on the computers, served by the mesh node
> (now a pxe/bootp server in addition to dhcp), to make quick and easy
> internet terminals/kiosks.

That's plenty. B.A.T.M.A.N. is designed to run on Linksys WRT machines, which
only have 8 to 32 Megs of RAM. It also does not have any dependencies
(except Linux and libc ;).
The stripped binary on my machine is 83kbyte. Space shouldn't be a
problem here.

> I would like to make the network as dead-simple to set up as possible.
> Emergency workers have enough to worry about without having to become
> network experts.  At most I would expect that they could connect a
> laptop to the Ethernet port and configure the devices with a web
> interface.  But ideally I would like there to be zero configuration
> on-site, if possible.  Plug and go, so long as you're in range.  Of
> course there would have to be some management console (probably web
> based) to get an idea of signal strengths, network performance, etc. for
> troubleshooting and fine tuning the network.

That's possible, just make sure that each machine has an individual IP.
(If you use batman-advanced, you don't even need IPs, but it helps ;)
Having a managment console would still be a good thing if you build up
long-shots [1]. You'll see that long distants can be covered with WiFi
too. Seeing the link qualities is always a good idea so you can plan
where you could set up more routers. We have a visualization server [2] for
this. It simply offers a graph in graphviz-format [3], which can also be
displayed with fancy 3D tools [4] as we did. ;)

Hope i could answer at least a few questions ...

Best Regards,
	Simon

[1] http://events.ccc.de/congress/2005/fahrplan/events/1078.en.html
[2] http://open-mesh.net/batman/vis
[3] http://graphviz.org/
[4] http://s3d.berlios.de/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2008-04-14 14:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-13  8:18 [B.A.T.M.A.N.] Suitability of B.A.T.M.A.N. protocol to my disaster relief network project Tim LePes
2008-04-14 14:52 ` Simon Wunderlich [this message]
2008-04-14 15:57   ` Sebastian Robitzsch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080414145207.GA7687@hrz.tu-chemnitz.de \
    --to=simon.wunderlich@s2003.tu-chemnitz.de \
    --cc=b.a.t.m.a.n@open-mesh.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox