<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Ruckus 802.11n beamforming - overcoming 2.4ghz co-channel interference ? in ZoneDirector</title>
    <link>https://community.ruckuswireless.com/t5/ZoneDirector/Ruckus-802-11n-beamforming-overcoming-2-4ghz-co-channel/m-p/35951#M6423</link>
    <description>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.</description>
    <pubDate>Thu, 17 Oct 2013 06:00:35 GMT</pubDate>
    <dc:creator>primoz_marinsek</dc:creator>
    <dc:date>2013-10-17T06:00:35Z</dc:date>
    <item>
      <title>Ruckus 802.11n beamforming - overcoming 2.4ghz co-channel interference ?</title>
      <link>https://community.ruckuswireless.com/t5/ZoneDirector/Ruckus-802-11n-beamforming-overcoming-2-4ghz-co-channel/m-p/35947#M6419</link>
      <description>How effective are Ruckus APs with using beam-forming to overcome co-channel interference ? 
&lt;BR /&gt;&lt;BR /&gt;
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.
&lt;BR /&gt;&lt;BR /&gt;
Does a Ruckus solution perform well in this situation (from client connection stability / throughput perspective ?) - for a 802.11g &amp;amp; 802.11n based client ?
&lt;BR /&gt;&lt;BR /&gt;
real world experiences welcome &lt;span class="lia-unicode-emoji" title=":slightly_smiling_face:"&gt;🙂&lt;/span&gt;</description>
      <pubDate>Wed, 16 Oct 2013 16:39:45 GMT</pubDate>
      <guid>https://community.ruckuswireless.com/t5/ZoneDirector/Ruckus-802-11n-beamforming-overcoming-2-4ghz-co-channel/m-p/35947#M6419</guid>
      <dc:creator>julian_fletcher</dc:creator>
      <dc:date>2013-10-16T16:39:45Z</dc:date>
    </item>
    <item>
      <title>Re: Ruckus 802.11n beamforming - overcoming 2.4ghz co-channel interference ?</title>
      <link>https://community.ruckuswireless.com/t5/ZoneDirector/Ruckus-802-11n-beamforming-overcoming-2-4ghz-co-channel/m-p/35948#M6420</link>
      <description>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?</description>
      <pubDate>Wed, 16 Oct 2013 20:05:25 GMT</pubDate>
      <guid>https://community.ruckuswireless.com/t5/ZoneDirector/Ruckus-802-11n-beamforming-overcoming-2-4ghz-co-channel/m-p/35948#M6420</guid>
      <dc:creator>keith_redfield</dc:creator>
      <dc:date>2013-10-16T20:05:25Z</dc:date>
    </item>
    <item>
      <title>Re: Ruckus 802.11n beamforming - overcoming 2.4ghz co-channel interference ?</title>
      <link>https://community.ruckuswireless.com/t5/ZoneDirector/Ruckus-802-11n-beamforming-overcoming-2-4ghz-co-channel/m-p/35949#M6421</link>
      <description>Thanks for the reply. &lt;BR /&gt;
The solution is based on ZD1025, running 8.2&lt;BR /&gt;
(20 APs across two levels of a school) &lt;BR /&gt;
The channels were selected by the ZD itself. &lt;BR /&gt;
I don't think channelfly is available in the solution deployed... &lt;BR /&gt;
I came across the issue whilst doing a quick airmagnet survey, and was confused by the &lt;BR /&gt;
channels chosen by the ZD.&lt;BR /&gt;
Any advice?</description>
      <pubDate>Wed, 16 Oct 2013 20:19:24 GMT</pubDate>
      <guid>https://community.ruckuswireless.com/t5/ZoneDirector/Ruckus-802-11n-beamforming-overcoming-2-4ghz-co-channel/m-p/35949#M6421</guid>
      <dc:creator>julian_fletcher</dc:creator>
      <dc:date>2013-10-16T20:19:24Z</dc:date>
    </item>
    <item>
      <title>Re: Ruckus 802.11n beamforming - overcoming 2.4ghz co-channel interference ?</title>
      <link>https://community.ruckuswireless.com/t5/ZoneDirector/Ruckus-802-11n-beamforming-overcoming-2-4ghz-co-channel/m-p/35950#M6422</link>
      <description>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. 
&lt;BR /&gt;&lt;BR /&gt;
If it's a lot of dirty/unstable air - upgrade (9.3 is max on that box) and utilize ChannelFly.</description>
      <pubDate>Wed, 16 Oct 2013 22:16:57 GMT</pubDate>
      <guid>https://community.ruckuswireless.com/t5/ZoneDirector/Ruckus-802-11n-beamforming-overcoming-2-4ghz-co-channel/m-p/35950#M6422</guid>
      <dc:creator>keith_redfield</dc:creator>
      <dc:date>2013-10-16T22:16:57Z</dc:date>
    </item>
    <item>
      <title>Re: Ruckus 802.11n beamforming - overcoming 2.4ghz co-channel interference ?</title>
      <link>https://community.ruckuswireless.com/t5/ZoneDirector/Ruckus-802-11n-beamforming-overcoming-2-4ghz-co-channel/m-p/35951#M6423</link>
      <description>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.</description>
      <pubDate>Thu, 17 Oct 2013 06:00:35 GMT</pubDate>
      <guid>https://community.ruckuswireless.com/t5/ZoneDirector/Ruckus-802-11n-beamforming-overcoming-2-4ghz-co-channel/m-p/35951#M6423</guid>
      <dc:creator>primoz_marinsek</dc:creator>
      <dc:date>2013-10-17T06:00:35Z</dc:date>
    </item>
  </channel>
</rss>

