<?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 Encourage clients to roam better in ZoneDirector</title>
    <link>https://community.ruckuswireless.com/t5/ZoneDirector/Encourage-clients-to-roam-better/m-p/17119#M3711</link>
    <description>The solution to the "client decides when to roam" problem:
&lt;BR /&gt;&lt;BR /&gt;
Tell the ZD that:
&lt;BR /&gt;
For all 2.4Ghz wifi clients whose AP sees them with less than 30db SNR:
&lt;BR /&gt;
kick them off of their current AP *if* they are seen by another AP with an SNR that is more than 10dB above their current SNR.
&lt;BR /&gt;
(the example values of 30dB and 10dB should be tunable and SNR data from APs should be averaged over a few samples)
&lt;BR /&gt;&lt;BR /&gt;
Also, if one AP attempts to band-steer a client to it's 5Ghz radio, the ZD should tell other APs to temporarily ban that client from associating on their 2.4Ghz radios.
&lt;BR /&gt;&lt;BR /&gt;
----------------
&lt;BR /&gt;&lt;BR /&gt;
Ruckus APs already have features that will:
&lt;BR /&gt;
Kick a client off an AP if the signal strength gets weak
&lt;BR /&gt;
(smartroam)
&lt;BR /&gt;
Limit the lowest data-rate a client can use 
&lt;BR /&gt;
(bss-minrate)
&lt;BR /&gt;
Steer a client to a 5Ghz radio by not responding with it's 2.4Ghz radio
&lt;BR /&gt;
(default band-steering behavior)
&lt;BR /&gt;&lt;BR /&gt;
These features are *configurable* from the ZD but they're *implemented* on the AP.
&lt;BR /&gt;
Aside from pushing configs to the APs, the ZD plays no active role in these features.
&lt;BR /&gt;&lt;BR /&gt;
The "Encouraging Clients" solution fills in gaps left by the existing features:
&lt;BR /&gt;&lt;BR /&gt;
smartroam kicks a "weak" client off but that decision is currently made by a single AP without regard to whether or not there's another AP available to provide a better connection.
&lt;BR /&gt;
Even if there *is* a better signal from another AP, the client *could* re-associate back to the original AP.
&lt;BR /&gt;&lt;BR /&gt;
bss-minrate could prevent a client from connecting to (or staying connected to) an AP at too-far of a distance.
&lt;BR /&gt;
Again, this currently happens without regard to whether or not there's another AP in a better position to provide service to that client.
&lt;BR /&gt;&lt;BR /&gt;
Band steering causes APs to not respond to clients with it's 2.4Ghz radio if the AP thinks the client could make a good connection to it's 5Ghz radio.
&lt;BR /&gt;
Unfortunately, some clients will associate with another distant 2.4Ghz radio instead of associating with the local 5Ghz radio.
&lt;BR /&gt;
In some cases, a client associated to a distant 2.4Ghz radio will continue to attemt to roam to a nearby 2.4Ghz radio but fail due to band-steering.
&lt;BR /&gt;
This can continue until the client gets "confused" and connectivity breaks entirely.
&lt;BR /&gt;&lt;BR /&gt;
These problems can be solved by having the controller take a more active role by implementing the "encouraging clients" solution.</description>
    <pubDate>Sat, 22 Mar 2014 01:12:21 GMT</pubDate>
    <dc:creator>bill_burns_6069</dc:creator>
    <dc:date>2014-03-22T01:12:21Z</dc:date>
    <item>
      <title>Encourage clients to roam better</title>
      <link>https://community.ruckuswireless.com/t5/ZoneDirector/Encourage-clients-to-roam-better/m-p/17119#M3711</link>
      <description>The solution to the "client decides when to roam" problem:
&lt;BR /&gt;&lt;BR /&gt;
Tell the ZD that:
&lt;BR /&gt;
For all 2.4Ghz wifi clients whose AP sees them with less than 30db SNR:
&lt;BR /&gt;
kick them off of their current AP *if* they are seen by another AP with an SNR that is more than 10dB above their current SNR.
&lt;BR /&gt;
(the example values of 30dB and 10dB should be tunable and SNR data from APs should be averaged over a few samples)
&lt;BR /&gt;&lt;BR /&gt;
Also, if one AP attempts to band-steer a client to it's 5Ghz radio, the ZD should tell other APs to temporarily ban that client from associating on their 2.4Ghz radios.
&lt;BR /&gt;&lt;BR /&gt;
----------------
&lt;BR /&gt;&lt;BR /&gt;
Ruckus APs already have features that will:
&lt;BR /&gt;
Kick a client off an AP if the signal strength gets weak
&lt;BR /&gt;
(smartroam)
&lt;BR /&gt;
Limit the lowest data-rate a client can use 
&lt;BR /&gt;
(bss-minrate)
&lt;BR /&gt;
Steer a client to a 5Ghz radio by not responding with it's 2.4Ghz radio
&lt;BR /&gt;
(default band-steering behavior)
&lt;BR /&gt;&lt;BR /&gt;
These features are *configurable* from the ZD but they're *implemented* on the AP.
&lt;BR /&gt;
Aside from pushing configs to the APs, the ZD plays no active role in these features.
&lt;BR /&gt;&lt;BR /&gt;
The "Encouraging Clients" solution fills in gaps left by the existing features:
&lt;BR /&gt;&lt;BR /&gt;
smartroam kicks a "weak" client off but that decision is currently made by a single AP without regard to whether or not there's another AP available to provide a better connection.
&lt;BR /&gt;
Even if there *is* a better signal from another AP, the client *could* re-associate back to the original AP.
&lt;BR /&gt;&lt;BR /&gt;
bss-minrate could prevent a client from connecting to (or staying connected to) an AP at too-far of a distance.
&lt;BR /&gt;
Again, this currently happens without regard to whether or not there's another AP in a better position to provide service to that client.
&lt;BR /&gt;&lt;BR /&gt;
Band steering causes APs to not respond to clients with it's 2.4Ghz radio if the AP thinks the client could make a good connection to it's 5Ghz radio.
&lt;BR /&gt;
Unfortunately, some clients will associate with another distant 2.4Ghz radio instead of associating with the local 5Ghz radio.
&lt;BR /&gt;
In some cases, a client associated to a distant 2.4Ghz radio will continue to attemt to roam to a nearby 2.4Ghz radio but fail due to band-steering.
&lt;BR /&gt;
This can continue until the client gets "confused" and connectivity breaks entirely.
&lt;BR /&gt;&lt;BR /&gt;
These problems can be solved by having the controller take a more active role by implementing the "encouraging clients" solution.</description>
      <pubDate>Sat, 22 Mar 2014 01:12:21 GMT</pubDate>
      <guid>https://community.ruckuswireless.com/t5/ZoneDirector/Encourage-clients-to-roam-better/m-p/17119#M3711</guid>
      <dc:creator>bill_burns_6069</dc:creator>
      <dc:date>2014-03-22T01:12:21Z</dc:date>
    </item>
  </channel>
</rss>

