public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
From: elektra <onelektra@gmx.net>
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.] Batman & multiple radios
Date: Tue, 10 Jun 2008 17:16:14 +0200	[thread overview]
Message-ID: <484E9ABE.8010808@gmx.net> (raw)
In-Reply-To: <1213107210.7872.15.camel@damian-x31.damian.org>

Hi -

B.A.T.M.A.N. supports multiple interfaces - so you may add more than one WiFi card to your systems and run batman on every interface that you like. Performance wise you should use different non-overlapping channels with different ESSIDs for your cards. You may use omnidirectional antennas, sectors or directionals. The latter two options will give you a planned infrastructure, where you have to do the channel planning (cellular infrastructure). There is no point in aiming directionals against each other while their interfaces work on different channels... You may still benefit from batman in such a planned network, because it will save you editing routing tables by hand.

If you use omnis (say two interface per device on channel 1 and 13) and the network is idle the routing may utilize just one channel. But as soon as there is traffic starting to saturate the links, the protocol should start using different channels. There is however no dedicated mechanism to coordinate the re-use of channels. Therefore Batman will need traffic in order to channel adaption. However this is AFAIK untested, and we'd love to hear about your results.

cu elektra




> I am seriously looking at using B.A.T.M.A.N. to drive a mesh network in
> a small town in Australia. One of the hassles with typical mesh networks
> is the way the performance drops off when you have many hops, due to the
> radio having to keep switching between send and receive. The standard
> way to get around this appears to be to use multiple radios.
>
> How is this done with batman? Is it a case of having multiple
> directional aerials - such that one radio can be receiving from one
> direction and another can be sending to the next node up the chain? It
> makes sense to put the local traffic (e.g. running a local AP) on a
> separate radio from the "back haul".
>
> Does anyone have any experience with sort of layout? The main driver
> here is performance rather than coverage.
>
> Damian 
>   


      parent reply	other threads:[~2008-06-10 15:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-10 14:13 [B.A.T.M.A.N.] Batman & multiple radios Damian Ivereigh
2008-06-10 14:34 ` Damian Ivereigh
2008-06-10 15:06   ` Benjamin Henrion
2008-06-10 15:16 ` elektra [this message]

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=484E9ABE.8010808@gmx.net \
    --to=onelektra@gmx.net \
    --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