Forum

Just trying to get something clear in my head.

If you have a hidden node issue and employ RTS/CTS in a multiple security profiles/ssid on a single AP, it's going to effect them all because the NAV distribution applies to the BSS?

Virtual BSSIDs make a difference?

Is it a bandwidth (as in frequency range) issue?

Is this a good argument to set up on different APs/channels (colocation) per security profile?

Thanks.

I probably can't answer this in complete detail but holy smokes medium contention could get interesting.

Yeah RTS/CTS will effect all stations regardless of profile/ssid as they are unprotected control frames sent in the clear, so they will be heard and obeyed by all stations in ear shot of the AP & its associated stations. RTS/CTS can cut your data throughput significantly although it may improve data rate some if your hidden node is chatty and causing a high percentage of retransmissions.

Different channels may help some but depending on output power and distance from transmitter the RTS/CTS could be heard by devices on other channels.

The Arbitration white paper available on this site goes into great detail about this very issue.

A few points:

- First, you need to know what type of hidden node you have.
- The first type, the type that most people think of, is hidden station. One station can't hear another while connected to the same AP.
- The second type is called hidden AP. This is more complicated to explain, but two APs on the same channel that can't hear each other (this is good) will more than likely have stations on the same channel that can hear each other (bad, but almost unavoidable).
- If you have hidden station problem, implementing RTS/CTS on the AP won't do anything to help your problem. (I'll explain more if needed).
- If you have hidden AP problem, implementing RTS/CTS on the APs will help; how much is very dependent on the situation.
- It is a myth that RTS/CTS takes up a lot of bandwidth.
- If RTS/CTS is used for protection mode, then yes, it takes up a lot of bandwidth because it always has to be sent at a low data rate.
- If RTS/CTS is turned on manually however (say for hidden node problems) the RTS/CTS frames will Tx at normal data rates appropriate for the medium. So, with RTS being 20 bytes and CTS at 16 bytes, it really is quite a lot less overhead than one would think.
- If you have hidden node, the SSID / Virtual SSID doesn't matter. What I mean is, you either need RTS/CTS or you don't. Having it on one SSID vs. another doesn't make any sense.
- To your question about setting up multiple APs, no, it really doesn't make any sense to do it that way. If we had an infinite number of channels to use then yes, it would be great. But alas, we are stuck with three channels so multiple APs as you describe makes things worse.

If you have any further questions, let me know and I'll be happy to try to answer them.

GT

[quote]- If you have hidden station problem, implementing RTS/CTS on the AP won't do anything to help your problem. (I'll explain more if needed).[/quote]

[quote]- If RTS/CTS is used for protection mode, then yes, it takes up a lot of bandwidth because it always has to be sent at a low data rate.[/quote]

Guess I never caught on to this fact but RTS/CTS as a hidden node "fix" is only configured on the device end and is separate ballgame from automatic protection in beacons?

Setting up RTS/CTS manually on the AP doesn't set protection in the beacons?

Right... protection mechanisms [i]use [/i]RTS/CTS (or just CTS), for protection mechanisms, but it wasn't designed [i]for [/i]protection mechanisms.

RTS/CTS is actually a really simple protocol.

I wrote an explanation of it in this post.

http://www.cwnp.com/bbpress/topic.php?id=5754

GT