Wi-Fi Relationships… It’s a one sided affair.
The relationship
The relationship between APs and STAs (clients), from an outside perspective, looks like a 50-50 split. However, this could not be more wrong. In most aspects of AP and STA relationships, the STA wears the trousers.
The STA (I will use STA more than client, as it’s shorter to type and more in line with the IEEE 802.11 documentation) decides the guard interval, MCS index, roaming thresholds, which band to transmit on, as well as several other features and behaviours that determine how wireless communication occurs.
That said, the AP is not entirely powerless. It can make recommendations such as band steering, minimum RSSI (a tool I have a love-hate relationship with), and data rate settings, to name a few. I will also cover STA load balancing, as this is one of the few areas where an AP has more control than the STA.
This brings me on to one of those analogies I thought of, to help explain the relationship between AP and STA. APs are like waitstaff: they serve exactly what the STA asks for in the best possible way, with one caveat, it has to be on the menu (frame). There is no off-menu ordering in wireless; you just aren’t going to get it, plain and simple. So, in this blog, we are going to look at what happens during a cordial service and what it looks like when things go a bit pear-shaped.
Access Points and their suggestions
So, lets talk about our wait staff the AP. Now, in 2025, after many revisions of the 802.11 amendment, we have a plethora of tools to help us give STAs better suggestions and I’ll go over a few main ones in this section.
Band Steering
Band steering, in simple terms, is like getting the specials menu before the main menu. It’s aim is simple: to encourage STAs from the congested 2.4 GHz band onto the more open and less congested 5 GHz and 6 GHz bands, where supported by the STA, making wireless communication more efficient and giving users a better overall experience.
How this works in the real world: when the STA associates or authenticates with an AP, the AP will detect if the STA is dual- or tri-band. Upon discovering 5 GHz or 6 GHz capabilities (via probe request and probe response frames), the AP may delay, suppress, or even reject attempts on 2.4 GHz in the hope that the STA will try the 5 GHz or 6 GHz band. This is only a suggestion, though, if the STA is persistent enough, it can still connect to the 2.4 GHz band.
It is worth noting that 6GHz band steering works differently. STAs don’t actively scan on the 6GHz band, instead they use Reduced Neighbour Reports (RNR) which advertise a 6Ghz Radio within 2.4/5 GHz beacon and probe frames.
There are also standards-based mechanisms that complement vendor band steering features. Once a certain RSSI threshold is reached, the AP may use 802.11v BSS Transition Management (BTM) to suggest that the STA move to a 2.4 GHz radio or roam to a different access point. However, once again, it is ultimately the STA’s decision.
To build on vendor band steering Wi-Fi Alliance standards like MBO/OCE (Agile Multiband) which build up on 802.11k/v to provide a more consistent and predictable way of steering across vendors.
Finally, a disclaimer: band steering is not a magic pill. It can sometimes degrade the user experience, depending on the behaviour of the STA itself, something I’ll explore more in the client section.
Minimum RSSI Threshold
Disclaimer: I’ll try to be unbiased in this section, as it is a useful tool. However, in my experience over the last 12 years in IT, I’ve only used it in very specific environments, and even then, it was far from perfect. At times, it feels like there should be an extra tick box labelled “acknowledge the number of issues this can cause.”
Minimum RSSI is like being told you have two hours at your table, and at two hours and one minute you’re tipped out of your chair, told to pay, and shown the door. It’s not very enjoyable. This is what’s known as a “soft kick” technique, quite ironic isn’t it.
How it works, you set the minimum acceptable RSSI for a STA can have on that AP, if a STA reaches that threshold the AP it sends a disassociation or a deauthentication frame to the STA and it disconnects the STA from the AP.
You may think this sounds great, finally AP has some control! Minimum RSSI is like trying to use a sledgehammer to crack a nut it’ll do the job but you might not be happy with the outcome.
When the STA is disconnected, it is forced to search for a new AP and then attempt to join it: exchanging probe request/response, association request response and possibly authentication/reauthentication request/response, creating extra overhead by requiring the whole process to be completed again. With 802.1X this overhead is even greater unless fast initial link setup (FILS) is supported and used, this is by shortening the frame exchange reducing EAP round trips and caching keys, but not all STAs support this.
During this period, the STA is disconnected and cannot send data or receive data. For latency sensitive or database centric applications, examples can be Teams, VoIP, Zoom and WMS (warehouse management systems) the disruption is noticeable. If the STA is not already scanning for another AP, the problem is amplified further.
I will touch on Hysteresis algorithms in the STA blog, but in short they are vendor or software specific and require a predetermined threshold to be reached before searching for another AP. So if the minimum RSSI value is reached before the value determined in the hysteresis threshold. The STA may need to go through entire connection process again, taking longer than expected.
Where I have seen it used and proposed is high density environments where airtime is precious and minimum RSSI can help prevent airtime from being wasted by forcing APs to cull sticky STAs with weak signals, but at the same time these venues, such as stadiums and auditoriums most users can be static rather than mobile.
Lastly on roaming with minimum RSSI it does not guarantee that the STA will roam to a better AP. It only guarantees that the STA is disconnected from the current AP.
Data rate limiting
Something similar to Minimum RSSI, but one I have more positive things to say about, is data rate limiting. Again it’s not a silver bullet but let me tell you I’ve improved wireless environments noticeably with it. This is possibly one of only a handful of times the AP has control of a variable, if it’s not on the menu you can’t have it.
Data rate limiting in short is specifying the minimum (and sometimes maximum) data rate supported, which are advertised in the beacon frame sent out by an AP at the lowest supported rate. If we think back to the mid to late 90s when 802.11 relied on DSSS and FHSS, data rates were far lower and efficiency was nothing like what we see today with 802.11ax and 802.11be.
Keeping this in mind the quicker a STA can transmit or receive data from its buffer the less time it spends on the wireless meaning it does not have to take up as much time on the medium in turn less airtime is used freeing up the medium again.
For example one STA on 1Mbps needing to transmit can consume the same amount of airtime as multiple STAs at 54Mbps, by removing the capability of transmitting at 1Mbps it forces the STA to either transmit at a higher speed or roam to another AP taking up less airtime in either APs basic service set (BSS) allowing for more efficient and effective usage of the medium. Remember Wi-Fi is half duplex you can only (currently) send or receive. STAs also will not hang on to low throughput rates (sticky clients) causing high airtime utilisation or Transmission (Tx) retries because of weak signal.
However, this is not without its trade offs, by increasing the minimum data rate we can shrink the coverage area of an APs BSS this is due to the higher-rate transmissions do not travel as far as 1 Mbps beacons. Another consideration is your STAs what is going to use the wireless, a lot of IoT devices (new and old), barcode scanners, medical devices, speakers and operate on the older standards and I’ll use my own description of B.A.N.G clients. Depending on by how much you are raising the data rates you may remove the capability of these devices to connect to the wireless this is a huge problem if they are in the slightest way needed as they STA cannot see the data rate in the beacon frame.
With data rates I like to keep it sensible in the 5GHz range and it will depend on the STAs who are connecting, don’t set it to something ridiculously high as you are causing your own problems. A good rule of thumb 2.4 disable up to 5.5Mbps, 5 GHz 12 or 18Mbps. And test, test a lot especially where you have identified legacy devices which you should have done during your survey.
Something I sometimes recommend, where legacy devices must remain in use, is deploying a second set of APs (they don’t have to be brand new) broadcasting a dedicated 2.4 GHz SSID. This can keep those devices connected while freeing up newer APs and STAs from being slowed down by older, less efficient STAs. IoT devices in particular tend to focus on transmission resiliency over throughput, so separating them can help provide a better overall experience.
Bear in mind, though, that the 2.4 GHz band is already very congested, with only three non-overlapping channels and added SSID management overhead. If you use this approach, it needs careful RF planning to avoid making congestion worse.
Multicast & Broadcast Rate Limiting and efficiency
Another form of rate limiting applies to broadcast and multicast traffic, which is always transmitted at the minimum basic rate (MBR). Some vendors also convert multicast traffic into multiple unicast streams at higher rates, known as multicast-to-unicast or “multicast optimisation” to improve efficiency.
The aim is simple: to reduce the airtime wasted on low-rate broadcast and multicast frames. However, there are trade-offs. Converting multicast to unicast increases the overall frame count, adding its own overhead, and I’ve personally seen broadcast-dependent services such as DHCP fail when this feature was enabled. Issues like that are often very difficult to diagnose and resolve.
Air Time Fairness
Airtime fairness is a fairly self-explanatory mechanism that most modern APs can, and should, use. It’s purpose is to stop older or slower devices from monopolising the medium by transmitting for long periods of time. Instead, each STA is allocated a fair slice of airtime in which to transmit.
It’s like a buffet where you’re only allowed to go up and spend five minutes getting your food. Anyone that is indecisive isn’t going to hold up the rest of the queue.
That said, airtime fairness doesn’t magically make inefficient STAs faster. It simply stops them hogging the airwaves, ensuring newer and more efficient STAs get their chance to transmit without being blocked by legacy devices.
Target Wait Time
Target Wake Time is a relatively new feature, designed with battery-powered devices in mind. First introduced in the 802.11ah amendment and further refined in 802.11ax, it allows APs and STAs to negotiate when the STA will sleep and when it will wake for a service period (SP) to transmit or receive data.
The core principle is simple: instead of the STA constantly contending for airtime in a busy medium, it schedules its communication with the AP. When the STA is awake for its agreed service period, the AP knows it can deliver both solicited and unsolicited frames, while the STA can transmit without needing to fight for access.
Service periods are these pre-agreed times when the AP knows the STA will be active and able to exchange data.
There are two types of TWT and both work exactly as their name suggests:
Individual TWT: A per-STA negotiation where the AP and STA agree on dedicated service periods.
Broadcast TWT: A group agreement where multiple STAs share the same schedule with the AP for example a fleet or air quality sensors will wake at the same time transmit their readings and return to dozing state this reduces the overhead of Individual TWT scheduling.
The main advantage of TWT is power saving, but there are additional benefits, particularly in IoT-heavy environments: reduced contention and more efficient airtime usage, which is critical in congested RF environments.
The main drawback is that legacy STAs don’t always support TWT, so this mechanism can only be leveraged when both AP and STA are capable.
A simple way of thinking about TWT is like reserving a table at a restaurant and pre-ordering your meal, you know exactly when you’ll be seated and what you’ll get, without waiting around.
Ready to order?
It’s clear that the AP can attempt to influence the STA in how it behaves, but just like us humans, we don’t always do what’s best, for better or worse. We can give it all the guidance possible, but if the STA really wants to communicate a certain way, it’s going to do so regardless.
The age-old saying applies well to the AP–STA relationship: “you can lead a horse to water, but you can’t make it drink.”
This is the first in a two-part blog, the next blog will be from the STAs perspective.