[Olsr-users] Channel Selection for Multi Radio OLSR
Benjamin Henrion
(spam-protected)
Tue Aug 12 10:37:13 CEST 2008
On Tue, Aug 12, 2008 at 5:47 AM, David Murray
<(spam-protected)> wrote:
> Hi,
>
> With the recent discussion about multiple radios and OLSR I would like
> to put my recent university project out there. TDCS: Table Driven
> Channel Selection is a Channel selection mechanism for multi radio OLSR.
>
> It works by using the drivers scan cache to make initial decisions
> about channel selection and then uses the OLSR routing table to
> stabilize these assignments. I am over simplifying but if an interface
> is currently being used for routing by OLSR, the channel assignment is
> considered stable. If the route is removed and the interface is no
> longer providing a usable route then the interface is reassigned to a
> different channel.
>
> There are also mechanisms to prevent too many nodes from converging on
> the same channel and ways to prevent co located radios from using close
> frequencies (inter radio interference). The other major problem that a
> lot of these schemes encounter is how to ensure that the backbone does
> not form radio islands that are disconnected. TDCS deals with this by
> ensuing that all nodes have connectivity to a single gateway node.
>
> TDCS is written in Ruby and can be found at [1]. If anyone wants to try
> it out I would be very interested in hearing some feedback. The draft
> chapter of my PhD thesis can be found here [2]. Apologies about the
> length. I have a much more concise paper but it has not been published
> yet so email me if you would like an advanced copy.
>
> I have tested TDCS using 8 dual radio ALIX nodes with Atheros CM9's.
> the results I was able to get are reasonably promising (see the
> chapter). Constructive criticism is always welcome. Also, if anyone
> thinks TDCS is a good idea and wants to help, they are more than
> welcome.
I was thinking to have one of the 2 atheros radios in VAP mode, one
VAP in ad-hoc and one VAP in monitor mode, in order to collect data
about the environement, and then the host sends proposals for channel
switching at a precise time (routers needs to change the channel in
sync) to other nodes via OLSR UDP packets (using the OLSR extensions
mechanism).
But at the end of the day, it would be easier to rewrite the MAC layer
to do similar hopping as Bluetooth does, as most cards are softmac
now.
--
Benjamin Henrion <bhenrion at ffii.org>
FFII Brussels - +32-484-566109 - +32-2-4148403
More information about the Olsr-users
mailing list