In some buildings- particularly precast concrete apartments- on our campus, the loss on 5 GHz signal can be pronounced versus 2.4. Like to the point where 5 is non-existent and 2.4 will support almost full data rate. But this effect varies wildly across our other building types.
Here is one of my favorite studies on 2.4 GHz versus 5 GHz losses through various building materials: http://www.am1.us/Papers/E10589%20Propagation%20Losses%202%20and%205GHz.pdf It is interesting to note that as thoroughly done as it is, the authors still stress the wide variability of performance as different materials are combined in different settings. -Lee Badman ________________________________________ From: The EDUCAUSE Wireless Issues Constituent Group Listserv [wireless-...@listserv.educause.edu] On Behalf Of Chuck Enfield [chu...@psu.edu] Sent: Monday, August 16, 2010 6:18 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Band Steering? I'd like to suggest that band-steering isn't causing this problem, it's just making it more apparent. Presumably, we all want 802.11n clients on 5GHz because performance and capacity are greater in that band. The use of band-steering suggests agreement on this point. In that case, it seems fair to say the root cause of the problem is having coverage gaps in the preferred band. In my experience with dual-radio networks, in locations where the 5GHz signal is unusable the 2.4GHz SNR will probably be 8dBm or less and SIR is likely to be even worse. In other words, where's there's no 5GHz there will only be poor 2.4GHz. If 5GHz is where we want to play on 802.11n, then that's the band for which we should be designing our coverage. If Aruba were to adjust their implementation, (and from the discussion it seems like they should) you would likely get fewer complaints of no connection, but you'll have even more clients with a poor connection. It may be better, but it's not exactly fixed. In the long run, filling in the 5GHz coverage gaps seems like the only real solution. Now that I've alienated you, let me make a feeble attempt to be helpful. I'm going to spell out my thinking because I don't know the answer. Instead, I'll suggest what may be a different way of looking at the problem. It seems like any good band-steering implementation should know what clients are 5GHz enabled and when they are within range of a 5GHz radio. Assuming Aruba collects that info, it would be stored in a table somewhere and updated at some interval. The problem could be caused by the controller taking too long to learn that the client is out of 5GHz range. Shortening the refresh interval could improve the situation. Unfortunately, I don't know which interval to shorten, or if the necessary interval can be shortened enough to stop this problem without causing a different problem, such as choking the bandwidth or overburdening the processor. I don't have much experience with the Aruba Controllers, but you might investigate the AM Poll Interval or the ARM Scan Interval. Maybe you can think of others. It's probably not realistic to reduce the scan interval much below 10 seconds, but depending on the network conditions it may be reasonable to reduce the AM Poll Interval way below the 1 minute default. Of course, even if you find the right variable and can reduce it sufficiently, you won't be rid of the problem. The best you can hope for is that it will be brief enough that few clients will notice. Chuck Enfield Sr. Communications Engineer Telecommunications & Network Services The Pennsylvania State University 110H, USB2, UP, PA 16802 ph: 814.863.8715 fx: 814.865-3988 -----Original Message----- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Ethan Sommer Sent: Monday, August 16, 2010 2:30 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Band Steering? FWIW: After upgrading to 5.0.2 from 5.0.0, things fall back to 2.4ghz much better than they used to. I think we still need to do some tweeking to get things working as well as we'd like. Unfortunately, we don't have the kind of budget to just throw out more APs to fix the problem, so that's not really an answer for us. I have to say, I've been really disappointed by Aruba tech support's answer to this sort of thing. 1. The documentation for 5.0.x says to turn on "Local probe response" but that doesn't seem to exist anymore in 5.0, but did in 3.x. 2. In two separate tech support tickets, with two separate tech support people, I was told that "that was just the way the system worked, people couldn't fail back to 2.4ghz." That's A) false, and B) not even what the user manual says. 3. They clearly didn't know that there was (apparently) a bug in 5.0.0 that was fixed by 5.0.2 which allowed clients to fail back more. Ethan On 08/16/2010 06:36 AM, Osborne, Bruce W. (NS) wrote: > Here is a response I received from Aruba Engineering: > > Bruce, > > I have heard this from some of my other customers as well. The basic issue comes down to the physical properties of the 5GHz wave vs. the 2.4GHz. The lower frequency (2.4) will be able to travel through air and walls and even "bend" around corners better than the higher frequency 5GHz wave. For this reason at the edge of an AP's coverage area the 2.4 signal will be better quality than the 5GHz. With band-steering enabled we will keep the client on the 5GHz radio despite a better performing 2.4 signal being available. > > I would prefer to keep band steering enabled and design the RF coverage based on the 5GHz coverage. > > You can add an AP 105 and set the b/g radio as a full time air monitor or you can consider a single radio AP (the AP-93) to provide 5GHz coverage only to these areas where the 2.4GHz can reach but the 5GHz does not. > > Thank you, > > > Bruce Osborne > Liberty University > > -----Original Message----- > From: Ethan Sommer [mailto:somm...@gac.edu] > Sent: Wednesday, August 11, 2010 3:30 PM > Subject: Band Steering? > > We are upgrading part of our network using Aruba AP-105s and a pair of > 3600 controllers. > > We've found an annoying problem when we have band steering turned on. > > We've create two SSIDs. Lets call them BandSteering and NoBandSteering. > When users are relatively close to an access point, they can connect to either. My MacBook will usually connect using 2.4 Ghz on NoBandSteering and will always connect using 5ghz to BandSteering. When a user is further away from the access point, however, they can connect fine to NoBandSteering (obviously it is slower than when they were closer) but can't connect at all to the BandSteering SSID. It doesn't fail back to 2.4ghz, and the clients don't recognize that they can't connect and connect to NoBandSteering if that's lower in their preferred networks list. > > The effect is that, understandably, users will select the NoBandSteering SSID because it is more reliable. (Even though it is slower in most cases.) > > Aruba suggested that I try setting the 5ghz ARM profile to always max out the 5ghz radio, which helps some but does not eliminate the areas where 2.4ghz works and 5ghz doesn't. > > So, my questions are: > 1. Are people using band steering? > 2. Have you found the same problem? > 3. Is there a way to fix it? (Other than turning off bandsteering.) > > > 4. I suppose a related question is, is there a way to make client computers prefer 5ghz more? > > I guess we'll probably just not use band steering if we can't find a solution, but it would be a shame not to better utilize the 5ghz spectrum better. > > Thanks for any suggestions! > > Ethan > > -- > Ethan Sommer > Associate Director of Core Services > Gustavus Technology Services > somm...@gustavus.edu > 507-933-7042 > > ********** > Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. > > ********** > Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. > -- Ethan Sommer Associate Director of Core Services Gustavus Technology Services somm...@gustavus.edu 507-933-7042 ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
