Adjusting your WLAN design requirements based on target client devices.
Many times in dealing with customers who are requesting a WLAN design, we ask the question, “What devices do you want us to design the WLAN to?” – we are usually met with a “Duh!” kind of expression and a request to design for “All of them…”.
We know that isn’t possible to design a WLAN that supports all possible client devices the same. We need to design to a very specific requirement, measured in dBm for both Primary RSSI and Secondary RSSI as well as SNR, Data Rates, CCI, etc. So having an actual target device to design to is a critical step in the WLAN design process.
Usually we end up going with whatever device is most ‘persnickety’ – OK, that’s probably a word many non-English speakers will have to look up. What I mean is we design to the device with the most stringent of requirements. In the past, this was usually the VoIP handsets. Nowadays it is probably the Apple iPhones. (see other blog post on the Cisco/Apple design guidelines posted previously)
Many of the various Survey software vendors have mistakenly added a ‘calibration’ function to their options. Please do not use these… they are based on flawed assumptions. (If you need further background on the fallacy of being able to ‘calibrate’ a Wi-Fi NIC – watch Devin Akin’s presentation on Metrology from #WLPC:
We all know different devices display different characteristics. They have different antennas, different chipsets, different firmware options, etc. So how can we design for one device, and yet use a different device in our measurements?
- First – not all NICs are even internally consistent between other same-brand, same-model. I’ve tested the exact same Proxim 8494 against 10 others – and though similar, there might be 2-5dB differentials between same type of NIC to other same type of NIC.
- Second – even holding all things constant, AP doesn’t move, walls don’t move, client test device doesn’t move… there is still variability sitting still. As you are collecting data, which specific data point are you going to use? The highest, the lowest? The Average?
- Third – different devices report different RSSI – even with specifically dBm results. (Using percentage would be far worse since they calculate the percentage differently)
Thus – my recommendation is to follow the words of Samuel Clements and “Compensate don’t Calibrate”.
Measure your own devices, your test NICs, your target client devices, etc. Then compenstate between the averges of each in your design requirements. If your Proxim 8494 reports an ‘on balance’ RSSI of -65dBm and your target iPhone reports -70dBm – then adjust your requirement you will be measuring with the Proxim by the different of 5dBm.
Below are some tests I ran on a variety of client devices over a 5-minute window. Note some devices are more ‘stable’ than others. I’m guessing this is based on the way the firmware calculates the RSSI that is being reported. Some have different time windows.
Note – the Macbook 12” with the exact same internal Wi-Fi NIC reported differently between running in OS X and as a Bootcamp in Windows. Again, same NIC, but perhaps different algorithms on how it calculates and reports the same data.
Also compare the differences between the stability of the reported signal from an Internal Wi-Fi NIC vs an external USB NIC designed for capturing data faster.
I used the AirPort Utility for measurements on the iOS devices, and the Aruba Utility for measurements on the Android devices.
If you have other data sets – please help share with the community. Perhaps as a group we can come up with a standard way of measuring and build a ‘compensation chart’ like to add data to Mike Albano’s great client site.
