[OLSR-users] Multi-Radio Multi-Channel support in OLSR???
Benjamin Henrion
(spam-protected)
Wed Jan 31 10:26:14 CET 2007
Radio seperation is of course important, but for testing purposes,
using 2 non overlaping channels in 802.11b is a good start, while
using b and a is preferable.
Furthermore, you can use different polarization to make the separation better.
On 1/31/07, Tim Martin <(spam-protected)> wrote:
>
> Maybe there's a multitude of mesh networking vendors who tout multi-channel
> multi radio because they rely on selling to people who know as little about
> it as you. If you have two or more radios broadcasting from the same
> location at close frequencies there is going to be a lot of bleedover or at
> least a lot of attenuation making the radios far less efficient. You can
> have one radio in the 11b/g range and one in the 11a range but having two in
> the same frequency range is a waste of time and money.
>
> Thanks,
> Tim
>
>
> Rajesh Narayanan wrote:
> no offense, but try explaining that to the multitude of mesh networking
> vendors that tout multi-channel multi-radio :-). They work and they work
> well! So I dont agree with your assessment as its too simple.
>
> You are right about bleedover. There is definitely some cross channel
> interference that has been studied. But I dont think it justifies not
> looking at multi-radio multi-channel systems. 802.11b/g has only 3
> non-interfering channels, while 802.11a has 11 (I think). So the channel
> distribution you are talking about is when there are interfering channels.
> These are the issues that an intelligent channel allocation scheme will need
> to take care of.
>
> Thanks,
> Rajesh.
>
>
>
> On 1/30/07, Tim Martin <(spam-protected)> wrote:
> >
> > I prefer to use just one radio because multiple radio's will interfere
> with each other if placed close together. Even if one is on channel 1 and
> the other on channel 11 there can be some bleedover which will cause a lot
> of lost packets.
> >
> > Tim
> >
> >
> > Rajesh Narayanan wrote:
> >
> > Hi,
> >
> > I posted this in the openwrt forum as well. Thought I might as well stir
> the hornets nest a little more. Only the OLSR part is specifically relevant
> . Has anyone looked at multi-radio multi-channel support in the OLSR
> though???
> >
> > I'm trying to look at any open-source implementations for MCMR. If I do
> find I'll post it here.
> >
> > Thanks,
> > Rajesh.
> >
> > Here is the post
> > ***************************
> > It just occured to me that there might be a possible for supporting
> multi-radio multi-channel support in the OpenWRT platform. Many
> mesh-networking companies typically tout multi-radio/multi-channel support.
> >
> > Here is a possible method by which three Linksys routers can be combined
> to support multi-radio multi-channel.
> >
> > Methodology:
> > 1. Hardware
> > - Put the three linksys (could be any other device) routers in Bridge
> mode.
> > - The three routers are physically connected via the ethernet LAN
> ports
> > - Lets call these routers LS1, LS2 and LS3.
> > - I have tested the bridge-mode connection and works quite well
> > - Essentially provides a very wide Layer2 connection
> > - These three linksys routers can be stacked on top of each other
> essentially providing 3 radios (you could use 2 for 2 radios)
> > - This will how a Node-group will look like
> > \ / <-- Radio1
> > Node1a
> > | <----------- Wired link
> > \ | / <-- Radio2
> > Node1b
> > | <----------- Wired link
> > \ | / <-- Radio3
> > Node1c
> >
> > 2. Software
> > - This is the secret-sauce that needs to be developed. The goal is:
> > - Launch it in each of the routers LS1, LS2, LS3
> > - Communicate among each other to know they are part of the same
> bridge
> > - Have a channel allocation scheme for each router so they do not
> mutually interfere with each other.
> > - This needs to be a modular and scalable architecture so that nodes
> can be added to the stack in an on-demand basis.
> > - The secret sauce could be developed either as a plugin for OLSR or
> for the spanning-tree-protocol implementation.
> > - The STP implementation would mean that its one big layer-2 wireless
> network with the node-groups forming some kind of non-loop network
> > - OLSR-plugin would obviously mean that all node-groups act as
> olsr-routers with intelligent channel assignment schemes.
> >
> > 3. References:
> > * While writing this post I did some web-search and looks like there is
> already some activity that is similar to what I am suggesting -
> http://moment.cs.ucsb.edu/tic/
> > * (more references later) ________________________________
>
> > _______________________________________________
> olsr-users mailing list (spam-protected)
> > https://www.olsr.org/mailman/listinfo/olsr-users
> >
> > -- Stop Spam Now:
> > http://www.spamarrest.com/affl?4025320
> >
> > _______________________________________________
> > olsr-users mailing list
> > (spam-protected)
> > https://www.olsr.org/mailman/listinfo/olsr-users
> >
> >
> >
>
> ________________________________
>
> _______________________________________________
> olsr-users mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-users
>
>
> --
>
> Stop Spam Now: http://www.spamarrest.com/affl?4025320
>
>
> _______________________________________________
> olsr-users mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-users
>
>
>
--
Benjamin Henrion <bhenrion at ffii.org>
FFII Brussels - +32-484-566109 - +32-2-4148403
More information about the Olsr-users
mailing list