Wireless Access

We have wireless carts with identical new Tangent PC's running Windows 7 in a hospital environment utilizing Paragon ECW software.

The drivers are up to date and configured for n with Agressive Roaming.

I have enabled Local Probe Request Threshold at 20db in the SSID profile.

They have been roaming from AP to AP with mixed results. I have seen clients roam whenever they pass under an AP and and clients that do not roam.

Today a client was associated with an AP(OB-e407) and moved down the aisle away from and right underneath another AP(e324-OB). Using the "show ap debug client-table ap-name apname"  command to monitor Thruput I could see the tx and rx rates decrease and the Last_Rx_SNR decrease. The client did not roam to e324-OB as I passed it, and when I wheeled the cart into a room it ultimately disconnected from the network.

Do I need to tweak Local Probe Request Threshold?
What other steps can be taken?
I have attached the debug output from right before the disconnect. The client's mac is 00:26:c6:30:fa:68.

How exactly does the Local Probe Request Threshold work?

This has to be a common problem and there has got to be a solution.

TIA

Attachment(s)

show ap debug client-table ap-name OB output.docx   20 KB 1 version

My advice would be to ONLY change the client drivers, OR the local probe threshold response, NOT both.  Let's try keeping the client driver at normal roaming.  Increase the local probe threshold to 30. and try that.  20 is not considered very aggressive, at all, in such a dense environment.

The local probe threshold parameter is not supposed to force clients to roam as soon as they pass near an access point with a good signal, but to NOT hold on to an access point with a weak signal.

Originally the Tangents had older drivers, set with the default Intel wireless parameters,  and would not roam at all.

 When the Carts were mobile they would associate with an AP and become Sticky.

They would disconnect when out of range.

I will try the updated clients again, with the local probe threshold configured for 30, with the Intel recommended default settings.

Thanks for your help!

Sounds like you are on the right track Bill.

BTW, a local probe response threshold of 20 is not that 'aggressive'... your '30' value is getting more to the ballpark to get clients to 'stay, well, local' ;)

I once turned up the setting to 40 to fit a specific (connect to the AP in the room only) type of application...worked well.

Hi,

Not sure what you mean by "get clients to 'stay, well, local'"?

Thanks.

Sorry if I'm about to sound ignorant, but wouldn't you want your client associations to be at best-range with the closest AP at all times? I don't see any advantage to keeping a client on an AP when there's another AP closer to the supplicant. When wouldn't you want to do this? The only thing I can think of would be if you wanted to balance between more than one AP in the same room, but then even still, I can't see any advantage.

I've got this very situation happening at all of my locations, and I'm going to illicit some change requests to get Min Tx EIRP turned up from 3 to 9 (no idea why it was set so low in the first place), and set the Local Probe Threshold Request value to 30 and do some testing on that; I'm tired of looking at big, blue lines in AirWave that traverse the entire distance of my floor plans, and I think this should fix it.

If anyone is interested, I'll post back what I find out.

---

@webcore wrote:

Sorry if I'm about to sound ignorant, but wouldn't you want your client associations to be at best-range with the closest AP at all times? I don't see any advantage to keeping a client on an AP when there's another AP closer to the supplicant. When wouldn't you want to do this? The only thing I can think of would be if you wanted to balance between more than one AP in the same room, but then even still, I can't see any advantage.

 

I've got this very situation happening at all of my locations, and I'm going to illicit some change requests to get Min Tx EIRP turned up from 3 to 9 (no idea why it was set so low in the first place), and set the Local Probe Threshold Request value to 30 and do some testing on that; I'm tired of looking at big, blue lines in AirWave that traverse the entire distance of my floor plans, and I think this should fix it.

 

If anyone is interested, I'll post back what I find out.

---

Webcore,

This thread is more than a year old, but let me update it with principles that everyone can use:

- It is desirable to have  a client on the closest access point for the best performance - TRUE, but it is only one factor that determines performance.  If there are more clients on the closer access point or more legacy clients on the closer access point, it *could* lead to worse performance for that client to be on the closer access point.  If there is also more bandwidth consumption on the closer access point, that could also lead to worse performance.  ClientMatch in the upcoming ArubaOS will address these issues in a more comprehensive fashion.  The client ultimately makes the decision at the end of the day.  Having clients on the closest access point is desirable, but is not the the only factor that determines performance, is my point.

