Tag Archives: design

Working with RX-SOP in a High-Density Network

Caveat Empator:

Of all the new features introduced in the 8.0 code this one is perhaps one of the most powerful, and also most dangerous if incorrectly implemented.

RX-SOP has been around a while, available via hidden CLI commands since the 7.2 code release and has been a go to tool of choice for finely optimising a high-density network once the usual “HD 101” type stuff has been done.

Over the last couple of years I have grown very comfortable with using RX-SOP on a day to day basis and often consider how it can be used as part of a design to squeeze out every last bit of performance from the network.

I am not encouraging people to use this as a way to cut corners on proper RF deisgn – that will frankly lead you to a whole world of hurt, however when you add it into the mix of all the tools we have available it can provide fairly significant gains in performance. Also please consider that my expereicnes of this feature is in that of high-density and super high-density deployments, often temporary ones for large scale events – not a hospital, office or school.

RX-SOP is a powerful tool, but heed warning here folks – understand what it does, understand how it will effect your environment not only from an infrastructure point of view but also client behaviour and thorogouhly test the results of your tuning. I would strongly urge anybody to go and read up on CSMA/CA and understnad it before you dive in and reach for the nerd knobs!

What can RX-SOP actually do for me?

In terms of what problems it can help us address I would refer you to the previously linked articles, but the TL;DR version would be something like this:

CCI / ACI are frankly hard to avoid in high-density designs, especialy consider this in the context of 2.4GHz and how CSMA/CA works.

RX-SOP gives us a means by which we can make the AP deaf to frames below a given threshold, and as a result allows us to force the AP into ignoring that the channel may otherwise be considered as busy.

A good analogy that I use when describing this feature to other engineers is that it’s like a pair of variable earmuffs for your AP. It can also be used as a tool to help us solve the sticky client issue.

Configuring RX-SOP:

A while ago there was a good bit of discussion on Twitter about what could be considered “a good starting point” in terms of values to use with RX-SOP, I was reticent to be specific in my answers during that discussion and still think the sensible answer here is “that depends”.

There are no hard rules on this, but that’s not to say there isn’t a good starting point or a way to determine one for your environment.

The NSA paper has a good section on how to go about arriving at some starting values for your network.

In 8.0 Cisco have introduced some buttons into the GUI that also take a bit of the guesswork away from this, four simple presets that can be applied either globally, or on a per RF-Profile basis. They apply the following values to the RX-SOP threshold of your network or group of APs according to RF-Profile:

Band
High
Medium
Low
Auto
5GHz -76 dBM -78 dBM -80 dBM Radio Default
2.4GHz -79 dBM -82 dBM -85 dBM Radio Default

For those of us who don’t feel those values meet our needs we can also apply a custom value either globally, per AP, or to an RF-Profile via the CLI:

config 802.11a/b rx-sop threshold <value> default
config rf-profile rx-sop threshold <value> profile_name
config 802.11a/b rx-sop threshold <value> ap ap_hostname

These commands override each other too, in other words per-ap trumps rf-profile which trumps global.

Real world example from the trenches:

A few months ago in an auditorium far, far away we had finished deploying a reasonably large number of 3702e + 2566 patch antennas (overhead mounting, ~7m high and in a 10×10 grid) to provide WiFi access to approx. 6500 delegates attending the event.

The night before doors opened we made our final measurements, mapped out coverage, tweaked TPC and arrived at a consensus  of what we considered a safe value to set RX-SOP at. For the sake of brevity I will focus on the 5GHz results here.

Our surveying had shown us that the average seat in the auditorium could see and be seen by at least 4 APs at a signal strength of -72 or higher so we decided to set RX-SOP to a value of -75 for 5GHz. After initial testing we felt confident that this would result in dropping sticky clients from APs as they entered the auditorium and also try and disperse the clients over the available APs (our target was ~100 clients per AP) once people had taken to their seats.

Well, we kind of got it right… As the room began to fill it looked like everything was going well until we hit about 60% capacity in the seating. We began to notice that some APs were now taking more than their fair share of clients, whilst neighbouring APs were almost unused by comparison. At that point we also began to see channel utilisation spike, and client associations were also failing.

After a few minutes of waiting to see if the situation would improve as people sat down and hopefully roamed onto other APs we were not seeing any drastic changes. We decided to raise the RX-SOP threshold on the network to -70. Now, if you look back at what Cisco considers to be a “high” value for 5GHz that is certainly well beyond that, and anybody who has used this command will appreciate just how much difference ±1dB threshold adjustments can make! Anyway, the end result was good and almost instantly improved the client distribution across the APs, reduced channel utilisation on the previously hammered channels and people were once again associating to the network.

Now, the above isn’t the most technical or imperial of examples (I can’t really share much more information about the event in question) but the point I am trying to get across is that RX-SOP is a great tool, and one that needs to be treated with a bit of respect. However, there are times when you may just need to go for it, you will need to experiment and test this command to find what works for your specific environment. In the above case we had deployed close to 500 APs for a temporary event in about 4 days, not bad going including all the cabling and other elements of a network that didn’t exist before we arrived on site. In a controlled and more permanent environment you will hopefully not be throwing caution to the wind quite as much as we were that day!