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

[Rajesh Narayanan]

tim,

maybe i sounded rude in my previous post so I apologise, and maybe I dont
know as much as you either. My only argument against your point is that you
cannot discount a technology just because it has technical issues that
cannot be overcome and made viable.

I say it again, MCMR is not a silver bullet. But any limitations are to be
studied and maybe based on our experiences someone may come in to make the
inherent system better by reducing bleed-overs and attenuation or whatever
the true nature of the problem is.

rgds,
rajesh



On 1/30/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)://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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20070131/413e7a02/attachment.html>