public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: The list for a Better Approach To Mobile Ad-hoc Networking
	<b.a.t.m.a.n@lists.open-mesh.org>
Subject: Re: [B.A.T.M.A.N.] OGM overhead and routing metric proposal
Date: Mon, 28 Feb 2011 15:48:20 +0100	[thread overview]
Message-ID: <20110228144820.GH4698@lunn.ch> (raw)
In-Reply-To: <AANLkTikdyLe01RSdet=Y1bZgjnCAUCcbdvJdXyUDSVw=@mail.gmail.com>

> I'm not a kernel guru but i find out that the new core mac80211 and
> cfg80211 (http://linuxwireless.org/) offers the possibility to obtain
> a per-station bit-rate information that should be driver independent.

O.K. I will take a look at this.

> I have not mentioned the hidden node problem. But I think this problem
> is very difficult to remove, the only best practice to reduce the
> problem is to force the RTS/CTS mechanism to be active.

RTS/CTS helps, true. But it has a few problems. e.g. most meshing
protocols use broadcast packets for there management. e.g. BATMANs
OGMs are broadcast. These cannot be protected with RTS/CTS. So the
OGMs can collide with RTS packets from a hidden node, or OGMs from a
hidden node.

Another way to help reduce the hidden node problem, or interference
with other nodes, is to use a low coding rate and transmit power when
possible. So for example when we don't have much traffic to send to
node X, it could send the packets with the lowest coding rate and low
power. This keeps the interference with other nodes to a minimum. As
the amount of data for X increases, the coding rate and transmit power
can be increased, so increasing the available bandwidth to X, but at
the same time increasing the amount of interference the traffic
produces.

Such a scheme to minimize interference does not play too well with
your idea of putting the coding rate into the OGMs. We would have to
ensure that the coding rate is the highest possible coding rate usable
between two peers, not the currently used coding rate, which could be
low in order to avoid interference.

> > Will you be at the WBMv4 next Month?
> >
> I'm afraid but I cannot be at WMBv4, I hope I can come to the next
> WBM, maybe with a working implementation :)

Shame, i plan to talk more about the hidden node problem during WBMv4.
It is also a good place to discuss new ideas like adding information
into the OGMs.

     Andrew

  reply	other threads:[~2011-02-28 14:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-28 11:50 [B.A.T.M.A.N.] OGM overhead and routing metric proposal Daniele Furlan
2011-02-28 12:37 ` Andrew Lunn
2011-02-28 13:07   ` Daniele Furlan
2011-02-28 14:48     ` Andrew Lunn [this message]
2011-02-28 16:00       ` Daniele Furlan
2011-03-01  8:51         ` Linus Lüssing
2011-03-01  9:13           ` Andrew Lunn
2011-03-01  9:42             ` Daniele Furlan

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=20110228144820.GH4698@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    /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