Devin Akin is the founder of Divergent Dynamics, a Wi-Fi Systems Integrator, Value-Added Reseller (VAR), and Training organization. He specializes in innovative performance optimization solutions for a variety of high-density scenarios in several markets.
Blog (WLAN Pros Blog)
Peter Mackenzie: Many wireless networks are designed using a basic RF specification which defines thresholds and limits based on signal strength. Signal strength may be a useful metric when defining coverage but not capacity.
[Read more…] about [Video] Specifying the Specification by Peter Mackenzie
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.
Remember, Compensate, don’t Calibrate!
Ronald Van Kleunen provides IT service mgmt, security and wireless certification training services since 2003.
According to Bluetooth.com there are two flavors of Bluetooth:
After reading the 36-page guide from Cisco on how to design for Apple devices on your WLAN, I’ve culled it down to a quick set of recommendations that can easily fit on a single page.