Ekahau Masters: Thoughts About Offsets in Ekahau Pro

Offsetting in Ekahau is a controversial subject. It’s a “hidden” feature meaning it requires a particular keyboard combination to find. It IS in the documentation, so you have to go looking for it to find it. That said, during the discussions at Masters about the offset I started to think about what the offset number means.

---

Let me start with, “I can’t talk about what we saw at Ekahau Masters.” I’m under NDA. I can talk about a topic of discussion that came up, and some of the thoughts I had during the event and after while I was flying home.

Today, in ESS the offset is a single number that shifts all Wi-Fi signals either up or down. This adjustment could be measured data like from a sidekick or a Proxim adapter, as well as virtual data from a simulated AP.

But what was most illuminating was what happened when I tried to draw out the offset and tie it to different processes I’ve used over the years. What I came up with is that we need three different offsets in Ekahau. Here’s my crude drawing from Masters.

The realization I had was that we don’t care about a single offset value. The offset is situational depending on our workflow. So let’s go through some workflows and kind of highlight how offsets should be applied. It’s also useful to name these different offsets so we can have conversations with others. It’s very complicated, and without proper names, it’s hard to have meaningful discussions amongst professional wireless folks.

Device Offsets:

The goal of the device offset is to be able to compensate for the receive signal difference between the measurement device used for surveys (Sidekick) and the “least capable, most important” device. Device Offsets only apply to measured data. Examples of workflows utilizing Device Offsets include APoaS surveys and Post Validation Surveys.

Predictive Offsets:

Predictive Offset would apply only to data from virtual/simulated APs, meaning this offset would not impact measured data. Predictive Offsets are used to adjust for the delta between the mathematical model and the sensitivity of the “least capable, most important” device.

Hybrid Offset:

Hybrid Offset would only be used in comparison visualizations and Mouseovers and affect only measured data. The goal is to verify that my predictive model closely matches empirical data collected on-site, but compensate for the sensitivity of the measurement device.

Depending on your workflow and design methodology, you might need one or more of these offset values.

AP-on-a-Stick:

A typical process would be to calculate the Device Offset and then do APoaS surveys based on that offset. After this process, a validation would likely use the same offset, making this the most simple example using a single offset value.

Predictive:

Another workflow that most people understand is dealing with a predictive model. Starting with the Predictive Offset, we would design a predictive only model. Here, we are trying to compensate for the difference in the theoretical signal and the measured signal as seen by the device.

The challenge is that when you get to post-installation validation, you need to calculate the Device Offset to ensure your validation results are accurate.

Hybrid:

The goal here is to adjust our predictive model based on measurements conducted an APoaS survey. The goal here is to create a predictive design and compensate based on what we measured. Then you can design the rest of the floor without having to do as much APoaS work. Ultimately, you will still need the other two offsets, because eventually, you’re going to want to design for the client device and finally validate that with a post-installation survey.

The Hybrid and Predictive dilemmas:

In both of these workflows, ultimately we have to go back, and post-installation validate the network. Because we didn’t start with the Sidekick to the device, we still need to calculate the Device Offset. We could take the Hybrid and Predictive offsets and calculate the Device offset, but with so many variables it’s probably best to figure it directly

Once you start looking at it this way, the whole ball of yarn begins to unravel. ]My idea of breaking into three individual offsets help us define when these values impact us and what data they affect.

Let’s walk through a Predictive example to illustrate:

Once the predictive design is complete, it shows that the signal level at the far wall of a large room should have a signal level of -65 dBm. Now we install the AP and take our iPhone to the same location and measure with a result of -70 dBm. This result shows that our Predictive Offset should be -5 dBm. If we were to survey this with the Sidekick, let’s say it showed a value in the same location of -62 dBm. These measurements result in a Device Offset of -8 dBm and a Hybrid Offset of -3 dBm.

So do we monkey with the “singular” offset at each phase? Or should we be going back to Ekahau and asking for multiple offsets? My concern with changing a single offset value is that it can be easy to forget changing the offset when moving between phases of a project.

It’s not the Sidekick’s fault:

Ultimately, the Sidekick’s sensitivity has made the concept of offsetting a big topic, but don’t try to go blaming the hardware for this issue. Compensation has always been a problem. In the past, we would do things like bumping the requirements to correct for lack of an offset feature.

Stanley Kubrick probably would have put it this way.

This problem has always been here, and will always be here.

Future considerations:

There is one more offset I would like to discuss, and that is the Per-AP offset. Once we can offset different data in different ways, this could open up the possibility to offset individual APs to represent adjusting AP TX power. I am frequently involved in the remediation of wireless networks, and often changing TX power is an option to explore. However, this is difficult to visualize today.