By stacking, I mean using the *same* channel (co-channeling) with the same SSID - with adequate signal dBm buffering in-between (preferably at least 30 dBm) - just as you would when avoiding other wifi overlapping networks - but now you are doing it to your own APs. You can still achieve excellent bandwidth with proper stacking.
I think Meru refers to this methodology within their technology architecture as "layering". I've always called it stacking - but that might be *old-school *- I dunno. I think some people also call it *channel blanketing*. Or, maybe I'm just in my own world on this one. You usually see protocol channel-stacking/blanketing/whatever in AP dense environments, like hotels, where the logistics of 1-6-11 are difficult to map in a 3-dimensional space - so you stack areas all on the same channel - giving an appropriate distance or power tweak in order to balance the dBm buffer between them. instead of 1-6-11 per AP, you do it per stacked area, with the same 1-6-11 methodology used in an area-wide scale. 1-6-11 per AP is of much easier, as so much of possible interference issues have no effect and don't matter. But, channel stacking can work perfectly fine too when implemented properly. HTH and doesn't sound too ridiculous. -- Espi On Mon, Nov 4, 2013 at 7:46 PM, Kurt Buff <[email protected]> wrote: > I presume by channel stacking you mean selecting channels for our WAPs > that have least overlap with the closest of their WAPs - say, if > they're doing 11, make sure that the closest ones we have are either 6 > or 1, etc. > > Am I understanding you correctly? > > Kurt > > On Mon, Nov 4, 2013 at 7:11 PM, Jon Harris <[email protected]> wrote: > > If you have dual band Wi-Fi's on the systems and if the Cisco units > support > > it you might want to try switching to A instead of using B, G or N. I > know > > a lot of if's but it should help and your neighbors would most likely not > > even see your signal (A band anyway). Other than that go with Micheal's > > suggestion start the conversation with the building owner and get them > > involved before you go to the neighbors. > > > > Jon > > > >> Date: Mon, 4 Nov 2013 18:05:32 -0800 > >> Subject: [NTSysADM] wifi in multitenant buildings? > >> From: [email protected] > >> To: [email protected] > > > >> > >> All, > >> > >> I can't remember if I've asked this before - it's certainly been on my > >> mind a bit lately. > >> > >> Until recently, we've been the main tenant in a medium-sized three > >> story building, taking up most of the first floor, and all of the > >> second floor, with a tenant occupying the north half of the third > >> floor. (it's about 190,000sqft, of which we occupy around > >> 100,000sqft). > >> > >> Now there are new tenants on the 1st floor, and the tenant on the > >> third floor has expanded to both sides of the building, and they've > >> each mounted their own wifi infrastructure - very understandable. > >> > >> However, the tenant on the 3rd floor seems to have completely revamped > >> their infrastructure (they used to use Cisco) and have turned up the > >> power quite a bit on their new Meraki units, and I'm starting get > >> reports of our staff having a hard time connecting to our WAPs. > >> > >> We have 17 Cisco units (15x1240AG, and two newer units - I can't > >> remember which model off the top of my head). > >> > >> It looks as if the 3rd floor tenant has a minimum of 9 Meraki units on > >> the South side of the building - I haven't yet surveyed the North > >> side. > >> > >> I'm looking online for strategies for managing wireless in this kind > >> of environment, and not seeing much - probably using the wrong search > >> terms. > >> > >> Aside from working with the landlord (which I plan on doing once I > >> have a bit more understanding under my belt), what strategies > >> (technical and business) have you seen employed to make such an > >> environment "livable"? > >> > >> I'm pretty sure that simply turning up the power on our WAPs isn't > >> going to be a winning strategy - it's probably just start a wifi war, > >> and I'd prefer to avoid that. > >> > >> Kurt > >> > >> > > >
