RX-SOP
Receiver Start of Packet, the threshold that decides which frames an AP bothers to hear
RX-SOP sets the signal level at which an AP radio starts to demodulate an incoming frame. Raise it and the AP ignores distant or weak transmitters, shrinking its effective cell. Used carefully in high density it improves cell sizing and load balancing. Used carelessly it creates a client that hears the AP perfectly, transmits, gets no answer, and never roams. RX-SOP is not an IEEE feature. It is a vendor lever, and each vendor implements it differently.
A preamble-level decode decision
When a frame arrives, the AP radio first detects the preamble, then decides whether the signal is strong enough to be worth demodulating. RX-SOP sets that decision point. If the received signal is below the RX-SOP threshold, the radio treats the preamble as noise and does not decode the frame. The frame is not weak, not corrupt, not lost to interference. The AP simply chose not to listen.
This is a receive-side decision made entirely inside the AP. The client has no knowledge of it, no field in any frame carries it, and there is nothing to negotiate. Two APs with identical coverage can behave completely differently if one runs default RX-SOP and the other runs an aggressive threshold.
Hear everything decodable
At the default threshold, the AP demodulates any frame whose signal clears the standard CCA signal-detect floor, roughly -82 dBm for a 20 MHz OFDM preamble. The cell is as large as the radio sensitivity allows. Distant clients are heard, which is usually what you want, except in dense deployments where every AP hearing every client wastes airtime.
Shrink the cell deliberately
Raise RX-SOP to, say, -76 dBm and the AP ignores anything weaker. The effective cell shrinks. Clients that were marginal now fall below the line and the AP stops acknowledging them, which is meant to push them toward a closer AP. The intent is tighter cells and better reuse. The risk is described in the Black Hole tab.
802.11ax OBSS_PD is the standardised cousin of RX-SOP. Both raise a receive threshold so the radio ignores weak signals. The differences are important. OBSS_PD only applies to inter-BSS frames, identified by a different BSS Color, so it never clips your own clients. OBSS_PD also carries a mandatory transmit power back-off so the device you ignore hears you proportionally less. RX-SOP has neither safeguard. It applies to every frame regardless of source, and it does not reduce your transmit power. RX-SOP is the blunt instrument. OBSS_PD is the same idea with guardrails.
Cisco gates on RSSI, Aruba gates on SNR
The single most important thing to know before touching this knob is which quantity your vendor gates on. Cisco RX-SOP is an absolute RSSI threshold. Aruba achieves the same cell-sizing goal through Cell Size Reduction, which operates relative to the noise floor (SNR). The distinction changes how the feature behaves in a noisy room, and it changes how aggressively you can tune.
RX-SOP threshold
Cisco Catalyst 9800 exposes RX-SOP as named levels per band. The threshold is an absolute received power in dBm. It is intended for weak-RF-link clients, sticky clients, and client load balancing across APs in high density such as stadiums and auditoriums.
Cell Size Reduction
Aruba reduces effective cell size by raising the receive sensitivity floor relative to noise, an SNR-based approach rather than an absolute RSSI cut. Because it tracks the noise floor, the behaviour adapts as the environment changes. A higher noise floor moves the effective cut point with it, which is a different failure profile from a fixed dBm threshold.
An absolute RSSI threshold does not know the noise floor. In a clean room a -78 dBm cut leaves healthy margin. In a noisy room that same -78 dBm cut may sit only a few dB above noise, so the frames it does accept are marginal. An SNR-based cut keeps a constant margin above noise by definition. Neither is universally better. They fail differently, and you tune them differently.
No client support required, downlink and uplink asymmetry
RX-SOP needs nothing from the client. It is a pure receive-side setting, so it works with every client ever made, including legacy devices. That is its appeal and its danger. Because the client cannot see the threshold, it has no way to know the AP has decided to stop listening to it. The client keeps hearing strong beacons on the downlink, concludes the link is healthy, and keeps trying to transmit on the uplink to an AP that is no longer answering.
Connected, in range, and going nowhere
The classic RX-SOP failure is a client that appears perfectly connected and cannot pass traffic. The downlink is fine. Beacons arrive at strong RSSI. The client shows full bars. But the AP, with an aggressive RX-SOP threshold, has decided the client's uplink signal is below the line and stops demodulating it. Frames go unacknowledged. The client retries, retries again, and because it still hears the AP it never decides to roam. It sits in a black hole.
Downlink beacons and management frames arrive at strong RSSI. From the client's point of view the link is healthy and there is no reason to roam.
The client sends data or a probe at its own transmit power, which is far lower than the AP's. A phone at 5 to 8 dBm against an AP at 20 dBm or more is the common mismatch.
The client's frame arrives below the raised RX-SOP threshold. The AP does not demodulate it and sends no ACK. Nothing is corrupted. The AP simply declined to listen.
Missing ACKs trigger retransmission and a rate drop, not a roam. Roaming decisions are driven by beacon RSSI, which is still strong. So the client retries at falling MCS and stays put.
The client is associated, shows good signal, and passes almost no traffic. To the user it looks like the internet is broken. To the AP dashboard the client may not even appear as a problem, because the AP is not hearing it.
The AP cannot report on a client it has chosen not to demodulate. By definition the black-holed client is below the AP's receive threshold, so it is partly or wholly invisible to the controller dashboard. This is the core reason RX-SOP problems are so hard to diagnose from the infrastructure side, and why a sniffer capture from near the client is often the only way to see both halves of the link at once.
The link is not symmetric
RX-SOP black holes are made worse by transmit power asymmetry. An AP transmits at high power and is heard easily on the downlink. A phone transmits at a fraction of that and is heard with far less margin on the uplink. The path loss is the same in both directions, but the transmitters are not. So a client can be comfortably inside the downlink cell while sitting outside the AP's raised uplink RX-SOP cell. The asymmetry is the gap the black hole lives in.
Tune out adjacent cells, never your own clients
RX-SOP is safe when it shrinks a cell just enough to stop hearing the next cell over, and dangerous the moment it starts clipping clients that should be served. The whole craft is staying on the right side of that line. Raise the threshold to reduce overlap between APs, never to a level where a legitimately served client falls below it. If you cannot get measurements first, do not touch the knob.
A method that does not create black holes
Poll the controller for the received RSSI of every associated client, repeatedly, over a full duty cycle of at least 24 hours. You want the distribution, not a snapshot.
For each AP, find the weakest client you actually need to serve. That minimum is the floor you must stay below. Your RX-SOP threshold must never rise above it.
RRM neighbour-discovery frames between APs must still be heard for the system to manage itself. Do not raise RX-SOP so far that APs stop hearing each other's NDP frames.
Move one level at a time. 5 GHz first, since it carries the high-rate traffic and tolerates smaller cells better than 2.4 GHz. Re-measure after every change.
After each step confirm channel utilisation fell, retry rates did not rise, MCS did not crash, and no clients began panic-probing. If any of those move the wrong way, back off one level.
High-density venues are where this knob pays off. Stadiums, arenas, lecture halls, and conference floors put hundreds of clients in line of sight of many APs at once. Default cells overlap massively and airtime collapses under contention. A carefully tuned RX-SOP, set from measured client distributions and validated against retry and MCS metrics, tightens cells so each AP serves the clients nearest it. This is the use case the Cisco documentation calls out directly, and where experienced high-density designers use it to real effect.
What an RX-SOP black hole looks like in a PCAP
RX-SOP cannot be read from a frame, because no frame carries it. You infer it from a pattern: a client at strong RSSI, retransmitting heavily, getting no ACKs, not roaming, not scanning. The capture has to be taken from near the client, not at the AP, because the whole point is that the AP is not hearing the client. A sniffer near the client sees both the downlink the client receives and the uplink the AP is ignoring.
Confirm the client is genuinely in range. Beacons from the serving BSSID should arrive at the sniffer, positioned near the client, at strong RSSI. This rules out a true coverage problem and sets up the contradiction.
wlan.fc.type_subtype == 8 && wlan.bssid == aa:bb:cc:dd:ee:ff The signature symptom. The client retransmits the same frames because the AP is not acknowledging them. Look for the retry bit set on a large fraction of the client's uplink data frames, with missing ACKs in the gaps.
wlan.fc.retry == 1 && wlan.ta == 11:22:33:44:55:66 wlan.fc.type_subtype == 29 && wlan.ra == 11:22:33:44:55:66 The client's rate adaptation reads the missing ACKs as a bad link and drops to the lowest MCS, trying to punch through. You see uplink data frames sliding to MCS 0 or 1 even though the downlink stays high. Rate asymmetry on one client is a strong RX-SOP tell.
wlan.ta == 11:22:33:44:55:66 && wlan_radio.11n.mcs_index <= 1 The defining negative. A client in a coverage hole scans and roams. A black-holed client does neither, because its beacon RSSI is strong. Confirm the absence of off-channel Probe Requests and the absence of a Reassociation Request during the stuck window.
wlan.fc.type_subtype == 4 && wlan.ta == 11:22:33:44:55:66 wlan.fc.type_subtype == 2 && wlan.ta == 11:22:33:44:55:66 Building WiFi Analyser V2 · CWNA-109 in progress · one post every two weeks