- If you have the Min TX at 3 and all your access points are at 3, that could mean that you have too much coverage on that band.  You do not want the TX power of the access points to be lower than the clients.  If you find your access points at 3, you might want to remove coverage (turn some radios on that band into air monitors) so that access points can increase power to match client output (12 is good).

- The big blue lines in airwave are separate and have to do with accurate placement of access points and how many access points can actually hear those clients to be able to draw an accurate location (3 or more is required for decent accuracy).  I will let rgin comment on that.

- If you decide to use local-probe-threshold parameter, make sure you use the "hide ssid" parameter in the Advanced portion of the SSID profile so that clients cannot discover access points via their beacons.  This configuration will of course NOT work on SSIDs where it needs to remain visible.  The local-probe-threshold parameter should be used if you have extreme cases where clients hang on to access points very far away.  Remember that the stronger signal from your access points can also be coming from the floor above and below; your clients can't tell the difference.

Again, this is general advice and more information about your setup might dictate you make other changes.

Yea sorry, I realize that this is a very old thread and originally was intending on making a joke referencing that, so I'll do that now ... *puts away shovel*, but on a serious note, I'm almost on the same wavelength as you except for the local probe parameter; I had fully intended to use this to get users to associate with more proximally desirable APs, but now I can't do that because of the Hidden SSID parameter, which MUST be visible (as well as the other SSIDS) that are being broadcast.

Also, regarding Tx EIRP value of 12, since mine was hardset to 3 couldn't I simply change it to 12 and call it a day? I'll have to research what you said about turning the radios on a band to air-monitors since the deployment was really curtailed towards coverage and not density (something that wasn't covered in my ACMA or ACMP classes). I believe I might be confusing air monitors with spectrum analyzers and, considering I only have 4 135s in deployment, I can't really afford to take any out of the AP function, so please tell me that I'm confusing spectrum analyzing with air monitoring. :)

Anything else I should be aware of? I'd like to post an example floor-plan based off of what I'm seeing in AirWave if you'd like to take a gander at it ...

---

@webcore wrote:

Yea sorry, I realize that this is a very old thread and originally was intending on making a joke referencing that, so I'll do that now ... *puts away shovel*, but on a serious note, I'm almost on the same wavelength as you except for the local probe parameter; I had fully intended to use this to get users to associate with more proximally desirable APs, but now I can't do that because of the Hidden SSID parameter, which MUST be visible (as well as the other SSIDS) that are being broadcast.

 

Also, regarding Tx EIRP value of 12, since mine was hardset to 3 couldn't I simply change it to 12 and call it a day? I'll have to research what you said about turning the radios on a band to air-monitors since the deployment was really curtailed towards coverage and not density (something that wasn't covered in my ACMA or ACMP classes). I believe I might be confusing air monitors with spectrum analyzers and, considering I only have 4 135s in deployment, I can't really afford to take any out of the AP function, so please tell me that I'm confusing spectrum analyzing with air monitoring. :)

 

Anything else I should be aware of? I'd like to post an example floor-plan based off of what I'm seeing in AirWave if you'd like to take a gander at it ...

---

If you cannot make the SSID hidden, you cannot take advantage of the local-probe-threshold parameter.  Some clients might be able to discover the probe via beacons if it is not hidden.  With 4 access points and good coverage, you probably don't want to bother with this parameter, anyway.

You could change the min TX to 12 and call it a day--you only have 4 access points.  Don't do anything else.

The only issue you should really be concerned about is if your clients complain about performance issues.  If they do not, don't change anything.  If  they do, gather enough information to determine if it is limited to a specific client, location, SSID, vlan, etc.

Total, at this location, we have 87 access points, but we're broadcasting 8 SSIDs, so I'm pretty sure that's a problem. I'm working on getting them consolidated.

Thanks for your input, Colin! :)

Yes, you have other problems :(