[OLSR-users] Multi-Radio Multi-Channel support in OLSR???

[Benjamin Henrion]

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