The previous link to metageek that I recently sent should explain it all, and with pictures. But I still recommend going coordinating with your neighbors so you are all on the same page and working together to have the least complications between you both - instead of *fighting a secret war*. You can agree to use 1 or 11 at your shared boarders to completely minimize issues.
When you are dealing with multiple APs (either your own or neighbors) a site survey is a given to minimize the issues you face. I dunno how comprehensive you really need to get though. Imho its best not to overcomplicate until/unless you are troubleshooting real issues. For a survey, I typically do spot-checks with my iPhone (with a proper wifi strength survey app) and just make notes on a floorplan as I go. Its a lot faster that way. I will do something more robust if things do not work as expected. Getting back to terminologies - IIRC, back in the day these were referred to as: Single Channel Architecture (SCA) for single protocol channel, Multiple Channel Architecture (MCA) for multiple protocol channel (typically ala 1-6-11), and Channel-Stacking/Channel-Spanning/Channel-Blankets for channel stacking. -- Espi On Tue, Nov 5, 2013 at 4:47 PM, Kurt Buff <[email protected]> wrote: > Ah - let me rephrase to see if I understand you correctly. > > Keep all of our WAPs on the same frequency/band, but vary radio power > so that there isn't overlap between them. > > Does that sound correct? > > That would seem to make a comprehensive site survey pretty much mandatory. > > Kurt > > On Mon, Nov 4, 2013 at 8:19 PM, Micheal Espinola Jr > <[email protected]> wrote: > > 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 > >> >> > >> >> > >> > >> > > > > >
