Ruckus 802.11n beamforming - overcoming 2.4ghz co-channel interference ?

[julian_fletcher]

How effective are Ruckus APs with using beam-forming to overcome co-channel interference ?

A quick wireless survey at a client site (that uses Ruckus solution), revealed a number of rooms illuminated by two AP's but both on the same channel, with roughly equal signal strength. For classic 802.11g, this would be problematic.

Does a Ruckus solution perform well in this situation (from client connection stability / throughput perspective ?) - for a 802.11g & 802.11n based client ?

real world experiences welcome 🙂

[keith_redfield]

It should perform better than a conventional design without beamflex, but it's still likely not an optimal configuration. Is there a reason they are both on the same channel? Is ChannelFly configured?

[julian_fletcher]

Thanks for the reply.
The solution is based on ZD1025, running 8.2
(20 APs across two levels of a school)
The channels were selected by the ZD itself.
I don't think channelfly is available in the solution deployed...
I came across the issue whilst doing a quick airmagnet survey, and was confused by the
channels chosen by the ZD.
Any advice?

[keith_redfield]

It depends on the environment. If it's pretty clean, and stable - I would just manually change the channel on one of the AP's and then monitor for issues.

If it's a lot of dirty/unstable air - upgrade (9.3 is max on that box) and utilize ChannelFly.

[primoz_marinsek]

I'm quite the believer in auto-channel assignment. But I too have seen this problem sometimes. Don't think I've seen it on the newer FWs though.