Offsets have been around in the industry in some mechanism since the early 802.11n days (maybe longer for some folks).
However, there are still lots of debates about offsets. Do we need them or not? Should they exist in design or just validation surveys? How do we calculate these offset values? Can I trust offsets calculated by other folks?
I can’t answer all these for you today, but what I can do is talk about how best to calculate offsets between two devices. Why I prefer this process vs others, why other mechanisms are flawed, and how to ensure you are using these values so you can be the most successful in this endeavor.
What is an offset in Wi-Fi?
An offset is the difference in signal values between two devices or methods.
Offsets can be the difference between your survey device and an actual end-user device, or it can be the difference between what the predictive design states the signal should be vs what a real device measures.
A typical example would be when your survey device measure -67dBm in a location, but your laptop only measures -72dBm in the same place.
My History With Offsets
In the early days of my career, we didn’t talk about offsets much. I used Airmagnet Pro for my designs and surveyed with my trusty Proxim 8494. But, what I quickly found was that not all 8494 adapters were the same. Of the 3 I started with, one was much more sensitive than the other two.
I noticed very early on that my designs and surveys didn’t match and that my devices did not roam where I expected them to based on the design. The cause of this behavior was that the sensitivity of the 8494 did not match what the actual device saw. It became exceptionally apparent when designing for Cisco 7921 and 7925 VoIP phones. My process was to adjust the design requirements such that the primary and secondary coverage values matched what the actual end user devices saw.
Ekahau is the first company I recall that implemented offsets into their products, hidden by some obscure modifier key combination to have it show up. And since then, more RF tools have been implementing offsets in some form.
The Trouble With Offsets
The conventional way of calculating an offset is to take measurements at fixed distances on the devices and calculate the fixed delta in RSSI between the two devices, typically through averaging.
Offsets are not linear across all signal strengths
The biggest challenge with offsets is how devices measure Wi-Fi signal differences are not linear across signal levels. Most represent signal as a number between 0 and 255, and the device applies these over a range of values. Meaning at -45dB, two devices might register 2dB apart, but that could be three at -50dB, four and -60dB and ten and -80dB.
A recent example in my home lab I was testing multiple devices against the new 6GHz MacBook Pro (MBP). One of my USB NICs that is used in a WlanPi had an offset of 3dBm. However, what I found was the the USB NIC was better than the MBP up to about 55dBm, and above that, the MBP was dramatically better. However, averaging these values resulted in an offset of -3dBm for this USB NIC. But when I directly compared the difference at -70dBm, the offset was closer to -8dBm.
If I had used this data to design or tune my network, I would have missed requirements by 5dB, not an insignificant amount.
Other attempts at solving this issue haven’t accounted for the non-linearity of these relationships and treat the offset as an average of values across a range. The most prevalent is rssicompared. It takes measurements at 3, 6, and 9 meters and does averaging and standard deviation. However, the validity of the data is poor given that the AP model, antenna pattern, and depending on vendor the TX power are all variables that are uncontrolled, and they are not reproducible. Also, the likelihood of having those line up with a measurement that we actually care about is low.
How Offset data is used by tools
Since the proliferation of offset features in RF tools, there are significant challenges regarding how they are applied in any given tool. Recently, I spent some time with the NetAlly Aircheck G3. It has the capabilities to account for an offset. However, it alters the values on its WLAN interface directly. The result is that raw data is altered before it is stored, which can lead to data accountability and traceability issues.
You REALLY need to understand how data offsets are applied in your tools before you can make confident decisions using offset data.
How To Measure Offsets
Here we go. How should you measure offset? My recommendation is to measure an offset at the points of interest in your RF Design. The first requirement we typically need to decide on is desired signal strength. Whether your device wants -67dB, -65dB or -59dB, the primary coverage goal should be the first place to measure offset.
For example, an iPhone prioritizes 5GHz at -67 and above. This means that if I’m developing an offset for the new iPhone 15, -67 is a possible requirement for primary coverage. I don’t care what the difference between the iPhone and my survey device is at -45dB because I’m trying to keep the device at -67 or better.
We also know the roaming threshold is around -70, so -70 is another possible place to calculate an offset. I don’t care what the offset is at -85 because the device will roam away at -70. Points of interest that we should consider for offsets are primary coverage threshold, secondary coverage threshold, roaming threshold, band prioritization thresholds, etc.
While I don’t subscribe to the LCMI device philosophy, it does work within this process, where you start with the LCMI device, calculate offsets, and then translate those same signal strengths to additional, more capable devices.
Measuring Device to Device Offsets
I recommend starting with the device you want to know the offset for, in my example, I’ll take my new iPhone 15 Pro Max and compare it to my NetAlly G3.
Start with the device you want to know the offset for, and walk away from your signal source until you reach the offset threshold you want to calculate. Then measure that location with the comparison device.
In this example, I would start with my iPhone 15 and walk away from the AP while performing scanning. I currently use nOversight on iOS to measure this. I walk away until I hit my desired threshold (-67dBm). Once the threshold is reached, I’ll restart nOversight and hold the phone stationary to confirm that the min and max values are relatively consistent. In this case, it’s + or – 1 from -67dBm.
Now replace the iPhone with the Aircheck G3 in the exact location and repeat. When finished, we should have a relative relationship between the iPhone and the Aircheck G3 at the iPhone’s -67dBm threshold.
A Note on Channels
As much as we would like them to be, antennas are not perfect. While they may have a gain rating, you will find that many antennas do not have the exact same gain over a large frequency range. These variances can cause some discrepancies in your offsets. The most accurate solution is to perform these tests on EVERY channel.
That said, I find this excessive in most cases. While we should be designing to meet our requirements, we shouldn’t create fragile designs, and a margin of error is essential to remove fragility. I find it is easier to repeat the test for a low channel, middle channel, and high channel in each band and take the worse value as your offset in 5GHz which might be 36, 100, and 165.
A Note on Environment
If you perform this testing in an open field, you will get different results than if you do it in a warehouse or an underground mine. This is why crowdsourcing this data is so complex, the device capabilities and the environmental effect can be drastic. Obviously, for the most accurate results you should use an RF chamber, but that’s not practical for everyone. So, my recommendation is to experiment yourself and find where you find the most representative results.
Measuring Predictive to Measured Offsets
I wrote about the idea of multiple types of offsets in 2019, because I didn’t like how Ekahau was doing offsets then, and proposed a better way. And I still believe that we should be discussing offsets in terms of deviation from what the predicted signal should be.
For predictive offsets, you can repeat the same process but start with the predictive model and find out what it shows the signal should be at a point. Then, measure with your survey device and validate the results.
Using Your Offset Data
Now that you have the offset between your two devices, should you just plug that into whatever option the tool vendor gives you? My recommendation is no.
When we design networks, we are trying to get it so that we are meeting the requirements. That means we are altering our design in order to achieve a specific result. If you are applying offsets in a tool, this obscures the effort that goes into both calculating and incorporating that offset into a design.
This is why my preference is that we should ALTER the design criteria in order to account for the offset.
If you listen carefully, you can hear every RF tooling vendor throwing up their hands in frustration. After years of building in offset features, I’m telling you not to use them.
Your design should account for the difference between predictive software and survey devices. And that you should take the difference between your survey device and the actual devices. But those can and should be represented as adjustments to the design requirements and not alterations of predictive or measured data.
So, instead of applying a -3dB offset to your data, you use +3dB offset to the requirements. And if you took your offsets at the primary, secondary, roaming thresholds, etc, you apply the specific offset to the individual requirement.
ToDSFromDS 