Off-channel scan — evil without which Wi-Fi cannot be cured

Why airtime is more important than channel overlap

The big companies like Cisco, Aruba, and other Ruckus use a "third eye" on the access point — a separate radio receiver that is not used for data transmission at all. A separate radio? In peacetime — a premium feature. In hard times — almost a crime for wasting budget money.

So what should we, mere mortals, do?

Off-channel scanning — a necessary evil

You have to divert the main radio from the working channel and perform off-channel scanning. This always slightly breaks the connection. It creates an unpleasant recursion: in order for Wi-Fi to work well, it first needs to be slightly broken by diagnostics. The classic example is: you treat the patient, but you have to start with bloodletting.

Without this data, any automatic RRM tuning is just guessing.

What is dwell time and why it annoys users

Off-channel scanning is when the access point switches to a foreign channel, listens to the air for some time (dwell time), collects counters, and then returns.

While the radio is not on its own channel, it cannot hear its clients and cannot properly serve the traffic. In practice, this means micro-pauses: latency increases, jitter appears, retries occur, and voice and video become jittery.

The more often and longer the dwell, the more noticeable the effect. Clients begin to call support and yell: "Wi-Fi is bad, my Yandex video bridge is glitching again!"

• Too short dwell > the measurement is as noisy as your drunken neighbor at night

• Too long dwell > the network really suffers, and you become that same neighbor

There is no ideal dwell. The only question is: how much "customer blood tax" are you willing to pay for observability.

Why channel overlap is not the main enemy

Many still think of Wi-Fi RRM as the task of "separating channels so they don’t overlap." This is important, but explains less than half of the real problems.

You can choose a channel with minimal overlap and still get poor Wi-Fi, because the channel is simply occupied by neighbors on the same or neighboring floors.

And vice versa: a channel may look "dirty" because of the number of networks, but work perfectly fine because the neighbors are barely audible, and they have almost no traffic. The neighbors simply exist, but don't interfere – like quiet neighbors who are definitely there, but are neither seen nor heard.

Wi-Fi doesn't suffer from the mere existence of neighbors. Wi-Fi suffers because the environment is occupied, and you can't transmit. This is what airtime utilization (busy) is. It answers the key question: how much time the channel is occupied by others' transmissions or interference, forcing your point and clients to be silent and frustrated.

Three typical situations that the intersection doesn't see

1. Channel "almost without neighbors", but high airtime
   One neighboring device pours traffic 24/7, or an external interference, or someone streams video on old hardware, clogging the air with 5 megabits at a low bitrate. Like a grandma standing in front of you on an escalator when you're rushing to success.
   There is little intersection – the air is clogged. Result: poor latency, low predictability, clients jerk and demand a Cisco or at least a Huawei.

2. Channel "with a bunch of neighbors", but low airtime
   Especially at night or in an office after work. You can hear the neighbors, the intersection is awful, but almost no one is trying to transmit. In reality, you can work great.

3. Non-Wi-Fi interference
   A microwave from hell, a neighbor's Bluetooth speaker, a radar, etc. The intersection by BSSID won't show anything – there are no "neighbors" as Wi-Fi devices, but the air is occupied. Clients and access points hear the noise and remain silent. Classic: "I have no neighbors, but Wi-Fi sucks."

Why off-channel is necessary for RRM

RRM makes the decision "which channel is better" – which means it needs a comparison of channels. On the working channel, you only see one column of reality.

Without off-channel data for other channels, RRM relies on indirect signs: who hears whom, which channels are "usually good," and other random nonsense. This is not optimization; it's an attempt to slip through on luck – sounds tempting, but rarely works.

The funniest part is that the radio environment changes over time: in the morning it's one way, in the afternoon it's different, and in the evening and night it's completely different. Therefore, a configured Wi-Fi is not a constant; it's not something you can do once and forget. It's something you need to do constantly.

Why the airtime graphs for off-channel look like a sieve, and that's normal

With short dwell, measurements are discrete: you hit the "window" - high busy, after a minute of silence - low. This is normal. Off-channel measurements are inherently noisy. The best you can expect is that not-so-beautiful, but usable data is collected without killing the network.

Even with noise, peaks, trends, and clearly bad channels are visible. Channels can be compared with each other. This is enough for RRM. Below are two images, one showing how the access point sees the air when scanning works almost imperceptibly to users and brings about zero benefits, and the other showing more aggressive scanning, which is on the verge of denial of service to clients, but still collects invaluable airtime usage.

.

How to reduce the harm of dwell time while maintaining benefits

1. Do not turn scanning into a senseless torture
   Intensive off-channel only when you are really recalculating the configuration or looking for a problem. Background scan – rare and inconspicuous, like a good killer.

2. Better many short jabs + aggregation than one long one
   A long dwell noticeably breaks the connection. Short ones generate noise, but the noise is smoothed out by accumulation.

3. Never scan with all points simultaneously
   You create a drop in quality yourself, and then you fix the consequences of your own "treatment". You dig your own hole.

4. Add hysteresis
   Even if the channel is a little better, there’s no need to jump. Channel switching itself is felt by users. The solution should require a noticeable gain. Don’t twitch unnecessarily – clients are already on edge.

Main Thought

Channel overlap is about potential conflict.
Airtime utilization is about fact, which directly impacts quality: latency, jitter, loss, speed, stability.

In real RRM, airtime should be the primary penalty. Overlap is a secondary factor that helps to choose between roughly equal options or reduce the mutual interference of our points.

Off-channel is evil. It really degrades the connection.
But it is a controllable evil that provides what is needed to optimize Wi-Fi: visibility of the real state of the spectrum on other channels.

If you don't measure airtime - you don't control Wi-Fi.