Currently I'm working on a issue which is very stubborn.
One of our customers has very large open areas that are being made of aluminium walls , floors and ceiling and. Next to the room itself there is a lot of metal in the area / machinery , desks etc. These are confined area's.
Clients have connectivity issues. What we've done this far :
- when enabling lower data rates (12 - 18Mbps) so effectively enabling QPSK connection seems to be more stable.
- When using patch antenne's it seems to be meer stable. (AP's are typically mounted against the ceiling).
- Mounted AP 30CM below ALU ceiling --> no difference.
- (long) Guard interval does not change anything.
- Started using 20Mhz channels to have less CCI.
- Disabling some AP's to not have to many AP's.
- Test with AP with integrated antenna in the area, some issues. You'll see a connection drop in MCS rate when you move away (only a few meters) from the test AP
- Multiple site surveys have been conducted (using Ekahau by multiple parties) to check for interferers , Rogue's , Coverage etc, all fine.
- issue occurs in both bands but most clients typically connect to 5Ghz.
Typically when a client is moving away from an AP you'll see that the connection drops to MCS 1 - 4. Also the clients are very sticky in this highly reflective area's. Effectively this leads to situations that a client does not roam to a neighboring AP whilst it has a very crappy connection (MCS1).
When we had not enabled 12 - 18 Mbps in many cases clients could not connect.
WLC reports in many cases a very good RSSI / SNR eventhough the client device thinks otherwise.
In similar smaller areas it works as a charm. In warehouse / office all works fine except these environments. We tried with 8.5 and 8.10 code / 3800 series AP's.
As mentioned using patch antenne's it seems to be more stable, we get less complaints but the throughput is still very low because of the MCS shifting.
Has anyone some other suggestions
This to me sounds more like a RF related issue due to client side limitations. What are the clients you are having the issue with? Was the clients profiled to learn their WiFI capabilities? Are they running with the latest WiFI drivers?
I agree it is RF related but not to a specific type of client. I've observed the issue with Iphone 11 Intel AC-8265 with latest drivers and even a WIFI 6 enabled intel AX-201 NIC . The main issue is with the laptop as those are the corporate machines to be used for all of their applications.
We also tested power levels, high power levels lead to situation which is worse than with low values. Now we operate typically at power level 6 ~ 8. Even with low power values u will measure very large cells (when using Ekahau).
I've also tested with the power level settings from client side : no difference.
I'm pretty sure that it has to do with reflection but is difficult nor impossible to prove this via any kind of measurements.
All of those devices work as a charm in the office / warehouse environments.
It is one of many 1000m2 area's all of those have the same issues.
ceiling height is approx. 7 meters.
Amount of users depends, In general about 10 clients per AP. those are not crowded areas.
Amount of AP's about 3 to 4 depending on the specific area. We've also tested with only 1 AP enabled, same issues. Instead of 3 we also tested with 7 AP's, same issue.
My recommendation is to use lower data rates for these cases.
Unwanted reflections and re-reflections in all directions in such areas could make RF signal to cancel.
First thing to do, try to use only long guard interval as with short interval the next symbol could be transmitted to soon so probably colliding with the earlier symbol.
Then try to disable higher modulations and use more robust modulations such as BPSK setting 6 Mbps as basic rate, and support only 9 Mbps. Then if that looks good, try to enabling QPSK modulation with 12 Mbps and 18 Mbps.
It's better to use lower rates and provide a decent user experience, that trying to support higher rates and speed but impact performance.
*** Please Rate Helpful Responses ***
I agree 100%. I would also test with higher data rates disabled and lower rates enabled.
Long guard interval is a must in this environment.
Beside from that you took the right steps, try to reduce reflections. Reduce power, increase distance between AP and ceiling and other reflective materials. Use directional antennas.
As you mentioned signal strength and SNR will be always good. If you want to compare quality you shall look for retry rates and rate shifting. I recommend a packet capture.
Also the client device has huge impact on the performance. Legacy devices will not work well and MIMO technology is a must.
What is the rationale behind disabling higher data rates ?
When a client connects I see it connecting on high rate but shifts MCS within seconds and is pretty stable when connected. Typically QPSK or 16-QAM can be achieved, MCS 1~4. So I don't see the benefit of disabling higher rates to be honest. Or I have to go as far back as QPSK indeed, that could work....
Tried the long guard interval but didn't see noticeable performance / stability gain. And it is a global setting which I do not like. We've got >1000 AP's on that controller and it is bad to have a drop in performance for 95% of the users ?
I'm starting to believe that WI-FI is may be just not suitable for these kinds of environments.
The idea behind disabling higher rates is that you save a many retries and therefore time when you directly send with lower (realistic) rates. It does not make sense to send 256- or 64-QAM frames when these frames never get acknowledged.
Rate shifting heavily depends on the client and is not well documented, but majority of clients always try to send with highest possible rate. Especially when they have strong signal and high SNR, like they have in your case. Some rates are tried couple of times before downshifting occurs.
So your clients might send at least one frame with 173 Mbit/s, if it gets no ACK either it tries to send it again with same speed or rate shifts down. So it might send another two frames with 173 Mbit/s, if there is no ACK, it might try 144 Mbit/s, 130 Mbit/s, 116 Mbit/s, 87 Mbit/s, 58 Mbit/s, 43 Mbit/s and maybe finally with 29 Mbit/s your frame gets ACKnowledged, but it was retransmitted 10 times before. Smart clients will directly use a lower rate for the next frame, but some clients will start again with top speed and you have vicious retry cycle.
I recommend that you capture some frames in the air. In that way you could see how your clients rate shift. You could also measure number of retries in your network.
I've attached an example of a downshifting client. It send two frames with 86, two frames with 58, four frames with 43 and another two frames with 14 Mbit/s. It's all the same frame.