* [B.A.T.M.A.N.] Suitability of B.A.T.M.A.N. protocol to my disaster relief network project
@ 2008-04-13 8:18 Tim LePes
2008-04-14 14:52 ` Simon Wunderlich
0 siblings, 1 reply; 3+ messages in thread
From: Tim LePes @ 2008-04-13 8:18 UTC (permalink / raw
To: b.a.t.m.a.n
Greetings!
If this list is the wrong place to be asking about this, please let me
apologize up front. :)
I am working on a project based around the Genesi EFIKA 5200B SoC
development board. You can find more details about the board by
visiting "http://www.genesi-usa.com/efika.php". The basic idea for my
project is that of an ad-hoc long-range wireless mesh network
infrastructure that can be easily set up by disaster relief workers.
The inspiration came from stories out of the hurricane Katrina disaster
in Louisiana and Alabama.
Please let me tell you about the project a little, and hopefully you may
be able to give me some advice - both general and specific to the
suitability of using the B.A.T.M.A.N. protocol. I understand that you
have far more experience with real-world applications of wireless mesh
networking than I, so any feedback will be greatly appreciated!
In the scenarios I imagine, a relief effort could quickly erect a series
of towers (telescoping poles?) with a wireless mesh node at the top, in
a weatherproof case. The mesh node can be powered by a generator or
whatever other means available. The purpose of the mesh is to provide a
network infrastructure out to areas that may have lost all traditional
connectivity and infrastructure. Generally, the idea is to bring
connectivity from one or more internet-connected points out to the areas
where you would have shelters set up, such as a Red Cross tent or other
similar congregation point for disaster victims. The mesh node would
connect them to each other (other sites in the field) and, ideally, back
to the internet. However in the event that it is not easy to get
internet connectivity to the mesh, it will still be useful for sites in
the field to communicate and coordinate with each other.
At the shelter, then, would be a mesh node up on a pole. The device
would act as a gateway, offering network connectivity to anything
attached to it's 10/100 ethernet port. It would be a DHCP server and
could provide connectivity to one or more computers (with the help of a
hub). The computer(s) would be used to access web-based services for
things such as logistics, people-finding service, access to government
and/or NGO relief agency web sites and services, etc.
There is another project I found that I hope to tie into my project, and
that is SAHANA. From their web site, "Sahana is a Free and Open Source
Disaster Management system. It is a web based collaboration tool that
addresses the common coordination problems during a disaster from
finding missing people, managing aid, managing volunteers, tracking
camps effectively between Government groups, the civil society (NGOs)
and the victims themselves." Their web site is "http://www.sahana.lk/".
The main consideration is that it be as easy as possible for emergency
response and other disaster relief workers to physically set up this
network. So my hope is that the network can be largely
self-configuring, self-monitoring, and self-healing. Thus an ad-hoc
mesh design. I would imagine that in some situations, the network would
be a simple mesh cloud connecting people on the ground to each other.
In other situations, and ideally, connectivity to the internet would be
established through one or more nodes in the mesh. I could see that
sometimes certain nodes may not really play the role of a mesh node so
much as a repeater, to get the connectivity strung out over some distance.
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.
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.
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?
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?
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)?
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.
Other possibilities include running squid caches on the nodes to reduce
back-haul traffic when many folks are visiting the same sites, or even
having them optionally be able to block traffic based on either white or
black lists, and since the SoC boards have audio in/out, they could be
used as a VoIP phone over the network. Besides having a data network
for email and web access, simply being able to simply talk to each other
between sites using the device could be very valuable. Especially when
traditional communications such as cell phone and land-line networks are
down. And being built into the mesh node, there would be at least voice
communications available immediately that way, even before other devices
are networked to the mesh nodes. There is a serial port, so keypads are
a possibility.
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.
Well anyway I have several ideas running around for this project,
including other devices that would network in and serve different
roles. But it all depends on the feasibility of constructing a wireless
networking infrastructure. I don't want to take up too much of your
time rambling on, so as I said, any feedback is welcome. As are any
questions you may have.
Genesi have been gracious enough to give me the development board for my
project, so I am anxious to make some headway.
Thanks so much!
Tim LePes (a.k.a. Mojo)
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [B.A.T.M.A.N.] Suitability of B.A.T.M.A.N. protocol to my disaster relief network project
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
2008-04-14 15:57 ` Sebastian Robitzsch
0 siblings, 1 reply; 3+ messages in thread
From: Simon Wunderlich @ 2008-04-14 14:52 UTC (permalink / raw
To: The list for a Better Approach To Mobile Ad-hoc Networking
[-- 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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [B.A.T.M.A.N.] Suitability of B.A.T.M.A.N. protocol to my disaster relief network project
2008-04-14 14:52 ` Simon Wunderlich
@ 2008-04-14 15:57 ` Sebastian Robitzsch
0 siblings, 0 replies; 3+ messages in thread
From: Sebastian Robitzsch @ 2008-04-14 15:57 UTC (permalink / raw
To: The list for a Better Approach To Mobile Ad-hoc Networking
[-- Attachment #1.1: Type: text/plain, Size: 8601 bytes --]
Hey guys,
I'm reading this mailing list since BATMAN is a potential approach for
a project of mine (which envisages an emergency scenario as well).
Anyway ... Tim - As far as I've understood you try to build a Mesh with
a WiMAX backhaul that consists of WiFi based APs ... right?
I propose BATMAN focuses on _mobile_ ad-hoc networks and WiMAX is still
more a carrier grade technology (see the minor comment within this
mail). From this it follows the question whether BATMAN is really a good
choice for creating a Mesh network based on WiMAX backhaul AND WiFi
APs... it's my point of view ;) ...
Nevertheless, BATMAN could be a feasible routing algorithm that has to
be extended.
some more comments inline ...
Rgds,
Sebastian
Simon Wunderlich wrote:
> 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.
just a minor comment on this: the 802.16j standard is released as a
draft (version3 - I think). This provides a Mesh network based on WiMAX.
But it is still a draft standard and has not been implemented (driver),
yet.
> 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.
IMO, if you think about an emergency scenario where the actual
infrastructure is down, you can assume around 5ms latency per WiFi node
if you care about radio management and channel selection. For WiMAX you
can assume around 15 ms per node (depends on the QoS profile).
>
>> 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/
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@open-mesh.net
> https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
[-- Attachment #1.2: sebastian_robitzsch.vcf --]
[-- Type: text/x-vcard, Size: 550 bytes --]
begin:vcard
fn:Sebastian Robitzsch
n:Robitzsch;Sebastian
org:Fraunhofer Gesellschaft;FOKUS.NETwork research
adr;dom:;;Schloss Birlinghoven;Sankt Augustin;;53754
email;internet:sebastian.robitzsch@fokus.fraunhofer.de
title:Dipl.-Ing.(FH)
tel;work:+49 (0)22 41 - 14 2785
tel;fax:+49 (0)22 41 - 14 4 2785
tel;cell:+49 (0)1 72 - 3 52 80 72
note;quoted-printable:Skype: seronline82=0D=0A=
Jabber: seronline@amessage.info=0D=0A=
=0D=0A=
www.seronline.de
x-mozilla-html:FALSE
url:www.fokus.fraunhofer.de/go/net/
version:2.1
end:vcard
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2008-04-14 15:57 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2008-04-14 15:57 ` Sebastian Robitzsch
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.